Designing Secure VPC Architectures for AWS

Most cloud network incidents do not begin with a sophisticated exploit. They begin with a permissive security group, an overlooked route table, an exposed management port, or a workload placed in the wrong subnet. Designing Secure VPC Architectures means treating the AWS network as a controlled security boundary, not simply a container for launching workloads.

For growing businesses, the goal is not to build the most complicated VPC possible. It is to create an architecture that limits blast radius, supports secure delivery, produces useful evidence during an investigation, and can evolve without interrupting operations. That requires clear decisions about segmentation, traffic paths, identity, inspection, and ownership.

Start with security boundaries, not CIDR blocks

CIDR planning matters, especially when an organization expects to connect multiple AWS accounts, offices, data centers, or acquired businesses. But address ranges are not the first architectural decision. The first question is which systems should be able to communicate, under what conditions, and who owns the approval for that communication.

A secure VPC separates workloads based on risk and function. Production should not share unrestricted network paths with development. Internet-facing services should not sit beside databases. Highly regulated workloads may need a dedicated account and VPC, with narrowly governed connections to shared services.

AWS accounts are often the strongest initial isolation boundary. They separate IAM policies, billing, logging, service quotas, and operational ownership. Within each account, VPCs and subnets provide more granular segmentation. For many small and mid-sized organizations, a practical model is separate accounts for production, nonproduction, security and logging, and shared infrastructure. This model creates meaningful boundaries without introducing an unmanageable number of network domains.

Avoid creating VPCs for every application by default. That can complicate DNS, routing, observability, and incident response. A dedicated VPC makes sense when an application has materially different compliance requirements, trust boundaries, connectivity needs, or operational ownership. Otherwise, carefully segmented shared VPCs may be easier to operate.

Build a VPC layout around intentional traffic flows

A subnet is not public because its name says public. It is public only when its route table provides a path to an internet gateway. That distinction matters because routing, not labels, determines exposure.

A common AWS pattern uses public subnets for internet-facing load balancers and private subnets for application workloads. Data stores belong in isolated subnets with no default route to the internet. Application instances can reach approved external services through a NAT gateway when needed, but inbound internet traffic should terminate at a controlled entry point such as an Application Load Balancer, API Gateway, CloudFront, or a managed edge service.

This layout should span at least two Availability Zones for critical systems. High availability is not merely an uptime feature. It also reduces the pressure to make emergency network changes during an Availability Zone event, when rushed changes can introduce security gaps.

For organizations with several VPCs, AWS Transit Gateway can centralize connectivity. It reduces the operational burden of many individual peering connections and supports consistent route-domain design. However, central connectivity does not automatically create security. Route tables on the Transit Gateway and in each attached VPC must explicitly restrict which networks can communicate. A hub-and-spoke model with unrestricted east-west routes simply moves a flat network into the cloud.

Private connectivity should be the default for AWS service access where feasible. VPC endpoints can keep traffic to services such as Amazon S3, Systems Manager, Secrets Manager, and ECR off the public internet. Interface endpoints add cost, so evaluate them against traffic volume, regulatory expectations, and the sensitivity of the service. Gateway endpoints for S3 and DynamoDB are often a straightforward security and cost improvement.

Apply layered controls for Designing Secure VPC Architectures

Security groups are the primary stateful firewall control for most AWS workloads. They should be attached according to application role, not broad IP convenience. For example, an application security group can allow inbound HTTPS only from a load balancer security group, while a database security group allows its database port only from the application security group.

This security-group-to-security-group approach is more durable than allowing a large private CIDR range. It remains valid when instances scale, addresses change, or a new subnet is added. It also expresses the intended dependency in a way reviewers can understand.

Network ACLs serve a different purpose. They are stateless, subnet-level controls and require explicit rules for return traffic. They are useful for coarse guardrails, known malicious ranges, or cases where a subnet-wide deny control is needed. They are rarely the best tool for managing application-level access. Overly detailed NACL rules can become brittle and make outages harder to diagnose.

A disciplined architecture layers several controls rather than expecting one control to handle every risk:

• Security groups enforce least-privilege traffic between services.
• Route tables prevent unintended paths between network segments.
• IAM controls who can change infrastructure and access cloud services.
• AWS Network Firewall, third-party firewalls, or secure web gateways inspect traffic where policy requires it.
• AWS WAF protects public web applications from common application-layer threats.
• Logging services create an audit trail for detection and investigation.

