AWS Security: A Practical Guide
How AWS security is organized, which services belong to which area, and the first controls to put in place. Service descriptions follow AWS documentation and the commands come from the AWS CLI reference, each linked to the AWS page it comes from. It covers the main security services, not every AWS service.
Last checked against AWS documentation: October 17, 2026
Start with the shared responsibility model
AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. Your responsibility is determined by the AWS services you select.
AWS shared responsibility modelThe seven areas of AWS security
The AWS Well-Architected Framework Security pillar says security in the cloud is composed of seven areas: security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. We use the same seven as the structure for this guide.
Which service sits under which area is our own grouping, not a mapping published by AWS. Many services serve more than one area. The service descriptions follow AWS documentation and each links to it.
1. Security foundations
Decisions made before any workload runs: how accounts are organized and which guardrails apply to all of them.
Helps you centrally manage and govern your environment as you grow and scale your AWS resources.
A type of organization policy that manages permissions in your organization. An SCP grants no permissions on its own. It sets limits on what IAM users and roles in member accounts can do. It does not affect users or roles in the management account, and it does not affect any service-linked role.
2. Identity and access management
Who and what can call which API, and what each of them is allowed to do.
A web service that helps you securely control access to AWS resources.
The AWS solution for connecting your workforce users to AWS managed applications and other AWS resources. It was named AWS Single Sign-On until it was renamed on July 26, 2022.
The AWS documentation lists these capabilities: external access analyzers, internal access analyzers, unused access analyzers, policy validation, custom policy checks, and policy generation. External access analyzers help identify resources in your organization and accounts that are shared with an external entity.
3. Detection
Knowing what happened and noticing what should not have.
Helps you enable operational and risk auditing, governance, and compliance of your AWS account.
Provides a detailed view of the configuration of AWS resources in your AWS account.
A threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs in your AWS environment.
Gives a comprehensive view of your security state in AWS and helps you assess your environment against security industry standards and best practices. The current documentation names it AWS Security Hub CSPM.
A fully managed security data lake service.
4. Infrastructure protection
Limiting what is reachable and filtering what reaches it.
Control the traffic that is allowed to reach and leave the resources they are associated with. Security groups are stateful.
Allow or deny specific inbound or outbound traffic at the subnet level. Network ACLs are stateless.
A web application firewall that lets you monitor the HTTP(S) requests forwarded to your protected web application resources.
Shield Standard and Shield Advanced provide protection against Distributed Denial of Service (DDoS) attacks. Shield Standard is provided automatically at no extra charge when you use AWS.
A stateful, managed network firewall and intrusion detection and prevention service for your VPC.
Simplifies administration and maintenance across multiple accounts and resources for protections including AWS WAF, AWS Shield Advanced, security groups and network ACLs, and AWS Network Firewall.
5. Data protection
Encryption, key control, secrets handling and finding sensitive data.
A managed service that makes it easy to create and control the keys used to encrypt and sign your data.
Helps you manage, retrieve, and rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycles.
A data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks.
6. Incident response
Investigating, containing and recovering when something goes wrong. The Security pillar also says to run incident response simulations ahead of time.
Helps you analyze, investigate, and quickly identify the root cause of security findings or suspicious activities.
7. Application security
Finding vulnerabilities in the software and workloads you run.
A vulnerability management service that automatically discovers workloads and continually scans them for software vulnerabilities and unintended network exposure.
The seven design principles
The same AWS Security pillar lists seven design principles. You can use them as a checklist when you review a design.
- 1. Implement a strong identity foundation
Apply least privilege and separation of duties, centralize identity management, and aim to eliminate reliance on long-term static credentials.
- 2. Maintain traceability
Monitor, alert, and audit actions and changes in your environment in real time, and integrate log and metric collection with systems that can investigate and act automatically.
- 3. Apply security at all layers
Use defense in depth with multiple controls, across the network edge, the VPC, load balancing, every instance and compute service, the operating system, the application and the code.
- 4. Automate security best practices
Automated software-based security mechanisms improve your ability to scale securely, more rapidly and cost-effectively. Define controls as code in version-controlled templates.
- 5. Protect data in transit and at rest
Classify data by sensitivity and use mechanisms such as encryption, tokenization and access control where appropriate.
- 6. Keep people away from data
Reduce or eliminate direct access and manual processing of data, which lowers the risk of mishandling, modification and human error.
- 7. Prepare for security events
Have incident management and investigation processes that fit your organization, run incident response simulations, and use automation to speed up detection, investigation and recovery.
First controls for a new AWS account
The selection and order of these nine controls is ours. Each control and caveat is based on the AWS documentation linked with it, and the commands are the examples in the AWS CLI reference, with placeholder names, IDs and bucket names that you must replace. Read each linked page before running anything in a real account, and test in a non-production account first.
Several of these settings apply per Region, as noted. This list is a starting point and does not replace an assessment of your own environment.
1. Protect the root user with MFA, and do not use it day to day
AWS says all account types (standalone, management and member accounts) require MFA on the root user, with a window of 35 days from the first sign-in attempt to register it. AWS strongly recommends that you do not access the root user unless a task requires root credentials, and that you do not create access keys for the root user, because root has full access to all services and resources in the account, including billing. It recommends creating an administrative user for everyday tasks instead. The root user page links to the steps for adding MFA.
AWS documentation2. Use temporary credentials instead of long-lived access keys
For people, AWS recommends federation through an identity provider, and recommends IAM Identity Center for centralized access management. For workloads on services such as EC2 or Lambda, an IAM role delivers temporary credentials, so there is no need to distribute IAM user keys to them. Where you need long-term credentials, AWS recommends updating the access keys when needed, for example when an employee leaves your company.
AWS documentation3. Create a multi-Region CloudTrail trail
Per the CloudTrail documentation, CloudTrail is enabled by default for your account and you automatically have access to event history, a record of the past 90 days of management events in a Region. For an ongoing record, AWS says to create a trail or an event data store. The create-trail page says a trail covers only the Region where you are signed in unless you ask for all Regions, and recommends all Regions as a best practice. Before running the command, note that if you use an existing S3 bucket, AWS says you must attach a policy to the bucket that allows CloudTrail to write to it. Replace the bucket name with your own.
aws cloudtrail create-trail --name Trail1 --s3-bucket-name amzn-s3-demo-bucket --is-multi-region-trail
aws cloudtrail start-logging --name Trail1The first line is the create-trail example and the second is the start-logging example from the CLI reference. The create-trail command also accepts --enable-log-file-validation, which is off by default.
AWS documentationstart-loggingCloudTrail event historyS3 bucket policy for CloudTrail4. Turn on S3 Block Public Access for the account
This is the AWS CLI reference example, which turns on all four block public access settings for the account. It applies to the whole account, so check first whether any bucket is meant to be public. The reference page also says the call may be restricted, with an Access Denied (403) error, when the account is managed by organization-level Block Public Access policies, and that organization-level policies override account-level settings. Replace the account ID with yours.
aws s3control put-public-access-block --account-id 123456789012 --public-access-block-configuration '{"BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true}'5. Require IMDSv2 on EC2 instances
With http-tokens set to required, a session token must be sent with instance metadata requests, and retrieving IAM role credentials always returns IMDSv2 credentials, so IMDSv1 credentials are not available. This command applies to one instance. Software on that instance that still relies on IMDSv1 will no longer get credentials that way, so check for it before you change a running instance (this consequence is our reading of the documentation, not a sentence on that page). Replace the instance ID.
aws ec2 modify-instance-metadata-options --instance-id i-1234567898abcdef0 --http-tokens required --http-endpoint enabled6. Enable GuardDuty
A GuardDuty detector represents the service in one Region. You must create a detector in each Region where you enable GuardDuty, and you can have only one detector per account per Region. AWS also says that when you enable GuardDuty for the first time it automatically enables all protection plans except Runtime Monitoring, with a 30-day free trial, so check the GuardDuty pricing before enabling it in production.
aws guardduty create-detector --enable7. Enable Security Hub (AWS Security Hub CSPM)
This enables Security Hub for your account in the current Region or the Region you specify. According to the CLI reference, enabling it also turns on two default standards: the CIS AWS Foundations Benchmark v1.2.0 and the AWS Foundational Security Best Practices standard. Other standards are not enabled automatically. Before enabling, note what AWS documents: you must enable AWS Config and record resources in it for Security Hub CSPM to generate most control findings. Security Hub CSPM only processes findings in the Region where you enabled it, and only findings generated after you enable it. The first time you enable it in an account, AWS enrolls that account in a 30-day free trial, during which you are still charged for other services it interacts with, such as AWS Config items.
aws securityhub enable-security-hub --enable-default-standardsThe CLI reference example for this command also includes an optional --tags argument, which we left out.
AWS documentationWhat is Security Hub CSPM (prerequisites and free trial)8. Create an IAM Access Analyzer analyzer
You can create only one analyzer per account per Region. AWS also says an external access analyzer only analyzes policies applied to resources in the same Region where it is enabled, so you need one in each Region where you use supported resources. The analyzer name is yours to choose.
aws accessanalyzer create-analyzer --analyzer-name example --type ACCOUNT9. Encrypt new EBS volumes by default
This enables EBS encryption by default for your account in the current Region. New volumes are then always encrypted. It has no effect on the encryption status of existing volumes, and after you enable it you can no longer launch instances of instance types that do not support encryption.
aws ec2 enable-ebs-encryption-by-defaultWant to see how your own account compares against a much longer list? The free AWS security checklist has 360 checks across 60 services.
When something goes wrong
AWS says its Security Incident Response engineers follow a structured process aligned with the NIST 800-61r2 framework, and that during an investigation in that service you can expect these five phases. They describe that service, not a general lifecycle:
We publish 12 step-by-step incident response playbooks for common AWS scenarios, including compromised IAM keys and unauthorized root access.
Go deeper
Security Cards
Reference cards for individual AWS services: attack vectors, misconfigurations and defenses.
Best Practices
In-depth security guides per AWS service.
IAM Security Guide
Identity and access management from fundamentals to monitoring.
S3 Security Guide
Protecting data in S3, with checks and remediation.
Incident Response Playbooks
Step-by-step runbooks for common AWS incidents.
Compliance Frameworks
What CIS, PCI DSS, SOC 2, ISO 27001, GDPR, HIPAA, NIST 800-53, DORA and FFIEC cover.
AWS Security Checklist
A free interactive checklist to track your progress.
State of AWS Security 2026
Our free whitepaper.
Weekly AWS Security News
A weekly digest of AWS security changes.
Security Specialty Exam Guide
The AWS Certified Security - Specialty (SCS-C03) exam, domain by domain.
Frequently Asked Questions
KloudSec, built by the team behind Toc Consulting
See AWS security checked automatically, continuously
What you just read is a manual, one-time check. KloudSec runs this and 400+ more automated checks across 90+ AWS services, continuously, agentless, live in about 5 minutes.