AWS Unpacked #3: VPC & Networking

Understanding the Basics of VPC Networking

What is a VPC?

A Virtual Private Cloud (VPC) is your isolated corner of AWS where you define your own IP address range, subnets, route tables, and gateways. Think of it as your own mini data center in the cloud.

CIDR Basics

• CIDR (Classless Inter-Domain Routing) defines IP ranges like 10.0.0.0/16.
• You can divide these ranges into smaller subnets (e.g., 10.0.1.0/24).
• It helps you organize and isolate workloads.
• The format is <base IP address>/<prefix length>.
• The prefix length (e.g., /16, /24) tells you how many bits are fixed. To calculate the size of a CIDR block given its prefix, you subtract the prefix length from 32 (for IPv4) to find how many host bits are available, then raise 2 to the power of that number. Here’s a quick breakdown:
  • The formula is: 2^(32 - prefix length)
  • For example:
    • /24 → 2^(32 - 24) = 2^8 = 256 IP addresses
    • /16 → 2^(32 - 16) = 2^16 = 65,536 IP addresses
    • /20 → 2^12 = 4,096 IP addresses
    • Prefix length: /22 means 22 bits are fixed, so 32 - 22 = 10 bits are left for hosts.
    • Block size: 2^10 = 1,024 IP addresses.
    • Fixed part: The first 22 bits (10.0.4.0 in binary) stay constant for all IPs in this block.
    • Starting address: 10.0.4.0 — this is the first usable IP in the block.
    • Range covered: From 10.0.4.0 to 10.0.7.255

    🧠 Rule of thumb: The IP address in a CIDR block must be the starting address of the range (i.e., evenly divisible by the block size). If it isn’t, the CIDR is invalid.

Public vs Private IPs

• Public IPs: Reachable over the internet. Automatically assigned to instances in public subnets.
• Private IPs: Only work inside the VPC.
• There are three main private IP address ranges commonly used:
  • 10.0.0.0 – 10.255.255.255 (10/8): This is a large private range often used by AWS and large organizations for big networks.
  • 172.16.0.0 – 172.31.255.255 (172.16/12): Another private range used by AWS for VPC subnets.
  • 192.168.0.0 – 192.168.255.255 (192.168/16): The most common private range used for home and small office networks.
• AWS also provides Elastic IPs (static public IPs).

Key VPC Components

Default VPC

• Created automatically in each region.
• Comes with public subnets, route table, internet gateway, and NAT capabilities.
• Great for quick-starts, but production environments typically use custom VPCs.

Custom VPC

While the default VPC is great for getting started, custom VPCs give you full control over your networking environment — crucial for production-grade architectures. You define the IP range, subnets, route tables, and gateways to suit your app’s specific needs.

Key points:

• IPv4 CIDR Blocks: A VPC must have a primary IPv4 CIDR block. It can range from /16 (65,536 IPs) to /28 (16 IPs). You can add up to five secondary CIDR blocks if you need more IP space (as long as they don’t overlap).
• Hard limits: You can’t expand a primary CIDR block — plan sizing carefully!
• IPv6 Support: You can optionally assign an Amazon-provided IPv6 block (/56) for globally unique, internet-routable addresses.
• Subnet Design: Subnets must not span AZs and must fit within your VPC’s CIDR block. You can’t have a subnet larger than your VPC.

Subnets

Subnets are subranges of IPv4 addresses within a VPC. AWS reserves 5 IP addresses (first 4 and last 1) in each subnet - these are not available for use and can’t be assigned to an EC2. For example, if CIDR block is 10.0.00/24:

• 10.0.0.0 - Network Address
• 10.0.0.1 - reserved by AWS for the VPC router
• 10.0.0.2 - reserved by AWS for mapping to Amazon-provided DNS
• 10.0.0.3 - reserved by AWS for future use
• 10.0.0.255 - Network Broadcast Address (AWS does not support broadcast in a VPC, therefore this address is reserved)
• Public Subnet: Has a route to the internet via an Internet Gateway.
• Private Subnet: No direct route to the internet.

Route Tables

Route Tables are critical components that determine how traffic flows within a VPC and to/from the internet. Each subnet in your VPC must be explicitly associated with one (and only one) route table — if you don’t assign one manually, the subnet uses the main route table for the VPC by default. A route table consists of a set of rules (routes), and each rule specifies:

