Overview

In our earlier article, Networking 101 - Part 1 you gained insight into the basics of networking. You learned about the various roles devices can play in a network, how networks are structured, and the fundamentals of network types and connections. Understanding these concepts is essential for grasping how networks operate in the cloud. If you haven't read the previous article, I recommend doing so before continuing. Otherwise, feel free to keep reading.

In AWS, the concept of networking is more refined and advanced. You can establish a private network in the cloud, configuring all your nodes as AWS services and resources. This private network is known as a VPC, or Virtual Private Cloud.

A VPC shares the attributes of a traditional network but adds the benefit of being logically isolated from other VPCs. Essentially, a dedicated virtual network is created for your AWS resources within your AWS account, providing a private environment. In AWS, we use a VPC to manage our network in the cloud.

---

VPC Architecture

Amazon VPC is a service that is specific to a particular AWS Region. This means you need to specify the AWS Region where you want to create it. A VPC cannot span multiple Regions; it can only exist in a single Region. Therefore, you cannot have the same VPC across Regions; this is not allowed.

However, within each Region, there are multiple Availability Zones. You can place your subnets in these Availability Zones within your Region. This allows you to distribute your resources across different Availability Zones, which is crucial for achieving high availability.

By placing your subnets in multiple Availability Zones, you can launch AWS resources such as EC2 instances, RDS databases, and ElasticCache instances in a way that follows best practices and recommendations.

While you can create multiple subnets in a single Availability Zone, it is not recommended if you want to achieve high availability. It's important to note that just as a VPC cannot span multiple Regions, a subnet cannot span multiple Availability Zones. Each subnet is specific to a single Availability Zone, so you cannot create subnets that span different Availability Zones.

💡 An Availability Zone (AZ) is a distinct location within an AWS Region, designed to be isolated from failures in other Availability Zones, providing high availability and fault tolerance for AWS resources.

When you create your AWS account, AWS automatically provides you with a default VPC in each AWS region available in your account. This default VPC includes a public subnet with internet access in every Availability Zone within the region.

This setup is designed to simplify the process of launching services such as EC2 instances, allowing you to start quickly without the need to set up a VPC from scratch. It's particularly useful for quickly launching public instances.

While AWS allows you to modify or configure the default VPC, it's generally not recommended. Instead, it's advisable to create a new customized VPC for your networking needs. AWS permits you to have a total of five VPCs per region, which means you can create up to four additional VPCs in addition to the default one.

💡 If you need more than five VPCs in a region, you can request an increase in the VPC quota by submitting a ticket.

The diagram illustrates the structure of a cloud network within a single region, featuring the optimal utilization of the available VPC (Virtual Private Cloud) quota by incorporating five separate VPCs. Each VPC is configured across three Availability Zones, indicating the infrastructure's readiness for high availability and fault tolerance

---

VPC components

The diagram provides a clear representation of a network topology within a cloud infrastructure, delineating the configuration of subnets within a single VPC across multiple Availability Zones in one region. It illustrates a typical arrangement with both public and private subnets in each Availability Zone, which is a common practice for structuring cloud networks to support various workloads, ensuring both accessibility and security. This layout is foundational for designing a highly available and secure cloud environment.

VPC CIDR Blocks

When creating a VPC, you must specify an** IPv4 CIDR block**, which is necessary to define the size of the network and allocate IP addresses to each node within the VPC. The CIDR block size determines the number of IP addresses available, so it's crucial to ensure it's large enough to accommodate all required addresses.

In AWS, the maximum CIDR block size is 16, providing up to 65,546 IP addresses, while the smallest is 28, yielding 16 IP addresses. It's important to note that subnets within a VPC cannot have overlapping CIDR blocks, as discussed in the previous article.

Each VPC in your AWS account should have a unique CIDR block to avoid conflicts. As previously mentioned, AWS permits the creation of up to five VPCs per region, each with its unique CIDR block. For example:

• VPC-1 (10.0.0.0/16) ⇒ Default
• VPC-2 (10.1.0.0/16)
• VPC-3 (10.2.0.0/16)
• VPC-4 (10.3.0.0/16)
• VPC-5 (10.4.0.0/16)

By ensuring each VPC has a unique CIDR block, you prevent IP address conflicts between VPCs within your AWS account.

---

VPC Identifier and Labels

