AWS Security - The Complete Guide

The Well-Architected Security Pillar, the AWS service catalog (GuardDuty, Security Hub, IAM, KMS, WAF, Macie, Inspector and the rest), a secure multi-account landing zone reference architecture, the top 10 AWS misconfigurations, AWS-specific attack paths, side-by-side comparisons against Azure and GCP, and deep cross-references to every cloud-security discipline as it runs on AWS. Vendor-neutral analysis from someone who works the platform every day.

AWS service catalog → Top 10 misconfigurations
Rows of illuminated server racks inside a data center
Photo from Pexels

· · Vendor-neutral · View source on GitHub

The 30-second version: AWS is the largest cloud by usage, the largest by service surface, and the largest by attacker interest. Most people who type "cloud security" into a search bar actually mean "AWS security," because AWS is the cloud they run. The platform is mature, the primitives are well-documented, and the failure modes are well-known - IAM that's too broad, S3 buckets that are too public, IMDS that's too easy to abuse, CloudTrail that's missing in some region. This page is the index: the Well-Architected Security Pillar, the service catalog with opinionated commentary on each one, a reference landing-zone architecture, the top 10 misconfigurations, the attack paths AWS specifically enables, and deep cross-references into every discipline page with AWS-specific anchors.

If you want one number: the shared responsibility model moves the line - AWS owns the physical and the hypervisor; you own the configuration, the identity, the data, and almost every misconfiguration the attacker exploits. Build the muscle, then let the certifications and the CSPM follow.

On this page

  1. Why AWS-specific guidance matters
  2. The shared responsibility model on AWS
  3. The Well-Architected Security Pillar
  4. AWS security service catalog
  5. Reference architecture - multi-account landing zone
  6. Top 10 AWS misconfigurations
  7. AWS-specific attack paths
  8. Service comparisons (AWS vs Azure vs GCP)
  9. Discipline cross-references
  10. AWS certifications track
  11. AWS-native vs third-party tooling
  12. Further reading
  13. FAQ
  14. Where next

Why AWS-specific guidance matters

"Cloud security" as a category exists because the disciplines - identity, network, data, detection, response - rhyme across providers. But the controls don't translate one-to-one. An IAM policy in AWS is a different shape from an Azure RBAC role assignment, which is a different shape from a GCP IAM binding. A GuardDuty finding triggers a different response runbook than a Defender for Cloud alert. The misconfigurations that breach AWS environments (public S3, IMDSv1 abuse, wildcard Resource: *) are not the same as the ones that breach Azure environments (over-privileged service principals, public storage accounts, exposed managed identities).

This page is the AWS-specific entry point. If you're a practitioner who runs workloads on AWS, this is where to start; the deeper discipline pages (IAM, network, data, detection, IR) each have an AWS anchor that drills in. If you run multi-cloud, pair this page with Azure Security and GCP Security, and consult the side-by-side comparison when you need to translate.

The opinions on this page are vendor-neutral but not provider-neutral. AWS gets credit for what it does well (IAM expressiveness, service breadth, partner ecosystem, deep documentation) and gets criticized for what it does badly (defaults that favor functionality over safety, naming that drifts over time, IAM that is uniquely capable of producing surprising privilege-escalation paths).

The shared responsibility model on AWS

AWS owns security of the cloud - the hardware, the hypervisor, the physical data center, the network backbone, and the parts of managed services you cannot see. You own security in the cloud - your identities, your network configuration, your OS and application patching (where applicable), your data and its encryption, and the configuration of every service you turn on. The line shifts by service: on EC2 you own a lot (OS, patches, agent posture, security groups); on RDS you own less (no OS, but still network, IAM, and encryption); on Lambda you own only the code, the IAM role, and a few runtime knobs; on S3 you own only the configuration and the data, but those two account for most S3 breaches. See the full shared responsibility model page for the table-form breakdown across AWS, Azure, and GCP.

Two practical implications. First, every audit conversation begins with you handing the auditor AWS's downloaded SOC 2 / ISO 27001 / PCI DSS reports (from AWS Artifact) to cover AWS's half, and then producing your own evidence - CloudTrail, Config, Security Hub findings, IAM exports - for your half. Second, almost every cloud breach you've read about happened on the customer's side of the line. AWS having FedRAMP High doesn't make your S3 bucket private.

