The benefits of the AWS Cloud: global reach, high availability, elasticity and agility

Why this matters

Every conversation about moving to the cloud starts with the same question: what does a company get that it cannot get from its own data centre? A manager approving a migration budget, a salesperson explaining AWS to a customer and a junior engineer asked to "make it scale" all need a precise answer, not a slogan. The answer is a short list of benefits, and each one solves a different problem.

The words matter because they are easy to blur. Elasticity, high availability and agility sound like three ways of saying "the cloud is flexible", but they describe three different things: matching capacity to demand, surviving failure, and moving quickly. A design that has one of them does not automatically have the others. A website spread across two data centres survives an outage but still pays for idle servers at night; a website that scales with demand still goes offline if everything sits in one building.

This lesson gives you the vocabulary the rest of the course builds on. Later lessons go deeper into the global infrastructure (lesson 13), scaling and load balancing (lesson 14) and the economics of the cloud (lesson 4).

The lesson

Value proposition of the AWS Cloud

Cloud computing is the on-demand delivery of IT resources, such as servers, storage and databases, over the internet with pay-as-you-go pricing. Instead of buying and running hardware, a company rents what it needs from a provider, for as long as it needs it. AWS (Amazon Web Services) describes its value in a handful of benefits, and it is worth learning them as a set.

• Trade upfront expense for variable expense (also phrased as trading fixed or capital expense for variable expense). On premises, a company buys servers before it knows whether a project will succeed. In the cloud it pays only for what it consumes while it consumes it. Most services need no long-term contract, so an experiment that fails stops costing money as soon as its resources are removed. A nightly reporting job that needs a hundred servers for two hours pays for two hours, not for a hundred machines that sit idle all day.
• Stop guessing capacity. Buying hardware means forecasting peak demand. Guess too high and servers sit idle; guess too low and customers are turned away. A retailer that buys servers for its holiday peak pays for them all year. In the cloud it provisions for the demand it actually sees and adjusts as that changes. This does not remove the need to monitor usage: scaling decisions depend on knowing how resources are being used.
• Increase speed and agility. New resources arrive in minutes, so teams can try ideas cheaply and deliver faster.
• Stop spending money running and maintaining data centres. AWS racks servers, replaces failed disks, and handles power and cooling. That work is often called "undifferentiated heavy lifting": every company has to do it, but it does not make any company's products better. Staff time goes to the business instead.
• Go global in minutes. A company can deploy in Regions around the world with no hardware to buy there.
• Benefit from massive economies of scale. AWS combines the usage of a very large number of customers, so it can buy, build and run infrastructure more cheaply than one company could, and pass the saving on as lower prices. AWS still pays for power, cooling and maintenance; it simply pays less per unit. Lesson 4 covers cloud economics in detail.