• Destination: an IP range (e.g. 0.0.0.0/0 for “anywhere”)
• Target: where to send traffic destined for that IP range (e.g., Internet Gateway, NAT Gateway, local, etc.)

There’s always a default “local” route in every route table that allows communication within the VPC.

Every route table in a VPC — including the main route table and any custom ones you create — will always include this default route entry:

Destination: 10.0.0.0/16 (or whatever your VPC CIDR is) Target: local

This local route enables communication between subnets in the same VPC. It is automatically added and cannot be removed or modified. This is what allows EC2 instances in different subnets (but the same VPC) to ping, SSH, or otherwise talk to each other — even across AZs.

Public vs Private Subnet Routing

The main difference between a public and a private subnet comes down to what’s in the route table:

• Public Subnet Route Table
  • Contains a route to the Internet Gateway (IGW) for 0.0.0.0/0
  • This route allows resources (like EC2 instances) to send/receive traffic from the internet if they also have a public IP or Elastic IP
  • Example route: Destination: 0.0.0.0/0 → Target: igw-abc123
• Private Subnet Route Table
  • Does not have a route to the IGW.
  • Instead, if internet access is needed, it will have a route to a NAT Gateway or NAT Instance in a public subnet.
  • Example route:Destination: 0.0.0.0/0 → Target: nat-gw-xyz456

Internet Gateway (IGW)

• Enables access to and from the internet.
• Must be attached to the VPC.

Creating a Public Subnet

To make a subnet “public” in AWS — meaning it can send and receive traffic from the internet — you need more than just assigning it a CIDR range. Here’s what makes a subnet truly public:

1. Attach an Internet Gateway (IGW) to the VPC
   • The IGW allows internet traffic in and out of the VPC.
   • It must be explicitly attached to the VPC that contains your subnet.
2. Route Table with a Default Route (0.0.0.0/0) to the IGW
   • Create or modify a route table to include a route like 0.0.0.0/0 → igw-xxxxxxx.
   • This tells the subnet to send internet-bound traffic through the IGW.
3. Associate the Route Table with the Subnet
   • A route table doesn’t automatically apply to new subnets.
   • You must explicitly associate the route table to the subnet you want to make public.
4. Assign Public IPs to Instances
   • Instances in a public subnet must have either:
     • An auto-assigned public IP, or
     • An Elastic IP (EIP).
   • Otherwise, even with a public route, they won’t be reachable from the internet.

High-level tip: A subnet is only “public” if both the route table has a route to the IGW and it’s associated with the subnet. Without both, it’s effectively private.

Controlling Inbound & Outbound Access

NAT Instances and NAT Gateways

NAT (Network Address Translation) allows instances in a private subnet to initiate outbound connections to the internet (like downloading packages or updates) without exposing themselves to inbound traffic from the internet. This is crucial when you want secure instances (e.g., app servers, DBs) to fetch updates or send logs without being directly reachable from the outside world. NAT modifies the source IP address of outbound traffic from private IPs to a public IP, so the return traffic can flow back through the same device. In AWS, NAT can be done via a NAT Instance (self-managed EC2 instance) or a NAT Gateway (AWS-managed service).

To set up a NAT Instance:

1. Launch an EC2 instance in a public subnet.
2. Assign it a public IP.
3. Disable source/destination checks (so it can route traffic).
4. Update the route table for your private subnet to send all internet-bound traffic (0.0.0.0/0) to the NAT instance.
5. Add proper Security Group rules to allow traffic.

To set up a NAT Gateway:

1. Create a NAT Gateway in a public subnet.
2. Attach an Elastic IP.
3. Update the route table of your private subnet to route internet-bound traffic (0.0.0.0/0) to the NAT Gateway.
4. That’s it — no maintenance required.
5. In order to be highly available, you need to set up a NAT gateways in more than one AZ.

NAT Instances and Gateways compared:

Bastion Hosts

• A Bastion Host (also called a jump box) is a securely exposed EC2 instance placed in a public subnet, acting as a controlled entry point to your private network.
• It’s used to SSH into instances in private subnets that don’t have public IPs — without opening those instances directly to the internet.
• To use it:
  • You connect via SSH to the bastion using its public IP (via port 22).
  • From there, you SSH into private instances using their private IPs.
• It’s a common security pattern to minimize exposure: only the bastion is internet-facing, while all internal servers remain private.
• Best practice is to restrict SSH access to trusted IPs (e.g., your office IP) using Security Groups and consider using Session Manager (from AWS Systems Manager) for even tighter control.

