AWS Cloud Infrastructure Essentials — Part 1

Introduction

We all have witnessed the cloud revolution and how it has changed the IT landscape. Amazon Web Services (AWS) started with humble beginnings back in 2006 and soon enough gained popularity. Major Cloud providers continues to disrupt the way we think about system architecture, design and service even after 16 years of cloud existence.

Cloud services has made such a profound impact that these days we rarely see system designs that do not take advantage of one or the other services that are running virtually on Cloud. However, this widespread adoption of Cloud services has challenged IT workforce to quickly learn and adapt to new ways of working and skill up on the demands of ever increasing cloud services.

Back in good old days when Cloud was only a weather phenomena, application infrastructure was responsibility of networking team. In an enterprise systems it still is and you need their expertise to manage complex workloads running in cloud, however, developers, application architects and project managers are now expected to have at-least basic understanding of cloud infrastructure.

Ever been in a call with external IT teams where they expect you to resolve whitelisting issues for the services you are providing? Have you ever been found lost with complex networking jargons like Internet Gateway, Subnets, CIDR blocks etc? If yes, then this article is an attempt to solve some mysteries behind these concepts.

This is the first of the three part series article where we will look at a reference architecture and then peel the layers off in an attempt to understand the infrastructure components in the architecture.

Reference Architecture

Instead of referencing a complex infrastructure setup, let’s look at a typical three tier web application architecture setup in AWS.

This may seem a simplistic or complex architecture diagram depending on your experience with AWS. However, it provides a good starting point for understanding what it takes to host an application in cloud infrastructure. So let’s start looking into some of the infrastructure components presented in the above reference architecture.

Regions, Availability Zones & Edge locations

Let’s start with the basics. An understanding of regions, availability zones and edge locations is critical when deciding where you want to run your workloads and how you would want to design your applications for failovers and high availability.

AWS has its presence across the globe. By far the largest datacenter for AWS is in North Virginia but its global infrastructure has presence in 27 geographical regions (as of writing this article).

Each region is further divided into multiple availability zones. For example, North Virginia region has 6 availability zones. Think of availability zones as a group of one or more datacenter within a region that are isolated from failure that may happen in other availability zones.

Then we have edge locations. Edge locations have a smaller setup of servers whose primary purpose is to reduce the latency when the end user connects to AWS services. For example, if the user is located in Nairobi, the closest region would be Cape Town, however, the user can connect to Edge location in Nairobi for services like Cloudfront (AWS CDN), Route 53 (AWS DNS Service) and AWS WAF (Web Application Firewall). AWS Global Accelerator also allows user’s request to connect to the nearest edge location from where the request is routed to AWS region through AWS internal network instead of via public internet which reduces the latency substantially.

Note that not all AWS services are available in all regions and the pricing may also differ based on the region(s) you decide to operate in.

Virtual Private Cloud (VPC)

It is difficult to have conversation about cloud without talking about Virtual Private Cloud (VPC). Virtual Private Cloud is a logically isolated portion of cloud that can be thought as your virtual “data centre”. You have full control over your VPC and what resources you may want to host in it. The “Private” part of VPC should be emphasised here since no one can have access to it without your permission. However don’t mistake it to be like an on-premise datacenter which is dedicated to your organisation. It is still on shared servers somewhere in one of the AWS datacenter, though it is logically isolated from other VPCs.

When requesting for a VPC, you need to provide an IP range that your VPC will be assigned. If you are planning to have multiple VPCs under same account or within the same Organization, it is highly recommended that you think through your IP addressing policies to avoid any conflict in future. This is because if IP addresses overlap VPC peering will be an issue.

Hands on Example — Creating VPC

1. On AWS Console search for VPC
2. Ensure that you are in correct region where you want to create your VPC and then click on “Create VPC”

3) Select “VPC only” and provide the Name of the VPC and the IP address range

4) Click on “Create VPC”

IP Addressing

Before we further delve into some of the concepts of cloud infrastructure, it is important to understand the IP addressing and CIDR blocks. These may seem more technical but are essential concepts to understand if we need to do anything useful in cloud. We would not deep dive into history or details of TCP/IP model but would rather aim to understand just the IP addressing fundamentals.

Any device that operates on internet be it your laptop, your mobile or a large server in datacenter has an IP address. There are two versions of IP addressing — IPv4 and IPv6. IPv4 addressing scheme is used by most devices since it is the older addressing scheme. An IPv4 address will look something like below

