Cloud Computing · Lessons 1–4

Cloud Computing Study Guide: Lessons 1–4

Review terms, concepts, comparisons, and high-yield distinctions for Lessons 1–4.

  • study-guide
  • aws
  • cloud-computing
  • free-tier
  • support-plans
  • regions
  • shared-responsibility

How to use this guide

This guide combines the Lessons 1–4 chapter material. It is organized by lesson so you can connect the core ideas of cloud computing to the AWS account, the support options around it, and the physical environment where AWS resources run.

Study in this order:

  1. Learn the vocabulary and comparisons in the lesson summaries.
  2. Explain the key comparisons and decision rules in your own words.
  3. Revisit the high-yield distinctions and connect them across the lessons.

Some AWS details (Free Tier offers, support plan names, and prices) have changed over time. Where your course material uses the older model, this guide lists both the older and current versions so you can recognize either one.

The ideas that connect all four lessons

Cloud computing turns physical data-center capacity into services you request on demand, pay for as you use, and place wherever you need them. The four lessons build on each other:

  • Lesson 1 — what the cloud is: virtualized, on-demand, metered resources delivered as IaaS, PaaS, SaaS, or serverless.
  • Lesson 2 — how the account is paid for and protected: Free Tier, pricing, service limits, budgets, cost tools, and Organizations.
  • Lesson 3 — where to get help: documentation, support plans, and Trusted Advisor.
  • Lesson 4 — where resources live: Regions, Availability Zones, subnets, edge locations, and who is responsible for what.

One rule appears in every lesson: AWS provides the infrastructure, but the customer still designs, configures, pays for, and secures what it builds.

Lesson 1 — Understanding Cloud Computing

What cloud computing is

Cloud computing is on-demand access to computing resources over a network, with usage measured and billed. Four characteristics define it: on demand, network accessible, shared provider scale (pooled resources), and measured service.

AWS can deliver scalable services mainly because of two strengths:

  • the enormous number of servers it operates, and
  • its highly automated infrastructure administration systems.

Geographic reach and the value of AWS’s capital assets are real, but they are not what most directly makes AWS services scalable.

Metered payment: CapEx versus OpEx

  • Capital expense (CapEx): paying up front to buy and own hardware.
  • Operating expense (OpEx): paying only for what you use, as you use it.

The metered payment model lets you:

  • build full-stack applications without a large capital investment, and
  • experiment with multiple configurations cost-effectively, because a test resource can run for an hour and then be shut down.

Metering is a billing model. By itself, it does not make an application more secure or more scalable.

Server virtualization and the hypervisor

Server virtualization logically partitions physical compute and storage devices into multiple smaller virtual devices (virtual machines). A hypervisor is the software that administers virtualized resources running on physical infrastructure. It allocates CPU, memory, storage, and networking to each VM and keeps the VMs isolated from one another.

Direct benefits of server virtualization:

  • fast resource provisioning and launching, and
  • efficient, high-density use of hardware.

Service models

Model What it means AWS examples Customer controls
IaaS Gives users direct control over the underlying compute and storage resources EC2, EBS, VPC Guest OS, applications, data, network settings
PaaS Hides infrastructure complexity behind a simple interface Elastic Beanstalk Application code and configuration
SaaS Provides a finished service to end users through a public network Web email, online office suites Users, data, and settings
Serverless Lets developers run code for short periods on cloud servers without managing them AWS Lambda Function code, permissions, and data

Serverless does not mean there are no servers. It means you do not manage them.

Scalability, elasticity, and high availability

  • Scalability: the ability of an application to automatically add preconfigured compute resources to meet increasing demand.
  • Elasticity: the ability of an application to increase or decrease compute resources to match changing demand. Elasticity includes scaling back down.
  • High availability: the application stays up despite failures. Signs include automatic failover to resources in another Region when one fails, and automatically adding resources when user demand spikes. Security layers and virtualization matter, but neither one directly makes an application highly available.

Security and migration basics