Security Groups vs Network ACLs

When it comes to controlling traffic in and out of your AWS environment, Security Groups (SGs) and Network ACLs (NACLs) are your two main tools — each with different scopes, behaviors, and use cases.

Security Groups

• Stateful: If you allow inbound traffic, the response is automatically allowed out (and vice versa).
• Applied at the EC2 instance level — you attach SGs directly to ENIs (Elastic Network Interfaces).
• Only allow rules — you explicitly define what is permitted, not what is blocked.
• Easy to manage and the primary mechanism for most use cases.
• Example use cases: Web server that accepts HTTP (port 80) and SSH (port 22) traffic, database server that only allows access from a specific app server SG.

Network ACLs (NACLs)

• Stateless: Both inbound and outbound rules must be explicitly defined. Return traffic is not automatically allowed.
• Applied at the subnet level — affect all resources in the subnet.
• Support both allow and deny rules, giving more granular control.
• Rules are evaluated in order, from lowest to highest rule number (for eg. rule 100 is given priority over rule 200)
• Use cases: Block specific IP addresses or ranges at the subnet level (e.g., for geo-blocking); provide an extra layer of protection in high-security environments; quickly lock down an entire subnet in case of incident response.

Ephemeral Ports – Why They Matter

When a client (like your browser or an EC2 instance) initiates a connection to a server (like a web server), it uses a random high-numbered port — known as an ephemeral port — for the response.

• These ports typically range from 1024 to 65535.
• For example: if you allow outbound HTTP (port 80), the response from the server will come back to the client’s ephemeral port.
• With Security Groups, you don’t need to worry about this — return traffic is handled automatically.
• With NACLs, you must explicitly allow inbound traffic on the ephemeral port range (e.g., TCP 1024–65535), or responses will be blocked.

SGs vs NACLs – Summary Table

Use Cases

Connecting VPCs and External Networks

VPC Peering

• Direct, one-to-one (private) network connection between two VPCs (using AWS network) - letting them behave as if they were in the same network. Connection can be between VPCs in different accounts or regions.
• Must update route tables in both VPCs.
• Must not have overlapping CIDRs
• No transitive peering (VPC A can’t route through VPC B to VPC C).
• Use cases:
  • Multi-account architecture: You separate workloads by account (e.g., dev, test, prod) and want secure communication between VPCs.
  • Shared services model: Centralize logging, monitoring, or authentication in one VPC and let other VPCs access it privately.
  • Hybrid environments: Extend a legacy VPC setup by peering with newer VPCs, without tearing everything down.
  • Inter-region low-latency: Connect VPCs across regions for apps that span geographies and need fast internal communication.

VPC Endpoints

A VPC Endpoint enables you to privately connect your VPC to supported AWS services without requiring access over the public internet or through a NAT Gateway or VPN. This keeps your traffic inside the AWS private network, improving both security and latency. VPC Endpoints are powered by AWS PrivateLink, they’re redundant and scale horizontally. It removes the need for IGW and NATGW.

There are two main types of VPC Endpoints:

1. Interface Endpoints (powered by PrivateLink)

• Powered by Elastic Network Interfaces (ENIs).
• Appear as private IPs within your subnet.
• You communicate with the service via private DNS — e.g., calling s3.amazonaws.com will automatically route to the private interface.
• Cost per hour and per GB of data processed
• Used for most AWS services like:
  • SSM (Systems Manager)
  • CloudWatch
  • Secrets Manager
  • API Gateway
  • SageMaker
  • ECS, etc.

1. Gateway Endpoints

• Specific to S3 and DynamoDB.
• They don’t use ENIs — instead, they work by providing a gateway and updating your route tables to direct traffic to the AWS service via the endpoint.
• Much simpler and cheaper than interface endpoints.

Use Cases for VPC Endpoints

• Security-sensitive workloads: You don’t want data going over the internet. For example, an app in a private subnet accessing Secrets Manager using a private route.
• Cost reduction: Avoid paying for NAT Gateways or bandwidth charges when accessing AWS services like S3.
• Compliance: Helps meet requirements where data cannot traverse public networks.
• Faster access: Lower latency when traffic doesn’t exit the AWS network.

VPC Flow Logs

VPC Flow Logs let you capture information about the IP traffic going to and from network interfaces in your VPC.

