1.3.2. Customer's Security Responsibilities (Security IN the Cloud)
First Principle: You are always responsible for your data, your identities, and your configuration — regardless of how managed the service is. AWS provides the tools (KMS, IAM, Security Groups), but enabling and configuring them is your responsibility.
"Security IN the cloud" means everything you build, configure, and store on AWS:
Always Your Responsibility (Regardless of Service Type):
- Data: Classification, encryption settings, access policies, backup strategies
- Identity: IAM policies, MFA enforcement, credential rotation, federation configuration
- Encryption: Choosing encryption methods, configuring KMS key policies, managing certificates
- Network Configuration: Security groups, NACLs, VPC design, endpoint policies
Responsibility That Varies by Service Type:
- EC2: You manage OS patching, application hardening, host-based firewalls
- ECS/EKS: You manage container images, task roles, network policies
- Lambda: You manage function code, execution role, environment variable encryption
- S3: You manage bucket policies, public access block, versioning, Object Lock
The critical pattern: even when AWS manages the platform, three things are ALWAYS yours: data, identity, and encryption configuration.
⚠️ Exam Trap: A question asks who is responsible for encrypting data in S3. The answer is always the customer — AWS provides SSE-S3, SSE-KMS, and SSE-C, but YOU must enable encryption. S3 now encrypts by default with SSE-S3, but choosing KMS for audit capability is still your decision.
Scenario: A compliance officer asks whether your Lambda functions are secure. You explain: "AWS manages the runtime and OS, but we're responsible for the function code (no hardcoded secrets), the execution role (least privilege), and the environment variable encryption (KMS)."
Reflection Question: Why are data, identity, and encryption configuration ALWAYS your responsibility, even on fully managed services where AWS handles the infrastructure?
