AWS Shared Responsibility Model

The AWS Shared Responsibility Model defines the security and compliance obligations of AWS (the cloud provider) and the customer (you) when using AWS services. It ensures clarity on who manages what, reducing risks and ensuring secure cloud operations.

AWS Responsibility (Security of the Cloud)

AWS is responsible for protecting the global infrastructure that runs all AWS services, including:

• Physical Security of data centers (access control, power, cooling).

• Hardware/Network Infrastructure (servers, storage, networking devices).

• Global Cloud Services (compute, storage, databases, networking).

• Managed Services (e.g., AWS RDS, Lambda, DynamoDB – AWS handles OS patching, scaling, and availability).

• Compliance Certifications (e.g., ISO 27001, SOC 2, GDPR, HIPAA).

Customer Responsibilities (Security in the Cloud)

You are responsible for securing what you deploy on AWS, including:

• Infrastructure Services (EC2, EBS, VPC, EKS)

• Managed Services (RDS, Lambda, S3, EFS)

• Applications & Data

• Networking (VPC, ALB)

• Identity (IAM, Cognito)

Design Principles for the Security Pillars

Your architecture will present a much stronger security presence if you follow these design principles from the security pillar of the Well-Architected Framework:

• Implement a strong identity foundation : Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources. Centralize identity management, and aim to eliminate reliance on long-term, static credentials.

• Protect data in transit and at rest : Classify your data into sensitivity levels, and use mechanisms, such as encryption, tokenization, and access control, where appropriate.

• Apply security at all layers : Apply a defense-in-depth approach with multiple security controls, and apply it to all layers (for example, edge of network, virtual private cloud [VPC], load balancing, every instance and compute service, operating system, application, and code).

• Keep people away from data : Use mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of mishandling or modification and human error when handling sensitive data.

• Maintain traceability : Monitor, alert, and audit actions and changes to your environment in real time. Integrate log and metric collection with systems to automatically investigate and take action.

• Prepare for security events : Prepare for an incident by having incident management and investigation policies and processes that align to your organizational requirements. Run incident response simulations, and use tools with automation to increase your speed for detection, investigation, and recovery.

• Automate security best practices : Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost-effectively. Create secure architectures, which includes implementing controls that are defined and managed as code in version-controlled templates.

AWS Identity and Access Management (AWS IAM)

IAM Terminologies

1. IAM User

   - An entity (person or service) that interacts with AWS.

   - Has credentials (password + access keys).

   - Example: dev-user, admin-user.

2. IAM Group

   - A collection of IAM users to manage permissions collectively.

   - Example: Developers-Group (with permissions for EC2, S3).

3. IAM Role

   - A temporary identity that can be assumed by users, services, or AWS resources.

   - No credentials attached (unlike users).

   - Example: EC2-Role (allows EC2 to access S3).

4. IAM Policy

   - A JSON document defining permissions (allow/deny access to AWS resources).

   - Two types:

   Managed Policies (AWS pre-built or custom reusable policies).

   Inline Policies (directly attached to a user/group/role).

5. Principal

   - An entity (user/role/service) that can make AWS requests.

   - Example: An IAM user or an EC2 instance with a role.

6. Permission Boundary

   - Sets the maximum permissions a user/role can have.

   - Prevents privilege escalation.

7. Resource-Based Policy

   - Attached directly to AWS resources (e.g., S3 bucket policies).

8. Assume Role

   - Allows temporary role assumption (e.g., cross-account access).

   - Used with STS (Security Token Service) to generate temporary credentials.

Principle of Least Privilege

The Principle of Least Privilege is a security best practice that ensures users, applications, and services have only the minimum permissions necessary to perform their tasks—nothing more. This reduces the risk of accidental or malicious misuse of privileges.

When you create access policies, determine what your users need to do, and then craft policies that allow them to perform only those tasks. Similarly, create policies for individual resources that identify precisely who is allowed to access the resource, and allow only the minimal permissions for those users. For example, perhaps developers should be allowed to create EC2 instances in production environments but not to stop or terminate the instances.

Using Encryption

In addition to limiting who has permissions to access data, you should prevent access to data through encryption. This practice relates to the design principle of protecting data in transit and at rest.

Protecting data at rest with client-side encryption

The client encrypts data before sending it. The encrypted data is sent through a secure pipe from the client to cloud storage. The client retrieves encrypted data from cloud storage and decrypts the data for use.

Protecting data at rest means using encryption to protect data that is stored anywhere in your cloud solution. Client-side encryption provides end-to-end protection for your object, in transit and at rest, from its source to storage.

Protecting data at rest with server-side encryption

Unencrypted data is sent through a secure pipe. The server encrypts data when storing it and decrypts data when you request it. Data is returned to the client through the secure pipe. With server-side encryption, data is encrypted before it’s stored.

Amazon S3 provides server-side encryption. The service encrypts your data at the object level as it writes the data to disks in AWS data centers and decrypts the data when you access it.