You can see:

• Source and destination IP addresses
• Ports and protocols
• Traffic accept/deny status
• Bytes transferred
• Timestamps

This data helps with:

• Debugging connectivity issues
• Monitoring network usage
• Identifying potential security threats

You can export flow logs to Amazon S3, CloudWatch Logs & Kinesis Data Firehose. If you send VPC Flow Logs to S3, you can query them using Amazon Athena, which is a serverless, SQL-based query engine. Here’s the workflow:

1. Enable VPC Flow Logs and send logs to an S3 bucket.
2. Create a Glue Data Catalog table that maps to your log format.
3. Use Athena to write SQL queries over the logs.

This lets you do things like:

• Find the top talkers in your VPC
• Search for unauthorized traffic attempts
• Track traffic volume by subnet or service
• Audit which ENIs are accessing S3 and how much data they’re moving

Site-to-Site VPN

A Site-to-Site VPN enables encrypted communication between your AWS VPC and your on-premises network over the public internet using the IPSec protocol. This is ideal for hybrid cloud setups where some workloads remain on-prem while others are hosted in AWS.

Benefits:

• Secure communication using industry-standard encryption.
• No need for leased lines like Direct Connect—good for cost-conscious use cases.
• Quick to set up, compared to physical connections.
• Scalable and redundant when configured with multiple tunnels.

Common Use Cases:

• Hybrid cloud architectures.
• Gradual cloud migration while keeping legacy systems on-prem.
• Connecting branch offices or regional sites to a central AWS network.

How To?

To establish a Site-to-Site VPN, you need components on both ends:

On the AWS Side:

• Virtual Private Gateway (VGW): A VPN concentrator on the AWS side. It’s attached to your VPC and serves as the anchor for the VPN connection.
• VPN Connection: A configuration that ties together the VGW and your on-premises Customer Gateway.
• Routing: Typically done via route tables in the VPC.

On the Customer Side:

• Customer Gateway (CGW): Represents your on-premises device (e.g. firewall, router) that supports IPSec VPN. You’ll configure this device to connect to the AWS-provided IP endpoints.

  • A public IP address is required for the CGW (static, not dynamic).
  • If your CGW is behind a NAT, you need to use NAT-Traversal (NAT-T), which allows IPSec to work over UDP 4500. But AWS recommends that your CGW have a public IP directly on the device if possible for better stability and simplicity.

Once the VPN connection is established, you can enable route propagation in your VPC’s route table. This means routes advertised from the VGW (typically the CIDR block of your on-prem network) will be automatically added to the route table. This saves manual work and ensures dynamic updates if you’re using BGP on the customer side. If you’re not using BGP, you can configure static routes on both ends.

When setting up and troubleshooting Site-to-Site VPNs, ICMP (e.g. ping) can be very helpful. It allows basic connectivity testing between hosts. By default, security groups and network ACLs in AWS block ICMP, so you’ll need to explicitly allow it for testing. Many VPN devices also use ICMP to detect tunnel health. So even if your IPSec tunnel is “up,” make sure ICMP is allowed through the firewall or security group if you want to test connectivity using ping.

AWS VPN CloudHub: Multi-Site Connectivity

If you have multiple remote networks (e.g. multiple branch offices) that need to talk to each other via AWS, AWS VPN CloudHub might be your friend. This is an extension of Site-to-Site VPN that allows multiple CGWs (from different remote sites) to connect to the same VGW. The VGW acts as a hub, and remote sites can communicate with each other via AWS.

Say you have branches in Cape Town, Joburg, and London. Instead of setting up direct VPNs between each branch, they all connect to AWS and use CloudHub to route traffic between each other through the VGW. Requirements for this setup:

• Each CGW must use BGP.
• Each site must have unique ASN and non-overlapping CIDR blocks.

Direct Connect & Direct Connect Gateway

• AWS Direct Connect (DX) provides a dedicated private network connection between your on-premises network and AWS. You can access both private (EC2) and public (S3) resources on the same connection.
• Direct Connect Gateway (DXGW) allows one DX connection to link to multiple VPCs across regions and accounts.

Prerequisites:

• You need either:
  • A Dedicated Connection provisioned through the AWS Console (takes longer, requires AWS approval).
  • A Hosted Connection provisioned via an AWS Direct Connect Partner (faster, easier to get started).

Steps to Set Up:

