Egress-Only Internet Gateway (EOIGW) | Overview & Hand-On.

An Overview of Egress-Only Internet Gateway (EOIGW).

Scope:

•        How Egress-Only Internet Gateway (EOIGW) works,
•        How AWS routes IPv6 egress,
•        Design patterns,
•        Hidden pitfalls,
•        Comparisons with NAT gateways and IGWs 

Breakdown:

•        Why EOIGW Exists (The Core Problem).
•         EOIGW Routing Behavior,
•        Comparison Table,
•        Security Model,
•        EOIGW + IPv6-Only Subnets,
•        EOIGW Return-Path Enforcement,
•        Diagnostics & Troubleshooting EOIGW,
•        EOIGW + TGW + Hybrid Connectivity,
•        Best Practices,
•        Architecture Diagram (Text Representation).

Intro:

•        Egress-Only Internet Gateway (EOIGW) is an AWS VPC component that enables outbound-only internet connectivity for IPv6 workloads without allowing any inbound connections initiated from the internet.
•        Egress-Only Internet Gateway (EOIGW) is the IPv6 functional equivalent of NAT Gateway for IPv4, but without performing NAT.
•        Instead, Egress-Only Internet Gateway (EOIGW) acts as a stateful edge firewall + router for IPv6 traffic leaving for a VPC.

1. Why EOIGW Exists (The Core Problem)

NB:

IPv6 does NOT use NAT (Network Address Translation).

In AWS:

•         Every IPv6 address inside a VPC is globally unique and internet-routable.
•         Without special protections, any IPv6-enabled EC2 could be reached from the internet directly if allowed by routing + security groups.

To prevent inbound IPv6 traffic while allowing outbound connectivity, AWS created EOIGW.

It solves this key problem:

“How do I let my EC2 instances reach the internet using IPv6 while preventing all unsolicited inbound IPv6 traffic?”

That is what EOIGW guarantees.

2. How EOIGW Works Internally

EOIGW is stateful:

Outbound IPv6:

1.    Instance sends IPv6 packet to its subnet route table.
2.      Subnet route table forwards ::/0 to the EOIGW.
3.      EOIGW forwards the packet directly to the internet.
4.      EOIGW remembers the connection state.

Inbound IPv6:

There are two categories:

A. Return traffic for established flows

EOIGW allows the inbound packet.

B. New incoming connections

EOIGW drops them regardless of:

•         Public IPv6 addressing
•         Security group inbound rules
•         NACL inbound rules

EOIGW enforces outbound-only behavior at the edge.

3. EOIGW Routing Behavior

In a subnet route table:

Destination: ::/0

Target: Egress-Only Internet Gateway (eigw-xxxxxxxx)

This route:

•         Sends all IPv6 internet-bound traffic to EOIGW
•         Does not affect IPv4 flows (NATGW needed for those)

EOIGWs cannot be used for:

•         IPv4
•         Local IPv6 routing inside VPC
•         TGW/DX/VPN routing
•         VPC Peering

They are strictly VPC → internet (IPv6 egress-only).

4. Comparison Table

Feature	EOIGW	NAT Gateway	IGW
IPv4	❌	✔️	✔️
IPv6	✔️	❌	✔️
Performs NAT?	❌	✔️	❌
Inbound allowed?	Return traffic only	Yes, via DNAT	Yes
Stateful?	✔️	✔️	❌
Supports private-only workloads?	✔️	✔️	❌
Charge	Free	Charged	Free

EOIGW is free (no hourly cost), unlike NAT Gateway.

5. Security Model

EOIGW is a stateful barrier.

Outbound IPv6 flow:

•         Allowed if SG/NACL outbound rules allow it
•         EOIGW builds flow state
•         Internet return flow allowed only if matching an existing session

Inbound IPv6 flow:

•         ALWAYS dropped unless:
•    It matches an existing, active connection entry

Security Groups are still required

EOIGW does not replace SGs.

The recommended pattern:

•         SG Outbound: allow needed IPv6 egress (::/0)
•        SG Inbound: allow minimal or no IPv6 inbound
•         Route Table: send ::/0 → EOIGW

This gives twtech:

1.   Least privilege SG model
2.   IPv6 outbound capability
3.  Guaranteed inbound isolation

6. EOIGW + IPv6-Only Subnets

