AWS VPC Networking for Backend Services¶

A backend service can be healthy at the application layer and still be unreachable because a route is missing, a security group blocks a connection, DNS resolves to the wrong address, or an outbound dependency depends on one Availability Zone.

AWS networking becomes easier to reason about when you separate four questions:

Where does the workload live? VPCs, CIDR ranges, subnets, and Availability Zones.
Where can packets go? Route tables, gateways, endpoints, and connections.
Which packets are allowed? Security groups and network ACLs.
How do names and failures behave? DNS, load balancers, multi-AZ design, and observability.

This guide designs a conventional internet-facing backend API with private application and database tiers. It focuses on the network path and its operational consequences, not on a particular compute platform. EC2, ECS, EKS, and managed services can all fit the same basic model, although each has service-specific networking details.

1. Start with the VPC and IP plan¶

A VPC is a logically isolated network in one AWS Region. It can contain subnets in multiple Availability Zones. A subnet, however, belongs to exactly one Availability Zone; it cannot span zones. Placing application capacity in separate AZs is therefore a deliberate part of the availability design, not a property you get merely by creating a large VPC.

Choose CIDR ranges before deploying workloads. For example, a VPC might use 10.40.0.0/16, with smaller non-overlapping ranges allocated to public, application, and data subnets in each AZ. Leave room for growth, interface endpoints, load-balancer network interfaces, container tasks, and future services. Avoid choosing ranges that overlap with networks you may later connect through VPN, Direct Connect, VPC peering, or a transit gateway.

A useful starting layout is:

Tier	AZ A	AZ B	Intended contents
Public ingress	`10.40.0.0/24`	`10.40.1.0/24`	Internet-facing load balancer; NAT gateway if required
Private application	`10.40.10.0/24`	`10.40.11.0/24`	API instances, ECS tasks, or worker nodes
Isolated data	`10.40.20.0/24`	`10.40.21.0/24`	Database and cache interfaces

These ranges are illustrative, not sizing recommendations. The correct size depends on expected interface count, scaling behavior, and service-specific subnet requirements.

Public, private, and isolated describe routing¶

A subnet is public when its associated route table has a route to an internet gateway. That route alone does not make every resource publicly reachable: an IPv4 workload also needs a public IPv4 address or Elastic IP, and security rules must allow the connection.

A private subnet has no direct route to an internet gateway. It may still have outbound internet access through a NAT device, or private access to AWS services through VPC endpoints. An isolated subnet has no route to destinations outside its VPC. It can still communicate with other VPC resources through the VPC's local route, subject to security controls.

Do not classify a subnet by its name or by whether an instance has a public IP. Inspect the route table. A public IPv4 address in a subnet without a route to an internet gateway does not create a working internet path.

2. Read the route table as the packet's next-hop decision¶

Every subnet is associated with a route table. A route has a destination and a target. The target may be the local VPC route, an internet gateway, a NAT gateway, a VPC endpoint, a peering connection, a VPN, or a transit gateway.

A simplified set of routes might look like this:

Route table	Destination	Target	Purpose
Public	`10.40.0.0/16`	local	Traffic inside the VPC
Public	`0.0.0.0/0`	internet gateway	Public ingress and egress path
App AZ A	`10.40.0.0/16`	local	Traffic inside the VPC
App AZ A	S3 managed prefix list	S3 gateway endpoint	Private S3 access
App AZ A	`0.0.0.0/0`	NAT gateway in AZ A	Required IPv4 internet egress
Data	`10.40.0.0/16`	local	Application-to-data traffic

The table is intentionally incomplete: production route tables may include routes for other VPCs, corporate networks, IPv6, or inspection appliances.

AWS selects the most specific matching route. A service-prefix route to an endpoint can therefore take precedence over a broader default route to a NAT gateway. This is useful when a private workload should reach S3 through a gateway endpoint but send other approved outbound traffic through NAT.

When a connection fails, verify the route table associated with the source subnet and the return path. A route in a different subnet's table does not help. Also check whether a route is active and whether its target exists and is available.

3. Use security groups as workload-level boundaries¶

Security groups are stateful virtual firewalls associated with network interfaces and supported resources. They contain allow rules; they do not provide explicit deny rules. Return traffic for an allowed connection is tracked automatically.

For a three-tier API, model permissions between tiers rather than opening broad CIDR ranges:

Security group	Inbound rule	Why
Load balancer	TCP 443 from approved client ranges, or the public internet for a public API	Accept HTTPS at the edge
Application	TCP 8080 from the load-balancer security group	Only the load balancer can reach the service port
Database	TCP 5432 from the application security group	Only application workloads can open database connections

The port numbers are examples. Use the actual listener and database ports for the service.

Referencing a security group as the source is usually more maintainable than copying the current private IP addresses of application instances into a database rule. As tasks or instances scale and their addresses change, the relationship remains tied to the workload's security group.

