15. Security, Identity, and Compliance

Security services implement the "Shared Responsibility Model," providing tools for protection, detection, and identity management.

AWS Artifact

Service Introduction: A central resource for compliance-related information, providing on-demand access to AWS’s security and compliance reports (e.g., SOC, PCI).

Common Usage: Downloading audit reports to prove the compliance of AWS infrastructure to external regulators.

Project Examples:

• Providing a SOC 2 report to a client during a security audit.
• Accepting an AWS BAA (Business Associate Addendum) for HIPAA compliance.

AWS Audit Manager

Service Introduction: Helps you continuously audit your AWS usage to simplify how you assess risk and compliance with regulations and industry standards.

Common Usage: Automating the collection of evidence for compliance audits like GDPR, HIPAA, or NIST.

Project Examples:

• Automatically gathering resource configuration data for a PCI DSS audit.
• Generating a compliance report for internal security stakeholders.

AWS Certificate Manager (ACM)

Service Introduction: A service that lets you easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services.

Common Usage: Implementing "Encryption in Transit" for load balancers and CloudFront distributions with automated renewal.

Project Examples:

• Securing an e-commerce website with a public SSL certificate.
• Managing a private Certificate Authority (CA) for internal microservice encryption.

AWS CloudHSM

Service Introduction: A cloud-based hardware security module (HSM) that enables you to easily generate and use your own encryption keys on dedicated FIPS 140-2 Level 3 hardware.

Common Usage: Meeting strict regulatory requirements for key management where keys must reside on dedicated, tamper-evident hardware.

Project Examples:

• Managing keys for a banking application that requires FIPS 140-2 Level 3 compliance.
• Offloading SSL/TLS processing to an HSM to secure web server private keys.

CloudHSM vs. KMS (exam-critical distinction): AWS CloudHSM provides single-tenant, dedicated hardware for the highest compliance standards (FIPS 140-2 Level 3), giving the customer full control of the HSM. AWS KMS with Customer Managed Keys runs on multi-tenant hardware (FIPS 140-2 Level 2/3 validated, but shared infrastructure) and is the easier, lower-effort option for most compliance needs. Decision Rule: If the question specifies dedicated, single-tenant hardware, the answer is CloudHSM; if it just needs customer control over key policies without dedicated hardware, the answer is KMS with CMKs.

Amazon Cognito

Service Introduction: Provides authentication, authorization, and user management for web and mobile apps; supports social and enterprise identity federation.

Common Usage: Implementing secure sign-in and sign-up (User Pools) and providing temporary AWS credentials (Identity Pools) for apps.

Project Examples:

• Adding "Login with Google" functionality to a mobile application.
• Managing a user database for a serverless web portal with millions of users.

Amazon Detective

Service Introduction: Makes it easy to analyze, investigate, and quickly identify the root cause of potential security issues or suspicious activities.

Common Usage: Providing automated visualizations of log data (from VPC Flow Logs, CloudTrail) to assist in security incident investigations.

Project Examples:

• Investigating a series of failed login attempts to find the originating IP and affected resources.
• Visualizing the movement of data during a potential exfiltration event.

AWS Directory Service

Service Introduction: Provides multiple ways to use Microsoft Active Directory (AD) with other AWS services.

Common Usage: Extending on-premises AD to the cloud or running a managed Microsoft AD for seamless Windows workload integration.

Project Examples:

• Providing Single Sign-On (SSO) for employees to access the AWS Management Console.
• Joining EC2 Windows instances to a managed Active Directory domain.

AWS Firewall Manager

Service Introduction: A security management service that allows you to centrally configure and manage firewall rules across your accounts and applications in AWS Organizations.

Common Usage: Enforcing consistent WAF rules, Shield protections, and Security Group policies across an entire organization.

Project Examples:

• Mandating that all public-facing ALBs in every account must have a specific WAF web ACL.
• Automatically applying Security Group rules to all new VPCs in an organization.

Amazon GuardDuty

Service Introduction: A threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads.

Common Usage: Automating security monitoring; detects threats like cryptocurrency mining, unusual API patterns, and known malicious IPs.

Project Examples:

• Alerting security when an EC2 instance is communicating with a Bitcoin mining pool.
• Detecting an IAM user making API calls from an unusual geographic location.

AWS IAM Identity Center (Successor to AWS SSO)

Service Introduction: A service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications.

Common Usage: Centralizing authentication via an external identity provider (like Okta or AD) for all AWS accounts in an organization.