The Well-Architected Security Pillar

The AWS Well-Architected Framework codifies what AWS thinks "good" looks like, and the Security Pillar lays out seven design principles. They are unglamorous, mostly common sense, and consistently the right answer when teams disagree about how to build something.

1. Implement a strong identity foundation

Centralize identity through IAM Identity Center (or your IdP federated through it). Eliminate long-lived IAM users for humans. Enforce least privilege via IAM policies, permission boundaries, and Service Control Policies. Use IAM Access Analyzer to surface unintended external access. The identity foundation is the only one that touches every other pillar.

2. Maintain traceability

Turn on CloudTrail in all regions, with an organization trail centralized to a log-archive account. Enable VPC Flow Logs, ALB / CloudFront access logs, and CloudTrail data events for sensitive S3 buckets. Aggregate to Security Hub and ship to a SIEM. The first 24 hours of an incident is forensic-quality logs, or it's nothing.

3. Apply security at all layers

Defense in depth: SCPs at the org perimeter, network controls at the VPC edge, host controls inside the VPC, application controls in the workload, data controls under the workload. Each layer assumes the one above will fail. Single-layer security is single-point-of-failure security.

4. Automate security best practices

Detective controls - Security Hub, Config rules, GuardDuty findings - should auto-route to EventBridge, into either ticketing or auto-remediation Lambdas. Preventive controls - SCPs, permission boundaries, Config conformance packs - should ship as code. Manual security at scale is no security.

5. Protect data in transit and at rest

Encrypt-by-default through KMS-managed keys; reach for customer-managed KMS keys (CMKs) where compliance, key-rotation, or cross-account access policy demands it. TLS 1.2+ at every public edge via ACM-issued certificates. S3 Block Public Access on at the account level. Macie for sensitive-data discovery. The encryption is easy; the key-management story is the work.

6. Keep people away from data

Humans should not have direct production-data access. Build query interfaces, redacted exports, and break-glass workflows that produce audit logs. Use Session Manager (not SSH bastions) for any necessary host access. The fewer hands that touch raw data, the smaller the blast radius of any compromised credential.

7. Prepare for security events

Have an IR runbook. Run game-days against it. Pre-stage IR tooling in a forensics account with EBS-snapshot copy permissions. Practice the chain - detection in GuardDuty / Security Hub, triage in Detective, evidence collection via API, containment via SCPs / quarantine VPCs. The runbook you've never executed will not work the first time.

The pillar's value isn't novelty - none of these are surprising. The value is that they're documented, prioritized, and reviewed annually by AWS, so when an engineering team and a security team disagree on direction, "what does the Well-Architected Security Pillar say?" is a productive question.

AWS security service catalog

AWS ships dozens of security services across overlapping problem domains. Below is the opinionated tour - what each service does, when it earns its keep, and where it falls short. Grouped by function, not by AWS console category.

Detection

GuardDuty

Managed threat detection across CloudTrail, VPC Flow Logs, DNS logs, EKS audit logs, S3 events, RDS login activity, EC2 runtime (with the agent), and Lambda runtime. The first detective control to turn on in every account. Findings are high signal; the noise is manageable. Turn it on org-wide via the delegated-admin pattern.

Security Hub

Findings aggregator and CSPM. Pulls from GuardDuty, Inspector, Macie, IAM Access Analyzer, Config, and dozens of partners. Runs CIS / PCI / NIST / AWS Foundational Security Best Practices conformance packs. Push to EventBridge for routing. Single pane of glass for AWS-native findings; not a substitute for a third-party CNAPP if you're multi-cloud.

Detective

Investigation graph that ingests CloudTrail and VPC Flow Logs and lets you pivot between IPs, IAM principals, and resources to chase down the timeline of an incident. Pairs with GuardDuty findings as the "what happened next" view. Earns its keep during an IR; spend less time in it day-to-day.

Inspector

Vulnerability scanner for EC2, ECR container images, and Lambda functions. Agentless for EC2 via SSM, image-pull-time for ECR, on-deploy for Lambda. CVE-based; results show in Security Hub. Good baseline; a third-party scanner (Wiz, Snyk, Trivy in CI, etc.) tends to outperform on container depth.

Macie

