Module 4: Shared Responsibility Model, Security, and Compliance

Step 1 – Why Security & Compliance Matter on AWS (CLF-C02 Focus)

In the AWS Certified Cloud Practitioner (CLF-C02) exam, Security and Compliance is one of the highest‑weight domains. This module connects what you learned about AWS value and architecture (Modules 2–3) to who does what in the cloud.

In about 15 minutes, you will be able to:

• Explain the AWS shared responsibility model and apply it to different service types (IaaS, managed services, serverless).
• Use core security concepts: least privilege, encryption at rest and in transit, and basic network protection.
• Identify key AWS compliance and governance resources (especially AWS Artifact and the AWS Compliance Center) and why they matter for regulated industries (e.g., healthcare, finance, public sector).

> Mental model: Think of AWS as the building owner and you as the tenant organization. AWS secures the building; you secure what you put inside and how you use it. The exact split changes depending on the type of service you use.

Step 2 – The AWS Shared Responsibility Model: Core Idea

The AWS shared responsibility model defines who is responsible for what in the cloud.

At a high level:

• AWS is responsible for _security *of* the cloud_

Protecting the infrastructure that runs all AWS services.

• Customers are responsible for _security *in* the cloud_

Protecting what they put in the cloud and how they configure it.

Security of the cloud (AWS responsibilities)

AWS is responsible for:

• Physical security of data centers (access control, surveillance, environmental controls).
• Hardware and facilities (servers, storage, networking equipment, power, cooling).
• The global network that connects AWS regions and Availability Zones.
• The hypervisor and foundational virtualization layer for compute services (e.g., Amazon EC2).
• The managed control plane of services (e.g., the S3 service itself, IAM service backend, DynamoDB service backend).

Security in the cloud (Customer responsibilities)

You (the customer) are responsible for:

• Data: classification, labeling, access control, backups, retention.
• Identity and access management: users, groups, roles, permissions (IAM policies).
• Application security: code quality, secrets management, input validation.
• Network configuration: security groups, NACLs, VPC design, firewall rules.
• Operating system and application configuration (when applicable): patching, hardening, antivirus.

> For CLF-C02: You do not need to memorize every detail, but you must clearly distinguish security of the cloud (AWS) vs security in the cloud (customer) and apply the idea to different service types.

Step 3 – Comparing Responsibilities by Service Type

Responsibilities change depending on how managed the service is. Use this as a mental ladder from most customer control to most AWS-managed.

1. Infrastructure as a Service (IaaS) – Example: Amazon EC2

You launch a virtual machine.

• AWS: Data center, physical hosts, networking, hypervisor.
• You:
• Choose the OS (e.g., Amazon Linux, Windows Server).
• Patch the OS and install security updates.
• Configure the firewall (security groups) and OS-level firewall.
• Manage IAM roles attached to EC2.
• Encrypt EBS volumes (you choose keys and policies).

2. Managed Services – Example: Amazon RDS (managed database)

AWS runs the database engine for you.

• AWS:
• Underlying EC2 instances, storage, and networking.
• Database software installation and patching of the RDS-managed engine.
• Automated backups (if enabled) and multi-AZ replication infrastructure.
• You:
• Choose DB engine and version.
• Configure DB-level users and permissions.
• Decide whether to enable encryption at rest.
• Set security groups and VPC settings.
• Secure application queries and credentials.

3. Fully Managed / Serverless – Example: AWS Lambda, Amazon S3

You focus on code (Lambda) or objects (S3), not servers.

• AWS:
• All server provisioning, OS, runtime, and scaling.
• The S3 and Lambda service infrastructure.
• You:
• Your code (Lambda) and how it handles data.
• IAM policies for who/what can access S3 buckets or invoke Lambda.
• S3 bucket policies, public access settings, versioning, and lifecycle.
• Enabling encryption and choosing keys.

> Rule of thumb: The more AWS manages, the less you manage the underlying infrastructure, but the more critical your configuration choices become. Misconfigured S3 buckets or IAM policies are common exam and real-world pitfalls.

