AWS Cloud Adoption Framework: Security Perspective — Governance & Assurance, IAM, Threat Detection, Vulnerability Management, Infrastructure & Data Protection, AppSec, and Incident Response

Where this fits

The AWS Cloud Adoption Framework groups transformation guidance into six perspectives — Business, People, Governance, Platform, Security, and Operations — and the Security perspective is the one that helps you achieve the confidentiality, integrity, and availability of your data and cloud workloads. Its common stakeholders are the CISO, the Chief Compliance Officer, internal-audit leaders, and security architects and engineers, and it comprises nine foundational capabilities; this article goes deep on eight of them — security governance, security assurance, identity and access management, threat detection, vulnerability management, infrastructure protection, data protection, application security, and incident response. (AWS counts security governance and security assurance as two capabilities; this article treats them together under one heading because they are two halves of the same control-and-evidence loop.) Crucially, the Security perspective is not a gate the Platform team passes through once — it operates under the AWS Shared Responsibility Model (“security of the cloud” is AWS’s job; “security in the cloud” is yours) and runs continuously alongside the other five, taking the landing-zone foundations Platform builds and the guardrails Governance defines and turning them into a measurable, auditable, threat-driven program.

Security governance and assurance

What it is. Security governance is the capability of developing, maintaining, and effectively communicating security roles, responsibilities, accountabilities, policies, processes, and procedures. Security assurance is its evidentiary twin: continually monitoring, evaluating, managing, and improving the effectiveness of your security and privacy programs so you can demonstrate compliance to regulators, auditors, customers, and your own board. Governance writes the rules and assigns the owners; assurance proves the rules are working. Together they form the control-and-evidence loop that the other six capabilities plug into.

Why it matters. Without governance, the other capabilities have no authority and no consistency — every account team invents its own encryption standard and IAM model. Without assurance, you cannot answer the only question an auditor or a large customer actually asks: “prove it.” The classic enterprise failure is a brilliant technical security posture (GuardDuty on, KMS everywhere) that nobody can evidence — the SOC 2 audit stalls for three months because controls were never mapped to a framework and evidence was collected by screenshot. Governance and assurance are what make security traceable to a control objective and a named owner.

How to do it well. Anchor governance in a recognized control framework (NIST CSF, ISO 27001, CIS, PCI DSS, HIPAA) so every policy maps to a control objective, then automate the assurance loop so evidence is collected continuously rather than scrambled together at audit time. On AWS, the spine is AWS Organizations with Service Control Policies (SCPs) to set non-negotiable guardrails (deny disabling CloudTrail, deny leaving the org, deny unapproved regions), AWS Control Tower to apply mandatory, strongly-recommended, and elective controls (formerly “guardrails”) and produce a compliance dashboard, AWS Config with conformance packs to evaluate resource configuration against the framework continuously, AWS Audit Manager to map evidence to control frameworks automatically and assemble assessment reports, and AWS Security Hub to aggregate findings against CIS, PCI DSS, and the AWS Foundational Security Best Practices standard into a single security score you can trend.

Artifacts, decisions, and AWS tooling.

The artifacts are a control framework mapping (your policies tied to NIST/ISO/CIS objectives), an SCP and guardrail catalog (the preventive controls applied org-wide), a RACI assigning every control to an owner, and an assurance/evidence package (Audit Manager assessments plus AWS Artifact for AWS’s own SOC/ISO/PCI attestations). The decision that comes out of this capability is not a single Terraform module — it is the authoritative control baseline every other capability implements against.

Identity and access management

What it is. Identity and access management (IAM) is managing identities and permissions at scale — establishing who (human or machine) can access what, under which conditions, and ensuring access is the least privilege necessary. It spans your workforce identities, your customer/application identities, and the non-human identities (workloads, services, CI/CD pipelines) that vastly outnumber the humans.

Why it matters. In the cloud, identity is the perimeter — there is no network edge to hide behind, so a single over-permissioned credential or a long-lived access key in a Git repo is the breach. The most consequential decisions in the entire Security perspective are made here: federate or fork identities, use roles or keys, scope a policy to one bucket or to *. AWS’s own guidance is unambiguous — secure the root user with hardware MFA and stop using it, prefer temporary credentials over long-lived access keys, and require MFA everywhere — because most real-world AWS incidents trace back to a leaked static key or an unprotected root account, not an exotic exploit.

