Cheat Sheet: AWS Security and Compliance

Domain 2 is 30% of the scored content, second only to Cloud Technology and Services at 34%. Most of it comes down to two things: knowing which side of the shared responsibility line a task falls on, and knowing which service answers which security question. Skim the tables, drill the traps.

The shared responsibility model at a glance

AWS is responsible for security of the cloud. The customer is responsible for security in the cloud.

AWS is responsible for	The customer is responsible for
Physical security of data centres	Customer data, and who can reach it
Hardware, and the global infrastructure (Regions, Availability Zones, edge locations)	Identity and access management: users, groups, roles, policies
The host operating system and virtualisation layer	Guest operating system: patching, hardening, configuration
Managed service software and patching	Application software and its configuration
Network infrastructure and its physical security	Network traffic protection: security groups, network ACLs, firewall rules
Decommissioning and destroying storage media	Client-side and server-side encryption choices, and key management

The line moves depending on how managed the service is.

Service	AWS handles	The customer handles
Amazon EC2	Hypervisor, host OS, hardware	Guest OS patching, application, firewall rules, data, encryption choice
Amazon RDS	Database engine patching, OS, backups, hardware	Database users and permissions, network access, encryption choice, what is stored
AWS Lambda	Everything under the function: OS, runtime patching, scaling	Function code, its IAM role, environment variables, data handled
Amazon S3	Durability, the storage infrastructure, the service software	Bucket policies, Block Public Access, object ACLs, encryption choice, what is stored

Three things are always the customer’s, whatever the service: the data, who has access to it, and how it is classified. Nothing on that list moves to AWS when you pick a more managed service.

Identity and access management at a glance

• Root user. The identity created with the account, signed in with the email address. It has unrestricted access, so lock it down and keep it out of daily work.
• IAM user. A long-lived identity for a person or an application. It carries a password, access keys, or both.
• IAM group. A collection of users that policies attach to. Groups cannot be nested.
• IAM role. An identity assumed temporarily, with no long-term credentials. Services, EC2 instances, cross-account access and federated users all run on roles.
• IAM policy. A JSON document that allows or denies permissions. Identity-based policies attach to a user, group or role; resource-based policies attach to the resource itself.
• AWS managed policy. Written and maintained by AWS. Quick to apply, and usually broader than the task needs.
• Customer managed policy. Written by you, reusable across identities. This is the route to least privilege.
• Inline policy. Embedded in a single identity. It goes when the identity goes, and it is harder to audit.
• IAM Identity Center. Workforce sign-in, with permission sets applied across many accounts. It connects an external identity provider, and it is the current answer for human users.
• Least privilege. Grant only the permissions a task needs. Start with nothing and add, rather than starting broad and trimming.

How a request is evaluated. Everything is implicitly denied by default. An explicit Allow grants it. An explicit Deny anywhere overrides any allow. That order does not change.

Roles over keys. An EC2 instance, a Lambda function or an ECS task that needs AWS permissions should carry a role. Credentials are then temporary and rotated automatically, and there is no access key to leak in a repository.

Protecting the root user

• MFA on the root user is mandatory. AWS requires it on standalone, management and member accounts, and allows 35 days from the first console sign-in attempt to register it. Passkeys, security keys, authenticator apps and hardware TOTP tokens all qualify.
• Delete root access keys, or never create them. Programmatic root access has no legitimate daily use.
• Use a strong, unique password and an address the organisation controls. Recovery runs through that email address and phone number.
• Create an administrative identity for daily work. Day-to-day administration does not need root.
• Apply a password policy to IAM users. Length, complexity, rotation, reuse prevention.

Tasks only the root user can perform:

• Change the root user’s email address, password or access keys, on a standalone account
• Close the AWS account, on a standalone account
• Restore IAM user permissions after the only administrator has revoked their own
• Activate IAM access to the Billing and Cost Management console, and view certain tax invoices
• Register as a seller in the Reserved Instance Marketplace
• Turn on MFA Delete for an S3 bucket
• Repair an S3 bucket policy or an SQS queue policy that denies every principal
• Sign up for GovCloud, and request GovCloud root access keys

Two qualifications on that list. Inside AWS Organizations, the management account and its delegated administrators can close member accounts and update their root email addresses, account names and contact details. Centralised root access goes further, letting them remove member root credentials altogether and repair those all-principals-denied S3 and SQS policies. That is how an organisation avoids depending on member-account root credentials, and it is why the notes above say “standalone account”.

And changing the Support plan is not a root-only task, despite appearing on most of the lists you will find elsewhere. AWS governs it with IAM permissions and publishes managed policies for it, so an administrator can change it. The account name is not root-only either, though the root email address on a standalone account is.

Detection, audit and monitoring at a glance

Question	Service	Notes
Who called which API, when, and from where?	AWS CloudTrail	Management, data, network activity and Insights events; an organisation trail covers every account
What is the configuration of this resource, and what was it last month?	AWS Config	Configuration history, relationships and rules; answers “what changed”
Is the metric outside its normal range, and what do the logs say?	Amazon CloudWatch	Metrics, alarms, logs, dashboards
Is something malicious happening in the account?	Amazon GuardDuty	Threat detection from CloudTrail management events, VPC Flow Logs and Route 53 Resolver DNS query logs, with no agent to install
Does this EC2 instance or container image have known vulnerabilities?	Amazon Inspector	Continuous vulnerability scanning of EC2 instances, ECR container images and Lambda functions
Is there sensitive data in this S3 bucket?	Amazon Macie	Discovers and classifies sensitive data in S3, and only in S3
What is the overall security posture across accounts?	AWS Security Hub CSPM	Aggregates findings from the services above and scores them against standards such as AWS FSBP, CIS, PCI DSS and NIST
How did this incident unfold?	Amazon Detective	Builds a linked view of events for investigation
Who can reach this resource from outside the account?	IAM Access Analyzer	Finds resources shared with external principals, and reports unused roles, keys and permissions

