Lesson 2.3: Developer-focused networking fundamentals
Networking in Amazon Web Services directly shapes how an application behaves at runtime. Most connectivity failures are not caused by code defects but by VPC design decisions. As developers, we must understand how subnets, routing, and traffic controls determine which services can communicate and which cannot.
The goal is not to master enterprise networking theory. The goal is to reason clearly about reachability, isolation, and failure patterns in real application scenarios.
VPC components and traffic flow
A Virtual Private Cloud (VPC) is a virtual network within a region where our AWS resources operate. Subnets divide the VPC into Availability Zone–specific segments, and whether a subnet is public or private depends entirely on its route table configuration.
A subnet becomes public only when its route table includes a route to an Internet Gateway. Without that route, even a resource with a public IP address cannot receive internet traffic. Private subnets lack this route and are typically used for databases and internal services.
Route tables define where outbound traffic goes, while Elastic Network Interfaces (ENIs) attach resources such as EC2 instances or VPC-enabled Lambda functions to subnets. If routing is incorrect, traffic fails before IAM policies are even evaluated.
A quick way to verify routing is through the CLI:
aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-12345
When diagnosing issues, remember that timeouts usually indicate routing or network security problems, not permission errors.
Security groups and network ACLs
Security groups act as stateful firewalls attached to individual resources. They control inbound and outbound traffic and automatically allow return traffic for established connections. Because they operate at the resource level, they are the primary access control mechanism for EC2 instances, RDS databases, and VPC-attached Lambda functions.
A common pattern is to allow database access only from the application’s security group. This enforces least privilege at the network layer and prevents direct exposure.
Network ACLs (NACLs) operate at the subnet level and are stateless. Both inbound and outbound rules must explicitly allow traffic, including return traffic. If return traffic is not allowed, connections fail with timeouts rather than explicit errors.
A typical rule to allow HTTP traffic in a NACL looks like:
aws ec2 create-network-acl-entry \
--network-acl-id acl-12345 \
--rule-number 100 \
--protocol tcp \
--port-range From=80,To=80 \
--cidr-block 0.0.0.0/0 \
--rule-action allow \
--ingress
In most development scenarios, security groups are the primary control point. When troubleshooting, evaluate security groups first, then routing, and then NACL rules.
Application entry points: API Gateway, CloudFront, and Route 53
While VPC networking defines internal connectivity, most applications also require managed entry points that route external traffic to backend services.
Amazon API Gateway provides a fully managed interface for exposing APIs to clients. It handles request routing, authentication, throttling, and integration with services such as Lambda, ECS, or HTTP backends. In many serverless architectures, API Gateway acts as the primary ingress layer.
Amazon CloudFront is a global content delivery network (CDN) that caches content at edge locations close to users. It improves latency and reduces load on origin services such as S3, API Gateway, or Application Load Balancers. CloudFront is commonly used to distribute static websites, APIs, and media content securely and efficiently.
Amazon Route 53 is the DNS service that directs client requests to the correct endpoint. It supports routing policies such as latency-based routing, failover routing, and weighted traffic distribution, allowing applications to implement high availability and traffic management strategies.
Together, these services often form the public entry path for AWS applications:
NAT Gateway and private subnet design
Resources in private subnets cannot access the internet directly, yet many workloads still require outbound connectivity to external APIs or public AWS endpoints.
A NAT Gateway enables outbound-only internet access for private subnet resources. It is deployed in a public subnet and referenced in the private subnet’s route table. Without it, outbound calls fail with timeouts.
This becomes especially important when attaching Lambda functions to a VPC. By default, Lambda has internet access. Once placed inside a VPC, it loses that default connectivity. If the function must call external services, a NAT Gateway or VPC endpoint must be configured.
A route to a NAT Gateway typically looks like:
aws ec2 create-route \
--route-table-id rtb-12345 \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id nat-12345
For high availability, NAT Gateways should be deployed in each Availability Zone. Routing traffic from one AZ to a NAT Gateway in another AZ adds latency and incurs cross-AZ data transfer charges in addition to standard transfer costs.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