AWS secures the cloud itself. The customer secures what it puts in the cloud (data, identities, configuration, and applications). Protect the account with MFA on the root user and do not use the root user for daily work.

When moving workloads to the cloud, the seven Rs describe how much change is involved: retire, retain, rehost, relocate, repurchase, replatform, and refactor/re-architect.

Lesson 1 terms to know

cloud computing, on demand, metered payment, CapEx, OpEx, virtualization, virtual machine, hypervisor, IaaS, PaaS, SaaS, serverless, AWS Lambda, scalability, elasticity, high availability, failover, and seven Rs.

Lesson 2 — Understanding Your AWS Account

The AWS Free Tier

Older (legacy) Free Tier model — used by accounts created before July 15, 2025 and by much of the study material:

  • For 12 months, one t2.micro EC2 instance (or several whose hours add up) for 750 hours per month in total.
  • 30 GB of EBS storage in total (for example, one 30 GB SSD volume, but not two 20 GB volumes).
  • 5 GB of S3 standard storage.
  • Always-free offers continue after the 12 months end, such as 10 custom CloudWatch metrics and 10 alarms and 1 million Lambda requests per month.

Current model — new accounts: a sign-up credit of $100 with the chance to earn more, and a Free Plan that lasts up to six months or until credits run out. Always-free offers still apply. Check your own account’s plan rather than memorizing limits.

Tools that help you stay inside the Free Tier:

  • automated email alerts when usage approaches Free Tier limits, and
  • the Top Free Tier Services by Usage section on the Billing & Cost Management Dashboard.

How AWS pricing works

Cost = quantity × unit rate × duration, plus secondary charges such as data transfer, requests, and snapshots.

Things that affect price: the Region, the volume of data stored (for example, in S3), data leaving AWS (egress, for example from S3 Glacier), instance type, and purchase model. Requesting a service limit increase does not change what you pay.

The most accurate source of pricing information is the AWS online documentation (pricing page) for that particular service. The AWS Pricing Calculator is the tool for building estimates, but it may not always reflect the very latest prices. Wikipedia and the AWS CLI are not reliable pricing sources. Purchase models include On-Demand (no commitment), Savings Plans / Reserved Instances (commitment for a discount), and Spot (discounted spare capacity that can be interrupted).

Service limits (service quotas)

  • Purpose: to prevent a customer from accidentally launching a crippling level of resource consumption.
  • Limits apply per Region; a limit in one Region doesn’t affect another.
  • Most limits are defaults that can be raised by request, but some limits are hard and cannot be increased.
  • The up-to-date list of limits is in the AWS General Reference at https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html. Today, the Service Quotas console shows the same information for your account.

Billing and cost tools

Tool What it does
Billing & Cost Management Dashboard Quick summary of the current month’s spending
Budgets Sets alerts when actual or forecast cost or usage crosses a threshold
Cost Explorer Lets you design graphs and visualizations of historical and current costs in the browser
Cost and Usage Reports Generates detailed, granular usage data in CSV format
Pricing Calculator Estimates cost before you deploy

A cost budget lets you set the period (monthly, quarterly, and so on), the amount, and filters such as service, Region, linked account, tag, and instance type. It does not have a “version type” or a resource-owner username setting.

Tags and AWS Organizations

A resource tag is a key–value label on a resource. A cost allocation tag is a tag you activate so it appears in billing reports.

AWS Organizations manages multiple AWS accounts from one place and provides consolidated billing (Consolidated Billing has been folded into Organizations). Good use cases:

  • a single company with multiple AWS accounts that wants one place to administer everything, and
  • a company that has integrated some of its operations with an upstream vendor.

Poor fits:

  • an organization whose many developers and admins all work inside a single AWS account (that is a job for IAM users and groups), and
  • a company whose operating units are completely separate, each with its own accounting system and AWS account.

Lesson 2 terms to know

Free Tier, always free, t2.micro, 750 hours, EBS, S3, Pricing Calculator, On-Demand, Reserved Instances, Savings Plans, Spot, service limit, service quota, hard limit, Billing & Cost Management Dashboard, Budgets, Cost Explorer, Cost and Usage Reports, cost allocation tag, AWS Organizations, and consolidated billing.