Security groups also have outbound rules. Review them deliberately. A restrictive egress policy can reduce unintended access, but it must still allow required database, endpoint, DNS, and external dependency traffic. Do not assume that allowing inbound traffic automatically permits a new outbound connection.

Security groups and network ACLs are not interchangeable¶

A network ACL applies at the subnet boundary. It is stateless and supports both allow and deny rules. Because it does not track connection state, return traffic must be allowed explicitly. For TCP connections, that often means accounting for ephemeral destination ports on the return path.

Control	Scope	State	Rules
Security group	Resource/network interface	Stateful	Allow only
Network ACL	Subnet	Stateless	Allow and deny, evaluated by rule number

Use security groups for the normal application-to-application policy. Add custom network ACLs when you have a specific subnet-level filtering requirement and can operate the inbound and outbound rule sets safely. A complicated ACL can break healthy connections even when the security groups look correct.

4. Give private workloads only the egress they need¶

A private application tier often needs to call a third-party API, download a dependency, or reach an AWS service. There are two different patterns; do not use NAT for every destination by default.

NAT gateways for outbound IPv4 internet access¶

A public NAT gateway lets resources in private subnets initiate IPv4 connections to the internet while preventing unsolicited internet connections from being initiated directly to those resources. The NAT gateway itself is placed in a public subnet and uses a route through the VPC's internet gateway.

NAT gateways are zonal resources. If private subnets in two AZs share one NAT gateway and that gateway's AZ becomes unavailable, workloads in the other AZs lose that egress path. For resilient multi-AZ services, create a NAT gateway in each active AZ and route each private subnet to the NAT gateway in the same AZ.

That design improves failure isolation but has a cost: NAT gateways have hourly and data-processing charges, and traffic that crosses AZ boundaries can add transfer cost. Compare the cost of per-AZ NAT with the actual egress requirements. If a workload only needs a small set of AWS services, endpoints may be a better fit.

A NAT gateway is not a security group. You cannot attach a security group to it. Control workload egress with the source workload's security group and use route tables to decide which destinations can use the NAT path.

VPC endpoints for private AWS-service access¶

Gateway endpoints provide private routing to Amazon S3 and DynamoDB without an internet gateway or NAT gateway. They add a service prefix-list route to the route tables you select and have no additional endpoint charge.

Interface endpoints use AWS PrivateLink. They create endpoint network interfaces with private IP addresses in selected subnets, and security groups control traffic to those interfaces. They are commonly used for supported AWS APIs and services that do not use gateway endpoints.

Endpoint policies can add a resource-access guardrail, but they do not replace IAM identity policies or service resource policies. A request can have a working network path and still receive an authorization error.

For interface endpoints, check the endpoint's subnets, security group, service name, and private DNS configuration. Private DNS lets applications continue using the normal AWS service hostname while resolving it to the endpoint's private addresses. The VPC must have DNS resolution and DNS hostnames enabled for this feature.

5. Put the load balancer at the edge, not every workload¶

For a public HTTP API, a common layout is an internet-facing Application Load Balancer in public subnets across at least two AZs, with application targets in private subnets. The load balancer terminates or forwards HTTP/HTTPS traffic and routes to target groups. The application instances or tasks do not need public IP addresses merely to receive traffic from the load balancer.

An Application Load Balancer requires subnets in at least two different AZs. AWS also recommends enough free IP addresses for scaling: each selected AZ subnet should have at least a /27 CIDR and eight free IP addresses. A subnet that is technically large enough when created can become too full as interfaces accumulate.

Choose the load-balancer type based on the protocol and routing requirement:

Application Load Balancer: Layer 7 HTTP/HTTPS routing, host/path rules, and HTTP-aware target groups.
Network Load Balancer: Layer 4 TCP/UDP/TLS traffic and network-level connection handling.

Health checks are necessary, but they are not a complete application-safety mechanism. A target can pass a shallow health check while failing real requests. Conversely, if every registered target is unhealthy, an Application Load Balancer can fail open and route to those targets. Make health checks reflect whether the service can safely accept traffic, and keep overload behavior inside the application design.

6. Treat DNS and VPC connectivity as part of the architecture¶

Use stable DNS names rather than embedding private IP addresses in application configuration. Amazon Route 53 Resolver provides DNS resolution inside a VPC. Private hosted zones let services use names such as orders.internal.example without publishing those records to the public internet.

When using private hosted zones or interface-endpoint private DNS, verify both VPC DNS attributes:

DNS resolution must be enabled.
DNS hostnames must be enabled.

Also check which VPCs are associated with a private hosted zone. A private DNS name does not automatically become resolvable from every connected network.

For VPC-to-VPC connectivity, VPC peering is a direct private connection. It is not transitive: VPC B cannot use a peering connection through VPC A to reach VPC C. Peering also requires non-overlapping IPv4 CIDR ranges. A transit gateway is usually a better hub-and-spoke option when many VPCs and network paths must be managed centrally. Choose based on routing complexity, isolation, operational ownership, and cost—not simply the number of VPCs today.