Project Examples:

• Granting a DevOps team "AdministratorAccess" to 50 different AWS accounts using their corporate login.
• Managing multi-account permissions from a single, centralized dashboard.

Amazon Inspector

Service Introduction: An automated vulnerability management service that continually scans AWS workloads (EC2, ECR, Lambda) for software vulnerabilities and unintended network exposure.

Common Usage: Proactive security; identifies "high" or "critical" CVEs in your application code and environment.

Project Examples:

• Scanning EC2 instances for outdated software packages with known vulnerabilities.
• Identifying Lambda functions with vulnerable third-party library dependencies.

AWS KMS (Key Management Service)

Service Introduction: A managed service that makes it easy to create and control the cryptographic keys used to encrypt your data.

Common Usage: Implementing "Encryption at Rest." Users can choose between AWS-managed keys or Customer Managed Keys (CMK) for granular control.

Project Examples:

• Encrypting an S3 bucket with a CMK that rotates automatically every year.
• Enforcing a policy where only the "Billing" role can decrypt sensitive financial data.

Amazon Macie

Service Introduction: A fully managed data security and data privacy service that uses machine learning and pattern matching to discover and protect sensitive data in S3.

Common Usage: Identifying Personally Identifiable Information (PII) like credit card numbers or SSNs in unencrypted buckets.

Project Examples:

• Scanning an entire S3 data lake to find forgotten files containing PII.
• Alerting when an S3 bucket containing sensitive data is made public.

AWS Network Firewall

Service Introduction: A managed service that makes it easy to deploy essential network protections for all of your Amazon VPCs.

Common Usage: Providing L3-L7 firewall protection, including deep packet inspection (DPI) and URL filtering at the VPC boundary.

Project Examples:

• Blocking all outbound traffic from a VPC to specific unauthorized domains.
• Inspecting all traffic entering a VPC for malicious signatures.

AWS Resource Access Manager (AWS RAM)

Service Introduction: A service that enables you to easily and securely share AWS resources with any AWS account or within your AWS Organization.

Common Usage: Sharing subnets, Transit Gateways, or License Manager configurations across accounts to reduce overhead.

Project Examples:

• Sharing a single VPC subnet with multiple development accounts to centralize networking.
• Sharing a Transit Gateway across all accounts in a corporate organization.

AWS Secrets Manager

Service Introduction: Helps you protect secrets needed to access your applications, services, and IT resources, such as database credentials and API keys.

Common Usage: Eliminating hardcoded credentials by allowing applications to retrieve secrets at runtime; supports automated rotation.

Key Sub-Features (exam-critical):

• Automated Rotation (the defining feature) — Secrets Manager natively supports automatic rotation for various secret types, including database credentials and third-party API keys via Lambda integration. This is the critical differentiator from AWS Systems Manager Parameter Store.
• Built-in vs. Custom Rotation — For AWS-managed secrets (RDS, Redshift, DocumentDB), rotation is built-in. For third-party services (Slack API keys, external databases), you define a custom Lambda function to rotate the secret.
• Rotation Schedule — Set rotation intervals (e.g., every 30 days) without manual intervention.

Secrets Manager vs. Parameter Store (exam-critical distinction):

• Secrets Manager — Designed for application secrets (API keys, database passwords, OAuth tokens); offers built-in automated rotation and Lambda-based custom rotation; best when rotation is a requirement.
• Parameter Store — Designed for configuration values and can store encrypted strings (via SecureString type), but does NOT offer built-in automated rotation; best for static config that doesn't rotate frequently.
• Decision Rule: If the question mentions "automatic rotation" or "rotate every X days," the answer is Secrets Manager, not Parameter Store.

Secrets Manager vs. KMS (exam-critical distinction):

• Secrets Manager — A repository for application-level secrets (API keys, credentials); can use KMS for encryption.
• KMS — Manages cryptographic keys for encryption; does not store or manage application secrets. KMS can encrypt data, but it doesn't rotate API keys or database passwords.
• Decision Rule: If the question asks about storing/rotating API keys or application credentials, the answer is Secrets Manager. If it's about encrypting data, it might be KMS.

Exam Example (SAA-C03 pattern): "An application requires an API key for a third-party service. The security team mandates that the key must be rotated every 30 days. Which AWS service provides this rotation capability with the least operational overhead?"

