ABC of Application Architecting on AWS – Series – Part A: Networks
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! 
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. 
- 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
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).
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. 
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!
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:
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. 
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!
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.
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”.  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). 
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.
- 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.
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!
Rakettitiede - Asiantuntijat ja yhteyshenkilöt
Rakettikauppias / Rocket Accelerator
|Vastuullani on Rakettitieteen asiakkaiden ja kehittäjien tarpeiden ja toiveiden yhteensovittaminen, liiketoiminnan uudistaminen sekä strategia. Olen mukana kehittämässä myös ..|
+358 40 520 3100
Rakastettu johtaja / Beloved Leader
|Olen yksi Rakettitieteen perustajaosakkaista ja Rakettitieteen toimitusjohtaja – jo toistamiseen.Rakettitiede perustettiin kymmenen vuotta sitten. Taustalla oli neljä ..|
Rakettitiede - Muita referenssejä
ReferenssiReadpeak - paljon dataa pienellä ruudulla ja nopeasti
Readpeak DSP on alusta ohjelmallisten natiivimainoskampanjoiden optimointiin. Ostojärjestelmää käyttävät tuhannet
ReferenssiRapsiApp tukee kotimaisten öljykasvien saatavuutta
Kotimainen, ruokaratkaisuihin keskittynyt pörssiyhtiö Apetit haluaa varmistaa, että Suomessa viljellään riittävästi
ReferenssiGameRefinery - pelianalytiikkapalvelun teknologia uusiksi
Kuvittele tilanne, jossa tiimisi pitää rakentaa uusi, pitkäikäinen palvelu ja samalla huolehtia vanhan toiminnasta täydellä
Rakettitiede - Muita bloggauksia
BloggausRankat työt vaativat huolettomat huvit
Lomalla viimeinkin, nyt voi konsulttikin ottaa iisisti. On taas tullut se aika vuodesta, kun laadusta tinkimättömät
BloggausRaketin toimari Juha: “Ihmisiä pitää johtaa niin kuin he haluavat tulla johdetuksi”
IT-konsultin työympäristössä jatkuva muutos on tänä päivänä enemmän sääntö kuin poikkeus. Siksi pomonkin pitää
BloggausRakettitiede tukee Suuntoa ydinliiketoiminnan äärellä
Suunto ja Rakettitiede ovat tehneet yhteistyötä vuodesta 2015. Pitkän kumppanuuden ytimessä on luottamus Rakettitieteen
It- ja ohjelmistoalan työpaikat
- Rekrytointi.com - C++ kehittäjä ilmailujärjestelmiin
- Rekrytointi.com - Application Manager (HR Systems)
- Rekrytointi.com - IT-ASIANTUNTIJA, HYBRID CLOUD & DATA CENTER ATEALLE
- Rekrytointi.com - Mission Planning Software Application Engineer
- Rekrytointi.com - C++ kehittäjä
- Rekrytointi.com - Software Test Engineer
- Softability Oy - Senior Test Automation Engineer
Premium-asiakkaiden viimeisimmät referenssit
- Avoin.Systems Oy - Suomalainen Kirjakauppa varmistaa toimintansa kehittymisen uuden ERP-järjestelmän avulla
- Nomis Oy - Nomis CleanDesk – Kauppakeskus Mylly
- Nomis Oy - HOK-Elanto käyttää Nomis QualityDesk laadunseurantajärjestelmää
- HiQ Finland Oy - HiQ auttoi Cross Wrapia suunnittelemaan askelmerkit ja data-arkkitehtuurin konenäön käyttöönottamiseksi
- HiQ Finland Oy - Asuntovuokrauksen verkkokauppa Rettalle
- HiQ Finland Oy - Hiab – Varmuutta myyntiin tarjoustyökalulla
- Nomis Oy - Digia luottaa Nomikseen
Tapahtumat & webinaarit
- 26.09.2023 - Enterprise Architecture 2023
- 29.09.2023 - Sustainability by Monitor – webinaari
- 12.10.2023 - Taloushallinnon terveysaamu
Premium-asiakkaiden viimeisimmät bloggaukset
- Innofactor Oyj - Innofactor Uratarina: Patrik, Junior Data Analyst
- Maxtech - Toimitusjohtajan katsaus H1/23
- Maxtech - Työkartta tuo tehokkuutta työnhallintaan
- Altoros Finland Oy - Päivän sana on ChatGPT
- Efima Oyj - Valitse jatkuvien palveluiden ERP-kumppanisi viisaasti – 3 kriteeriä
- Cinode - Hidastumista jakaantuneessa konsultointimarkkinassa
- Ready Solutions Oy - Microsoft Fabric, kokonaisvaltainen analytiikkapalvelu
Digitalisaatio & innovaatiot blogimedia
Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä