Cloud Concepts and Shared Responsibility

Cloud computing is a usage model in which IT resources are not owned but borrowed only when needed, in the amount needed, and paid for based on usage. The time from request to availability is short, and billing stops the moment resources are returned. Fixing the required amount before deployment and purchasing equipment, and managing even power and air-conditioning in-house, are both on-premises approaches, and because the amount must be decided in advance, they lead to over-provisioning or capacity shortages. The description that the amount cannot be changed during the contract period is the opposite of the cloud premise that it can be increased or decreased later.

Pay-as-you-go is the principle of paying only for what you actually use, with no upfront payment and no long-term commitment. Because you can scale to actual demand rather than a forecast, it reduces the risk of over-provisioning. Lowering the unit price in exchange for committing to a usage level over a set term is Save when you commit; the unit price falling as usage increases is Pay less by using more; and bundling into a fixed monthly amount with no overage charges is Flat rate — all of these refer to different principles.

Pay less by using more is the principle that a tiered pricing structure is applied for things like S3 and data transfer, so that the per-GB unit price falls as usage increases. Lowering the unit price in exchange for committing to a usage level over a set term is Save when you commit, which Savings Plans exemplifies. Paying only for what was actually used, each time, is Pay-as-you-go, and bundling into a fixed monthly amount with no overage charges is Flat rate. The four principles serve different purposes, so they are not mutually exclusive and are used in combination.

Save when you commit is the principle that, as with Savings Plans, prices for compute or machine learning services are discounted in exchange for committing to a specific usage level over a 1-year or 3-year term. Fixing the monthly amount so no overage charges occur, with no carry-over mechanism, is Flat rate. A tiered structure in which the unit price falls as usage increases is Pay less by using more. Being able to stop at any time with no commitment is a property of Pay-as-you-go, which is the opposite premise of this commitment-based principle.

As of August 2026, the official list of exam guides places two certifications at Foundational: AWS Certified Cloud Practitioner (CLF-C02) and AWS Certified AI Practitioner (AIF-C01). Developer - Associate (DVA-C02) and Data Engineer - Associate (DEA-C01) are both Associate, and Advanced Networking - Specialty (ANS-C01) is Specialty. For certifications whose name ends with a level name, that is a useful clue, but Cloud Practitioner and AI Practitioner have no level name attached, so remember that these two are the Foundational ones.

CLF-C02 is the exam code for AWS Certified Cloud Practitioner. CLF stands for Cloud Practitioner, and the trailing C02 indicates the revision generation. The code for AWS Certified AI Practitioner is AIF-C01, for AWS Certified Developer - Associate it is DVA-C02, and for AWS Certified Data Engineer - Associate it is DEA-C01. Certification names are sometimes renamed, but the exam code does not change until it is revised, so checking the code is a reliable way to confirm whether study material is current.

The exam code for AWS Certified Solutions Architect - Professional is SAP-C02. SAA-C03 is the Associate level of the same Solutions Architect track, SOA-C03 is CloudOps Engineer - Associate, and SCS-C03 is Security - Specialty. The first three letters look similar and can be confusing, but it helps to remember that SAA corresponds to Associate and SAP to Professional.

The CLF-C02 Exam Guide sets Cloud Concepts at 24 percent, Security and Compliance at 30 percent, Cloud Technology and Services at 34 percent, and Billing, Pricing, and Support at 12 percent. So the largest is Cloud Technology and Services, and the smallest is Billing, Pricing, and Support. Being an entry-level certification, one might assume concepts get the most weight, but in fact the domain testing knowledge of services is the largest, followed by security. Study time allocation should follow this same ratio.

The SAA-C03 Exam Guide sets Design Secure Architectures at 30 percent, Design Resilient Architectures at 26 percent, Design High-Performing Architectures at 24 percent, and Design Cost-Optimized Architectures at 20 percent. The largest is designing secure architectures. It is easy to remember the four domain names by mapping them to the Well-Architected pillars, which shows they are ordered security, reliability, performance efficiency, and cost optimization.

