Lesson 007 · AWS Learning Path

AWS 007: What is cloud computing

Anil Jalela · Published Jul 2, 2025 · 13 min read

The business situation

A company owns two physical servers. Purchasing a replacement takes six weeks. Demand is highest for three hours each evening, but the company pays for peak capacity all day. A manager proposes "move everything to the cloud" without defining availability, security, recovery, data location, or cost requirements.

Your first job as an architect is not to choose an AWS service. It is to determine what cloud computing changes, what it does not change, and which requirements must drive the design.

What you will be able to do

By the end of this lesson, you can:

1. explain cloud computing in plain language;
2. apply the five NIST essential characteristics;
3. distinguish cloud capability from ordinary remote hosting;
4. explain elasticity, scalability, and measured usage without treating them as synonyms;
5. identify responsibilities that remain with the customer;
6. evaluate whether a workload benefits from cloud characteristics;
7. explain the path from owned physical computers to on-demand cloud services;
8. create the first entry in the Foundation Decision Workbook.

A practical definition

Cloud computing provides configurable IT capabilities as network-accessible services that can be provisioned and released on demand, drawn from a shared provider pool, adjusted rapidly, and measured.

AWS describes cloud computing as on-demand delivery of IT resources over the internet with pay-as-you-go pricing. Compute, storage, databases, networking, and higher-level application capabilities can be requested through a Console, API, command-line tool, or automation.

The important change is not simply that the server is in someone else's data center. The operating model changes:

Traditional purchase
Requirement -> quotation -> approval -> order -> delivery -> rack -> configure

Cloud consumption
Requirement -> authorized API request -> provision -> verify -> use -> release

Cloud can shorten provisioning time, but authorization, architecture, testing, security, operations, and cost control still require human decisions.

Why cloud computing appeared

Cloud computing makes more sense when you understand the problem it replaced. This is a problem-and-solution history, not a list of dates to memorize.

Stage 1: one organization owns the whole machine

Early business computing centered on expensive physical computers operated by the organization using them. People shared large systems through terminals. Capacity planning meant buying hardware, finding space and electrical power, installing it, and maintaining it for years.

A physical server is a real computer built to provide processing, memory, storage, or network services to other computers. A data center is a controlled facility containing servers, networking equipment, power, cooling, and physical security.

The old model provided direct control, but it created three recurring problems:

• purchasing capacity took time;
• unused capacity still consumed money and operational effort;
• a sudden demand increase could exceed the installed hardware.

Stage 2: client-server systems distribute the work

Personal computers and networked applications moved organizations toward the client-server model. A client requests work; a server responds. Web browsers and web servers are familiar examples. AWS 012 develops this model in detail.

Client-server computing changed where work happened, but organizations still bought and operated enough physical servers for their applications.

Stage 3: virtualization divides one physical server

Virtualization allowed one physical server to run multiple isolated virtual machines. A virtual machine, or VM, behaves like a computer, but software maps its virtual processor, memory, disk, and network devices onto physical hardware.

Virtualization improved hardware use and made servers easier to create and replace. It did not automatically create cloud computing. If every VM still required a manual ticket, fixed allocation, and no usage measurement, the operating model remained similar to a traditional data center. AWS 011 compares virtual machines and containers.

Stage 4: internet APIs turn infrastructure into a service

An API, or application programming interface, is a defined way for software to request an operation from other software. A web API accepts requests across a network. When infrastructure can be requested through an authorized API, software can provision, inspect, and release capacity without waiting for physical installation.

This combination made the cloud operating model practical:

Pooled physical infrastructure
             |
             v
Virtualized or managed capability
             |
             v
Authorized network API
             |
             v
On-demand request -> measured use -> release

The API is important because the AWS Management Console, AWS Command Line Interface, software development kits, and infrastructure-as-code tools ultimately cause API requests. They are different interfaces to the same control plane, not separate clouds.

Where AWS enters the history

Amazon had experienced the cost and delay of provisioning infrastructure for its own business. AWS was created to expose reusable infrastructure capabilities to customers as services. The name Amazon Web Services reflects that service-and-API model: customers request capabilities across a network instead of purchasing the underlying servers.

AWS launched Amazon Simple Storage Service, or Amazon S3, in March 2006. S3 made internet-accessible object storage available through a service interface. Amazon Elastic Compute Cloud, or Amazon EC2, followed in 2006 and provided resizable computing capacity. These services illustrate the original cloud separation:

Need to keep data -> request object storage from S3
Need processing    -> request virtual compute from EC2
Finished           -> release temporary compute; retain only required data

The distinction still matters. Compute and storage have different lifecycles, failure modes, security controls, and prices. Later AWS services added managed databases, virtual networking, content delivery, event processing, containers, serverless computing, analytics, security controls, and automation. Those services did not make the fundamentals obsolete; they moved more operational responsibility into managed service layers.

A short problem-to-service timeline