Sensitive-data discovery for S3. Scans for PII, financial data, credentials, and custom data identifiers. Per-GB pricing makes "scan everything" expensive; the right pattern is targeted scans on data classifications you care about. Findings flow to Security Hub.

Audit Manager

Pulls evidence (CloudTrail logs, Config snapshots, API outputs) on a schedule and maps it against prebuilt frameworks (SOC 2, PCI DSS, NIST 800-53, HIPAA, etc.). Useful inside an AWS-centric GRC program; less useful if your evidence story spans multiple clouds (use a dedicated GRC platform instead).

AWS Config

Resource-configuration history and rule evaluation. The substrate every other AWS detection service depends on - turn it on org-wide and aggregate to a central account. Managed and custom rules; conformance packs for frameworks. Cost grows with resource count and rule count; review periodically.

CloudTrail

The audit log of the AWS control plane. Management events (free); data events for S3 / Lambda / DynamoDB (paid, on-by-default-off). Org trail to a log-archive account is the only correct configuration. Most cloud breach investigations begin and end in CloudTrail.

Network Firewall

Managed stateful firewall with Suricata-compatible rules, deployed at VPC egress. Earns its keep for egress filtering, IDS/IPS on north-south traffic, and TLS-SNI-based blocklisting. Per-GB pricing means you'll think hard about scope.

Route 53 Resolver DNS Firewall

Block DNS resolution to known-bad domains (or any domain list you maintain). Cheap, high-signal preventive control. Catches malware C2, accidental data exfil to file-share domains, and the long tail of "we should not be talking to that." Use AWS-managed domain lists or your own.

Identity

IAM

The per-account identity service. Users, groups, roles, policies, permission boundaries, condition keys. Uniquely expressive - and uniquely capable of producing surprising privilege-escalation paths. Almost every AWS breach involves an IAM misuse. Read the IAM page for the deep dive.

IAM Identity Center

The workforce identity service (formerly AWS SSO). Federates your IdP (Okta / Entra ID / Google Workspace / its own directory) into AWS Organizations and brokers short-lived role sessions across accounts. The right answer for all human access in 2026. Eliminate IAM users for humans entirely.

IAM Access Analyzer

Free service that surfaces resources (S3 buckets, KMS keys, IAM roles, Lambda functions, SQS queues, Secrets Manager secrets) shared with external accounts or the public, plus unused access findings and policy validation. Turn it on org-wide; review the public/external findings weekly.

IAM Roles Anywhere

Lets workloads outside AWS (on-prem, other clouds, SaaS) authenticate via X.509 certificates and assume IAM roles for short-lived credentials. The replacement pattern for hard-coded AWS access keys on non-AWS hosts. Use it.

Cognito

Customer identity service - user pools for the directory, identity pools for federated identity to AWS resources. Fine for B2C apps; not the right place for workforce identity (use Identity Center) or fine-grained authorization (build that yourself or use a dedicated authZ service).

Resource Access Manager (RAM)

Shares resources (VPC subnets, Transit Gateway attachments, License Manager configurations, etc.) across accounts within an Organization. Underused - many teams stand up VPC-per-account when a shared-services pattern via RAM is cleaner. Audit who has shared what; over-sharing is a real risk.

Data

KMS

The crypto API for AWS. AWS-managed keys (free, per-service), customer-managed keys (CMKs, $1/month + API calls), and external / XKS keys. The key policy is the access-control surface most teams under-invest in. Rotate yearly; restrict kms:Decrypt via condition keys; alarm on key deletion.

CloudHSM

Dedicated FIPS 140-2 Level 3 hardware. Needed for very specific regulatory requirements (some payment-card flows, regulated industries that require single-tenant HSM). For almost all customers, KMS is the right answer. Don't over-engineer here.

Secrets Manager

Centralized secrets storage with automatic rotation, KMS-backed encryption, and IAM-controlled access. Pairs with Parameter Store for non-secret config. Use it instead of environment-variable secrets in Lambda or container task definitions.

ACM

Free public TLS certificates for ALB, NLB, CloudFront, API Gateway, and other AWS endpoints. ACM Private CA for internal PKI. Auto-renews public certs; treat the private-CA hierarchy with the same gravity you'd treat any root-of-trust.

S3 Block Public Access