Lesson 3 — Getting Support on AWS

Support plans

Older plan lineup (used in much of the study material):

Plan Best fit Key features
Basic Everyone (free) 24/7 customer service for account and billing questions, documentation, forums, Service Health Dashboard, core Trusted Advisor checks
Developer Individual developers in early development who need help with problems specific to their setup Business-hours email access to support professionals; limited access
Business Major deployments, including the design and testing stages before launch, and production workloads 24/7 email, chat, and phone access to an engineer; help with third-party software and operating system interoperability; full Trusted Advisor
Enterprise Business-critical workloads and serious outages the team can’t solve Full access to senior engineers plus a dedicated Technical Account Manager (TAM); $15,000 monthly minimum

Older pricing rules to know:

  • Developer: the greater of $29 or 3% of monthly AWS usage.
  • Business: the greater of $100 or a sliding scale of 10% of the first $10,000 of monthly usage, 7% from $10,000 to $80,000, 5% from $80,000 to $250,000, and 3% above $250,000.

Example: $11,000 of usage in one month on Business = (10% × $10,000) + (7% × $1,000) = $1,000 + $70 = $1,070 for that month.

Current plan lineup: Basic, Business Support+, Enterprise Support, and Unified Operations. The older Developer, Business, and Enterprise On-Ramp names are being retired. Always check the current AWS plan comparison page for exact prices.

Choose a plan by operational risk, not prestige: how bad is it if the workload fails, and how fast do you need a human expert? Quick decision rules:

  • Basic gives no personalized technical help, only account and billing support.
  • Developer fits individual developers working through setup problems before anything is deployed.
  • Business is the least expensive plan that helps with interoperability between AWS and third-party software or operating systems, and it gives round-the-clock engineer access for a major deployment even before launch.
  • Enterprise fits a serious, hard-to-diagnose outage, because the lower tiers reach only lower-level support professionals.

People who can help

  • Technical Account Manager (TAM): a cloud professional employed by AWS (Enterprise plan) who guides you through the planning and execution of your infrastructure.
  • AWS Professional Services: helps APN cloud professionals work alongside your own team to administer your cloud infrastructure. Its site also offers free material such as tech talk webinars, white papers, blog posts, and code snippets.
  • AWS Partner Network (APN): third-party consulting and technology partners with AWS expertise (Direct Connect links, for example, are offered through APN partners). The APN does not offer free documentation.

Documentation and self-help

  • AWS documentation: service guides, API and CLI references. A URL containing latest shows you are reading the current version.
  • Knowledge Center (repost.aws/knowledge-center): an FAQ that presents solutions to commonly encountered technical problems. Introductory guides live on the main documentation site instead.
  • AWS re:Post and the AWS discussion forums: community questions and answers.
  • Professional Services site (aws.amazon.com/professional-services): webinars, white papers, blog posts, and code snippets you can adapt (after you understand exactly what they do).
  • Security resources: the AWS Security Blog, AWS Artifact (compliance reports), and the Trust Center.

Trusted Advisor

Trusted Advisor checks your account against best practices in five categories:

Category Example finding
Cost optimization Instances running mostly idle
Performance Over-used resources
Security Open ports, missing MFA
Fault tolerance Data volumes that aren’t backed up
Service limits Usage close to a quota

A false positive is an alert for a state that you set up on purpose (for example, a port you intentionally left open). A false negative is the opposite: a green OK status for something that is actually failed or failing. Always review a recommendation before acting on it.

Lesson 3 terms to know

Basic, Developer, Business, Enterprise, Business Support+, Unified Operations, TAM, Professional Services, APN, Knowledge Center, re:Post, documentation, Trusted Advisor, cost optimization, performance, security, fault tolerance, service limits, false positive, and false negative.

Lesson 4 — Understanding the AWS Environment

Regions

A Region is a separate geographic area containing multiple Availability Zones. The most significant architectural benefits of AWS’s Region design are:

  • lower latency (place applications near your end users), and
  • compliance with local regulations (keep data in a specific country).

