What the Cloud Is and How AWS Charges You

By the end of this lesson you will be able to

• Explain what cloud computing is, and what changes when a company stops running its own data centre.
• Name the five characteristics of cloud computing and the six advantages AWS lists, and match exam keywords to them.
• Tell IaaS, PaaS, FaaS and SaaS apart, with an AWS service for each, and say which layers you still manage in each one.
• Choose between public, private and hybrid cloud for a scenario.
• Split any security task between AWS and the customer using the shared responsibility model, for EC2, RDS, Lambda and S3.
• Describe how AWS charges (compute, storage, data transfer out), explain CapEx vs OpEx and TCO, and estimate a simple bill.

#Before the cloud: running your own servers

Imagine a company in 2005 that wants to launch an online shop. Before a single customer can visit, it has to:

1. Guess how much capacity it will need, for the busiest day it can imagine, years ahead.
2. Buy the hardware: servers, disks, switches, firewalls. Tens of thousands of dollars, paid up front.
3. Find a place for it: a server room or a rented rack in a data centre, with power, backup power, cooling and physical security.
4. Wait: ordering, shipping, racking, cabling and installing take weeks or months.
5. Run it forever after: replace failed disks, patch firmware, upgrade machines every few years, pay staff to watch it at night.

This is called on-premises (often just "on-prem"): the company owns and runs the equipment itself, in its own building or in a rented space. It works, and many organisations still do it for some systems. But it has three big problems:

• The guess is always wrong. Too little capacity and the site falls over on its best day. Too much and expensive machines sit idle most of the year.
• It is slow. A new project waits weeks for hardware before anyone writes a line of code.
• Most of the work is not your business. Swapping disks and fixing air conditioning does not make your shop better than a competitor's.

#What cloud computing is

AWS defines cloud computing as the on-demand delivery of IT resources over the internet with pay-as-you-go pricing. Instead of buying, owning and maintaining physical data centres and servers, you use compute power, storage, databases and many other services from a provider such as AWS, when you need them.

The provider still has data centres and real machines. The difference is who owns them, who runs them, and how you pay: the provider builds huge shared data centres, and you rent small slices of them by the second, the gigabyte or the request.

#The five characteristics

The widely used definition from NIST (the US National Institute of Standards and Technology) says a service is "cloud" when it has these five characteristics:

Two words in that table appear everywhere in AWS and in the exam:

• Scalability: the ability to handle more load by adding resources (bigger machines or more machines).
• Elasticity: scalability that happens automatically and in both directions, so capacity follows demand up and back down, and you stop paying for what you removed.

The animation shows the two problems that elasticity solves. On the sale day the on-premises shop goes down because three servers are all it has. On the quiet night it pays for servers that do nothing. The cloud side adds instances in minutes and removes them when the rush is over. And when hardware fails, AWS owns the spare parts, but only a design with more than one instance actually keeps the shop online.

#The six advantages of the cloud

AWS describes the benefits of moving to the cloud as six advantages. They come up again and again in exam questions, usually in disguise.

#What AWS is

Amazon Web Services (AWS) is the cloud provider owned by Amazon. It gives you servers and hundreds of other services that you use on demand and can scale easily. A short history explains why it looks the way it does:

• In the early 2000s Amazon's own engineers built shared internal infrastructure so that teams could stop rebuilding the same servers and databases for every project. They realised that running infrastructure well was one of Amazon's core strengths, and that other companies would pay for it.
• 2004: the first public service, a message queue (SQS, now covered in chapter 13), launched in beta.
• 2006: AWS relaunched with S3 (storage, March) and EC2 (virtual servers, August). These two are still the foundation of almost everything else.
• 2007: the first resources outside the US, in Europe. Today AWS runs Regions on every inhabited continent (lesson 1.2).

AWS is the largest cloud provider. Its revenue passed $100 billion in 2024, and it has led the market for well over a decade, ahead of Microsoft Azure and Google Cloud. Companies of every size run on it: Amazon.com itself, Netflix, banks, governments, start-ups and games studios.

Typical uses include company IT and back-office systems, backup and storage, big data analytics, websites, mobile and social apps, games, machine learning and high-performance computing. This course follows the order you need the services in, not the order they were launched.

#Service models: IaaS, PaaS, FaaS and SaaS

"Cloud" is not one product. Providers offer different amounts of the stack, from bare virtual machines to finished software. The model decides how much you manage yourself and how much the provider manages for you.

