Being able to architect your own isolated segment of AWS is a simple process using VPCs; understanding how to architect its related networking components and connectivity architecture is key to making it a powerful service.
Many services within Amazon Web Services (AWS) require you to create and configure a VPC to provision and distribute your resources. Using the AWS global infrastructure, you can architect high availability and resilience into your deployment using availability zones and regions. For more information on the AWS global infrastructure, click the previous link and read my blog about availability zones, regions, edge locations, and regional edge caches.
When designing your VPC to isolate your resources, you need to ask yourself a number of questions to help with the architectural decisions that are related to VPC design. These might include:
All of these questions are important factors when creating your VPC. To help answer them, you need to be aware of some AWS services and components that relate to VPC management, control, and operation.
An internet gateway (IGW) is an AWS-managed component that is attached to your VPC. This provides a connection between your isolated VPC and the outside world, essentially the internet. When an IGW is attached to your VPC, subnets can set a route to the IGW for traffic residing outside of the VPC. Subnets with this configured route are defined as public subnets.
A VPC subnet allows you to segment your VPC CIDR block into smaller network segments across multiple availability zones with your VPC region. This then helps you to isolate, organize, and manage your resources in addition to helping you implement resilience and high availability.
Within your VPC, you can create multiple route tables. These enable you to configure where and how to route your network traffic based on its destination via different targets, such as internet gateways, network address translation (NAT) gateways, or customer gateways.
NACLs act as a logical firewall that provide network level security, operating at the subnet layer. They provide a stateless rulebase, allowing you to stipulate both the ingress and egress traffic based on protocols that allow or deny access in or out of the subnet.
Much like NACLs, security groups are also like a firewall; however, these operate at the instance layer, providing a level of protection to instances residing within your subnets based on defined protocols. Security groups are stateful by design and rules within the rulebase are considered “allowed” — security groups do not offer a “deny” function like NACLs do.
NAT gateways are managed services that allow instances located within a private subnet to access the internet, enabling them to download and perform patch updates and maintenance. NAT gateways prevent inbound connections that are initiated from the internet, helping to protect private resources.
A bastion host is a secure, hardened instance that resides within the public subnet of your VPC. It has very restrictive security controls, allowing restricted inbound connections from known and trusted IP addresses — usually using SSH or RDP protocols. These security controls allow engineers to perform a remote and secure connection to the Bastion Host where the instance acts as a “jump server” allowing the engineers to SSH or RDP to instances residing within private subnets.
A virtual private network (VPN) connection allows two remote networks to securely connect to each other across the internet. You could use a VPN connection to allow your remote office or data center to connect to your VPC allowing traffic to move between both networks.
A direct connect (DC) connection also allows you to connect your VPC to your remote office/data center. This connection is established across a secure, dedicated infrastructure rather than the internet. A connection is established to a direct connection location usually managed by an AWS partner using dedicated infrastructure. From here, the connection is made to the AWS network, allowing a secure and private connection to your VPC.
VPC peering allows you to connect two VPCs together using the internal AWS infrastructure as if they were on the same network. There are some key points to bear in mind. Mainly, the two VPCs are not allowed to have overlapping CIDR blocks. VPC peering provides a one-to-one connection only and does not allow transitive peering to a third VPC.
For example, if you had three VPCs connected (VPC1 connected to VPC2 and VPC2 connected to VPC3), then VPC1 will not be able to talk to VPC3. You would have to either set up another peering connection from VPC1 to VPC3 or implement the AWS Transit Gateway.
AWS transit gateway (TGW) allow you to perform a one-to-many relationship with your VPCs in addition to your remote networks as well. The TGW acts as a central hub within your network, allowing all VPCs, remote offices, and data center to connect to it. This configuration simplifies multiple peering connections and reduces overall connectivity from remote locations to your VPCs.
If you are new to AWS, then it’s important that you understand each of these components and the part they play within your architectural design of your VPC. To learn more about each of these components, you can take a look at our new course which will provide a deeper explanation of each via graphical explanations and designs allowing you to easily follow the concepts and principles of each.
If you’re interested to learn how to architect a VPC across multiple availability zones within a Region, how to secure your VPCs, and assess which method of connectivity to your VPCs is more appropriate for your organization, enroll on the Working with AWS Networking and Amazon VPC Course. I’ve built this whole course through the experience of a drawing pad.
To have a taste of what the course experience is like, watch this video on NAT Gateways.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…