AWS ABCs – EC2 Internet Connectivity

So, you’ve created a compute instance (ie, a virtual machine) on Amazon EC2. Next question: does the instance require access to and/or from the Internet?

Protip: just because you created the instance in the public cloud, i.e. the cloud that you get to over the Internet, it doesn’t mean that your instances all need to sit on the Internet. They can have direct inbound and outbound Internet access, no Internet access, or something in between (which I’ll explain).

The basic building block for networking on AWS is the VPC (Virtual Private Cloud). Within a VPC, you define your IP space, gateways, ACLs, DHCP options, and more. Gateways will be the focus of this article.

TL;DR

  • Internet Gateway == static NAT: 1-to–1 mapping between the private IP address assigned to an instance and a public IP address that gets assigned to the instance. Note this implies that NAT works in both directions (in- and outbound) and enables direct reachability to the instance from the Internet via its public IP address.
  • NAT Gateway == NAT overload, aka port address translation: all instances behind the NAT Gateway are mapped to a single public IP address.
  • No gateways == no NAT! No Internet access.

As you can see, Internet access in EC2 is always provided via NAT. Read below to understand the mechanisms for enabling NAT within a VPC.

Internet Gateway

An Internet Gateway (igw) is a scalable, highly available object in AWS that functions as the IP gateway towards the Internet. The igw implicitly performs NAT for outbound and inbound traffic and exposes an instance to direct communication from the Internet at large.

An igw should be attached to a subnet within a VPC where public instances sit. Eg, public web servers.

NAT Gateway

A NAT Gateway (natgw) is a scalable object in AWS that functions as a gateway towards the Internet that explicitly does Network Address Translation outbound only. Think of the natgw as similar in functionality to your home router: it allows all the instances behind the natgw to reach the Internet but doesn’t allow inbound connectivity to the instances. A natgw is highly available within the availability zone in which it’s created.

A common use-case for natgw is for instances that need to reach the Internet to pull software updates, reach third-party APIs, or download software packages, but that don’t process incoming connections from the Internet.

Side note: NAT Gateways are different from NAT Instances. NAT Instances are a predecessor to NAT Gateways and have some limitations when comparing the two. That’s all I’m going to say on NAT Instances because you’d be better off focusing on NAT Gateways.

No Gateway

Seems weird, right? But a use-case here might be for a very private VPC that has no Internet access and only talks to other VPCs. Or, perhaps this private VPC only talks to an on-premises data center via IPsec tunnel or Direct Connect. And yeah, I know each of those require their own type of special gateway, but as far as Internet-related gateways, they aren’t required for those use cases.

Public Subnet? Private Subnet?

Last thing on this subject: public and private subnets.

Neither of these are things you explicitly configure; there’s no ticky box for one or the other. A public subnet is simply a subnet that has an igw attached to it; a subnet where the instances are publically accessible from the Internet.

And hopefully you’ve guessed that a private subnet is one with instances that are not exposed to the Internet; it’s a subnet with a natgw attached (or no Internet-related gateway).

References

Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Amazon Web Services or Amazon, Inc.

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to subscribe to email notification of new comments? You can also subscribe without commenting.