Step 4 – Classify Responsibilities (Thought Exercise)

For each scenario below, decide whether it is AWS or Customer responsibility. Then check yourself with the provided answers.

1. Replacing a failed hard drive in an AWS data center
2. Ensuring an S3 bucket with medical records is not publicly readable
3. Patching the operating system on an EC2 instance
4. Maintaining compliance certifications like ISO 27001 for the AWS infrastructure
5. Configuring password policies for IAM users
6. Deciding which AWS Region to store EU customer data in, to meet GDPR obligations

Scroll down for answers (try first without looking).

---

Answers

1. AWS – Physical hardware maintenance is part of security of the cloud.
2. Customer – S3 access configuration is security in the cloud.
3. Customer – On EC2, you manage the guest OS.
4. AWS – AWS maintains many baseline certifications for its cloud infrastructure.
5. Customer – IAM configuration is your responsibility.
6. Customer – You are responsible for data residency decisions and regulatory obligations.

Step 5 – Core Security Concepts: IAM & Least Privilege

At the heart of AWS security is Identity and Access Management (IAM).

IAM basics (conceptual)

• Identities: IAM users, groups, roles, and AWS accounts.
• Policies: JSON documents that define who can do what on which resources.
• Principle of least privilege: Give identities only the permissions they need, only for as long as they need them.

Applying least privilege

Instead of:

• Giving a user `AdministratorAccess` for convenience.

You should:

• Create a policy that allows only specific actions (e.g., `s3:GetObject` and `s3:PutObject`) on specific resources (e.g., one bucket or prefix).

Example scenario

A data analyst needs to read data from one S3 bucket (`my-company-analytics`) but not delete or list objects in other buckets.

• Good practice: Attach a policy that allows only `s3:GetObject` on `arn:aws:s3:::my-company-analytics/*`.
• Bad practice: Attach a policy that allows `s3:` on `` (all actions on all S3 buckets).

> For CLF-C02: You don’t need to write complex JSON policies, but you should recognize least privilege as a best practice and know that IAM is the main tool to implement it.

Step 6 – Example IAM Policy for Least Privilege (Conceptual)

Here’s a simple IAM policy that grants read-only access to a single S3 bucket. Focus on the structure and the idea of limiting actions and resources.

```json

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"s3:GetObject"

],

"Resource": "arn:aws:s3:::my-company-analytics/*"

}

]

}

```

Key points:

• `Effect: "Allow"` – This policy grants permissions (not denies).
• `Action` – Only `s3:GetObject` (read objects). No delete, upload, or list.
• `Resource` – Limited to one bucket and its objects (`my-company-analytics`).

In the exam, if you see a question about restricting access to a subset of resources, think about:

• IAM policies (who can call which APIs), and
• Least privilege (only needed actions, only needed resources).

Step 7 – Encryption at Rest, In Transit, and Basic Network Protection

AWS expects you to know the concepts, not crypto math.

Encryption at rest

Data is encrypted where it is stored (on disk, in backups, in database storage).

AWS examples:

• Amazon S3: Server-side encryption (SSE-S3, SSE-KMS) protects objects at rest.
• Amazon EBS: Encrypted volumes protect EC2 instance data at rest.
• Amazon RDS: Encrypted DB instances protect database storage and automated backups.

Key service: AWS Key Management Service (AWS KMS) manages encryption keys and access to them.

Encryption in transit

Data is encrypted while moving between clients, services, and regions.

AWS examples:

• HTTPS (TLS) endpoints for S3, API Gateway, ALB, CloudFront.
• VPN connections & AWS Direct Connect with MACsec (where supported) for secure connectivity.

Basic network protection concepts

• Security groups (stateful): Act as virtual firewalls for EC2, RDS, Lambda (via VPC), etc.
• You specify allowed inbound and outbound traffic.
• Network ACLs (NACLs) (stateless): Act at the subnet level.
• You define allow and deny rules for IP ranges and ports.
• VPC: Logically isolated section of the AWS Cloud where you define your own IP ranges, subnets, and routing.

