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

Different silent install files WLS 10.3.2 and 10.3.3

Today I tried to cut some corners and use a silent.xml file for WLS 10.3.3 for a silent installation of 10.3.2. To my amazement on a clean machine I received the following error: oracle@xxx001:/opt/oracle$ java -Djava.io.tmpdir=/opt/oracle/tmp -jar /nfsstage/wls1032_generic.jar -mode=silent -silent_xml=./silent/wls_silent.xml -log=/tmp/wls.log Extracting 0%....................................................................................................100% The local BEA product registry is corrupted. Please select another Middleware Home or contact Oracle Support I checked the wls_silent.xml file and found that it includes Coherence, which was not bundled with the 10.3.2 version. So I modified the 10.3.3 silent_xml file from value="WebLogic Server/Core Application Server|WebLogic Server/Administration Console|WebLogic Server/Configuration Wizard and Upgrade Framework|WebLogic Server/Web 2.0 HTTP Pub-Sub Server|WebLogic Server/WebLogic JDBC Drivers|WebLogic Server/Third ...

Unpacking Oracle cpio for AIX

When extracting a cpio file with Oracle software from OTN on AIX you might encounter the following problem: oracle@mymachine-app:/install/oracle/MRCA>cpio -idmv cpio: 0511-903 Out of phase! cpio attempting to continue... cpio: 0511-904 skipping 642010 bytes to get back in phase! One or more files lost and the previous file is possibly corrupt! Segmentation fault The solution is to use the option -idcmv oracle@mymachine-app:/install/oracle/MRCA>cpio -idcmv c Reads and writes header information in ASCII character form. If a cpio archive was created using the c flag, it must be extracted with c flag.

Add a user to the JavaSSO

In AS 10.1.3.x Oracle came up with the JavaSSO. Seems to be (from a high level perspective) a poor man's version of the SSO from the AS 10.1.2.x. Having said this it strikes me how little documentation is available for this feature. But we're explorers, aren't we? JavaSSO is based on a file based security provider. The two main files are: - jazn.xml - system-jazn-data.xml Both exist in the $OH/j2ee/ directory. This means that if you have more than one OC4J instance you need to edit both. The most basic task is to add a user. You can - of course try to do this by editing the xml files, but luckily Oracle provides the jazn.jar tool. Make sure that you use the correct java executable and start it: java -jar jazn.jar -adduser jazn.com andreas welcome1 You will be asked for the AbstractLoginModule username (oc4jadmin) and its password. Now we have a user but usually this has to be added to a role before it can do something useful: java -jar jazn.jar -grantrole users jazn.com an...