Understanding Cloud Computing

Lesson purpose

Cloud computing is an operating model for obtaining computing resources over a network when they are needed. This lesson connects the business value of AWS to the technical choices that follow: how much control to keep, how to respond to changing demand, how to pay for capacity, and how to plan a migration. The assigned reading is uCertify Lesson 1, sections 1.1–1.6, reinforced by the Lesson 1 Modern deck.

Learning objectives

• Explain why provider scale improves availability, agility, reach, security, and cost efficiency.
• Describe virtualization and distinguish IaaS, PaaS, SaaS, and serverless responsibilities.
• Distinguish scalability from elasticity and identify the guardrails an elastic design needs.
• Compare CapEx and OpEx and connect metered usage to cost control.
• Use Well-Architected thinking and the seven migration strategies to frame change.
• Create or use an AWS account safely without leaving billable resources running.

1. Cloud computing is an operating model

The four characteristics to listen for are on demand, network accessible, shared provider scale, and measured service. On-demand provisioning replaces a hardware procurement queue with an API or console request. Network access makes the service available to people and systems through standard networks. Pooling lets AWS spread facilities, hardware, and operations across many customers while keeping workloads logically isolated. Measurement makes usage visible and lets cost follow consumption.

Do not describe cloud as “someone else’s computer” and stop there. The important change is that capacity becomes programmable, repeatable, and available without owning the underlying hardware.

2. Why provider scale changes the value equation

• Agility: teams can experiment or deploy in minutes instead of waiting for purchasing, racking, and installation.
• Availability and resilience: redundant components, health checks, failover, and geographically separated infrastructure are practical at provider scale. High availability still requires a customer design; AWS cannot infer the right recovery plan for an application.
• Elastic reach: a workload can add capacity and serve users from infrastructure distributed around the world.
• Managed capability: databases, analytics, security controls, and other capabilities can be consumed as services instead of built from raw hardware.
• Economies of scale: aggregated demand and efficient operations can lower the unit cost of infrastructure, but a customer still pays for the resources and architecture it chooses.

3. Security, metering, and CapEx versus OpEx

AWS secures the cloud: facilities, physical hardware, host networking, and the service infrastructure AWS operates. Customers secure what they put in the cloud: data, identities, configuration, applications, and guest operating systems where the selected service leaves those layers exposed. The boundary moves with the service model; “AWS is secure” is not a substitute for correct IAM, encryption, patching, or network rules.

Metered payment means a test server can run for an hour and then be stopped instead of remaining an idle owned asset. CapEx pays up front for owned capacity and brings procurement, depreciation, and over- or under-provisioning risk. OpEx pays as services are consumed and supports faster experimentation, but it requires budgets, tagging, monitoring, and cleanup. A cloud bill is not automatically lower; the advantage is the ability to align cost with actual use and change the design quickly.

4. Virtualization and serverless

A physical host contributes CPU, memory, networking, and storage. A hypervisor allocates isolated virtual hardware to several virtual machines, each with its own operating system and applications. Virtual storage presents logical volumes without requiring one physical drive per workload. This separation improves provisioning speed, workload isolation, portability, and hardware utilization.

Serverless does not mean that no servers exist. It means the customer does not manage the servers. An event such as a file upload, schedule, request, or message invokes an AWS Lambda function; the function runs with configured memory and permissions, and concurrent invocations can scale with demand. This is a good fit for event-driven work that does not need a continuously running host. Explain the trade-off: less server administration, but continued responsibility for code, data, permissions, observability, and cost.

5. Service models move control and responsibility

Model	Customer focus	Provider focus	Useful decision rule
IaaS (EC2, EBS, VPC)	Guest OS through data; most network and runtime choices	Facilities, hardware, host networking, virtualization	Choose it when OS control, custom software, or lift-and-shift compatibility matters.
PaaS (Elastic Beanstalk, ECS)	Application code, data, and application configuration	Runtime, scaling platform, operating system, and servers	Choose it when deployment speed matters more than platform administration.
SaaS	Users, data use, configuration, and access policy	The application and its full runtime stack	Choose it when the business outcome matters more than customization of the platform.
Serverless (Lambda)	Function code, data, IAM, and event behavior	Runtime, scaling, and servers	Choose it for event-driven execution without an always-on host.

Use the phrase “if you can edit it, you own it” as a practical responsibility check, not as a replacement for service documentation.

6. Scalability, elasticity, and guardrails

Scalability is the ability of an architecture to handle growth, either vertically by changing resource size or horizontally by adding resources. Elasticity is the ability to add and remove capacity as demand changes. An elastic e-commerce site may run one instance during quiet periods, add instances during a flash sale, and remove them afterward.

Elasticity needs four controls: a meaningful signal (requests, latency, or saturation), a policy with thresholds and cooldown behavior, bounds such as minimum, desired, and maximum capacity, and cost control through budgets and service quotas. Ask students what happens if the metric is noisy, the maximum is too low, or the application is not stateless enough to use the new capacity.

7. Applied practice: account safety and deliberate change

When creating an AWS account, use a unique email, a strong root password, multifactor authentication, and the least privilege needed for daily work. Add payment and identity information only through the official AWS flow, choose Basic Support for initial learning if no paid plan is required, and wait for activation. Before leaving the console, stop or delete lab resources, snapshots, public IPs, and other billable objects. Never use the root user for routine administration.

A migration decision is not “move everything.” The seven Rs—retire, retain, rehost, relocate, repurchase, replatform, and refactor/re-architect—describe different amounts of change and operational benefit. Pair the choice with the six Well-Architected lenses: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. A flash sale exercise should make students predict, observe, scale, route, and recover rather than simply name services.

Common misconceptions

• Cloud means infinite free capacity. Quotas, budgets, latency, and application limits still apply.
• High availability is a provider feature that appears automatically. Customers must place redundant capacity and define health-aware routing.
• Serverless removes all operations. The customer still owns code, permissions, data, logging, and cost.
• Elasticity and scalability are synonyms. Scalability is growth capability; elasticity includes automatic contraction and expansion.
• OpEx guarantees a lower bill. Poor sizing, idle resources, transfer, and storage can make a cloud design expensive.

Lesson summary

Cloud value comes from on-demand access to a provider-scale platform, not from a slogan. Virtualization turns physical capacity into flexible building blocks; service models determine which layers the customer operates; serverless responds to events without host administration; and elastic designs use signals, policies, bounds, and cost controls. The next lesson turns these ideas into account economics: Free Tier rules, pricing dimensions, quotas, budgets, allocation, and cost investigation.