Watch the naming here. The standards-and-findings service is now AWS Security Hub CSPM, and the name AWS Security Hub belongs to a newer service that correlates and prioritises alerts across accounts. Study material written before the split calls the CSPM service Security Hub.

The three that get confused. CloudTrail records who did what. Config records what the resource looks like and how it changed. CloudWatch records how it is behaving. An unauthorised API call is a CloudTrail matter; a security group that drifted from its approved state is a Config matter; CPU or an error rate is CloudWatch.

Protective services at a glance

• AWS WAF. Filters HTTP requests: SQL injection, cross-site scripting, rate limiting, geo-blocking.
• AWS Shield Standard. Automatic for every AWS customer at no extra charge. It defends against the common network and transport layer DDoS attacks, and Route 53, CloudFront and Global Accelerator get the fullest benefit.
• AWS Shield Advanced. A paid subscription. It adds application-layer protection through WAF, health-based detection, protection groups, access to the Shield Response Team, and cost protection as service credits for attack-driven scaling charges. Reaching the SRT also requires Business or Enterprise Support.
• AWS Firewall Manager. Applies WAF web ACLs, Shield Advanced protections, Network Firewall rules and security group rules across many accounts centrally.
• AWS Network Firewall. A stateful network firewall inside a VPC.
• Security groups and network ACLs. Security groups are stateful, take allow rules only, and attach to an ENI. Network ACLs are stateless, take allow and deny rules, and attach to a subnet.

Encryption and secrets at a glance

• AWS KMS. Creates and controls encryption keys: AWS owned keys, AWS managed keys, and customer managed keys, which can use key material you import.
• AWS CloudHSM. A dedicated single-tenant hardware security module, usually chosen to satisfy a compliance requirement.
• AWS Certificate Manager. Issues and manages TLS certificates for AWS services. Public certificates issued for use with integrated services carry no charge and renew automatically. Exportable public certificates and private certificates from AWS Private CA are billed separately.
• AWS Secrets Manager. Stores, retrieves and rotates database credentials and API keys, with automatic rotation and native database integrations. It is billed per secret per month and per API call.
• AWS Systems Manager Parameter Store. Stores configuration data, and secrets as SecureString parameters encrypted with KMS. There is no built-in rotation, and standard-tier parameters carry no additional charge.

Encryption in transit is TLS between the client and the service, and between services. Encryption at rest is the data on disk. S3 applies SSE-S3 to every new object as a base level of encryption, and has done since January 2023. EBS volumes and RDS instances take an encryption setting at creation, and KMS holds the keys.

Compliance and governance at a glance

• AWS Artifact. Self-service downloads of AWS’s SOC reports, ISO certifications and PCI DSS attestations, free of charge. Agreements such as the Business Associate Addendum are reviewed and accepted here too.
• AWS Audit Manager. Collects evidence continuously and maps it to a control framework.
• The AWS Compliance Programs pages. Which services are in scope for which certification.
• Region choice. Data residency in a particular country comes from choosing the Region. AWS does not move customer data out of the Region it was stored in without instruction.
• AWS Organizations. Service control policies cap the permissions available to principals in member accounts, and resource control policies cap the permissions available on resources. AWS Control Tower sets up a governed landing zone on top.
• AWS Trusted Advisor. Checks across six categories: cost optimisation, performance, security, fault tolerance, service limits, and operational excellence.
• AWS Trust and Safety. Where abuse of AWS resources gets reported.
• Penetration testing. Permitted against a defined list of services with no prior approval, EC2, RDS, CloudFront, API Gateway, Lambda and Fargate among them. Red team exercises, phishing simulations and malware testing need authorisation, requested at least two weeks ahead.

Where to read about security

• AWS Security Center. Security bulletins, compliance information and practices.
• AWS Security Blog. Announcements and how-to material.
• AWS Knowledge Center. Answers to frequently asked support questions.
• AWS re:Post. Community question and answer, successor to the AWS Forums.
• AWS Prescriptive Guidance. Patterns, guides and strategies from AWS teams.
• AWS Marketplace. Third-party security products, including appliances and agents, billed through your account.

Traps

• The customer always owns the data. No service, however managed, moves responsibility for data, classification, or who has access to it.
• Patching depends on the service. The customer patches the guest OS on EC2. AWS patches the database engine on RDS and everything under a Lambda function.
• CloudTrail is not CloudWatch is not Config. Who called the API, how the resource is behaving, and what the resource is configured as, in that order.
• GuardDuty detects, Inspector scans, Macie classifies, Security Hub CSPM aggregates. Four different questions.
• Shield Standard is automatic and free. Advanced is the paid tier, with the Shield Response Team and cost protection.
• Security groups are stateful and allow-only; network ACLs are stateless and take deny rules. A return packet needs an explicit ACL rule, and does not need a security group rule.
• An explicit deny always wins. No allow anywhere overrides it.
• IAM is global, not Regional. Users, groups, roles and policies are not created per Region.
• Groups are not principals. A policy cannot name a group in its Principal element, and groups cannot be nested.
• A role has no long-term credentials. That is what makes it the fit for an EC2 instance or a cross-account grant, rather than an access key.
• Artifact holds AWS’s compliance reports, not your own evidence. Audit Manager collects yours.
• MFA on the root user is the control a scenario about account protection is usually looking for, and AWS now requires it on every account type.
• Changing the Support plan is not a root-only task. IAM permissions govern it, and a lot of study material still says otherwise.