The operations-focused Associate certification was renamed from SysOps Administrator to CloudOps Engineer, and its exam code also changed from SOA-C02 to SOA-C03. The last day to take the old code was September 29, 2025, and the new code started on September 30, 2025. Data Engineer - Associate and Machine Learning Engineer - Associate are not successors to the operations track; they are separate, newly established certifications in the data and ML domains respectively. DevOps Engineer - Professional is a pre-existing Professional-level certification at a different level.

AWS officially calls its own responsibility "Security of the Cloud," defined as protecting the infrastructure that runs all the services offered in the AWS Cloud — that is, the hardware, software, networking, and facilities. Addressing vulnerabilities in an application installed on an instance is the customer's responsibility when EC2 is chosen. Choosing data encryption options and granting permissions via IAM remain the customer's tasks no matter which service is chosen, and both belong on the "Security in the Cloud" side.

AWS states explicitly that "customer responsibility will be determined by the AWS Cloud services that a customer selects." This means the amount of configuration work a customer must perform, as part of their security responsibility, varies depending on the service chosen. A support plan determines how technical assistance is received and does not move the line of responsibility. Region and Availability Zone are about placement, and usage duration or spend are about billing — none of these determine the breadth of responsibility.

AWS officially states that for services requiring configuration such as EC2, the customer manages "guest operating systems (including updates and security patches), any application software or utilities installed on the instances, and configuration of the security groups." So applying patches to the OS is the customer's responsibility. For EC2, what AWS operates extends only to the physical infrastructure and the virtualization layer, not the OS inside the instance. A support plan is a contract for receiving technical assistance and does not shift where responsibility lies.

For abstracted or managed services, AWS states that "AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data." What remains with the customer is managing their own data (including encryption options), classifying assets, and applying appropriate permissions using IAM tools. The customer does not perform OS updates or operate the platform, but data classification and permission settings never leave the customer's hands, regardless of the service.

The line in the shared responsibility model is not fixed; it moves depending on the service chosen. For a service like EC2, where the customer manages the guest OS, patching is the customer's responsibility, but for a service like S3 or DynamoDB, where AWS operates all the way up through the OS and platform, it becomes AWS's responsibility. So neither "always AWS" nor "always the customer" is correct. Region is a placement choice and does not change the division of responsibility. Keeping this one point in mind lets you estimate the line for an unfamiliar service just by asking whether it leans toward EC2 or toward S3.

Facilities are explicitly listed under "Security of the Cloud" as part of the infrastructure that runs AWS Cloud services, so they are always AWS's responsibility regardless of which service is used. Customers cannot audit this area themselves or enter and inspect the facilities; instead they confirm it through the third-party certifications and audit reports AWS publishes. This corresponds to the control category called Inherited Controls among the three control classifications — the part that customers fully inherit from AWS. What moves depending on the chosen service is the OS and middleware layer, not the physical layer.

AWS explicitly states that managing one's own data (including encryption options), classifying assets, and applying appropriate permissions using IAM tools remain with the customer even when using abstracted services. Since this never leaves the customer regardless of the service chosen, it serves as a fixed point when thinking about where the line falls. Replacing a physical server and protecting the backbone network are matters of facilities and hardware, and are always on the AWS side. The OS underlying a managed service is operated by AWS, so applying patches to it is not the customer's task.

Inherited Controls are officially defined as controls the customer fully inherits from AWS, and physical and environmental controls fall into this category. Controls applied separately to both the infrastructure layer and the customer layer are Shared Controls, and controls that are entirely the customer's responsibility, such as service and zone security, are Customer Specific Controls. Inheritance flows in one direction, from AWS to the customer, not a relationship where AWS carries forward the customer's own settings.

AWS cites Patch Management, Configuration Management, and Awareness & Training as its three examples of Shared Controls. What they have in common is that the same activity is carried out in parallel at both the infrastructure layer and the customer layer — for patch management, for instance, AWS applies patches to its own infrastructure while the customer applies them separately to the guest OS and applications. Entry/exit controls, power redundancy, and hardware procurement and disposal are physical and environmental controls, which the customer inherits from AWS. Service and zone security is an example of Customer Specific Controls.