1. Order the connection:
   • Dedicated: Request 1 Gbps or 10 Gbps via AWS Console → AWS reviews & approves → You receive LOA-CFA (Letter of Authorization & Connecting Facility Assignment).
   • Hosted: Partner provisions 50 Mbps to 10 Gbps port for you — you don’t deal with LOA.
2. Physically connect:
   • You (or your partner) must install cross-connects at the Direct Connect location (colocation center).
3. Set up Virtual Interfaces (VIFs):
   • Private VIF: Connects to VPCs via Virtual Private Gateway or Transit Gateway.
   • Public VIF: Connects to AWS public services (e.g., S3, DynamoDB) without using the internet.
4. Set up BGP (Border Gateway Protocol):
   • Needed for routing between your on-premises and AWS.
   • BGP handles failover and redundancy automatically when configured with multiple connections.
5. Link to your VPC:
   • Via Virtual Private Gateway (VGW) for basic setups.
   • Or via Transit Gateway (TGW) for large/multi-VPC/multi-region setups.

Encryption & Security

DX does not encrypt traffic by default. If encryption is required, use Direct Connect + VPN:

• Set up a Site-to-Site VPN over the Direct Connect link.
• This adds IPsec encryption on top of the private connection.
• Alternatively, use TLS at the application layer for encryption.

Resiliency: High Availability Options

For Critical Workloads:

• Use two DX connections in one AWS region, in two separate DX locations (if possible).
• Each connection should have redundant virtual interfaces and be terminated in different routers.
• Combine with VPN failover:
  • Set up a backup Site-to-Site VPN over the internet.
  • BGP routes handle failover automatically.

For Maximum Resiliency (Across Regions):

• Use two Direct Connect connections in different AWS regions and locations.
  • Each connects to its own Direct Connect Gateway, which links to multiple regional VPCs.
• Add VPN connections to both regions as additional backup paths.
• Use BGP routing policies and route priorities to failover gracefully.

Transit Gateway (TGW)

• AWS Transit Gateway (TGW) acts as a central hub to interconnect multiple VPCs, VPNs, and Direct Connect gateways at scale.
• It simplifies large, complex network topologies by replacing full-mesh peering with a hub-and-spoke model.
• Supports transitive routing: traffic can flow through the TGW from one VPC to another or to on-prem.
• TGWs are regional, meaning:
  • All attached VPCs must be in the same region.
  • You can peer TGWs across regions (inter-region peering) for global connectivity.
  • Inter-region traffic via TGW peering is encrypted and stays on the AWS backbone (not public internet).

Key Use Cases

• Enterprise hub-and-spoke architectures with many VPCs.
• Hybrid environments with multiple on-premises data centers.
• Multi-account network architectures using AWS Organizations + Resource Access Manager (RAM).
• Cross-VPC access for shared services (e.g. centralized logging, monitoring, or authentication).
• Network segmentation (e.g. dev/stage/prod isolation but shared access to common infra).
• Multicast applications like real-time data distribution (financial services, media, etc.).

Resource Access Manager (RAM)

• AWS RAM allows you to share TGWs across accounts within your organization.
• The owning account creates the TGW and shares it via RAM.
• Other accounts can attach their VPCs or VPNs to the TGW without managing it directly.
• Ideal for centralized network teams in multi-account orgs.

Integration with VPN & Direct Connect

Direct Connect Gateway (DXGW) + TGW

• TGW cannot connect directly to a Direct Connect physical connection.
• Use a Direct Connect Gateway to bridge DX and TGW.
• This allows on-prem → DXGW → TGW → VPCs (even across accounts and regions).
• Enables single DX to multiple VPCs via centralized routing.

Multicast with TGW

• TGW supports IP Multicast within AWS.
• Useful for applications like:
  • Market data feeds in financial services.
  • Live video streaming, telemetry, etc.
• Only supported in the same region and across Elastic Network Interfaces (ENIs).
• You need to create multicast domains and associate ENIs to it.

Equal Cost Multi-Path Routing (ECMP)

ECMP, or Equal-Cost Multi-Path, is a routing technique that allows AWS to distribute traffic across multiple paths that have the same routing cost (i.e., same prefix and same weight). This enables load balancing and failover across multiple connections such as:

• VPN tunnels (using AWS Site-to-Site VPN),
• Transit Gateway (TGW) peerings, or
• Direct Connect connections (when used with TGW).

