Cloud Architecture Threat Modeling: AWS and Azure Workload Risk Assessment Using STRIDE and PASTA
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Traditional threat modeling asks: what can go wrong with this application? Cloud architecture threat modeling adds a layer that traditional models often miss: what can go wrong with the cloud services, IAM configuration, and multi-account structure that the application depends on? The attack surface includes not just the application code but the IAM roles the application uses, the S3 buckets it reads from, the instance metadata service that provides credentials, and the cross-account trust relationships that connect production to development.
Applying STRIDE to a cloud architecture data flow diagram takes a few hours for a medium-complexity workload. The output is a prioritized list of threats with associated controls that feeds directly into the security review before deployment — preventing the class of cloud misconfigurations that consistently appear in breach reports.
Building the data flow diagram for cloud workloads
The data flow diagram is the prerequisite for STRIDE analysis and must capture cloud-specific elements that traditional DFDs omit. Standard DFDs model application processes and network flows, but cloud architectures introduce additional attack surface in IAM role trust policies, instance metadata service access, and cross-account resource policies that are invisible on a network diagram. A cloud DFD must explicitly represent IAM roles and their trust relationships, the instance metadata service endpoint, and every AWS service-to-service call alongside the compute and storage components. Without these elements, the STRIDE analysis cannot surface the IAM privilege escalation and SSRF-to-credential-theft threat paths that are responsible for a large proportion of cloud security incidents.
Include IAM roles and trust relationships as first-class elements in cloud DFDs
A cloud architecture DFD must include IAM roles, their trust policies, and the resources they can access as explicitly labeled elements alongside the compute and storage components. Draw arrows from each IAM role to the AWS services it can call, and draw the trust policy boundary showing which principals can assume each role. Without these elements, the DFD cannot reveal IAM privilege escalation paths (where a low-privilege role can assume a high-privilege role through a misconfigured trust policy) or cross-account access paths that bypass the expected isolation. The STRIDE Elevation of Privilege category maps directly to this IAM layer.
Mark the instance metadata service as a trust boundary in EC2 workloads
The EC2 instance metadata service at 169.254.169.254 is a trust boundary that most DFDs omit because it is not visible in architecture diagrams. Include it explicitly: draw an arrow from the application running on EC2 to the IMDS endpoint and label it with the IAM role credentials it returns. The SSRF threat at this boundary (an attacker exploits an SSRF vulnerability in the application to call the IMDS and retrieve credentials) is one of the most commonly exploited cloud attack paths. The corresponding control (enforce IMDSv2 to require a PUT-based token request before credential retrieval) should appear in the threat enumeration for this boundary.
STRIDE application: cloud-specific threat enumeration
Applying STRIDE to cloud trust boundaries surfaces the threats most relevant to cloud architecture security, but the cloud context changes what each category means in practice. Elevation of Privilege in a cloud environment means IAM privilege escalation through misconfigured role trust policies, not just local OS permission elevation. Information Disclosure means S3 bucket public access or secrets in Lambda environment variables, not just network eavesdropping. Each STRIDE category maps to specific AWS and Azure attack patterns that require cloud-native controls. Working through each category systematically for every trust boundary in the DFD produces a list of cloud-specific threats that generic checklists miss.
Apply Elevation of Privilege to every IAM role trust policy in the diagram
For each IAM role in your DFD, apply the STRIDE Elevation of Privilege threat: can an unintended principal assume this role? Review the trust policy to confirm that the Principal element is scoped to specific, expected ARNs rather than aws:* or an entire account. Check whether the role has iam:PassRole or sts:AssumeRole permissions that could allow it to escalate to higher-privilege roles. For Lambda functions, confirm the execution role cannot be used by other services through overly broad trust policies. The IAM Access Analyzer can automatically flag trust policies that allow access from external accounts or overly broad principals, complementing the manual STRIDE analysis.
Apply Information Disclosure to every S3 bucket and data store in the diagram
For each S3 bucket, RDS instance, DynamoDB table, and other data store in the DFD, apply the STRIDE Information Disclosure threat: can the data be accessed by unintended principals? For S3 buckets, verify the bucket policy does not include s3:GetObject with Principal: * (public access), check that S3 Block Public Access is enabled at both the bucket and account level, and confirm that the bucket is not accessible through a bucket policy that allows access from an unintended AWS account. For RDS, verify the security group does not allow inbound connections from 0.0.0.0/0 and that the database is not publicly accessible (PubliclyAccessible: false in the RDS configuration).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Cloud architecture threat modeling using STRIDE takes a few hours per workload and produces a structured list of threats with associated controls that prevents the most common cloud misconfigurations. The key additions to traditional threat modeling for cloud environments are including IAM roles and trust policies in the data flow diagram, marking the instance metadata service as a trust boundary for EC2 workloads, and applying ATT&CK for Cloud as a completeness check after the STRIDE analysis to identify tactic coverage gaps. The output is a pre-deployment security review artifact that documents what threats were considered, what controls were selected, and what risks were accepted.
Frequently asked questions
What is cloud architecture threat modeling and why is it different from traditional threat modeling?
Cloud architecture threat modeling applies structured threat identification frameworks like STRIDE to cloud workloads by mapping trust boundaries specific to the shared responsibility model: the boundary between your AWS or Azure tenant and the cloud provider's infrastructure, between public-facing and internal cloud services, between IAM roles and the resources they can access, and between cloud services communicating within a VPC or virtual network. It differs from traditional threat modeling because the attack surface includes cloud-specific attack paths such as IMDS credential theft via SSRF, IAM privilege escalation through misconfigured role trust policies, storage bucket misconfiguration leading to data exposure, and cross-account access path abuse rather than just network-layer attacks.
How do I apply STRIDE to an AWS cloud architecture?
Applying STRIDE to AWS starts with a data flow diagram showing every AWS service involved in the workload, the data that flows between them, the IAM roles involved in each service-to-service call, and the trust boundaries. For each trust boundary crossing, enumerate the six STRIDE threats: Spoofing (could an attacker impersonate a service or IAM principal at this boundary?), Tampering (could an attacker modify data in transit or at rest?), Repudiation (could an actor deny their actions at this boundary without audit evidence?), Information Disclosure (could data be exposed at this boundary?), Denial of Service (could an attacker exhaust resources at this boundary?), and Elevation of Privilege (could an attacker gain higher permissions by crossing this boundary?). For each identified threat, select an AWS-native control or compensating control.
What are the most common cloud-specific threats I should model for AWS workloads?
Cloud-specific threats to include in every AWS threat model: SSRF attacks reaching the EC2 instance metadata service to steal IAM role credentials (mitigated by IMDSv2 enforcement), IAM privilege escalation via overly permissive role trust policies that allow unintended principals to assume high-privilege roles, S3 bucket misconfiguration exposing data publicly through bucket policies or ACLs, secrets stored in EC2 user data or Lambda environment variables that are readable through the console, cross-account access via misconfigured resource policies on S3 buckets or KMS keys, CloudTrail disablement by a compromised admin role to cover tracks, and Lambda function URL exposure without authentication creating an unauthenticated execution path.
How do I identify trust boundaries in a cloud architecture diagram?
Trust boundaries in a cloud architecture appear wherever the level of trust or the authentication mechanism changes. Key trust boundaries to identify in AWS: the internet-to-application boundary at your load balancer or API Gateway, the application-to-database boundary at the VPC security group level, the IAM boundary where a Lambda function or EC2 role makes API calls to AWS services, the boundary between AWS accounts in a multi-account organization, the boundary between a Kubernetes pod's service account and the AWS services it calls via IRSA, and the boundary between a public S3 endpoint and the data it stores. Draw each boundary as a dashed line on your data flow diagram and apply STRIDE analysis to each crossing.
What tools support cloud architecture threat modeling?
Microsoft Threat Modeling Tool supports creating data flow diagrams with built-in STRIDE threat generation and can be adapted for cloud architectures using custom stencils for AWS and Azure services. OWASP Threat Dragon is an open-source web application for creating DFDs with STRIDE threat enumeration that runs locally. draw.io (diagrams.net) supports AWS and Azure shape libraries for creating architecture diagrams that can serve as the DFD basis for a manual STRIDE analysis. For automated threat analysis, IriusRisk and SD Elements provide commercial threat modeling platforms that map STRIDE threats to cloud component types automatically. MITRE ATT&CK Navigator can be used to visualize which ATT&CK for Cloud techniques your controls address and which are gaps.
How do I prioritize which threats to mitigate after completing a STRIDE analysis?
After enumerating threats using STRIDE, prioritize using a simple likelihood-times-impact scoring for each threat. Assign likelihood on a 1-5 scale based on attacker motivation (is this workload a likely target?), exploitability (does the attack require physical access, credentials, or just an internet connection?), and existing controls (is there already partial mitigation?). Assign impact on a 1-5 scale based on data sensitivity, regulatory exposure, and business disruption potential. Score each threat and sort by total score. Focus remediation effort on the top quartile of scored threats where the combination of high likelihood and high impact justifies the control investment. Document residual accepted risks at the bottom of the list so future reviewers understand what was knowingly accepted.
How should I use MITRE ATT&CK for Cloud in threat modeling?
MITRE ATT&CK for Cloud provides technique-level descriptions of how attackers execute specific attacks against AWS, Azure, GCP, and container platforms organized by tactic. Use it after completing a STRIDE analysis as a completeness check: for each tactic in ATT&CK for Cloud (Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact), verify that your threat model includes at least one threat for each tactic relevant to your workload. Techniques not addressed by your STRIDE analysis or your existing controls represent coverage gaps. Also use ATT&CK technique IDs to reference specific known attack patterns when communicating threat model findings to stakeholders who are familiar with the ATT&CK framework.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.