How to do it well. Centralize workforce identity in AWS IAM Identity Center (the successor to AWS SSO) federated to your existing IdP (Entra ID, Okta, Ping), and grant access through permission sets that resolve to short-lived role sessions — never IAM users with passwords scattered across accounts. For workloads, use IAM roles (EC2 instance profiles, IAM Roles Anywhere for on-prem, EKS Pod Identity / IRSA for Kubernetes) so nothing carries a static key. Enforce least privilege as a measurable practice, not an aspiration: generate policies from observed activity with IAM Access Analyzer (which also flags external/public access and validates policies), apply permission boundaries to delegate admin safely, and use service control policies as the org-wide ceiling. For customer-facing apps, use Amazon Cognito (or AWS Verified Permissions for fine-grained, policy-as-code authorization with Cedar). Rotate and vault any unavoidable secrets in AWS Secrets Manager.

Artifacts: an identity architecture (federation topology, account/permission-set matrix), a least-privilege policy library, a root-account protection runbook, a break-glass procedure (emergency access with alarms), and an Access Analyzer report of external and unused access reviewed on a cadence. The defining decision is federate-and-temporary by default — get that right and most of the rest of cloud security gets easier.

Threat detection

What it is. Threat detection is understanding and identifying potential security misconfigurations, threats, or unexpected behaviors so you can act before — or as — they cause harm. It is the always-on telemetry-and-analysis layer that turns raw logs into actionable findings.

Why it matters. Prevention is never perfect; detection is how you compress dwell time (how long an adversary operates undetected) from months to minutes. In the cloud the relevant signals are unusual API calls, anomalous network flows, credential exfiltration, and crypto-mining — none of which a traditional on-prem IDS sees. Detection is also the trigger for incident response: a finding nobody routes to a responder is just an expensive log line.

How to do it well. Build on a non-repudiable audit foundation first — AWS CloudTrail (management and data events) and VPC Flow Logs, delivered to a tamper-resistant, central log archive account — then layer managed analytics on top. Amazon GuardDuty is the cornerstone: it continuously analyzes CloudTrail, VPC Flow Logs, DNS logs, and (with its protection plans) S3, EKS audit logs, Lambda, RDS login activity, and EBS malware, using ML and threat intelligence to surface findings with no agents to manage. Aggregate every finding into AWS Security Hub (which also runs configuration-posture standards), correlate and triage in Amazon Detective (which builds behavior graphs to accelerate investigation), and add domain-specific detectors — Amazon Macie for sensitive-data exposure in S3, AWS WAF logs and AWS Network Firewall alerts for the edge. Route high-severity findings automatically (EventBridge → Lambda/Step Functions/Security Hub automation) so detection feeds response without a human in the latency path.

Artifacts: a logging and detection architecture (central log archive, delegated administrator for GuardDuty/Security Hub across the org), a detection coverage matrix (which threats are covered by which detector), finding severity-to-action routing rules, and an alert-fatigue control plan (suppression rules, finding aggregation). The key decision is org-wide, delegated-administrator detection turned on for every account by default — detection you have to remember to enable account-by-account is detection you do not have.

Vulnerability management

What it is. Vulnerability management is continually identifying, classifying, remediating, and mitigating security vulnerabilities — in your operating systems, application dependencies, container images, infrastructure-as-code, and configurations — before an attacker exploits them. It is the proactive, known-weakness discipline that complements threat detection’s active-attack focus.

Why it matters. The overwhelming majority of breaches exploit a known, patchable vulnerability or a misconfiguration that scanning would have flagged. The cloud changes the shape of the problem: ephemeral, auto-scaling fleets and container images mean you cannot rely on a quarterly agent scan — you need continuous, automatic assessment that follows resources as they appear and disappear, and you need to catch vulnerabilities left of deploy in the pipeline, not only in running production.