ECMP enables:

• Increased bandwidth: AWS can send traffic over multiple active tunnels or peerings in parallel, effectively aggregating bandwidth.
• High availability: If one path fails, traffic automatically shifts to the others.
• Better throughput: Traffic distribution improves utilization across links.

To actually benefit from ECMP:

1. Establish multiple VPN tunnels or peerings:
   • For VPN: Create multiple Site-to-Site VPN connections, ideally using multiple customer gateway devices at your on-premises location.
   • For TGW peering: Set up multiple peering attachments between TGWs in different regions.
2. Ensure routes have equal cost:
   • In your route tables (e.g., on the Transit Gateway), advertise the same prefix over each tunnel/peering.
   • AWS will recognize these as equal-cost routes and distribute traffic across them.
3. Distribute outbound traffic from your side:
   • On-prem routers/firewalls must also be ECMP-aware and capable of sending traffic across multiple tunnels.
   • AWS distributes inbound traffic using ECMP, but you need to match this on your side to fully utilize bandwidth.

VPN: TGW vs VGW

Sharing Direct Connect Across Accounts

You can share a DX connection with multiple accounts via Direct Connect Gateway + TGW:

1. Account A owns the DX connection and DXGW.
2. DXGW is attached to TGW (owned by same or different account).
3. Other accounts share VPCs with the TGW using RAM.

This gives centralized control, but distributed access — common in enterprise environments.

VPC Monitoring and Advanced Features

VPC Traffic Mirroring

VPC Traffic Mirroring lets you capture and inspect network traffic from Elastic Network Interfaces (ENIs) in your VPC — in near real time — by creating a copy of the traffic and sending it to an analysis destination. It works similarly to port mirroring (SPAN) in traditional networks and is supported on Nitro-based EC2 instances (majority of current gen instances). The mirrored traffic uses VPC infrastructure — no need to send anything over the public internet.

Why do I need it?

• Helps you monitor, analyze, and troubleshoot network traffic inside your AWS environment.
• You get packet-level visibility — deeper than flow logs or metrics.
• Ideal for:
  • Security investigations
  • Intrusion detection systems (IDS)
  • Performance analysis
  • Application debugging
  • Compliance monitoring

What can I capture?

• You mirror traffic from a source ENI, which is tied to an EC2 instance, a load balancer or a NAT gateway
• You can capture Inbound, outbound, or both traffic directions and filtered traffic using capture filters (protocol, port, IP range, etc.). Example: Mirror only TCP port 443 outbound traffic from a given ENI.
• You can mirror multiple ENIs — either in the same VPC or across different VPCs, provided:
  • They are in the same region.
  • You have VPC peering, Transit Gateway, or shared services architecture in place if you’re doing cross-VPC captures.
• All mirrored traffic must be routed to a single destination ENI (typically a monitoring appliance or collector EC2 instance).

Notes and limitations

• Only available on Nitro-based instances (T3, M5, C5, etc.).
• You can’t mirror traffic to/from AWS-managed services like S3 or DynamoDB.
• You are charged for the mirrored traffic — same as standard VPC data transfer within a region.
• Mirror targets should be tuned to handle incoming mirrored traffic volume (high-volume mirroring can overwhelm).

IPv6 and Egress-Only Internet Gateway

• IPv6 addresses are globally unique and internet-routable by default — unlike IPv4 where you often use private ranges (like 10.0.0.0/16) and rely on NAT for internet access.
• This means: no NAT, no private IPv6, and therefore outbound traffic could be reachable unless explicitly controlled.

Why Use an Egress-Only Internet Gateway (EOIGW)?

Egress-Only Internet Gateway is the IPv6 equivalent of a NAT Gateway — but with a key difference:

EOIGW allows instances in a private subnet with IPv6 addresses to initiate outbound connections to the internet, while preventing unsolicited inbound connections — critical for maintaining security.

Where Does the Internet Gateway Fit In?

• The standard Internet Gateway (IGW) supports both IPv4 and IPv6, and allows bi-directional internet traffic.
• If you attach an IGW and update your route table, your instance with an IPv6 address can receive inbound traffic unless blocked by a security group or NACL.

AWS Network Firewall

