AWS Networking
AWS Networking
Introduction to Amazon VPC
The world of cloud computing often involves creating and managing secure environments where applications and resources can operate without outside interference. In Amazon Web Services (AWS), one such environment is known as a Virtual Private Cloud (VPC). Just imagine a VPC as a private piece of property within the cloud that is fully fenced off from everyone else, protecting everything inside.
When setting up a VPC, there are two main factors to consider. The first is the region, which refers to the geographical location where you want your VPC to exist. For example, if you are operating primarily on the west coast of the United States, you might choose the Oregon region.
The second factor is the IP range, also known as CIDR notation. This determines the number of IP addresses your VPC can accommodate. For instance, an IP range of 10.1.0.0/16 allows for over 65,000 unique IP addresses, providing ample room for your applications and resources.
Creating a VPC is like building a large, empty house. The next step is to create ‘rooms’ within it, technically referred to as subnets. A subnet is a smaller segment within a VPC, where resources such as EC2 instances (virtual machines in AWS) can be placed.
Subnets offer a strategic advantage as they allow for different access rules in different areas. Suppose you have public-facing resources, like a website. You could house these in one subnet designed for internet accessibility. Conversely, if you have private resources, like a database, these could reside in a separate subnet with restricted access controls.
To set up a subnet, you’ll need to specify which VPC it will belong to, the availability zone (essentially a server location within the chosen region), and a subset of the VPC’s IP range.
Furthermore, in order for resources in the VPC to access the internet, an Internet Gateway is required. This is akin to a modem in your home that connects your devices to the internet. To function, this gateway must be attached to the VPC.
For scenarios where you have internal resources that only need to be accessed from your local network, such as from your office or a private data centre, AWS provides the option of a Virtual Private Gateway (VGW). This allows you to establish a secure, encrypted connection from your local network to your resources on AWS.
Finally, it’s essential to consider the concept of “high availability” for the longevity and reliability of your services. The principle is to ensure that your services remain operative even if part of your infrastructure experiences a failure. To implement this, it is recommended to duplicate your resources across two or more availability zones. That way, should one zone experience a problem, your services can continue to operate from the other zone.
In conclusion, when working with AWS or similar cloud platforms, it’s crucial to understand the purpose and setup of a VPC, including creating and managing subnets, utilising an Internet Gateway for public access, and distributing resources across multiple availability zones for high availability. You should also be aware of options like a Virtual Private Gateway for secure, private access to cloud resources.
Reserved IPs
In Amazon Web Services (AWS), the concept of Reserved IPs is important to comprehend when working with Virtual Private Clouds (VPCs) and subnets. This refers to a small set of IP addresses that AWS reserves in each subnet for its own use to ensure the network operates efficiently. These IP addresses are essential for internal networking purposes such as routing, Domain Name System (DNS) services, and network management.
When creating a subnet within a VPC, it’s crucial to note that not all the IP addresses within the CIDR block you specify for the subnet will be available for your use. AWS reserves the first four IP addresses and the last IP address in every subnet CIDR block. Therefore, a subnet with a CIDR block of /24, which technically comprises 256 IP addresses, will effectively have only 251 usable IP addresses.
Let’s break this down with an example. Suppose you have a VPC with the IP range 10.0.0.0/22. This VPC includes 1,024 total IP addresses. If this is divided into four equal-sized subnets, each with a /24 IP range, then each subnet would have 256 IP addresses. However, because AWS reserves five IP addresses in each subnet, there are actually only 251 usable IP addresses in each subnet.
Understanding this reservation of IP addresses by AWS is important when designing your network, especially when considering the size of your subnets. This is particularly relevant if you anticipate needing a large number of IP addresses. For beginners, a typical strategy is to create a VPC with an IP range of /16 (providing up to 65,536 IP addresses) and then create subnets within that VPC with an IP range of /24. This gives a plentiful supply of IP addresses both at the VPC level and within each subnet.
Overall, while these Reserved IPs are necessary for the proper functioning of your network within AWS, it’s important to factor them into your calculations when planning your network to ensure you have an adequate number of IP addresses for your needs.
Amazon VPC Routing
Our system is hosted on an Amazon Virtual Private Cloud (VPC), equipped with an internet gateway and four subnets, two of which are public and two are private. These subnets are distributed across two availability zones to ensure high availability and failover support.
An EC2 instance hosting our employee directory is placed in a public subnet in the first availability zone. The question now is how to make this EC2 instance accessible to external internet traffic.
An internet gateway is linked to the VPC, but it isn’t sufficient to direct incoming traffic to the right subnet. This is where route tables come in.
A route table is a set of rules to determine where network traffic from a subnet or a gateway should go. By default, a new VPC comes with a main route table that allows traffic to flow freely between all subnets within the VPC.
However, to control inbound and outbound traffic from the internet, we need custom route tables. For our public subnets, we create a custom route table that includes a rule directing traffic from and to the internet gateway. This route table is then associated with the public subnet, thus allowing traffic to and from our EC2 instance.
For our private subnets, we create another custom route table, this one without a rule directing traffic to the internet gateway. This route table is associated with our private subnets, thereby isolating them from direct internet access.
As a result, our setup now consists of a VPC, an internet gateway, four subnets across two availability zones, and custom route tables that control traffic. The public subnets can communicate with the internet, while the private subnets are limited to local traffic within the VPC as defined by the main route table.
Secure your Network with Amazon VPC Security
Network Access Control Lists (Network ACLs) and Security Groups are two types of firewall mechanisms in AWS that allow you to manage inbound and outbound traffic to your Amazon VPC resources.
Network Access Control Lists (Network ACLs)
A Network ACL is a type of firewall that controls traffic to and from one or more subnets within your VPC. It is considered to operate at the subnet level, providing a layer of security that acts as a gatekeeper for all the traffic going in and out of the subnets it’s associated with.
A Network ACL contains a numbered list of rules that AWS evaluates in order, starting from the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL. By default, a Network ACL allows all inbound and outbound traffic.
the lower the number, the higher its priority
An important point to note about Network ACLs is that they are stateless, meaning they evaluate each incoming and outgoing packet only in the context of the rule set for the network ACL. It doesn’t matter if a request was initiated from within the network or if it is a reply to a request that was originally sent out from the network. Each packet is evaluated independently.
Security Groups
In contrast, Security Groups act as a firewall at the instance level. This means that each rule you add to a security group applies to the entire group, which could consist of multiple instances. Unlike Network ACLs, Security Groups are stateful. This means that if you send a request from your instance, the response traffic for that request is automatically allowed to flow in regardless of inbound security group rules. Similarly, if a client outside your VPC sends a request to your instance, and this request is allowed by your inbound rules, the response traffic for that request is automatically allowed to flow out, regardless of outbound rules.
By default, Security Groups deny all inbound traffic, and allow all outbound traffic. The security group rules that you add define what inbound traffic is allowed to reach the instances that are associated with the security group and what outbound traffic is allowed to leave them.
Stateless vs. Stateful:
The terms stateless and stateful refer to the ability of a firewall to “remember” or “forget” information about a network connection. In a stateful firewall like security groups, the firewall maintains information about the state of a connection between an internal and an external host. It automatically allows return traffic for outbound requests that originated from inside the network.
In contrast, a stateless firewall like network ACLs treats each network packet in isolation without regard to any other related packets or the state of the connection. This means that for each direction of communication, you must explicitly allow traffic in each direction.
In a well-secured AWS environment, both Network ACLs and Security Groups should be carefully configured to provide layered security. While Network ACLs provide a first layer of defense against unwanted traffic into the subnets, Security Groups provide a more granular level of security at the instance level.
Hybrid Connectivity with AWS
AWS Virtual Private Network (AWS VPN)
This is a service that enables you to establish a secure and private tunnel from your network or device to the AWS global network. It’s a common and popular way to securely connect your remote network to AWS. AWS VPN consists of two different services: AWS Site-to-Site VPN and AWS Client VPN.
AWS Site-to-Site VPN:
This service allows you to connect your on-premises or remote network to your Amazon VPC. It essentially extends your data center or network across a VPN connection, creating a “hybrid” environment that includes both your on-premises data center and AWS.
AWS Client VPN:
This is a managed client-based VPN service that enables you to securely access your AWS resources or your home or corporate network from anywhere. It’s used for connecting individual users (like administrators or remote employees) to AWS or to your on-premises data center.
AWS Direct Connect:
This service provides a dedicated private connection from a remote network to your Amazon VPC. Unlike a VPN, which uses the public internet for the connection, AWS Direct Connect uses a private network connection between the remote network and the AWS VPC. This means you can have a more consistent network experience with better bandwidth and network performance compared to Internet-based connections.
In a nutshell, AWS provides several ways to connect your on-premises or remote network to AWS, including VPN and Direct Connect. The best choice depends on your specific needs, including the amount of data you plan to transfer, the network performance you require, and your budget. In some cases, you may use both VPN and Direct Connect, using VPN as a failover for Direct Connect for higher reliability.
Difference between AWS VPN and AWS Cirect Connect
AWS VPN is a secure and easy-to-setup service that allows you to connect your on-premises network to AWS over the public internet, but it might have variable speed and occasional slowdowns.
AWS Direct Connect is a more robust and consistent connection that bypasses the public internet, offering better performance and reliability, but it could be more complex to set up and may cost more.
Virtual Private Gateway
In AWS, a virtual private gateway (VGW) is essentially the anchor on the AWS side of the connection between your Amazon Virtual Private Cloud (VPC) and your own on-premises network, or another network. You can think of it as a router that connects your VPC to the outside world, specifically to your own network. It helps to enable a hybrid cloud architecture, which is an IT architecture that incorporates both cloud and on-premises resources.
Here are a few key points:
1. Purpose:
The VGW provides a path for the traffic to flow between the AWS VPC and your on-premises network or another network. The VGW is attached to the VPC and serves as the gateway for all communication coming in or going out of the VPC to your own network.
2. VPN and Direct Connect:
VGW is commonly used in conjunction with the AWS VPN or AWS Direct Connect. AWS VPN establishes a secure and private tunnel from an on-premises network to your Amazon VPC. The VGW is the point at which the VPN connection attaches to the Amazon side of the VPN tunnel. AWS Direct Connect, on the other hand, bypasses the public Internet and establishes a secure, dedicated connection from your on-premises network to AWS. Again, the VGW serves as the endpoint on the AWS side for this Direct Connect connection.
3. Stateful Inspection:
VGW supports stateful inspection of packets, meaning it keeps track of all network connections between your VPC and your on-premises network. This allows return traffic from AWS to be allowed back to the sender without the need to add inbound rules.
4. Redundancy and Failover:
VGW is designed for redundancy and high availability within an AWS Region. If you establish multiple VPN connections or Direct Connect connections, the VGW can handle automatic failover if one connection goes down.
5. Route Propagation:
VGW can propagate routes to the main route table of your VPC or to any custom route tables that you might have, allowing for dynamic updates of network routes as they change.
In summary, a Virtual Private Gateway is a critical part of your VPC setup if you’re planning on a hybrid cloud deployment with AWS. It provides the necessary bridge between your on-premises network (or other network) and your AWS VPC, allowing for secure and efficient data transmission.