Shared Responsibility

# ===== The model =====
# AWS is responsible for SECURITY OF THE CLOUD.
# You are responsible for SECURITY IN THE CLOUD.

# The line shifts by service category:
# - IaaS (EC2):       you secure OS, network config, data, IAM at host level
# - PaaS (RDS):       AWS secures OS + DB engine patching; you secure data + IAM + access
# - SaaS (S3, Lambda): AWS secures more; you focus on data classification + IAM
# - Managed (Cognito, KMS): AWS handles the heavy lifting; you configure policy

# ===== AWS responsibilities (always) =====
# - Physical security of data centres
# - Hardware + storage + network underlying infrastructure
# - Virtualisation layer
# - Core service availability + SLAs
# - Patching of MANAGED service runtime (RDS engine, Lambda runtime)

# ===== Customer responsibilities (yours) =====
# - Data classification + encryption at REST (you choose KMS keys, S3 SSE)
# - Data in transit (TLS termination)
# - Identity + access (IAM users, roles, policies)
# - Network controls (Security Groups, NACLs, WAF)
# - OS + apps (for IaaS)
# - Logging + monitoring (CloudTrail, CloudWatch, GuardDuty)
# - Backup + restore (often you own this even for managed services)
# - Compliance audits (HIPAA / PCI / SOC paperwork on YOUR config)

# ===== Common misunderstandings =====
# 'S3 is managed so AWS secures my buckets'
#   No. AWS keeps the SERVICE up; YOU set Block Public Access, bucket policies, encryption.

# 'RDS does backups for me'
#   AWS does automated snapshots for the configured retention. YOU verify, restore, and
#   ensure off-region copies if you need geo redundancy.

# 'IAM users are enough'
#   Use IAM Identity Center (SSO) + roles for humans; access keys only for workloads
#   when alternatives are not available.

# 'Encryption at rest = encryption everywhere'
#   At rest is on disk. You still need TLS for in-transit + field encryption for sensitive data.

# 'AWS will patch my EC2'
#   No. You patch the OS + app on EC2. AWS only patches the underlying hypervisor.

# ===== Checklist per service =====
# EC2:
#   - You: OS patching, in-OS firewall, IAM role on instance, encrypted EBS, S3-access policy
#   - AWS: hypervisor patching, host security, hardware
# RDS:
#   - You: parameter groups, IAM auth, encryption at rest, backups verified, network
#   - AWS: engine patches (in maintenance window), failover, hardware
# Lambda:
#   - You: function code, IAM execution role, env vars, dependency CVEs
#   - AWS: runtime patching, scaling, isolation
# S3:
#   - You: Block Public Access, bucket policy, encryption choice, access logs, lifecycle
#   - AWS: durability, availability, low-level encryption infrastructure

# ===== Compliance =====
# AWS Artifact: download AWS compliance reports (SOC 2, ISO 27001, ...)
# That covers AWS's part. Your config + audit covers your part.

# ===== Patterns to internalise =====
# - Read the per-service responsibility table on the AWS docs page for any service you adopt
# - 'AWS does it' is rarely a complete answer; check IAM + encryption + backups + logs
# - Use Trusted Advisor + Security Hub for hygiene checks
# - Run least-privilege audits quarterly

# ===== Pitfalls =====
# - Trusting service defaults (S3 once defaulted to public-ish; now blocked by default)
# - Assuming RDS automated snapshots cover disaster recovery (test the restore!)
# - Lambda execution role granted *:* for convenience (lateral movement at scale)
# - 'It is in AWS, so it must be encrypted' — verify the setting

# AWS secures "of the cloud"; you secure "in the cloud".
# IAM, encryption, network rules are your job.