Text: Minna Wahlroos

This blog post is the first in a series of three posts on setting up your own application infrastructure on AWS. The three encompass Networks, Computing, and Storage in the respective order. This post is about Networks and there’s a dedicated chapter for each building block, and a ton of other useful information – stay tuned!

The AWS building blocks you will learn after having read this post: VPCs, Subnets, Security Groups, Elastic IPs, Route53 (Domains and Hosted Zones).

Why is this important?

So why is defining a network and subnetting important anyway? Why doesn’t it make sense to “just deploy virtual machines” and let AWS take care of details?

Defining networking for your application means defining the physical location where it runs. In AWS there’s no concept of “run somewhere”, it’s always explicitly defined at least on a region-level because it has a high impact on latency, and prices differ per region!

Additionally, being able to distribute your compute instances to several different locations gives you resiliency. Even when countrywide infrastructure breaks (such as major power outages), your application will continue to operate. Thus your application can be more resilient than a country! [1]

The network has to be defined before deploying compute instances. This is because changing it requires replacement. Check the accompanied link for a detailed scenario. [2]

• In layman’s terms: any instances on it have to be deleted and re-created.
• This shuts down any ongoing processes (“services”) until re-created.

This is because of the structure of AWS Networking: Changing a VPC or Subnet may involve changing the data center where your application runs.

Parts of AWS Networks block by block

VPC

The foundation of a new environment requires VPC (short for Virtual Private Cloud) first of all. In essence VPC is just metadata, containing the geographical Region you want your compute instances to reside in (such as “Frankfurt” aka “eu-central-1”), and a maximum number of internal IP addresses available in the environment (expressed in CIDR notation[3]).

Regions include for example Ohio-region, California-region, Ireland-region, Frankfurt-region, London-region, and so on.

One of AWS Regions, “Frankfurt” also known as “eu-central-1”, depicted by area within dots.

In AWS’ VPC, the highest possible number of IPv4 addresses you can set is 65 536 internal IP addresses (via netmask /16). Lowest you can set is 16 addresses (via netmask /28). Generally, it makes sense to use the full /16 netmask, since there is no downside to having more internal addresses available. Resizing this after creation is impossible. [4]

A way to picture VPC is like “a big, empty piece of land”. It has a location and a size (maximum number of compute instances you could place there), but no electricity, no internet connectivity, or such.

Figuratively speaking, VPC can be described as a sized piece of land, in a certain region.

Having set-up a VPC (the boundary of IP addresses in a specific region), next you need Subnets!

Subnet

A Subnet, like VPC, is metadata too, but geographically more specific. Whereas VPC specifies a Region, Subnet specifies Availability Zone (generally a data center) where the compute instances will be running.

For example Frankfurt-Region’s all 4 AZs (data centers) you can find on Google Maps:

1. Frankfurt-Region’s AZ on Google Maps

2. Frankfurt-Region’s AZ on Google Maps

3. Frankfurt-Region’s AZ on Google Maps

4. Frankfurt-Region’s AZ on Google Maps

Unlike VPC, where it's sensible to configure the highest possible number of private IP address space; on the other hand, Subnets should be allocated with plenty, but reasonably few private IP addresses. The reason for this is that every address given to a Subnet is away from the other Subnets within the VPC. [5]

If a Subnet is associated with AWS Internet Gateway service, it’s called a “Public Subnet” (equivalent to Default VPC’s default Subnets).

If a Subnet does not have such association, then it’s generally considered “Private Subnet”. Additionally, a Private Subnet may have an association to AWS NAT Gateway service for one-way internet access. This allows compute instances to download updates from the internet, but other computers (from the internet) cannot address these compute instances.

If a Private Subnet doesn’t have a NAT Gateway associated with it, then it can be called an “Isolated Subnet”. These are useful for managed services (PaaS) such as RDS Databases because those are updated by AWS and don’t require downloading patches from the internet.

A way to picture a Subnet is “a building on the aforementioned land, with wall sockets connected to electricity, and possibly to internet providers”.