Fault tolerance usually comes from spreading resources across multiple AZs within one Region, not from using multiple Regions, and Regions are not what lowers AWS’s running costs.

Region codes follow the pattern area-direction-number. For example, us-east-1 is US East (Northern Virginia) and us-west-2 is US West (Oregon). AWS GovCloud is a Region with restricted access for U.S. government agencies and approved customers.

Most AWS resources are tied to one Region because they run on physical hardware, and that hardware has to live somewhere. When you launch an EC2 instance, it goes into the currently selected Region. Service endpoints follow the pattern service.region.amazonaws.com, such as rds.us-east-1.amazonaws.com.

Global services are not tied to one Region. The course treats IAM, S3, and CloudFront as globally based services (Route 53 is global too). Technically, each S3 bucket’s data is stored in a Region you choose, but S3 is managed from a global console and bucket names are globally unique.

Availability Zones and subnets

An Availability Zone (AZ) is one or more independently powered data centers running a wide range of hardware host types. Compare: an edge location runs data centers with uniform host types, and a Region covers all the data centers within a broad geographic area. AZ names add a letter to the Region code, such as us-west-2a.

AZ and subnet options in EC2 dialog boxes appear in random order. AWS does this so customers don’t all launch too many resources into too few zones (AZ names are also mapped differently for each account). When you launch an instance you choose its subnet (and therefore its AZ) yourself; there’s no default choice. Use AZ IDs such as use1-az1 when accounts must match physical locations.

A subnet is a block of IP addresses (a CIDR range such as 10.0.1.0/24) for use within a single AZ. A subnet can never span two AZs.

Reliability and high availability

  • Redundancy is the most effective strategy for reliability: remove single points of failure by running more than one of everything important. (Isolation helps security, and automation helps administration, but neither is the main reliability strategy.)
  • Load balancing orchestrates parallel resources and directs incoming user requests to healthy instances. It is what most directly drives high availability.
  • Auto Scaling keeps a predefined service level regardless of external demand or instance failures, by adding, removing, or replacing instances. It cares about the overall service, not any one resource.
  • The most effective and efficient way to make an EC2 web server resilient is to run parallel, load-balanced instances in multiple AZs within one Region. Multiple Regions are more than most applications need.

Edge locations and edge services

Edge locations are points of presence close to users that cache content and run network-edge services.

Service Purpose
CloudFront Content delivery network: reduced-latency access to content wherever users live
Route 53 Domain name registration, DNS, and traffic routing
AWS Shield Protection against DDoS attacks
AWS WAF Protects web applications from web-based threats
Lambda@Edge Uses Lambda to customize CloudFront behavior

Services such as RDS and EBS are not likely to benefit from edge locations, because they serve resources inside a Region rather than delivering content to end users.

Extension options: Outposts (AWS hardware in your own data center), Local Zones (AWS services near a city), and Wavelength (AWS inside 5G carrier networks).

Shared Responsibility Model

  • AWS is responsible for security of the cloud: buildings, hardware, networking, and patching the underlying virtualization software in AWS data centers.
  • The customer is responsible for security in the cloud: data, IAM, configuration, applications, and patching the operating system on EC2 instances.
  • For managed services, whatever the customer can control (application code and configuration settings) is the customer’s responsibility. Short version: “if you can edit it, you own it.”

Health and acceptable use

  • The Service Health Dashboard is one of the first places to look when troubleshooting a failing application, because it shows AWS service problems by Region.
  • The AWS Acceptable Use Policy lists the limits on how you may use your account and resources.

Lesson 4 terms to know

Region, Region code, AWS GovCloud, endpoint, global service, Availability Zone, AZ ID, subnet, CIDR, redundancy, single point of failure, load balancer, Auto Scaling, edge location, CloudFront, Route 53, AWS Shield, AWS WAF, Lambda@Edge, Outposts, Local Zones, Wavelength, Shared Responsibility Model, Service Health Dashboard, and Acceptable Use Policy.