1 Cloud Concepts and AWS Fundamentals
Learn how cloud computing works, how AWS organizes and secures its infrastructure, and how to apply core cloud benefits and design principles.
and service models
provides on-demand access to IT resources—including compute, storage, databases, and applications—over a network. It commonly uses pay-as-you-go pricing, so an organization can provision resources when needed and adjust them as demand changes instead of buying and maintaining all physical infrastructure in advance.
Cloud services differ in how much of the technology stack the provider manages:
: The provider supplies foundational resources such as virtual servers, storage, and networking. Customers retain substantial control over the operating system and applications; Amazon EC2 is an example.
: The provider manages more of the underlying platform, allowing customers to focus primarily on deploying and managing applications.
: The provider delivers a complete application, typically for use through a browser or app.
Cloud deployments may use a public cloud, a private cloud dedicated to one organization, or a hybrid approach that connects cloud resources with environments the organization operates itself.
AWS global infrastructure
AWS organizes much of its infrastructure into Regions and Availability Zones. A is a separate geographic area containing multiple AZs. An AZ consists of one or more discrete data centers with redundant power, networking, and connectivity. Distributing a workload across AZs can improve availability and fault tolerance compared with relying on one data center.
AWS also provides infrastructure closer to end users or particular workloads, including Local Zones, Wavelength Zones, and edge locations. These can support use cases that need lower latency or local processing.
Choose a by considering proximity to users, required services, and legal or operational requirements. Service availability can vary by , so check that the services a workload needs are offered in the intended location.
For example, a company might run an application in a near most of its customers to reduce network latency, then distribute key components across multiple AZs to reduce the impact of an AZ-level disruption.
Shared responsibility for security
The separates AWS responsibilities from customer responsibilities. AWS is responsible for security of the cloud: protecting underlying infrastructure, including facilities, hardware, networking, and the virtualization layer. Customers are responsible for security in the cloud, with specific duties depending on the services they choose.
For an EC2 virtual machine, the customer manages tasks such as the guest operating system, its patches, installed applications, and security group configuration. With more abstracted services such as Amazon S3 or Amazon DynamoDB, AWS manages more of the underlying platform, but customers still manage their data, permissions, and relevant security settings. Using a managed service shifts responsibilities according to the service and configuration; it does not make customer responsibility disappear.
Cloud benefits and their limits
can provide several operational benefits:
Agility: Provision resources quickly to make it easier to experiment and respond to changing needs.
: Scale resources up or down as demand changes instead of permanently sizing infrastructure for a peak that may rarely occur.
Pay-as-you-go use: Avoid some large upfront hardware purchases and pay according to the applicable service pricing and usage.
Global reach: Deploy in different geographic locations to serve users closer to where they are and address location requirements.
Less infrastructure maintenance: The provider manages the physical cloud infrastructure, leaving customers more time to focus on applications and business needs.
These are benefits to plan for, not automatic guarantees. Resources can still be misconfigured, oversized, or left running unnecessarily, so customers must design and manage workloads deliberately.
Cloud design principles
AWS Well-Architected guidance highlights principles for designing in the cloud:
Stop guessing capacity needs. Use adjustable capacity and scale resources in or out as demand changes.
Test at production scale. Create realistic test environments when needed, then remove them when testing is complete.
Automate and experiment. Automating infrastructure and repeatable changes makes it easier to test ideas, track changes, and revert when necessary.
Evolve the architecture. Revisit design decisions as requirements and available technology change rather than treating the initial architecture as permanent.
Use data to guide decisions. Observe workload behavior and use evidence to decide what to improve.
Practice for failures. Run planned exercises, sometimes called game days, to test how systems and teams respond to disruptions.
For example, a ticketing site expecting a large temporary traffic spike can design for scaling rather than buying enough servers for the peak year-round. It can monitor demand, test the scaling approach, and remove unneeded capacity afterward.