AWS Security Principles — Study Notes

AWS Academy · Module 2

AWS Security
Principles

Mastering cloud security, identity access management, data protection, and least privilege architecture on Amazon Web Services.

Shared Responsibility Model Well-Architected Security Pillar Principle of Least Privilege Data Protection (Transit & Rest)

AWS Core Security

AWS Shared Responsibility Model

The cornerstone of cloud security. AWS and the customer divide tasks to ensure workloads are completely defended.

Figure 1: AWS Shared Responsibility Model (Security OF the Cloud vs. Security IN the Cloud).

AWS Responsibilities

AWS secures and maintains the global cloud infrastructure that runs all AWS services:

Physical Infrastructure: Security, power, and climate control for physical data centers.
Hardware & Software: Servers, storage systems, hypervisors, and virtualization layers.
Networking: Fiber cables, switches, and edge infrastructure.
Global Infrastructure: Regions, Availability Zones (AZs), and Edge Locations.
Managed Services: Base security configurations for S3, RDS, DynamoDB, etc.

Customer Responsibilities

The customer secures everything they deploy, configure, and store in the cloud:

Customer Data: Classification, permissions, and data integrity.
Applications: Custom application logic, updates, packages, and code flaws.
IAM Configuration: User accounts, passwords, MFA, roles, and access permissions.
Operating Systems: Patching, upgrading, and hardening OS on Amazon EC2 instances.
Network Protection: Firewalls, Security Groups, and Network ACLs configuration.
Encryption: Server-side & client-side encryption configuration, network traffic (TLS/SSL).

💡

Exam Tips & Memory Tricks

Memory Trick: AWS = OF the cloud (Infrastructure) | Customer = IN the cloud (Data, Configs, Apps).
AWS responsibility example: Replacing a broken physical hard disk drive or hypervisor security patching.
Customer responsibility example: Enabling MFA, changing a password policy, encrypting S3 buckets, or OS security updates.

Cloud Architecture Standards

Security as a Well-Architected Framework Pillar

The AWS Well-Architected Framework provides design principles to help you construct secure, resilient, and highly efficient cloud systems.

AWS Well-Architected Framework Pillars Diagram

Figure 2: The Six Pillars of the AWS Well-Architected Framework with Security emphasized.

The Six Pillars of the Framework

⚙️

1. Operational Excellence

Running, monitoring, and continuously improving systems to deliver business value.

🛡️

2. Security

Protecting systems, data, identities, and assets while assessing and managing security risks.

🔄

3. Reliability

Recovering dynamically from infrastructure/service failures and maintaining availability.

⚡

4. Performance Efficiency

Selecting and utilizing computing resources efficiently as demand changes and technology evolves.

💰

5. Cost Optimization

Avoiding unnecessary spending and optimizing the cost-effectiveness of cloud workloads.

🌱

6. Sustainability

Minimizing the environmental impact of running cloud workloads by optimizing resources.

Security Pillar Focus Areas

The Security Pillar centers on six foundational domains:

Identity & Access Management (IAM): Who can access what resources.
Data Protection: Encrypting and protecting data at rest and in transit.
Infrastructure Protection: Securing network boundaries and compute layers.
Detection & Monitoring: Collecting and analyzing logs for security threats.
Incident Response: Preparing response procedures and incident mitigation.
Secure Architecture Design: Building defense-in-depth structures.

AWS Well-Architected Tool

A free, self-service tool provided by AWS to review the health of your workloads:

Assesses architectures against AWS Well-Architected best practices.
Identifies architectural risks (high/medium) and flags critical vulnerabilities.
Generates recommendations and improvement plans across all 6 pillars.
Facilitates continuous review and optimization as workloads scale.

🧠

Memory Trick

Pillars mnemonic: O S R P C S → Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability.
AWS WA Tool: Free self-service assessment against best practices, identifying architectural flaws and offering recommendations.

Architectural Best Practices

AWS Well-Architected Security Design Principles

Seven core design principles that guide the creation of secure systems on the AWS cloud infrastructure.

Security Pillar Design Principles Diagram

Figure 3: Seven Design Principles for AWS Security.

🔑

1. Strong Identity Foundation

Enforce least privilege and separation of duties. Use temporary credentials and centralize access.

Example: IAM Roles instead of static keys

🔒

2. Protect Data in Transit & Rest

Classify your data by sensitivity. Encrypt it stored (at rest) and moving across networks (in transit).

Example: HTTPS (TLS) & S3 / EBS encryption

🧅

3. Apply Security at All Layers

Use defense-in-depth. Secure the network edge, VPC, load balancers, instances, OS, application, and code.

Example: WAF + ALB + Security Groups + IAM

🤖

4. Keep People Away from Data

Reduce direct human access to data to prevent leaks, manual errors, and unauthorized adjustments.

Example: Automated backups & pipeline delivery

👁️

5. Maintain Traceability

Monitor, log, audit, and alert. Keep detailed records of every configuration and API call.

Example: AWS CloudTrail, CloudWatch & AWS Config

🚨

6. Prepare for Security Events

Have an incident response plan. Automate threat detection, isolation, and recovery, and run simulations.

Example: Automated quarantine scripts

💻

7. Automate Security Best Practices

Use Infrastructure as Code (IaC). Automate security controls to reduce human errors and ensure consistency.

Example: CloudFormation or Terraform secure templates

🧠

Mnemonic & Mapping

Memory Trick: I P A K M P A → Implement identity foundation, Protect data, Apply security layers, Keep people away, Maintain traceability, Prepare for events, Automatic security.
Exam Question Clues: Monitoring/API Auditing → Maintain Traceability | Reduce manual errors → Automate Security | Firewalls at multiple layers → Apply Security at All Layers.