DynamoDB is an abstracted service, so AWS operates all the way through the infrastructure layer, the OS, and the platform. Guest OS patching, which the customer handled under EC2, becomes AWS's task after the migration. Meanwhile, classifying data, choosing encryption options, and granting permissions via IAM remain with the customer regardless of which service is chosen. Protecting the physical facility is already always AWS's responsibility, so it never shifts to the customer through migration. It helps to organize it as: what moves is the OS/platform layer, and what does not move is data and permissions.

The current pillars are the six of Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. Sustainability was added as the sixth pillar in 2021, so a list of only five pillars without it reflects outdated information from before the addition. Interoperability and Portability are not listed as pillars of the framework; neither appears in the official list. An explanation with an outdated pillar count is also likely to have outdated service names or exam codes, so it can serve as a marker for how current a piece of study material is.

Operational Excellence is the pillar that focuses on running and monitoring systems, and on continually improving processes and procedures. This includes automating deployments, updating procedures based on post-incident reviews, and making changes in small, frequent steps. Protecting information and systems is Security; optimizing resource allocation and selecting resource types is Performance Efficiency; and eliminating wasteful spending and right-sizing resources is Cost Optimization — all of these point to different pillars.

The Security pillar focuses on protecting information and systems, centered on data integrity and access control. Encryption and access control based on least privilege fall squarely under it. Stopping unused resources and right-sizing instances is Cost Optimization; automating deployment and updating runbooks after incident reviews is Operational Excellence; and measuring and reducing environmental impact is Sustainability. Most of what remains the customer's responsibility under the shared responsibility model is handled within this Security pillar.

Reliability is the pillar that focuses on a workload performing its intended function and on how quickly it recovers from failure. Distributing across multiple Availability Zones, automated recovery, and verifying backup and recovery procedures fall here. Its distinguishing feature is that it covers not just preventing breakage but also recovering quickly once something has broken. Optimizing resource allocation is Performance Efficiency; running, monitoring, and continually improving procedures is Operational Excellence; and minimizing environmental impact is Sustainability.

Performance Efficiency is the pillar that focuses on optimizing the allocation of IT resources and on selecting the resource type that fits the workload's needs. Reselecting a resource type to meet a requirement falls squarely under this. Cost Optimization can look like a similar activity, but its aim is eliminating wasteful spending, whereas here the motivation is meeting a latency requirement, so the focus differs. Reliability looks at resilience to failure and Operational Excellence looks at improving procedures — neither is the main concern here.

Cost Optimization is the pillar that focuses on eliminating wasteful spending and right-sizing resources against business requirements. Judgments such as stopping unused resources, correcting oversized instances, and choosing appropriate pricing models fall here. The point is not simply to minimize cost but to ask whether value is being obtained commensurate with spending. Protecting information and systems is Security; performing the intended function and recovering is Reliability; and minimizing environmental impact is Sustainability.

Sustainability is the pillar that focuses on minimizing the environmental impact of running a cloud workload. It is the newest pillar, added as the sixth in 2021, and its presence or absence marks the line between current and outdated study material. Optimizing resource allocation and selecting resource types is Performance Efficiency; running, monitoring, and continually improving procedures is Operational Excellence; and performing the intended function and recovering from failure is Reliability — all of these point to different pillars.

The missing one is Sustainability, the pillar covering minimizing the environmental impact of running a cloud workload. Because it was added as the sixth pillar in 2021, articles written before that still list only five. Operational Excellence, Performance Efficiency, and Reliability all existed before the addition, so they appear even in an article listing five pillars. When a basic fact like the number of pillars is out of date in an article, the rest of its content is also likely to be outdated.

The current pillars are the six of Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability, and Interoperability is not included in this list. Different systems being able to connect to one another is an important design concern, but the Well-Architected Framework does not set it up as a standalone pillar. Cost Optimization, Operational Excellence, and Performance Efficiency are all genuine members of the six. Memorizing a term not in the framework as if it were a pillar becomes a source of confusion when narrowing down answer choices.

Eliminating wasteful spending and right-sizing resources against business requirements is the focus of Cost Optimization, not Reliability. Reliability is the pillar that focuses on a workload performing its intended function and on how quickly it recovers from failure. The other three pairings match the official descriptions. Because pillar names sound close to everyday words, matching them by impression alone invites mistakes; memorizing them together with the one-sentence description of their focus prevents stumbling on this type of question.

