The Shared Responsibility Model

AWS runs some of the most heavily protected data centres in the world, with guards, biometric doors and engineers watching the hardware day and night. Yet a startup in Bengaluru can still leak its customers' Aadhaar-linked records from an S3 bucket in one afternoon. Both statements are true because security in the cloud is split between AWS and you. This split is called the shared responsibility model.

The Cloud Security Basics lesson introduced the idea for all providers. Here you will see exactly how it applies to the AWS services in this course, and which settings you must turn on yourself.

Security "of" the cloud and "in" the cloud

AWS describes the model in two phrases:

• AWS is responsible for security of the cloud: the physical data centres, the hardware, the global network, and the software that runs the services (such as the hypervisor that separates EC2 instances).
• You are responsible for security in the cloud: your data, who can access it, how you configure each service, your operating systems where you manage them, and your application code.

The line moves depending on how managed a service is. The more AWS runs for you, the less you have to patch, but your data and access settings never move to AWS.

How the line moves between services

Look at the last two rows: every service leaves identity, access and data with you. Most AWS security incidents in the news, such as public buckets, leaked access keys and open database ports, come from those rows.

Shared controls

Some controls are split, with each side doing its own part:

• Patch management: AWS patches its infrastructure and managed services; you patch your guest operating systems and applications.
• Configuration management: AWS configures its own devices; you configure your instances, databases and applications.
• Awareness and training: AWS trains its staff; you train yours.

Some controls you simply inherit from AWS, such as physical and environmental protection of data centres. Others are customer-specific, such as separating data into different security zones and routing traffic inside your own network.

Your settings in practice

A few account-wide settings show how "in the cloud" work looks. These are not on by default in every case, so it is your job to check them.

Block public access to S3 for the whole account, so no bucket can be made public by mistake:

aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3control get-public-access-block --account-id 111122223333

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

Encrypt every new EBS disk in a Region automatically. The setting is per Region, so repeat it for each Region you use:

aws ec2 enable-ebs-encryption-by-default --region ap-south-1

{
    "EbsEncryptionByDefault": true
}

Find Lambda functions still using an old runtime. AWS patches supported managed runtimes, but upgrading your function to a newer runtime is your job:

aws lambda list-functions --region ap-south-1 \
  --query "Functions[?Runtime=='python3.10'].[FunctionName, Runtime]"

[
    [
        "old-report-generator",
        "python3.10"
    ]
]

Python 3.10 on Lambda runs on Amazon Linux 2 and is scheduled for deprecation, so this function should move to python3.14.

Compliance is shared too

AWS is audited against many standards, such as ISO 27001 and SOC 2, and you can download those reports free from AWS Artifact in the console. Auditors and customers often ask for them. But an AWS certificate covers only AWS's half. If a bank in Mumbai runs on AWS, the bank must still show that its configuration, access control and data handling meet RBI guidelines, and a company processing personal data remains the data fiduciary under India's DPDP Act 2023.

Common mistakes

• "AWS is secure, so my app is secure." AWS secures the platform; a public bucket or weak IAM policy is still your fault.
• Forgetting to patch EC2 instances. On IaaS, the guest operating system is completely yours. Use AWS Systems Manager Patch Manager or rebuild instances from fresh images regularly.
• Ignoring runtime deprecation emails for Lambda functions.
• Using AWS's audit reports as your own compliance proof. They prove AWS's controls, not yours.
• Enabling a setting in one Region only. EBS default encryption and many security services are per Region.

Key points

• AWS secures the cloud itself (facilities, hardware, network, service software); you secure what you put in it.
• The more managed a service, the fewer patches you apply, but data, identity and configuration always stay with you.
• On EC2 you patch the operating system; on RDS and Lambda AWS patches the engine or managed runtime.
• Patch management, configuration management and training are shared controls; physical security is inherited from AWS.
• Account settings such as S3 Block Public Access and EBS encryption by default are your responsibility to turn on and verify.
• AWS Artifact provides AWS's compliance reports, but your own compliance still depends on your configuration.

Isha's responsibility:
1. Patch the operating system and PHP on the EC2 instances.
2. Restrict security groups so only the web servers can reach MySQL (port 3306).
3. Write least-privilege IAM policies so the app can read and write only its own bucket.
4. Keep mark sheets private, encrypted, and back up the database with a suitable retention period.

AWS's responsibility:
1. Physical security and hardware of the data centres.
2. Patching the RDS database engine and its operating system (in her chosen maintenance window).

aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true