Dates provide orientation; certification questions normally test the resulting architecture and responsibility boundaries. The useful question is always: which earlier burden did this service remove, and which responsibilities remain with the customer?

Check the history model

Match each change to the problem it addresses:

1. Virtualization divides a physical server into separately managed machines.
2. An infrastructure API allows authorized software to request capacity.
3. Measured service records consumption.
4. S3 separates durable object storage from the lifecycle of a compute instance.

Expected reasoning:

• virtualization improves isolation and physical-resource use;
• APIs enable self-service and automation;
• measurement supports usage visibility and consumption charging;
• separate storage prevents a temporary compute lifecycle from being the only home of durable data.

The five essential characteristics

NIST SP 800-145 defines five essential characteristics. Use them as a test rather than memorizing a slogan.

1. On-demand self-service

An authorized consumer can provision capability without waiting for a person at the provider to perform each request.

AWS example:

• an authorized identity requests an EC2 instance through the Console or API;
• AWS processes the request automatically;
• the customer does not submit a hardware purchase order for that instance.

Counterexample:

• every capacity change requires a provider employee to receive a ticket and manually assign a server.

On-demand does not mean uncontrolled. IAM, quotas, policies, approvals, automation gates, and budgets can govern the request.

2. Broad network access

Capabilities are available over networks through standard mechanisms usable by different client types.

Examples:

• a browser reaches an HTTPS application;
• a mobile application calls an API;
• an administrator uses the AWS Console;
• automation calls an AWS API endpoint.

Broad access does not mean public access. A cloud service can use private addresses, private endpoints, VPN, dedicated connectivity, identity-aware access, or other controls.

3. Resource pooling

The provider pools physical and virtual resources to serve multiple customers while maintaining logical separation. Capacity is assigned and reassigned according to demand.

You select useful location scopes such as a Region or Availability Zone, but you normally do not choose the exact physical server rack.

Resource pooling creates economies and flexibility. It does not remove the need for isolation, access control, encryption, or data-governance decisions.

4. Rapid elasticity

Capacity can expand or contract quickly as demand changes. From the consumer's perspective, available capability can appear very large.

Example:

• an application adds compute capacity for an evening traffic peak and removes it afterward.

Elasticity is not automatic merely because a workload runs on AWS. The architecture must use scalable components, scaling rules, stateless or correctly managed state, quotas, observability, and tested behavior.

5. Measured service

The platform meters resource use. The provider and consumer can monitor and report usage according to the service's pricing and measurement dimensions.

Examples of possible dimensions:

• instance time;
• storage amount and duration;
• requests;
• data processed;
• data transferred;
• provisioned capacity;
• active public IPv4 addresses.

Measured service enables usage-based charging and analysis. It does not guarantee that the workload is cheaper. Waste is also measured.

Scalability and elasticity are related but different

Scalability is the ability of a system to handle increased or reduced demand by changing available capacity.

Elasticity is the ability to make that capacity track demand dynamically and release it when demand falls.

Scale up:   use a larger resource
Scale down: use a smaller resource
Scale out:  add resources
Scale in:   remove resources
Elastic:    adjust capacity as demand changes, often through automation

A database moved manually to a larger instance once per year is scalable. A web tier that adds and removes instances based on tested signals demonstrates elasticity.

Cloud does not automatically provide these outcomes

Lower cost

Cloud changes the cost model and can reduce waste, but an oversized or forgotten resource can cost more than a well-used owned system.

High availability

A single instance in one Availability Zone is still a single failure domain. Availability must be designed and tested.

Backup

Durable infrastructure does not replace a backup and restore strategy. Deletion, corruption, malicious change, and application errors still matter.

Security

AWS protects the cloud infrastructure. Customers still make identity, data, configuration, application, logging, network, and service-selection decisions.

Compliance

AWS certifications and service capabilities can support a compliance program. The customer must configure and operate the workload to meet applicable requirements.

Unlimited capacity

Services have quotas, feature availability, account restrictions, and Regional capacity considerations. Architects plan and monitor these constraints.

The AWS shared responsibility boundary

AWS describes:

• security of the cloud as AWS responsibility for the infrastructure that operates AWS services;
• security in the cloud as customer responsibility determined partly by the selected service.

The boundary changes with the service.

For an EC2 virtual machine:

• AWS operates the facilities, physical hardware, foundational networking, and virtualization layer;
• the customer configures the guest operating system, patches it, controls applications, protects data, assigns permissions, and configures controls such as security groups.

For a more abstracted service such as Amazon S3:

• AWS operates more of the infrastructure and platform;
• the customer still classifies data, controls access, chooses encryption and lifecycle settings, and configures the service safely.

Using a managed service changes your tasks. It does not transfer accountability for your data and workload outcomes to AWS.

Why organizations use cloud

AWS describes six common advantages:

