The shared responsibility model

On the Monday after the board meeting, Gwen Halvorsen drew two boxes on the whiteboard in the Calgary head office: a large one labelled AWS and a smaller one labelled Cascade Ridge. Mateo Ruiz, who had looked after the clinics' computers for six years, expected a lecture about firewalls. Instead Gwen asked a simpler question. "When the server room overheated in July, whose problem was it?"

"Mine," Mateo said. "The air conditioner, the server, the operating system, the backups, the practice software. All of it."

"After we move, some of that becomes Amazon's problem and some of it stays yours," Gwen said. "Security on AWS starts with knowing exactly where that line is. Most cloud breaches you read about are not someone breaking into Amazon's data centres. They are customers leaving their own side of the line open."

That line has a name: the shared responsibility model. It is the first idea in the security domain of the AWS Certified Cloud Practitioner exam, and it shapes every other lesson in this course. This lesson explains what AWS is responsible for, what the customer is responsible for, what the two share, and why the line moves depending on which service you use.

Security of the cloud and security in the cloud

AWS describes the split in two short phrases. AWS is responsible for security of the cloud: the infrastructure that runs every AWS service. The customer is responsible for security in the cloud: everything the customer puts on that infrastructure and every setting the customer chooses.

Security of the cloud covers the physical world and the software that runs the services. AWS guards the data centre buildings, controls who can walk into them, and destroys old disks so data cannot be recovered. It maintains power, cooling and fire suppression, the very things that failed in the Cascade Ridge server room. It runs the network that links Availability Zones and Regions, and it operates the virtualization layer that keeps one customer's virtual machines separated from another's. When a flaw is found in the hypervisor or in the hardware of a managed service, AWS patches it.

Security in the cloud covers the customer's choices. The customer decides who can sign in to its AWS accounts and what each person may do. The customer decides whether a storage bucket is private or public, whether a database is encrypted, which network ports are open, and whether logs are kept. The customer owns its data and chooses where it lives. AWS never decides any of these on the customer's behalf, although it provides tools and safe defaults that make good choices easier.

A useful test is to ask who can change the thing in question. Mateo cannot change the locks on an AWS data centre, so that is AWS's responsibility. He can change a security group rule, an IAM policy or the encryption setting on a disk, so those are his. If you can configure it, you are responsible for configuring it well.

What AWS is responsible for

AWS's side of the model includes several layers, and exam questions often name one of them and ask whose job it is.

• Physical security of facilities. Guards, cameras, access badges, visitor logs and controlled destruction of storage media.
• Environmental controls. Power, backup generators, cooling and fire detection and suppression.
• Hardware. Servers, storage devices and network equipment, including replacing failed parts.
• The global network. The links between Availability Zones, Regions and edge locations.
• The virtualization layer. The hypervisor that isolates customer virtual machines from each other and from the host.
• The software of managed services. For services such as Amazon RDS or AWS Lambda, the operating systems and platforms underneath that AWS runs on the customer's behalf.

AWS proves that it does these things through independent audits. Lesson 11 shows where to download the audit reports. For now, the important point is that a customer inherits these controls. Cascade Ridge does not need to hire security guards for its data, because the AWS facilities already have them, and an auditor can read AWS's reports to confirm it.

What the customer is responsible for

The customer's side is larger than many newcomers expect. Gwen wrote this list on the whiteboard, and Mateo copied it into the project plan.

• Customer data. What is stored, how it is classified, who may read it, how long it is kept, and whether it is backed up.
• Identity and access. Who has accounts, which permissions they hold, whether multi-factor authentication is on, and how the root user is protected.
• Encryption choices. Whether data is encrypted at rest and in transit, and who controls the keys.
• Network settings. Security groups, network access control lists and which resources are reachable from the internet.
• Operating systems on virtual machines. Patching the operating system and installed software on Amazon EC2 instances.
• Applications. The security of the customer's own code, such as the BookVet booking app, and its settings.
• Logging and monitoring choices. Turning on the services that record activity and reading what they find.

Kwame Asante, who wrote BookVet, asked whether AWS would at least fix bugs in his code. Gwen laughed kindly. "AWS will keep the server under BookVet patched if we let a managed service run it. AWS will never review your Python. If your login page has a flaw, that stays your flaw, in the cloud or anywhere else."

Shared controls

Some controls belong to both parties, each in its own layer. AWS calls these shared controls, and three examples come up often.

Shared controls catch people out because the same word, such as patching, appears on both sides. The question to ask is always: patching what? AWS patches the host and the platforms it manages. The customer patches anything it installed or manages itself.

