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

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

Scope:

•        Intro,
•        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),
•        Project: Hands-On.

Intro:

•   AWS 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

NB:

• 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    

•    Does the subnet route table have:
•   ::/0 → eigw-xxxx
•      Is the IGW attached to the VPC?
•     (EOIGW requires IGW presence)
•     Are SG outbound rules allowing IPv6 traffic?
•      Are SG inbound rules too restrictive for return traffic?
•      (Usually not, SG is stateful)
•      Is NACL blocking ephemeral ports?
•      Is PMTUD broken due to ICMPv6 filtering?
•      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:

• twtech Creates egress only internet gateway:

Create EOIGW:

Step-2:

• twtech Edits the route table: Private route table (twtechPrivateRT)

Add route: 

Save changes:

twtech explanation:

• Any traffic directed to IPV6 addresss (::/o) is 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. 

NB:

• Those instances in the Private subnet are NOT accessible from the public internet.

Step-3:

Finally:

• twtech verifis that EOIGW allow internet access via IPV6 to private subnet instances within the VPC.

Connect (SSH) into BastionHost-instance:

From Bastion Host.

• twtech connects (SSH) to Bastion Host.

From Bastion Host,  

• twtech Connects 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

Step-4:

twtech updates and Install git package to verify with command:

sudo yum install git -y

Step-5:

twtech performs 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