Cloud basics: what you're actually renting

What "the cloud" actually is

The cloud is someone else's data centre that you rent by the second, through an API. Instead of buying a server, waiting weeks for it to arrive and racking it yourself, you ask AWS for one and it's running a minute later. When you don't need it, you delete it and stop paying.

Three things make it different from renting a server the old way:

• On demand. You create and delete resources yourself, with a click or a command. No tickets, no sales call.
• Pay for what you use. Most services bill by the second, hour or gigabyte. A server that runs for 20 minutes costs 20 minutes.
• Elastic. Need 50 servers for a sale weekend and 5 on Monday? Scale up, then scale back down.

That last point is why DevOps and the cloud go together: once infrastructure is an API call, you can automate it, version it and rebuild it from scratch whenever you need to.

IaaS, PaaS and SaaS

Every app sits on the same stack of layers, from the network at the bottom to your code and data at the top. The service model decides where AWS stops and you start.

⤢ View

The shared responsibility model. The more managed the service, the smaller your share.© Diagram: DevOps Academy, based on AWS's shared responsibility model

Close

Public, private and hybrid cloud

In this course we use the public cloud: AWS.

Regions and Availability Zones

AWS runs data centres all over the world, grouped in two levels:

• A Region is a geographic area, like ap-south-1 (Mumbai) or ap-south-2 (Hyderabad). Regions are independent of each other. Your resources stay in the Region you create them in.
• An Availability Zone (AZ) is one or more data centres inside a Region, with their own power, cooling and network. AZs in a Region are far enough apart that a fire or flood shouldn't hit two at once, but close enough for fast private links between them. Mumbai has three: ap-south-1a, ap-south-1b and ap-south-1c.

⤢ View

What an Availability Zone is made of: rooms full of server racks with their own power and cooling. This one is at CERN; AWS doesn't publish photos from inside its own data centres.© Florian Hirzinger, www.fh-ap.com · CC BY-SA 3.0 · resized · Source ↗

Close

The rule that follows: run anything that matters in at least two AZs. If one AZ has a problem, the copy in the other AZ keeps serving users. Most of the high availability you'll build in this course comes from that one idea.

How to pick a Region

1. Where your users are. Closer means lower latency. Users in India → Mumbai or Hyderabad.
2. Where the data is allowed to live. Some data must stay in the country by law or by contract.
3. Which services exist there. New services often reach a few Regions first.
4. Price. The same server can cost a little more or less depending on the Region.

Look around with the AWS CLI

The quickest way to start is AWS CloudShell: a terminal in your browser, opened from the AWS console, with the AWS CLI installed and signed in as you. No keys to create or leak.

$ aws --version
aws-cli/2.x.x Python/3.x Linux/x86_64        # your exact versions will differ
$ aws sts get-caller-identity                # which account and identity am I using?
{
    "UserId": "AIDAEXAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/rajeev"
}
$ aws ec2 describe-regions --query "Regions[].RegionName" --output text
$ aws ec2 describe-availability-zones --region ap-south-1 --query "AvailabilityZones[].ZoneName" --output text
ap-south-1a	ap-south-1b	ap-south-1c

--query picks the fields you want out of the JSON response, and --output text prints them plainly. You'll use both constantly.

$ aws ec2 describe-availability-zones --region ap-south-1 --query "AvailabilityZones[].ZoneName" --output text > ~/region-choice.txt
$ aws ssm get-parameters-by-path --path /aws/service/global-infrastructure/regions/ap-south-1/services --query "Parameters[].Value" --output text | tr '\t' '\n' | grep -x -e ec2 -e rds
ec2
rds
$ cat ~/region-choice.txt
ap-south-1a	ap-south-1b	ap-south-1c