How the line moves between services

The model is not one fixed line. It moves depending on how much of the stack the customer manages, and the exam guide names three services to illustrate it: Amazon EC2, Amazon RDS and AWS Lambda.

With Amazon EC2, the customer rents a virtual machine. AWS provides the hardware and the hypervisor; everything from the operating system upward is the customer's. If Mateo runs the VetLedger application servers on EC2 instances, he must patch Windows Server on them, configure the Windows firewall, install anti-malware software and manage the application.

With Amazon RDS, AWS runs the database engine for the customer. AWS patches the operating system under the database, installs database engine updates during a maintenance window the customer chooses, and runs the backups the customer configures. The customer still chooses who can connect, which network can reach the database, whether storage is encrypted, how long backups are kept, and of course what data goes into the tables. This is one reason Gwen recommended moving the VetLedger database to RDS for SQL Server: a whole category of night-time patching moves to AWS.

With AWS Lambda, the customer uploads code and AWS runs it when an event arrives. There is no server or operating system for the customer to manage at all. The customer is still responsible for the code, for the permissions the function has, for any secrets it uses and for the data it touches. When Kwame rewrites parts of BookVet as Lambda functions in phase two, his responsibilities shrink but do not disappear.

The pattern generalizes to other services. Infrastructure services such as EC2 leave the most with the customer. Container and managed platform services move the operating system to AWS. Abstracted or serverless services, such as Amazon S3, Amazon DynamoDB and Lambda, leave the customer responsible mainly for data, access settings and code. The one thing that never moves is the data itself: the customer always decides what is stored and who can see it.

Why the model matters for compliance

Hannah Weiss, Cascade Ridge's privacy and security lead, joined the second half of the session with a practical question. Under PIPEDA and the Alberta and B.C. private-sector privacy acts, we are accountable for our clients' personal information even when a service provider holds it. Does moving to AWS hand that accountability to Amazon?"

"No," Gwen said. "It hands Amazon some of the controls, and Amazon proves those through its audits. Accountability for the data stays with us. The model is how we explain to an auditor which controls we inherited from AWS and which ones we run and must evidence ourselves."

This is how organizations use the model in practice. When an auditor asks how physical access to the servers holding pet records is controlled, Cascade Ridge points to AWS's independent audit reports. When the auditor asks who can read those records, Cascade Ridge must show its own IAM policies, its sign-in logs and its access reviews. Both answers are needed, and neither party can give the other's.

# Who is responsible? A tiny lookup that mirrors the lesson's grid.
layers = ["data and access", "application code", "operating system patches",
          "database engine", "hardware and facility"]
model = {
    "Amazon EC2": ["customer", "customer", "customer", "customer", "AWS"],
    "Amazon RDS": ["customer", "customer", "AWS", "AWS", "AWS"],
    "AWS Lambda": ["customer", "customer", "AWS", "not used", "AWS"],
}
for service, owners in model.items():
    mine = [l for l, o in zip(layers, owners) if o == "customer"]
    print(f"{service}: customer manages {len(mine)} of {len(layers)} layers -> {', '.join(mine)}")

Amazon EC2: customer manages 4 of 5 layers -> data and access, application code, operating system patches, database engine
Amazon RDS: customer manages 2 of 5 layers -> data and access, application code
AWS Lambda: customer manages 2 of 5 layers -> data and access, application code

The model applies to resilience too

The same split applies to keeping systems running, not only to keeping them secure. AWS is responsible for the resilience of its infrastructure: building Regions with several isolated Availability Zones, replacing failed hardware and keeping services within their published service levels. The customer is responsible for designing its workloads to use that resilience. If Cascade Ridge runs VetLedger on a single EC2 instance in one Availability Zone, an outage in that zone takes the practice system down, and that design choice is Cascade Ridge's. Dr. Simone Kaur, the medical director, cared about this more than anything else in the meeting. "At three in the morning," she said, "I do not care whose fault the outage is. I care that the emergency team can see the patient's history." Gwen promised that the design would spread the system across Availability Zones, and noted it as a customer responsibility in the plan.

Common traps on exam questions

Scenario questions about the model usually describe a task and ask who performs it. A few patterns repay attention.

By the end of the session the whiteboard had a third column. Mateo had written "ours" beside eleven items and "theirs" beside six. "Fewer air conditioners," he said, "and a lot more settings." Gwen nodded. "Settings are where the next eleven lessons live."