What is a VPC and how does it work?

What is a VPC and how does it work?

What is Amazon VPC in simple words?

Amazon Virtual Private Cloud (Amazon VPC) is a service that lets you create dedicated, private networks in AWS. A VPC can be thought of as your private slice of the AWS network. It's like having your own isolated network within the cloud, where you can launch AWS resources in a virtual environment that you control. This service can be likened to a traditional network that you'd operate in your own data center, but with the benefits of the scalable infrastructure of AWS.

In VPC you can define the IP address range and subnets, decide whether instances in these subnets can reach the internet, and control inbound and outbound traffic through the use of Network Access Control Lists and Security Groups.

Basics of Amazon VPC

A VPC is a private virtual network in AWS, where you can deploy AWS resources such as EC2 instances and RDS databases. You're not limited to a single VPC, you can create as many as you want. In fact, you're encouraged to create a new VPC for every workload that you want to deploy.

Default VPC

When you create an AWS account, a default VPC is set up for you in each region. This ready-to-use environment makes it easy for you to start deploying instances right away. Every EC2 instance that you launch in the default VPC has a private and a public IP address, allowing these instances to communicate out to the internet and enabling the internet to communicate back, through AWS's infrastructure.

While the default VPC is user-friendly and facilitates easy transitioning for new users, it might not fulfill the requirements of more complex or larger systems. Its configuration is rather general, and it may lack the necessary security settings or the architectural segregation essential for more sophisticated infrastructures.

Creating additional VPCs

Creating additional VPCs allows you to segment your network for different purposes, like maintaining separate VPCs for production and development environments. These additional VPCs are entirely independent from your default VPC and from each other, ensuring isolation and security of your various environments.

When you create a new VPC, it comes with its own IP address range, router, default security groups, network access control list (NACL), and route table. You can also add more subnets, security groups, network ACLs, etc., according to your project's requirements.

Creating additional VPCs also provides opportunities for advanced networking architectures. For instance, you can implement VPC peering for secure communication between different VPCs or establish a VPN connection between your office network and your VPC.

Master AWS with Real Solutions and Best Practices. Subscribe to the free newsletter Simple AWS. 3000 engineers and tech experts already have.


Amazon VPC includes a wide array of networking components that allow you to design your network in a way that best suits your needs for architecture, security and connectivity. These components work together to provide connectivity, security, and functionality to your VPC.

Internet Gateway

An Internet Gateway (IGW) is a pivotal component that provides a path for network traffic between your Amazon VPC and the internet. It's an AWS-managed component designed to be highly available and horizontally scalable, ensuring reliability and performance.

The IGW plays two critical roles. Firstly, it serves as a route through which your VPC can communicate with the internet. Secondly, it performs network address translation (NAT) for instances that have been assigned public IPv4 addresses.

To enable internet access within a VPC, you must attach an IGW to your VPC, update your subnet's route table to direct traffic to the IGW, and ensure instances have publicly routable IP addresses (public or Elastic IPs).

Route Table

Route Tables form the backbone of your network traffic flow. They consist of a set of rules, known as routes, which determine where network traffic should be directed within your VPC. Every subnet in your VPC must be associated with a route table.

By default, each VPC uses a main route table, but you can create additional custom route tables that specify more precise routes. A route table can have multiple routes that influence the traffic from and to the subnets associated with it.

Each subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table. By manipulating route tables, you have control over the network traffic paths, which can help enhance your network security and efficiency.

Public and Private Subnets

A public subnet is defined as any subnet that has a route to an IGW in the main or associated route table, thereby allowing instances in the subnet to connect directly with the internet.

In contrast, a private subnet doesn't have a route to the IGW, restricting instances in the subnet from having direct access to the internet. However, internet access can still be achieved indirectly by using a NAT gateway or NAT instance, allowing instances to download necessary updates or software while maintaining the private nature of the subnet.

Private, Public, and Elastic IP Addresses

In Amazon VPC, each instance is assigned a private IP address from the IPv4 address range of your VPC. Public IP addresses are reachable from the internet, but only if the network security group and network ACLs associated with your subnet allow such traffic, and if the instance is in a public subnet.

Public IP addresses are only assigned to an instance upon launching or when you allocate an Elastic IP address. Elastic IP addresses are static, public IPv4 addresses that are reserved for your AWS account, and you can associate or disassociate them with your instance as needed.

NAT Gateway

A NAT Gateway is a AWS managed service that provides instances in a private subnet access to the internet, but prevent the internet from initiating a connection with those instances. It's used for scenarios where instances in the private subnet need to download patches, updates, and other necessary data, but don't need to be accessible from the internet.

