AWS VPC Explained for Web Developers: From Browser to Database
Learn how AWS VPCs, subnets, route tables, internet gateways, NAT gateways, and security groups work together. Follow a typical web application request to understand how AWS networking controls connectivity between application servers, databases, and the internet.
AWS VPC Explained for Web Developers: From Browser to Database
You deploy an API to an EC2 instance, but it cannot connect to your database. Or your application can reach the database, but it cannot call an external API.
These problems can look like application bugs, but the cause may be in the AWS network configuration.
A route table might send traffic to the wrong destination. A security group might block the connection. A private subnet might not have a route to a NAT gateway.
Understanding Amazon Virtual Private Cloud, commonly known as VPC, makes these problems easier to investigate. Instead of treating AWS networking as a collection of unrelated services, you can follow the traffic and understand how each component affects connectivity.
1. What Is an AWS VPC?
An Amazon VPC is a logically isolated virtual network that you define inside an AWS Region.
It provides the network foundation for resources such as EC2 instances, load balancers, and databases. You configure its IP address ranges, subnets, routing, and network access controls according to your application's requirements.
For example, a web application might use this arrangement:
VPC: 10.0.0.0/16|| Public Subnets| Application Load Balancer|| Private Subnets| Application Servers|| Private Subnets| DatabaseThis is a logical overview rather than a complete network configuration. The actual connectivity depends on route tables, security groups, IP addressing, and other relevant settings.
A VPC does not automatically make every resource public or private. You need to configure the network so that the required connections work without exposing resources unnecessarily.
2. Understanding Subnets and Availability Zones
A subnet is a range of IP addresses within a VPC. Every subnet belongs to one Availability Zone, while a VPC can span multiple Availability Zones in the same Region.
Suppose your VPC uses the IPv4 CIDR block
10.0.0.0/16 . You could divide it into smaller ranges:VPC: 10.0.0.0/16
Public Subnet:10.0.1.0/24
Private Application Subnet:10.0.2.0/24
Private Database Subnet:10.0.3.0/24These ranges are examples. When planning a real network, account for AWS reserved addresses, expected resource counts, and future growth.
Public and private subnets
A public subnet has a route to an internet gateway. A private subnet does not have a direct route to an internet gateway.
However, a route to an internet gateway does not automatically make every resource in a public subnet reachable from the internet.
For example, an EC2 instance generally needs a suitable public IPv4 address, an appropriate route, and security rules that permit the required inbound traffic to be directly reachable over IPv4.
Resources in private subnets can still communicate with other resources in the VPC. They can also access supported external destinations through other network paths, such as a NAT gateway.
Why Availability Zones matter
For a production application, you might distribute your load balancer and application servers across multiple Availability Zones.
This helps reduce dependence on a single zone, provided the application and its other dependencies are designed to tolerate a zone failure.
For example:
AWS Region|| VPC|| Availability Zone A| | Public Subnet| | Private Subnet|| Availability Zone B | Public Subnet | Private SubnetEach subnet belongs to only one Availability Zone. If you deploy application resources across multiple zones, consider the placement and availability of supporting network components as well.
3. Route Tables: Where Does Traffic Go?
A route table contains rules that determine where network traffic should be directed based on its destination IP address.
Each route has a destination and a target.
For example:
Destination Target10.0.0.0/16 local0.0.0.0/0 Internet GatewayThe
10.0.0.0/16 route allows traffic within the VPC's IPv4 range to use the local route.The
0.0.0.0/0 route is a default route for IPv4 destinations that do not match a more specific route. In this example, traffic is directed to an internet gateway.AWS selects the most specific matching route for a destination.
A subnet is associated with one route table at a time, either explicitly or through the VPC's main route table.
Why route tables matter
Imagine that an application server needs to call an external API.
Even if the instance has a public IP address, connectivity can fail if the subnet's route table does not provide an appropriate path.
For a private subnet that uses a public NAT gateway, the route table might look like this:
Destination Target10.0.0.0/16 local0.0.0.0/0 NAT GatewayThe NAT gateway must also have an appropriate route to the internet gateway through its public subnet.
When troubleshooting a failed connection, inspect the route table alongside the relevant security group rules. A valid route does not override a security rule that blocks the traffic.
4. Internet Gateways: Connecting a VPC to the Internet
An internet gateway provides connectivity between a VPC and the internet.
Attaching an internet gateway to a VPC is only one part of the configuration. For an EC2 instance to receive direct inbound IPv4 traffic from the internet, several conditions generally need to be met:
- The VPC has an attached internet gateway.
- The subnet's route table has an appropriate route to that gateway.
- The instance has a suitable public IPv4 address.
- Its security group permits the required inbound traffic.
- Other applicable network and operating system controls allow the connection.
A simplified view looks like this:
User's Browser | v Internet | vInternet Gateway | v Public Subnet | v EC2 InstanceThe diagram represents the logical connectivity path, not every detail of packet routing.
For a typical production web application, it is often better to expose an Application Load Balancer rather than make every application server directly reachable from the internet.
The load balancer receives client requests and forwards them to application targets according to its listener and target group configuration.
This gives you a clear place to manage public entry traffic while keeping the application servers in private subnets.
5. NAT Gateways: Outbound Access for Private Resources
Consider an application server that needs to download software updates or call an external payment API.
You want the server to initiate these connections without making it directly reachable from the public internet.
A public NAT gateway can provide this outbound connectivity when the relevant routes and controls are configured correctly.
The traffic path looks like this:
Private Application Server | vPrivate Route Table0.0.0.0/0 → NAT Gateway | vPublic SubnetPublic NAT Gateway | vPublic Route Table0.0.0.0/0 → Internet Gateway | v InternetThe private subnet sends supported outbound internet traffic to the NAT gateway. The NAT gateway uses its public network path to reach internet destinations.
A public NAT gateway does not allow unsolicited inbound connections from the internet to the private instances using it. It supports outbound connections and their associated response traffic.
AWS also offers private NAT gateways, which serve different networking purposes. The example above specifically describes a public NAT gateway.
NAT gateways and cost
NAT gateways have hourly and data processing charges. Their placement can also affect data transfer costs and availability.
For production workloads that require resilient outbound connectivity, deploying a NAT gateway in each active Availability Zone is a common design. This can reduce cross zone dependencies and help preserve outbound connectivity if a zone becomes unavailable.
However, not every application needs general internet access from its private subnets.
If your application needs to access supported AWS services, VPC endpoints may be a better option for some traffic. For example, an S3 gateway endpoint can route supported Amazon S3 traffic through the endpoint without requiring that traffic to pass through a NAT gateway.
Access still depends on the applicable IAM permissions, bucket policies, endpoint policies where configured, and network configuration.
6. Security Groups: Controlling Which Connections Are Allowed
Route tables determine where traffic goes. Security groups control which traffic is allowed to reach the associated resources and network interfaces.
Security groups are stateful. When a connection is allowed, response traffic for that connection is automatically permitted by the security group's connection tracking behavior.
Security groups use allow rules. You can specify protocols, ports, and permitted sources or destinations.
Consider an application with a load balancer, application servers, and a PostgreSQL database.
Load Balancer Security GroupAllow inbound HTTPS from intended clients | vApplication Security GroupAllow application traffic from Load Balancer SG | vDatabase Security GroupAllow TCP 5432 from Application SGHere is how the rules work:
Load balancer: Allow inbound HTTPS traffic on port
443 from the intended clients. Configure its outbound permissions to allow traffic to the application targets and health check ports.Application servers: Allow inbound traffic on the application's listening port from the load balancer's security group. The servers do not need to accept arbitrary inbound connections from the internet.
Database: Allow inbound TCP traffic on port
5432 from the application security group. This is the default PostgreSQL port.Referencing the application security group is often easier to maintain than listing individual application server IP addresses. As instances change, the rule continues to identify the permitted source by its security group association.
The important principle is to allow only the traffic required for each component to operate.
A database that serves an application backend generally should not accept connections from arbitrary public IP addresses.
7. Security Groups vs Network ACLs
AWS also provides Network Access Control Lists, commonly called Network ACLs.
Both security groups and Network ACLs control network traffic, but they work differently.
Feature | Security Group | Network ACL |
|---|---|---|
Applies to | Network interfaces and associated resources | Subnets |
Connection tracking | Stateful | Stateless |
Rules | Allow rules | Allow and deny rules |
Return traffic | Automatically permitted for tracked connections | Must be allowed by the applicable rules |
Rule evaluation | All applicable rules are considered | Rules are evaluated in ascending rule number order |
Because Network ACLs are stateless, you must account for both inbound and outbound traffic, including the applicable ephemeral ports.
Network ACLs can provide an additional layer of subnet level control, but they do not replace security groups.
For many web applications, security groups are the main place to define which components can communicate with each other. Network ACLs are useful when you need additional subnet level traffic restrictions.
8. Putting Everything Together: A Web Application on AWS
Let's put these components into one example.
Suppose you have a web application with an API running on EC2 and a PostgreSQL database hosted on Amazon RDS.
A possible architecture is:
Internet | v Internet Gateway | v Public Subnets | v Application Load Balancer | v Private Subnets Application Servers | v Private Subnets Amazon RDSIn a production deployment, you would typically consider multiple Availability Zones for the load balancer, application servers, and database configuration.
For Amazon RDS, a DB subnet group normally includes subnets in at least two Availability Zones. The database's public accessibility setting and security group rules are separate considerations when determining whether it can be reached from outside the VPC.
Now follow a request through the application.
Step 1: The browser sends a request
A user opens your application. The request reaches the public Application Load Balancer through the configured public network path.
The load balancer receives the request and selects a healthy target based on its listener and target group configuration.
Step 2: The load balancer forwards the request
The load balancer's security group permits the incoming HTTPS connection.
The application server's security group allows the relevant application traffic from the load balancer's security group.
The application server does not need a public IP address just to receive requests forwarded by a load balancer.
Step 3: The application queries the database
The application connects to the RDS endpoint using the configured database port.
The database security group allows the connection from the application security group.
If the database security group does not permit that traffic, the connection can fail even when the route between the resources is available.
Step 4: The application calls an external API
Suppose the application needs to contact an external payment provider.
If the application server is in a private subnet, its route table can direct outbound internet traffic to a public NAT gateway.
The NAT gateway provides the required outbound path through the internet gateway.
If the application also accesses AWS services such as S3, suitable VPC endpoints may allow some of that traffic to bypass the NAT gateway.
The network design should reflect the actual connections the application needs, rather than enabling broad connectivity by default.
9. Common VPC Mistakes Developers Should Avoid
Understanding the components is useful, but knowing how they interact is what helps when something fails.
Mistake 1: Assuming an internet gateway makes every resource public
An internet gateway alone is not enough. Routing, IP addressing, and security controls determine whether a resource is reachable.
Mistake 2: Giving a database unnecessary public access
A database that serves only an application backend generally does not need direct public internet access. Private subnets and narrowly scoped security group rules are a sensible starting point.
Mistake 3: Assuming private subnets cannot access the internet
Private subnets can have outbound internet access through a NAT gateway. Suitable VPC endpoints can also provide private connectivity to supported AWS services.
Mistake 4: Opening database ports to everyone
Allowing database connections from
0.0.0.0/0 is rarely appropriate for an application database.Instead, permit connections from the application security group and any additional trusted sources that are genuinely required.
Mistake 5: Confusing routes with permissions
A route table can provide a path to a destination, but that does not mean security groups or other controls will allow the connection.
When troubleshooting, check the route table and the relevant access rules rather than assuming one configuration controls everything.
Mistake 6: Ignoring Availability Zone dependencies
An application might run across multiple Availability Zones while depending on a network component in only one zone.
Review the placement of NAT gateways, application instances, load balancers, and databases to understand what happens if an Availability Zone becomes unavailable.
10. A Simple Mental Model
Each VPC component has a different responsibility.
VPC: Defines the virtual network.
Subnets: Divide the network into IP address ranges within individual Availability Zones.
Route tables: Determine where traffic is directed.
Internet gateway: Provides a connection between a VPC and the internet.
NAT gateway: Provides supported outbound connectivity for private resources without allowing unsolicited inbound connections to those resources.
Security groups: Control permitted traffic for associated resources and network interfaces.
Network ACLs: Apply stateless traffic rules at the subnet level.
A working network depends on configuring these components together. No single component provides all the connectivity and security controls an application needs.
Conclusion
When an AWS application cannot communicate with another resource, check the network path before assuming the application code is responsible.
Start with the destination, inspect the route table, and verify the relevant security group rules. If the request needs internet access, check whether the resource has the appropriate public connectivity or an outbound path through a NAT gateway.
These checks will not solve every networking issue, but they provide a useful starting point for troubleshooting web applications on AWS.
The goal is not to memorize every VPC feature. It is to understand how traffic moves through your application and which configuration controls that movement.
Further Reading
For more details, refer to the official AWS documentation:
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article