A Region is a physical location in the world where AWS has multiple Availability Zones. Regions have names such as us-east-1 or ap-northeast-1, and are chosen based on data residency and regulatory requirements, distance from users, and pricing. A unit for isolating failures made up of one or more discrete data centers is the description of an Availability Zone. A location where CloudFront caches and delivers content is an Edge Location, and a zone placed inside a telecom carrier's network is a Wavelength Zone.

An Availability Zone is defined as consisting of one or more discrete data centers, each with redundant power, networking, and connectivity, and housed in separate facilities. The key points are that it is not the same as a single data center building but rather a grouping, and that it sits in a different building from other zones. An intermediate layer between an edge location and the origin is a Regional Edge Cache, and a place near a user's city for running applications describes Local Zones — both refer to different mechanisms.

AWS officially states that each Region is composed of "a minimum of three, isolated, and physically separate Availability Zones." Because the total number of Regions and zones keeps growing, memorizing those totals is of limited value, but the rule for how many zones a single Region has at minimum is stable and can be used directly as a design assumption. Being located within the same facility contradicts the definition of being housed in separate facilities. Zones are not something customers apply for to increase, nor is there just one per Region.

Edge locations are the worldwide network of data centers where CloudFront delivers content. Requests are routed to the edge location with the lowest latency, and delivery happens from there. The key point is that this is not a redundancy unit for increasing availability, but a caching location for redelivering content closer to the user. Isolating failures is the role of an Availability Zone, partitioning IP address ranges is the role of a subnet, and running applications inside carrier facilities is the role of Wavelength Zones.

A request is routed to the edge location with the lowest latency, and if the content is already there it is delivered immediately. If not, it is fetched from an origin — such as an S3 bucket or an HTTP server — delivered, and also stored in the cache. That is why subsequent requests can be returned directly from the nearby location. A missing cache entry does not turn into an error, nor is the user left waiting. Forwarding to an Availability Zone is a failure-isolation mechanism and is unrelated to the flow of content delivery.

A Regional Edge Cache is a caching layer positioned between an edge location and the origin. Its role is to reduce the number of times a request has to travel all the way back to the origin when it is not found at the edge. A management unit that groups Availability Zones is a Region, and zones placed inside a telecom carrier's network are Wavelength Zones — both are different concepts. Caching on the user's own device is not an AWS mechanism but a feature of the browser or OS.

An Availability Zone is a failure-isolation unit housed in a separate facility with redundant power and networking. Placing resources of the same role across multiple zones means that even if one zone goes down entirely, the rest can keep processing. This is a Multi-AZ configuration and is the starting point of availability design. Delivering from the nearest location is the role of an edge location; data residency is a factor in choosing a Region; and lowering the unit price through a usage commitment is a pricing matter — none of these is the motivation for splitting across zones.

Local Zones are a mechanism that lets applications run on AWS infrastructure closer to end users or workloads, placed in cities away from a Region. They resemble edge locations in dealing with "nearby," but the difference is that they run the application itself rather than serving as a content-delivery cache. Isolating failures within a Region is an Availability Zone, a delivery-only location is an edge location, and an intermediate cache in front of the origin is a Regional Edge Cache.

Wavelength Zones are zones placed inside a telecommunications carrier's network. Like Local Zones, they are a mechanism for running the application itself close to users, which differs in purpose from an edge location, a delivery point for a content cache. Placed between an edge location and the origin is a Regional Edge Cache; a failure-isolation unit within a Region is an Availability Zone; and partitioning the IP address range of a VPC is a subnet.

An Availability Zone is a failure-isolation unit housed in a separate facility, so preparing for an entire zone going down requires placing resources across zones. Because each Region is composed of at least three isolated zones, distributing across multiple zones within the same Region is possible. Adding more servers within the same zone does not meet the requirement, since if that zone goes down, all of them go down together. CloudFront speeds up delivery, but if the origin stops, dynamic processing cannot continue. Changing the pricing plan is a cost matter unrelated to availability.