How to do it well. Run Amazon Inspector for continuous, automated vulnerability assessment of EC2 instances, container images in Amazon ECR, and Lambda functions — it auto-discovers resources, scans on change, and produces a risk-prioritized score (Inspector score) so you remediate by exploitability and exposure, not just raw CVSS. Shift left by scanning container images in CI (Inspector or ECR enhanced scanning, plus image provenance) and scanning infrastructure-as-code before it deploys. Pair finding with fixing: drive OS patching with AWS Systems Manager Patch Manager and Patch baselines, and treat the OS layer as immutable where possible — bake hardened, scanned golden AMIs with EC2 Image Builder so remediation is “redeploy a new image,” not “patch in place.” Aggregate Inspector findings into Security Hub and route them to ticketing with SLAs by severity.

Artifacts: a vulnerability management policy with remediation SLAs by severity (e.g., critical in 7 days, high in 30), a golden-AMI / base-image pipeline, a patch baseline and maintenance-window schedule, and a risk-acceptance register for the vulnerabilities you consciously defer with compensating controls. The decision worth calling out: continuous and automatic, not periodic — Inspector’s auto-discovery is the point, because a fleet that scales out at 2 a.m. must be assessed without anyone scheduling a scan.

Infrastructure protection

What it is. Infrastructure protection is validating that systems and services within your workload are protected against unintended and unauthorized access, and potential vulnerabilities — the hardening of your networks, compute hosts, and service boundaries. It is defense-in-depth applied to the substrate everything else runs on.

Why it matters. Identity is the new perimeter, but the network is still a control plane: micro-segmentation limits lateral movement and blast radius when (not if) a credential or host is compromised. Infrastructure protection is also where many of the most damaging mistakes happen — a security group open to 0.0.0.0/0 on port 22, a public subnet that should have been private, an unrestricted egress path that lets exfiltrated data leave. Getting the substrate right contains incidents that would otherwise be catastrophic.

How to do it well. Design the network for segmentation and controlled flow: structure accounts and VPCs with public/private subnet tiers, route egress through inspection, and connect at scale with AWS Transit Gateway. Put a stateful firewall in the data path with AWS Network Firewall (domain/IP allow-lists, IPS), filter recursive DNS with Route 53 Resolver DNS Firewall, and keep service-to-AWS traffic off the public internet entirely with VPC endpoints / AWS PrivateLink. At the edge, protect Layer 7 with AWS WAF (managed rule groups for OWASP Top 10, rate limiting, bot control) and absorb volumetric attacks with AWS Shield / Shield Advanced. Harden the hosts themselves: enforce IMDSv2, restrict access with AWS Systems Manager Session Manager (no bastion, no open SSH, full session logging), and minimize the OS via golden AMIs. Enforce all of this preventively with SCPs (deny opening 0.0.0.0/0, deny disabling Network Firewall logging) and detect drift with AWS Config and AWS Firewall Manager (org-wide WAF/SG policy enforcement).

Artifacts: a network segmentation and connectivity design (account/VPC topology, egress-inspection pattern), a firewall rule and WAF policy baseline enforced via Firewall Manager, a no-bastion access standard (Session Manager + IMDSv2), and a preventive-guardrail SCP set for network controls. The decision that pays off most is controlled, inspected egress and PrivateLink-by-default — it is the difference between a contained incident and a data-exfiltration headline.

Data protection

What it is. Data protection is maintaining visibility and control over data, and how it is accessed and used in your organization — classifying it, encrypting it at rest and in transit, controlling who can read it, and ensuring it can be recovered. Data is the asset every other capability ultimately exists to protect.

Why it matters. A breach is measured by the data it exposes, and most regulatory exposure (GDPR, PCI DSS, HIPAA, DPDP) is data-centric. The cloud makes encryption nearly free and ubiquitous, so the bar is high: unencrypted data at rest, a public S3 bucket, or a database reachable from the internet are no longer defensible. Data protection is also the last line of defense — when prevention and detection fail, immutable backups are what let you recover from ransomware instead of paying it.

