AWS VPC Networking Design Notes
AWS VPC networking becomes easier when each component is treated as a specific control point: interfaces attach compute, route tables choose paths, endpoints avoid public internet, and flow logs explain traffic.
The practical skill is not memorizing service names. It is knowing which control point to inspect when the diagram and the behavior disagree.
Elastic Network Interfaces
An ENI is a virtual network card inside a VPC. It can have a primary private IPv4 address, secondary private IPv4 addresses, security groups, a MAC address, and optional public addressing.
Important constraints:
- An ENI belongs to one availability zone.
- An ENI attaches to one EC2 instance at a time.
- The primary ENI cannot be detached from a running instance.
- Instance type controls ENI and IP address limits.
ENIs are useful for dual-homed instances and hot-standby patterns where a network identity must move quickly.
That is why ENIs show up in designs that need failover identity, not just more IP addresses.
NAT
Private subnet instances need a path to the internet for updates and outbound calls. NAT provides that path without allowing inbound internet connections to the instances.
NAT instances are EC2-based and require security group, route table, and source/destination check configuration. NAT Gateways are managed, scalable, and simpler, but cost more.
In practice, the reason NAT Gateways win is not elegance. It is that teams stop owning the failure modes of a custom middlebox.
VPC Peering
VPC peering connects two VPCs over AWS private networking. It is simple and useful for small topologies.
The key limitation is non-transitivity. If VPC A peers with B and B peers with C, A does not automatically reach C. For larger networks, use Transit Gateway.
Also remember CIDR overlap. Peering cannot fix overlapping address plans.
VPC Endpoints
Endpoints let private resources access AWS services without using an internet gateway or NAT gateway.
Interface endpoints use PrivateLink and create ENIs with private IP addresses. They support many AWS services and can be controlled with security groups.
Gateway endpoints are route table targets and are free, but only support S3 and DynamoDB.
That "only" is easy to forget and operationally important. For private subnet access to DynamoDB or S3, the default answer should be gateway endpoints, not interface endpoints.
Flow Logs
VPC Flow Logs can be enabled at VPC, subnet, or ENI level. They do not capture packet payloads, but they are excellent for answering:
- Who is talking to whom?
- Which traffic is accepted or rejected?
- Which IPs are producing the most traffic?
- Which route or security rule might be wrong?
Common paths include CloudWatch Logs with metric filters, S3 with Athena, or dashboards through QuickSight.
One debugging rule is worth memorizing: CloudTrail tells you who called an AWS API. Flow Logs tell you how network traffic moved. Mixing them up wastes a lot of time.
Design Rule
Keep the network boring. Use endpoints for AWS service access, NAT for required outbound internet, Transit Gateway for hub-and-spoke scale, and flow logs for evidence when the diagram disagrees with reality.