Subnet is like a part of VPC's land, where electricity and network connectivity are available.

Having defined a Subnet, you have "a location" to place your compute instances in, but still need the wiring to connect them to either the internet or each other within the VPC. This is what Security Groups allow!

Security Group

When finally launching a compute instance, you’ll have to either choose an existing or create a new Security Group attached to your instance. This is because all network traffic to-and-from instances is forbidden by default, and must be explicitly allowed via Security Group(s). (This “disallow by default” and “enable explicitly” comes from “principle of least privilege”, one of universally agreed Best Practices when working with AWS services.)

In other words, this means no internet connectivity is available even if your Subnet has an Internet Gateway and was deployed with a public IP address. This may confuse those who are used to a default SSH connectivity. It is a key difference to many VPS hosting service providers, who may have SSH traffic enabled out of the box.

In case if you don’t pick a Security Group yourself (e.g. clicking “Launch” in AWS Console), it’d be attached to what is called “Default Security Group”. It is able to connect to the internet (if either Internet Gateway or NAT Gateway is associated with the Subnet), but other computers cannot create incoming connections to it.

Security Groups are basically port-to-address mappings for inbound (“ingress”) traffic and outbound (“egress”) traffic.

Example of a Security Group, allowing incoming connections (“Inbound rule”) from within VPC’s private network (“Source”) to Postgresql’s default port (TCP 5432). Enabling access to a PostgreSQL database from any instance within VPC.

It makes sense that Security Groups have only Allow -rules since everything is forbidden by default. Also if you allow traffic one-way (for example “Get me webpage google.com”), then for that request’s session the inverse is automatically allowed (for google.com to return you webpage content). This is why sometimes Security Groups are called “Stateful” and are always configured from the perspective of “who initiates the network connection”.

Security Groups are implemented by AWS separately from your compute instance, so in practice, you could additionally limit network traffic by using firewalls/iptables on Operating System -level. Additionally, you could use AWS’ Network Access Control Lists (often shortened to ACLs), which are stateless and attached to specific Subnet(s), not instances. This way you could have as many as 3 layers of practically the same rule mappings, but often it makes sense to only use Security Groups!

Correctly configured, they’re secure enough in themselves, and ACLs are not required in principle. Valid niche use-cases for ACLs are for example “If you have a group of AWS developer user accounts restricted to a specific Subnet, where they are allowed to launch new EC2 instances – as an administrator, you can make sure specific ports’ traffic won’t get through (assuming the developers don’t have privileges to Subnet’s configuration)”.

Security Groups can be pictured as the wiring, connecting individual compute instances either to other instances, Subnets, or the internet; But via explicit firewall configuration.

Having established a VPC, Subnet(s), and Security Group(s), you’re technically able to instantiate a compute instance that’s accessible through the internet. ????

Following are additional “nice to know” information and services that you can use for a smoother flying experience in cyberspace. But as for network fundamentals, this wraps the post up!

Good to know: Elastic IP address

When you finally launch an EC2 instance, if it’s in a Public Subnet and configured with “enable auto-assigning public IP address”, then in addition to its private IP address (used within VPC) it’ll also get a public IP address (used internet-wide). In case you shut down the instance, and later on restart it, this public IP address may change. This behaviour becomes a problem if, for example, the IP address was listed in some other system’s firewall rules.

To have what is called a “static IP address”, you can create an Elastic IP address (abbrev. EIP) and connect it to a compute instance. EIP is essentially a “static IP address as a service”, and maintains the same public IP address even if the compute instance is shut down.

EIP doesn’t currently cost anything when attached to an instance that’s running, but every EIP that’s unused by an instance (i.e. “reserved static IP address that isn’t in use”) costs approximately 3.5 €/month (billed hourly, so only fraction of cents for a couple of hours). In most cases, Elastic IP is a cheap (or “free”) and recommendable service to use.

Fun estimate: Amazon owns more than $2B worth of IPV4 addresses (as of 11/12/20). 

Good to know: Domain names (Route 53 Domains and Hosted Zones)