192.168.0.0

Every IP address such as above has a network id and a host id. All the resource that are on the same network will have the same network id and unique host id. Lets say you have 3 servers sharing the same network, they may have IP address as below

In the above example, numbers represented by brown are network ids and number in orange are host ids. As can be seen, the network id remains same for all the three servers as they share the same network but the host id differs.

When creating a VPC, you need to provide the IPv4 CIDR which is the range of IPs that are assigned to your VPCs. A CIDR (Classless Inter-Domain Routing) is a method of allocating IP address which differs from traditional classful IP addressing. Simply put, a CIDR notation has an IP address and a subnet mask

192.168.0.0/24

In above example, 192.168.0.0 is the starting range of IP address, the subnet mask of /24 indicates which bits in the address identifies the network id. So in above example since the subnet mask is /24 the first 3 octets (24/8 = 3) would be network id and the last octet will be the host id as shown below

So when the subnet mask is /24, you get the range of IPs starting with 192.168.0.0 and ending with 192.168.0.255 which are 256 IPs (remember that network id do not change within the network). The first IP 192.168.0.0 is the network address and the last IP 192.168.0.255 is the broadcast address and hence cannot be used for allocating to a host in the network. Therefore the first host IP will be 192.168.0.1 and the last host IP will be 192.168.0.254.

If the subnet mask is /16, it means that only the first two octets are network ids and the remaining two are host ids as shown below

In this case the starting IP address in the range is 192.168.0.0 and last IP address is 192.168.255.255 which means that the total number of available IPs are 65,536.

Use the below formula to calculate the number of available IPs for any CIDR block

2^ (32 — subnet mask)

So if the subnet mask is /24, the number of IPs available are 2 ^ (32–24) which is 2⁸ = 256. If the subnet mask is /16, the number of IPs available are 2 ^ (32–16) which is 2¹⁶ = 65,536

Note:

1. Not all IPs are reachable on internet. There are private IPs that are defined by RFC 1918 and these IPs cannot be called via internet. When defining CIDR range for VPC, it can only use private IPs ranges as defined by RFC 1918

Private network - Wikipedia

2. In AWS, the CIDR block size can be between /16 and /28

3. The number of available IPs will define the number of host that your VPC can support.

4. AWS reserves the first four address and the last address in IP range and cannot be used by a host in the VPC

5. There are lot of tools available which can provide you the information on IP range based on the network address and subnet mask that you are defining for your VPC. One of the subnet tool calculator which I find quite useful is IPv4SubnetCalculator

Subnets

Once you define your VPC, you would create subnets within VPC. A subnet is a subset of your network infrastructure which is deployed to a particular availability zone and can run your specific workloads. Think of VPC as a large house. Every house would have rooms for specific purpose like Living room, Kitchen, Bedrooms etc. Subnets are like those rooms that would subdivide your VPC and can run workloads of specific nature.

When creating subnets, you need to provide the VPC to which it would be attached, the Availability Zone on which it would be deployed and the IPv4 CIDR block that you would want to assign to the subnet. The IPv4 CIDR block should be a subset of CIDR block that you selected for the VPC during the creation.

The following diagram provides an overview of how regions, availability zones, VPC, subnets and IP ranges would typically play out in cloud infrastructure

In above diagram we have 4 subnets, two in each availability zone. The CIDR block of subnets should be a range that falls under the main CIDR block of VPC. There are many tools online that can help you calculate the correct subnet range given your VPC CIDR range. One that I find particularly useful is IP Subnet Calculator

Hands on Example — Creating Subnet

1. On AWS console navigate to VPC and from the left navigation bar select “Subnets”

2) Click on “Create subnet” and select the VPC to which the subnet must be associated

3) Under subnet settings provide the subnet name, Availability Zone and IPv4 CIDR block

4) Click on “Add new subnet” button to add additional subnets

5) Once all subnets are added, click on “Create subnet” button to create the subnets

Note: By default all the subnets created are “private”. This means that any resource that you host on the subnet will have no access to internet at all (either inbound or outbound). We will look at creating a public subnet later in the article.

Route Tables

Route tables define the communication routes via rules that specify the outbound communication allowed from the subnet. If you select a subnet you can see that it is attached to a particular route table.