Account-level and bucket-level setting that overrides any public ACL or bucket policy. Turn on at the account level on day one, then carve out the (vanishingly rare) buckets that legitimately need public access via OAC / CloudFront. The most impactful single click in AWS security.

S3 Object Lock

WORM (write-once-read-many) protection for S3 objects in Compliance or Governance mode. The control of choice for ransomware-resistant backups; pairs with versioning and replication to a separate account. See backup & DR for the pattern.

Network

AWS WAF

Web application firewall for ALB, CloudFront, API Gateway, App Runner, and Cognito user pools. Managed rule groups (AWS-managed and Marketplace). Good baseline; for high-volume apps or sophisticated bot management, Cloudflare and Akamai are typically deeper. Pair with rate-based rules and the AWS Managed Bot Control rule group.

Shield (Standard & Advanced)

Standard is free and automatic against L3/L4 DDoS for all AWS customers. Advanced ($3K/month) adds L7 protection, the DDoS Response Team, and cost-protection credits if you get attacked. Worth the spend only for high-profile or revenue-critical public surfaces.

VPC

The network primitive. Subnets, route tables, NAT gateways, internet gateways, VPC endpoints. Design once, change reluctantly - every workload depends on it. See network security on AWS for the patterns.

Security Groups & NACLs

Security Groups are stateful, instance-level, allow-only. NACLs are stateless, subnet-level, allow-and-deny. Use Security Groups as the primary control; reach for NACLs only when you need an explicit deny rule at the subnet boundary. 0.0.0.0/0 on SSH or RDP is a finding, not a configuration.

PrivateLink

Private connectivity to AWS services and partner / customer services without traversing the internet. Use VPC endpoints (interface and gateway flavors) to keep S3, KMS, Secrets Manager, and the rest of the control plane off the internet. Cheap, high-impact.

VPC Lattice

Application-layer service-to-service networking across VPCs and accounts, with IAM-authenticated calls and observability. The newer answer for what used to be Transit Gateway + complex SG plumbing. Worth piloting for service-mesh use cases that don't need a full service mesh.

Network Firewall & Cloud WAN

Network Firewall sits at VPC egress with Suricata rules; Cloud WAN is the managed global backbone for connecting many VPCs and on-prem sites. Enterprise patterns; small shops over-buy these.

Compliance & governance

Audit Manager

Continuous evidence collection mapped to frameworks. Useful inside the AWS perimeter; pairs poorly with multi-cloud GRC where you'd want a dedicated platform. See the GRC page for the broader landscape.

AWS Artifact

Self-serve portal for AWS's compliance reports (SOC 1/2/3, ISO 27001/27017/27018, PCI DSS, FedRAMP, HIPAA BAA, and more). The first stop in every auditor conversation - download AWS's reports to cover the provider half of shared responsibility.

Control Tower

Opinionated multi-account landing-zone framework. Deploys Organizations, OUs, Identity Center, log-archive and audit accounts, an org-wide CloudTrail, a Config aggregator, and a starter set of preventive (SCPs) and detective (Config rules) guardrails. The default starting point for new AWS deployments in 2026.

Organizations + SCPs

Organizations is the account-grouping layer. SCPs (Service Control Policies) are the org-perimeter preventive control - they constrain what IAM principals in member accounts can do, no matter what their IAM policies say. The strongest preventive control in AWS; use them sparingly and explicitly.

Incident response

Detective

The investigation graph (see above). The "next page" in an IR after a GuardDuty finding triggers a ticket.

Security Hub

The findings aggregator and triage console during an event. Pre-build your insights and saved searches before you need them.

Systems Manager Incident Manager

Incident-orchestration service - escalation chains, response plans, runbook automation, post-incident review templates. Genuinely useful even outside AWS-only environments. Pairs with EventBridge to trigger incidents from GuardDuty severity thresholds.

AWS IR runbook library

AWS publishes a customer IR playbook framework on GitHub with prebuilt runbooks for credential exposure, IAM compromise, S3 exposure, and others. Fork, customize, run game-days against. See IR on AWS for the operational pattern.

Reference architecture - multi-account landing zone

The right starting shape for any AWS deployment past three accounts is a multi-account landing zone built on Organizations, Control Tower, and Identity Center. The pattern below is the one that almost every well-run AWS estate converges on, regardless of whether they started there.