The value also comes from managed services, where AWS runs part of the stack for you. Amazon RDS (Relational Database Service) is a managed relational database: it automates tasks such as database software patching and backups. If the same database ran on Amazon EC2 (Elastic Compute Cloud, AWS's virtual servers), the customer would install and patch both the operating system and the database. "Managed" in a scenario usually means "less work for the customer's staff".

One thing the cloud does not do is remove the customer's security duties. Under the shared responsibility model (lesson 6), AWS secures the cloud itself, and the customer always keeps responsibility for what it puts in the cloud and how it configures it.

The global infrastructure: fast deployment and worldwide reach

AWS's global infrastructure is built from a few parts, explained fully in lesson 13:

• A Region is a separate geographic area where AWS runs data centres. Regions are far apart and isolated from one another.
• An Availability Zone (AZ) is one or more discrete data centres inside a Region, with redundant power, networking and connectivity. Every Region contains several AZs, physically separated so that one failing is unlikely to affect the others. All the AZs of a Region are in the same geographic area.
• Edge locations are sites in many cities worldwide that serve users from nearby. Amazon CloudFront, a content delivery network (CDN), caches content such as images and videos at edge locations so that downloads travel a short distance. Amazon Route 53, AWS's DNS (Domain Name System) service, also answers from edge locations, but it resolves names; it does not deliver content.

These parts produce four benefits a scenario may describe.

Speed of deployment. The Regions already exist. A company can launch resources on another continent in minutes, without contracts, staff or hardware there. That makes short-term needs practical: a marketing campaign in a new country can run in a nearby Region for a month and then be removed, paying only for that month. A long-term commitment such as a Savings Plan would be the wrong fit for a one-month need. It also lowers the risk of an uncertain plan, because a company can wait until demand in Asia is real and then deploy there.

Lower latency. Latency is the delay before data arrives. A European company whose Australian customers report slow responses fixes it by deploying in a Region close to Australia. Bigger servers or more scaling in Europe add capacity but do not shorten the distance the traffic travels. For content that many users download, CloudFront at the edge does the same job without running the application abroad. For players or users connecting from home, AWS Global Accelerator gives them fixed entry points at the AWS edge and carries their traffic over the AWS global network instead of the congested public internet.

Fault isolation. Because AZs and Regions are isolated, a failure in one does not spread to the others. The next section shows how designs use this.

Data residency. The customer chooses the Region where its content is stored, and AWS does not move that content out of the chosen Region without the customer's agreement, except where the law requires it. A bank that must keep data inside its own country stores it in a Region in that country. AWS does not copy data to every Region; doing so would break residency rules rather than help meet them.

Watch for the distractors. AWS Direct Connect is a private network link from a company's own premises to AWS, so it does not help users connecting from home. AWS Outposts puts AWS hardware in a customer's own site, which means ordering and installation, not an instant launch. And moving data between Regions is charged, not free.

High availability, elasticity and agility

These three are the most commonly confused terms in this domain. Learn one test for each.

High availability means a workload keeps serving users when something fails. The usual way to achieve it is to remove single points of failure. Running all web servers in one AZ makes that zone a single point of failure: an outage there takes the site offline, even though the site is reachable worldwide and can still scale. Spreading instances across two or more AZs means the loss of one leaves the others serving. One very large instance is still one point of failure, and a nightly backup helps recovery but leaves the application down until it is restored. For a disaster that affects a whole area, such as a major flood, a copy of the application in a second, distant Region keeps running; backups kept only in the same Region could be lost to the same event. Route 53 can help too: it runs health checks on endpoints and, with failover routing, sends users only to healthy ones.

Elasticity means capacity grows when demand rises and shrinks when it falls, automatically or on request. A ticketing site that sees a sharp spike when popular concerts go on sale adds capacity for that hour and releases it afterwards, so it pays for peak capacity only while the peak lasts. A batch fleet that shrinks to zero when its queue is empty is also elastic. The service to know is AWS Auto Scaling, which adds and removes capacity, such as EC2 instances, as demand changes. Amazon CloudWatch supplies the metrics and alarms that scaling acts on, but CloudWatch itself does not launch or terminate anything. Two things elasticity does not promise: zero downtime, which needs a highly available design, and a fixed bill. The bill rises and falls with usage, which is the point.

Agility means a team obtains resources quickly and cheaply, so it can experiment and deliver faster. A team that used to wait weeks for test servers and now creates and deletes test environments in minutes is showing agility. It does not mean applications never fail or that testing can be skipped.

What the exam is really asking

Most scenario questions on this topic describe a problem and ask which benefit solves it. Match the problem to the test:

• Idle servers bought for a peak, or traffic that swings: elasticity and stop guessing capacity.
• "Keeps working if a zone fails", "no single point of failure": high availability.
• "Weeks became minutes", "try out new ideas": agility.
• Users far away, a new country, "within days": go global, a Region near the users, or CloudFront for cached content.
• Staff freed from racking and cooling: stop running data centres.
• Lower prices because of AWS's size: economies of scale.

When two answers both sound right, ask what the scenario is actually short of: capacity, survival or speed.