AWS Certified Cloud Practitioner Training Course

More questions on this exam depend on the shared responsibility model than on any other single concept. It is worth learning precisely, because the wrong version of it — "AWS handles security" — produces confidently wrong answers.

The two halves

AWS states the model as a division between security of the cloud and security in the cloud.

AWS is responsible for security of the cloud. That means the infrastructure that runs every AWS service: the physical data centers and their access controls, the hardware, the host operating system and virtualization layer, and the network infrastructure connecting it all. You cannot audit an AWS data center yourself, you cannot patch a hypervisor, and you do not manage the physical destruction of failed disks. AWS does those things and demonstrates that it does them through third-party audits and compliance reports.

You are responsible for security in the cloud. That means everything you put into the services and everything you configure about them: your data, your guest operating systems and their patches where applicable, your application code, your identity and access management configuration, your network and firewall configuration, and your encryption choices. AWS gives you the controls; using them is your job.

The clearest way to remember it

AWS secures the infrastructure that the service runs on. You secure how you use the service. Every specific case is a consequence of that sentence.

What is always yours

Three responsibilities never transfer, whatever service you choose, and they are the safest answers when a question asks what remains with the customer.

• Your data. AWS never decides what data you store, how it is classified, who may see it, or whether it should be encrypted. You own the data and the decisions about it.
• Identity and access management. Who has an account, what permissions they hold, whether multi-factor authentication is required, and whether old credentials are removed — all customer configuration. AWS supplies IAM; it does not decide your policies.
• Configuration of the services you use. If you make a storage bucket publicly readable, or open a firewall rule to the entire internet, AWS will do exactly what you configured. The controls to prevent both exist and are yours to apply.

The boundary moves with the service

The line is not in a fixed place. It moves depending on how much of the stack the service operates, which is the same spectrum as infrastructure, platform, and software as a service.

Consider three examples of a database, since this is the comparison the exam uses most.

• A database you install on Amazon EC2. AWS operates the physical host and hypervisor. You are responsible for the guest operating system — including patching it — the database engine and its patches, its configuration, its backups, network controls, and the data. This is the largest customer share.
• Amazon RDS. AWS operates the host, the guest operating system, and the database engine installation and patching, and it runs backups you configure. You remain responsible for the data, for who may access the database, for the network controls around it, for encryption settings, and for the schema and queries. A noticeably smaller customer share.
• Amazon DynamoDB or Amazon S3. There is no operating system or engine for you to see at all. Your responsibility narrows almost entirely to access control, encryption configuration, and the data itself.

The exam phrasing to watch for is "who patches the guest operating system." On EC2 it is you. On RDS, Lambda, DynamoDB, and S3 it is AWS. That one question separates a large share of the items in this domain.

Inherited, shared, and customer-specific controls

AWS describes three categories of control, and the vocabulary appears in compliance discussions.

• Inherited controls are ones you get entirely from AWS — physical and environmental controls in a data center, for example. You inherit them and cite AWS's audit reports as evidence.
• Shared controls apply to both layers, with each party doing its part. Patch management is the standard example: AWS patches its infrastructure, you patch your guest operating systems and applications. Configuration management, awareness and training, and each party managing its own personnel are also shared.
• Customer-specific controls are entirely yours, based on the workload — for example, classifying data, or protecting a particular category of regulated information within your application.

Compliance is shared too

AWS achieving a compliance certification does not make your workload compliant. What it does is remove the infrastructure layer from the scope of your own audit and give you evidence to hand to an auditor. You still have to demonstrate that what you built on top meets the requirement. This is why AWS Artifact exists — it is the self-service portal where you download AWS's audit reports and certifications — and why passing your own audit still requires your own controls, logging, and evidence.

A related point that is frequently tested: AWS never has visibility into or responsibility for the contents of your data. The provider operates infrastructure; the customer operates the workload.

Working through a scenario

Suppose a company runs a web application on EC2 instances, storing files in Amazon S3, with a managed database on Amazon RDS. Assign the responsibilities.

• Physical security of the data centers, and the hypervisor — AWS.
• Patching the operating system on the EC2 instances — customer.
• Patching the RDS database engine — AWS, within the maintenance window the customer configures.
• Deciding whether the S3 bucket is public — customer.
• Deciding whether data is encrypted, and managing the keys if the customer chooses to — customer, using AWS-supplied key management.
• Configuring security groups to limit inbound traffic — customer.
• Replacing a failed physical disk and securely disposing of it — AWS.
• Setting IAM permissions for the application's role — customer.

Notice that the customer's list is longer, and that most of the items on it are configuration decisions rather than maintenance labor. That is the honest summary of what the cloud does to security work: it removes a great deal of physical and low-level operational responsibility, and it concentrates what remains into configuration that is fast to change and, for the same reason, fast to get wrong. The rest of this module is about the controls AWS provides for the customer half of the line.