Control Tower deploys most of this in an afternoon. The AWS Landing Zone Accelerator (LZA) is the CDK/CloudFormation alternative for environments that need bespoke control sets Control Tower can't express. Read the landing zones page for the full architectural treatment, including diagrams.

Top 10 AWS misconfigurations

Synthesized from the CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, and the post-mortems of the public AWS breaches of the last several years. Roughly in order of how often each shows up in actual incidents.

  1. Public S3 buckets. Still the canonical AWS breach. Mitigation: S3 Block Public Access at the account level, IAM Access Analyzer alerts on public buckets, SCPs that deny s3:PutBucketPolicy with public statements. The fix is a single click; the audit ritual is to verify it's clicked.
  2. IMDSv1 still enabled. The Instance Metadata Service v1 is fetchable via blind SSRF - and SSRFs in cloud workloads are a top finding. IMDSv2 requires a PUT to get a session token before the GET. Mitigation: enforce IMDSv2 via account-level setting, EC2 launch templates, and a Config rule that flags exceptions.
  3. No MFA on the root account. Root has unrestricted access; MFA is the only credential-theft protection. Hardware MFA, password in a corp secrets vault with break-glass procedure, alerting on root login. CIS check 1.4, and it should never fail.
  4. Wildcard IAM policies (Action: * or Resource: *). Especially in custom policies - managed policies are at least scoped. Action: * on a role used by Lambda is a privilege escalation away from total account compromise. Mitigation: permission boundaries, Access Analyzer's policy validation, periodic least-privilege reviews via CloudTrail-derived access reports.
  5. Public RDS snapshots. An RDS snapshot shared publicly exposes the entire database. Mitigation: SCP denying rds:ModifyDBSnapshotAttribute with public, Config rule, weekly scan via IAM Access Analyzer's RDS coverage.
  6. Exposed AWS access keys in public repositories. Long-lived IAM user keys committed to GitHub get scraped within minutes - AWS's own scanners catch many, but not all. Mitigation: eliminate long-lived keys (Identity Center for humans, IAM roles for workloads, Roles Anywhere for non-AWS workloads), GitHub secret scanning, GitGuardian / TruffleHog in CI.
  7. Security Groups open to 0.0.0.0/0 on SSH / RDP. Endless scanning. Use Session Manager for host access; if you must SSH from a fixed range, lock the SG down to that range. Better: don't SSH at all.
  8. Default VPC used in production. The default VPC has overly permissive defaults (Internet Gateway, default SG allowing internal traffic). Delete it in every region in every account, and force teams to think about networking when they create one.
  9. CloudTrail not enabled in all regions, or not enabled with management events. Attackers pivot to disabled regions. Mitigation: an org-wide trail covering all regions, including future ones, delivering to the log-archive account, with log-file validation.
  10. Root account used for daily operations. Root should be locked away. Daily use means there's no IAM model. Mitigation: Identity Center for humans, alarm on every root sign-in, audit log review.

Every one of these is a single line in a Security Hub or CSPM dashboard. The point isn't that they're undetectable - they're trivially detectable. The point is that they keep showing up because the defaults favor functionality, the org-level controls are opt-in, and turnover means new accounts get spun up without the central guardrails until somebody notices.

AWS-specific attack paths

The attack patterns below are the ones AWS specifically enables. They're not novel - many derive from generic SSRF, supply-chain, or credential-theft chains - but the AWS-specific mechanic is the part worth knowing. See cloud pentesting on AWS for the offensive-side treatment.

Service comparisons (AWS vs Azure vs GCP)

The right tool is rarely AWS-only or third-party-only - it's the one that fits your shape. The tables below are deliberately opinionated; calibrate against your own environment.

Threat detection: GuardDuty vs Defender for Cloud vs Security Command Center

