Designing Highly Available, Cost Efficient Cloud Solutions
Developing Cloud Solutions
An introduction to the AWS components that help us develop highly available, cost efficient solutions
In this course we will:
Understand the core AWS services, uses, and basic architecture best practices
Identify and recognize cloud architecture considerations, such as fundamental components and effective designs.
Elasticity and Scalability
Regions and AZ's
Amazon Elastic Load Balancer
Amazon Simple Queue Service
Amazon Elastic IP Addresses
Amazon Auto Scaling
Identify the appropriate techniques to code a cloud solution
Recognize and implement secure procedures for optimum cloud deployment and maintenance
Using Amazon SQS
Using Amazon SNS
Using Amazon SWF
Using Cross Origin Resources (CORS)
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
Let's start by reminding ourselves of the 10 AWS components that can enable highly available solutions when they're used together, and how we use each of these AWS components to increase fault tolerance and durability. These AWS services really help us, so it's only fair we give them the star treatment they deserve. So to help you remember, let's count down to naming a number one high-availability component. Starting at number 10 with AWS Regions. AWS has 15 geographical regions, including AWS GovCloud and the China region. Each region is a separate geographic area designed to be completely isolated from the other Amazon regions. This achieves the greatest possible fault tolerance and stability. Essentially, everything you need to run a service is available in any AWS region, so choose the one closest or best network to your location. You only see the resources tied to the region that you specified. When you store data in a specific region, it is not replicated outside that region unless you explicitly request AWS to do so. Which brings us nicely to candidate number nine on the high-availability top 10, availability zones. Each region has multiple isolated locations known as availability zones, or AZs as we call them. AZs allow you to place instances and data in multiple locations. AZs are distinct geographical locations that are engineered to be insulated from failures in other AZs. In short, availability zones are designed for fault isolation. They are connected to multiple internet service providers in different power grids. They are interconnected using high-speed links, so applications can rely on local area network connectivity for communication between availability zones within the same region. You may be responsible for selecting the availability zones where your system will reside. Systems can span multiple availability zones, and you need to design your systems to survive temporary or prolonged failure of an availability zone in the case of a disaster. By placing Amazon EC2 instances in more than one AZ, an application can be protected from failure at a single location. Ideally, you want to run independent application stacks in more than one AZ, so that if one zone fails, the application in the other zone can continue to run. A few design points to keep in mind when considering global versus regional in the design stage, AWS accounts are global, you can use the same AWS account in all regions. AMIs, or Amazon Machine Images, are regional, so an AMI is tied to the region where its files are located within Amazon S3. You can copy an AMI from one region to another. Elastic IP addresses are regional, by default you can have five elastic IP addresses per region. Security groups are regional, so you can have a maximum of 500 security groups per region. EBS snapshots are stored regionally, it's tied to the region and can only be used to create volumes in that region. You can, however, copy a snapshot from one region to another. EBS volumes are tied to its availability zone, and can be attached only to instances in that same availability zone. An instance is tied to the availability zone in which you launched it. However, do note that the instance ID is tied to the region.
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.