How to do it well. Start with classification and discovery: know what sensitive data you hold and where, using Amazon Macie to discover and classify PII/PCI/PHI in S3 at scale. Encrypt everything with AWS Key Manager (KMS) — enforce encryption by default, prefer customer-managed keys (CMKs) with rotation and key policies for sensitive workloads, and use CloudHSM where you need single-tenant, FIPS 140-3 Level 3 custody. Enforce encryption in transit (TLS 1.2+, ACM-managed certificates, aws:SecureTransport deny policies). Lock down access at the data layer: S3 Block Public Access at the account level, bucket policies and VPC endpoint policies, and AWS Lake Formation for fine-grained (row/column/cell) governance of the data lake. For resilience, make backups immutable and recoverable: AWS Backup with Backup Vault Lock (WORM/immutable, anti-ransomware), S3 Object Lock for compliance retention, and cross-region/cross-account copies. Where you share data, AWS Clean Rooms lets parties collaborate without copying raw data, and AWS Nitro Enclaves isolate data even from your own operators in use.

Artifacts: a data classification scheme and inventory, an encryption standard and key-management policy (CMK strategy, rotation, key-policy ownership), a public-access prevention baseline, and a backup/immutability and recovery plan with tested restores. The decision that most reduces real risk is immutable, cross-account backups plus enforced default encryption and Block Public Access — three controls that, between them, defang ransomware, accidental exposure, and the most common audit findings.

Application security

What it is. Application security (AppSec) is detecting and addressing security vulnerabilities during the software development process — embedding security into the SDLC so flaws are caught in code, dependencies, and pipelines rather than in production. It is the “shift-left” capability that makes secure software the default output of your delivery process.

Why it matters. Software is the product, and the cheapest place to fix a vulnerability is in the developer’s editor; the most expensive is in an incident report. Modern apps are mostly third-party code (open-source dependencies, base images), so AppSec must cover the software supply chain, not just first-party code. Without it, every other control is downstream of an app that ships an injection flaw or a vulnerable library straight to production.

How to do it well. Build a secure pipeline with layered scanning: SAST (static analysis) and secrets scanning on every commit, SCA (software-composition analysis) for dependency CVEs, DAST against running pre-prod, and IaC scanning so misconfigurations never deploy. On AWS, use Amazon CodeGuru Security (and CodeGuru Reviewer) for code-level vulnerability detection, Amazon Inspector for container-image and Lambda dependency scanning in the pipeline, Amazon Q Developer for AI-assisted secure code review and remediation, and git-secrets / Secrets Manager to keep credentials out of source. Establish threat modeling for new services, define security gates in CodePipeline / CodeBuild (or your CI) that fail the build on critical findings, and sign and verify artifacts for supply-chain integrity (provenance, image signing). Treat the runtime protections (WAF, Shield, Cognito/Verified Permissions for authZ) as the AppSec contract with infrastructure protection and IAM.

Artifacts: a secure SDLC standard (the mandatory gates), threat models for significant services, a pipeline security-gate definition with break-the-build thresholds, and a dependency/SBOM and supply-chain policy. The defining decision is security gates that fail the build — advisory scanners that only warn are quietly ignored; a gate that blocks a critical finding is what actually changes behavior.

Incident response

What it is. Incident response (IR) is reducing potential harm by effectively responding to security incidents — the prepared, practiced capability to detect, contain, eradicate, recover from, and learn from a security event. It is where all the other capabilities are tested under fire.

Why it matters. Breaches are inevitable; the variable you control is how fast and how well you respond. The difference between a contained incident and a company-ending breach is almost always preparation: pre-staged access, automated containment, and a rehearsed playbook. AWS’s guidance is explicit that you must prepare before an incident — establish accounts, roles, tools, and runbooks in advance, because acquiring forensic access during an incident is how investigations stall and evidence is lost.

How to do it well. Prepare the foundations: a dedicated security tooling / forensics account, pre-created IAM roles for responders (with break-glass and full logging), and the data sources IR depends on (CloudTrail to an immutable archive, GuardDuty, Detective, Config history). Codify response as runbooks/playbooks and automate them: EventBridge routes a GuardDuty finding to Step Functions / Lambda / Systems Manager Automation that can isolate an instance (quarantine security group, snapshot the EBS volume for forensics, detach from the auto-scaling group), revoke a compromised role’s sessions, and quarantine a public S3 object — turning containment from minutes-of-typing into seconds-of-automation. Use Amazon Detective to scope blast radius, capture forensic artifacts (memory/disk snapshots into the forensics account), and recover from immutable backups. Then practice: run game days and tabletop exercises, and after every incident produce a blameless post-incident review (correction of error) that feeds fixes back into governance, detection, and prevention. AWS Incident Detection and Response and the Customer Incident Response Team (CIRT) are available for enterprise-support customers.