Dimension AWS GuardDuty Azure Defender for Cloud GCP Security Command Center
Pricing modelPer GB of analyzed logs + per million eventsPer resource per month (plan tiers)Premium tier per asset
Coverage breadthCloudTrail, VPC Flow, DNS, EKS, S3, RDS, Lambda, EC2 runtimeVMs, containers, storage, databases, App Service, key vault, DNS, APIs, AIVMs, containers, IAM, storage; weaker network
Posture managementSeparate - Security HubBundled - CSPM in Defender CSPM tierBundled - SCC Premium
Attack-path graphNo (need third-party CNAPP)Yes (in Defender CSPM)Yes (in SCC Enterprise)
Multi-cloudAWS onlyMulti-cloud (AWS & GCP supported)Multi-cloud in Enterprise tier
When it winsSingle-cloud AWS shops disciplined about tuningMicrosoft-heavy enterprises; integrated with SentinelGCP-first shops, especially with BigQuery analytics

WAF: AWS WAF vs Cloudflare vs Akamai

Dimension AWS WAF Cloudflare Akamai
DeploymentALB / CloudFront / API Gateway / App Runner / CognitoCloudflare proxy in front of any originAkamai edge in front of any origin
Bot managementManaged Bot Control rule group (good baseline)Strong; bot-management product is matureStrong; long-standing product
DDoSShield Standard free; Advanced $3K/moIncluded; unmetered on enterpriseIncluded; unmetered on enterprise
LatencyAdds little if origin is AWSReduces - global edge usually closer to userReduces - largest CDN footprint
Pricing modelPer request + per rulePlans, with enterprise commit pricingEnterprise commit, generally higher
When it winsAWS-only public surfaces; cost-sensitiveMulti-origin; deep bot needs; integrated CDNEnterprise with strict perf SLAs and global footprint

Vulnerability scanning: Inspector vs Wiz vs Orca

Dimension AWS Inspector Wiz Orca
Cloud coverageAWS onlyMulti-cloud (AWS, Azure, GCP, OCI, Alibaba)Multi-cloud (AWS, Azure, GCP)
Workload scan modelSSM agent for EC2; image scan for ECR; on-deploy for LambdaAgentless via snapshotAgentless via snapshot (SideScanning)
Container depthECR; basic K8sDeep K8s, including admission controlDeep K8s
Attack-path graphNoYes - flagshipYes
Identity correlationVia Security Hub aggregationFirst-class identity graphFirst-class identity
When it winsCost-sensitive AWS-only shopsMulti-cloud enterprise; graph-driven prioritizationMulti-cloud; agentless preference

Disclosure: the site author works at Wiz. Everything above is a fair characterization rather than a marketing pitch; calibrate against your own evaluation.

AWS certifications track

AWS certifications won't get you a job by themselves, but they organize your study and demonstrate baseline literacy. The pragmatic security-engineer ladder:

Pair the exams with a home lab - labs in CloudGoat, flAWS, AWS Skill Builder, and a personal sandbox account where you can break things. The exam tests recognition; the job tests execution. See the certifications hub for the broader landscape including Azure, GCP, and vendor-neutral options.

AWS-native vs third-party tooling

The recurring question for every AWS security program: do you use the AWS-native service or buy a third-party tool? Some heuristics that hold up over time:

Capability Native usually wins Third-party usually wins
Single-cloud AWS, small teamSecurity Hub + GuardDuty + Inspector + Macie-
Multi-cloud-Wiz / Orca / Prisma / Lacework
Attack-path graph-CNAPP graph
Kubernetes / container depth-CNAPP or dedicated K8s tool
SIEM-Splunk / Sentinel / Elastic / Sumo / Panther
CSPM with broad framework mappingsSecurity Hub conformance packsCNAPP with deeper mappings
GRC platformAudit Manager (AWS-only programs)Vanta / Drata / OneTrust (multi-cloud GRC)
Secrets managementSecrets Manager (AWS workloads)Vault / Doppler / 1Password (hybrid)
WAFAWS WAF (AWS-only public surfaces)Cloudflare / Akamai (perf-critical, bot-heavy)
DDoSShield Standard (free, all surfaces)Shield Advanced or third-party for high-risk

The bias should be: start native, especially for detective controls in a single-cloud AWS environment, and earn the right to add a third-party tool when you've outgrown what native provides or you've gone multi-cloud. The cost of operating an over-stack of tools - license, integration, maintenance, operator fatigue - is real, and the security outcome of "we have everything but use none of it well" is consistently worse than "we have less but use it well."

Further reading

AWS official

Community resources

Related CSOH pages

FAQ

Is AWS more secure than Azure or GCP?