When you create a VPC, it is automatically assigned a unique identifier known as the VPC ID. This ID is a string of alphanumeric characters that serves as the VPC's identifier within your AWS Region. The VPC ID is important because it is used to associate other components of the VPC, such as subnets, network gateways, and route tables.

For example, if we consider the five VPCs from the previous example, each VPC would have a unique VPC ID similar to the following:

• VPC-1 (vpc-0476e890abedg995f) ⇒ Default
• VPC-2 (vpc-1589d721cdffg345e)
• VPC-3 (vpc-2365a891pqrs567c)
• VPC-4 (vpc-8542b987tuvw321x)
• VPC-5 (vpc-6023c654mnop123y)

Each VPC ID is unique and identifies a specific VPC within your AWS account and Region.

While VPC IDs are unique identifiers, they can be challenging to remember and search for. Tags offer a solution by allowing us to classify or group VPCs, providing a more manageable way to organize them. Tagging provides granularity, allowing us to associate identifiable names with VPCs and their components, such as subnets and route tables.

When tagging, the tag name appears after the VPC ID in parentheses, making it easier to identify the VPC. Each component of the VPC can be tagged with an identifiable name. This not only helps in identifying the correct VPC but also provides a better way to manage and organize VPCs.

Here is how the tagged VPC IDs could look:

• vpc-0476e890abedg995f (Prod)
• vpc-1589d721cdffg345e (Dev)
• vpc-2365a891pqrs567c (Test)
• vpc-8542b987tuvw321x (Staging)
• vpc-6023c654mnop123y (Demo)

In this example, each VPC is tagged with a different category (Prod, Dev, Test, Staging, Demo) to indicate its purpose or environment, making it easier to identify and manage them.

---

Subnets

In the cloud, subnets function similarly to on-premises networks, providing smaller network segments within a VPC where you can deploy your AWS resources. Subnets that are designed to route traffic to and from the internet are known as public subnets. In contrast, subnets that do not allow internet access are called private subnets, accessible only from within the VPC.

Public and private subnets serve different purposes. For example, if you want your website to be accessible only to company employees and not the general public, you would use a private subnet. However, since private subnets do not have direct internet access, you would need to establish a Virtual Private Network (VPN) to bridge the connection and enable access.

Another common use case is to keep the data and logic tiers private while making the presentation tier public. This setup allows you to control access to sensitive data and processes while still providing a public-facing interface. In a VPC, you can have all public subnets, all private subnets, or a mix of both, depending on your specific use case and requirements.

💡 To access your private subnets over the internet, you will need to use a Virtual Private Network (VPN).

To ensure high availability and fault tolerance in your network, it is recommended to create your public and private subnets in at least two different Availability Zones.

In a previous article, you learned how to calculate the range of IP addresses per subnet and that certain IP addresses are reserved. For example, AWS reserves five IP addresses within each subnet CIDR block:

1. First IP ⇒ Network address
2. Second IP ⇒ VPC local router for internal communication
3. Third IP ⇒ DNS resolution
4. Fourth IP ⇒ Future use
5. Last IP ⇒ Network Broadcast Address

It is also advisable to create larger subnets rather than smaller ones. This approach simplifies workload placement because every node on your network requires an IP address. If you run out of available IP addresses, you won't be able to add more to that subnet.

When creating a subnet, you must choose the VPC ID to which you want to associate that subnet. This action attaches the subnet to the VPC. Once attached, you cannot detach a subnet from a VPC. Just as VPCs have unique IDs, subnets are also associated with unique IDs called Subnet IDs. You will use these Subnet IDs to attach AWS resources to the subnet.

Example

If you want to create a highly available and fault-tolerant application with three tiers (Presentation, Logic, Data) in each subnet, across all five availability zones in the Virginia region, you will need to calculate the total number of subnets required.

For each tier, you will need one subnet, totaling three subnets. Since there are five availability zones, you will need three subnets per availability zone, resulting in a total of 3 * 5 = 15 subnets.

To ensure each subnet has enough IP addresses for all nodes, you can use a CIDR block. For example, if you use a CIDR block of /16 for your VPC, you have a total of 65,536 IP addresses. Dividing this by 15 subnets, each subnet would have approximately 4,369 IP addresses.