AWS Network Firewall is a managed, stateful network security service that protects your VPCs at layers 3 through 7 (network to application layer). It acts as a powerful, flexible barrier for controlling traffic in any direction — whether it is VPC-to-VPC traffic, outbound access to the internet, inbound internet traffic via Transit Gateway or traffic to and from Direct Connect or Site-to-Site VPN. It supports thousands of rules by:

• IP, port, and protocol,
• Fully qualified domain names (FQDNs),
• Regular expressions (for deep content filtering),
• Application-level traffic inspection (e.g. detect and block malware, command-and-control callbacks, etc.)

It can be used with Gateway Load Balancer (GWLB) to scale across AZs and simplify insertion into your traffic flow and offers stateful traffic inspection: maintains awareness of traffic flows, not just individual packets.

Use cases

• Use AWS Firewall Manager to manage policies centrally across many accounts and VPCs.
• Apply consistent guardrails in an Organization using AWS Organizations.
• Simplifies governance and compliance in large multi-account environments.
• Send log events (e.g. rule matches, allowed/denied traffic) to:
  • Amazon S3 (for long-term storage),
  • CloudWatch Logs (for real-time visibility),
  • Kinesis Data Firehose (for advanced analytics and alerting pipelines).
• Enforcing outbound traffic rules from private subnets (e.g. allow only certain domains or services).
• Protecting east-west VPC traffic between microservices.
• Applying layer 7 filtering for high-security workloads.
• Enforcing corporate or regulatory egress controls.

AWS VPC Data Transfer Pricing

Networking costs in AWS can be surprisingly tricky—and if you’re not paying close attention, they can quietly add up. While some traffic flows are free (like traffic within the same Availability Zone using private IPs), others—like inter-AZ or internet egress—can significantly impact your monthly bill. Understanding the cost structure is essential if you want to architect high-performance, cost-efficient systems.

• Traffic Into AWS: free across all AWS regions
• Intra-AZ Traffic (Same Availability Zone): Free when using private IP addresses within the same AZ.
• Inter-AZ Traffic (Different Availability Zones)
  • Private IP: $0.01 per GB for both ingress and egress, totaling $0.02 per GB.
  • Public/Elastic IP: Same as private IP when staying within the same region.
• Inter-Region Traffic:
  • EC2 to EC2: Varies by region pair, generally around $0.02 per GB.
  • Data Transfer OUT to Internet: Starts at $0.09 per GB for the first 10 TB/month, decreasing with higher usage

Cost Optimization Tips

• Use Private IPs: Always prefer private IPs for internal communication to avoid unnecessary charges.
• Same AZ Deployments: Keep interdependent services within the same AZ to eliminate inter-AZ data transfer costs.
• Minimize Internet Egress: Keep as much traffic within AWS as possible to reduce data transfer out charges.
• Direct Connect: Choose a Direct Connect location co-located with your AWS region to reduce latency and data transfer costs

Amazon S3 Data Transfer Pricing

• Ingress (Data Upload to S3): free
• Egress (Data Download from S3):

  • To Internet:

    First 1 GB/month: Free, thereafter reducing rates (up to 10TB/month: $0.09 per GB and over 150TB/month: $0.05 per GB)

  • To EC2 in Same Region: Free.
  • To EC2 in Different Region: $0.02 per GB

S3 Transfer Acceleration

• Upload via Edge Locations:
  • US, Europe, Japan: $0.04 per GB.
  • Other locations: $0.08 per GB.
• Download via Edge Locations: $0.04 per GB.

S3 to CloudFront

• S3 to CloudFront: Free.
• CloudFront to Internet: Starts at $0.085 per GB, decreasing with higher usage.

S3 Cross-Region Replication

• Data Transfer: $0.02 per GB.
• Replication PUT Requests: $0.005 per 1,000 requests.
• Storage in Destination Region: Standard S3 storage rates apply

Cost-Saving Strategies

• Consolidate Data Transfers: Aggregate data transfers to reduce per-GB costs.
• Monitor Usage: Regularly review AWS Cost Explorer to identify unexpected data transfer charges.
• Leverage AWS Savings Plans: Commit to consistent usage to receive discounted rates.
• For accessing S3 or DynamoDB from a private subnet, use a VPC Gateway Endpoint to avoid NAT Gateway charges:
  • NAT Gateway charges: hourly charge of $0.045 per hour plus data charge of $0.045 per GB plus data transfer costs t to S3 (for cross-region only)
  • VPC Gateway Endpoint: free, plus $0.01 Data transfer/GB for data in/out