In this course, you'll gain a solid understanding of the key concepts for Domain Four of the AWS Solutions Architect Professional certification: Network Design.
By the end of this course, you'll have the tools and knowledge you need to successfully accomplish the following requirements for this domain, including:
- Demonstrate ability to design and implement networking features of AWS.
- Demonstrate ability to design and implement connectivity features of AWS.
This course is intended for students seeking to acquire the AWS Solutions Architect Professional certification. It is necessary to have acquired the Associate level of this certification. You should also have at least two years of real-world experience developing AWS architectures.
As stated previously, you will need to have completed the AWS Solutions Architect Associate certification, and we recommend reviewing the relevant learning path in order to be well-prepared for the material in this one.
This Course Includes
Expert-led instruction and exploration of important concepts.
Complete coverage of critical Domain Four concepts for the AWS Solutions Architect - Professional certification exam.
What You Will Learn
- Key network design concepts for AWS
- VPC peering and connectivity
- Other critical networking skills relevant for the AWS Solutions Architect Professional certification exam.
About the Author
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.
The Virtual Private Cloud is a core building block for designing highly available, fault tolerant environments. Since 2013 all accounts have a Virtual Private Cloud by default. Now the Virtual Private Cloud or VPC is a logically isolated section of the AWS Cloud dedicated to your environment. You have complete control over the VPC, including the IP range, subnets, routing tables and security. VPCs use security groups and access control lists to secure access and protect against unauthorized entry access. In short, the VPC is your private CIDR block of the AWS Cloud. You can have a CIDR of 16 down to a CIDR of 28. Let's look at the core components and acronyms of the VPC. Subnet is a segment of the VPC's IP address range where you can place groups of isolated resources. The IGW is a great acronym to forget in the last five minutes of an exam, it's the Internet Gateway. The Amazon VPC side of a connection to the public internet. Hardware VPN connection is a hardware-based VPN between your Amazon VPC and your data center or co-lo facility. VGW is another great one to forget when you see it written down on the question. VGW stands for the Virtual Private Gateway. And that's the Amazon VPC's side of a VPN connection. With Virtual Private Gateways, you can connect existing networks to your VPC. How about CGW? Customer Gateway, your side of a VPN connection. So routers interconnect subnets and direct traffic, between internet gateways, virtual private gateways, net gateways and sub-ets. Peer end connections enable you to route traffic via private IP addresses between two peered VPCs. Great feature is the VPC endpoint for S3. Now that enables Amazon S3 access from within your VPC without using an internet gateway or net. So it allows you to control the access using VPC Endpoint policies. Subnets are CIDR blocks within the IP range of your VPC. What's a CIDR block I hear you ask? That stands for Classless Inter-domain Routing. It's essentially a block of IP numbers. A subnet is a distinct network segment with its own IP address range within the larger VPC classless inter-domain routing range. When planning a subnets, take the time to properly anticipate how many nodes you might need in future. You can't change the size of a VPC after you've created it. If your VPC is too small, create a new larger VPC and then migrate your instances to the new VPC. The first four IP addresses and the last address of any subnet are not available. Now these are reserved by AWS for routers, DNS broadcast and network addresses. AWS won't allow you to create netmasks lower than /16 or higher than /28. Each subnet must be associated with a route table. Every subnet that you create is automatically associated with a main route table for the VPC. Each subnet must be associated with a network access control list. If you don't explicitly associate a subnet with a network access control list, the subnet is automatically associated with the default network access control list. We're allowed 200 subnets per VPC. The IGW or Internet Gateway provides connectivity in and out of your VPC. In practice, it serves two functions. First, it provides a target in your VPC route tables for internet-routable traffic. And secondly it performs network address translation for instances that have been assigned public IP addresses. If a subnet is associated with a route table that has a route to an Internet gateway, it's known as a public subnet. That subnet route table needs to contain a route that directs internet bound traffic to the internet gateway. One approach to achieve this is to scope the route to all destinations not explicitly known to the route table using 0.0.0.0/0, or you can scope the route to specific IP addresses. You can create a VPN tunnel using IPSEC to onpremise or co-locations. If you need more predictable connectivity or a private connection use Direct Connect. Direct Connect is a private, dedicated connection between your on-premise network and your AWS Virtual Private Cloud. It uses the 802.1 q VLAN standard. Network access control lists enable subnet level control within a VPC. Security groups control resource level permissions. Network access control lists manage subnet level permissions. Your VPC comes with a default network access control list. That list allows inbound and outbound traffic by default. Network access control lists are stateless. So responses to allowed inbound traffic are subject to the rules for outbound traffic and vice-versa. A network access control list contains a numbered list of rules that are read in order starting with the lowest numbered rule. A network access control list has separate inbound and outbound rules. And each rule can either allow or deny traffic. You can create a custom network access control list and associate it with a subnet. By default, each custom network access control list denies all inbound and outbound traffic until you add rules, which if you remember, is different from the default network access control list which allows all. Each subnet in your VPC must have a network access control list. If you don't explicitly associate your own network access control list to a subnet, the subnet is automatically associated with the default network access control list. You can associate a network access control list with multiple subnets. However, a subnet can be associated with only one network access control list. When you associate a network access control list with a subnet, the previous association is removed. A network ACL can have up to 20 rules. A security group acts as a virtual firewall to control inbound and outbound traffic to your instances. Security groups act at the instance level. Network access control lists work at the subnet level. While network access control lists restrict or allow access to a subnet, security groups are your resource level control. Instances, elastic load balancers, et cetera. You can specify allow rules but not deny rules. Instances in a subnet in your VPC could be assigned to a different set of security groups. If you don't specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC. Security groups are stateful. For each security group, you add rules that control the inbound traffic to instances. And a separate set of rules that control the outbound traffic. No inbound traffic is allowed until you add inbound rules to the security group. Return traffic is allowed by default. Security groups are associated with your network interfaces. So here is a quick summary of the differences between security groups and network access control lists. The security group operates at the instance level so it's your first layer of defence. The network access control list operates at the subnet level so it acts as a second layer of defense. Security groups support ALLOW rules only. Network ACLs support allow rules and deny rules. Security group is STATEFUL and return traffic is automatically allowed, regardless of any other rules. The network ACL is STATELESS so return traffic must be explicitly allowed by your rules. With security groups, they are evaluated before deciding whether to allow traffic. With network ACLs, rules are processed in number order when decision is made to allow traffic or not. With the security group it applies to an instance only if someone specifies the security group when launching that instance, or when that security group is associated with an instance once it's already launched. With the network ACL, that's automatically applied to all instances in a subnet it's associated with, so it acts as a backup layer of defense. Here's a quick summary of a limits per virtual private cloud. We're allowed five virtual private clouds per region. There's a default virtual private cloud set up with each new AWS account. That one default virtual private cloud per region has a default internet gateway, network access control list, and a routing table. We're allowed 500 security groups. We're allowed a maximum of five internet gateways per region. This limit is correlated with the limit of VPCs per region. We're allowed 10 VPNs per VPC. We're allowed 200 subnets and five Elastic IP addresses. Okay let's discuss this sample question. The question is: You are configuring a new virtual private cloud for one of your clients for a cloud migration project. Only a public VPN will be in place. After you've created your VPC, you created a new subnet, a new internet gateway and attached your internet gateway to the VPC. That all sounds pretty good so far doesn't it? After launch, your first instance into your VPC, you realized that you cannot connect to the instance even if it is configured with an elastic IP address. What should be done to access the instance? So it's always important to read these questions very carefully. They give us all the facts that we need to answer this. So the first thing that we're gonna note is that we've created a new subnet. It's got an internet gateway so therefore it is a public subnet. And we've attached the internet gateway to the VPC. So by all means and purposes, that public subnet should have connectivity to the public domain. So let's read through our options. The first one, a network access control list should be created and allow all outbound traffic. Well the network access control list, it's our outer perimeter security isn't it, that goes on a subnet? You remember our security groups give us resource level permissions and those allow rules, and our network access control lists are stateless, and they can do allow and deny rules. So this is quite a tricky option if we had specifically had given to us that we'd created a network access control list, then any custom access control list we would set policies for inbound and outbound. But because we haven't been told that, we just have to assume that we're using the default network access control list. And that allows all by default. So we're gonna have to discount this as an option. So option B is a route should be created as 0.0.0.0/0 and your internet gateway as a target. Now that to us is a very rich in the right to cap in my view. Because what's missing from the description that we have above is the route. And remember that every VPC needs to have a route table to point traffic from any instance inside the VPC out to the external domain. So I'm going to go with that one at this stage, a route should be created. Okay and the third option we have is a NAT instance should be created and all traffic should be forwarded to the NAT instance. No, that would be appropriate if we had a private subnet that was trying to connect to the internet, for example. And it was a private subnet then that would be one way of connecting using a bastion host to have instances that are in a private subnet connect to the external or public domain. So I'm not going to go with that one. Option D is attach another elastic network interface to the instance and connect via that elastic network interface. Now that's a very interesting option I don't think that's what in any way going to solve our connectivity problem. So attaching another network instance can be done, yes but it's not going to provide us with any more connectivity. Having read all four of those I think that the best option here is that we need that route. And thinking back to those basics we had around VPC, every access needs to have a route table.