Getting Started With AWS Networking Services - Part 1
VPCs, subnets, and CloudFormation: each of these components is essential to your understanding of AWS networking.
Join the DZone community and get the full member experience.Join For Free
I have often observed that application developers new to AWS struggle most to understand those services that come under "Networking." I do agree that in recent years, with so many frameworks and APIs at your disposal, programming and software development has abstracted to a level that most application developers need not spend time in understanding underlying networking infrastructure and its impact on applications.
In this series of articles, (without any heavy text or going deep dive) I will try to explain AWS Networking building blocks such as VPC, Subnet, NAT, IGW, Route Tables, etc. to help app developers, who are new to AWS and not from a networking background, get basic familiarity with these services.
You may also enjoy: AWS - VPC Networking for Beginners
I am assuming readers are aware of AWS Regions and Availability Zones (AZ), which are in simple terms, global infrastructure owned and managed by AWS and grouped according to geo-locations. AWS Region has typically 3 or more AZs. Each AZ has 1+ datacenters, each datacenter is a separate building and each AZ is isolated from other AZs.
I highly recommend viewing this re:Invent 2016 session from James Hamilton to understand AWS infrastructure in detail. Anyway, let's get started.
1. Virtual Private Cloud (VPC)
The first and most important service for AWS networking. Think of VPC as a virtual network created by AWS for your account. It is completely isolated from VPCs of other users, which allows only you or any AWS account authorized by you to use or modify it. This is your personal network in the cloud.
So, why you need VPC? It is required to provision EC2 instances, DB instances or any compute instances where applications need any sort of network communications. Given the importance of VPC, AWS creates a default VPC for every user in every region. You also get a default Internet Gateway (IGW) attached to the default VPC. As the name suggests, IGW allows you to access the internet within a VPC. It is bidirectional access (source of connection can be either a system on the internet or any EC2 with public IP in VPC).
VPC is associated with a Region and as of now can't be copied or moved to different Regions. Each VPC will be created with a specific IP Address range which is in a CIDR notation.
I highly recommend getting familiar with CIDR notations and IP Address ranges. You can use the following helpful sites to visualize CIDR: (a) http://cidr.xyz/, (b) http://jodies.de/ipcalc or (c) http://www.subnet-calculator.com/cidr.php.
AWS uses CIDR "172.31.0.0/16" as the default VPC in every region. This CIDR range provides 65,534 IP Addresses (2^16) for hosts.
**AWS reserves 5 IP Addresses from each CIDR and that are not available for use:
• Network Address: 172.31.0.0
• VPC Router: 172.31.0.1
• DNS: 172.31.0.2
• Reserved for future: 172.31.0.3
• Broadcast: 172.31.255.255
After you have created a VPC, the next logical step is to partition it into subnets. Similar to a traditional network, a subnet represents a logical part of your network and acts as a group with self-contained security policies. Your resource (EC2) actually resides inside a subnet and communicate to resources in other subnets.
Each subnet is associated with a CIDR taken from parent VPC. A subnet CIDR lets you determine how many private IP Addresses are available for this subnet. Using the default VPC CIDR as an example, which provides usable IP Addresses from 172.31.0.4 - 172.31.255.254, you can divide this entire range into multiple subranges to form a subnet CIDR. E.g. 172.31.16.0/24 and 172.31.32.0/24 are valid subnet CIDR.
I am using 10.0.0.0/16 CIDR for all the examples shared in this post. I am using “ap-south-1” as my base AWS region. It has 3 AZs for which I have used subnets CIDR as follows
- ap-south-1a = 10.0.1.0/24
- ap-south-1b = 10.0.2.0/24
- ap-south-1c = 10.0.3.0/24
A Quick Intro To CloudFormation
Before we move to other topics, I want to briefly mention CloudFormation, which is AWS’s Infrastructure-as-a-Code service. To save our time in creating and configuring various AWS Networking components, I will use CloudFormation template files to create and delete all infrastructure. I am also sharing these template files for your reference.
This is an optional step, you can choose to use AWS console for your setup. The console UI is a nice way to learn and start things in AWS.
Navigate to your AWS console -> CloudFormation and create a new stack using this template file. After the stack is created, you should see a new VPC created in your VPC dashboard similar to the following screenshot.
As mentioned, a default VPC is always created by AWS with the default CIDR. Ignore the AWS-generated ID since it will be different for yours.
Deleting your stack from CloudFormation dashboard will delete any resources created by AWS. However, the S3 bucket where this template is saved must be deleted by users, so don’t forget to check your S3 dashboard and delete unwanted buckets.
The next step is to create a VPC with 3 subnets. Each subnet will be created in a different AZ. From the AWS Console, create a new stack using this file. After the stack is created, you should see 3 new subnets created similar to the below screenshot.
So far, our AWS environment can be represented as follows
In the next part, I discuss Route Tables, Network ACLs, Security Groups and Internet Gateways.
Opinions expressed by DZone contributors are their own.