Cloud Fundamentals & Infrastructure

Choose where a system runs—and what happens when it fails

A shop wants to handle a seasonal traffic spike, serve customers in another country, and recover when infrastructure fails. “Move it to the cloud” does not answer any of those requirements on its own.

This lesson turns those goals into three decisions: how capacity changes, where components live, and what evidence supports the availability and cost claims. You should leave able to read an AWS location diagram, identify a shared failure dependency, and calculate an illustrative cost comparison without treating it as a forecast. AWS details were checked 14 September 2026.

1. Cloud changes how capacity is obtained

Cloud computing gives access to configurable computing resources over a network, with rapid provisioning and measured use. In the NIST definition, five characteristics work together:

NIST cloud definition

Scalability is the ability to handle changing load by changing capacity. Elasticity adds responsive expansion and contraction. Neither means infinite capacity: quotas, scaling speed, application design and downstream services still matter. An EC2 Auto Scaling group can automate changes even though you manage its instances' software.

Compare a fixed fleet with a variable fleet. If demand drops but ten instances keep running, cloud billing still includes them. Cloud makes releasing capacity possible; your architecture and operating process must use that ability. A queue can absorb a burst while workers catch up, provided processing delay fits the requirement. EC2 Auto Scaling

Service model and deployment model answer different questions

IaaS—Infrastructure as a Service—supplies infrastructure such as EC2; the customer manages the guest OS and application. PaaS—Platform as a Service—adds a managed application platform. SaaS—Software as a Service—delivers an application for customers to use and configure. These labels describe responsibility and abstraction, not a guarantee of low cost or complete security.

A public cloud serves customers through a provider's cloud infrastructure; your private VPC and data can still have restricted access. A private cloud is for one organization's exclusive use and can be on or off premises. A dedicated server alone is not necessarily a cloud. A hybrid architecture, in common AWS usage, integrates on-premises environments with cloud services—for example, an existing factory system exchanging data with AWS through suitable connectivity.

NIST also defines community cloud for organizations with shared concerns, and defines hybrid cloud more specifically as connected distinct cloud infrastructures. “Public/private/hybrid” is a useful first comparison, not an exhaustive universal list. Multiple providers is multicloud, a separate dimension: an architecture can be both hybrid and multicloud. AWS deployment-model overview

Private does not automatically mean more secure, and public does not automatically mean cheaper. Compare the actual controls, people, usage and requirements. Direct Connect and Storage Gateway can support hybrid designs; they are services, not deployment models by themselves.

2. Read location names as failure boundaries

Regions, AZs and edge locations are not interchangeable. Nor is every AWS facility a child of a customer VPC. The supported services, zone offerings and available capacity differ; consult the current AZ information instead of memorizing a fixed worldwide count. AWS currently describes every Region as having at least three AZs, but the AZs accessible to an individual account can be fewer.

An AZ name such as us-east-1a can map differently across accounts; an AZ ID identifies the physical AZ consistently. A subnet occupies one AZ. Deploying to us-east-1 and us-east-2 uses two Regions, while two available AZs within us-east-1 form a Multi-AZ design. Multi-Region designs can serve availability, disaster recovery or global latency goals; they are not categorically wrong for high availability. They add replication, routing, testing and operating complexity. AZ IDs

Choose a Region from requirements

For the shop, first identify permitted data locations and required services. Then measure representative user-to-application latency and compare relevant prices, capacity and quotas. Geographic distance is a clue, not a latency measurement. A Region's age alone is not a reliable selection rule.

Placing compute in a Region does not prove that every backup, log, global service or replication target stays there. Inspect the behavior and configuration of each service. Region isolation is a design property, not a promise that any fault is physically impossible. Regional services

3. Trace a request before adding more Regions

For cacheable product images, the path is conceptually:

Viewer → CloudFront edge
         ├─ usable cache entry → response to viewer
         └─ origin needed → origin request → response (possibly cached)

The first request you personally make might already find a shared cache entry. A later request can still need the origin because the entry expired, the cache key differs, or the response is not cacheable. Caching static assets does not remove the latency of a live database transaction. How CloudFront serves content

Route 53 provides DNS and routing policies. Latency-based routing selects among configured regional resources using latency information; it does not authenticate players or automatically deploy servers. Global Accelerator can improve network routing to supported endpoints; it is not an object cache. Measure the complete request path rather than promise the same millisecond latency everywhere. Route 53 latency routing

4. Design for one concrete failure

Suppose the shop requires continued service after losing one AZ. Here is a conceptual serving design, not an exact placement or provisioning diagram:

                  Application Load Balancer
                    /                 \
             app in AZ A         app in AZ B
                    \                 /
                      DB endpoint
                           |
                RDS primary in AZ A
                           |
                  synchronous replication
                           v
                RDS standby in AZ B

