Content Domain 1: Cloud Concepts

Task Statement 1.1: Define the benefits of the AWS Cloud

Let's get started with the first task statement, which is to define the benefits of the AWS Cloud. For this task statement, ensure you know the value of AWS. But before you can understand the value of AWS, ensure you know what AWS is. Can you define AWS? Well, AWS says that Amazon Web Service is the world's most comprehensive and broadly adopted cloud, offering over 200 fully featured services from data centers globally. Millions of customers, including the fastest growing startups, largest enterprises, and leading government agencies are using AWS to lower costs, become more agile, and innovate faster. So AWS provides us a way to power our infrastructure, while becoming more agile and also lowering our costs. But you also need to understand what cloud computing is. And if you ask around or you Google what is cloud computing, you will find multiple different answers. But cloud computing basically means that you have to meet certain criteria. Let's break it down and quickly walk through the five criteria. The first criteria we have to meet for AWS to be considered cloud computing is that AWS has to offer an on-demand self-service, which is the ability to provision compute features or capabilities like servers, databases, network, storage, and more on demand when that service is needed. Also, cloud computing has to be able to provision resources without any human intervention or interaction to make it an on-demand self-service. AWS gives us the ability to do this from the console, the command line, and also by using application programming interfaces. We do not need to request or ask anyone. With the correct permissions, you can go in and start building. The second criteria is that cloud computing needs to have network connectivity to access and provision resources that are needed. AWS gives us the ability to build using the AWS Management Console, the command line, HTTP, HTTPS, VPN, SSH, and more. The third criteria is that cloud computing needs resource pooling. Well, what is resource pooling? AWS provides pooled resources to serve multiple different AWS customers. AWS has thousands of servers, databases, and more that we can on-demand provision and build in our own environment. And these pooled resources are available to me, to you, and to others as well. But another part of this third criteria that we have to meet is that we do not know the exact location of these pooled resources. For example, when you spin up an Amazon Elastic Compute, Amazon EC2, instance, you can select the AWS Region. But AWS is allowed to choose any data center in that AWS Region. However, you can choose Availability Zone if you want to. And we'll talk more about Regions and Availability Zones in a few minutes. AWS procures multiple resources for their AWS customers. So we're talking about thousands to make sure they are using economies of scale. And you will learn more about economies of scale in cost optimization. But for now, economies of scale allows AWS with the larger scale of resources to offer economies at scale to their customer, which means that AWS can pass along savings to their customer while also providing customers the resources needed to scale and grow. And this leads us to our fourth criteria that cloud computing needs, which is elasticity, which we will be talking about throughout this course. But elasticity is the ability to scale with demand. As your demand increases, you can scale up your AWS resources, and then when that demand decreases, you can scale your resources back down. And the fifth and last criteria that AWS must meet to be considered cloud computing is that the resource usage in the AWS accounts can be monitored and billed. So with the AWS, we are no longer pre-provisioning, procuring your storage, your servers, your compute, and so on. You no longer have to estimate your demands because with AWS, we are not only using services that are monitored for usage and that are billed, but we are also actually scaling those resources to meet your demand instead of being over- or under-provisioned. And the biggest cost optimization benefit is that we only pay for what we use with AWS. So how does AWS provide such amazing cloud computing? Well, AWS offers a global infrastructure, which is a collection of smaller groupings of infrastructure that is connected by a global high-speed network. And this global infrastructure allows you to design systems that are resilient and highly available. And we will dive deeper into the AWS global infrastructure later on in this course under domain 3. But for now, ensure you understand AWS Regions, Availability Zones, and edge locations. Let's wrap up this lesson and cover the advantages of high availability, elasticity, and agility. High availability and fault tolerance are often confused. So let's dive a bit deeper into both and disaster recovery too. Let's start off with high availability. High availability is a way to design your systems to have the ability to keep your systems up and running and providing service as often as possible. It is designed so that if a system component fails, then that failure can be replaced or fixed as quickly as possible. So it maximizes the system's online time. But high availability does not mean it stops failures. And high availability also does not mean that there will be no downtime or outages. What high availability does is respond when there is a failure to fix the failure as soon as possible so that system can be brought back into service. So what is an example of high availability? Well, let's say that we have an application running on a single server inside AWS. And this server is used by employees to complete their job. If this server goes down, then the employees cannot work because the server is down and it is currently experiencing an outage. If you design this architecture to be highly available, you could quickly spin up a new server to failover to or you could be running two servers for this application. One in active mode and one in a standby mode. So if one server goes down, you can failover to the second server to serve the employees. But in this situation, the employees may have to log back in so there could be a bit of downtime, which is okay. It's not what you want, but with high availability, some downtime can be expected depending on your design. The goal of high availability is to reduce outages and stay operational to be fast, and automatic recovery is best. But there is usually downtime even if it's very brief. Now, let's go over fault tolerance. It is similar to high availability, but fault tolerance is the actual ability of a system to keep operating in the event of a failure. For example, let's say that one or more of the system's components fails, but the system is able to continue on with those faults failing. So a fault-tolerant design must continue to operate. Let's go back to our earlier scenario. In this case, we are designing for fault tolerance. Then we would have two active servers serving the one application. So if one server goes down, the second server is already active and will continue to serve the employees, and there is actually no downtime in this situation. Fault tolerant designs operate to minimize failures, but also to continue to operate through failure. And these system designs are usually more expensive than high availability designs. Disaster recovery is a bit different from fault tolerance and high availability because fault tolerance and high availability are all about designing systems to operate through a disaster. Disaster recovery is all about what we need to plan for and also what we need to do in the event of a disaster. And having a disaster recovery plan is crucial because the worst time to recover from a disaster is in the middle of that disaster. Disaster recovery needs pre-planning and also steps to complete the disaster recovery process. So when the disaster occurs, you're already set with the plan to recover your systems as quickly as possible. Throughout this course, we will continue discussing high availability, fault tolerance, and disaster recovery, and how different AWS services are great options for one, both, or all. Let's move on and talk about elasticity. We mentioned scaling earlier in this lesson. Scaling is the ability of a system to scale. So increasing or decreasing the load placed upon that system. And systems scale when they need to grow or shrink depending on the load. So when a system scales, we are adding or removing resources to and from a system. There are two ways to scale, vertically and horizontally. An example of vertical scaling is if you have a particular size of an Amazon EC2 instance and that instance size is not able to keep up with the increase in demand, so that instance may start running very slowly, or in a worst case scenario, it may cause the system to crash. Vertical scaling is resizing your Amazon EC2 instances to a larger size. If you are using a T2 micro, you might need to resize to a T2 medium or larger. And by resizing your instance, you are adding more CPU and memory for your system to handle the increase in demand. And if you choose to scale vertically, you will encounter a few issues. There usually is a small disruption because the instance when resized will need to be rebooted. And to tie in cost optimization, when you vertically scale to a larger or even larger instance size, you'll also see an increase in your cost. And this is one area where you can dive deeper into the AWS Well-Architected Framework cost optimization pillar, which we will cover in the next lesson to make sure you are right sizing your instances in the beginning. But some benefits to vertical scaling are that there are usually no application modifications needed, and it usually works for all applications. Now let's talk about horizontal scaling because it was designed to fix some of the issues we have with vertical scaling. So with horizontal scaling, instead of increasing the size of your instance, you add more instances of the same size to handle that load. And instead of having one running copy of your application, you now have one copy for each instance it scaled and you can use a load balancer to help distribute the load across all of your instances. But we also have to consider certain things with horizontal scaling. One consideration is session. With your application, you do not want to interrupt customer sessions. When you have a single application running on a single server, then all of your sessions are stored on that server. But what do you think happens to your sessions when we scale to multiple servers with copies of your application? Well, sometimes you're shifted between the instances because horizontal scaling is meant to even out the load. So the load balancer sends requests to different servers that have a copy of your application. You can use the sticky sessions feature so that you do not lose your session switching between servers. And this works when scaling in or scaling out. Also, as far as for cost optimization, horizontal scaling is usually less expensive because you are using smaller, cheaper instance sizes. Now, let's cover elasticity. What is it? It is an important topic to know and understand for the exam. Elasticity is using automation along with horizontal scaling to match capacity and supply with the demand. You'll notice that demand is very rarely linear. It is usually increasing and decreasing. And using elasticity allows your capacity to increase and decrease and meet that ever-changing demand. AWS provides launch configurations and auto scaling to scale out your systems to match that capacity to that demand, which enables your environment to scale out, adding additional resources as the demand increases. And then when that demand decreases, we can scale back in to a smaller number of servers or even no servers, which optimizes for performance efficiency, operational excellence, as well as cost optimization, which are all pillars of the AWS Well-Architected Framework. Here are a few exam tips. Vertical scaling is a larger size and horizontal scaling is adding more instances of the same size, and adding elasticity is using automation along with horizontal scaling to match our capacity to our demand. Let's get started with the second task statement and talk about design principles of AWS.