How to design high availability and fault tolerant architectures
Designing solutions for elasticity and scalability
The course is part of this learning path
Designing Resilient Architectures. In this module, we explore the concepts of business continuity and disaster recovery, the well-architected framework and the AWS services that help us design resilient, fault-tolerant architectures when used together.
We will firstly introduce the concepts of high availability and fault tolerance and introduce you to how we go about designing highly available, fault-tolerant solutions on AWS. We will learn about the AWS Well Architected Framework, and how that framework can help us make design decisions that deliver the best outcome for end users. Next, we will introduce and explain the concept of business continuity and how AWS services can be used to plan and implement a disaster recovery plan.
We will then learn to recognize and explain the core AWS services that when used together can reduce single points of failure and improve scalability in a multi-tier solution. Auto Scaling is a proven way to enable resilience by enabling an application to scale up and down to meet demand. In a hands-on lab we create and work with Auto Scaling groups to improve add elasticity and durability. Simple Queue service increases resilience by acting as a messaging service between other services and applications, thereby decoupling layers, reducing dependency on state. Amazon Cloudwatch is a core component of maintaining a resilient architecture - essentially it is the eyes and ears of your environment, so we next learn to apply the Amazon CloudWatch service in a hands-on environment.
We then learn to apply the Amazon CloudFront CDN service to add resilience to a static website that is served out of Amazon S3. Amazon Cloudfront is tightly integrated with other AWS services such as Amazon S3, AWS WAF and Amazon GuardDuty making Amazon CloudFront an important component to increasing the resilience of your solution.
- [Instructor] 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 CIDR of 16 down to a CIDR of 28. Let's look at the core components and acronyms of the VPC. Subnet, it's 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. What does the IGW stand for? 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 Colo 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 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, and net gateways and subnets. Peering connections allow you to direct traffic via private IP addresses between two peered VPCs. A 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 the subnets, take the time to properly anticipate how many nodes you might need in the 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 let you 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 the 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 a 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 the 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 0000/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 onpremise 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 your remember, is different than 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 a default network access control list. You can associate a network access control list with multiple subnets. However, a subnet can only be associated with 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 twenty 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 balances, etc; 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 specific 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. Note 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 defense. 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're evaluated before deciding to allow traffic. With network ACLs, rules are processed in numbered order when the decision is made to allow traffic or not. With a security group, it applies to an instance only if someone specifies the security group when launching that instance or when a security group is associated with an instance once it is already launched. With a 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 the 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 routing table. We're allowed 500 security groups. We're allowed a maximum of five internet gateways per region. This limit is correlated with a 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 the 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've created a new subnet, a new internet gateway, and attached your internet gateway to your VPC. That all sounds pretty good so far, doesn't it? After launch, your first instance into your VPC you realize that you can't 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. 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 that 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. With a network access control list, it's our outer perimeter security, isn't it, that goes on a subnet? You'll remember our security groups give us resource level permissions and those allow rules. And our network access control list is stateless and they can do allow and deny rules. So this is quite a tricky option. If we had been specifically given to us that we've created a network access control list, than any custom network 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've been using the default network access control list and that allows all be 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 and your internet gateway as a target. Now that is very much in the right camp, 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 from inside the VPC out to the external domain. So, I'm gonna go with that one at this stage. A route should be created. Okay, and the third option we have is a net instance should be created and all traffic should be forwarded to the net 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 gonna go over that one. Option D is attach another elastic network interface to the instance and connect by that elastic network interface. Now that's a very interesting option. I don't think that's what, in any way, is gonna 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 around to those basics we had on VPC, every access needs to have a route table.
About the Author
Head of Content
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.