The notes give the clearest IaaS example: EC2 is AWS's virtual server. Like your own computer it has a CPU, RAM, storage and an operating system (Linux or Windows), but it physically sits in an AWS data centre, and you rent it instead of buying it. Because you get the machine and nothing on top of it, EC2 is IaaS.

#Deployment models: public, private, hybrid

Separate from the service model is where the cloud runs and who shares it.

Two more terms you will meet:

• Multi-cloud: using more than one public provider (for example AWS and Azure). It is a business choice, often for negotiating power or acquired systems. It adds complexity and is rarely the right exam answer.
• AWS in your building: services such as AWS Outposts put AWS-managed racks in your own data centre, for workloads that need very low latency to on-prem systems or must keep data on site, while you still use the same AWS APIs. (Outposts is covered in chapter 25.)

#The shared responsibility model

When you move to AWS, security does not become someone else's problem. It is split. AWS states the split in one sentence:

• AWS is responsible for security of the cloud: the infrastructure that runs every AWS service. That means the buildings, physical access, power, cooling, the hardware, the global network, and the software that runs the services themselves (for example the hypervisor under EC2).
• You are responsible for security in the cloud: everything you put in it and how you configure it. Your data, who can access it (IAM, chapter 2), your network rules (security groups and network ACLs, lesson 3.5), encryption choices, and, depending on the service, the operating system and applications.

#The line moves with the service

The more a service manages for you, the more of the stack AWS takes on. Your data and your access settings always stay with you.

Some controls are called shared controls, because both sides do part of them in their own layer:

• Patch management: AWS patches the infrastructure; you patch your guest OS and applications.
• Configuration management: AWS configures its devices; you configure your OS, databases and applications.
• Awareness and training: AWS trains its staff; you train yours.

And some are inherited controls: you get them from AWS without doing anything, such as the physical and environmental controls of the data centres. Auditors accept AWS's reports for those (you download them from AWS Artifact, the self-service portal for AWS's compliance reports).

#What goes wrong in practice

Almost every famous cloud breach sits on the customer's side of the line:

• An S3 bucket made public with private files in it. S3 did exactly what its policy said. (New buckets now block public access and encrypt objects by default, but a person can still switch that off.)
• SSH or a database port open to 0.0.0.0/0, found by bots within minutes.
• An unpatched EC2 instance running an old web server with a known flaw.
• Access keys pushed to GitHub, then used to launch crypto-mining instances on the victim's bill (chapter 2 and lesson 1.3 show how to avoid long-term keys).
• A database with a weak admin password reachable from the internet.

The notes give a small example of the same rule: a NAT instance (lesson 3.4) is just an EC2 instance, so its scaling, OS patching and high availability are your job, while a NAT gateway is managed by AWS. Choosing a managed service moves work to AWS's side of the line.

#How AWS charges you

AWS prices almost everything pay as you go: no upfront payment, no long contract by default, and you stop paying when you stop using. Three things drive nearly every bill:

1. Compute: how long your resources run, and how big they are. EC2 Linux instances bill per second (with a one-minute minimum); Lambda bills per request and per millisecond of run time, scaled by memory.
2. Storage: how much data you keep, and for how long, usually priced per GB-month. S3, EBS volumes, snapshots and backups all count. Storage keeps charging even when nothing is running.
3. Data transfer out: data leaving AWS to the internet, or crossing between Regions, is charged per GB. Data coming in from the internet is free.

Prices vary by Region and change over time; always check the pricing page or the AWS Pricing Calculator before you trust a number.

#Three ways AWS lowers the price

1. Pay as you go: the default. Best for new, spiky or short-lived workloads.
2. Save when you commit: promise a steady amount of use for one or three years (Savings Plans, Reserved Instances) and pay up to about 72 % less than On-Demand. Covered in lesson 4.4.
3. Pay less by using more: tiered prices, so the per-unit price falls as volume grows (for example data transfer out and S3 storage get cheaper per GB at higher tiers).

#CapEx, OpEx and total cost of ownership

Comparing a server's price to an instance's hourly price is not a fair comparison. TCO (total cost of ownership) counts everything a system really costs over its life:

• On-premises: hardware, software licences, data centre space, power and cooling, network links, spare parts, the staff who run it, and the cost of idle capacity bought for peaks.
• Cloud: the service charges, data transfer, support plan, the staff who design and operate it, and the cost of migrating.