Application requests reach app targets through the load balancer; the applications use the database endpoint. The load balancer does not route SQL traffic from the web tier into RDS. In this example, RDS is a Multi-AZ DB instance deployment, with a standby for failover rather than a read-serving replica. Other RDS deployment types differ. RDS Multi-AZ DB instances

If AZ A fails, several mechanisms must work together:

1. Health checks identify unhealthy app targets and traffic is directed to healthy targets in AZ B. Detection takes time; verify the load balancer's behavior for your target-health conditions.
2. AZ B needs enough working capacity. Redundancy without capacity headroom can still fail under load.
3. RDS can promote the standby and update the database endpoint's DNS record. Existing database connections must reconnect. AWS describes typical 60–120 second failovers for this deployment type, with longer recovery possible.
4. The application needs bounded retries, connection recovery and sensible handling of uncertain transaction outcomes. External sessions, files and other dependencies must survive too.

An interrupted response does not always mean the transaction failed. Design payment or order retries to avoid duplicating a successful operation. Replication also does not protect against every logical deletion or application bug: keep and test recovery procedures. RDS failover behavior

Availability targets are not automatic rewards

A service-level objective (SLO) is a target for your service. An AWS service-level agreement (SLA) specifies a particular service commitment, measurement and conditions, including any credit remedy. Adding a second AZ does not grant every application 99.99% uptime; adding a second Region does not grant 99.999%.

For intuition only, assume a 365-day year and uniform time-based availability:

The calculation is 365 × 24 × 60 × (1 − availability) minutes. These are annual illustrative budgets, not AWS SLA measurement windows or promised outage durations. Many application SLOs instead measure successful requests. Check the Compute SLA for its actual service scope and monthly definitions.

Try it: imagine removing the standby from the diagram, leaving two app servers but only the database primary and no other recovery path. Which dependency defeats the AZ-survival goal? Check: the single-AZ database remains a critical failure dependency; duplicating app servers alone does not solve it.

5. Keep responsibility attached to the actual service

AWS protects its underlying cloud infrastructure. Customers still control data, identities, permissions and their application's behavior. For EC2, guest OS and application patching are customer tasks. With RDS, AWS operates the managed infrastructure, while customers choose database settings, access, appropriate backup retention and recovery procedures. With Elastic Beanstalk, managed platform features help, but customers still need supported versions, update policies and testing.

A blanket diagram saying “AWS manages all security” is wrong for SaaS too: customer accounts, configuration and data handling still matter. Likewise, a blanket “customer patches every OS” ignores managed-service boundaries. AWS shared responsibility, Beanstalk platform maintenance

6. Calculate costs from explicit assumptions

Cloud adoption can shift spending from buying equipment (CapEx) toward paying for consumed services (OpEx). It does not eliminate every upfront cost, commitment or operational task. For planning, include staff work, migration, software, connectivity and recovery capacity as well as compute. Accounting treatment depends on the arrangement; this is an infrastructure-cost comparison, not an accounting rule.

Here is a deliberately simplified worksheet. All rates are invented teaching inputs, not AWS quotes. Assume the two options deliver the required amount of useful work:

traditional = 100 * 5000          # 100 servers at $5,000/year
baseline = 10 * 1500              # 10 committed units at $1,500/year
variable = 2800 * 12              # average variable charge per month
cloud = baseline + variable
savings = traditional - cloud
percent = savings / traditional * 100
print(traditional, cloud, savings, round(percent, 2))

Check: traditional = $500,000; baseline = $15,000; variable = $33,600; cloud = $48,600; difference = $451,400, or 90.28%. The percentage describes these inputs only. If useful-work equivalence or missing cost categories are wrong, the conclusion changes. A 30% utilization figure alone does not prove that exactly 70% of total ownership cost is recoverable waste.

Sensitivity check: if the variable charge doubles to $5,600/month, cloud becomes $82,200, and the difference becomes $417,800, or 83.56%. The model makes it possible to challenge the claim instead of trusting a success story.

Review these often-missed items before estimating a real system:

• Provisioned capacity that remains idle, and minimum running capacity.
• Storage, snapshots, object requests and archival retrievals.
• Data transfer along the actual path, with service-specific pricing and exceptions.
• NAT processing, public IPv4 addresses and paid endpoint types.
• Redundancy, monitoring, support, staff effort and commitment utilization.

An Internet Gateway itself has no hourly gateway charge. An S3 gateway endpoint can avoid a NAT path for suitable traffic; interface endpoints have different pricing. Replacing a route is not a universal way to eliminate all network costs. Use the VPC pricing page and AWS Pricing Calculator for a dated real estimate.

Make a defensible decision

For the shop, write a short recommendation with a proposed Region, a measured latency question, the failure to tolerate, the recovery mechanism, and the missing cost inputs. A useful answer explains why the pieces satisfy the requirement and what still needs testing.

The next lesson compares service models in more detail: how much operating responsibility to keep, and when EC2, managed platforms, serverless compute or a finished SaaS product fit the job.