When we create a VPC, AWS creates a main route table for us. This main route table defines the local routing for all subnets that are created in the VPC. As can be seen above, the subnet is associated to main route table and the Destination CIDR is the CIDR block that we defined for our VPC. This local routing as defined above, allows communication between subnets created in the VPC.

You can create your own route tables and then can associate one or more subnets to the route table. Each route table can specify multiple rules for outbound communication. Each rule has a destination that is defined by CIDR notation and the target where it can be routed to.

If you navigate to the route tables and select the main route table for the VPC as shown below, you can see various details for the route table

Selecting the subnet association provides you information on which subnets are associated with this route table. Any subnet that is created in the VPC and is not explicitly associated with any route table is by default associated with the main route table.

Internet Gateway

When you create a subnet, by default AWS will create it as private subnet. This means that any resources hosted on that subnet will have no access to internet, either inbound or outbound. Now, if you have a public load balancer or a public server that needs to communicate with internet, as first step you would need to convert a private subnet to a public subnet. Below are the steps needed to create a public subnet

• Create an internet gateway
• Attach it to the VPC
• Create a public route table to allow communication from internet to the internet gateway

Lets look at the above steps in more detail in our next hands on exercise

Hands on Example — Creating a public subnet

1. Under the VPC navigation, select Internet Gateways and click on “Create internet gateway”

2) On the “Create internet gateway” screen provide the name of the internet gateway and click on “Create internet gateway” button

3) Once the internet gateway is created, you will see that it has a state of “Detached”

4) Attach it to VPC by selecting “Actions” → “Attach to VPC” and then select the VPC to which you want to attach the internet gateway. Click on “Attach internet gateway” button

5) Once internet gateway is successfully attached to VPC, its state will change to “Attached”

6) Navigate to Route tables from left navigation and click on “Create route table” button

7) Provide a name to the route table and select the same VPC that you selected when creating internet gateway

8) Click on “Create route table” button

9) For the route table created, under Routes select “Edit routes”

10) Select “Add route” and add destination as 0.0.0.0/0 and Target as the internet gateway that we just created and click on “Save changes”

Note: IP range 0.0.0.0/0 is a blanket representation for any IPv4 IP address and so essentially what we have defined above is that this route table allows communication from internet gateway to any IPv4 address out there in the internet.

11) Under the route table navigate to “Subnet associations” and click on “Edit subnet associations”

12) Select the subnets that you would like to make public subnet and click on “Save associations”

Let’s take a step back and summarize what we have done till now. First we created our VPC then we deployed subnets to multiple Availability Zones. Later we created an internet gateway and attached it to our VPC. Next we created a public route table and defined route for our internet gateway and associated our subnets that need internet access to the public route table.

Next we will look at Security Groups and NACLs before we deploy an EC2 server to the subnet.

AWS Firewall — Security Group and NACLs

Security Group and Network Access Control List (NACL) are two built in firewalls in AWS which ensures that the traffic is allowed or denied based on the rules configured. An understanding of these are critical in ensuring that your network is not exposing its resources to malicious attacks.

Network Access Control List (NACL) controls the traffic flow at subnet level whereas are Security Group controls the traffic at EC2 (Elastic Compute Cloud) level.

Security Group

Let’s first look into some of the details for Security Group. As mentioned earlier, Security Groups defines a set of rules that can filter traffic flowing to your EC2 instance. When communication happens between two systems (example: client/server communication or server/server communication), it uses a protocol and a port for the communication. When defining rules for security group, you provide the protocol, port range and the source/destination of the request that must be allowed.

If we look at the simple example above, Server 1 is sending an inbound request to Server 2 using TCP protocol on port 8060. Hence, if these servers are in AWS and we need to allow this request via security group inbound rules, it will look like below

The security group with the above inbound rule will then be associated to Server 2 so that it can allow inbound request from Server 1. What about the response from Server 2 back to Server 1? The response back to Server 1 will be allowed by default and we need not configure an outbound rule for it. The reason is that Security Groups are stateful in nature. This means that if the inbound request is allowed in, the response or the outbound request is always allowed out. The reverse is also true, which means if the outbound is allowed the inbound is also allowed.

Some other important points to understand about security groups are:

