Skip to main content

Gateways within AWS VPC

 In AWS there are a number of gateways within a VPC. 

The following types exist:

AWS VPC Gateway Types

Gateway Type

Purpose

Internet Gateway (IGW)

Enables public internet access for VPC resources (in public subnets).

NAT Gateway (NGW)

Allows private subnet instances to access the internet outbound only.

Virtual Private Gateway (VGW)

Enables VPN connectivity to on-premises networks.

Transit Gateway (TGW)

Connects multiple VPCs and on-premises networks at scale.

Egress-only Internet Gateway

IPv6-specific gateway for outbound-only internet access from private subnets.

PrivateLink / Interface Endpoints

Secure, private access to AWS services over AWS network.

Gateway Endpoints (S3/DynamoDB)

Private access to AWS services without an IGW or NAT.



So let's dive in a little deeper.

Detailed Overview of Each Gateway

1. Internet Gateway (IGW)

  • Publicly routable gateway for outbound and inbound traffic.
  • Required for instances with Elastic IPs in public subnets.

Example Route Table:

Destination: 0.0.0.0/0

Target: Internet Gateway (igw-abc123)

Use Case: Web servers that need to be publicly accessible.

This is the most common of the interfaces. You want (a part of) your servers or services to be able to get to the outside world and/or let these services be accessed from outside.


2. NAT Gateway

  • Provides outbound internet access for instances in private subnets.
  • Managed service (replaces NAT instance).
  • One per AZ for HA.

Example Route Table (Private Subnet):

Destination: 0.0.0.0/0

Target: NAT Gateway (nat-xyz789)

Use Case: EC2 instances pulling OS updates without being exposed to the internet.

A private subnet needs to access the outside world, but shall not be accessed from there. Imagine you have a special service that supplies some data to an external application, directly from your back-end.


3. Virtual Private Gateway (VGW)

  • Used for VPN or AWS Direct Connect connections to on-prem networks.
  • Attached to the VPC; paired with a Customer Gateway (CGW) on-prem.

Use Case: Hybrid cloud architectures needing secure VPN tunnels.

The Virtual Private Gateway is the workhorse of the hybrid architecture. Parts of your applications are still on-prom, while some are already in the cloud, either with lift&shift, or completely new build.


4. Transit Gateway (TGW)

  • Central hub for connecting multiple VPCs, on-premises, and VPNs.
  • Reduces complex peering meshes.

Use Case: Enterprises with 5+ VPCs or regional/global architectures. Mind the costs, as this is billed per connection.


5. Egress-Only Internet Gateway

  • IPv6-specific gateway for outbound-only internet traffic from private subnets.
  • No inbound traffic allowed.

Use Case: IPv6-only environments needing outbound access without public exposure.


6. Gateway Endpoints (S3 / DynamoDB)

  • Enable private, VPC-level access to specific AWS services without internet access or NAT.
  • Only available for S3 and DynamoDB.

Route Table Entry Example:

Destination: pl-68a54001 (com.amazonaws.region.s3)

Target: Gateway Endpoint (vpce-123456)

Use Case: Accessing S3 buckets from a private subnet with no internet gateway or NAT.


7. Interface Endpoints (AWS PrivateLink)

  • Use AWS PrivateLink to privately access services via ENIs.
  • Works for AWS services, third-party SaaS, and your own services.

Use Case: Secure access to services like Secrets Manager, without crossing the internet.


📌 Summary Comparison

Gateway

Direction

Internet Required

Services Accessed

Subnet Type

Internet Gateway

In/Out

Yes

Any

Public

NAT Gateway

Out only

Yes

Any (via outbound only)

Private

Virtual Private Gateway

In/Out

No (VPN/IPSec)

On-prem

Any

Transit Gateway

In/Out

No (AWS Internal)

VPCs, VPNs, DX

Any

Egress-only IGW

Out only (IPv6)

Yes

Any

Private (IPv6)

Gateway Endpoint

Out only

No

S3, DynamoDB

Any

Interface Endpoint

In/Out

No

AWS/private services

Any

 


A graphical representation of these gateways shows their position:






Comments

Popular posts from this blog

Oracle Fusion Middleware Forum in Valencia

Last week the 22nd Fusion Middleware and PaaS Partner Community Forum took place in Valencia, Spain. For me this was a very valuable experience - again as I have visited a number of #ofmForum before. Let me recap here the highlights of this meeting. After a great Welcome-Reception the evening before, where everybody had the chance to catch up with a large number of old (and soon-to-be new) friends, the conference started with a kind of the state of the union by Jürgen Kress. The community already has more than 8000 people. This - in a fact - is a tremendous achievement. Everybody agrees that this is only possible by the relentless work of Jürgen who puts a big effort into this. It shows that other areas inside the Oracle technology stack do not benefit by equivalent communities. Even other communities, when they exist at all, do not compete in the same league. So a VERY BIG THANK YOU for Jürgen is at its place here. After the opening a keynote from Alistair Hopkins showed ver...

Paas Summercamp 2017 in Lisbon

So – another summer camp is over. What was the outcome of this? Was there more to it than meeting some old friends, dive into some slides, get your hands dirty on new versions and finally talk about it over a glass of Portuguese wine or beer? So let’s start at the beginning – where are we right now? In the Process Cloud Service track the global PM Nathan Angstadt kicked of the session by asking how many projects we are on that use PCS and how we get along selling the product. The outcome was somewhat predictable: about one or two participants were on PCS projects, and selling is still a big issue. We discussed the various reasons for that. The main essence was that the PCS is often positioned at previous BPM customers who still have to deal with large BPM implementations and are somewhat afraid of the new PCS-style. BPM and PCS are two different things. They target different customer issues. BPM is still useful when it comes to large scale implementation...

USB2 for Logitech wireless keyboard/mouse

I have bought an Acer E17 laptop. Also I redecorated my study room - so I wanted to get rid of all the clutter, plus sharing the desk with my wife and use the big screen I have - which sat idle on my old desk. So I thought to get a docking station. Just a brief check on the underside of the Acer's (I have three now) showed me that they are not in the league of grown-ups when it comes to the point of supplying docking station slots. So I tried to use a wireless keyboard and mouse from Logitech which I bought a year ago. However there was sometime a big lag in the keyboard and also the mouse did not react that well. Looking on the internet I found a number of folks who complained about this but only little help in solving the problem. Finally I stumbled over a posting that stated that USB2 would be a better choice than USB3, as this scans more devices on more frequencies. So I put the receiver in the USB2 port and since then I am a happy computer user again, not wishing to ...