A multi-tier VPC design should make the application’s trust boundaries visible in the network rather than placing every component in one flat subnet. Public entry points, private application services, databases, management paths, and outbound access have different exposure requirements. Amazon VPC provides the address space, subnets, route tables, gateways, endpoints, and security controls needed to express those differences while still allowing the tiers to communicate.
The current SAA-C03 perspective includes secure, resilient, high-performing, and cost-aware network architecture. A good VPC design therefore balances isolation with operability: it keeps private resources off the public internet, spreads critical components across Availability Zones, provides controlled egress and service access, and remains understandable when troubleshooting a failed connection.
Define tiers by exposure and responsibility
Begin with the application flow. Internet users may enter through a public Application Load Balancer or another managed edge service. The application tier can run in private subnets, reachable only from the load-balancer security group. Databases can run in dedicated private subnets with access limited to the application tier. Management and platform services may use separate paths or VPC endpoints.
Subnets are useful segmentation constructs, but a subnet alone is not a security boundary. Route tables determine where traffic can go, while security groups control stateful traffic to resources and network ACLs can add stateless subnet-level controls. The design should use each layer for a clear purpose instead of creating overlapping rules nobody understands.
Do not expose an EC2 instance simply because the application needs outbound software updates. Private subnets can reach approved external destinations through NAT or use private VPC endpoints for supported AWS services, keeping the instance itself without a public IP address.
Spread critical tiers across Availability Zones
Resilience starts with more than one Availability Zone. Public and private subnets should be created across at least two AZs for production workloads that need to tolerate an AZ failure. Load balancers, Auto Scaling groups, and managed databases can then distribute components across those zones.
Keep dependencies aligned with the same failure goal. Deploying application instances in two AZs provides limited value if both rely on a NAT gateway, self-managed firewall, or stateful service in one AZ. AWS VPC examples commonly place a zonal NAT gateway in each AZ for resilient private-subnet egress, and newer regional NAT gateway options may simplify some architectures.
A high-availability target should reflect the whole request path. The application is only as available as the least resilient required dependency.
Design public ingress separately from private workload networking
Public subnets contain resources that need a route to an internet gateway, but that does not mean every resource in a public subnet is automatically reachable from the internet. A public IPv4 address, route, and security policy are all part of internet reachability. In a multi-tier design, keep the public footprint narrow.
Application Load Balancers are common public entry points for HTTP and HTTPS. They terminate or pass TLS according to design, perform health checks, and distribute traffic to private targets. Network Load Balancers serve different needs such as layer-4 traffic and static IP characteristics. Choose the load balancer from protocol and application requirements.
The cloud load-balancing model helps separate entry-point architecture from instance placement. A load balancer improves distribution and health-based routing; it does not remove the need for private subnet design or secure target groups.
Give private tiers controlled outbound connectivity
Private instances often need outbound access for package repositories, external APIs, certificate validation, or operating-system services. A NAT gateway can provide outbound IPv4 connectivity while preventing unsolicited inbound connections from the internet. The private subnet route points appropriate destinations to the NAT path.
Use the NAT path intentionally. Sending all AWS service traffic through a NAT gateway adds data processing and creates unnecessary public service endpoints when a private endpoint is available. Gateway VPC endpoints provide private access to Amazon S3 and DynamoDB without a NAT gateway, and interface endpoints use AWS PrivateLink for many other services.
Review egress as a security boundary. Application tiers should not automatically have unrestricted outbound internet access if the workload does not need it. Network Firewall, proxy services, domain controls, security groups on interface endpoints, and route segmentation can reduce the destinations a compromised instance can reach.
Use VPC endpoints to keep service traffic private
VPC endpoints connect workloads to supported AWS services without requiring traffic to traverse an internet gateway or NAT device. Gateway endpoints for S3 and DynamoDB become route-table targets. Interface endpoints create elastic network interfaces in selected subnets and are powered by AWS PrivateLink.
Endpoint policy, service policy, IAM identity policy, and resource policy can all participate in authorization. A private network path does not mean the caller is automatically authorized. Design the endpoint as a connectivity control and keep data-access permissions explicit.
Private DNS settings deserve attention for interface endpoints. Applications often continue using the normal service hostname while DNS resolves it to the endpoint’s private addresses. Hybrid DNS and custom resolver configurations can affect this behavior, so endpoint design should be tested from the actual workload subnet.
Use security groups as the primary workload traffic control
Security groups are stateful and attach to supported resources such as EC2 network interfaces, load balancers, and database interfaces. Prefer references to other security groups when the relationship is between application tiers. For example, allow the application security group to receive HTTPS only from the load-balancer security group rather than from an entire subnet CIDR.
That relationship follows the logical tier even as Auto Scaling replaces instances. CIDR-based rules still have a place for external networks, shared infrastructure, or protocols where security-group references are not available, but they should not be the default for every internal dependency.
A broader AWS security toolkit remains necessary around the VPC. Network controls reduce exposure; identity policies, encryption, detection, vulnerability management, and logging address different parts of the risk.
Plan IP address space for growth and connectivity
Choose VPC and subnet CIDR blocks with future connectivity in mind. Address overlap can block peering, Transit Gateway, VPN, and Direct Connect designs later. Enterprises should allocate cloud CIDRs from a managed plan rather than letting each team select an arbitrary 10.0.0.0/16.
Subnet sizing should consider load balancers, Auto Scaling, managed services, and interface endpoints that consume addresses. A subnet that appears large for today’s EC2 count can become constrained after many endpoint network interfaces and scaling events. Reserve enough space for failure conditions as well as normal capacity.
DHCP fundamentals remain useful context, but VPC address management is primarily driven by CIDR planning, AWS-provided subnet behavior, private DNS, and the interfaces created by managed services.
Observe the packet path from source to destination
When a connection fails, trace it systematically: source IP and security group, source subnet route, gateway or transit hop, destination route, destination security group, network ACLs, application listener, and return path. Randomly editing several layers at once makes the failure harder to understand.
VPC Flow Logs can show accepted and rejected network flows, although they do not replace application logs. Reachability Analyzer can reason about network configuration between supported endpoints. Load-balancer health checks provide another view of whether a target is reachable and responding as expected.
Keep diagrams synchronized with infrastructure as code or automated inventory. In a dynamic environment, a static drawing can become misleading quickly. Operators need current route tables, endpoint associations, security groups, and attachment state during an incident.
Review the VPC as an application architecture, not a one-time setup
Network requirements change as applications adopt new services, move databases, add partners, or expand into another Region. Periodically review unused internet routes, broad security-group rules, NAT costs, orphaned endpoints, address pressure, cross-AZ traffic, and hidden dependencies on one Availability Zone.
The professional SAP-C02 view extends these choices across accounts and Regions, but the foundation remains the same: build explicit tiers, limit exposure, design redundant paths, and keep routing understandable.
A strong multi-tier VPC makes the intended communication path obvious. Users reach a managed public entry point, private application components communicate only with required dependencies, databases remain private, AWS services are reached through efficient private paths where appropriate, and the entire network can be reconstructed from controlled configuration. That clarity is what turns VPC primitives into a resilient application network.
Database subnets should be treated as a separate data tier even when the managed database service provides its own network abstraction. Keep the subnet group across multiple AZs, restrict inbound traffic to the application tier, and avoid broad routes that give database interfaces unnecessary internet reachability. A private database still needs controlled access to monitoring, backup, or management services according to the engine and architecture.
IPv6 changes the egress model. IPv6 addresses are globally routable, so private IPv4 patterns based on NAT do not translate directly. Use appropriate routing, security groups, and an egress-only internet gateway when workloads need outbound IPv6 without unsolicited inbound initiation. Test dual-stack clients because preference for AAAA records can expose paths that were never validated.
NAT architecture should consider zonal failure and data-path cost. A private subnet using a NAT gateway in another Availability Zone creates cross-AZ dependency and data transfer. For zonal NAT gateways, align private subnet routes with a NAT in the same AZ when resilience and cost justify it, or evaluate the current regional NAT gateway option for designs that benefit from automatic multi-AZ expansion.
Application-tier security groups should be based on protocol relationships, not on inherited network folklore. If the database listens on one port and only the application tier needs it, express exactly that. Avoid “allow all internal” rules that turn a compromised web server into unrestricted reachability throughout the VPC.
Shared management access should avoid public SSH or RDP wherever possible. Systems Manager Session Manager can provide administrative access to supported instances without opening inbound management ports, and interface endpoints can keep that management path private. This reduces both public exposure and dependence on bastion hosts.
Service-to-service traffic may deserve PrivateLink instead of broad network routing when one producer should expose a narrow service to multiple consumers. PrivateLink can reduce address-overlap concerns and prevent consumers from gaining general network reachability into the provider VPC. Choose the connectivity primitive that matches the relationship rather than routing every service through a common mesh.
Route-table design should be simple enough to audit. Separate public, private application, and specialized subnet routes when their egress differs, but avoid creating dozens of nearly identical tables without a reason. Infrastructure as code can enforce a standard pattern while still allowing deliberate exceptions.
Logging should include the controls that explain denied traffic. Flow Logs show accepted or rejected network flows, load-balancer access logs show requests reaching the entry tier, and application logs show protocol-level failures. Correlating these layers helps teams distinguish a network block from an unhealthy process or authorization problem.
Cost reviews should look at data movement, not only instance price. Cross-AZ calls between chatty tiers, NAT processing, inter-Region traffic, and interface-endpoint hourly charges can dominate network cost at scale. Sometimes moving a service closer to its consumers or changing the endpoint pattern improves both performance and spend.
The best multi-tier network has a small set of intentional paths and very few surprises. Public traffic enters through controlled endpoints, east-west calls follow explicit tier relationships, outbound access is minimized, AWS service traffic uses efficient private paths where appropriate, and operators can trace any connection from route to policy to application. That is the standard a VPC architecture should aim for.
Availability Zone selection should be consistent across tiers when possible. If the load balancer, application fleet, and database all span three AZs but one tier has no usable subnet in the third, recovery may concentrate traffic unexpectedly. Review subnet maps and managed-service subnet requirements together.
PrivateLink and VPC endpoints can reduce public exposure but add DNS, security-group, and endpoint-policy complexity. Standardize how endpoints are created and named so application teams do not each build a different private-access pattern. Centralization can be valuable, but measure cross-VPC routing and cost before forcing every endpoint into one shared VPC.
Network ACLs should remain coarse-grained unless a specific requirement justifies detailed rule sets. Because they are stateless and operate at subnet boundaries, complex ACLs can break return traffic and create difficult troubleshooting. Use security groups for most workload relationships and reserve ACLs for clear subnet-level controls.
When a VPC becomes too crowded with unrelated applications, consider whether account and VPC boundaries should change rather than adding more subnets indefinitely. VPC design is part of the workload isolation model. A network that is impossible to explain is often signaling that too many responsibilities share one boundary.
Web application firewalls and edge controls should be considered outside the VPC boundary as well. CloudFront, AWS WAF, and other edge services can reduce malicious or unwanted traffic before it reaches the public load balancer. The VPC remains responsible for private tier separation even when the public entry point is partly outside it.
Service discovery should be aligned with the network model. Hard-coded private IP addresses undermine Auto Scaling and failover. Use DNS names, load balancer endpoints, or service-discovery mechanisms so components can be replaced without changing callers, and make TTL choices consistent with the expected rate of endpoint change.
When workloads use containers or managed compute, remember that the VPC still supplies subnets, routes, and security relationships even if no engineer manages the underlying instance. Network architecture should be expressed in terms of application flows rather than tied too closely to one compute implementation.