1. A security group can be associated with multiple EC2 instances (it actually gets associated with the network interface of the EC2 instance but lets keep things simple here)
2. A default security group is created by AWS whenever we create a VPC and it is associated to the VPC. The default security group cannot be deleted but you have the option to not associate it with any EC2 instance. The default security group allows all outbound traffic.
3. You can and should create your own custom security group and define inbound and outbound rules. You can only define ALLOW rules but not the DENY rules. Any traffic that is not allowed is implicitly denied.

Hands on Example — Creating a Security Group

1) Select the VPC console, and on left navigation under “Network & Security” select “Security Groups”

2) Click on “Create security group” button

3) Add the name and description and select the VPC to which the security group should be attached as shown below

4) Add rules for Inbound Access as required by Security Group.

Note:

• In the above we have added inbound rule for allowing access to SSH connection and HTTPS connection. Security Group provides many different options to add different types of rule for TCP, UDP and ICMP protocols
• The security groups must be created and vetted careful as this is your last line of defense before traffic reaches your EC2 servers. If we talk about three tier web application architecture, typically you will have security group for each layer — public load balancer, web server, app server and database server.
• While specifying the Source in the inbound rules or Destination in the outbound rules, apart from adding CIDR IP, you can also add a security group. This is useful when you are creating security groups for your application architecture where you may want to allow inbound traffic on your app server only from your web server security group.

5) Add rules for Outbound Access as required by Security Group

The above is the default Outbound rule which allows all traffic outbound from this security group. This can also be restricted similar to Inbound rules.

6) Click on “Create security group” button

Network Access Control List (NACL)

Network Access Control List is the firewall that can be applied at a subnet level and any traffic flowing in or out of the subnet will be governed by the NACL rules defined.

NACLs have explicit allow and deny rules and unlike security group which are stateful in nature, NACL rules are stateless, which means that if an inbound rule is allowed in, the outbound response is not allowed out by default, unless we configure an allow rule for outbound.

NACL rules are numbered and are evaluated in the order in which they are defined. Below is a sample table the defines inbound and outbound rule

In the above table, the inbound rules and outbound rules looks exactly the same. As discussed before, NACLs are stateless and for any request inbound for which outbound response is not explicitly allowed, it will be denied. The rules are numbered here and you can use your own numbering convention but it is advisable that you space out your rule numbering to ensure flexibility in future.

The rules are evaluated from the starting rule for both inbound and outbound and the evaluation stops at the first match and no further rules are analyzed. Hence, one needs to be careful in defining the rules and ensure that they are evaluated correctly. Take an example of inbound rules below

Rule 110 denies RDP connection from any IP address and rule 120 allows the RDP connection from 172.18.54.120/32. Since rule 110 will be evaluated and matched first, rule 120 will never be evaluated and hence the RDP connection from 172.18.54.120/32 will always be denied.

Security groups are must have when we setup our network infrastructure in AWS, however, NACLs may not be always needed. If you have configured and tested your security groups you may not feel the need to configure NACL. However, think of NACLs as the main gate to enter a premise and security group as individual gates for each building in the premise. If the access is denied from the main gate, you secure all the buildings in one go. In case of a security attack, you can deny access via NACL and all the subnets which are associated with the NACL will be protected.

Some other important points to understand about NACLs are

1. Each VPC is assigned a default NACL which is created by AWS when you create the VPC. The default NACL allows all inbound and outbound traffic.
2. One or more subnets can be assigned to a single NACL but one subnet can be associated with only one NACL
3. Unlike security group where you can only specify allow rules and any rule that is not allowed is implicitly denied, rules in NACL have to be explicitly allowed or denied.

EPHEMERAL PORTS

If you closely look at the NACL table configuration above, you would find a range of ports (32768–61000) that we allowed for inbound rules and outbound rules. These are called ephemeral ports. To better understand ephemeral ports, lets take an example of client/server communication as shown below

In above example, when Client sends a request to Server, the port is well defined (in this case 443). Hence when creating NACL rules we can whitelist that port for communication. However, when the response for the request is send from Server to Client, the Operating System has the liberty to choose a random port on which it can respond. For example, many Linux server use random ports between 32768–61000 and many Window server operating systems uses 1024–65535 range. These random ports are called Ephemeral ports.

Note: You can refer to following Wikipedia article for more information

Ephemeral port - Wikipedia