Most modern architectures use IPv6-only subnets + EOIGW + NAT64/DNS64 combination:

Pattern used for:

•         EKS/ECS clusters scaling into tens of thousands of pods
•         Microservice-only VPCs
•         High-scale SAAS architectures

EOIGW is required because IPv6-only workloads have no private IPv6 vs public IPv6 distinction—every IPv6 is globally valid.

7. EOIGW Return-Path Enforcement

EOIGW tracks state using:

•         5-tuple: src/dest IPv6, ports, protocol
•         Timeout values similar to NAT Gateway
•         Symmetric routing requirement

If return traffic comes through a different route, EOIGW drops it.

Common architectural pitfalls:

•         TGW incorrectly routing IPv6 return traffic
•         IGW and EOIGW mixed in same VPC with asymmetric paths
•         EC2 instance has multiple ENIs in multiple subnets

8. Diagnostics & Troubleshooting EOIGW

Symptoms of EOIGW issues

•         EC2 instance can’t reach the IPv6 internet
•         IPv6 outbound stuck at SYN_SENT
•         Some IPv6 services reachable, others not
•         Return traffic flows missing due to asymmetry

Checklist

1.      Does the subnet route table have:
2.   ::/0 → eigw-xxxx
3.      Is the IGW attached to the VPC?
4.     (EOIGW requires IGW presence)
5.     Are SG outbound rules allowing IPv6 traffic?
6.      Are SG inbound rules too restrictive for return traffic?
7.      (Usually not, SG is stateful)
8.      Is NACL blocking ephemeral ports?
9.      Is PMTUD broken due to ICMPv6 filtering?
10.      Is asymmetric routing present?

Management Commands

Inside EC2:

# bash

curl -6 https://ipv6.google.com

ping6 -c3 2606:4700:4700::1111

traceroute6 <IPv6 address>

To view IPv6 routes:

# bash

ip -6 route

Check SGs:

# bash

aws ec2 describe-security-groups

9. EOIGW + TGW + Hybrid Connectivity

Important rule:

EOIGW applies only to traffic that leaves the VPC to the global internet.

Traffic via:

•         Transit Gateway
•         Direct Connect
•         VPN
•        VPC Peering

Does NOT use the EOIGW.

This avoids:

•         Breaking on-prem IPv6 routing
•         Returning traffic unnecessarily hitting EOIGW
•         Hybrid asymmetry

10. Best Practices

1. Always enforce ::/0 → EOIGW in private IPv6 subnets

Consistent and safe.

2. Avoid adding IGW ::/0 routes in the same RT

This creates nondeterministic routing patterns.

3. Use SG outbound allow-list models

Avoid open ::/0 outbound unless required.

4. Monitor IPv6 flows via VPC Traffic Mirroring

EOIGW-compatible for state validation.

5. For EKS/ECS, combine EOIGW + NAT64 for hybrid compatibility

Allows IPv6-only workloads to reach IPv4-only services safely.

11. Architecture Diagram (Text Representation)

Project: Hands-On

How twtech uses Egress-only Internet Gateway (EOIGW) to enables outbound-only internet connectivity for IPv6 workloads without allowing any inbound (public) connections initiated from the internet.

Search for aws service: VPC (Virtual private cloud)

Navigate to:  Egress-only internet gateways

Step-1:

Create egress only internet gateway:

Create EOIGW:

Step-2:

Edit the route table: Private route table (twtechPrivateRT)

Add route: 

Save changes:

twtech explanation:

• Any traffic directed to IPV6 addresss (::/o) should be directed to Egress-on Internet Gateway created (twtechEOIGW)
• With IPV6, twtech instances in the private subnet of the vpc (twtechvpc) can access internet with help of EOIGW. 
• Those instances in the Private subnet are NOT accessible from the public internet.

Finally:

• Twtech needs to verify that EOIGW allow internet access via IPV6 to  private subnet instances in the VPC.

Connect (SSH) into BastionHost-instance:

Connect to instance in the Public subnet of the VPC (twtechPrivateInstance): via SSH forwarding with command

sudo ssh ec2-user@10.0.xx.89 -i mykey.pem

Install git packages with command:

sudo yum install git -y

Security checks:

twtech needs to verify that the instances in the Private subnet do not have public internet access via ping command:

ping google.com