Artifacts: an incident response plan (roles, severities, comms/escalation, legal/regulatory notification timelines), a playbook library (compromised credentials, exposed S3, crypto-mining EC2, ransomware), a pre-provisioned forensics environment, and a game-day schedule with post-incident-review records. The decision that matters most is prepare and automate containment before you need it — the worst time to discover you have no forensic access role is during the breach.

Real-world enterprise scenario

Aspen Health Networks is a fictional US-based, HIPAA-regulated healthcare-technology company: ~3,400 employees, a patient-engagement SaaS platform serving 140 hospital customers, ~38 million patient records, and a hard contractual requirement to maintain HITRUST and SOC 2 Type II attestations. After a near-miss (a developer pushed an access key to a public GitHub repo; GuardDuty caught the resulting anomalous API calls within minutes, but the incident exposed gaps), the CISO, Priya Nair, sponsors a CAF Security-perspective uplift across the company’s 62-account AWS Organization managed by Control Tower. Here is how each capability is implemented.

• Security governance & assurance. Aspen maps every policy to NIST CSF and HITRUST CSF control objectives, applies a catalog of SCPs (deny disabling CloudTrail/GuardDuty, deny non-us-east-1/us-west-2 regions, deny public S3) and Control Tower controls org-wide, evaluates configuration continuously with AWS Config conformance packs, and stands up AWS Audit Manager with the HIPAA and SOC 2 frameworks so evidence is collected automatically. Security Hub gives the board a single security score, trended monthly. Artifact: a control-framework mapping, SCP/guardrail catalog, RACI, and a continuous evidence package.
• Identity and access management. Workforce identity moves to IAM Identity Center federated to Okta with mandatory MFA; the 62 accounts are accessed only via permission sets resolving to short-lived sessions. The root user in every account gets hardware MFA, is locked away, and triggers a CloudWatch alarm on any use. All workloads use IAM roles (IRSA on EKS, instance profiles on EC2) — a project to eliminate the last 240 long-lived access keys runs to zero. IAM Access Analyzer generates least-privilege policies and reports external access weekly. Artifact: an identity architecture, least-privilege policy library, break-glass procedure, root-protection runbook.
• Threat detection. GuardDuty is enabled org-wide via a delegated administrator with the S3, EKS, RDS-login, and EBS-malware protection plans on; CloudTrail and VPC Flow Logs land in an immutable log-archive account. Findings aggregate into Security Hub and are investigated in Amazon Detective; Amazon Macie watches the 140-customer S3 estate for exposed PHI. Artifact: a detection coverage matrix and finding-to-action routing rules.
• Vulnerability management. Amazon Inspector continuously scans EC2, the ECR image registry, and Lambda; critical findings carry a 7-day SLA, high a 30-day SLA, into Jira. EC2 Image Builder bakes hardened, CIS-benchmarked golden AMIs, and Systems Manager Patch Manager handles the remainder on weekly maintenance windows. Artifact: a vulnerability-management policy with SLAs, a golden-AMI pipeline, a risk-acceptance register.
• Infrastructure protection. Production VPCs use private subnets with egress routed through AWS Network Firewall (domain allow-list) and Route 53 DNS Firewall; service traffic uses PrivateLink endpoints. The patient portal sits behind AWS WAF (OWASP managed rules + rate limiting) and Shield Advanced, with Firewall Manager enforcing the WAF policy across accounts. Hosts run IMDSv2 and are reachable only via Session Manager — no bastions, no open SSH. Artifact: a segmentation/connectivity design, firewall/WAF baseline, no-bastion standard.
• Data protection. All 38M records are encrypted at rest with KMS customer-managed keys (annual rotation, strict key policies), TLS 1.2+ is enforced via aws:SecureTransport deny policies, and S3 Block Public Access is locked at the account level org-wide. Backups use AWS Backup with Vault Lock (immutable) replicated cross-account, and S3 Object Lock enforces PHI retention. Artifact: a data-classification scheme, encryption/key policy, backup-immutability and tested-recovery plan.
• Application security. Every commit runs CodeGuru Security (SAST) and secrets scanning; Inspector scans images in the build; CodePipeline gates fail the build on any critical finding; artifacts are signed. Amazon Q Developer assists secure remediation, and threat models are required for new microservices. Artifact: a secure-SDLC standard, threat models, pipeline gate definitions, SBOM policy.
• Incident response. A dedicated forensics account holds pre-created responder roles; an EventBridge → Step Functions workflow auto-isolates a compromised EC2 instance (quarantine SG, EBS snapshot, ASG detach) and revokes role sessions within seconds. Quarterly game days rehearse the compromised-key and exposed-PHI playbooks, each closed with a blameless correction-of-error. Artifact: an IR plan, playbook library, pre-provisioned forensics environment, game-day records.