The appropriate inspection model depends on the environment. Centralized egress inspection can provide consistent policy enforcement and visibility, particularly for regulated workloads or large multi-account estates. It also adds cost, routing complexity, and potential throughput considerations. Smaller environments may begin with strict security groups, VPC endpoints, managed WAF, and focused egress controls, then add centralized inspection as risk and scale justify it.

Treat administrative access as a high-risk traffic path

Direct SSH and RDP access from the internet should be the exception, not the operating model. Even when restricted to corporate IP addresses, public management ports create unnecessary exposure and depend on source addresses that may change.

AWS Systems Manager Session Manager provides a stronger pattern for many environments. It supports access without inbound management ports, can enforce IAM-based authorization, and can log session activity. Where bastion hosts remain necessary, place them in a tightly controlled management subnet, require multi-factor authentication, restrict access by identity and source, and monitor every connection.

Administrative access also includes access to managed databases, Kubernetes control planes, CI/CD runners, and SaaS integration endpoints. Review these paths with the same rigor used for server access. A database placed in a private subnet is still at risk if a broad security group permits connections from every workload in the VPC.

Make visibility part of the architecture

A VPC without telemetry is difficult to secure because teams cannot distinguish intended traffic from accidental exposure. Enable VPC Flow Logs for production VPCs and key subnets, then retain them in a centralized logging account with access controls appropriate for security investigations. Flow logs will not show packet payloads, but they are valuable for identifying accepted and rejected connections, unexpected ports, and suspicious source patterns.

Pair flow logs with CloudTrail, AWS Config, GuardDuty, Security Hub, load balancer logs, DNS query logs where appropriate, and application observability. The point is not to turn on every log source without a plan. The point is to answer operational questions quickly: Which identity changed this security group? Did the instance connect externally? Which route made the path possible? Is the application rejecting traffic, or is the network blocking it?

Infrastructure as code is central to this discipline. Terraform, CloudFormation, or comparable tooling makes route tables, security groups, endpoints, and logging configurations reviewable and repeatable. CI/CD checks can flag 0.0.0.0/0 access to sensitive ports, missing flow logs, public IP assignments, or noncompliant route changes before deployment. Periodic Well-Architected Reviews then validate that the deployed environment still matches the intended design.

Secure VPC architecture questions leaders ask

Should every workload be in a private subnet?

Not necessarily. Internet-facing load balancers and certain managed services may require public subnet placement. The more useful rule is that application servers, worker nodes, databases, and internal services should not require direct inbound internet access. Public entry points should be few, intentional, protected by TLS and WAF where applicable, and monitored.

Is a NAT gateway a security control?

A NAT gateway allows private-subnet workloads to initiate outbound connections without accepting unsolicited inbound internet traffic. That is helpful, but it is not egress filtering. By itself, it does not decide which domains, IP addresses, ports, or destinations workloads can reach. Use route design, firewall policies, proxy controls, endpoint policies, and DNS controls when outbound restrictions matter.

Should production and development use separate VPCs?

They should at least use separate accounts and clearly separated network controls. Separate VPCs are advisable when production must be protected from developer experimentation, when compliance requires stronger isolation, or when environments have different connectivity patterns. For smaller teams, account separation combined with disciplined subnetting may be sufficient initially, provided permissions and routes do not create accidental cross-environment access.

How often should VPC rules be reviewed?

Review them continuously through infrastructure-as-code pull requests and automated policy checks, then conduct a broader review at least quarterly and after major changes. Trigger an immediate review after an incident, a merger, a new third-party integration, or a change to regulatory requirements. Stale rules are common because temporary exceptions often outlive the work that justified them.

What is the most common design mistake?

The most common mistake is allowing broad east-west access because all workloads are considered internal. Internal is not a security classification. Assume a compromised workload could attempt lateral movement, and restrict every dependency to the ports, protocols, and identities it actually needs.

A secure VPC should make the safe path the easy path for engineering teams. When network patterns are documented, deployed through automation, observable in operation, and reviewed as the business changes, security becomes a repeatable operating capability rather than an emergency project.

Author: Yavor Y. Zlatev CEO of AdvisionIT
Date: 18.08.2026