AWS Academy Cloud Foundations — Module 4: AWS Cloud Security

Module Objective: Explain the AWS shared responsibility model, describe how AWS Identity and Access Management (IAM) controls access to resources, and identify the AWS services and programs available for securing, monitoring, and demonstrating compliance of a cloud environment.

Builds on Module 1, which introduced the shared responsibility model briefly; this module covers it — and the tools that implement it — in depth.

The Shared Responsibility Model

Security in AWS is a shared undertaking. AWS is responsible for security "of" the cloud; the customer is responsible for security "in" the cloud. Where exactly the line falls shifts depending on which type of service is being used.

Party	Responsible For
AWS ("of" the cloud)	Physical data center security, hardware, the global network, and the virtualization layer underlying every service
Customer ("in" the cloud)	Guest OS patching (for IaaS), application security, IAM configuration, data encryption, and network/firewall configuration

🔵 Note The customer's share of responsibility grows with IaaS (e.g. Amazon EC2, where the customer manages the guest OS) and shrinks with managed or serverless services (e.g. AWS Lambda, where AWS manages the runtime) — but the customer is always responsible for their data and access configuration, regardless of service type.

AWS Compliance Programs

Because AWS operates the underlying infrastructure for regulated workloads worldwide, it maintains certifications and attestations against a wide range of global, regional, and industry-specific compliance frameworks — such as ISO 27001, SOC 1/2/3, PCI DSS, HIPAA, and FedRAMP.

Resource	What It Provides
AWS Artifact	A self-service portal for downloading AWS compliance reports and agreements on demand
AWS Compliance Center / AWS Compliance page	Documentation describing which certifications AWS holds and which services fall within their scope

✅ Tip — Compliance Is Inherited, Not Automatic AWS's certifications cover the infrastructure AWS operates. A customer's own application still has to be built and configured correctly to inherit that compliance posture — using a HIPAA-eligible service doesn't automatically make a workload HIPAA-compliant.

AWS Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) is the global AWS service used to control who can do what within an AWS account. IAM is free to use and is the primary tool customers use to fulfill their side of the shared responsibility model.

IAM Concept	What It Is
IAM user	An identity representing a single person or application, with its own long-term credentials
IAM group	A collection of IAM users that share the same set of permissions
IAM role	An identity with temporary permissions that can be assumed by a user, application, or AWS service — no long-term credentials attached
IAM policy	A JSON document that defines what actions are allowed or denied on which resources

✅ Tip — Prefer Roles Over Long-Term Credentials Because IAM roles issue short-lived, automatically rotated credentials, AWS recommends using roles — for both AWS services and, where supported, human users — instead of long-term IAM user access keys wherever possible.

The Root User and MFA

Every AWS account has a single root user, created with the email address used to open the account. The root user has unrestricted access to every resource and setting in the account, including the ability to close the account or change billing information.

Practice	Why It Matters
Avoid daily use of the root user	Its permissions can't be restricted, so a compromised root user compromises everything in the account
Create an administrative IAM user or role instead	Day-to-day administrative work should use an IAM identity with only the permissions actually needed
Enable multi-factor authentication (MFA)	Requires a second factor — such as a virtual MFA device or hardware key — in addition to a password, and should be enabled on the root user at minimum

⚠️ Warning — Protect Root Credentials Losing control of root user credentials is one of the most serious security incidents an AWS account can experience. Enabling MFA on the root user and storing its credentials securely are treated as non-negotiable first steps for any new account.

IAM Policies and the Principle of Least Privilege

The principle of least privilege means granting an identity only the permissions it needs to perform its task — nothing more. IAM policies are the mechanism for applying this principle precisely.

Policy Element	Purpose
Effect	Whether the statement `Allow`s or `Deny`s the specified access
Action	The specific API operation(s) the statement applies to, e.g. `s3:GetObject`
Resource	The specific AWS resource(s) the statement applies to
Condition	Optional constraints, such as restricting access to a specific IP range or time window

🔵 Note An explicit Deny in any applicable policy always overrides an Allow elsewhere. If no policy explicitly allows an action, IAM denies it by default.

AWS Organizations and Service Control Policies

For companies managing many AWS accounts, AWS Organizations extends access control beyond a single account using Service Control Policies (SCPs) — guardrails applied at the organization, organizational unit (OU), or account level.

Concept	What It Does
Organizational unit (OU)	A grouping of accounts within an organization, used to apply policies to many accounts at once
Service Control Policy (SCP)	Sets the maximum available permissions for accounts in scope — it can restrict, but never grant, permissions

✅ Tip — SCPs Are Guardrails, Not Grants An SCP that doesn't explicitly allow a service still blocks it — but even a permissive SCP doesn't grant access by itself. IAM policies within each account still have to grant the actual permissions; the SCP only defines the outer boundary.

AWS Security Services Overview

Beyond IAM, AWS offers a set of purpose-built services covering detection, data protection, and network/application defense.

Service	Category	Purpose
Amazon GuardDuty	Threat detection	Continuously monitors for malicious activity and unauthorized behavior
Amazon Inspector	Vulnerability management	Automatically scans workloads for software vulnerabilities and unintended network exposure
Amazon Macie	Data protection	Uses machine learning to discover and protect sensitive data, such as personally identifiable information, in Amazon S3
AWS Key Management Service (KMS)	Encryption	Creates and manages cryptographic keys used to encrypt data across AWS services
AWS Shield	Network protection	Provides DDoS protection, with a free Standard tier and a paid Advanced tier
AWS WAF	Application protection	A web application firewall that filters malicious HTTP(S) requests before they reach an application

🔵 Note These services are layered, not redundant — GuardDuty detects threats in account activity, Inspector finds vulnerabilities before they're exploited, Macie protects data at rest, and Shield/WAF defend the network and application edge.

Key Terms for Module 4

shared responsibility model: The division between AWS's responsibility for security "of" the cloud and the customer's responsibility for security "in" the cloud
AWS Artifact: A self-service portal for downloading AWS compliance reports and agreements
IAM (Identity and Access Management): The global AWS service used to control authentication and authorization within an account
root user: The single, unrestricted identity created when an AWS account is opened
multi-factor authentication (MFA): Requiring a second authentication factor beyond a password
principle of least privilege: Granting an identity only the permissions it needs to perform its task
Service Control Policy (SCP): An AWS Organizations policy that sets the maximum available permissions for accounts in scope
Amazon GuardDuty: A threat detection service that monitors for malicious or unauthorized activity
AWS Shield: A service providing DDoS protection, available in a free Standard tier and paid Advanced tier

Review Questions

Under the shared responsibility model, how does the customer's share of responsibility change between Amazon EC2 (IaaS) and AWS Lambda (serverless)?
What is AWS Artifact, and what problem does it solve for a customer that needs to prove compliance to an auditor?
What is the difference between an IAM user, an IAM group, and an IAM role?
Why does AWS recommend against day-to-day use of the root user, even though it has full access to everything?
In an IAM policy, what happens if one policy allows an action and another applicable policy explicitly denies it?
What is the difference between what a Service Control Policy can do and what an IAM policy can do?
Which AWS security service would you reach for to detect malicious activity in account behavior, versus to discover sensitive data stored in Amazon S3?