Measurable outcome (12 months in): Security Hub score up from 71% to 94%; long-lived access keys reduced from 240 to 0; mean time to contain a simulated compromised instance down from ~45 minutes (manual) to under 90 seconds (automated); the HITRUST and SOC 2 Type II audits completed with evidence assembled from Audit Manager in days instead of the prior three-month scramble; and zero PHI-exposure incidents — every control traceable to a NIST/HITRUST objective and a named owner.

Deliverables & checklist

• Control-framework mapping — policies tied to NIST CSF / ISO 27001 / CIS / HIPAA-PCI control objectives.
• SCP and Control Tower guardrail catalog — the preventive controls applied org-wide, with a RACI.
• Continuous compliance + assurance package — AWS Config conformance packs, Security Hub standards, AWS Audit Manager assessments, AWS Artifact attestations.
• Identity architecture — IAM Identity Center federation, permission-set matrix, root-account protection runbook, break-glass procedure, Access Analyzer review cadence.
• Detection architecture — org-wide GuardDuty (delegated admin) with protection plans, central immutable log archive, finding-to-action routing, Detective for triage.
• Vulnerability-management policy — Amazon Inspector coverage, remediation SLAs by severity, golden-AMI/Image Builder pipeline, patch baselines, risk-acceptance register.
• Infrastructure-protection baseline — VPC segmentation and inspected egress, Network/DNS Firewall, PrivateLink, WAF + Shield via Firewall Manager, Session Manager + IMDSv2 host hardening.
• Data-protection standard — classification scheme (Macie), KMS/CMK encryption policy, TLS enforcement, S3 Block Public Access, immutable cross-account backups (Backup Vault Lock / Object Lock) with tested restores.
• Secure-SDLC standard — SAST/SCA/secrets/IaC scanning, fail-the-build pipeline gates, threat models, SBOM/supply-chain integrity.
• Incident response plan — forensics account, pre-provisioned responder roles, automated containment playbooks, game-day schedule and post-incident-review process.

Common pitfalls

• Posture without evidence. Strong tooling that no one mapped to a control framework leaves you unable to pass an audit. Avoid it by mapping every control to NIST/ISO/CIS up front and running AWS Audit Manager so evidence is continuous, not a screenshot scramble.
• Long-lived access keys and an unprotected root user. Most real AWS breaches start with a leaked static key or an exposed root account. Avoid it by federating workforce identity through IAM Identity Center, using roles (never keys) for workloads, and locking the root user behind hardware MFA with alarms.
• Per-account, opt-in security. Detection and guardrails enabled account-by-account inevitably leave gaps as the org grows. Avoid it by using delegated administrators (GuardDuty, Security Hub, Inspector) and SCPs to make security org-wide and on-by-default.
• Treating cloud security like a firewall problem. Relying on the network edge while ignoring identity, data, and the SDLC leaves the real attack surface open. Avoid it by treating identity as the perimeter and applying defense-in-depth across all eight capabilities, not just infrastructure protection.
• Advisory-only scanners. Vulnerability and AppSec scanners that merely warn are quietly ignored, and findings rot. Avoid it with remediation SLAs by severity and pipeline gates that fail the build on critical findings.
• Improvising incident response. Acquiring forensic access and writing playbooks during an incident loses evidence and time. Avoid it by pre-provisioning a forensics account and responder roles, automating containment with EventBridge/Step Functions, and rehearsing with game days before you need them.

What’s next

Part 7 of the AWS Cloud Adoption Framework series moves to the Operations perspective — observability, event and incident management, change and release, and the availability and continuity practices that keep the workloads this phase secured running at the level the business agreed.