A common pattern for web services is for them to be accessible through a public Load Balancer, in which case instances don't need to be accessed directly. For securiy reasons, those instances should be placed in private subnets. In those cases a NAT Gateway will grant the instances access to the internet without making them directly accessible from the internet, enabling all functionality with a secure configuration.

Access the internet from your instances

Instances without a public IP can access the internet in two ways. One method is through a NAT device, which translates the private IP addresses of the instances to public IP addresses for outgoing internet traffic. The other way is to use a VPC Endpoint, which allows private connectivity to services across your VPC, without routing traffic across the public internet.

VPC Peering

VPC Peering is a networking connection between two VPCs, either within the same region or across different AWS regions, that enables you to route traffic between them privately. Instances in a peered VPC can communicate with each other as if they were within the same network. VPC peering connections are not transitive, meaning if you have a peering connection between VPC A and VPC B, and between VPC B and VPC C, VPC A does not have automatic access to VPC C.

Security Groups and Network ACLs

In the context of Amazon VPC, security groups and Network Access Control Lists (Network ACLs) are features that help secure your resources. They act as virtual firewalls that control the inbound and outbound traffic to your instances and subnets.

Security Groups for Web Servers

Security Groups act at the instance level, providing high-granularity access control. Each security group you create for your web servers should include rules that allow inbound and outbound traffic as necessary for your web applications.

For instance, a security group for a web server often allows inbound traffic on HTTP and HTTPS ports 80 and 443, respectively, to permit incoming client requests. It would typically allow outbound traffic on all ports to facilitate responses to client requests and communication with other components of the application.

If your web server needs to communicate with a database server, you might allow outbound traffic to the specific port your database server listens on, typically connecting to the security group your database server belongs to.

Security Groups for Database Servers

In contrast to web servers, database servers usually have a stricter set of rules. Inbound traffic is generally limited to specific ports that the database listens on, such as 3306 for MySQL or 5432 for PostgreSQL. This traffic is often allowed only from specific sources, such as the security group attached to your web servers, thus restricting access to only the necessary instances.

Outbound rules for a database server security group are usually less restrictive. Many configurations allow all outbound traffic, as responses to legitimate inbound requests and for necessary communication with other parts of the application.

Security Group Rules

Security Group rules are always permissive; you can't create rules that deny access. An absence of a rule is an implicit deny. Also, security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules.

You can add rules to a security group that allow traffic to or from its associated instances. You can modify the rules of a security group at any time; the new rules are automatically applied to all instances associated with the security group.

Network ACLs

Network ACLs operate at the subnet level and provide a second layer of defense if your security group rules are not sufficient. Unlike security groups, Network ACLs have separate inbound and outbound rules, and each rule can either allow or deny traffic. Network ACLs are stateless, which means return traffic must be explicitly allowed by rules.

By default, each VPC comes with a modifiable default network ACL that allows all inbound and outbound traffic. When you create a new network ACL, it denies all inbound and outbound traffic until you add rules.

Overall, the combined use of security groups and Network ACLs can help ensure your VPC's security and integrity, enabling you to establish the precise access control that your applications require.

Pricing for Amazon VPC

There are no extra charges for creating and using a VPC itself. You pay for the AWS resources (like EC2 instances, EBS volumes) that you choose to launch within your VPCs.

However, note that some components associated with Amazon VPC, such as NAT Gateway, VPN Connections, and data transfer costs, have their own pricing structures. For example, there may be charges for data transfer between your VPC and your on-premises data center if it's done through the public internet.

Moreover, while inbound data transfer is typically free, outbound data transfers are charged after the first GB per month. These prices vary depending on the region and the specific service used.

Remember to monitor and adjust your resources as needed, taking advantage of the AWS Free Tier when possible to reduce costs.

In conclusion, Amazon VPC is a powerful tool that allows you to leverage the benefits of a private, isolated network while capitalizing on the scalability and efficiency of the AWS Cloud. It provides a reliable foundation upon which you can build your cloud infrastructure, making it an essential component of any robust AWS environment.

Master AWS with Real Solutions and Best Practices.
Join over 3000 devs, tech leads, and experts learning real AWS solutions with the Simple AWS newsletter.

  • Analyze real-world scenarios

  • Learn the why behind every solution

  • Get best practices to scale and secure them

Simple AWS is free. Start mastering AWS!

If you'd like to know more about me, you can find me on LinkedIn or at www.guilleojeda.com

Did you find this article valuable?

Support Guillermo Ojeda by becoming a sponsor. Any amount is appreciated!