Why Ephemeral port configuration is important for NACLs? Well, as we know by now that NACLs are stateless which means inbound rules and outbound rules are independent of each other. Hence, in above example, if we want to allow response back from server to client we need to whitelist the range of ephemeral ports. This is not an issue on Security Group since Security Groups are stateful and hence if any inbound request is allowed, the corresponding response is always allowed on the outbound.

Hands on Example — Creating a NACL

1. Select the VPC console, and on left navigation under “Network & Security” select “Network ACLs”

2) Click on “Create network ACL” button

3) Enter the name of NACL and the VPC to which it should be attached and click on “Create network ACL”

4) Select the newly created NACL from the list and in the settings window, select “Inbound rules”

5) Click on “Edit inbound rules” button and then click on “Add new rule” button

6) Add the new rules as desired as click on “Save changes”

7) Go to “Outbound rules” tab and click on “Edit outbound rules” button

8) Click on “Add new rule” and add the desired rules

9) Click on “Save changes” button

10) Go to “Subnet associations” tab and select “Edit subnet associations”

11) Select the subnet to which the NACL should be associated to and click on “Save changes”

EC2 Instance

Any discussion on AWS networking cannot be complete without discussing on Elastic Compute Cloud (EC2). In almost all the infrastructure setup that you do in AWS, you will find yourself ordering EC2 instances.

Simply put EC2 instances are your servers on the cloud infrastructure. However, there is a lot more to EC2 instances and to do any justice in an attempt to understand it deserves a separate discussion. When working with enterprise networks, you need to understand many variables of EC2 instances such as the type of instances needed, the pricing strategy (reserved/on-demand/spot), Storage options, Auto-recovery options etc. In this post, we will only touch upon the very basics of EC2 instance and will have a separate post to discuss it in more details.

Amazon Machine Images

Any EC2 instance launched in AWS is created from an image called Amazon Machine Image (AMI). Think of image as a snapshot of your server that has Operating System, all the required softwares, and configuration settings for your server, all packaged into one template. You can take this image and launch multiple instances and all these instance will be exact replica of each other.

You can navigate to AMI catalog by selecting “AMI Catalog” under “Images” in EC2 console as shown below

You can use AWS provided machine images if you are getting started (there are 46 different AMI configurations at the time of writing this post) or you can select it from AWS Marketplace or create your own image. There are Community AMIs also on offering which can be published by anyone. AWS Marketplace has a catalog of 6000+ images from various publishers and it is likely that one of them would meet your need. For example, if I need to launch my EC2 instance with NGINX server, I can go to Marketplace and select NGINX image

EC2 Instance Types

There are over 400 instance types on offer in AWS and Amazon keeps adding new instance types as needed. Each instance type is defined by the amount of available RAM, number of virtual CPUs (vCPUs), the type and amount of instance storage available and the network performance the instance will be able to deliver. Below is an example of m5.xlarge vs m5.2xlarge for reference

At a high level, these instance types are divided in the following 5 instance families

• General Purpose — As the name suggests, the instances belonging to these families are for general purpose use and provide baseline CPU processing, storage and network performance. If you do not have any special needs to run your workload, you should start with General Purpose instance family. You can use general purpose instance to start with your development and testing needs and if you find yourself in a need for more specialised instance you can upgrade to other instance family.

Note: General Purpose also covers burstable instances (T2, T3 and T4) that can burst into higher performance threshold given you have enough credits available. If you want to learn more about burstable instance, refer to the following

Key concepts and definitions for burstable performance instances

• Compute Optimised — Instances belonging to this family are suited for workloads that are CPU intensive such as high performance server, batch processing and High Performance Computing (HPC).
• Memory Optimised — Memory optimised instances are tuned for large datasets that needs fast in-memory processing such as Memcached and Redis Cache. Instances from this family are also useful for high performance databases such as MySQL or NoSQL databases.
• Storage Optimised — If you have a workload that needs high sequential reads/writes on local storage, you should use storage optimised instances. Storage optimised instances deliver high IOPS (Input/Output operations per second) and are useful for relational database, data warehousing and distributed file processing
• Accelerating Computing (GPU optimised) — Accelerated computing instances use hardware accelerators or co-processors to perform functions, such as floating point number calculations, graphics processing, or data pattern matching, more efficiently than is possible in software running on CPUs. Ideal for machine learning, image processing and natural language processing applications these instances deliver low cost to train complex machine learning models

Note: For more information on instance families and the instance types, please refer to following

Instance Type Explorer - Amazon Web Services