1. replace some fixed expense with variable expense;
2. benefit from provider economies of scale;
3. reduce capacity guessing;
4. increase speed and agility;
5. reduce undifferentiated data-center operation;
6. reach users through multiple global locations.

Treat these as possible advantages, not guaranteed results.

For example, "go global" can reduce user latency, but a multi-Region system adds data consistency, deployment, observability, security, recovery, and cost complexity.

Practical exercise: test a workload against cloud characteristics

No AWS resource is needed.

Scenario:

NitWings Learning runs a three-tier training portal. Normal traffic is 500 learners per day. A certification event can bring 20,000 learners for four hours. The application stores profiles, progress, videos, and assessment results. The company currently waits four weeks for new servers. It must protect learner data, restore assessment results after failure, and understand event cost.

Create the evidence directory:

mkdir -p "$HOME/nitwings-aws/evidence/aws-007"

Create this file:

$HOME/nitwings-aws/evidence/aws-007/cloud-characteristics.md

Use this template:

# Cloud-characteristics analysis

## Workload
NitWings Learning training portal

## On-demand self-service
Current problem:
Cloud opportunity:
Required control:

## Broad network access
Users and clients:
Private or public paths:
Required control:

## Resource pooling
Shared capability:
Isolation requirement:
Location requirement:

## Rapid elasticity
Demand change:
Candidate scaling behavior:
State or quota risk:

## Measured service
Important usage dimensions:
Cost evidence:
Budget boundary:

## Responsibilities that remain with the customer

## Cloud outcome
Good candidate / partial candidate / poor candidate:

## Reason

Expected reasoning

Your wording can differ, but a sound analysis should include:

• self-service can reduce the four-week provisioning delay, subject to identity, quota, policy, and review controls;
• browsers and mobile clients need secure network access, but databases should not become public merely because users are remote;
• pooled provider capacity can support changing demand while tenant and customer-data isolation remain required;
• the event creates a strong elasticity case, but the application must support horizontal scaling and manage session or database state;
• requests, compute, storage, delivery, transfer, and other service-specific dimensions must be estimated and observed;
• the customer still owns data classification, permissions, application security, recovery targets, configuration, monitoring, and cost decisions;
• the workload is a good cloud candidate if the architecture and operating model are redesigned rather than copied unchanged.

Compare cloud with ordinary hosting

Classify each offering:

Offering A

A provider rents one fixed server for 12 months. Capacity changes require a support ticket and contract change. Usage is not metered beyond the fixed monthly fee.

Offering B

An authorized user can request compute and storage through an API, capacity comes from a provider pool, resources can be added or released rapidly, and usage is metered.

Offering C

An internal virtualization team provides pooled virtual machines through a self-service portal, meters use by department, and can add or release capacity rapidly.

Expected analysis:

• A is remote hosting but does not strongly exhibit all five cloud characteristics.
• B exhibits the cloud operating model.
• C can be cloud computing even though it is private to one organization. Deployment models are covered in AWS 009.

Cloud is an operating model, not merely a location.

Common misconceptions

Check your understanding

1. Which characteristic allows an authorized customer to request capacity without provider staff handling each request?
2. Does broad network access require a public IP address?
3. What is the difference between scalability and elasticity?
4. Why is measured service useful and potentially dangerous?
5. Who patches the guest operating system on an EC2 instance?
6. Is a private internal cloud possible?

Expected answers

1. On-demand self-service.
2. No.
3. Scalability is the ability to change capacity; elasticity makes capacity track demand and release unneeded capacity, often dynamically.
4. It enables usage visibility and variable charging, but waste is also metered and charged.
5. The customer.
6. Yes, if the capability follows the cloud characteristics. Deployment models are explored in AWS 009.

Architecture decision points

In an exam or real design, ask:

• Is demand variable or predictable?
• How quickly must capacity change?
• Which responsibilities can a managed service reduce?
• Which responsibilities must remain with the organization?
• Are there location, latency, or connectivity constraints?
• What availability and recovery targets exist?
• Which usage dimensions drive cost?
• Can the application actually scale?
• What evidence will prove security, performance, recovery, and cost?

Do not select "cloud" only because rapid provisioning sounds attractive.

Completion gate

You pass AWS 007 when:

• cloud-characteristics.md evaluates all five characteristics;
• the analysis identifies at least five customer responsibilities;
• you correctly classify Offerings A, B, and C;
• you can explain why cloud is not automatically secure, available, backed up, unlimited, or cheaper;
• no AWS resource was created.

Retain the completed analysis for AWS 008, AWS 009, AWS 010, and the three-tier model in AWS 022.

Official sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• AWS: Our origins
• AWS announcement of Amazon S3 in March 2006
• AWS Blog: the first five years
• AWS announcement of AWS Lambda in November 2014
• AWS announcement of Amazon EC2 Container Service in November 2014
• AWS overview: What is cloud computing?
• AWS overview: Six advantages of cloud computing
• AWS shared responsibility model
• AWS Well-Architected Framework