However, if you use a CIDR block of /24 instead, you would only have 256 IP addresses per subnet. This means that for your 15 subnets, each subnet would only have 17 IP addresses, which might not be sufficient depending on your requirements.

💡 The number of subnets you can create in your VPC depends on the size of the IP CIDR block you assign to your VPC.

---

Network Gateways

Another crucial component in a VPC is the network gateway, which plays a critical role in determining traffic access to your network. There are two types of network gateways used depending on the use case:

Internet Gateway

This is a horizontally scaled, redundant, and highly available VPC component that facilitates communication between your VPC and the internet. An Internet Gateway is attached to your VPC ID and has a one-to-one relationship, meaning you can't connect the same Internet Gateway to two VPCs. Therefore, each VPC should have its own Internet Gateway. Unlike subnets in a VPC, when you attach an Internet Gateway, you can detach it and associate it with another VPC.

---

Virtual Private Gateway

This gateway allows your VPC to connect privately to your on-premises site through a site-to-site VPN connection. The virtual private gateway acts as the VPN connector on the Amazon side of the site-to-site VPN connection. Similar to an Internet Gateway, you attach a Virtual Private Gateway to the VPC ID that you want to use for the site-to-site VPN connection.

💡 If you want to connect your on-premises resources to the AWS cloud, you will need to set up a site-to-site VPN connection.

Each network gateway created is assigned a unique ID. For example, an Internet Gateway follows the structure igw-xxxxx, where xxxxx represents numeric digits. For instance, an Internet Gateway ID might look like igw-34556.

---

Route Tables

Route tables in a VPC serve as the mechanism that directs traffic within the VPC. They function similar to a router and contain a set of rules, known as routes, that specify how network traffic should be directed from your subnet.

Each route in a * route table* specifies a destination and a target. The destination is the destination CIDR block to which you want traffic from your subnet to be sent. For example, you might want traffic from your subnet to be directed to a gateway or to other network interfaces or connections. The target is where you want the traffic for the destination to be sent.

For example, a route table might look like this:

Destination	Target
0.0.0.0/0	igw-34556
10.0.0.0/24	local

In this table, the destination 10.0.0.0/24 represents the CIDR block of the VPC itself, and the target local signifies that all subnets within the VPC can communicate with each other. The destination 0.0.0.0/0 represents all possible destinations (i.e., the internet), and the target igw-34556 indicates that traffic for this destination should be sent to the Internet Gateway associated with the VPC, enabling internet connectivity.

💡 A local route is always present and cannot be deleted.

It's important to note that each subnet in your VPC must be associated with a route table. You have the flexibility to create custom route tables and associate them with your subnets. Additionally, you can replace the main route table with your custom route table if desired. Route tables in a VPC follow a many-to-one rule, meaning many subnets can be associated with one route table. However, you cannot associate one subnet with more than one route table.

---

Security Components

In your VPC, you can manage network access and security using two key components: Security Groups (SGs) and Network Access Control Lists (Network ACLs). These components serve as security measures to control access to your VPC and ensure its safety.

Security Groups

Security Groups act as firewalls, allowing only authorized traffic and routing it to the permitted parts of your network. They operate at the instance level rather than the subnet level, meaning they apply to instances within your subnets. You can attach different sets of security groups to your instances in your VPC, and you can also attach the same security group to other instances, ensuring they all have the same security settings.

Essentially, a security group filters inbound and outbound traffic that is allowed to your instances.

When you create a security group, you define its rules, as security groups are composed of rules that control inbound and outbound traffic. When customizing a security group, you can specify allow rules, but not deny rules. If you don't specify an allow rule, traffic is considered denied by default. All rules are evaluated before a decision is made to allow traffic.

When creating your security group, you have two types of rules:

• Inbound rule: By default, a security group has no inbound rules, meaning all traffic originating from another host to your instance is denied. You must add inbound rules to allow specific traffic to reach your instance.
• Outbound rule: By default, a security group includes a predefined outbound rule that allows all outbound traffic. If you remove this rule and add your custom outbound rules, and if your security group doesn't have outbound rules, no outbound traffic from your instance is allowed. This can potentially block all communication from your instances, so caution is advised when modifying outbound rules.

Security groups use stateful rules, meaning that if you allow inbound traffic, the corresponding outbound response is automatically permitted, and vice versa. This ensures that traffic is tracked and handled appropriately in both directions.