Instance naming convention

Every instance in AWS follows a naming convention as shown below

M5A.2xlarge

If we break down the naming convention it represents the following

• Instance family — The first character in the name represents instance family. In the above example, M represents the general purpose instance.
• Instance generation — The number next to instance family is the instance generation. There can be multiple generations of same instance type. For example T4 is a newer generation than T3 which in turn in newer than T2. Note that many times newer generations provide better performance and may also cost less than older generation instances.
• Feature — Feature is present only in some instance type names. In the above example, “A” is a special feature of the instance. It denotes an AMD processor, similarly you can find instances such as t4g.large where “g” represents Graviton2 processor.
• Instance Size — Instance size is the relative size of the instance from the baseline configuration. You may think of it as T-shirt sizing where you have representation of L, XL and XXL. So when we have an instance which is 2xlarge, it means that the instance has twice as much resources when compared to an xlarge instance. Below is the configuration of m5.xlarge and m5.2xlarge for reference

Hands on Example — Launching an EC2 instance

1. Navigate to EC2 console and on the left hand menu select “Instances” under “Instances” header and click on “Launch Instances”

2) Provide the name to EC2 instance and select the AMI for the EC2 instance

3) Select the instance type that you want to launch

Note: If you are on free tier, look at free tier eligible AMI and instance type. Selecting these would provide you 750 hours per month of compute time without any charges.

4) If you already have a key pair, select the key pair or create a new key pair by selecting “Create new key pair”

Note: Key pair is used to login to your EC2 instance once it is launched. You should secure your key pair once it is generated and downloaded.

If you click on “Create new key pair”, provide a key pair name, key pair type and private key file format and click on “Create key pair” button

Note: Once you create your key pair, AWS will prompt you to download the key pair. You must download the key pair and secure it as this is the only time you can download the key pair. If you misplace your key pair, you don’t have an opportunity to download it again from AWS.

4) Under “Network Settings” tab click on Edit and select the desired VPC in which the instance will be launched along with any subnet preference where it will be placed. Note that if you are launching an EC2 instance which should be publicly accessible over the internet you should select a public subnet (if you recollect our discussion on subnets, a public subnet is one which has internet gateway associated with the subnet’s route table).

The next setting “Auto-assign public IP address” can be enabled if you want AWS to automatically assign an IP address which is publicly accessible. If you are creating a private EC2 instance, you must keep this disabled.

5) You need to select a security group for your instance. The launch wizard provides you the option of creating one if you don’t already have it

6) Next, you can configure the storage options needed for your EC2 instance.

You can add EBS (Elastic Block Storage) volume if needed by selecting “Add new volume” button and selecting the memory requirements. EBS volumes are block storage services from AWS that reside outside the EC2 instance. You can persist data in EBS even if you terminate the EC2 instance and can attach it to another EC2 instance if needed.

7) Under the Summary tab, select the number of instances that you would want to launch with this EC2 configuration and click on “Launch Instance” button

8) You can now return to your instances and you would find that the instance has been provisioned successfully.

Connecting to the instance

If you are connecting to Windows EC2 server, you can RDP into it and if it is Linux server, you can use SSH to connect to it. However, you need to ensure that your Security Group has an inbound rule that allows SSH/RDP from your IP address. To understand various ways in which you can connect to your newly launched EC2 instance, select the EC2 instance and on the top select Connect from “Actions” dropdown

Terminating the Instance

Remember that the cost you incur on Cloud is directly proportionate to the amount of resource that you use on cloud. You need to always looks at your cloud design, workloads that running on the cloud, your monitoring services such as Cloudwatch, server sizing and budget vs cost to ensure that you are optimally using cloud resources.

If you have launched on-demand EC2 instance (the one we launched in above hands-on exercise) and you are not using it, you will still be charged for it. It is recommended that you terminate the instance once you no more need it. To terminate the instance, select the instance that you want to terminate from EC2 console, on the top go to “Instance State” drop down and select “Terminate instance”.

On the subsequent confirmation screen click “Terminate”

Conclusion

We have come a long way and have discussed many important aspects of AWS infrastructure. If we go back to our reference architecture, you should be able to understand many of the networking components present in there. Although this has been a long post, we have barely scratched the surface of networking in AWS. In next next part of this series, I plan to cover EC2 in more details along with some essential related services. Until then, thank you for your time and happy learning!