• Correct Answer: AWS Secrets Manager — Natively supports automatic rotation for various secret types, including third-party API keys via Lambda integration.
• Why not Parameter Store? — While it can store encrypted strings, it does not offer built-in automated secret rotation.

Exam Example (SAA-C03 pattern): "A solutions architect needs a way to store and automatically rotate credentials used by an application to connect to an RDS database." Answer choices include AWS KMS and AWS Secrets Manager as distractors.

• Correct Answer: AWS Secrets Manager — Purpose-built for application secrets, with native integration for automated rotation, especially for RDS.
• Why not KMS? — KMS manages the cryptographic keys used for encryption but does not store or rotate the actual application credentials or passwords themselves.

Project Examples:

• Automatically rotating an RDS database password every 30 days.
• Storing an external API key and retrieving it securely from a Lambda function with automatic 30-day rotation.
• Rotating a Slack bot token every 60 days using a custom Lambda rotation function.

AWS Security Hub

Service Introduction: A cloud security posture management (CSPM) service that performs security best practice checks, aggregates alerts, and enables automated remediation.

Common Usage: Providing a single "pane of glass" for all security alerts from GuardDuty, Inspector, Macie, and IAM Access Analyzer.

Project Examples:

• Reviewing the overall security score of an AWS organization against CIS benchmarks.
• Consolidating security findings from 10 different accounts into one central dashboard.

AWS Shield

Service Introduction: A managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS.

Common Usage: Shield Standard provides automatic protection for all customers; Shield Advanced provides 24/7 access to the SRT and cost protection.

Project Examples:

• Protecting a high-traffic e-commerce site from L3/L4 DDoS attacks.
• Enabling Shield Advanced for an application's Route 53 and CloudFront resources.

AWS WAF

Service Introduction: A web application firewall that helps protect your web applications or APIs against common web exploits and bots.

Common Usage: Implementing "Defense in Depth" at L7 to block SQL injection, Cross-Site Scripting (XSS), and rate-limit bad actors.

Project Examples:

• Blocking traffic from specific geographic regions for an internal-only web portal.
• Rate-limiting requests to a login page to prevent brute-force attacks.

Defense-in-Depth: AWS WAF vs. AWS Shield Standard vs. Amazon GuardDuty

In the context of AWS security, AWS WAF, AWS Shield Standard, and Amazon GuardDuty serve distinct roles within a "defense-in-depth" strategy, protecting different layers of your architecture and addressing different types of threats.

AWS WAF (Web Application Firewall) AWS WAF is designed to protect your web applications and APIs at the Application Layer (Layer 7).

• Primary Function: It blocks common web exploits such as SQL injection (SQLi), Cross-Site Scripting (XSS), and malicious bots.
• Deployment: It can only be deployed on specific entry-point services: Application Load Balancer (ALB), Amazon API Gateway, and Amazon CloudFront.
• Control Mechanism: Users manually configure Web ACLs and rules to implement custom protections, such as rate-limiting requests to prevent brute-force attacks or blocking traffic from specific geographic regions.

AWS Shield Standard AWS Shield Standard is a managed Distributed Denial of Service (DDoS) protection service that operates at the Network (Layer 3) and Transport (Layer 4) levels.

• Primary Function: It provides baseline protection against common, volumetric DDoS attacks to ensure your applications remain available.
• Cost and Availability: It is free and always-on for all AWS customers by default.
• Operational Effort: Unlike WAF, Shield Standard is automatic and requires no user configuration. For enhanced protection, such as 24/7 access to a response team and cost protection, users must upgrade to AWS Shield Advanced.

Amazon GuardDuty Amazon GuardDuty is a threat detection service that provides continuous security monitoring for your AWS accounts and workloads.

• Primary Function: It identifies malicious activity and unauthorized behavior by analyzing data from VPC Flow Logs, AWS CloudTrail management and data events, and DNS logs.
• Common Findings: It is the primary tool for detecting threats like cryptocurrency mining (e.g., an EC2 instance communicating with a Bitcoin mining pool), unusual API call patterns, and compromised credentials.
• Operational Role: While WAF and Shield act as perimeter firewalls to block specific traffic, GuardDuty acts as a detective control to alert you if a resource within your account has already been compromised.

Comparison Summary for the SAA-C03 Exam