💡 If you don't have an outbound rule in your security group, all outbound traffic will be denied by default, including responses to allowed inbound traffic.

When choosing and configuring your security group, it's important to adhere to the principle of least privilege. This means allowing inbound traffic only for specific ports and IPs in the necessary protocol. For example, if you need a security group for an RDS database like Aurora MySQL, you would identify the protocol (TCP), the type (MySQL/Aurora), the port range (3306 for MySQL databases), and the source (the IP allowed to access that port).

For inbound rules:

Type	Protocol	Port Range	Source
Aurora/MySQL	TCP	3306	10.0.0.0/24

Here, a CIDR block is used to allow a range of source IPs, in this case, all IP addresses in the VPC.

For outbound rules, you need to define the destination, protocol, and port range. If you know the expected response from your database, you can be specific. Otherwise, you can customize the destination to allow responses only for that destination. For example, you could allow responses to all CIDR blocks in the VPC (10.0.0.0/24).

💡 Security groups follow a many-to-many relationship, allowing you to associate multiple security groups with an instance. Additionally, you can use the same security group across multiple instances.

Network ACLS

Network ACLs act as another layer of firewall protection for your VPC, operating at the subnet level to control inbound and outbound traffic. Unlike Security Groups, which operate at the instance level, Network ACLs control traffic flow at the subnet level.

When you create a subnet, you must associate it with a Network ACL. If you don't explicitly associate a subnet with a Network ACL, it will be automatically associated with the default Network ACL. Network ACLs follow a many-to-one relationship, meaning you can associate the same Network ACL with multiple subnets, but you can't associate multiple Network ACLs with a single subnet.

Unlike Security Groups, Network ACLs are considered stateless. This means that when an inbound rule allows certain traffic into the subnet, it does not automatically allow an outbound response. You must define the Network ACL to allow the return traffic to pass out of the subnet. Therefore, when configuring Network ACLs, you need to specify which traffic is allowed for inbound and outbound rules.

💡 Network ACL rules can be used for various security approaches, such as setting up deny rules to block specific types of traffic or IP addresses. Another common use is to prevent traffic from leaving a subnet.

Network ACLs contain a numbered list of rules that are evaluated in order, starting with the lowest numbered rule. It's important to note that rule order matters. For example, if you have a rule that denies all traffic and it's placed first, all traffic will be denied, regardless of any subsequent allow rules. Therefore, the rules are applied sequentially, and traffic is allowed or denied based on the first rule that applies to that traffic.

By default, the default Network ACL allows all inbound and outbound traffic in your VPC. However, if you create a custom Network ACL, it denies all inbound and outbound traffic until you add rules. So, it's essential to create custom Network ACLs and add rules to allow necessary traffic, following the principle of least privilege to allow only necessary traffic and deny unnecessary traffic.

Here's an example of how Network ACL rules are evaluated:

Rule	Type	Protocol	Port Range	Source	Allow/Deny
10	SSH	TCP	22	192.0.4.46	Allow
20	SSH	TCP	22	192.0.4.0/24	Deny
30	HTTPS	TCP	443	0.0.0.0/0	Allow

The rules are evaluated in order. Rule 10 allows SSH traffic on port 22 from source IP 192.0.4.46. Rule 20 denies SSH traffic on port 22 from all IPs in the range 192.0.4.0/24, except for the one allowed by rule 10. Finally, rule 30 allows HTTPS traffic on port 443 from any source IP.

---

Summary

This article provides an introductory overview of Amazon VPC, focusing on networking within AWS. It explains VPC architecture, components like CIDR blocks, VPC IDs, and tags, and key security measures like Security Groups and Network ACLs. It also discusses the importance of subnetting, network gateways, and route tables in managing and securing your AWS network infrastructure.

As we continue to delve deeper into the world of networking in the upcoming articles of this series, we will explore more advanced topics and practical applications. Whether you're a beginner looking to get started in networking or someone with a keen interest in AWS and cloud technology, this series aims to provide you with the knowledge and tools to navigate the digital landscape with confidence.

🙏 If you found this article informative and helpful, please consider sharing it with your friends and colleagues who might also benefit from this knowledge. Your support through likes and shares is greatly appreciated and motivates to continue creating valuable content for our readers.