Archival reconstruction notice
The original article body was not recovered. This page is a topic-matched reconstruction based on the surviving legacy URL and anchor, not a faithful historical restoration of White Knight Technology content. No claim is made that Brian Knight wrote the original or the reconstruction.
Historical context: White Knight Technology archive
An efficient Amazon Virtual Private Cloud (VPC) is not necessarily the one with the fewest components. It is the one whose address space, routes, security controls, and operating costs remain understandable as workloads change. Good VPC design makes the normal path obvious and gives every exceptional path a clear reason to exist.
Plan subnets around failure domains and workload roles
Choose a VPC CIDR block with enough room for expected growth and for connections to other networks. Avoid overlapping ranges when the VPC may later connect through peering, a transit gateway, a VPN, or another routing layer.
Create subnets per Availability Zone and role. Public subnets normally contain resources that require a route to an internet gateway, while private subnets contain application and data workloads without that direct route. A subnet is not public merely because it uses a public IP address; its route table must also provide the relevant path through an internet gateway.
Do not create more subnet tiers than the architecture needs. A consistent pattern across Availability Zones is easier to route, secure, and automate than a collection of one-off subnets. Leave address capacity for scaling, but remember that AWS reserves addresses in every subnet, so very small subnets provide less usable space than their CIDR size suggests.
Keep routing explicit
Use separate route tables when subnets need different paths. Public, private-egress, isolated, and inspection subnets should not share a route table simply for convenience. Keep routes narrow enough that an operator can tell which target handles each destination, and remove obsolete routes when a peering connection, gateway, or appliance is retired.
Centralized routing through a transit gateway or inspection VPC can simplify a multi-VPC environment, but it also introduces dependencies and data-processing costs. Use it when the operational consistency is worth that trade-off. For a small environment, a simpler topology may be easier to operate safely.
Control NAT gateway use and cost
A NAT gateway allows instances in a private subnet to initiate IPv4 connections outside the VPC without accepting unsolicited inbound connections through that gateway. It has hourly and data-processing charges, and traffic may incur other transfer charges depending on its path.
Place NAT gateways deliberately. A NAT gateway in each active Availability Zone can keep egress local to that zone and avoid making one zone's gateway a shared dependency. Fewer gateways cost less per hour, but cross-zone routing can add cost and creates a broader failure dependency. Choose the pattern from availability requirements and measured traffic rather than applying one rule everywhere.
Reduce unnecessary NAT traffic before resizing the design. Keep large transfers on private paths when possible, review which workloads truly require internet egress, and restrict outbound destinations through the appropriate controls. NAT gateways do not replace egress policy or application-level filtering.
Use VPC endpoints for private service access
VPC endpoints let workloads reach supported AWS services without sending that traffic through an internet gateway or NAT gateway. Gateway endpoints support services such as Amazon S3 and DynamoDB and are associated with route tables. Interface endpoints create private network interfaces in selected subnets and use AWS PrivateLink; they have hourly and data-processing costs.
An endpoint is efficient when it improves the private network path, reduces NAT use, or supports a security requirement. It is not automatically cheaper in every VPC. Compare endpoint charges with the NAT and transfer traffic it would replace, and use endpoint policies and security groups to limit access where supported.
Apply security groups and network ACLs for their intended jobs
Security groups are stateful controls attached to resources such as elastic network interfaces. Return traffic for an allowed connection is automatically permitted. Use security groups as the primary least-privilege control and reference other security groups where that expresses the application relationship more clearly than fixed IP ranges.
Network ACLs apply at the subnet boundary and are stateless, so inbound and outbound rules must account for both directions of a flow. They support ordered allow and deny rules. Use them for coarse subnet-level guardrails or explicit deny requirements, not as a substitute for carefully scoped security groups. Complex ACLs can be difficult to troubleshoot because they must also allow the required response and ephemeral-port traffic.
Review both controls periodically. Remove rules created for temporary migrations or testing, replace broad CIDR access with narrower sources where practical, and document any rule that must remain unusually permissive.
Make flow logs operationally useful
VPC Flow Logs can capture accepted and rejected IP traffic metadata for VPCs, subnets, or network interfaces and publish it to a supported destination. They help investigate blocked connections, unexpected egress, and traffic patterns, but they do not capture application payloads and are not a substitute for application or DNS logging.
Select the scope, fields, destination, retention, and query method before enabling logs everywhere. Logging without retention limits or a way to search the records creates cost without much operational value. Pair flow logs with metrics and alerts for NAT gateway traffic, rejected connections, route or configuration changes, and endpoint utilization where those signals matter.
Treat cleanup as part of the lifecycle
VPC efficiency declines when temporary infrastructure becomes permanent. Tag network resources with an owner, environment, purpose, and lifecycle information. Include route tables, elastic IP addresses, endpoints, NAT gateways, peering connections, transit gateway attachments, and flow-log destinations in regular reviews—not only instances.
When retiring a workload, remove dependencies in a controlled order and verify that traffic has stopped before deleting shared network paths. Release unused elastic IP addresses, delete idle endpoints and gateways, clean up stale security rules and routes, and confirm that old logs follow the required retention policy. Infrastructure as code and change review make this work repeatable and reduce configuration drift.
The practical goal is a VPC where each subnet, route, gateway, endpoint, and rule has a current workload behind it. Measure traffic and cost, keep the design consistent, and remove components once their purpose ends.