Lesson 1.4: Shared responsibility model for developers
When building applications on AWS, it is incorrect to assume that managed services transfer security responsibility to AWS. AWS secures the underlying platform and infrastructure, including physical facilities, hardware, networking, and the foundational layers of managed services. Developers remain responsible for configuring services, authorizing identities, and handling data. The shared responsibility model is therefore an explicit responsibility boundary. Every decision involving IAM, encryption, networking, logging, and deployment resides on the developer side of that boundary. Many DVA-C02 scenarios test whether you can correctly identify which layer is misconfigured.
What AWS secures vs what developers secure
AWS secures the infrastructure and platform of managed services, including data centers, storage hardware, networking components, virtualization layers, and the operating system and runtime environments of services such as Amazon S3, DynamoDB, and Lambda. Developers do not patch DynamoDB servers or manage the host OS for Lambda. Developers secure everything configured and built on top of that infrastructure, including identity, access policies, encryption settings, network rules, secret handling, and application logic.
This command shows enabling encryption for an S3 bucket, a responsibility of the developer.
aws s3api put-bucket-encryption \
--bucket mybucket \
--server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
Identity and access management responsibility
IAM is a global service, and its configuration affects all regions. AWS provides the identity framework, but developers define its application. Assigning IAM roles to EC2 instances or Lambda functions determines workload access. Broad permissions expand the risk surface, whereas least-privilege policies limit exposure. Roles should replace hard-coded credentials, and periodic review is necessary.
This policy JSON illustrates a least-privilege IAM policy scoped to a specific S3 bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::mybucket/*"]
}
]
}
Data protection, network, and application-layer responsibility
Developers must configure encryption for data at rest and in transit using KMS or service-native encryption. AWS provides the secure infrastructure and platform, but configuring encryption is the developer’s responsibility. Network security, including VPCs, subnets, route tables, security groups, and network ACLs, also falls to developers. Misconfigurations such as open ports or public subnets are common sources of exposure. At the application layer, developers must enforce input validation, authentication, and domain-specific authorization.
This command configures secure network access for a specific CIDR block.
aws ec2 authorize-security-group-ingress \
--group-id <group_id> \
--protocol tcp \
--port 443 \
--cidr 203.0.113.0/24
Logging, monitoring, and deployment responsibility
AWS provides observability tools like CloudWatch and CloudTrail, but enabling logging, configuring alarms, and reviewing audit data remains the developer’s responsibility. Infrastructure-as-code and CI/CD pipelines require careful management: least-privilege roles, encrypted artifacts, and reviewed changes are essential to prevent insecure configurations.
This alarm ensures developers monitor Lambda errors proactively.
aws cloudwatch put-metric-alarm \
--alarm-name HighLambdaErrors \
--metric-name Errors \
--namespace AWS/Lambda \
--statistic Sum \
--period 300 \
--threshold 5 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:<account_id>:NotifyMe
The shared responsibility model defines a clear boundary: AWS secures the infrastructure and platform of managed services, while developers secure identity, permissions, encryption, networking, secrets, monitoring, and application logic.
Understanding these boundaries enables systems to degrade predictably, recover safely, and align with AWS operational realities.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