> Exam tip: Be able to differentiate security groups (instance-level, stateful, allow rules only) from NACLs (subnet-level, stateless, allow/deny rules).

Step 8 – Map Controls to Risks (Thought Exercise)

Match each risk to the most relevant AWS control or feature. Think first, then compare with the suggested mappings.

Risks

1. An attacker eavesdrops on data between your users’ browsers and your web app.
2. An employee accidentally makes an S3 bucket with customer data public.
3. A stolen backup drive from an AWS data center exposes unencrypted data.
4. A compromised application tries to reach an internal database it shouldn’t access.

Possible controls/features

A. Use HTTPS (TLS) via an Application Load Balancer or CloudFront.

B. Enable server-side encryption with SSE-S3 or SSE-KMS on the bucket.

C. Use security groups to restrict which instances can talk to the database.

D. Rely on AWS’s disk encryption at rest plus your own key management for backups.

---

Suggested mappings

1 → A – Encrypt traffic in transit with TLS.

2 → B – Encryption at rest doesn’t stop exposure, but enabling SSE-KMS plus strict IAM and bucket policies is part of a good control set. (Also: block public access settings.)

3 → D – Encryption at rest protects data even if a physical drive is stolen.

4 → C – Security groups can restrict which instances can reach the database.

> Note: In reality, you’d combine multiple controls (IAM, logging, monitoring). The exam focuses on recognizing the primary control for a given risk.

Step 9 – Compliance, Shared Responsibility, and Regulated Industries

Cloud compliance is also shared.

AWS compliance vs your compliance

• AWS compliance: AWS maintains certifications and attestations for the cloud infrastructure (e.g., ISO 27001, SOC 1/2/3, PCI DSS for the underlying services).
• This is part of security of the cloud.
• Customer compliance: You must configure and operate your workloads to meet your own regulatory obligations (e.g., HIPAA in the US, GDPR in the EU, financial regulations).
• This is part of security in the cloud.

Key resources (as of early 2026)

• AWS Artifact (console service):
• Self-service access to AWS compliance reports (e.g., SOC reports, PCI reports) and agreements (e.g., Business Associate Addendum for HIPAA-eligible services).
• You can download current reports to show your auditors how AWS manages its side.

• AWS Compliance Center (on aws.amazon.com/compliance):
• High-level information on regional and industry compliance programs.
• Customer-facing whitepapers, FAQs, and regulatory mappings (e.g., how AWS services align with GDPR requirements).

• AWS Artifact vs CloudTrail vs Config (don’t confuse them):
• AWS Artifact = Compliance reports and agreements.
• AWS CloudTrail = Logs of API calls and account activity (security/audit logging).
• AWS Config = Records configuration history and checks resources against rules.

> In regulated industries, teams often use AWS Artifact to prove AWS’s compliance posture, then design their own controls (IAM, encryption, logging) to meet their part of the shared responsibility model.

Step 10 – Quick Check: Shared Responsibility & Compliance

Answer this CLF-C02‑style question to check your understanding.

Step 11 – Key Term Flashcards

Use these flashcards to reinforce key concepts from this module.

Step 12 – Wrap-Up: Connecting to Architecture & Exam Prep

You can now connect security and compliance back to what you learned in Modules 2–3:

• Global infrastructure (regions, AZs) underpins security of the cloud.
• Well-Architected Framework (especially the Security and Reliability pillars) provides best practices for security in the cloud.
• The Cloud Adoption Framework (CAF) highlights security and governance as key perspectives when moving to AWS.

For CLF-C02 preparation:

• Be ready to identify who is responsible in different scenarios (EC2 vs RDS vs Lambda vs S3).
• Recognize least privilege, encryption at rest/in transit, and basic network protections as core design principles.
• Know that AWS Artifact and AWS Compliance Center are your go‑to places for AWS compliance documentation.

In the next modules, you’ll build on this foundation by looking at more specific AWS services and how they fit into secure, well‑governed architectures.