For IPv6, plan routes and security rules separately from IPv4. An egress-only internet gateway allows outbound IPv6 connections while preventing the internet from initiating connections to the workload. It is not an IPv4 NAT replacement.

7. Diagnose the whole path, not just the security group¶

A useful troubleshooting sequence follows the connection from name to process:

DNS: Does the name resolve to the intended address? Is private DNS enabled and associated with the right VPC?
Route: Does the source subnet have a route to the destination, and is the target available?
Security group: Does the source allow egress and the destination allow ingress on the expected protocol and port?
Network ACL: If custom ACLs exist, do both request and response packets match the ordered rules?
Endpoint and identity: Is the VPC endpoint reachable? Do its policy, IAM policy, and resource policy permit the operation?
Target: Is the service listening on the expected interface and port? Is the load-balancer target healthy?
Return path: Can response traffic return through the expected routes and controls?

Useful tools answer different questions:

VPC Flow Logs record IP traffic metadata for a VPC, subnet, or network interface. They can help distinguish accepted from rejected flows, but they are not packet captures and do not capture every type of traffic. Records can also be skipped.
Reachability Analyzer statically evaluates whether the configured network path between supported resources is reachable and identifies blocking components. It models configuration; it does not send test packets or prove that an application is listening.
Load-balancer target health helps determine whether registered targets pass the configured health check. It does not prove that every route or business operation works.
Application logs and metrics explain failures after the network connection reaches the service.

Start with the exact source and destination ENIs, ports, protocol, and AZs. Avoid changing several security groups and route tables at once; that makes it difficult to identify which change fixed or weakened the path.

8. Common design failures¶

Calling a subnet public because of its name: The route table, public address, and security policy determine actual reachability.
Putting application instances in public subnets by default: A public load balancer can reach private targets; application workloads rarely need direct inbound internet exposure.
Sharing one NAT gateway across AZs without accepting the dependency: A zonal failure can remove egress for workloads elsewhere.
Sending all AWS service traffic through NAT: Use gateway or interface endpoints where they fit the service and cost model.
Allowing the database from an entire VPC CIDR: Prefer an application security-group reference and the smallest required port.
Adding restrictive network ACLs without return-port analysis: Stateless rules can silently break otherwise valid TCP sessions.
Ignoring subnet address consumption: Load balancers, endpoint interfaces, and scaling workloads all need addresses.
Treating Flow Logs as a complete packet trace: Missing records do not prove that no traffic occurred.
Assuming peering is transitive: Plan a direct connection or a transit hub for multi-VPC routing.

9. Interview questions with reasoned answers¶

Q1. What makes an AWS subnet public?
Its associated route table has a route to an internet gateway. For an IPv4 instance to communicate directly with the internet, it also needs a public IPv4 address or Elastic IP and permissive security controls. A route alone does not expose every resource.

Q2. What is the difference between a security group and a network ACL?
A security group is stateful and attached to a resource's network interface; it allows traffic. A network ACL is stateless and applies at the subnet boundary; it supports ordered allow and deny rules. Use security groups for most workload policies.

Q3. Why deploy one NAT gateway per active AZ?
A NAT gateway is a zonal resource. If several AZs depend on a gateway in one AZ, failure of that AZ removes their outbound path. Per-AZ gateways with same-AZ routes reduce that dependency, at additional cost.

Q4. When should you use an S3 gateway endpoint instead of NAT?
When private workloads need S3 access, a gateway endpoint adds a route for S3's managed prefix list and avoids using NAT for that traffic. It has no additional endpoint charge. Bucket policy, IAM, and endpoint policy still determine authorization.

Q5. How do you expose an API without exposing application instances?
Place an internet-facing Application Load Balancer in public subnets across AZs. Put application targets in private subnets and allow their service port only from the load balancer's security group. Keep data services in a more restricted tier.

Q6. An application cannot connect to PostgreSQL. What do you inspect?
Confirm the database DNS name resolves correctly, the application subnet has a route through the VPC local path, the database security group allows the application's security group on the database port, and custom ACLs permit both directions. Then verify that PostgreSQL is listening and the database is healthy. Network reachability and database authentication are separate checks.

Q7. When is VPC peering insufficient?
Peering is point-to-point and non-transitive. If many VPCs need centrally managed routing, a transit gateway may be a better fit. CIDR overlap also prevents ordinary VPC peering, so address planning matters before connecting networks.

Design checklist¶

Allocate non-overlapping CIDRs with room for future interfaces and workloads.
Place ingress, application, and data resources in separate subnet tiers.
Spread critical application capacity and ingress across multiple AZs.
Review route tables for both forward and return paths.
Use security-group references between tiers and minimize exposed ports.
Use per-AZ NAT where internet egress is required; use VPC endpoints for supported AWS services.
Configure private DNS and endpoint policies deliberately.
Leave enough subnet addresses for load-balancer and service scaling.
Use Flow Logs, Reachability Analyzer, target health, and application telemetry together.
Document the expected traffic path for each critical dependency.