Last updated: June 2026
AWS Virtual Private Cloud (VPC) is the networking layer for your AWS infrastructure. It lets you define a logically isolated network within AWS (with your own IP ranges, subnets, route tables, and gateways) and control exactly what traffic can reach your resources.
Every AWS account gets a default VPC in each region. For anything beyond basic experimentation, you’ll want to configure your own.
This guide covers how VPC works, its key components, and the security controls that matter most in production environments.
With Amazon VPC you can control and restrict traffic to AWS resources and connect cloud and on-premises resources using Transit Gateways.
The on-premises comparison for the services that AWS VPC provides includes routers, modems, switches, and lots of cable.
Your VPC has a built-in router, and you can use routing tables to control network traffic. You can also control internet connectivity to a VPC and use gateways to connect your VPC to the internet, like the function of a modem. And you can create private subnets and peering connections, like you might have in a private network.
A quick example deployment of AWS Virtual Private Cloud:
A webserver and a database are hosted inside the VPC on a private subnet with no access to the internet. To allow traffic to and from the internet, a public subnet with an internet gateway is created within the VPC. For this web server to communicate with the internet a NAT (Network Address Translation) gateway is needed to send outbound traffic to the internet while staying hidden from direct access to the actual web server.
Security groups and network ACLs (Access Control Lists) must be created for the web server to communicate with the databases. This will allow inbound and outbound traffic to the webserver’s private subnet and thus the connected database.
A Virtual Private Cloud on AWS offers multiple cost-saving benefits compared to traditional on-premises networks. With AWS, customers have access to enterprise-level hardware such as routers, modems, switches, and firewalls, which are provided and managed by AWS. This means that customers no longer need to bear the overhead costs associated with managing a physical data center, such as software patching, equipment cooling, and data center security. By offloading these responsibilities to AWS, customers can reduce their total cost of ownership (TCO) for applications running on the VPC.
The VPC can also improve the level of security inside your AWS Cloud in numerous ways. By isolating a network, traffic can only flow between resources that are part of the same VPC or explicitly allowed to communicate with each other. By creating rules for inbound and outbound traffic, you can restrict access to resources thus mitigating your risk for downtime. VPCs also enable you to encrypt data in transit and at rest. Lastly, VPCs can log and monitor your network traffic in real time, enabling you to detect and respond to security incidents quickly.
Overall, a VPC can provide a more secure cloud environment by providing isolation, control, and visibility over your network traffic and resources. By mitigating some of the risks of owning a data center, you are reducing your TCO while having the freedom to scale rapidly as your application grows.
AWS VPC’s key components include:
Virtual Private Cloud Subnets
A subnet is a group of IP addresses. While Amazon VPC covers all the availability zones in a specific region, subnets are restricted to a single availability zone. Subnets are public when their traffic is routed via an internet gateway and private when the internet gateway is not attached.
In order to enable internet access to a subnet, the route table of the subnet should have an entry that diverts internet traffic to the internet gateway. Each instance in the subnet is assigned a unique private and public IP address. When traffic flows out of the internet gateway, the public IP address is used for communication. Conversely, when traffic flows into the VPC, the public IP address is translated to the private one, which remains hidden from the external world. This is called IP masquerading.
On-Premises Communication
Communication between an on-premises data center and Amazon VPC can be established using IPSec over the internet, AWS Direct Connect, or AWS PrivateLink. With IPSec over the internet, VPN connections are configured over the internet to establish communication between the data center and AWS cloud. If you don’t want to create connections over the internet, you can use AWS Direct Connect or AWS PrivateLink to establish a connection between your on-premises resources and Amazon VPC. Because traffic never leaves the AWS network, AWS PrivateLink does not require a VPN connection, NAT instances, or a direct link.
How AWS Virtual Private Cloud Enhances Cloud Security
AWS Virtual Private Cloud can enhance cloud security using features such as:
Security Groups
Security groups act as the firewall for Amazon VPC resources and are assigned at the instance level. If you want to restrict traffic to and from an Amazon EC2 instance, create a security group. A default security group will be assigned if you do not choose one explicitly. There can be a maximum of five security groups assigned to one instance.
Network Access Control Lists
A network access control list (ACL) is an optional line of defense for your VPC and is configured at subnet level. Default ACLs allow all inbound and outbound traffic, both IPv4 and IPv6, through your subnet.
Flow Logs
Flow logs help monitor and troubleshoot Amazon VPC’s network interfaces and subnets. You can enable flow logs for an interface or subnet that you want to monitor and access the flow logs via Amazon CloudWatch. While there are no additional charges for using the flow logs, CloudWatch charges will apply.
- Use VPC endpoints to secure access to AWS services: Set up VPC endpoints to connect privately to AWS services like S3 and DynamoDB without exposing your traffic to the public internet. This reduces the attack surface and enhances data security.
- Automate VPC configuration backups: Regularly back up your VPC configurations, including routing tables, subnets, and security groups, using tools like AWS Config or N2WS. Automate these backups to ensure you can quickly restore your VPC settings in the event of accidental changes or failures.
- Segment workloads with multiple VPCs: For better security and management, segment different workloads into multiple VPCs instead of placing all resources in a single VPC. Use peering connections or Transit Gateway for secure communication between VPCs.
- Deploy Transit Gateway for scalable architecture: Implement AWS Transit Gateway to simplify and scale your network architecture. Transit Gateway enables you to easily manage communication between multiple VPCs, on-premises data centers, and even other AWS accounts, providing a hub-and-spoke model that enhances network efficiency.
- Regularly test VPC failover scenarios: Simulate VPC failover scenarios using N2WS or AWS CloudFormation templates to ensure that your disaster recovery processes work smoothly. Regular testing ensures that all dependencies are accounted for and that your environment can be restored quickly in a different region or account.
How to protect AWS VPC
Amazon VPC is the backbone of AWS cloud security, providing multiple ways to establish a secure communication with corporate data centers, such as through VPN connections and direct and private links. With the help of security groups and access control lists, inbound and outbound traffic can be further restricted to provide complete end-to-end network security.
But what do you if you have an outage or other event that requires you to restore your VPC configuration?
Because AWS Backup doesn’t support VPC backup, you’ll likely want a cloud-native solution like N2W, which can capture the VPC and Transit Gateway settings as root resources (including the related resources) of user environments and clone those settings back to AWS:
- In the same region and account, for example, if the original settings were lost.
- To another region and/or account, such as in DR scenarios.
- With VPC resource properties modified in template uploaded with CloudFormation, if required.
Plus, with N2W, you have built-in resiliency features, like AWS disaster recovery and cost-saving features like cold storage for backups.
FAQ: AWS VPC
A VPC is the entire isolated network. It spans all availability zones in a region. A subnet is a segment within that VPC, restricted to a single AZ. Public subnets route traffic through an internet gateway; private subnets don’t. Most production architectures use multiple subnets across at least 2 AZs for redundancy.
VPC peering creates a direct network connection between two VPCs, letting resources in each communicate using private IP addresses. Traffic stays within the AWS network and doesn’t go through the internet, a VPN, or a gateway. Peering works within a single account, across accounts, and across regions. One limitation: peering isn’t transitive. If VPC A is peered with VPC B and VPC B is peered with VPC C, A can’t reach C through that chain (you’d need a direct peering or Transit Gateway instead).
The VPC itself is free. You pay for the resources inside it and for specific networking components: NAT gateways ($0.045/hour + $0.045/GB processed), VPC endpoints ($0.01/hour per AZ + data processing), VPN connections ($0.05/hour), and AWS PrivateLink endpoints ($0.01/hour per AZ). Data transfer out of a VPC to the internet is charged at standard AWS egress rates.
No. VPCs are isolated by default, even within the same account and region. You need to explicitly enable communication via VPC peering, AWS Transit Gateway, or VPC endpoints. Security groups and NACLs add another layer of control on top of that.
AWS Backup doesn’t support VPC backup. To protect your VPC settings (route tables, subnets, security groups, gateways) you have a few options: export the configuration manually using AWS CLI (aws ec2 describe-vpcs and related commands), use AWS Config to track and record configuration changes over time, or use N2WS, which captures VPC and Transit Gateway settings as root resources and can restore them to the same region, a different region, or a different account. That last option is the one that matters for actual disaster recovery scenarios.