Identity and Access Management

AWS IAM Policies: Access Control

Understanding how JSON policy documents dictate permissions on AWS resources, and how AWS evaluates Allow vs. Deny rules.

AWS IAM Policies User Permissions Diagram

Figure 4: IAM Policy evaluation for user John trying to access S3 Buckets and DynamoDB.

IAM Policies Overview

IAM policies are JSON files defining actions allowed or denied on resources. They attach to:

IAM Users: Individual account operators.
IAM Groups: Collections of users sharing roles (e.g., Developers, Finance).
IAM Roles: Identities assumed by services or external users for temporary credentials.

Three Evaluation Types

Allow: Explicit permission to execute actions.
Read-Only: Permission to view/retrieve data but not write or delete.
Explicit Deny: Explicitly blocks access. Always overrides any Allow permissions.

Example Access Matrix (User: John)

John's access evaluation matches the JSON policies attached to his profile:

AWS Resource	Access Level	Result
S3 Bucket 1	Full Access (Read, Write, Delete)	✅ Allow
S3 Bucket 2	Read-Only Access	✅ Read-Only
DynamoDB Table 1	Explicitly Denied	❌ Deny

⚠️

Critical Exam Rule

Rule: Explicit Deny > Allow
If an IAM policy grants access (Allow) to an S3 bucket, but another policy explicitly blocks access (Deny) to the same bucket, the user is blocked. The Explicit Deny always wins.

Access Architecture Best Practice

The Principle of Least Privilege (PoLP)

Granting only the absolute minimum permissions required for a user or system to accomplish their job function—and nothing more.

Principle of Least Privilege Comparison Diagram

Figure 5: Comparing privileges of Administrator John vs. Marketing User Mary.

🛡️

Why Implement Least Privilege?

Improves Security: Limits the attack surface.
Restricts Damage: Compromised credentials only access specific items.
Prevents Accidents: Stops users from accidentally deleting DBs or servers.

🔧

How to Apply (The SAR Method)

Start (S): Begin with the absolute minimum set of permissions.
Add (A): Add additional permissions only when specifically requested and validated.
Remove (R): Audit regularly to revoke unnecessary or unused permissions.

🌍

Real-World Role Examples

Developer: Can launch EC2, read logs, but cannot terminate Production EC2.
DB Admin: Manage RDS database instances, but cannot touch S3 buckets.
Finance Team: Can read Billing Dashboard, but cannot access EC2/RDS servers.

Least Privilege Case Study

User Account	Job Role	S3 Bucket 1 (General Public)	S3 Bucket 2 (Confidential Financials)	Security Rationale
John	Cloud Administrator	Full Access	Full Access	Needs administrative control over both storage repositories for maintenance.
Mary	Marketing Associate	Read-Only	Explicit Deny	Only requires access to read asset files. Must be blocked from financial data.

💡

Exam Tips

Principle of Least Privilege: Always the answer when asked about setting up credentials securely, reducing risk of compromised credentials, or preventing accidental deletion.
Implementation: Set minimal permissions initially, use IAM policies, and execute regular access audits.

Data Cryptography

Protecting Data in Transit and at Rest

Classifying data and employing cryptography to prevent interception, theft, or modifications.

Data in Transit (Data Moving)

Data moving between devices, networks, or services is highly vulnerable to intercept attacks.

Primary Protocol: TLS (Transport Layer Security), the modern standard of SSL.
HTTPS: Combines HTTP with TLS to secure browser-to-server traffic.
Benefits: Confidentiality, data integrity, and server authentication.

Data at Rest (Data Stored)

Data stored statically on disks, solid state drives, databases, or S3 object storage.

              Client-Side Encryption: Client encrypts first, then uploads.
            

              Server-Side Encryption: AWS encrypts when saving data.
            

Transit vs. Rest Comparison

Property	Data in Transit	Data at Rest
Status	Active network transmission (moving)	Saved on storage services (static)
Protocols / Mechanisms	TLS, SSL, HTTPS, IPsec VPN	KMS, AES-256, S3 Server-Side (SSE), BitLocker
AWS Encryption Role	Secured with TLS certificates via ACM	Secured via AWS KMS keys (SSE-S3, SSE-KMS)
Examples	Uploading an image to S3; API call to RDS	File resting in S3 bucket; Database volume on EBS

🧠

Transit vs. Rest Clues

Transit = Traveling = TLS: Whenever you see "data moving" or "uploading securely", it is transit encryption using TLS/HTTPS.
Rest = Resting = KMS/AES-256: Whenever you see "storing sensitive files" or "securing database volumes", it is data at rest encryption.

Quick Revision

Key Takeaways: Security Principles

✓
Shared Responsibility: AWS protects the underlying infrastructure (OF the cloud); Customers protect their data, apps, operating systems, and network access (IN the cloud).
✓
Security Pillar: One of the 6 Well-Architected Pillars (O S R P C S). The AWS Well-Architected Tool evaluates design posture against best practices.
✓
Least Privilege: Grant minimum access required. Apply the SAR method: Start minimal, Add when needed, Remove unused. Explicit Deny overrides Allow.
✓
Data Protection: Encrypt transit data using TLS/HTTPS. Encrypt at rest data using KMS/AES-256 (via Client-side or Server-side mechanisms).

Core Exam Keywords

• Shared Responsibility → OF the cloud vs IN the cloud
• Least Privilege → Minimum permissions
• Data in Transit → TLS/HTTPS
• Data at Rest → KMS / SSE / Client-side
• Explicit Deny → Always wins over Allow

AWS SecurityPrinciples