AWS VPC Best Practices for Secure and Scalable Infrastructure

#arclogiq

Most AWS environments have a VPC that technically works and hasn't actually been revisited since it was first set up, often by whoever was standing there when the account was created. That's fine at small scale. It becomes a genuine liability once real workloads, real compliance requirements, and real growth start depending on decisions that were never meant to carry that much weight.

My position: VPC design mistakes are among the most expensive to unwind in AWS specifically, because so much else gets built on top of the initial network layout. Getting the foundational decisions right early is disproportionately valuable compared to almost any other AWS architecture decision.

CIDR Block Sizing: Bigger Than You Think You Need

The single most common regret in AWS VPC design is a CIDR range sized for current needs that runs out of room within a couple of years. Since VPC CIDR blocks are genuinely difficult to resize after subnets and resources are already deployed within them, allocate generously from the start a /16 for a VPC that might only need a /20 today costs nothing extra and saves a painful future migration.

Use Multiple Availability Zones Deliberately, Not Just Nominally

Subnets should be genuinely distributed across multiple AZs, and critically, actual resources need to be deployed across those subnets in a way that provides real redundancy — not just technically available multi-AZ subnets sitting mostly empty while everything actually runs in one zone. Verify this directly rather than assuming multi-AZ subnet creation alone constitutes multi-AZ resilience.

Security Groups vs. Network ACLs: Use Both, Understand the Difference

Security groups are stateful and instance-level; NACLs are stateless and subnet-level. A lot of AWS environments rely purely on security groups and never seriously use NACLs, missing a genuine additional layer of defense. NACLs are particularly useful for explicit deny rules at the subnet level blocking known-bad ranges broadly, for instance in a way that complements rather than duplicates security group logic.

VPC Endpoints Reduce Both Cost and Exposure

Traffic to AWS services like S3 or DynamoDB doesn't need to route through a NAT Gateway or the public internet if VPC endpoints are properly configured. This reduces NAT Gateway data processing costs meaningfully and keeps that traffic off the public internet entirely, which is both a cost optimization and a genuine security improvement, and it's consistently underused because NAT Gateway routing works "well enough" without anyone specifically optimizing it.

Flow Logs Should Be Enabled by Default, Not Added Reactively

VPC Flow Logs provide genuine visibility into traffic patterns and are frequently only enabled after an incident makes their absence painfully obvious. Enable them from the start, at the VPC level, and route them to a genuinely reviewed destination not just enabled and left uncollected in a log group nobody's watching.

Multi-Account VPC Strategy Matters at Real Scale

For organizations running multiple AWS accounts, deciding how VPCs relate across accounts shared VPC via Resource Access Manager, or separate VPCs connected via Transit Gateway deserves deliberate architecture rather than an ad hoc pattern that emerged as accounts were added one at a time without an overarching plan.

What This Actually Requires

Generous CIDR allocation from day one, avoiding a painful future resize

Genuine, verified multi-AZ resource distribution, not just multi-AZ subnet availability

Both security groups and NACLs used deliberately, not relying on one layer alone

VPC endpoints configured for AWS service traffic, reducing both cost and public internet exposure

Flow logs enabled by default and genuinely reviewed, not added reactively after an incident

A deliberate multi-account VPC strategy, not an emergent pattern from adding accounts individually over time

The Actual Point

VPC design decisions are foundational in a way that's easy to underestimate when the account is new and the stakes feel low. Getting the CIDR sizing, AZ distribution, and account strategy right early saves a considerably more painful and disruptive correction once real workloads depend on the structure already in place.