Feature	AWS WAF	AWS Shield Standard	Amazon GuardDuty
OSI Layer	Layer 7 (Application)	Layer 3 & 4 (Network/Transport)	Account/Workload Level
Protection Type	Preventative (Blocks exploits)	Preventative (Mitigates DDoS)	Detective (Identifies threats)
Target Threats	SQLi, XSS, Malicious Bots	Volumetric DDoS attacks	Compromised instances, compromised keys
Scope	ALB, API Gateway, CloudFront	All AWS services	Entire AWS Account
Cost	Paid (per ACL/rule/requests)	Free (included by default)	Paid (per data processed)

Decision Rule: Use AWS WAF to stop application-level attacks like SQL injection on your load balancer. Rely on AWS Shield Standard for automatic DDoS protection. Use Amazon GuardDuty to find out if an EC2 instance is performing anomalous activity or has been compromised.

IAM (Identity and Access Management)

Service Introduction: The core service for managing access to AWS resources securely by controlling who is authenticated and authorized.

Common Usage: Implementing the "Principle of Least Privilege" using Users, Groups, Roles, and JSON-based permission policies.

Types of IAM Roles (exam-critical — none of these are "custom-built from scratch"; each is a role you attach a policy to for a specific purpose):

An IAM Role is just an identity with permission policies attached that something (a person, an AWS service, or an application) can assume temporarily instead of using long-lived credentials. What varies is who assumes it and when AWS creates it for you vs. you create it yourself:

• IAM User — Not a role at all; a permanent identity (with its own long-term credentials/password) for a person or application. Roles exist as a safer alternative to giving out user credentials — there's no such thing as an "IAM User Role."
• Service Role (a role you create, e.g. Task Role, Task Execution Role, a Lambda execution role) — Assumed by an AWS service on your behalf to perform actions in your account, with permissions you define. In ECS specifically:
  • Task Role — Assumed by your application code inside the container to call other AWS APIs (S3, SQS, DynamoDB, etc.). Grant this the permissions your app itself needs.
  • Task Execution Role — Assumed by the ECS agent/infrastructure (not your app code) to pull the container image from ECR and push logs to CloudWatch, so the task can even start.
• Service-Linked Role — A special, predefined role that an AWS service (e.g., AWSServiceRoleForECS) creates and manages for itself to reach into your account and manage resources it needs — you don't author its permissions and typically can't edit them; it's not for granting your application custom permissions.
• Instance Profile Role — A role attached to an EC2 instance so that any process running on that instance (or the underlying host in ECS's EC2 launch type) can get temporary credentials without hardcoding keys. Doesn't apply to Fargate, since Fargate has no EC2 instance for you to attach a profile to.
• Cross-Account Role — A role in Account A that a trusted principal in Account B can assume, avoiding the need to share long-term credentials across accounts.
• Identity Federation Role — Assumed by an external identity (via SAML, OIDC, or Cognito Identity Pools) after they authenticate elsewhere, giving them temporary AWS access without an IAM User.

Decision rule for "which role" exam questions: ask what is calling AWS APIs. Your own app code inside a container/function → Task Role / Lambda execution role. The platform's own machinery (pulling images, writing platform logs) → Task Execution Role. A whole EC2 host → Instance Profile. A service itself acting autonomously → Service-Linked Role. A human or external identity → User or federation, not a service role at all.

IAM Groups (brief): A Group is just a named collection of IAM Users — not something a service or app assumes, and not itself a security principal. You attach a policy to the Group once, and every User in it inherits those permissions; add or remove a User from the Group to grant/revoke that access instantly. This is the standard way to manage permissions for people at scale (e.g., a "Developers" group, a "Billing-Admins" group) instead of attaching policies to each User individually. A Group cannot be nested inside another Group, and a Group cannot be referenced as the Principal in a resource-based policy (unlike Users and Roles) — only individual Users or Roles can be granted access that way.

Identity-based vs. Resource-based Policies — the Principal element (exam-critical): Both policy types share the standard elements — Effect (Allow/Deny), Action, and Resource — but only a resource-based policy (e.g., an S3 bucket policy, a KMS key policy, an SQS queue policy) requires a Principal element. It's mandatory there because the policy is attached to the resource itself, so it must explicitly state who is being granted access. An identity-based policy (attached to a User, Group, or Role) never includes a Principal — the identity it's attached to is the implicit principal, so specifying one is invalid. Decision Rule: If a question asks which element distinguishes the two policy types, the answer is Principal — not Effect, Action, or Resource, since those appear in both.

Project Examples:

• Enforcing Multi-Factor Authentication (MFA) for all users with administrative access.
• Granting a Lambda function a "Role" that allows it to only write to one specific S3 bucket.