Route 53 is a collection of domain-related services, but two of them are essential to know. “Route 53 Domain” refers to AWS as Domain Registrar, allowing to purchase domains from many TLDs (e.g. .com .net .io), and it’s a competing service with other Domain Registrars like GoDaddy or Gandi. Route 53 itself actually uses Gandi under-the-hood.

Using Route 53 for your domain is totally optional, you can connect other domain registrars to AWS services. Why’d you purchase a domain from AWS’ Route 53 could be for ease-of-use (having all your infrastructure configuration in one place, and less log-ins), but as previously mentioned it isn’t necessary to use Route 53 as your domain registrar!

“Route 53 Hosted Zone” refers to AWS’ own DNS -servers (Domain Name Servers), which can be configured with DNS Records. These are essentially mappings, e.g. a given public IP address to a domain name (called A Record), or one domain name to another domain name (called CNAME Record). These are important if you’re having a highly automated infrastructure on AWS because they allow you to automatically validate TLS Certificates (created in AWS’ Certificate Manager).

By default, if you use AWS as Domain Registrar, you’ll be using Route 53 Hosted Zone (DNS servers). But if you use another Domain Registrar, then they have their own set of DNS servers, and you have 2 options:

• You can keep using them, and manually validate TLS Certificates.
• Or you can configure the other Domain Registrar to use Route 53 Hosted Zone as your domain’s DNS server. Configuring this initially is a manual process (depending on the Domain Registrar where exactly it is configured), but after it’s done you can use your Route 53 Hosted Zone for creating new DNS Records for your domain.

Good to know: Default VPC of a Region?

When you create a new AWS account, you’ll have a pre-created Default VPC in every Region. And every Default VPC has several default Subnets (one per AZ). So why define IP range and Subnets, instead of using Default VPC, if knowing Region is enough for latency and pricing?

 The devil is in the details; All of these pre-created Subnets are public. This means a newly deployed compute instance by default gets a public IP address and is connected to the internet. Additionally, these Subnets have around 4000 available internal IP addresses each, which means you could deploy a maximum of 4000’ish compute instances in each.

Default VPC is good for rapidly prototyping services that may be fully on the public internet, this is what it was actually made for - “getting started quickly with AWS”. [6] Technically speaking you could add new non-default Subnets that aren’t connected to the internet, however you shouldn’t because it’s not as maintainable as having independent VPCs for each separate project.

Performing a move of an existing application from Default VPC to its own VPC without incurring downtime, requires very careful planning as previously mentioned. Having set up its own VPC in advance saves you from this trouble. AWS has several guides on how to move resources to a new VPC, but they generally don’t describe how to perform these scenarios without downtime (which is possible but more complex). [7]

On dangers of Default VPC, say, if you deploy a Database service. Relatively recent news about a Finnish company called Vastaamo; they had a database server connected to the internet, with reportedly insecure credentials (username & password). A criminal connected to that database, and stole a lot of personal secret information, causing a nation-wide scandal. A prime example of why network segmentation and security is important. Setting up your own VPC and knowing the essential parts avoids such scandals.

Notes

• Prices of services differ and are listed, per Region.
• Subnet is linked to AZ which designates the data center (within VPC Region) where resources are deployed. Most regions currently have 3 AZs.
• Default VPC is only good for publicly accessible non-production prototypes.

References

1 Chaos Engineering Upgraded (The Netflix Technology Blog)

2 How do I move my EC2 instance to another subnet, Availability Zone, or VPC? (aws.amazon.com)

3 https://tools.ietf.org/html/rfc4632

4 How can I modify the CIDR block on my VPC to accommodate more hosts? (aws.amazon.com)

5 A subnet in use by load balancers in my VPC has insufficient IP addresses (aws.amazon.com)

6 Default VPC and default subnets (docs.aws.amazon.com)

7 How do I change the VPC for an Amazon RDS DB instance? (aws.amazon.com)

This was the first blog post in a series of three posts on setting up your own application infrastructure on AWS. Next up, Computing! Follow and stay tuned!

We’re looking for developers to board our rocket ship – read more and apply!