No cloud is categorically more secure than another at the platform level - all three meet the major frameworks (FedRAMP High, ISO 27001, PCI DSS, HIPAA) and run mature security programs. The differences are in defaults, service granularity, and ecosystem. AWS has the largest service surface (which is both more capability and more sharp edges), the most mature partner ecosystem, and IAM that is uniquely powerful and uniquely easy to misuse. Azure leads on enterprise identity (Entra ID). GCP leads on safe defaults and the simplicity of its resource hierarchy. Security outcomes are determined by the operator, not the provider - pick the cloud your team can run safely.

Do I need a CSPM if I already have Security Hub?

Security Hub is a credible CSPM for single-cloud AWS shops that have time to tune it. It aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and Config; runs CIS / PCI / NIST / AWS Foundational Security Best Practices conformance packs; and pushes to EventBridge for routing. Where a third-party CNAPP (Wiz, Orca, Prisma, Lacework, etc.) earns its license cost: multi-cloud coverage, agentless workload scanning, attack-path graph (which Security Hub does not produce), Kubernetes / container depth, identity-graph correlation across clouds, and a more polished operator UX. If you are single-cloud AWS and disciplined, Security Hub is fine. Multi-cloud or graph-driven prioritization, you want the third-party tool.

What's the difference between IAM and IAM Identity Center?

IAM is the per-account identity service that defines users, roles, and policies inside a single AWS account. IAM Identity Center (formerly AWS SSO) is the org-wide workforce-identity service that federates a human identity provider (Okta, Entra ID, Google Workspace, or its own directory) into AWS and lets that human assume IAM roles across many accounts via short-lived sessions. The right pattern in 2026: zero IAM users for humans, Identity Center for all human access, IAM roles for workload access (with IAM Roles Anywhere for non-AWS workloads), and IAM users only for the rare cases short-lived credentials can't satisfy.

Should new AWS accounts start from Control Tower or build the landing zone from scratch?

Start with Control Tower unless you have a specific reason not to. It deploys an opinionated multi-account baseline - Organizations with an OU structure, Identity Center, a log archive account, an audit account, CloudTrail org trail, Config aggregator, and a starter set of guardrails - in an afternoon. The escape hatches are real: you can layer your own custom SCPs, customize controls, and migrate off later via the Customizations for Control Tower (CfCT) framework. The accounts where teams skip Control Tower are usually heavily regulated environments with bespoke control sets that conflict with Control Tower's defaults; even then, the AWS Landing Zone Accelerator (LZA) gives you a CloudFormation/CDK baseline that's closer to a from-scratch build but still maintained.

Is the root account ever safe to use?

Almost never. The root user is required for ~10 tasks (closing the account, changing the support plan, restoring an IAM policy that locks everyone out, registering as a seller in the Reserved Instance Marketplace, and a few others - AWS publishes the list). For everything else, root should be locked away. The hardening pattern: hardware MFA on root, no access keys, password in a corporate secrets manager with a break-glass procedure, account email tied to a distribution list (never an individual), and CloudTrail + EventBridge alerting on any root login. If your team uses root weekly, your IAM model is broken.

How does the AWS shared responsibility model affect what I have to audit?

AWS owns security of the cloud - hardware, hypervisor, physical data center, the parts of managed services you can't see. You own security in the cloud - IAM, network configuration, OS / app patching where applicable, data encryption, the configuration of every service. Auditors will ask you for AWS's SOC 2 and ISO 27001 reports (downloadable from AWS Artifact) to cover the provider side, and they will ask you to produce evidence - CloudTrail logs, Config snapshots, IAM policy exports, Security Hub findings - for everything on your side of the line. The line moves by service: with EC2 you own a lot; with Lambda you own less; with S3 you own only the configuration and the data.

Which AWS certification path should a cloud security engineer take?

The pragmatic ladder: Cloud Practitioner (foundational vocabulary, can skip if you're already working in AWS), then Solutions Architect Associate (architecture intuition that the security exam assumes), then Security Specialty (the deep-end exam - IAM, KMS, detective controls, infrastructure security, IR). Optional layers: Solutions Architect Professional (multi-account, hybrid, enterprise patterns) for staff / principal roles, and Advanced Networking Specialty for engineers who own connectivity. Pair the certs with a home lab - because the exam tests recognition but the job tests execution.

Where next