Often the cloud wins on TCO because idle capacity and data centre staff disappear. Sometimes it does not: a large, perfectly steady workload that already has paid-off hardware can be cheaper on-premises. A Solutions Architect's job is to do the sum, not to assume.

#Economies of scale

AWS buys servers, disks, network gear and electricity in amounts no single customer could, designs its own hardware (such as the Nitro system and Graviton processors), and runs it with heavy automation. That lowers its cost per unit. AWS has passed part of this on as price reductions more than a hundred times since 2006. This is the advantage "benefit from massive economies of scale".

#The cloud in system design

The ideas in this lesson change how you design systems on AWS:

• Design for failure. Hardware breaks in AWS too. AWS fixes the hardware; your design decides whether users notice. Run more than one copy, in more than one Availability Zone (lesson 1.2), behind a load balancer (chapter 6).
• Treat servers as replaceable. Because a new instance is one API call away, you replace broken or outdated servers instead of repairing them. Golden AMIs and launch templates (lesson 4.3) make that routine.
• Scale with demand. Use elasticity: Auto Scaling for instances, serverless services that scale by themselves, and turning off what is idle (development environments at night).
• Make cost a design property. Data transfer, idle resources and storage you forgot about are architecture decisions. Keep chatty components in the same AZ where it is safe, serve downloads through a CDN (chapter 11), and tag resources so you can see who spends what.
• Prefer managed services when they fit. Each one moves part of the shared responsibility line to AWS: fewer servers to patch, fewer things to break at 3 a.m.
• Know the Well-Architected Framework. AWS's guidance for good cloud designs rests on six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Chapter 26 goes through them; every chapter of this course touches them.

#Try it yourself

#Estimate a small bill with the AWS Pricing Calculator

1. Open the calculator

   Go to calculator.aws (no account needed) and choose Create estimate.

2. Add a small web server

   Add Amazon EC2, Region US East (N. Virginia), one Linux t3.micro running 730 hours a month (always on), with a 20 GB gp3 EBS volume.

3. Add storage and traffic

   Add Amazon S3 Standard with 50 GB stored, and on the EC2 entry set data transfer out to the internet to 200 GB per month.

4. Read the result

   Look at which line is largest. Then change the instance hours to 200 (only office hours) and see how much the compute line falls while the storage line does not move. That difference is pay-as-you-go in action.

#Look at the raw price list

AWS publishes every price as machine-readable files. This lists the services that have a price list:

curl -s https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json | head -c 600

You will use the CLI properly in lesson 1.3; aws pricing get-products reads the same data with filters.

#Do the TCO sum by hand

A company plans 4 servers at $6,000 each, replaced every 3 years, plus $300 a month for rack space and power and one-quarter of an engineer's time at $2,000 a month. That is $24,000 / 36 months ≈ $667 + $300 + $500 ≈ $1,467 per month, whether the servers are busy or not. Now price four equivalent instances in the calculator, running only when needed, and compare. Then ask what the comparison leaves out on each side.

#Summary

Key points

• Cloud computing is the on-demand delivery of IT resources over the internet with pay-as-you-go pricing. The provider owns and runs the hardware; you rent slices of it.
• The five characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. Elasticity means capacity follows demand both up and down automatically.
• AWS's six advantages: variable instead of fixed expense, economies of scale, stop guessing capacity, speed and agility, no data centre to run, global in minutes.
• IaaS (EC2): you manage from the OS up. PaaS (Beanstalk, RDS): you manage code and data. FaaS (Lambda): you manage one function. SaaS (Gmail, Rekognition): you manage only your data and users.
• Public, private, hybrid: hybrid connects on-premises and the public cloud and is the answer when some data must stay on site.
• Shared responsibility: AWS secures of the cloud (facilities, hardware, network, hypervisor); you secure in the cloud (data, IAM, network rules, encryption, and the OS on EC2). The more managed the service, the more AWS takes, but your data and permissions are always yours.
• AWS charges for compute, storage and data transfer out. Data in is free; the first 100 GB out each month is free; crossing AZs costs about $0.01 per GB each way.
• CapEx is paying up front for owned assets; OpEx is paying as you go. Compare TCO, not sticker prices. Storage, IPs and some managed resources keep billing after you stop instances: set a budget first (lesson 1.4).

Self-check: what the cloud is and how AWS charges30 questions