Rethinking defense entirely

We know attackers are already using AI to operate at machine speed, running more frequent and more effective attacks. They're automating reconnaissance, standing up infrastructure, and pivoting faster than human analysts can triage an alert. We have seen the cyber kill chain that used to unfold step by step now happens in the blink of an eye, and defenders are struggling to keep up in a fight that no longer gives them time to react.

It's clear that organizations need to reduce risk, defend pre-attack, and act at machine speed. But beyond just moving faster, they may need to rethink defense entirely. Imagine not scrambling to keep pace with the threat landscape, but moving with it: changing as it changes and acting as fast as the attacker acts. That's a world where an autonomous defense system works alongside defenders, applying intelligence at the speed and scale today's threats demand.

Today at Mastercard RiskX in Arizona, we premiered an autonomous defense platform built into Recorded Future. The age of AI action has arrived, and we're excited to show you what's next. Read on to see how this capability came to be, why it's a fundamentally different way to defend, and how you can be a part of it.

From answers to actions

AI for threat intelligence has come a long way. In a short time, analysts and security leaders have gone from searching for answers to finding them fast, thanks to capabilities like AI Insights and Sessions in Recorded Future AI. At the core of it all is the Intelligence Graph®, which turns large sums of data and information into actionable insights, and gives Recorded Future AI the context to deliver the right answer to analysts in seconds.

That success created a new demand: Analysts and business leaders wanted this same intelligence, at the same speed, everywhere they worked — not just inside the Recorded Future Platform. That's why we built Recorded Future Model Context Protocol (MCP). Agents, whether ours or our customers', run across many tools and platforms. This gives them direct, standardized, and cost-efficient access to Recorded Future intelligence.

The Intelligence Graph®, Recorded Future AI's Insights and Sessions, and Recorded Future MCP have laid the foundation for what comes next: defending at the pace adversaries set. To keep up with adversaries, analysts need to act at their speed, confidently taking 10 actions where they once had time for one. They need to spend their time focused on business outcomes, not buried in process. Ultimately, they need a fundamentally different way to use intelligence and act. That's why we're building autonomous defense.

What autonomous defense can do

This is a different way to think about the day-to-day analyst workflow. Analysts can task Recorded Future’s autonomous defense with a goal, not just a question, and it will go from there: drawing on the Intelligence Graph®, deciding what the situation calls for, and delivering outputs directly into your team's existing tools across over 100 integrations. It can act on your behalf, clearing away work so your team can focus on the outcome, not the process.

Autonomous defense runs on the Intelligence Graph® with over 15 years of threat intelligence and analyst research, combined with your own organizational context through your Private Graph, so the system knows what's relevant before anything happens. It's the same intelligence layer customers already use across cyber operations, third-party risk, digital risk protection, and counter-fraud, now can be put to work taking agentic action. When your threat priorities shift or a new vulnerability surfaces, agents already understand why it matters to your environment and start acting in real time.

What this looks like from start to finish: A trigger like a new high-priority threat actor, a malicious website notification, or a critical third-party vulnerability starts the workflow. The Platform reasons through what matters, pulling intelligence and building a hunting package, checking a site's ownership to assess takedown eligibility, or drafting outreach and confirming approvals. Then it can act, including running the hunt and blocking the threat, initiating and monitoring a takedown, or notifying your third party and tracking remediation.

Agents default to fully autonomous execution, because defending at machine speed requires it, but teams that want human review first can dial back to managed autonomy. The result is a system, not just a model, that connects detection, investigation, and response into a single workflow. But a capability like this only matters if you can trust it, which is where Recorded Future’s autonomous defense sets itself apart.

A fundamentally different approach

AI security tools have exploded, but much of the industry feels oversold. Dashboards relabeled. SOAR engines rebranded, chatbots dressed up in analyst clothing. Security teams have grown skeptical of the pattern, and rightly so.

What makes Recorded Future's autonomous defense different?

1. Reasoning models and agent frameworks are becoming commodities. Nearly any vendor can wire up an agent loop. What's scarce is trustworthy, structured intelligence for those agents to reason over. That's what we've spent over 15 years building, and it's the foundation every Recorded Future agent runs on. Frontier models generally lack this training on relevant data.
2. It's grounded in the deepest threat intelligence available. Claims about a threat actor's infrastructure, a vulnerability's exploitation status, or a campaign's targeting come from the Intelligence Graph®: continuous analysis across open, dark, and technical web sources, enriched by Insikt Group's analysts. Not plausible-sounding guesses from general training data. Real intelligence, sourced, traceable, and trustworthy.
3. It's architecturally agentic, not superficially so. Most agents have to poll the world to notice that something has changed. Recorded Future agents subscribe to changes in the Intelligence Graph® and get real-time triggers the moment something relevant moves, so they act on signals instead of burning cycles searching for them. This isn't a chat interface bolted onto a search box. It's purpose-built for how security work actually happens.
4. Every output is auditable. Security teams can't operate on black-box AI. Trust requires transparency. Recorded Future shows its work, so every source, step, and conclusion can be traced. When it flags a threat as high priority, you can see exactly why.
5. Intelligence that ends in a chat window has limited value. Recorded Future delivers outputs into SIEM platforms, ticketing systems, communication tools, and the rest of your security stack where the work actually happens.

This is the beginning

We believe that what we're announcing today is a real leap in what security teams can accomplish: workflows that can eliminate critical threats, hours returned to the analyst, and coverage that wasn't previously achievable. And we're not stopping here.

We're already building expanded multi-agent architectures, where AI agents collaborate on complex, long-running investigations. We're building toward AI that monitors threat groups and updates intelligence continuously over weeks, not sessions. And we're extending the integration layer so Recorded Future AI doesn't just deliver intelligence into your stack, it participates in it.

This is a new era of defense, and we know that many of our customers are as excited about it as we are. If you're a Recorded Future customer and want to be part of what's next, apply for early access here. Autonomous defense is planned for general availability early next year.

On Saturday, October 24, 2026, we will conduct an exercise demonstrating that the AWS European Sovereign Cloud can operate without depending on any infrastructure outside of the European Union (EU).

For several hours, the AWS European Sovereign Cloud will operate without a connection to the AWS Global Network backbone. The backbone is the private network that moves authorized AWS operational data between AWS locations without using the public internet. During the exercise, this traffic will securely reroute over the public internet.

The exercise will not affect service availability within the AWS European Sovereign Cloud, other AWS Regions, or private connectivity through AWS Direct Connect. Customers may experience brief connectivity disruptions as traffic moves onto a separate network route at the beginning or the end of the exercise, after which normal connectivity resumes.

The operational team, composed entirely of EU residents within the EU, will execute the exercise using only the hardware and software resources of the AWS European Sovereign Cloud. The AWS European Sovereign Cloud Managing Directors called for this exercise to showcase its operational independence.

The AWS European Sovereign Cloud is a new, independent cloud for Europe. Located in Brandenburg, Germany, its data centers are physically and logically separate from other AWS Regions, with a local in-EU copy of the source code. All customer content and customer-created metadata stay in the EU. It has no critical dependencies on non-EU infrastructure and is operated exclusively by EU residents.

In standard operations, the AWS European Sovereign Cloud uses two global systems. The first is the AWS Global Network backbone. The second is a dedicated system that the local EU team controls and supervises to securely manage limited, controlled transfers of operational AWS data.

Neither is operation-critical, and neither affects the sovereignty assurance of the AWS European Sovereign Cloud. The AWS European Sovereign Cloud can operate independently at any time without a connection to these global systems, and on October 24 that’s what the team will demonstrate.

This exercise will produce verifiable technical and operational evidence that the AWS European Sovereign Cloud can operate independently within the EU. The exercise is designed to be consistent with the objectives of the European Commission’s EU Cloud Sovereignty Framework (CSF) and the criteria of the C3A framework from Germany’s Federal Office for Information Security (BSI). These frameworks set out objectives and criteria for assessing whether cloud services can be provided independently and autonomously.

We designed the AWS European Sovereign Cloud for regulated customers and the public sector across the EU. The AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF) gives our customers and partners a comprehensive set of evidence points, maps to controls, artifacts, and other elements regulators and compliance authorities need to accelerate their adoption of the AWS European Sovereign Cloud. The results of this exercise will provide additional evidence for their compliance and assurance packages.

The AWS European Sovereign Cloud runs connected to the AWS Global Network backbone because it delivers superior performance, capacity, reliability, security, and cost savings to customers. That includes always-on encryption and distributed denial of service (DDoS) defenses; and the backbone can’t decrypt or see the encrypted data that AWS European Sovereign Cloud customers send and receive. While the backbone delivers these benefits day-to-day, the AWS European Sovereign Cloud can continue to operate independently, with the appropriate security controls in place.

During the exercise, instead of using the AWS Global Network backbone, the AWS European Sovereign Cloud will exclusively use its dedicated internet connectivity from European internet service providers. This will provide connectivity to the worldwide internet.

Whenever traffic moves between internet links, there’s a small window of limited disruption called convergence, a short time when other non-AWS networks change their routing information to reflect the change. This could happen at the beginning of the exercise, when traffic moves to dedicated AWS European Sovereign Cloud internet providers, and at the end of the exercise, when traffic moves back to the AWS Global Network backbone.

AWS has committed to not moving AWS European Sovereign Cloud customer content and customer-created metadata outside of the EU. Only certain data, which is neither customer content nor customer-created metadata, such as AWS operational data, leaves the EU. We use a dedicated system to securely manage these limited, controlled transfers under the control and supervision of the local EU team. We’re rigorous about what the system transfers. It accepts vetted source code mirroring and software updates, and transfers out very limited and approved routine information. During the exercise, the AWS European Sovereign Cloud team will disable the system entirely, confirming that the AWS European Sovereign Cloud continues to operate independently without it.

AWS will share an update after the exercise with regulators and customers. To learn more about the AWS European Sovereign Cloud’s design and digital sovereignty controls, visit aws.eu. If you have questions about this exercise or would like to discuss how it may impact your workloads, reach out to AWS Support or contact your AWS Account team.

Ransomware does not start when files are encrypted. By then, an attacker may already have obtained valid credentials, entered the network, moved between systems and established a command-and-control (C2) channel.

That gives defenders an earlier window to act. Ransomware threat intelligence helps security teams identify the actors, infrastructure and access methods connected to ransomware activity before an attack reaches its final stage. Instead of waiting for an endpoint alert or ransom note, teams can look for exposed credentials, malicious infrastructure and known attacker behavior, then act on the threats most relevant to their organization.

The need for that earlier view is growing. Modern ransomware operations may use Ransomware-as-a-Service (RaaS) models and double- or triple-extortion tactics, giving defenders more reason to identify warning signs before encryption.

Key takeaways

• Ransomware threat intelligence can expose signs of an attack before encryption, including compromised access and attacker infrastructure.
• IOCs remain useful, but TTPs provide longer-lasting context because attacker behavior changes less quickly than individual IP addresses or file hashes.
• Early disruption can focus on closing initial access paths or cutting communication between compromised systems and known C2 infrastructure.
• Recorded Future assists in connecting ransomware intelligence with organizational exposure, threat actor context and existing security workflows so teams can better prioritize action.

Why reactive ransomware defense is not enough

Reactive controls remain important, but they often cannot provide the external context security teams need to identify which ransomware threats are most likely to reach their environment.

Endpoint detection and response (EDR), network monitoring, and backups all have a role in ransomware defense. The problem is timing. If a team only acts after malicious behavior appears inside its environment, the attacker may already have gained access or started moving toward systems that matter.

This is where modern ransomware detection benefits from external intelligence. Security teams can compare what they see internally with information about active ransomware groups, infrastructure and exploitation activity outside their network.

IOCs show what happened. TTPs help anticipate what comes next.

Indicators of compromise (IOCs), such as malicious IP addresses, domains, and file hashes, can help security controls identify known threats. They also typically have a short shelf life when attackers rotate infrastructure or alter malware.

Tactics, techniques, and procedures (TTPs) describe how an adversary operates. MITRE ATT&CK organizes those behaviors across stages such as initial access, lateral movement and command and control.

A ransomware actor can quickly replace an IP address. Changing a working attack method takes more effort. Tracking both IOCs and TTPs gives defenders a stronger basis for deciding what to block now and what behavior to watch for next.

The goal is not to replace IOC-based detection. It is to add enough context to understand who may be behind an indicator, how it fits into an attack, and what the adversary is likely to attempt next.

How does Threat Intelligence help prevent ransomware attacks?

The best time to disrupt ransomware is before the attacker reaches the impact stage. Threat intelligence creates opportunities to act during initial access and C2 activity rather than relying on recovery after encryption.

External intelligence can reveal parts of the ransomware operation that are difficult to see from internal telemetry alone. That includes activity in criminal marketplaces as well as infrastructure connected to known threat actors.

Phase 1: Track the adversary outside your network

Initial access is often a business in its own right. Initial access brokers (IABs) obtain access to compromised organizations and advertise it to other criminals. Threat intelligence can surface compromised credentials and exposed Remote Desktop Protocol (RDP) access associated with an organization. It can also monitor IAB listings, actor chatter, and target discussions for warning signs before that access is used.

Monitoring those sources can give security teams a warning that credentials or access associated with their organization are exposed. A credential discovered for sale does not prove that a ransomware attack will follow, but it creates a specific risk that defenders can investigate before someone uses that access.

Threat intelligence can also connect ransomware groups with domains, IP addresses, and other infrastructure associated with their operations. Malware analysis and controlled sandbox testing can add newly observed indicators and behavioral information.

C2 intelligence is especially useful because command-and-control gives attackers a way to communicate with systems they have compromised. If defenders know the infrastructure associated with an active threat actor, they can look for related connections within their own network rather than waiting for the ransomware payload to execute.

Phase 2: Act at the point of disruption

Tracking only matters if the intelligence changes what the security team does.

At initial access, one priority is removing the opportunity before an attacker can use it. If exposed corporate credentials appear in criminal sources, the organization can investigate the affected account, reset credentials where needed, and review authentication activity for signs of misuse.

The same principle applies to vulnerabilities. A large vulnerability backlog does not indicate which flaw an attacker is likely to exploit first. Vulnerability intelligence adds evidence of exploitation activity, enabling teams to respond faster to weaknesses associated with active threats rather than relying on severity scores alone.

C2 creates another intervention point. High-confidence indicators associated with malicious infrastructure can be supplied to security controls so connections are blocked or detected earlier. If an endpoint begins communicating with known C2 infrastructure, the security team can investigate and isolate the affected system before the attacker progresses further.

Disruption does not always require taking criminal infrastructure offline. For an individual organization, breaking the attacker's access to its environment can be enough to stop that attack path.

These controls should sit alongside broader guidance on how to prevent ransomware, including identity protection, patching, and recovery planning. Threat intelligence makes those efforts more targeted by showing teams where an active threat is most likely to intersect with their environment.

Recorded Future turns ransomware intelligence into action

Recorded Future helps security teams connect external ransomware activity with their own exposure so they can spend less time sorting through threat data and more time acting on relevant risks.

Recorded Future’s ransomware mitigation capabilities bring together threat research, dark web intelligence and information about an organization's attack surface. Threat actor, industry and TTP context helps teams narrow their attention to ransomware threats that warrant attention.

Reduce research time with the Intelligence Graph^Ⓡ

A large feed of indicators can contribute to alert fatigue if analysts must investigate each item manually. Recorded Future's Intelligence Graph^Ⓡ connects information about threat actors with associated malware, infrastructure, and vulnerabilities.

That context helps analysts move from an isolated indicator to the relationships around it. Rather than treating every IOC as equally important, teams can assess how an indicator relates to an active threat and whether that threat is relevant to their organization.

Recorded Future uses AI to collect, process, and correlate threat data within the Intelligence Graph. This helps reduce repetitive research and enables teams to prioritize relevant findings.

Focus on the ransomware actors most relevant to your organization

Not every ransomware group has the same targets. Industry, geography and previous victim patterns can help analysts understand where a threat actor tends to focus.

Recorded Future's Ransomware Risk Profile provides a view of an organization's ransomware exposure. Victimology insights help teams understand which ransomware groups and TTPs are most relevant based on targeting patterns such as industry and geography.

This allows SOC and threat intelligence teams to tune detection and hunting around ransomware groups whose past activity makes them more relevant to the business rather than treating the entire ransomware landscape as equally urgent.

Put intelligence into existing security workflows

Threat intelligence loses value when an analyst has to move findings manually from one tool to another.

Recorded Future can deliver intelligence through APIs and integrations with security information and event management (SIEM), security orchestration, automation, and response (SOAR), and endpoint detection and response (EDR) tools. Depending on the configured workflow, intelligence can add context to alerts and support automated blocking of malicious infrastructure.

Build an intelligence-driven ransomware defense

Ransomware threat intelligence changes the point at which defenders can respond. Instead of treating encryption as the first clear sign of an attack, teams can look for the access, infrastructure and behavior that come earlier.

This does not replace EDR, access controls or backups. It gives those defenses external context. A vulnerability becomes more urgent when a ransomware actor is actively exploiting it. An exposed credential becomes an immediate investigation point when criminals are offering access to the organization. A C2 indicator becomes more useful when analysts can connect it to the actor and TTPs behind it.

That earlier context can reduce both the likelihood of a successful attack and the damage an attacker can cause. Given how ransomware affects businesses, moving the disruption point earlier in the attack lifecycle can protect far more than encrypted files.

Ready to stop ransomware before a breach occurs? Explore our product tours to get a feel for how Recorded Future automates the tracking and disruption of the most relevant threat actors targeting your industry.

Ransomware Threat Intelligence FAQs

What is the primary difference between a reactive and a threat intelligence-led disruption strategy for ransomware?

A reactive strategy focuses on detecting and recovering from ransomware after malicious activity reaches the environment. A threat intelligence-led strategy looks for earlier warning signs, such as exposed access, known threat actor behavior and malicious infrastructure, so teams can intervene before encryption occurs.

Is paying a ransom ever considered an effective disruption strategy?

Paying a ransom occurs after an organization has already been compromised, so it is generally not a preemptive disruption strategy. Threat intelligence-led disruption focuses on stopping the attacker earlier in the ransomware lifecycle.

Which stages of the ransomware attack lifecycle offer the best opportunities for external disruption via threat intelligence?

Reconnaissance and command and control (C2) provide valuable opportunities for disruption. Threat intelligence can identify exposed credentials, access being advertised by initial access brokers and infrastructure associated with known ransomware actors before those resources are used against the organization.

How does Recorded Future use AI to accelerate ransomware disruption?

Recorded Future uses AI to collect, process and correlate threat data within the Intelligence Graph. This helps analysts connect indicators with threat actors, infrastructure and TTPs, reducing manual research and helping teams identify ransomware threats that require attention faster.

Can Recorded Future help our organization identify and mitigate our most critical ransomware exposure points?

Recorded Future combines vulnerability and attack surface intelligence with external threat context to help teams identify exposures associated with active ransomware threats. This can help security teams prioritize remediation based on evidence of exploitation and organizational risk rather than severity scores alone.

What is victimology in the context of ransomware intelligence, and how is it used to protect an organization?

Victimology examines the types of organizations ransomware groups have targeted, including patterns related to industry and geography. Security teams can use those patterns alongside threat actor TTPs to identify ransomware groups that may be more relevant to their organization and adjust detection and hunting accordingly.

How is the rise of Ransomware-as-a-Service impacting the way organizations use threat intelligence for tracking?

Ransomware-as-a-Service can separate ransomware operators from the affiliates carrying out attacks. Threat intelligence teams therefore need to track more than a single malware family, including affiliate behavior, initial access activity and criminal-market sources that may reveal how attacks are being prepared.

Read all about the latest AWS security features, compliance updates, and hands-on resources in our monthly digest posts. You’ll find expert blog posts, new service capabilities, code samples, and workshops.

August brought 20 AWS Security Blog posts organized across seven categories. Identity and access management led the month with five posts covering self-service rate limits for Amazon Cognito, a decade of AWS Managed Microsoft AD, a redesigned sign-in experience, console Private Access for isolated VPCs, and automated IAM Identity Center governance. Data protection followed with four posts on AWS KMS data key caching, ACME protocol support in AWS Certificate Manager, Amazon S3 over-permissioned access remediation, and the upcoming deprecation of email-based domain validation. AI security continued to grow with four posts on custom authentication in Amazon Bedrock AgentCore Gateway, user authorization propagation in AI agents, and extending Bedrock Guardrails to tool interactions. Threat detection, governance and networking.

From 2 weeks to 2 minutes: Amazon Cognito launches provisioned limits for self-service rate limit management
Authors: Kiran Dongara, Howie Li | Published: August 5, 2026
Learn to use Amazon Cognito provisioned limits for on-demand authentication rate limit adjustments, replacing the previous 10–14 day support ticket process with self-service capacity scaling in minutes.

A decade of enterprise identity in the cloud with AWS Managed Microsoft AD
Authors: Vladimir Provorov, Tekena Orugbani, Rodney Underkoffler | Published: August 7, 2026
AWS Managed Microsoft AD celebrates 10 years of fully managed Active Directory in the cloud, now offering Standard, Enterprise, and Hybrid editions with multi-Region replication and 20+ AWS service integrations.

Updates to your AWS sign-in experience
Authors: Vaibhav Chowla, Ella Segura | Published: August 17, 2026
AWS is gradually rolling out a redesigned sign-in page with a unified email entry point, social identity provider options, and an updated session selection experience for managing multiple active sessions.

Extend your data perimeter to the AWS Management Console with Private Access
Authors: Madhur Kulkarni, Abhijit Barde, Sujay Ghosh, Mateusz Jaworski | Published: August 28, 2026
AWS Management Console Private Access now supports VPCs without internet connectivity, routing all console traffic – authentication, static assets, and service API calls – through AWS PrivateLink endpoints to strengthen your data perimeter.

Automate IAM Identity Center governance with continuous discovery and reporting
Author: Jonathan Nguyen | Published: August 31, 2026
Learn to deploy automated discovery and reporting for AWS IAM Identity Center applications and assignments across your organization, with event-driven monitoring that validates naming conventions and enables near real-time enforcement of governance policies.

Caching KMS data keys in multi-thread environments: per-tenant encryption for event-driven systems at scale
Authors: Maria Gutovsky, Hemmy Yona | Published: August 6, 2026
Learn to solve the cache stampede problem in multi-tenant envelope encryption using the AWS-recommended hierarchical keyring pattern or a custom Caffeine-based caching approach to reduce AWS KMS costs.

Automate certificates with ACME support in AWS Certificate Manager
Authors: Anthony Harvey, Chandan Kundapur | Published: August 6, 2026
Learn to use ACME protocol support in AWS Certificate Manager to automate public certificate issuance and renewal using standard clients like Certbot and cert-manager, with enterprise controls for domain scoping and centralized visibility.

Securing your Amazon S3 buckets: identifying and remediating over-permissioned access
Authors: Hetal Kolekar, Fernando Chiera di Vasco Freitas, Manonmayi Vedam | Published: August 7, 2026
Learn to detect and fix over-permissioned Amazon S3 buckets across multi-account environments using AWS Lambda, AWS Config, and AWS Security Hub, with automation for continuous monitoring.

AWS Certificate Manager will discontinue email validation to prove domain validation for certificates
Authors: Adam Aboudi, Poojil Tripathi | Published: August 13, 2026
ACM will discontinue email-validated public certificates by September 30, 2027, aligning with CA/B Forum standards – learn the timeline and how to migrate to DNS validation in place.

Implement custom authentication for tools integration using request Lambda interceptor in AgentCore Gateway
Authors: Nishant Mainro, Ram Ramani | Published: August 18, 2026
Learn to use a request Lambda interceptor in Amazon Bedrock AgentCore Gateway to bridge legacy authentication mechanisms like Basic Auth, isolating credentials from AI agents using AWS Secrets Manager.

Propagate user authorization context in AI agents with Amazon Bedrock AgentCore
Authors: Anshu Bathla, Prafful Gupta, Rohit Verma | Published: August 19, 2026
Learn to enforce least-privilege access in AI agents by propagating user identity through Amazon Bedrock AgentCore to Amazon DynamoDB, Knowledge Bases, and Salesforce, without embedding authorization logic in agent code.

Extend Amazon Bedrock Guardrails to tool interactions using the Strands Agents SDK
Authors: Stephan Traub | Published: August 27, 2026
Learn to extend Amazon Bedrock Guardrails beyond the model boundary to tool calls, external data, and MCP server interactions using three validation checkpoints built with Strands Agents SDK lifecycle hooks.

Security Hub Extended adds supply chain security as its tenth category
Author: Michael Fuller | Published: August 18, 2026
AWS Security Hub Extended now includes supply chain security with Chainguard and Socket as curated partners, helping you verify open source dependencies and block malicious packages through a single AWS billing relationship.

Detecting multi-stage attacks on AWS: a guide to cross-service signal correlation
Authors: Nisha Kashyap | Published: August 26, 2026
Learn to correlate signals across AWS CloudTrail, VPC Flow Logs, and Route 53 Resolver logs to detect multi-stage attacks by layering your business context, data classification, access norms, and change windows – on top of Amazon GuardDuty Extended Threat Detection.

AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows
Author: Chet Kapoor | Published: August 5, 2026
AWS Continuum for code vulnerabilities now integrates with Anthropic Claude Code, OpenAI Codex, and Kiro, enabling developers to discover, prioritize, validate, and remediate vulnerabilities within their coding environments.

We invited a direct competitor into Security Hub Extended. Here’s why.
Authors: Michael Fuller | Published: August 31, 2026
AWS Security Hub Extended now includes Upwind, a runtime-first cloud security company, offering eBPF-based workload protection with pay-as-you-go pricing through a single AWS bill, reinforcing customer choice even where capabilities overlap with AWS offerings.

AWS Network Firewall now supports rule hit count
Authors: Preetkumar Shah, Amit Gaur, Cheriyan Mundapuzha, Santosh Shanbhag, Srivalsan Mannoor Sudhagar | Published: August 20, 2026
AWS Network Firewall now tracks how often stateful rules match traffic, helping you identify unused rules, validate security controls for compliance, and accelerate incident response at no additional cost.

Landing Zone Accelerator independent assessment report for C5:2020 now available on AWS Artifact
Authors: Kevin Donohue, Michael Wahlers | Published: August 11, 2026
An independent assessment by Schellman evaluates how Landing Zone Accelerator on AWS aligns to C5:2020 requirements, implementing 325 security controls to accelerate your compliance journey.

Fast track ISM-ready cloud environments and IRAP assessments with Landing Zone Accelerator on AWS
Authors: Kevin Donohue, Dave Connell, Dan Friebe | Published: August 25, 2026
A new independent assessment by gwi.digital evaluates Landing Zone Accelerator against 1,081 ISM controls, achieving 91% coverage of addressable scope to help Australian customers accelerate IRAP assessment readiness.

How Moeve scales AWS governance with automated AWS Organization Service Control Policies
Authors: Gonzalo Guerrero, Jonatan De Martín, Rayco Martinez | Published: August 26, 2026
Learn how Moeve manages 150 SCPs across 300+ accounts in three AWS Organizations using a governance-as-code model; policies live in Git, deploy through GitHub Actions pipelines, and attach dynamically based on account metadata during onboarding, with Amazon EventBridge and AWS Lambda providing real-time observability of every organizational change.

In August 2026, AWS published 23 security bulletins addressing vulnerabilities across open-source SDKs, MCP servers, developer tools, and the OpenSearch ecosystem. A dominant theme was the AI agent tool surface: prompt-injection consent bypasses in Strands Agents Tools enabled command and code execution, an insecure direct object reference exposed cross-tenant agent memory, and credential disclosure and authorization flaws affected the Amazon MQ, DocumentDB, and AWS Transform MCP servers and the Bedrock AgentCore harness. Remote code execution recurred throughout, from prototype pollution and Java deserialization in OpenSearch to path-traversal-to-root in amazon-ssm-agent, Zip Slip in awsdac, and an uncontrolled search path in the Kiro IDE and CLI on Windows.

Other notable issues include disabled SSH host key verification in the AWS CLI, memory-safety flaws in the AWS SDK for C++, privilege escalation in the FreeRTOS-Kernel, and memory-amplification denial of service in Amazon ion-java. OpenSearch accounted for a large share of the month, spanning authorization, input validation, SSRF, stored XSS, and denial of service, while Athena Federated Query connectors exposed Secrets Manager secrets. A common thread: insufficient authorization and input validation at the boundary between AI agents and the systems they reach. All patches are available, upgrade promptly. For more information, see AWS Security Bulletins.

In August 2026, we published 17 new code samples organized into five categories: governance and compliance (7), AI security (3), data protection and privacy (3), identity and access management (2), and infrastructure security (2). This month’s collection reflects the rapid growth of agentic AI workloads: most samples focus on governing, auditing, and securing AI agents built on Amazon Bedrock AgentCore, from platform-level governance and telemetry to fraud investigation and biosecurity screening.

Agentic Governance Platform

Learn to deploy an AWS-native control plane for governing AI agents across your enterprise with centralized registry, Microsoft Entra ID single sign-on, Cedar tool policies, multi-vendor agent inventory, and Langfuse observability, all self-hosted on Amazon Bedrock AgentCore.

Enterprise Agentic AI Platform Accelerator

Learn to deploy a secure, governed foundation for production AI agents on Amazon Bedrock AgentCore with modular CDK stacks covering identity, gateway, memory, runtime, and observability; supporting Strands Agents, LangGraph, and Claude Agent SDK with opt-in security controls.

Video Compliance Agent

Learn to deploy an end-to-end pipeline that automatically verifies video content against broadcast compliance guidelines such as Ofcom; extracting frames, audio transcripts, and OCR text shot by shot, then using Amazon Bedrock to flag potential violations and produce a structured per-shot compliance report.

Intelligent Security for Healthcare APIs

Learn to add behavioral anomaly detection, automated data sensitivity classification, and HIPAA compliance reporting to your FHIR API using Amazon Bedrock; running asynchronously so clinical workflows are never blocked, with Amazon Comprehend Medical and Bedrock Guardrails anonymizing PHI throughout the monitoring path.

Governed Agentic Companion

Learn to deploy a governed, orchestrator-driven multi-agent builder companion on Amazon Bedrock AgentCore, reachable from Kiro, Claude Code, or any MCP client; the kit enforces 13 codified tenets through an always-on governance gate with no off switch, routing each request to a specialist while blocking deploys, secret leaks, and ungrounded answers by construction.

Audit the Agent

Learn to deploy a serverless daily executive audit pipeline for AWS AI agents (AWS DevOps Agent, AWS Security Agent) using AWS Step Functions and AWS Lambda; the report answers five questions: what the agent accessed, who authorized it, what it cost, its risk posture across five trust dimensions, and whether you should be concerned, all sourced deterministically from AWS CloudTrail, CUR, and IAM with AI-generated summaries bounded by layered guardrails.

Telemetry Enablement for AgentCore CloudFormation

Learn to deploy a single AWS CloudFormation stack that enables Amazon CloudWatch logs and X-Ray traces for every Amazon Bedrock AgentCore resource type – Runtime, Gateway, Memory, Browser, CodeInterpreter, and WorkloadIdentity – using native and custom telemetry rules.

Bedrock Guardrails to OCSF on CloudWatch

Learn to transform Amazon Bedrock Guardrails intervention events into OCSF Detection Finding records and land them in the Amazon CloudWatch unified data store; enabling you to query guardrail violations alongside AWS CloudTrail, Amazon VPC Flow Logs, and other sources with Amazon Athena or CloudWatch Logs Insights.

Bedrock Readiness Agent

Learn to deploy a read-only assessment agent built with the Strands Agents SDK that evaluates your Amazon Bedrock environment across six dimensions: IAM governance, data retention, quota headroom, model selection fitness, cost projection, and operational observability; generating severity-rated findings with AWS CloudFormation and Terraform remediation templates you can apply directly.

DDoS Guardian

Learn to install an agent skill that reviews an AWS WAF web ACL as a system: evaluation order, rule interactions, and L7 DDoS posture; then delivers a severity-ranked HTML report with ready-to-apply remediation. Offline, read-only, no AWS resources modified.

Biosecurity Screening Policy on Amazon Bedrock AgentCore Gateway

Learn to use Policy in Amazon Bedrock AgentCore to deterministically screen AI agent tool requests for biosecurity risks, combining Cedar policies with three independent screening layers: MMseqs2 sequence alignment, ESMC-600M embedding similarity, and Foldseek structural homology; enabling defense-in-depth controls that block high-risk protein sequences before they reach downstream tools.

MCP Fraud Investigation Agent

Learn to deploy an end-to-end AI-powered e-commerce fraud investigation agent built with the Strands SDK on Amazon Bedrock AgentCore, connecting through an AgentCore Gateway over MCP to query transaction history, customer profiles, login activity, support cases, and fraud playbooks; a React dashboard on AWS Amplifystreams the agent’s reasoning token by token as it works each case.

IAM Account Access Manager with ABAC

Learn to implement workforce access using IAM account access manager and attribute-based access control, where one IAM role per project shares a single policy document and access decisions are made by comparing role tags against resource tags at request time; onboarding a new project requires only tagging and entitlement configuration with no policy authoring.

Operationalizing Least Privilege: Automate IAM Remediation through Your CI/CD Pipeline

Learn to automate remediation of unused IAM permissions using AWS IAM Access Analyzer, AWS CloudTrail, and Amazon Bedrock for AI-generated AWS CDK code; the solution attributes each role to its origin (IaC or manual), then creates pull requests for IaC-managed roles or issues for manually created roles in GitLab or GitHub, with configurable exclusion rules and policy diffs for human review.

Data Residency Chatbot with Amazon Bedrock AgentCore

Learn to deploy a data-residency-compliant natural-language chatbot on Amazon Bedrock AgentCore where all data and AI inference stay within a single AWS Region; the solution uses a Strands agent that answers plain-English questions from Aurora PostgreSQL through governed, whitelist-validated read-only tools exposed via an AgentCore Gateway, with a residency guard that rejects any cross-region inference profile, demonstrated with a rooftop-solar subsidy program and adaptable to any sector or geography.

LLM-based PII Detection

Learn to detect personally identifiable information in conversational text using Amazon Bedrock; the solution prompts any Converse-compatible model to return PII spans with category, value, and character offsets, handles long inputs via word-boundary chunking, recovers near-miss labels, and supports custom categories, few-shot examples, and pluggable backends beyond Bedrock.

Agentic Data Classification and Redaction

Learn to build a conversational AI research assistant that automatically classifies documents for MNPI, PII, and security sensitivity, then enforces per-user redaction at query time using Amazon Bedrock AgentCore, Guardrails, and Amazon OpenSearch Serverless vector search.

August 2026 provides comprehensive guidance and runnable code for governing agentic AI workloads at enterprise scale, from orchestrator-driven governance gates and biosecurity screening policies to daily executive audit pipelines and OCSF-normalized guardrail telemetry. The posts and samples provide patterns for console Private Access in isolated VPCs, attribute-based access control with IAM account access manager, automated least-privilege remediation through CI/CD, and cross-service signal correlation for multi-stage threat detection. Each resource includes deployment steps or runnable code so you can validate in your own environment before adopting. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.

If you have feedback about this post, submit comments in the Comments section below.

The Australian Signals Directorate (ASD) has this month issued a clear call to action through its Multi-factor authentication: Switch it on campaign, urging businesses, organisations, and individuals to enable multi-factor authentication (MFA) across their online accounts. At AWS, we strongly support this message.

As threat actors continue to target credentials through phishing, credential stuffing, and social engineering, passwords alone are no longer enough. MFA is one of the most effective security controls available. It’s a cornerstone of ASD’s Essential Eight maturity model and a recognized component of major cybersecurity frameworks worldwide. ASD’s campaign reinforces what the security community has long advocated: switching on MFA is one of the simplest and most impactful steps any organization or individual can take to protect themselves online, and we encourage all to heed ASD’s call.

At AWS, we’ve put this principle into practice at scale. In June 2025, AWS Identity and Access Management (IAM) achieved comprehensive MFA enforcement for root users across all account types, a significant milestone and the first of its kind among major cloud providers. This was the culmination of a deliberate, phased security journey: beginning with requiring MFA for AWS Organizations management account root users in May 2024, expanding to standalone account root users in June 2024, introducing centralized root access management in November 2024, and completing enforcement across all account types including member accounts. MFA prevents over 99 percent of password-related attacks and is available to all AWS customers at no additional cost, with support for FIDO2 passkeys and FIDO-certified security keys for phishing-resistant authentication. This milestone reflects our ongoing commitment to secure-by-design principles, setting a high bar for our customers’ default security posture and demonstrating that organizations of any scale can, and should, make MFA the standard rather than the exception.

A compromised email account can be used to reset AWS passwords. A breached source control system can expose infrastructure-as-code secrets. Enable MFA on your email, collaboration tools, source control, and other services that support it. Visit the ASD Multi-factor authentication campaign page for broader guidance.

AWS enforces MFA automatically for root users. To extend that same protection to your IAM users—the identities your team members and applications use daily—you can configure MFA individually through the AWS Management Console for IAM. To learn more, see Security best practices in IAM. For phishing-resistant authentication with FIDO2 passkeys, see Passkeys and security keys in IAM.

If you have questions or feedback about MFA on AWS, leave a comment below or reach out on AWS re:Post. If you haven’t already, heed ASD’s call and switch on MFA across every account you own.

This post was written in support of ASD’s Multi-factor authentication: Switch it on campaign. For more AWS security content, visit the AWS Security Blog.

If you have feedback about this post, submit comments in the Comments section below.

Recorded Future's Insikt Group^Ⓡ, our team of threat intelligence analysts and security researchers, has been tracking a technique called ClickFix as it works its way into a growing number of brand impersonation campaigns. We recently hosted a webinar digging into that research, and what stood out wasn't just the technique itself. There's no malware automatically installed, no exploit, just a page convincing enough that the victim ends up doing the damage themselves. It is also a strong example of the detection capabilities built into Malicious Site Monitoring, a new use case included in Digital Risk Protection, and a good way to show what those capabilities are actually built to catch.

How ClickFix actually works

ClickFix works by mimicking the visual language people already trust, a CAPTCHA prompt, a familiar logo, a "verify you're human" screen, and using that trust to get someone to run a command on their own machine. There's no code being smuggled past a firewall. The victim is the delivery mechanism.

That's also what makes it hard to catch with traditional tools. A page built to look exactly like a real verification screen doesn't behave like malware, and it doesn't trip the same alarms as a page trying to exploit a browser. It succeeds because the person on the other end believes they're completing something routine.

It's not static, either. The instructions can change depending on the operating system a victim is running, one path for Windows, a different one for macOS, which means the "fix" itself adapts to the target. A single signature or a one-off takedown was never going to keep up with that. Catching this at scale means watching for the pattern, not waiting to recognize a specific file.

Malicious Site Monitoring

This kind of research and the product built to act on it aren't two separate things. Digital Risk Protection's Malicious Site Monitoring is built to catch this exact category of infrastructure, phishing domains, lookalike sites, brand impersonation, fast enough to matter. Disposable infrastructure like this is designed to do its damage and disappear before anyone gets around to reporting it, so speed isn't just a nice-to-have here, it's a necessity.

Underneath that speed is a detection process built in layers. Analyst-built signatures catch known patterns with precision. Content similarity analysis can catch campaigns that move in clusters. Attackers often reuse the same page template across dozens of disposable domains, so even though each domain name looks unrelated, the pages themselves share the same structure underneath. A separate component flags a familiar logo or brand mark through screenshot analysis and Optical Character Recognition (OCR). Machine learning is often able to catch what the other methods might miss, sites that don't resemble any known signature or template, by predicting risk from the page's characteristics rather than requiring a direct match. That layered approach is what makes it possible to evaluate a massive volume of candidate domains and URLs every single day without generating excessive false positives.

From detection to takedown

Finding a threat fast doesn't help much if the next steps are still manual. The real shift in how Digital Risk Protection operates is this: detection, triage, and action now live in the same workflow.

Not every detection needs a human to look at it immediately, and that distinction matters. A multi-stage detection funnel helps filter raw monitoring volume down to those that could need a response, and for malicious sites specifically, an AI Triage Agent reviews flagged detections and delivers a verdict before anything reaches an analyst's queue. Instead of triaging a wall of alerts, teams are looking at a shortlist of things that already have context attached, what was found, why it matters, and what to do about it.

And when something does need action, takedown doesn't require a separate process. Coordination happens directly from the alert, one click, instead of manually chasing down registrars and hosting providers one by one.

What this means going forward

ClickFix is one campaign type. It won't be the last one built this way, and it almost certainly won't be the most sophisticated one we see this year. The interesting story isn't any single technique, it's that the same detection engine tracking it in a research report is the one running in production, watching for the next one before it has a name.

If you want to see that detection-to-action workflow in practice, not just malicious sites, but the full picture across dark web monitoring, code repository exposure, impersonation, and identity monitoring, take a self-guided click-through of Digital Risk Protection or request a demo. If you're already a customer, your account team can walk you through what this looks like against your own brand.

Frequently asked questions

Is ClickFix something Digital Risk Protection can actually detect, or just something Insikt Group writes about?

Both. The detection methodology behind the ClickFix research, layered signature, similarity, and machine learning analysis, is the same engine running inside Malicious Site Monitoring today. The research isn't separate from the product; it's built on it.

Is the AI Triage Agent available for this use case?

Yes. Malicious Site Monitoring is one of two use cases, alongside Dark Web Brand Monitoring, where the AI Triage Agent is live today. It reviews flagged detections and delivers a verdict before anything reaches an analyst's queue.

How do I get access to Digital Risk Protection?

It's available as a standalone solution or as part of Recorded Future's Core, Professional, and Elite platform packages. If you already use Recorded Future for brand monitoring, it's available to activate directly in the platform. If you're new to Recorded Future, request a demo to see it in action.

The intelligence community has always done things the same way: Identify a potential source (a target); make a recruitment (an agent); train, brief, and run the agent in place to collect intelligence of value to decision makers.

A great agent gives the decision maker insight into intent, and a reasoning and decision advantage over his or her adversaries. In some circumstances, this advantage shapes destiny. Control over destiny is commonly called sovereignty.

AI has rapidly made reasoning ubiquitous; a commodity accessible to all at ever-decreasing marginal cost. In the age of AI, advantage accrues to those who use reason most effectively, make good decisions most quickly, and take actions most confidently. And who will do the bulk of this reasoning, make these decisions, and take these actions? Agents.

Agent Running in the Age of AI

Historically, agents were sources of intelligence but, in the age of AI, the new consumer of intelligence is an agent. Agents will be dependent on the quality and timeliness of the intelligence they receive to give them context, shape their priorities, drive their behavior, and ensure the quality of their actions. Every agent will need an intelligence layer it can trust. Recorded Future is that layer.

Recruiting and running human agents is hard and expensive, and very few have the resources and the expertise to do it well. One experienced MI6 officer might run a handful of agents at any one time. But the human-to-agent ratio is about to change dramatically as decision-making shifts from carbon to silicon, driving down the costs of agent running, but dramatically increasing our reliance on agent decisions and actions.

The best military and political outcomes often result from the seamless integration of different sources and types of intelligence to produce a true understanding of the threat or the objective to be met, enabling good decision-making and decisive actions. The Cuban Missile Crisis combined geospatial, human, and signals intelligence; the D-Day Landings combined signals, human, and meteorological intelligence. As frontier AI capabilities diffuse, and as agentic systems incorporate these capabilities into multi-agent workflows, the performance of these systems relative to others, and thus their ability to deliver advantage, will be determined by ongoing access to high-fidelity, multi-source intelligence.

This is already the case in the domain of cyber security. Intelligence-enriched systems and workflows learn more quickly, adapt more nimbly, and operate more efficiently and effectively than those they are competing with. The adoption rate of Recorded Future’s AI triage capabilities proves this hands down.

Intelligence platforms like Recorded Future, which shed light on threat actor tactics, techniques, and procedures (TTPs) in real time, and which scale with AI and agent capabilities, are the foundation for effective agentic systems. Intelligence-driven agent running will ensure better agentic decisions and actions, delivering an enduring advantage over adversaries.

As former CIA Director Bill Burns put it, “The foundation for good policy choices is good intelligence wisely used.” In the age of AI, agents will make those choices, and the value of good intelligence will be greater than ever.

Security teams investigating possible AI-related security events need guardrail intervention data alongside their existing security telemetry. When a guardrail identifies or blocks a prompt injection attempt or redacts sensitive data, that intervention carries additional investigative value comparable to a failed sign-in or a network intrusion alert. AWS Bedrock publishes this telemetry to AWS CloudWatch metrics and model invocation logs for operational monitoring.

In this post, I show you how to transform AWS Bedrock Guardrails intervention events into structured Open Cybersecurity Schema Framework (OCSF) Detection Finding records and land them in the CloudWatch unified data store. Launched in December 2025, the unified data store consolidates operational, security, and compliance data from AWS services and third-party sources into a single platform. Security operations center (SOC) and threat analysts can query guardrail events alongside identity, network, and endpoint data, including AWS CloudTrail and AWS Virtual Private Cloud (AWS VPC) Flow Logs, using AWS Athena or CloudWatch Logs Insights.

Consider an organization deploying AWS Bedrock across many applications, with guardrails applied as a governance control. The guardrails detect and block several categories of activity: harmful content, off-topic queries, sensitive information such as personally identifiable information (PII), and prompt injection attempts. Each time a guardrail intervenes, it produces a signal the security team wants to investigate alongside the rest of its telemetry.

Without a consolidation layer, guardrail interventions stay siloed as per-AWS Region CloudWatch metrics and entries in raw model invocation logs, separate from the identity, network, and audit data the security team already relies on. The CloudWatch unified data store is built to remove this kind of silo: it consolidates operational and security data across accounts and Regions into one store. Routing normalized guardrail records into it is what makes them correlatable with the rest of your security telemetry. To investigate effectively, the team needs to answer questions that span multiple data sources:

• Identify which user accounts trigger the most guardrail interventions, and whether those same accounts also show unusual AWS Identity and Access Management (IAM) activity such as failed API calls or privilege changes. A spike in prompt injection blocks from a role that’s also generating access-denied events is a stronger signal than either on its own.
• Determine whether prompt injection attempts correlate with specific source IP addresses that also appear in VPC Flow Logs, which helps distinguish a single misbehaving client from a coordinated pattern across the environment.
• Track the trend of guardrail violations across the organization and compare it against a baseline from 30 days ago, so the team can tell routine policy noise apart from an emerging change in attacker behavior or a misconfigured application.

AWS GuardDuty already helps here: its AI Protection feature analyzes CloudTrail data events from AWS Bedrock and produces managed threat findings, including a direct prompt injection finding and anomalous model invocation findings. GuardDuty AI Protection is a complementary managed detection layer for AWS Bedrock activity. The pipeline in this post works alongside it: it captures the raw guardrail intervention records themselves, normalizes them to OCSF, and lands them in the unified data store so you can run your own cross-source correlation and long-term trend analysis alongside GuardDuty findings, CloudTrail, and VPC Flow Logs.

Guardrail traces arrive as JSON embedded in the AWS Bedrock model invocation logs, in an AWS Bedrock-specific shape rather than a normalized security schema. After the pipeline transforms them to OCSF and ingests them into the CloudWatch unified data store, a single Athena query answers all three questions, because guardrail findings then share the same field structure as other security sources and sit in the same catalog as AWS CloudTrail events and VPC Flow Logs.

At a high level, the solution captures guardrail intervention events from AWS Bedrock model invocation logs, transforms them into OCSF Detection Finding records with an AWS Lambda function, and lands them in the CloudWatch unified data store, where SOC analysts query them with Athena or CloudWatch Logs Insights. The CloudWatch unified data store provides Apache Iceberg-compatible access through AWS S3 Tables, CloudWatch Logs Insights queries, and, for supported sources, built-in OCSF normalization at ingestion.

CloudWatch offers native OCSF conversion through the ParseToOCSF log transformation processor for specific AWS log sources. As of this writing, that processor supports five AWS log sources: CloudTrail, AWS Route 53 Resolver, VPC Flow Logs, AWS EKS audit logs, and AWS WAF. AWS Bedrock Guardrails isn’t one of the sources that ParseToOCSF supports, so guardrail traces aren’t converted to OCSF automatically.

Guardrail traces also need transformation logic that ingestion-time processors don’t provide. A single model invocation log can contain multiple guardrail assessments (for example, a content policy filter and a sensitive information policy match in one request), and the transform step splits that one log entry into one OCSF Detection Finding per assessment rather than a single combined record. This one-to-many expansion, combined with conditional severity assignment based on policy type, is application logic rather than field normalization. For these two reasons, this solution uses a dedicated transform step to produce OCSF records, then uses built-in CloudWatch mechanisms for enrichment, storage, centralization, and query.

This solution captures AWS Bedrock model invocation logs containing guardrail trace data, filters for intervention events, transforms them into OCSF Detection Finding records (class_uid 2004), and writes the structured records to a CloudWatch Logs log group that is associated with AWS S3 Tables through the CloudWatch unified data store managed integration. Guardrail interventions are detection events: the guardrail detected and blocked prohibited content, so OCSF class 2004 (Detection Finding) under the Findings category is the appropriate classification.

How a source’s records are stored depends on whether it’s a vended source or a custom source. For the five vended sources that ParseToOCSF supports, the unified data store produces individual typed OCSF columns. For any custom source, including AWS Bedrock Guardrails in this solution, records land in the associated S3 Tables table as OCSF JSON in a single managed cwl__message column rather than as typed columns. This is a property of custom sources in general, not specific to AWS Bedrock. You read the OCSF fields at query time with Athena json_extract functions, and you can correlate them with the vended sources that share the same catalog. This post shows that query pattern.

The pipeline supports multiple AWS Bedrock event types by changing the filter pattern and OCSF mapping. This post demonstrates the guardrail interventions row:

The following diagram shows the end-to-end pipeline from guardrail intervention to CloudWatch unified data store ingestion. It shows the flow within a single account for clarity. In an organization, you deploy this transform pipeline in each workload account and use CloudWatch Logs centralization to bring the OCSF output into one central account, so you query organization-wide without standing up the query layer per account or per Region. The Multi-account deployment section later in this post covers this pattern.

Figure 1: End-to-end pipeline from guardrail intervention to CloudWatch unified data store ingestion

The data flow consists of the following steps:

1. An application calls AWS Bedrock (InvokeModel or Converse API) with a guardrail attached.
2. AWS Bedrock evaluates the guardrail and logs the invocation, including guardrail trace data, to a CloudWatch Logs log group using model invocation logging. A subscription filter matches log entries where the guardrail action is INTERVENED (blocked or masked content).
3. The subscription filter delivers matching records to a Lambda function (OCSF Transform). This step performs the custom transformation that native OCSF conversion doesn’t cover for AWS Bedrock, expanding each guardrail assessment into its own OCSF Detection Finding.
4. The Lambda function writes the OCSF JSON records to a dedicated CloudWatch Logs log group and sets contextual fields (account ID and Region) on each record during transformation. If the Lambda function fails to process a record, the message routes to an AWS Simple Queue Service (AWS SQS) dead-letter queue for later analysis and redrive.
5. The destination log group is associated with AWS S3 Tables through the CloudWatch unified data store managed integration, so the unified data store stores the OCSF records as an Apache Iceberg table. Because AWS Bedrock Guardrails is a custom source, each record is stored as OCSF JSON in a managed cwl__message column.
6. SOC analysts query guardrail intervention data with Athena, using json_extract to read the OCSF fields, and correlate it with vended security sources (CloudTrail, VPC Flow Logs) that share the same catalog. For real-time operational queries, analysts can also query the destination log group directly with CloudWatch Logs Insights.

The following table shows how AWS Bedrock Guardrails intervention fields map to OCSF Detection Finding (class_uid 2004) attributes.

The following prerequisites are needed to deploy the reference implementation. Before you begin, clone the repository:

git clone https://github.com/aws-samples/sample-bedrock-guardrails-cloudwatch.git
cd sample-bedrock-guardrails-cloudwatch

Verify you have the following:

• An AWS account with AWS Cloud Development Kit (AWS CDK) bootstrapped in the target Region
• Python 3.12 or later
• Node.js 20 or later (for AWS CDK CLI)
• An existing AWS Bedrock guardrail (or create one during deployment)
• Model invocation logging enabled on AWS Bedrock (with guardrail trace data enabled)
• The target Region must support the CloudWatch unified data store and AWS S3 Tables integration (see the CloudWatch pipelines Regional availability)

The reference implementation deploys two CloudFormation stacks: TransformPipelineStack and MonitoringStack. The following commands deploy the stacks in dependency order:

cdk deploy TransformPipelineStack \
  -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf

cdk deploy MonitoringStack \
  -c alarm_email=your-team@example.com

Or deploy both stacks at once:

cdk deploy --all \
  -c destination_log_group=/aws/cloudwatch-uds/bedrock-guardrails-ocsf \
  -c alarm_email=your-team@example.com

Model invocation logging captures the guardrail trace data you need. Turn on full request and response logging to a CloudWatch Logs log group and configure textDataDeliveryEnabled to capture the text bodies that include the guardrail trace output when a guardrail is attached to the invocation. The following AWS Command Line Interface (AWS CLI) command enables it:

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/aws/bedrock/model-invocation-logs",
      "roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole"
    },
    "textDataDeliveryEnabled": true
  }'

Because logging is an account-level prerequisite rather than part of the pipeline, the CDK stacks don’t manage it. Enable it once for each account before deploying.

The TransformPipelineStack deploys the Lambda function, subscription filter, destination log group, and dead-letter queue.

• Create the subscription filter: The stack creates a CloudWatch Logs subscription filter on your model invocation log group with a filter pattern that matches guardrail interventions. This captures only the events where a guardrail blocked or modified content, not the successful pass-through events, which reduces Lambda invocations and cost.
• Transform to OCSF: The Lambda function parses each CloudWatch Logs event and produces one OCSF Detection Finding record (class_uid 2004) per guardrail assessment in the trace. The transformation maps guardrail trace fields to OCSF attributes as described in the OCSF mapping table and sets contextual fields such as account ID and Region. Severity is set to High for prompt injection interventions and Medium for content, topic, or sensitive information interventions. The records contain structural metadata only; no prompt or response content is included.
• Dead-letter queue: If the Lambda function fails to process a record, the message routes to an AWS SQS dead-letter queue with error metadata (error type, message, timestamp) for investigation and redrive.

To make the OCSF records queryable through Athena, associate the destination log group with AWS S3 Tables. This is a two-step managed setup: create an S3 Tables integration, then associate the log group as a data source. The integration delivers to the managed aws-cloudwatch table bucket at no additional storage charge.

1. Tag the destination log group so the unified data store recognizes it as a data source. Use the tags cw:datasource:name (for example, bedrock_guardrails) and cw:datasource:type (for example, ocsf). The generated table name joins the two tag values with a double underscore, so these example tags produce a table named bedrock_guardrails__ocsf.
2. Create the integration with CreateS3TableIntegration (CloudWatch Observability Admin), supplying an encryption configuration and an IAM role. This returns an integration AWS Resource Name (ARN).
3. Associate the data source with AssociateSourceToS3TableIntegration (CloudWatch Logs), passing the integration ARN and the dataSource name and type from step 1.

The reference implementation performs steps 2 and 3 with the CloudFormation resource AWS::ObservabilityAdmin::S3TableIntegration and a custom resource that calls AssociateSourceToS3TableIntegration, so cdk deploy sets up the association for you.

After association, the OCSF records become available as an Apache Iceberg table in the managed catalog, at the path "s3tablescatalog/aws-cloudwatch"."logs"."bedrock_guardrails__ocsf". You can query it with Athena, AWS Redshift, or any Iceberg-compatible tool.

As noted in the solution overview, AWS Bedrock Guardrails is a custom source, so each record is stored as OCSF JSON in a managed cwl__message column. You read the fields at query time with the Athena json_extract_scalar function, as shown in the next section, and correlate against vended sources such as CloudTrail in the same catalog.

The association delivers records to the managed table, but analytics engines can’t read them until you enable the AWS S3 Tables analytics integration and grant read permissions. Complete these steps once in each Region:

1. In the AWS S3 console, choose Table buckets, then choose Enable integration. The first time you do this in a Region, AWS S3 creates a service role that lets AWS Lake Formation federate access to your tables in the AWS Glue Data Catalog. This is what makes the s3tablescatalog catalog visible to Athena.
2. In the Lake Formation console, under Data lake permissions, choose Grant, and grant Select and Describe on the aws-cloudwatch table bucket (and the bedrock_guardrails__ocsf table) to each IAM principal that runs queries, such as your SOC analyst roles. Without this grant, Athena queries return an access denied error even when the IAM policy allows Athena.
3. In the Athena query editor, choose the AWS S3 Tables catalog from the data source list, and select the logs database.

The MonitoringStack creates a CloudWatch dashboard and alarms for pipeline health. The dashboard includes widgets for intervention count by policy type, transform errors, Lambda duration, and dead-letter queue depth. Alarms notify your team when the error rate exceeds 5 percent, the dead-letter queue depth exceeds 0, or p99 Lambda duration exceeds 10 seconds. Notifications are sent through AWS Simple Notification Service (AWS SNS).

After deployment, guardrail interventions are available through two query paths. Use the one that matches your investigation:

• Athena (through AWS S3 Tables) for cross-source correlation and historical analysis. Athena joins the OCSF guardrail records with vended OCSF sources in the unified data store (such as CloudTrail and VPC Flow Logs) over long time ranges. Because AWS Bedrock Guardrails is a custom source, its OCSF fields live inside the cwl__message column, so you read them with json_extract_scalar. Use Athena when you need to join guardrail findings against other security data or run trend analysis across weeks or months.
• CloudWatch Logs Insights for real-time, operational queries against the destination log group. Use Logs Insights when you need results in seconds on recent data, without a table join, such as during an active investigation.

The Athena queries in this section run against the managed table "s3tablescatalog/aws-cloudwatch"."logs"."bedrock_guardrails__ocsf". For readability, the examples reference it as bedrock_guardrails_ocsf after selecting the s3tablescatalog/aws-cloudwatch catalog and logs database in the Athena query editor.

The following example identifies users who trigger both prompt injection interventions and failed CloudTrail activity. The guardrail side extracts fields from cwl__message; the CloudTrail side is a vended source with typed OCSF columns.

WITH guardrail_violators AS (
    SELECT json_extract_scalar(cwl__message, '$.actor.user.uid') AS user_arn,
           COUNT(*) AS violation_count
    FROM bedrock_guardrails_ocsf
    WHERE json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') = 'PromptAttack'
    GROUP BY json_extract_scalar(cwl__message, '$.actor.user.uid')
),
iam_failures AS (
    SELECT "actor.user.uid" AS user_arn, COUNT(*) AS failure_count
    FROM aws_cloudtrail__management
    WHERE "status_id" = 2
    GROUP BY "actor.user.uid"
)
SELECT g.user_arn, g.violation_count, i.failure_count
FROM guardrail_violators g
JOIN iam_failures i ON g.user_arn = i.user_arn
ORDER BY g.violation_count DESC;

You can also track violation trends by policy type over time to establish baselines and detect spikes:

SELECT date_trunc('day', from_unixtime(
         cast(json_extract_scalar(cwl__message, '$.time') as bigint) / 1000)) AS event_day,
       json_extract_scalar(cwl__message, '$.unmapped.guardrail_policy_type') AS policy_type,
       COUNT(*) AS violation_count
FROM bedrock_guardrails_ocsf
GROUP BY 1, 2
ORDER BY event_day, violation_count DESC;

If you run these correlation queries frequently, you can materialize the extracted OCSF fields into a typed table with CREATE TABLE AS SELECT (CTAS) and refresh it on a schedule. Queries against the materialized table use plain column names instead of json_extract_scalar, which keeps recurring dashboards and joins concise.

For operational queries on recent data without a table join, query the destination log group directly in CloudWatch Logs Insights:

fields @timestamp, severity, finding_info.title, actor.user.uid, unmapped.guardrail_policy_type
| filter class_uid = 2004
| filter unmapped.guardrail_policy_type = "PromptAttack"
| stats count() as attack_count by actor.user.uid
| sort attack_count desc
| limit 10

This query returns results in seconds on recently ingested records.

For organizations running AWS Bedrock across multiple accounts, the recommended pattern is to transform locally and centralize the OCSF output, rather than replicating raw invocation logs and transforming centrally.

Deploy the subscription filter and transform pipeline in each workload account where model invocation logging is enabled. Each account produces OCSF records in its own destination log group. Then use CloudWatch Logs centralization to replicate those OCSF records into a central logging account automatically. Centralization integrates with AWS Organizations and picks up new accounts as they join, and you create the AWS S3 Tables integration one time in the central account (rather than in every workload account) for organization-wide querying.

Transforming in each workload account keeps the guardrail trace parsing close to the source, avoids moving raw invocation logs (which might contain prompt and response text) across account boundaries, and centralizes only the sanitized OCSF findings. If your organization prefers to keep transformation logic in one place, an alternative is to centralize the raw invocation logs first and run a single transform pipeline in the logging account; this concentrates the parsing logic but moves more data, including request and response content, between accounts.

To avoid ongoing charges, destroy the stacks in reverse dependency order:

cdk destroy MonitoringStack --force
cdk destroy TransformPipelineStack --force

In this post, you learned how to transform AWS Bedrock Guardrails intervention events into OCSF Detection Finding records and ingest them into the CloudWatch unified data store. This integration gives SOC teams structured guardrail telemetry that correlates with CloudTrail, VPC Flow Logs, and the other security sources already available in CloudWatch. Because guardrail interventions are a custom source, their OCSF fields are stored as JSON and read with Athena json_extract functions, so you can join them with the vended OCSF sources that share the same catalog.

The pipeline filters for intervention events only, which keeps costs low while capturing the security-relevant signals. Athena over AWS S3 Tables provides cross-source correlation and historical analysis, and CloudWatch Logs Insights provides real-time operational queries.

Clone the reference implementation and adapt the OCSF mapping and subscription filter to your guardrail configuration. To extend the pipeline, apply the same transform pattern to agent guardrail traces, which map to the same OCSF Detection Finding class.

• AWS Bedrock Guardrails
• AWS CloudWatch unified data and telemetry
• Transform logs during ingestion
• ParseToOCSF processor
• AssociateSourceToS3TableIntegration
• AWS Bedrock model invocation logging
• Monitor AWS Bedrock Guardrails using CloudWatch metrics
• OCSF Detection Finding (class_uid 2004)
• CloudWatch Logs centralization

If you have feedback about this post, submit comments in the Comments section below.

Recorded Future was just named a Leader in The Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026.

We’re incredibly proud of this acknowledgment, just as we are of every recognition we’ve received over the years. Behind every one of these industry evaluations is a lot of work that readers never see — including product demonstrations, customer reference calls, briefing presentations, and formal questionnaire submissions — all of it condensed into a single final report. But the most interesting part of any industry recognition is all the details and information that resides in the demos, decks, and responses, so we wanted to share some additional context on the factors that we believe contributed to our ranking this year.

Use this blog post as a companion guide when reading your complimentary copy of the Forrester Wave™ report, which you’ll find in the link below.

Get the report.

Superior support for Priority Intelligence Requirements

Priority Intelligence Requirements (PIRs) are foundational in helping security teams achieve meaningful outcomes, because they help shape data collection strategy and support the effective decision-making that enables machine-speed defense.

Recorded Future received the highest possible score in the PIR criterion. Forrester’s evaluation describes this score as for vendors that offer “superior support for features such as mechanisms to translate external PIRs meaningfully, advanced querying for building/optimizing PIRs, and structured management of General Intelligence Requirements.”

We’ve made PIRs a particular focus in the Recorded Future Platform, adding prebuilt PIRs and enabling customers to use them or define their own in our Impact and Metrics Dashboard. The dashboard surfaces metrics based on those requirements, so teams can more easily measure and better report on how successfully their programs are answering the key questions business leadership wants answered.

Extensive intelligence collection sources and deep and dark web monitoring

Intelligence is at the core of the modern security stack, and good intelligence is often what separates reactive security teams from proactive ones that can defend themselves pre-attack, at the first sign of threat.

To us, Forrester’s evaluation criteria show how important comprehensive intelligence collection is in providing security teams with full visibility across the threat landscape. Here are the different types of data sources we primarily index and analyze and how these data sources can be used for a multitude of use cases:

1. Technical intelligence — network traffic analysis across billions of daily data points from over 200 points of presence, internet-wide scanning and infrastructure monitoring, malware detonation and behavioral analysis, and vulnerability exploitation tracking
2. Underground intelligence — data gathered from criminal forums, marketplaces, and adversaries that can help identify stolen data and credentials, emerging attack techniques, threat actor intent, and ransomware victimology
3. Community intelligence — aggregated detections across customers that reveal patterns and campaign-level activity no single organization would usually catch on its own
4. Open-source intelligence — broader context from data leakage detection, code repository monitoring, social media monitoring, and web/HTML/DOM analysis to help catch brand abuse, impersonation, and exposed data

Threat hunting, vulnerability intelligence, third-party risk management, and more
We believe that receiving the highest possible scores in the Forrester Wave in criteria around multiple cybersecurity disciplines — including brand protection, third-party and supply chain intelligence, fraud intelligence, and threat hunting and vulnerability intelligence — demonstrate our commitment to providing powerful threat intelligence and defensive capabilities across the entire attack surface.

Figure 1: Unified threat intelligence visibility across the critical attack surfaces

As both human-directed and autonomous AI-powered attacks accelerate, security organizations, policymakers, and industry groups around the world are rethinking traditional approaches to defense.

Recorded Future CISO Jason Steer and Mastercard VP of Government Affairs and Policy Christian Ohanian recently sat down with Recorded Future’s Jon Miller to discuss how to build threat intelligence programs that can defend at machine speed, how emerging policy frameworks can help, and why high-quality intelligence is increasingly essential in this new era.

This blog offers highlights from the discussion. Watch the full event.

Evolving security standards and frameworks
Globally, security frameworks like the National Institute of Standards and Technology (NIST) Cyber AI Profile and Singapore’s cybersecurity guidelines are evolving to help organizations keep pace with new threats. According to Christian Ohanian, the goal is to encourage the adoption of AI to bolster resilience while also providing guidance on the kinds of AI-enabled threats organizations now face.

However, Ohanian pointed out that creating these standards involves debate. While some argue that frameworks should provide a clear, prioritized checklist to help resource-strapped teams improve their security programs, others believe that a "one-size-fits-all" approach fails to account for the unique risk profiles of different industries and organizations.

Jason Steer noted that while standards create a helpful taxonomy, the burden remains on CISOs to translate that language into business-specific risk decisions. “This is why intelligence is important,” he noted. “Every industry, every geography, has its own subtleties of attack, so leaning into ‘What are the real risks to my business?’ becomes the hardest part.”

The role of high-quality, purpose-fit intelligence
Ohanian noted that global security standards increasingly recognize that threat intelligence is a foundational component of modern defense. They’re also beginning to acknowledge that security organizations need to use AI and other autonomous solutions to improve the way they operationalize their intelligence. Framework discussions, he said, are now focused on “the importance of organizations looking really closely at how they can increase the speed of the way they’re using threat intelligence, how they can increase the accuracy of the prioritization of the alerts and warnings they’re getting.”

Ohanian emphasized that organizations must move beyond the simple acquisition of data and evaluate the intelligence sources feeding into their threat intelligence solutions. They need to look at "fit for purpose," ensuring that the intelligence aligns with the organization’s specific risk profile and governance requirements.

Steer agreed. “Coverage and collection at fast speed enable information to be brought together for people to assess the impact to their business,” he said. “But then it's only good if that information gets to the right people in the right tools.”

When it does, he said, high-quality intelligence can better fulfill its ultimate goal of providing “decision advantage”—enabling even less experienced SOC analysts to make quick, effective decisions.

Operationalizing security at machine speed
To begin operationalizing intelligence, organizations need to first know what they’re defending. Do they run software on-premise, in the cloud, or a combination of the two? Once they have a complete picture of the mission-critical systems they need to defend, Steer said, they’ll better understand the threats that might be targeting them.

Then, in order to achieve machine-speed defense against AI-driven attacks, organizations need the right API integrations. That way, they can send enriched, contextual threat data to their vulnerability tools and use AI to identify the clusters of high-risk activity where vulnerabilities intersect with active exploitation.

Steer noted that this shift will eventually allow security leaders to move away from trying to patch every single vulnerability—an impossible task—and toward a strategic, risk-based prioritization model. “Vulnerability prioritization is absolutely primed for AI to streamline and accelerate contextual decision-making at executive levels,” he said.

Driving toward an intelligence-led defense future
The consensus from the panel was clear: The future of cybersecurity lies in the convergence of AI, intelligence-led defense, and robust governance. While the X-factor of new threats—the ones that disrupt even the best-laid plans—will always exist, the goal is to reduce reactive panic and focus on strategic risk reduction.

For security practitioners, the takeaway is two-fold. First, they need to keep a close watch on the evolution of global security frameworks, as these documents will define industry expectations and communication standards, and they’ll give organizations a better understanding of where modern security is going in light of AI.

Second, practitioners need to focus on the quality of intelligence over quantity. By ensuring that their tools are enriched with actionable context, they can empower their teams to move from a state of constant, reactive chaos to one of calculated, proactive defense.

As Jon Miller noted, intelligence-led defense is the best way to ensure that when you move at machine speed, you’re moving in the right direction. “Speed without intelligence just means you're wrong, faster,” he said.

To get a customized walkthrough of Recorded Future’s machine-speed defense in action, take our interactive tour.

An alert may be the first sign a security team sees, but it rarely marks the beginning of an attack.

Before an intrusion reaches the network, threat actors may research targets, prepare infrastructure, trade stolen credentials, or discuss vulnerabilities they plan to exploit. Security teams that rely solely on internal alerts may miss earlier activity.

Proactive threat intelligence helps security teams identify and assess threats earlier by adding external context about adversaries, infrastructure, vulnerabilities, and emerging activity. That context can help teams decide what deserves attention first and act before a threat develops into a larger incident.

Reactive security still matters: organizations need detection, incident response, and recovery capabilities when attacks occur. But proactive intelligence adds visibility earlier in the process, so security teams are not forced to make every decision after an alert fires.

Key takeaways

• Proactive threat intelligence can reveal adversary activity, infrastructure, and exposure before suspicious behavior appears inside the organization
• Intelligence can show which vulnerabilities, threat actors, and external exposures are most relevant to an organization's environment
• A proactive security mindset informs decisions about patching, threat hunting, security controls, and risk remediation
• Automated collection and analysis can reduce manual intelligence work, so analysts can spend more time investigating relevant threats

How to shift to a proactive security mindset

Reactive security begins when something has already happened. An alert fires, suspicious activity appears, or an incident is confirmed. The security team then investigates what happened and decides how to contain the threat.

Proactive threat intelligence shifts part of that work earlier by helping teams understand which adversaries may target them, which vulnerabilities attackers are exploiting, and what infrastructure or techniques are associated with current campaigns. Instead of waiting for those threats to surface internally, teams can use threat intelligence to prepare and prioritize their response.

The goal is not to predict every attack. It is to reduce uncertainty early enough to make better security decisions.

That distinction matters when teams face more alerts, vulnerabilities, and threat information than they can address at once. Proactive intelligence provides context to determine which risks are most closely connected to the organization's assets, technology, industry, and exposure.

For security leadership, that context can also support risk management. Security leaders can compare threat likelihood, asset importance, and potential business impact rather than treating alert volume as a measure of risk. This helps connect intelligence priorities with CISO-level decisions about people, budget, and remediation.

Steps in a proactive intelligence program

A proactive intelligence program follows four interconnected steps: define intelligence requirements, collect relevant information, analyze it within an organizational context, and turn the findings into security actions.

1. Requirements: Define the security and business questions the intelligence program needs to answer. These may include which adversaries pose the greatest risk, which vulnerabilities need faster action, or where the organization has external exposure.
2. Collection: Gather information that can answer those questions. Internal telemetry remains useful, but proactive intelligence also depends on external visibility. Sources may include open-source intelligence (OSINT), technical forums, dark web sources, and illicit marketplaces where threat activity can appear before an internal alert.
3. Analysis: Connect those signals with organizational context. Analysts assess whether an adversary, vulnerability, or piece of infrastructure is relevant to the organization's assets and current threat profile.
4. Action: Use that context to make a security decision. Teams may change a patching priority, block malicious infrastructure, investigate exposed credentials, or begin a targeted threat hunt.

The cycle continues as threats and business priorities change. For operational cyber threat intelligence to support security operations, the process cannot stop at collection and analysis. Intelligence needs to reach the people and controls that can act on it, then feed new findings back into the next cycle.

Examples of proactive intelligence in action

Proactive intelligence creates value when it changes a security decision. Three use cases show how external context can move action earlier.

Use case 1: Prioritize vulnerabilities using real-world threat activity

Security teams generally cannot treat every published Common Vulnerabilities and Exposures (CVE) record as equally urgent. Severity scores describe the potential technical impact of a vulnerability, but severity alone does not show whether threat actors are exploiting it or how relevant it is to a specific organization.

Proactive threat intelligence adds exploitation context to the decision.

Recorded Future Vulnerability Prioritization provides information about current exploitation and threat activity that can help teams identify which vulnerabilities warrant faster attention. A vulnerability associated with active exploitation may require a different response from another vulnerability with a similar severity score but less evidence of current attacker activity.

This gives teams another factor for deciding what to address first. It also connects threat intelligence and vulnerability management, allowing patching decisions to reflect internal exposure alongside activity in the external threat environment.

Use case 2: Identify external risk before it becomes an internal incident

Not every meaningful security signal appears within systems an organization controls.

Threat actors may register domains that imitate a company, expose employee credentials, or discuss potential targets in criminal communities. Command-and-control infrastructure and other malicious assets can also be prepared outside the organization's environment before they are used in an attack.

Digital risk monitoring gives security teams visibility into that external activity.

Recorded Future Digital Risk Protection monitors external threats including malicious domains, credential exposure, brand impersonation, and dark web activity. Finding those signals earlier gives teams an opportunity to investigate and remediate exposure before it contributes to a larger security problem.

This expands the security team's view from what has already happened internally to what is developing outside the organization.

Use case 3: Give threat hunters a more focused starting point

Threat hunting is proactive, but analysts still need a useful hypothesis about what they are looking for.

Without external context, analysts may spend too much time selecting relevant threat actors, gathering intelligence from multiple sources, validating anomalies, and assembling findings for stakeholders. Proactive intelligence can reduce some of that manual work by giving hunters a clearer starting point.

If intelligence shows that a threat actor is targeting organizations in the same industry, analysts can review that actor's known techniques, malware, and infrastructure and determine which signals are relevant to search for in internal telemetry.

The intelligence does not replace threat hunting. It helps shape the hypothesis and narrow the investigation.

Recorded Future Cyber Operations connects external intelligence with investigation, hunting, detection, and response workflows, helping analysts reach relevant threat context faster. Intelligence can also add context to alerts in SIEM, SOAR, and EDR/XDR tools, helping teams determine whether internal activity relates to known external threats.

How a proactive security mindset reduces business risk

A proactive security mindset can reduce business risk by giving teams more time and context to address relevant threats before they cause greater disruption.

Security teams can direct limited resources toward vulnerabilities being actively exploited, external exposures that require remediation, or adversaries that present a stronger risk to the organization. Earlier context can also improve preparation if a threat later develops into an incident.

For security leaders, this creates a clearer link between intelligence work and business priorities. Instead of measuring value by the number of alerts or reports produced, teams can focus on whether intelligence changed a decision, reduced exposure, or helped security teams act sooner.

Recorded Future: The engine for proactive threat intelligence

External visibility creates its own challenge: scale.

Threat information can appear across public sources, technical data, criminal communities, and internal telemetry. Manually collecting and connecting that information can leave analysts spending more time finding data than deciding what it means.

Recorded Future's Intelligence GraphⓇ addresses that problem by indexing information from more than one million sources and connecting data about threat actors, infrastructure, vulnerabilities, and organizations. The value is not simply in collecting more information, but in connecting signals and adding context so teams can better determine which threats relate to their organization and what response those threats may require. Recorded Future applies that intelligence across security and risk workflows, as the examples below show.

Precision intelligence for different security teams

• Vulnerability Prioritization adds exploitation context to help vulnerability teams prioritize remediation beyond severity scores alone.
• Cyber Operations supports investigation, threat hunting, detection, and response. External intelligence can enrich existing security tools and help teams identify and act on relevant threats with less manual research.
• Digital Risk Protection monitors external exposure such as compromised credentials, malicious domains, and brand impersonation so teams can investigate risks outside infrastructure they directly control.

Recorded Future also extends proactive intelligence into other areas of business risk.

• Third-Party Risk provides external context about vendors and other organizations in the supply chain, helping teams assess changes in third-party exposure.
• Payment Fraud monitors external fraud signals such as compromised payment data and criminal activity so fraud teams can act earlier in the fraud lifecycle.

Together, these capabilities allow teams to apply external intelligence to the decisions they already make rather than treating threat intelligence as a separate research function.

Get ahead of the next threat

Moving beyond a reactive security cycle does not mean trying to predict every attack. It means giving security teams the external visibility and context to identify relevant threats earlier, prioritize them more accurately, and act before the available window closes.

Ready to move beyond the reactive cycle and adopt a proactive security mindset? See the Intelligence Graph in action and learn how proactive threat intelligence can help your team identify and address threats before they develop into major breaches targeting your organization. Schedule a personalized demo today.

European organizations can run AI workloads on Amazon Web Services (AWS) while keeping data within the European Union (EU) and meeting regulatory requirements. You can now run generative AI workloads on open weight models on Amazon Bedrock in the AWS European Sovereign Cloud. We’re excited to announce the general availability of the first open weight model family, Gemma 4, on the Amazon Bedrock next-generation inference engine in the AWS European Sovereign Cloud. Gemma 4, released under the Apache 2.0 license, on Amazon Bedrock benefits from the same data residency and operational controls that define the AWS European Sovereign Cloud so you can build, iterate, and scale generative AI applications while meeting digital sovereignty requirements.

The AWS European Sovereign Cloud is an independent cloud for Europe, located entirely within the EU, designed to help customers meet their most stringent digital sovereignty requirements. It runs entirely within the EU and is independently operated with strong technical controls, sovereign assurances and legal protections. Only AWS employees who reside in the EU control day-to-day operations, including access to data centers, technical support, and customer service.

In this post, we explain how the Amazon Bedrock inference engine protects your inference data when running Gemma 4 models, how the AWS European Sovereign Cloud keeps it within the EU, and then walk through the available Gemma 4 models and your first inference request.

The inference engine is a distributed engine for serving large-scale machine learning models, built for high performance, reliability, and security. You reach it through the bedrock-mantle endpoint, which supports OpenAI-compatible APIs (the Responses and Chat Completions APIs). You can bring an existing OpenAI SDK codebase to Amazon Bedrock by changing only the base URL and API key. The Responses API supports stateful conversation management, which rebuilds context without you passing conversation history with each request. Stored responses are scoped by Amazon Bedrock project, a logical boundary that represents a workload for access control, cost tracking, and usage monitoring.

The engine applies the same operational security practices you rely on across AWS. Access follows a least privilege model, where each operator has access only to the systems a specific task requires, and only for the time that privilege is needed. Any access to systems that store or process customer data or metadata is logged, monitored for anomalies, and audited. All your prompts and responses are kept private during inference.

Amazon Bedrock uses a zero operator access data security model, meaning no service operators can access model input or output during inference. It also uses a zero data retention model, so by default it doesn’t store your inputs or outputs. For certain models, limited retention might apply for abuse detection (see the Amazon Bedrock abuse detection documentation). Your prompts and responses are encrypted in transit and, by default, are not shared with the model provider.

All inference stays within the eusc-de-east-1 AWS Region as described in the following section on data residency. Combined with the data residency and EU-based operations of the AWS European Sovereign Cloud, this gives organizations in highly regulated industries the confidence to run their most sensitive AI workloads in the cloud.

The AWS European Sovereign Cloud became generally available in January 2026, with its first Region in Brandenburg, Germany (eusc-de-east-1). It’s a separate, independently operated cloud, with infrastructure located entirely within the EU and no critical dependencies on non-EU personnel or infrastructure. All your content remains within the Region you select unless you choose otherwise. Beyond content, customer-created metadata including roles, permissions, resource labels, and configurations also stays within the EU. The AWS European Sovereign Cloud is operated exclusively by EU residents located in the EU. We’re also gradually transitioning the AWS European Sovereign Cloud to be operated exclusively by EU citizens located in the EU. During this transition period we will continue to work with a blended team of EU residents and EU citizens located in the EU.

All Amazon Bedrock inference requests, including Gemma 4, use in-Region inference in eusc-de-east-1, which keeps every request within the AWS European Sovereign Cloud. Global cross-Region inference, which routes requests across commercial AWS Regions worldwide, isn’t available in the AWS European Sovereign Cloud.

With AWS Identity and Access Management (IAM), you decide which principals in your account can call the inference API and which models they can use. Fine-grained permissions let you grant only the access each workload needs, following least privilege, and we recommend short-lived credentials over long-term keys.

For auditing, every call to the endpoint is recorded in AWS CloudTrail, giving your security and compliance teams an audit trail of who invoked inference and when. You can also monitor usage with Amazon CloudWatch and set alarms on patterns that matter to you, such as unexpected spikes in request volume.

Organizations adopting open weight foundation models (FMs) for production face a constant challenge: how to access the leading models without compromising on data protection, regulatory alignment, or operational control. Amazon Bedrock removes that challenge. It gives you leading open weight FMs through a fully managed service, with inference running entirely on infrastructure operated by AWS and the security and privacy controls you expect from Amazon Bedrock. Because the models are open weight, you can independently evaluate the model architecture and training methodology, benchmark your own workloads, and fine-tune on proprietary data when customization is required.

Gemma 4 is a family of open weight models, released under the Apache 2.0 license. It’s available in three instruction-tuned variants, so you can evaluate and choose the model that fits your workload. The following table provides guidance on which model to choose based on your use case:

All three variants offer built-in reasoning, native function calling, and multimodal input across text and image.

Gemma 4 is served through the bedrock-mantle endpoint, the OpenAI-compatible API for the next-generation inference engine, so you can call it with the OpenAI Python and TypeScript SDKs. Use the following steps to use the OpenAI Python SDK to send your first request to Gemma 4 31B in the AWS European Sovereign Cloud.

To follow this example, you need an AWS account with access to the AWS European Sovereign Cloud and an IAM principal with permissions to call the bedrock-mantle endpoint. Create an IAM policy that grants the two actions this walkthrough uses, then attach it to your IAM principal. The bedrock-mantle:CreateInference action runs inference, and the bedrock-mantle:CallWithBearerToken action authenticates with an Amazon Bedrock API key. The following sample policy grants the actions this example needs. Scope the resources further for your environment as described after the policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GemmaMantleInference",
      "Effect": "Allow",
      "Action": "bedrock-mantle:CreateInference",
      "Resource": "arn:aws-eusc:bedrock-mantle:eusc-de-east-1:<account-id>:project/<project-id>"
    },
    {
      "Sid": "GemmaMantleBearerToken",
      "Effect": "Allow",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*"
    }
  ]
}

Replace <account-id> and <project-id> with your own values.

Install the OpenAI SDK and the Amazon Bedrock token generator with the command pip install “openai>=2.45.0" aws-bedrock-token-generator.

You authenticate with an Amazon Bedrock API key. Amazon Bedrock offers two types of API keys. Short-term keys expire automatically within 12 hours and inherit the permissions of the IAM principal that generated them, which makes them the recommended choice for production. Long-term keys last until a configured expiration and are intended for development and exploration. For production, use the auto-refreshing short-term key shown in the following example, or store the key in AWS Secrets Manager.

from aws_bedrock_token_generator import provide_token
from openai import BedrockOpenAI

region = "eusc-de-east-1"

client = BedrockOpenAI(
    aws_region=region,
    base_url="https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu/v1",
    bedrock_token_provider=lambda: provide_token(region=region),
)

Alternatively, you can pass a short-term API key through an environment variable. This key isn’t refreshed and expires after at most 12 hours.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu/v1",
    api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"],
)

The Responses API uses a single input field and returns the generated text in output_text. Setting store to false means Amazon Bedrock doesn’t retain the request or response.

response = client.responses.create(
    model="google.gemma-4-31b-it",
    input="Explain the benefits of open-weight models for regulated industries.",
    max_output_tokens=512,
    store=False,
)
print(response.output_text)

You can also call the OpenAI-compatible Chat Completions endpoint directly. If you use AWS credentials instead of an API key, sign the request with AWS Signature Version 4 (SigV4), as in the following example.

export ENDPOINT=https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu
export AWS_REGION=eusc-de-east-1

curl -X POST ${ENDPOINT}/v1/chat/completions \
  --aws-sigv4 "aws:amz:${AWS_REGION}:bedrock" \
  --user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
  -H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "google.gemma-4-31b-it",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

This walkthrough creates no persistent resources, so there’s nothing to delete. The short-term API keys used here expire automatically within 12 hours.

Gemma 4 is available in Amazon Bedrock in the AWS European Sovereign Cloud. You pay per token with no upfront commitment, and usage counts toward your existing AWS commitments. For current pricing, see Amazon Bedrock pricing. For model and Regional availability, see Regional availability by models.

Beyond the technical integration, running AI workloads in a sovereign context raises important questions about requirements. As you plan AI workloads for a sovereign context, evaluate them against your organization’s requirements for data residency, model governance, and operational control. The AWS European Sovereign Cloud is designed to help you meet these requirements in the EU.

AWS is committed to making AWS the best place for European organizations to innovate with AI, without compromise. To learn more about AWS European Sovereign Cloud visit aws.eu.

If you have feedback about this post, submit comments in the Comments section below.

The AWS European Sovereign Cloud is a new, independent cloud for Europe, physically and logically separate from existing AWS Regions and operated within the European Union (EU). It provides the same services, features, and APIs as AWS commercial Regions, but runs as a distinct AWS partition (aws-eusc), with its own control plane, AWS Identity and Access Management (IAM), billing, console, and service endpoints. Understanding the partition boundary is the key that unlocks correct answers to questions about billing roll-ups, single sign-on (SSO), cross-account roles, AWS Direct Connect, and image distribution. In this post, we show you how to architect a secure, scalable landing zone in the AWS European Sovereign Cloud. We cover account structure and governance, identity managed as infrastructure as code (IaC), centralized logging to a security and event management (SIEM) tool, data protection, network and perimeter design, secure continuous integration and delivery (CI/CD) and artifact distribution, and incident response. Throughout, we map the design to the AWS Security Reference Architecture (AWS SRA) and the AWS Well-Architected Framework, and we call out which behaviors are platform boundaries of a sovereign partition and which are configuration choices you can adapt.

If you are evaluating compliance readiness alongside your landing zone build-out, see the companion post Landing Zone Accelerator Independent Assessment Report for C5:2020 now available on AWS Artifact. This post covers how to align with C5:2020 criteria and provides an independent assessment report and compliance workbook, resources that complement the architectural patterns described here.

AWS groups Regions into partitions. Every Region is in exactly one partition, and each partition has one or more Regions. Partitions have independent instances of AWS Identity and Access Management (IAM) and provide a hard boundary between Regions in different partitions. AWS commercial Regions are in the aws partition, Regions in China are in the aws-cn partition, and AWS GovCloud Regions are in the aws-us-gov partition. The AWS European Sovereign Cloud is the aws-eusc partition, with its first Region in Brandenburg, Germany (eusc-de-east-1).

Some AWS services provide cross-Region functionality, such as Amazon S3 Cross-Region Replication or AWS Transit Gateway Inter-Region peering. These capabilities work only between Regions in the same partition. You can’t use IAM credentials from one partition to interact with resources in a different partition. There are practical differences that impact your architecture, shown in the following table:

Every AWS Region is sovereign by design: if you find yourself architecting across Regions, note that this partition boundary means that the centralization—one organization, one logging account, one identity source, one billing roll-up—is achievable within each partition. In the EUSC you operate an independent landing zone in aws-eusc that mirrors your commercial operating model. Where you need to bridge the two clouds (for example, a standard application CI/CD system in an AWS commercial Region deploying into EUSC), you integrate at the network or API layer with separate credentials for each partition, not with cross-partition trust. With these partition fundamentals in mind, the remainder of this post walks you through the considerations to build a production-ready landing zone in the EUSC. Each section addresses a critical layer of the architecture, starting with how to write partition-aware infrastructure code that works across both aws and aws-eusc, then moving into the organizational and governance controls that underpin everything else.

These Terraform and AWS CloudFormation IaC snippets demonstrate partition-aware Amazon Resource Name (ARN) construction—a pattern that helps ensure your infrastructure code works unchanged across AWS partitions (such as standard aws, GovCloud aws-us-gov, or European Sovereign Cloud aws-eusc).

In the case of using the same Terraform script from a commercial Region, ensure that arn:aws isn’t hard coded. This Terraform script derives the partition at deploy time so the same modules work in both AWS commercial Regions and the EUSC.

# Terraform: partition-aware ARNs (works unchanged in aws and aws-eusc)data "aws_partition""current" {}
data "aws_partition" "current" {}
data "aws_region" "current" {}
data "aws_caller_identity" "current" {}
data "aws_organizations_organization" "current" {}

locals {
partition = data.aws_partition.current.partition# "aws" or "aws-eusc"
account_id = data.aws_caller_identity.current.account_id
org_id= data.aws_organizations_organization.current.id
ecs_task_execution_policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
central_logs_bucket_arn= "arn:${local.partition}:s3:::${local.org_id}-central-logs"
}

resource "aws_iam_role" "amazon_ecs_role" {
  name = "AmazonECSrole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid= ""
        Principal = {
          # IAM service principals are "amazonaws.com" across all partitions,
          # this stays literal (do NOT use ${AWS::URLSuffix} here).
          Service = "ecs-tasks.amazonaws.com"
        }
      },
    ]
  })
}

resource "aws_iam_role_policy_attachment" "amazon_ecs_role_attach" {
  role= "AmazonECSrole"
  # Use ${local.partition } rather than hardcoding "aws" in the ARN.
  policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

# CloudFormation: use the AWS::Partition pseudo parameter, never a literal "aws"

AWSTemplateFormatVersion: "2010-09-09"

Description: >-
Creates an ECS task execution role. Demonstrates using the
${AWS::Partition} pseudo parameter in ARNs instead of hardcoding "aws",
so the template works across partitions (aws, aws-cn, aws-us-gov, aws-eusc).

Resources:
  ExecRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AmazonECSroleCF
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                # IAM service principals are "amazonaws.com" across all partitions,
                # so this stays literal (do NOT use ${AWS::URLSuffix} here).
                - "ecs-tasks.amazonaws.com"
            Action: "sts:AssumeRole"
      ManagedPolicyArns:
        # Use ${AWS::Partition} rather than hardcoding "aws" in the ARN.
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"

Outputs:
  ExecRoleArn:
    Description: ARN of the created ECS task execution role
    Value: !GetAtt ExecRole.Arn

AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour. Resources are set up and managed on your behalf.

We recommend following the AWS Security Reference Architecture (AWS SRA) multi-account model structure for a EUSC deployment. Use the management account only for governance, deploy universal security guardrails through service control policies (SCPs), resource control policies (RCPs), and service deployments (such as AWS CloudTrail) that will affect all member accounts in the organization.

Region-deny SCPs are commonly applied in commercial Regions, but aren’t required (at this time) in the EUSC because of the physically and logically separated nature of its design.

Other possible SCPs for the management OU:

• Service-level guardrails – Restrict which AWS services can be used, based on your compliance posture.
• Network perimeter controls – Enforce virtual private cloud (VPC) endpoints, deny public access patterns, and restrict egress.
• Encryption and key management – Require AWS Key Management Service (AWS KMS) managed keys for all data-at-rest services and enforce key policies aligned with your sovereignty requirements.

Note: As additional EUSC Regions or Local Zones become available, the partition boundary continues to enforce isolation from non-EUSC Regions. If you need to restrict usage to a subset of EUSC Regions (for example, only eusc-de-east-1 but not a future eusc-de-west-1), a Region-deny SCP would become relevant at that point.

IAM Identity Center is available in the AWS European Sovereign Cloud as an independent instance within the partition. You can connect it to your external identity provider (IdP)—Microsoft Entra ID, Okta, and so on—using SAML/SCIM, exactly as in AWS commercial Regions. If you already use Identity Center to federate in the commercial partition, you can point a second Identity Center integration at the same corporate IdP, so users keep one set of credentials. You manage permission sets, groups, and account assignments separately for each partition.

The following Terraform defines a permission set with both an AWS managed policy and an inline least-privilege policy, then assigns a group to a target account. Reproduce the aws_ssoadmin_account_assignment for each account or organizational unit (OU) mapping.

Because group membership comes from your IdP over SCIM, the IdP handles joiner, mover, and leaver, and access in EUSC updates automatically. No one receives direct access to the management account; all human access flows through IAM Identity Center permission sets assigned to non-management accounts.

data "aws_ssoadmin_instances" "this" {}
data "aws_partition" "current" {}

# Workload account the group is assigned to.
variable "analytics_workload_account_id" {
  type        = string
  description = "Account ID of the workload account to assign the permission set to"
}

locals {
  sso_instance_arn  = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0]
}

resource "aws_ssoadmin_permission_set" "analytics_operator" {
  name             = "AnalyticsOperator"
  description      = "Operate analytics workloads; no IAM or billing"
  instance_arn     = local.sso_instance_arn
  session_duration = "PT4H"
}

# Attach an AWS managed policy
resource "aws_ssoadmin_managed_policy_attachment" "analytics_ro" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
  managed_policy_arn = "arn:${data.aws_partition.current.partition}:iam::aws:policy/ReadOnlyAccess"
}

# Add a least-privilege inline policy (note the partition-aware ARNs)
resource "aws_ssoadmin_permission_set_inline_policy" "analytics_inline" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
  inline_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid      = "OperateAnalyticsData"
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
      Resource = [
        "arn:${data.aws_partition.current.partition}:s3:::analytics-*",
        "arn:${data.aws_partition.current.partition}:s3:::analytics-*/*"
      ]
      Condition = { StringEquals = { "aws:RequestedRegion" = "eusc-de-east-1" } }
    }]
  })
}

# Group for analytics operators.
# In production this is typically synced from your IdP via SCIM; here we
# manage it directly so the config is self-contained.
resource "aws_identitystore_group" "analytics" {
  identity_store_id = local.identity_store_id
  display_name      = "analytics-operators"
  description       = "Analytics operators"
}

# Assign the group to a workload account with the permission set
resource "aws_ssoadmin_account_assignment" "analytics_to_workload" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn
  principal_id       = aws_identitystore_group.analytics.group_id
  principal_type     = "GROUP"
  target_id          = var.analytics_workload_account_id
  target_type        = "AWS_ACCOUNT"
}

Cross-account roles within the EUSC partition work normally; this is how the logging and security-tooling accounts collect from workload accounts. Scope each trust policy to a specific principal and harden it with an external ID (for third-party tooling) and partition-aware ARNs.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:${AWS::Partition}:iam::<SECURITY_TOOLING_ACCOUNT_ID>:role/SecurityAuditCollector"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "eusc-sec-audit" },
      "ArnLike": { "aws:PrincipalArn": "arn:${AWS::Partition}:iam::*:role/SecurityAuditCollector" }
    }
  }]
}

A role in the aws partition can’t assume a role in aws-eusc (or the reverse).

A sovereign logging architecture requires three things:

• A single, immutable store for all audit and operational logs
• A central security account that runs detective controls and correlates findings
• A reliable, in-partition path that feeds everything into your SIEM without data ever leaving the boundary.

In the subsections that follow, we walk through each layer: Centralized log collection in the Log Archive account, Amazon GuardDuty and AWS Security Hub administration through the Security Tooling account, and the pull-based SIEM integration pattern that keeps telemetry inside the EUSC partition.

The Log Archive account holds the organization trail and a central log bucket as part of the landing zone. In the commercial AWS partition, global services like IAM route their CloudTrail events to us-east-1. In the EUSC, global services events are logged within the EUSC partition because the control plane is independent and located entirely within the EU.

GuardDuty and Security Hub are available in EUSC, but organization-wide auto-enable and some newer features might differ from commercial AWS features at any given time. Design the Security Tooling account as the delegated administrator where supported. If org-level auto-enable isn’t yet available, enable per-account through your IaC (AWS CloudFormation StackSets) so coverage is complete and code-managed. Treat the EUSC service and feature list as the source of truth and gate optional features behind a partition flag.

The AWS European Sovereign Cloud has its own sovereign AWS Direct Connect points of presence (PoPs), with dedicated networking infrastructure and connectivity from European providers, providing customers an autonomous network path into the partition. You terminate Direct Connect in a dedicated Network account and share connectivity to workload VPCs using Transit Gateway (with AWS RAM). A Direct Connect connection or Direct Connect gateway in the commercial partition can’t be extended into aws-eusc. To reach EUSC VPCs, you provision a separate Direct Connect connection that lands in the EUSC partition’s Network account. If your on-premises network already backhauls to AWS commercial Regions, you connect that network to EUSC with its own virtual interface or connection, or a site-to-site VPN. You don’t bridge the two AWS partitions through a shared Direct Connect gateway.

The following figure shows the recommended perimeter design in EUSC.

Figure 1: Recommended perimeter design in EUSC

The perimeter design includes:

• Centralized egress and inspection – Route workload egress through an inspection VPC in the Network account (gateway load balancer with your firewall of choice, or AWS Network Firewall. Keep workload VPCs private with no internet gateway.
• Private service access – Use VPC interface endpoints (VPCe) for AWS service calls so traffic stays on the AWS network within the partition. VPCe doesn’t cross partitions; expose any commercial-partition service to EUSC consumers over DX/VPN and an in-EUSC load balancer.
• DNS – EUSC has its own Amazon Route 53. For names that must resolve across clouds, use subdomain delegation or Resolver forwarding rules over your DX or VPN link rather than expecting hosted zones to be visible across partitions.
• Segmentation as code – Express segmentation with security groups referencing prefix lists and keep the EUSC IP ranges current from the partition’s published ip-ranges file in your firewall automation.

AWS Key Management Service (AWS KMS) is available in EUSC; use customer managed keys for all sensitive data stores and enforce their use with SCPs and key policies. Where your residency or operational-autonomy requirements call for it, evaluate AWS KMS external and imported key material options available in the partition.

For workloads where regulation mandates that key material never resides within the cloud provider’s infrastructure, configure an AWS KMS External Key Store (XKS) in the EUSC Region. The XKS proxy connects AWS KMS to your EU-based hardware security module (HSM) (on-premises or hosted with an EU trust service provider); all encrypt and decrypt operations are performed by your external key manager. Note the trade-offs: increased latency, reduced availability SLA, and added operational burden. Reserve XKS for the subset of data where regulatory or contractual obligations explicitly require it.

The EUSC Region has achieved SOC 2, BSI C5 Type 1 attestation, and seven ISO certifications, including ISO 27001, 27017, 27018, and 27701. Reference these in your data protection evidence packages when demonstrating encryption-at-rest and key management controls to EU regulators.

If you need to deploy existing images or binaries into EUSC (aws-eusc) from existing AWS commercial (aws) accounts, you can’t use cross-partition Amazon Elastic Container Registry (Amazon ECR) replication, Amazon Machine Image (AMI) copy, or Amazon Simple Storage Service (Amazon S3) replication. Instead, treat EUSC as an independent supply-chain destination:

• Container images – Build (or re-tag and re-sign) images and push to an Amazon ECR registry inside EUSC. ECR cross-Region replication works within the partition (useful as EUSC adds Regions or Local Zones), but the initial crossing from commercial is an explicit pipeline push using EUSC credentials. Sign images with a sovereign signing key and verify at deploy time.
• AMIs and images – Rebuild golden images in EUSC with EC2 Image Builder (run the pipeline natively in EUSC), or import virtual machine (VM) images using Amazon S3 in EUSC and aws ec2 import-image. There is no direct cross-partition AMI copy.
• Binaries and artifacts – Stage in an artifact bucket in the EUSC Shared Services account. Move packages across the boundary with aws s3 sync or AWS DataSync over your DX or VPN, or using controlled export, then distribute within the partition using in-partition S3 replication to other EUSC Regions or Local Zones as they come online.

# Push a container image to ECR inside EUSC (note the .eu endpoint).
# Credentials/profile must be for the aws-eusc partition.
aws ecr get-login-password --region eusc-de-east-1 --profile eusc-shared-services \
  | docker login --username AWS --password-stdin \
    111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu

docker tag company/runtime:7.x \
  111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x
docker push \
  111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x

Remember that endpoints and ARNs use amazonaws.eu in the EUSC partition. IAM service principals always use amazonaws.com regardless of partition.

Run a native deployment plane in EUSC (AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, or your existing tool deployed in-partition) in the Shared Services account, with cross-account deploy roles into workload accounts. If a commercial-partition continuous-integration system must deploy into EUSC, give it separate credentials for each partition; the clean pattern is OIDC federation with two trust configurations, one for each partition, because no cross-partition role assumption exists.

// Deploy role in an EUSC workload account, trusted by the EUSC Shared Services pipeline role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws-eusc:iam::<SHARED_SERVICES_ACCT>:role/PipelineDeployRole" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "EUSC-deploy" } }
  }]
}

For account vending and landing-zone-as-code, use Account Factory for Terraform (AFT) deployed in EUSC. AFT pipelines create accounts through AWS Control Tower, apply baseline guardrails, bootstrap the preceding partition-aware modules, and register OUs, giving you the accounts and account groups as code. Keep Terraform state for each partition in an in-EUSC Amazon S3 backend with an Amazon DynamoDB lock table; don’t share state across partitions.

The Landing Zone Accelerator on AWS (LZA) solution is an alternative deployment method that provisions a baseline security architecture and includes customizations for each partition, with consideration for service availability. A customized configuration baseline for European Sovereign Cloud was recently released and is accompanied by the LZA Compliance Workbook, which maps regional European security standards and international frameworks to over 200 security settings deployed by LZA.

Roll up within the EUSC organization, not across partitions. Enable consolidated billing in the EUSC management account and deliver AWS Data Exports (Cost and Usage Report 2.0) to an S3 bucket in a dedicated finance or governance account in the Security or Infrastructure OU.

Set permissions so workload teams can query the curated data in that account; no one should be able to access the management or payer account directly. You can’t replicate billing data into the commercial partition; the EUSC has a separate payer (billed in EUR through the EU contracting entity).

Architecting in the AWS European Sovereign Cloud is, in most respects, architecting a second well-run AWS landing zone with one organizing principle that resolves nearly every design question: it’s an independent partition. Centralization of governance, identity, logging, and billing is fully achievable, but within the EUSC partition. The boundaries you encounter between commercial AWS and EUSC—no cross-partition roles, peering, replication, or billing roll-up—are the sovereignty guarantees doing their job.

Build the foundation as code. Use an AWS Control Tower landing zone driven by AFT, IAM Identity Center permission sets and assignments in Terraform federated to your corporate IdP, an immutable central log store, customer managed encryption keys constrained to the sovereign Region, and a Network account terminating a dedicated Direct Connect. Add a CI/CD plane that pushes images and artifacts into the partition with per-partition credentials. Keep every ARN partition-aware and every optional service behind a feature flag, and the same modules will serve both clouds.

To accelerate your build with additional enablement from AWS, explore the LZA Universal Configuration for European Sovereign Cloud on GitHub, which packages many of the patterns described in this post into a ready-to-deploy baseline. To complement your deployment with compliance readiness, the LZA Independent Assessment Report for C5:2020 evaluates how LZA’s security baseline maps to C5:2020 technical requirements, and you can download the report and the LZA Compliance Workbook from AWS Artifact.

• AWS Security Reference Architecture (AWS SRA)
• AWS Well-Architected Framework and the Security Pillar
• AWS European Sovereign Cloud and European digital sovereignty and compliance overview
• Organizing your AWS environment using multiple accounts
• AWS Control Tower and Account Factory for Terraform (AFT)
• IAM Identity Center User Guide (EUSC)

If you have feedback about this post, submit comments in the Comments section below or start a thread on AWS re:Post.

AWS Security Token Service (AWS STS) has simplified session token size limits, giving you more room for your session policies and session tags. STS has replaced the packed policy size and the overall session token size limits with a single token size limit of 4,096 bytes. STS now reports session token size in API responses, Amazon CloudWatch metrics, and AWS CloudTrail events. By using STS, you can also generate session tokens of different sizes, so you can find the maximum token size that your infrastructure can support.

The 4,096-byte limit is the current maximum, not a permanent ceiling. AWS might increase the limit as new capabilities are added that require session tokens to carry more information.

In this post, you learn what has changed, what this change means for you, and what to do next.

AWS STS session-vending APIs, such as AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, GetSessionToken, and GetFederationToken, return temporary security credentials: an access key ID, a secret access key, and a session token. This change governs the session token, the opaque string that STS creates from the session policies and tags you pass plus the context that AWS adds.

Three things have changed.

• A single limit: Previously, STS enforced two size limits on the session token. It serialized and compressed your session policies and tags into a form called the packed policy, which had its own limit. The assembled token, which included the packed policy, had a separate overall limit. A request could fail against either limit, and both failures returned the same PackedPolicyTooLargeException, so you couldn’t tell which one you exceeded. STS now enforces a single limit: the assembled session token must fit within 4,096 bytes. The separate packed policy limit, which made failures hard to predict, has been removed. When a token exceeds the assembled session token limit, STS returns PackedPolicyTooLargeException. STS continues to use the same exception, so existing error-handling code works without an SDK update.
• Session token size is now reported. Every successful response from an STS session-vending API includes SessionTokenSize (which reports the session token size in bytes) and SessionTokenUtilization (which reports the percentage of the 4,096-byte limit consumed). STS also returns PackedPolicySize in every successful response for backward compatibility. PackedPolicySize now reports the same value as SessionTokenUtilization, enabling applications that use older AWS SDK versions to monitor utilization through this field. These response fields are also recorded in CloudTrail events. In CloudWatch, SessionTokenSize and SessionTokenMaxSize (the enforced limit) are published in the AWS/STS namespace.
• Testing is more straightforward: MinimumSessionTokenSize is a new optional parameter on the STS session-vending APIs. You can use it to increase a session token to at least the size you specify, up to 4,096 bytes. Use the parameter to find the maximum token size your infrastructure can handle.

How this affects you depends on your situation. The following scenarios cover the most common cases.

• If you have never hit a token size error: You’re unlikely to notice a change. Your tokens stay their current size and gain headroom. Over time they could become larger than your systems have handled before. We recommend you use MinimumSessionTokenSize to find the maximum token size your systems can handle. See the What to do next section for more details.
• If you’ve hit PackedPolicyTooLargeException before: Some requests that previously failed now succeed under the single limit. Review any workarounds you put in place specifically to avoid token size errors and decide whether you still need them. General best practices still apply: consistent tag casing and reused tag values compress more efficiently, and concise session policies keep the assembled token smaller. No code change is required for error handling. AWS STS still returns PackedPolicyTooLargeException when the assembled session token exceeds the limit, the same exception STS returned before this change.
• If your systems enforce their own size limits on credentials: If your application uses an AWS SDK to obtain temporary credentials and make AWS API calls, the SDK handles the session token internally, so token size doesn’t affect your code. Focus instead on systems that store or forward session tokens, such as load balancers, proxies, caches, and databases. These systems might have size limits that smaller tokens didn’t reach. For example, a database column defined as varchar(2048) can’t hold a 4,096-byte token. Review where you persist or pass session tokens, and identify the maximum token size each system supports. The next section shows how to test this.

We recommend the following three steps to prepare your systems for this change.

1. Validate the maximum token size your systems can handle. Use MinimumSessionTokenSize to find the maximum session token size each system in your infrastructure can handle. Knowing these limits helps you identify systems that might reject or truncate larger tokens. The 4,096-byte limit reflects today’s needs, not a permanent ceiling. It might grow as AWS introduces new capabilities such as additional context keys for new services, richer audit metadata, and larger cryptographic signatures as the industry transitions to post-quantum algorithms. Avoid hard-coding the current maximum into your systems and revisit any fixed size assumptions if the limit changes.
   

   Tip: AWS STS serializes and compresses your session policies and tags when assembling the token. Compression results vary based on the actual content, not just its length. Two sets of tags with identical character counts can produce different token sizes. This is why MinimumSessionTokenSize is a more reliable way to test your infrastructure than estimating from input length.

   aws sts assume-role \
     --role-arn arn:aws:iam::123456789012:role/MyRole \
     --role-session-name validation-test \
     --minimum-session-token-size 4096

   Start at 4,096 bytes to test against the largest possible token. If a system truncates or rejects it, lower the value to find the size your infrastructure supports, then raise that limit where you can. MinimumSessionTokenSize is available in the latest AWS SDK, AWS Command Line Interface (AWS CLI), and Tools for PowerShell versions. See the STS API Reference for details. If your AWS SDK or AWS CLI predates the parameter, update it to use this feature.

2. Monitor your session token size (recommended). If your infrastructure has size constraints, you can use monitoring to see tokens that are approaching your limit and act before a request fails. AWS STS reports size through three channels, each suited to a different need.
   • In the API response: Reading SessionTokenUtilization and SessionTokenSize from the response requires the latest AWS SDK version. You can also monitor token size through CloudWatch and CloudTrail without updating your SDK.

   {
     "Credentials": {
       "AccessKeyId": "REDACTED",
       "SecretAccessKey": "REDACTED",
       "SessionToken": "REDACTED",
       "Expiration": "2026-06-30T12:00:00Z"
     },
     "AssumedRoleUser": { "...": "..." },
     "PackedPolicySize": 61,
     "SessionTokenSize": 2532,
     "SessionTokenUtilization": 61
   }

   • In CloudWatch: STS publishes SessionTokenSize and SessionTokenMaxSize in the AWS/STS namespace. Use them to build dashboards and set alarms. Set your alarm against the size limit you found during testing, not the 4,096-byte maximum. The maximum is the same for every account, so your own infrastructure limit is the one that matters.

   The following figure shows the SessionTokenMaxSize and SessionTokenSize metrics graphed in the CloudWatch console.

   

   Figure 1: SessionTokenMaxSize and SessionTokenSizemetrics in the CloudWatch console

   • In CloudTrail: Each STS session-vending event records SessionTokenUtilization and SessionTokenSize for successful calls.

   {
     "eventName": "AssumeRole",
     "responseElements": {
       "credentials": { "...": "..." },
       "assumedRoleUser": { "...": "..." },
       "packedPolicySize": 61,
       "sessionTokenUtilization": 61,
       "sessionTokenSize": 2532
     }
   }

3. Use appropriate fields for monitoring session token utilization. AWS STS still returns PackedPolicySize in session-vending API responses and CloudTrail records for backward compatibility. The field now reports the same value as SessionTokenUtilization: the percentage of the 4,096-byte session token size limit consumed by the token. As a result, PackedPolicySize values might appear lower even when your token content has not changed.

   If your SDK exposes SessionTokenUtilization, use that field because its name reflects the value’s current meaning. If an earlier SDK does not expose SessionTokenUtilization, use PackedPolicySize to monitor the same utilization percentage without updating the SDK. We recommend you monitor SessionTokenSize for the token size in bytes.

You now have more room for session tags, tag values, and session policies in your AWS sessions. AWS STS enforces a single 4,096-byte session token limit, returns a clearer error message when a token exceeds it, and reports token size so you can track growth proactively. Validate your token-handling systems with MinimumSessionTokenSize, and watch SessionTokenUtilization and SessionTokenSize for ongoing visibility.

• AWS STS API Reference
• Request temporary security credentials
• Session policies
• Pass session tags in AWS STS

If you have feedback about this post, submit comments in the Comments section below.

Your consumer identity and access management (CIAM) system is the foundation of your customer experience. It’s how users sign in, access services, and engage with your applications. As your business scales across geographies, ensuring authentication is always available becomes a core architectural requirement. However, building multi-Region authentication has traditionally required complex custom replication solutions that synchronize user data, manage consistency, and handle failover, all adding significant operational overhead. Amazon Cognito simplifies this with multi-Region replication (MRR), which automatically replicates user pools across AWS Regions with near-real-time synchronization, built-in failover, and seamless sign-in, while keeping operational complexity and costs optimized.

In this post, we show you how to prepare your user pool for MRR, provide architectural decisions and reference architectures for business to consumer (B2C), business to business (B2B), and machine to machine (M2M) use cases, and practical guidance on implementing failover strategies.

Amazon Cognito MRR creates a replica user pool in another AWS Region (a replica Region) that shares the same user pool ID as your primary user pool. The primary user pool (the user pool in your primary Region) remains authoritative, and its configurations (app client IDs, client secrets), user data (attributes, hashed credentials, group memberships), and external identity provider (IdP) settings are replicated to the replica with eventual consistency.

The user pool in the replica Region (replica user pool) supports user authentication operations (such as sign-in, token generation and revocation) and read-only operations towards user pool configurations and user attributes (such as list users and groups and describe user pool configurations). Write operations against user pool configurations and updating user attributes aren’t enabled in the replica user pool and can only be made in the primary user pool. Amazon Cognito returns an Action temporarily unavailable error when using managed login, or an OperationNotEnabledException when using an AWS SDK for those operations. See Supported API operations in secondary Regions for a list of API operations supported in replica Regions.

JSON web tokens (JWTs) and active sessions are interoperable between Regions; for example, a refresh token issued by the primary Region is accepted in the replica Region to retrieve new ID and access tokens.

While this post primarily focuses on MRR architecture patterns and considerations, you can visit the following posts to learn more about MRR basics and the next-generation infrastructure behind it:

• Improve your application resilience with Amazon Cognito multi-Region replication
• Amazon Cognito unlocks advanced capabilities with next-generation infrastructure

In this section, we show you architectural decisions and preparation work for a successful MRR deployment.

Without MRR enabled, data is encrypted at rest with an AWS owned AWS Key Management Service (AWS KMS) key and encrypted in transit with TLS 1.2 and TLS 1.3 with hybrid post-quantum key exchange. Before enabling MRR, you must configure your user pool to use a customer managed key. This must be a symmetric multi-Region AWS KMS customer managed key.

Architectural considerations for your KMS key:

• You only need to set up one replica multi-Region key for your customer managed key because Amazon Cognito MRR supports only one additional replica Region.
• You own the administration of the customer managed key, including key policies, rotation, and deletion. You can also consider a key rotation strategy before enabling MRR or enable automatic key rotation.
• Follow least-privilege principles in KMS key policy and scope the KMS key to your user pool only. You can do so by applying a condition statement: kms:EncryptionContext:aws:cognito-idp:<userpool-arn>. See the data encryption section in the Amazon Cognito developer guide for a full example key policy.

In each ID and access tokens, Amazon Cognito includes a default Issuer claim in the JWT payload, referred as iss, to represent the identity provider that issued the token. The OpenID Connect (OIDC) specification dictates that the iss format must be a URL that uses https scheme and publishes a JSON metadata document about the identity provider available at the <iss>/.well-known/openid-configuration path. The metadata document must also include the JSON Web Key (JWK) document in the <iss>/.well-known/jwks.json path, which contains the signing keys to validate the token signatures for its integrity.

The original issuer type follows the format as https://cognito-idp.<region>.amazonaws.com/<userpool_id>. However, this issuer URL format and the OIDC well-known metadata are regional resources. As part of the MRR capability, Cognito introduces a new multi-Region OIDC issuer type, the updated issuer, and follows the format as https://issuer-cognito-idp.<region>.amazonaws.com/<userpool_id>. This new updated issuer type replaces the original single Region type and maintains availability of the issuer endpoint regardless of the state of primary or replica Region.

Based on the issuer URL format you select, your OpenID Connect discovery endpoint is hosted at  <iss>/.well-known/openid-configuration and your JSON Web Key Set (JWKS) endpoint at <iss>/.well-known/jwks.json. Both original type and updated type are supported with the Amazon Cognito MRR capability. You can change the issuer type at any stage in your MRR journey, and the newly issued tokens, including those generated by refresh tokens, will reflect the most current issuer type configurations.

We recommend adopting the updated issuer type. With the updated issuer type, the OpenID Connect discovery document and JWKS endpoint remain consistent and available regardless of which Region is servicing requests. This means your applications can always fetch signing keys for token verification, even during a regional impairment.

To adopt the updated issuer type, update your applications and downstream dependencies to validate against the new updated iss value. If you use the aws-jwt-verify library, update to v5.2.1 or later that supports updated issuer type. Plan this as a coordinated deployment; existing ID and access tokens with the original issuer type remain valid and accepted by Amazon Cognito endpoints until they expire. When using an existing refresh token to exchange for a new set of ID and access tokens, new tokens always carry the current issuer format configuration at the time of token refresh operation, providing interoperability across two issuer formats.

If you can’t immediately adopt the multi-Region issuer—for example, because downstream services or third-party integrations validate the iss claim against a hard-coded original format pattern—you can enable MRR while continuing to use the original issuer type. However, in this configuration the OIDC discovery endpoint and JWKS endpoint are tied to a single Region and might be unavailable during a regional impairment. Your multi-Region application might not be able to fetch public keys dynamically and validate token signatures. To mitigate this, it’s a good practice to implement a JWKS caching strategy in your token verification layer. Cache the signing keys locally (respecting the Cache-Control headers) so your applications can continue to validate tokens using cached keys when the JWKS endpoint is unreachable. This approach lets you benefit from MRR for user authentication while maintaining token verification continuity until you’re ready to complete the issuer migration. To learn more about the original and updated issuer types, see the Amazon Cognito user pools as an OIDC issuer section of the developer guide.

Amazon Cognito user pools support several integrations with AWS services for extended customization functionalities. Those AWS services are regional services and must be configured independently in the replica Region, including:

• AWS Lambda – Lambda triggers (for example, pre-authentication, pre-token generation, and others) are invoked in different authentication stages and should be deployed in the replica Region and attached to the replica user pool to match customized behaviors in the primary user pool. When deploying Lambda triggers, you can adopt the same logic for both primary and replica user pools and access to downstream resources or set up a different logic to characterize different behaviors when requests are served in the replica Region.
• AWS WAF – WAF web access control lists (web ACLs) are associated to protect the user pool from unwanted requests. When accepting traffic to the replica user pool, create matching WAF web ACLs in the replica Region.
• Amazon Simple Notification Service (Amazon SNS) – If you send text messages (for example, SMS-based multi-factor authentication (MFA), passwordless authentication, or SMS notifications), configure Amazon SNS in the replica Region. SNS requires additional set up (origination identities, spending limits) in each Region, and sender ID registration time depends on several factors.
• Amazon Simple Email Service (Amazon SES) – If you use Amazon SES for email delivery, verify sending domains and email addresses in the replica Region and configure your replica user pool accordingly.
• Amazon CloudWatch – If you export user activity logs from Amazon Cognito to a CloudWatch log group, or monitor service quotas in CloudWatch, configure alarms and analytics accordingly.

Use infrastructure-as-code tools like AWS CloudFormation or AWS Cloud Development Kit (AWS CDK) to maintain consistent configurations and deployments across Regions and environments. You should also monitor for any configuration drifts between assets.

For authentication use cases that rely on managed login and OAuth 2.0 endpoints—including federated authentication and M2M authorization—Amazon Cognito supports automatic failover to the replica Region with an Amazon Route 53 health check. Cognito uses the health status of Route 53 health check to control whether traffic routes to the primary or replica user pool. The health check can be set up to monitor the health of an endpoint, a CloudWatch alarm, or a calculated number of other health checks, so you determine what triggers a healthy or unhealthy state and can adjust traffic routing as needed.

Both the Amazon Cognito prefix domain (for example, auth.us-east-1.amazoncognito.com) and custom domain (for example, auth.example.com) support automatic domain failover. Your domain serves as the single entry point for the user pool OAuth 2.0 endpoints and directs traffic to the managed login pages. Cognito automatically fails over domain traffic to the replica Region when a Route 53 health check becomes unhealthy and fails back to the primary Region when the check is healthy. You don’t need to create another prefix domain in the replica user pool for failover use cases.

With the automatic failover capability, you can use a single domain to serve external IdP configurations, including redirect URIs and SAML assertion consumer URLs. For example, use https://auth.example.com/saml2/logout to send SAML 2.0 sign-out responses. Because the domain can serve traffic to both the primary and replica Regions and remains unchanged across Regions, your external IdP configurations stay consistent across Regions, and existing federated users continue to authenticate without disruption. This means that you can enable MRR without having to contact external IdP admins to update configurations; all existing configurations will continue to work.

For SDK-based authentication use cases without managed login, a custom domain isn’t strictly required. We recommend configuring a custom endpoint for SDK requests to simplify failover orchestration, so you don’t have to modify the Region parameter in the SDK configuration. Behind your custom endpoint, you can use the same Route 53 health check or a custom load balancing strategy to proxy API requests to primary or replica Region endpoints. You might also consider load balancing user authentication traffic, by referring to an X-Amz-Target HTTP header (for example, X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth), to both the primary and replica Regions, while keeping user sign-up operations in the primary Region. If you use both managed login and SDK authentication in the same user pool, you can consider using the custom domain as the custom endpoint of the SDK for a streamlined operation, where Route 53 health check initiates failover and failback between the primary and replica Regions.

Time-Based One-Time Password (TOTP) MFA isn’t supported in replica user pools. Users configured to use TOTP MFA must authenticate through the primary Region. If your application relies on TOTP as a second factor, this limitation requires careful planning because you want to enable an alternative MFA for your users, such as SMS OTP, email OTP, or passkey.

When you activate a replica user pool, you gain a separate set of default quotas in the replica Region. Previously reserved higher quotas for your user pool in the primary Region aren’t carried over to the replica Region.

When selecting a replica Region for your user pool, consider your organization’s data sovereignty and residency requirements, as user identity data will be replicated to and stored in that Region. For guidance on navigating compliance, continuity, and control obligations that may influence your Region selection, see Practical digital sovereignty: Navigating the pillars of compliance, continuity, and control.

In this section, we show you reference architectures for common authentication patterns using the Amazon Cognito MRR capability. Each architecture demonstrates how Cognito MRR works with different authentication use cases.

Amazon Cognito managed login provides a fully managed authentication UI that handles sign-in, sign-up, and federation flows. With MRR, managed login endpoints are served from the healthy user pool based on your Route 53 health check configuration. Managed login also includes OAuth 2.0 endpoints and can be used with local Cognito accounts and federated users. Figure 1 depicts a reference architecture for using managed login to authenticate Cognito users.

Figure 1: Cognito MRR reference architecture for managed login and federation use cases

When using Amazon Cognito with managed login, the process flow is:

1. The user visits the application and is redirected to the managed login to begin the authentication flow.
2. Managed login uses the Route 53 health check to control traffic routing.
3. If the health check returns a healthy status, all traffic to the managed login flows to the primary Region user pool for user authentication.
4. For a federated user, the primary Region user pool redirects the user to a federated IdP or social IdP for authentication. After successful authentication, Amazon Cognito creates or updates user attributes depending on whether it’s a new user signing in for first time or an existing user.
5. If the health check returns an unhealthy status, all traffic to the managed login flows to the replica Region user pool. Cognito users will authenticate against the replica user pool.
6. The replica Region user pool endpoint redirects federated users to external IdPs. However, any user creation or attribute update against replica user pool will fail until the health check returns healthy and traffic routes back to the primary Region.

In an M2M architecture, services authenticate using the OAuth 2.0 client credentials grant. This flow doesn’t involve users; instead, backend services exchange client credentials for access tokens.

Figure 2: Cognito MRR reference architecture for machine-to-machine use case

The authentication flow is:

1. Application clients send a POST request to the Amazon Cognito /token endpoint with client credentials.
2. Managed login uses the Route 53 health check to determine whether traffic should flow to the primary or replica user pool.
3. If the health check returns a healthy status, traffic to the /token endpoint will flow to the primary Region user pool.
4. If the health check returns an unhealthy status, traffic to the /token endpoint will flow to the replica Region user pool. After the health check returns to a healthy status, traffic will return to routing to the primary user pool.

For applications that use AWS SDK or Amazon Cognito APIs directly (rather than through managed login), the authentication flow is embedded in your application code. This gives you more control over the user experience but requires additional considerations for failover.

Figure 3: Cognito MRR reference architecture for SDK use cases

The process shown in Figure 3 is:

1. The user visits the application and signs in through a custom UI (using APIs or SDKs).
2. (Optional) An Amazon Route 53 health check is configured to perform a health check against regional proxy endpoints and determine traffic routing. You can also use a custom health check or your DNS resolver to make traffic routing determinations.
3. If the health check returns a healthy status, all traffic to the proxy endpoints will flow to the primary Region proxy for user authentication. You can also choose to load balance user authentication traffic across both the primary and backup Regions.
4. The primary Region Amazon API Gateway proxy forwards user requests to the Amazon Cognito regional endpoint.
5. If the health check returns an unhealthy status, all traffic will flow to the replica Region proxy.
6. The replica Region API Gateway proxy begins forwarding user requests to the Amazon Cognito regional endpoint until the health check returns to healthy status.

In an SDK-based architecture, Amazon Cognito regional endpoints can also be called directly. You can also set up custom routing to use replica Region endpoints to load balance user authentication requests by routing read-only requests to both the primary and replica Region endpoints while keeping write requests in the primary Region.

Now that you’ve set up multi-Region replication with Amazon Cognito, the next step is to test and monitor your multi-Region configuration. In this section, we walk through strategies for monitoring your endpoints, determining when to trigger failover, and testing your failover readiness.

Failover for Managed Login and all OAuth 2.0 flows is driven by Amazon Route 53 health checks associated with your Amazon Cognito prefix or custom domain. You’re responsible for what determines the state of this health check. The health check isn’t tied to your DNS CNAME record but is the signal that tells Amazon Cognito whether to route traffic to the primary or replica Region for all managed login endpoints. When the health check fails, Amazon Cognito routes traffic to the replica user pool. When the health check recovers, traffic is restored to the primary user pool.

A practical approach to get started to build a health check:

1. Create a synthetic canary – Use Amazon CloudWatch Synthetics to run a canary that periodically exercises an actual authentication flow against your primary Region. For example, the canary can perform a client credentials token request against your Amazon Cognito domain’s /oauth2/token endpoint or execute a full AdminInitiateAuth API call with test credentials. This validates that the end-to-end authentication path is functional, not just that an endpoint is responding.
2. Tie the canary to a CloudWatch alarm – Configure a CloudWatch alarm on the canary’s SuccessPercent CloudWatch metric. Set a threshold that accounts for transient errors (for example, alarm when success drops below 90% for three consecutive evaluation periods).
3. Connect the alarm to your Route 53 health check (optional) – Create a Route 53 health check that monitors the CloudWatch alarm. When the alarm enters the ALARM state, the health check fails, and Amazon Cognito routes traffic to the replica user pool. If you prefer to rely on human intervention, skip this step and instead configure the CloudWatch alarm alert your operations team to manually invert the health check.

After you have your health check, associate it with your Amazon Cognito domain using the UpdateUserPoolDomain API or the Amazon Cognito console.

Before implementing failover, consider how your authentication layer relates to the rest of your application stack. There are two common patterns:

• Authentication-only failover – Your application remains in a single Region, but authentication traffic fails over to the Amazon Cognito replica if only the primary Region’s authentication service is impaired. This works when your application can continue operating with tokens already issued (for example, cached JWTs, active sessions) and when downstream APIs don’t depend on the same Region as your user pool. Consider this option when the rest of your stack has its own availability model.
• Full-stack failover – Your entire application—compute, data stores, APIs, and authentication—fails over to a replica Region. In this model, Amazon Cognito MRR is one component of a broader multi-Region architecture where authentication flows have tight dependencies on regional resources (such as Lambda triggers calling regional Amazon DynamoDB tables, or post-authentication logic writing to a regional event bus) that must be co-located with the user pool.

Use Amazon Application Recovery Controller (ARC) to coordinate failover across all components with a single action. ARC provides three capabilities that are particularly relevant for multi-Region authentication architectures:

• Routing controls – Extremely reliable data plane controls that let you shift DNS traffic across Regions, with safety rules that prevent partial or unintended failovers (for example, preventing you from failing over authentication without also failing over the dependent API layer).
• Readiness checks – Continuous monitoring of resource quotas, capacity, and network routing policies in your secondary Region, so you have confidence that the replica environment—including your Amazon Cognito replica user pool and its regional dependencies—can handle production traffic before you failover.
• Region switch – Centralized, automated, and observable multi-Region recovery orchestration across multiple AWS accounts and resources, so you can execute a coordinated failover of your Cognito user pool alongside databases, compute, and APIs in a single recovery plan.

ARC is particularly valuable when your Amazon Cognito Lambda triggers, WAF rules, SNS and SES configurations, and downstream services all need to switch Regions in lockstep. Rather than managing failover for each component independently, you can use ARC to define a single recovery group that treats your authentication stack and application stack as one unit. To learn more about the capabilities and use cases of ARC, see Introducing Amazon Route 53 Application Recovery Controller.

The right choice depends on your recovery scope. Map the dependencies in your authentication flow: if your Lambda triggers call regional DynamoDB tables or your post-authentication logic writes to a regional event bus, those tight couplings point to full-stack failover. If your application validates tokens independently and doesn’t make real-time calls back to Amazon Cognito after token issuance, authentication-only failover keeps both your blast radius and operational overhead smaller.

Triggering failover too aggressively risks unnecessary disruptions; too conservatively risks a drop in desired availability. Here are the factors to balance:

• Monitor authentication flow health – Validate that critical flows are functioning, including managed login endpoint availability and token endpoint responses.
• Use composite health checks – Combine multiple signals. For example, require both the managed login and token endpoints to be healthy.
• Set appropriate thresholds – Configure failure thresholds (for example, three consecutive failures) to distinguish transient errors from genuine impairments.
• Consider downstream dependencies – Factor in Lambda triggers, external IdPs, and other regional services.
• Client side retry logic – For SDK-based single-page application (SPA) architectures, consider implementing client-side retry logic with Region failover. When the primary Region is unavailable, your application should detect the failure and redirect authentication of API calls to the replica Region’s Amazon Cognito endpoint.

Understanding and determining the recovery time objective (RTO) and recovery point objective (RPO) should also be the key factor in determining when and why to failover. See the Establishing RPO and RTO Targets for Cloud Applications blog post to learn more.

If using Route 53 health check, start by manually inverting your Route 53 health check during a maintenance window. In the Route 53 console, enable Invert health check status to force the health check into a failed state; this triggers failover to the replica Region without requiring any infrastructure changes. While traffic is routing to the replica Region, validate that your critical authentication flows (sign-in, token refresh, federation) work correctly, then disable the inversion to restore traffic to the primary. This test confirms your end-to-end failover path is functional.

When you’re confident in the basic failover path, graduate to more realistic failure simulations with AWS Fault Injection Service (FIS). Create FIS experiment templates that disrupt your primary Region’s Amazon Cognito dependencies; for example, block network access to a dependent resource or inject latency into downstream API calls. Use FIS stop conditions (guardrails) to automatically halt experiments if unexpected impacts are detected. These experiments validate not just that failover triggers correctly, but that your replica Region handles real authentication load under degraded conditions.

We recommend conducting failover tests on a predefined and regular cadence and after any significant changes to your authentication architecture. Document your runbooks and make sure your operations team is familiar with both the failover and recovery procedures.

In this post, we built on the foundational knowledge of the Amazon Cognito MRR capability and showed you how to architect resilient authentication for real-world use cases:

• Preparation considerations – Multi-Region KMS keys, OIDC issuer transitions, regional dependencies, and TOTP MFA considerations
• Reference architectures – B2C, B2B, and M2M patterns using managed login, plus SDK-based approaches
• Failover strategies – Route 53 health checks, ARC integration, and testing with health check inversion and AWS FIS

To get started, make sure your user pool is on the Essentials or Plus feature plan, configure your multi-Region KMS key and OIDC issuer, and create your first replica. For step-by-step setup instructions, see Multi-Region replication for user pools

If you have feedback or thoughts about this post, submit comments below. If you have questions, start a new thread on Amazon Cognito re:Post or contact AWS Support.

The principle of least privilege is straightforward to articulate but challenging to maintain at scale. When teams first deploy applications to AWS, they often grant broader permissions than strictly necessary; it’s faster to get things working, and the plan is always to tighten permissions later. But later rarely comes. Permissions accumulate, AWS Identity and Access Management (IAM) principals that once needed broad access for initial deployment retain those permissions long after they’re necessary, and some principals stop being used entirely. Even small teams face this challenge—permission reviews aren’t a one-time task but an ongoing operational burden that demands automation.

AWS IAM Access Analyzer addresses detection and recommendation. It identifies unused permissions across IAM roles and users: actions that haven’t been exercised, services that haven’t been accessed, and principals that aren’t being assumed at all. For each finding, it generates a recommended policy with the excess permissions removed. Security teams can see exactly what to fix, but manual remediation doesn’t persist. A security engineer can right-size a role today, but if that role is defined in an AWS CloudFormation template or AWS Cloud Development Kit (AWS CDK) stack, the next deployment restores the original permissions. The fix must live where the role is defined, and not every role starts in the same place. Some are managed through infrastructure-as-code (IaC), where remediation means updating source code and deploying through a pipeline. Others were created manually through the AWS Management Console and have no code representation. And some principals aren’t being used at all and need a controlled decommission path. Each scenario requires a different remediation strategy.

This post walks through an automated remediation workflow that bridges the gap between detection and action. Instead of findings accumulating in a dashboard waiting for someone to investigate, the automation classifies each role by how it was created and produces a ready-to-review remediation artifact: a pull request with production-ready CDK code and a plain-English explanation for IaC-managed roles, an issue with the recommended policy and step-by-step IaC migration guidance for manually created roles, or a soft-disable issue with a monitored decommission plan for unused principals. Each output flows through your existing code review and issue tracking processes—the same workflows your teams already follow. By the end of this post, you’ll have a pattern that converts IAM Access Analyzer findings into tested, deployable code changes rather than a growing backlog of security tickets.

Unused IAM permissions increase the attack surface. Removing unused permissions limits the actions available to any compromised credentials, reducing potential impact. Roles that aren’t being assumed represent unused resources; removing them simplifies your IAM inventory and reduces potential access paths that aren’t actively monitored.

The challenge isn’t knowing what to fix. As we said earlier, Access Analyzer provides both the findings and the recommended policies. The challenge is acting on that knowledge consistently across your environment. Each finding requires context:

• What the role does
• Who created the role
• Determining if the permission is unused or used infrequently
• If the role is managed in a CloudFormation stack, or was created through the console

Multiply this by hundreds of roles and security teams face a backlog that grows faster than they can address it.

Manual remediation compounds the problem. A security engineer can right-size a role directly in the console, but that fix is fragile. If the role is defined in an IaC template, the next deployment restores the original permissions. If it was created manually, there’s no record of what changed or why, and no easy way to revert if the change causes issues.

This is where IaC changes the equation. When roles are defined in code, remediation means updating that code. Changes flow through pull requests, are reviewed by the team that owns the role, and deploy consistently across environments. The fix becomes permanent, not a point-in-time correction that drifts back on the next deployment. And because every change is tracked in version control, teams can confidently remove permissions knowing they can revert if something breaks. That safety net matters; it’s often the difference between a team acting on a finding and leaving it in the backlog.

The solution automates remediation by connecting four capabilities: IAM Access Analyzer for detection and policy recommendations, CloudTrail for role attribution, Amazon Bedrock for CDK code generation and plain-English explanations, and your existing continuous integration and delivery (CI/CD) pipeline for remediation execution. The workflow operates on a core principle: every IAM role has an origin, and that origin determines the remediation path.

Figure 1 shows the solution architecture: Amazon EventBridge triggers an AWS Lambda orchestrator on a daily schedule. The Lambda orchestrator integrates with IAM Access Analyzer, CloudTrail, Amazon Bedrock, and Amazon CloudWatch. Each finding is routed to one of three remediation paths: a pull request for IaC-managed roles, an issue for manually created roles, and a soft-disable issue for unused roles.

Figure 1: The daily remediation workflow; from scheduled trigger to the three role-based remediation paths

On each scheduled run, the automation retrieves active findings from IAM Access Analyzer and queries CloudTrail to determine how each role was created. Roles created through CloudFormation or AWS CDK have a traceable origin: the service principal, stack name, and originating repository. Roles created manually through the console have a different origin: the IAM user who created them and the timestamp. This distinction drives the remediation strategy.

For IaC-managed roles, the automation retrieves the IAM Access Analyzer-recommended policy and uses Amazon Bedrock to wrap it in production-ready CDK code that includes the role definition and policy statements and imports what your CI/CD pipeline needs to deploy the update. It then creates a pull request in the originating repository. The pull request (PR) includes the updated CDK code, a policy diff showing exactly which permissions are being removed, and a plain-English explanation of the changes, for example, “This change removes write access to S3, keeping only read and list permissions.” Your existing code review process evaluates the change, and after being merged, the fix deploys consistently across environments.

For manually created roles, the automation creates an issue that includes the IAM Access Analyzer-recommended policy with unused permissions removed, a diff highlighting the changes, and an Amazon Bedrock-generated explanation of what the permission changes accomplish. The issue also provides guidance on importing the role into your IaC codebase. This gives teams an immediate remediation path while encouraging long-term governance through IaC adoption.

For roles that aren’t being assumed at all, the automation takes a more cautious approach. Instead of taking direct action, it creates an issue recommending a soft-disable workflow: attach a deny-all policy to the role, monitor for 30 days to confirm no workload depends on it, then delete. The issue provides the steps and context, the team executes the decommission through their preferred process, whether that’s a console change, an AWS Command Line Interface (AWS CLI) script, or a PR removing the role from the IaC. This controlled decommission path reduces the risk of removing a role that’s used infrequently or seasonally.

The solution supports both single-account and organization-wide deployment. In single-account mode, it uses an ACCOUNT_UNUSED_ACCESS analyzer to process findings for one account. In organization mode, it uses an ORGANIZATION_UNUSED_ACCESS analyzer deployed in a delegated administrator account, which generates findings across all member accounts from a single vantage point. The Lambda function automatically detects which analyzer type is available and extracts the account ID from each finding’s resource Amazon Resource Name (ARN), so role attribution and remediation routing work the same way regardless of scope.

This three-path strategy acknowledges operational reality. Not all roles start in IaC, not all unused roles are safe to delete immediately, and forcing immediate migration isn’t always practical. The solution provides a clear path forward for each scenario: remediate IaC roles through code, give teams actionable recommendations for manually created roles, and safely decommission what’s no longer needed. Over time, your infrastructure becomes increasingly code-driven, and remediation becomes a routine part of your CI/CD process rather than a manual security task.

Consider a company—call them AnyCompany—running 200 IAM roles across three AWS accounts. Some roles were created through AWS CDK stacks during initial deployment. Others were created manually through the console by engineers who needed quick access during incident response or prototyping. A handful haven’t been assumed in over 6 months. AnyCompany’s security team wants to act on their IAM Access Analyzer findings, but each role requires different handling. The solution’s architecture addresses this by routing each finding through a classification and remediation pipeline.

Figure 2 shows how each IAM Access Analyzer finding is processed:

1. The finding is first checked against exclusions and excluded findings are skipped.
2. Remaining findings are split by type: UnusedPermission findings retrieve a recommended policy from IAM Access Analyzer and then query CloudTrail for role origin, while UnusedIAMRole findings follow the unused role path.
3. By origin, IaC-managed roles generate AWS CDK code using Amazon Bedrock and create a pull request.
4. Manually created or unknown-origin roles create an issue with the recommended policy and IaC migration guidance.
5. Unused roles create a soft-disable issue to deny-all, monitor for 30 days, then delete.
6. All paths publish CloudWatch metrics.

Figure 2: Detailed component interactions—the orchestrator’s five steps, its four service integrations, and the three remediation paths

The rest of this section walks through each component using AnyCompany’s roles as examples.

Before processing any finding, the Lambda function loads an exclusion configuration and checks whether the role should be skipped. This prevents the automation from creating remediation items for roles that legitimately need broad permissions.

{
  "excluded_roles": [
    "arn:aws:iam::123456789012:role/BreakGlassRole",
    "arn:aws:iam::123456789012:role/ServiceLinkedRole"
  ],
  "excluded_permissions": [
    "iam:*",
    "sts:AssumeRole"
  ],
  "excluded_by_tag": {
    "NoRemediation": ["true"],
    "CriticalService": ["true"]
  },
  "min_unused_days": 30
}

AnyCompany excludes their break-glass role (used only during incidents), any service-linked roles, and roles tagged CriticalService. The min_unused_days threshold prevents false positives from seasonal workloads; a role that ran a quarterly batch job 25 days ago won’t generate a finding.

IAM Access Analyzer generates two types of findings relevant to this solution. UnusedPermission findings identify roles with permissions that haven’t been exercised within the analysis period. UnusedIAMRole findings identify roles that haven’t been assumed at all. The Lambda function queries both finding types separately because they follow different remediation paths.

The Lambda function auto-detects the analyzer type at startup. When ANALYZER_SCOPE is set to organization, it checks for an ORGANIZATION_UNUSED_ACCESS analyzer first and falls back to ACCOUNT_UNUSED_ACCESS if none exists. If multiple analyzers of the same type exist in the account, the Lambda function selects the first active analyzer returned by the API. To target a specific analyzer, set the ANALYZER_ARN environment variable explicitly. With an organization-level analyzer, findings include roles from all member accounts. The Lambda function extracts the account ID from each finding’s resource ARN (for example, account 111122223333 from arn:aws:iam::111122223333:role/MyRole) and carries that context through the entire pipeline: attribution, remediation, and issue or PR creation all include the originating account.

For UnusedPermission findings, the Lambda function calls GenerateFindingRecommendation to initiate policy generation, then retrieves the IAM Access Analyzer-recommended policy through the GetFindingRecommendation API. This is a key integration point: IAM Access Analyzer provides the right-sized policy with unused permissions removed, so the automation doesn’t need to generate policies itself.

Here’s what a typical finding looks like for one of AnyCompany’s application roles:

{
  "id": "a1b2c3d4-5678-90ab-cdef-example11111",
  "resource": "arn:aws:iam::123456789012:role/AnyCompanyOrderProcessorRole",
  "findingType": "UnusedPermission",
  "analyzedAt": "2026-03-01T00:00:00Z",
  "unusedPermissions": [
    { "action": "s3:PutObject", "lastAccessed": null },
    { "action": "s3:DeleteObject", "lastAccessed": null },
    { "action": "s3:PutBucketPolicy", "lastAccessed": null },
    { "action": "dynamodb:DeleteItem", "lastAccessed": null }
  ],
  "activePermissions": [
    { "action": "s3:GetObject", "lastAccessed": "2026-02-28T14:30:00Z" },
    { "action": "s3:ListBucket", "lastAccessed": "2026-02-28T14:30:00Z" },
    { "action": "dynamodb:Query", "lastAccessed": "2026-02-28T12:00:00Z" }
  ]
}

The OrderProcessorRole has write and delete permissions for Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB, but only uses read operations. The IAM Access Analyzer recommendation removes the four unused actions while preserving the three active ones.

For UnusedIAMRole findings, no recommendation is needed: the role isn’t being assumed at all, so the remediation is to disable or delete it. The Lambda function caps the number of unused role issues per run (configurable using MAX_UNUSED_ROLE_ISSUES, default 10) to avoid overwhelming teams with a flood of issues on the first execution.

For each finding, the Lambda function queries CloudTrail to determine how the role was created. The CreateRole event contains the information needed to classify the role’s origin.

An IaC-created role looks like this in CloudTrail:

{
  "eventName": "CreateRole",
  "userIdentity": {
    "type": "AWSService",
    "invokedBy": "cloudformation.amazonaws.com"
  },
  "requestParameters": {
    "roleName": "AnyCompanyOrderProcessorRole"
  },
  "userAgent": "cloudformation.amazonaws.com"
}

The cloudformation.amazonaws.com service principal and user agent tell the automation this role was created through a CloudFormation or AWS CDK deployment. The Lambda function then looks up the role’s tags to find the originating repository (stored in a Repository tag set during deployment).

A manually-created role looks different:

{
  "eventName": "CreateRole",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "jstiles"
  },
  "requestParameters": {
    "roleName": "AnyCompanyIncidentResponseRole"
  },
  "userAgent": "console.amazonaws.com"
}

Here, the IAMUser type and console.amazonaws.com user agent indicate someone created this role through the console. Roles created through the AWS CLI show a similar pattern: the IAMUser type with a user agent like aws-cli/2.x.x. The automation classifies both console and AWS CLI-created roles as manually created, because neither has an IaC origin that can be updated programmatically. The automation captures the username and timestamp for the remediation issue.

When the Lambda function processes findings from an organization-level analyzer, the role might live in a different account than the one running the function. The automation handles this by assuming a cross-account role (configurable using CROSS_ACCOUNT_ROLE_NAME, defaulting to OrganizationAccountAccessRole) in the member account, then querying that account’s CloudTrail and IAM APIs for the CreateRole event. If the cross-account assume fails—because the role doesn’t exist in that account or permissions aren’t configured—the automation falls back gracefully, classifying the role as unknown origin and creating an issue with the account ID and available context. This approach helps the automation produce an actionable output for findings even when attribution is incomplete.

For IaC-managed roles with UnusedPermission findings, the Lambda function retrieves the IAM Access Analyzer-recommended policy and sends it to Amazon Bedrock to generate production-ready AWS CDK code. This is an important distinction: IAM Access Analyzer decides what the policy should be, and Amazon Bedrock wraps that policy in the AWS CDK constructs, imports, and resource definitions that the CI/CD pipeline needs to deploy the update.

The prompt instructs Amazon Bedrock to convert the recommended policy to AWS CDK code exactly as provided, with no modifications:

Generate Python CDK code that creates/updates the role with the
RECOMMENDED policy exactly as provided. Include proper imports
(aws_cdk, aws_iam), use CDK best practices (PolicyStatement,
proper resource ARNs), and add tags: ManagedBy=CDK,
RemediatedBy=AccessAnalyzer.

IAM Access Analyzer generates recommendations for both inline policies and customer managed policies. When a managed policy has partially unused permissions, the recommendation contains the full right-sized policy. The automation wraps this in AWS CDK code as an iam.ManagedPolicy construct. Note that if a managed policy is shared across multiple roles, the recommendation applies to the specific role’s usage pattern. In this case, the automation generates an issue for manual review rather than a PR, because modifying a shared policy could affect other roles.

The generated code goes through a validation step before inclusion in any PR. The Lambda function compiles the Python code to check for syntax errors and verifies that required AWS CDK patterns (iam, PolicyStatement) are present. If validation fails, the finding is logged as an error rather than creating a broken PR.

The solution doesn’t currently invoke the IAM Access Analyzer ValidatePolicy API to check the generated policy for errors or overly permissive statements. However, this is a natural extension point. Teams can add a validation step that calls ValidatePolicy on the Amazon Bedrock-generated policy before including it in a PR, detecting issues like missing resource constraints or invalid action names.

Amazon Bedrock also generates a plain-English explanation of the policy changes. For AnyCompany’s OrderProcessorRole, the explanation might read:

“The role currently has full S3 write access and DynamoDB delete permissions, but only uses read operations. Removing s3:PutObject, s3:DeleteObject, s3:PutBucketPolicy, and dynamodb:DeleteItem reduces the scope of impact if credentials are compromised, while preserving the s3:GetObject, s3:ListBucket, and dynamodb:Query permissions the application needs.”

The solution uses the Anthropic Claude Sonnet model on Amazon Bedrock for CDK code generation (where accuracy matters) and Claude Haiku on Amazon Bedrock for explanations (where speed and cost efficiency matter more).

The Lambda function evaluates each finding’s origin and routes it to one of three remediation paths.

Path 1: IaC-managed roles (pull request) – For AnyCompany’s OrderProcessorRole, the automation creates a PR in the originating repository. The PR includes:

• The Amazon Bedrock-generated AWS CDK code implementing the IAM Access Analyzer-recommended policy
• A policy diff showing exactly which permissions are being removed
• The plain-English explanation of what the changes accomplish
• Labels (security, iam-remediation, automated) for filtering and tracking

The team that owns the role reviews the PR through their normal code review process. Once merged, the fix deploys consistently across environments through the existing CI/CD pipeline.

Path 2: Manually-created roles (issue) – For AnyCompany’s IncidentResponseRole, the automation creates an issue that includes the Access Analyzer-recommended policy with unused permissions removed, a diff highlighting the changes, an Amazon Bedrock-generated explanation, and step-by-step guidance on importing the role into IaC. This gives the team an immediate remediation path (apply the recommended policy) while encouraging long-term governance through IaC adoption.

Path 3: Unused roles (soft-disable issue) – For roles that haven’t been assumed at all, the automation creates an issue recommending a three-stage decommission workflow: attach a deny-all policy to the role, monitor for 30 days to confirm no workload depends on it, then delete. This controlled approach reduces the risk of removing a role that’s used infrequently or seasonally – if something breaks during the monitoring period, removing the deny-all policy restores access immediately.

Dry-run mode

Before creating real PRs and issues, you can run the automation in dry-run mode by setting “dry_run": true in the CI/CD configuration or setting the CI_CD_PLATFORM environment variable to dryrun. In this mode, the Lambda function processes findings, classifies roles, and generates remediation data, but logs what it would create instead of making actual API calls to your repository platform. You can use the log to validate the automation’s behavior, review the classification accuracy, and tune exclusions before going live.

Operational metrics

The Lambda function publishes CloudWatch metrics after each run:

These metrics feed into dashboards and alarms. AnyCompany sets an alarm on errors > 5 to catch API throttling or configuration issues, and tracks prs_created + issues_created over time to measure remediation velocity.

The solution ships as two AWS CDK stacks and deploys in minutes. The accompanying GitHub repository contains the complete source code, AWS CDK stacks, configuration templates, and step-by-step deployment instructions.

At a high level, deployment involves:

1. Prerequisites: An AWS account with an ACCOUNT_UNUSED_ACCESS or ORGANIZATION_UNUSED_ACCESS analyzer enabled, Python 3.11 or later, AWS CDK v2, a CI/CD platform API token stored in AWS Secrets Manager, and Amazon Bedrock model access for the Anthropic Claude models you plan to use. The model IDs are configurable environment variables (BEDROCK_CODEGEN_MODEL and BEDROCK_EXPLANATION_MODEL); Amazon Bedrock retires older foundation models over time, so if the shipped defaults stop working, set these variables to current models you have enabled and redeploy. The repository README documents this.
2. Configuration: Two files in the config/ directory control behavior. exclusions.json defines which roles and permissions to skip (break-glass roles, service-linked roles, tagged exceptions), and ci_cd_config.json configures your repository platform integration (GitLab or GitHub), labels, and throttling limits.
3. Deploy: Run cdk deploy --all to create the Lambda function, EventBridge schedule, IAM roles, and CloudWatch alarms.
4. Validate in dry-run mode: Start with “dry_run": true to see how the automation classifies your roles without creating real PRs or issues. Review the CloudWatch logs to confirm attribution accuracy and tune exclusions.
5. Go live: Set “dry_run": false and redeploy. The Lambda function runs on schedule (daily by default) and begins creating PRs and issues.

The repository README covers each step in detail, including organization-wide deployment, cross-account configuration, and platform-specific setup for GitLab and GitHub.

Deploying the automation is only the starting point. Running it in production means making decisions about how roles are retired, how the volume of findings is managed at scale, which roles warrant human review before any change is proposed, and how you measure the automation’s impact over time. The following practices keep remediation sustainable as your IAM footprint grows, so the automation reduces operational burden rather than adding to it.

Unused roles follow a three-stage decommission workflow. When the automation identifies a role that hasn’t been assumed within the analysis period, it creates an issue with the recommended decommission steps; the automation doesn’t modify the role directly. The team then follows the soft-disable approach:

1. Attach a deny-all inline policy to the role. This blocks all actions without deleting the role or its existing policies.
2. Monitor for 30 days. If a workload depends on the role (seasonal jobs, infrequent batch processes), the deny-all policy surfaces the dependency quickly. Removing the deny-all policy restores full access immediately; no need to recreate the role or reattach policies.
3. Delete the role after the monitoring period confirms no impact.

This approach is deliberately conservative. Deleting a role is irreversible; you lose the trust policy, attached policies, and any resource-based policies that reference it. The soft-disable step gives teams a safety net while still making progress on reducing their unused role inventory.

On AnyCompany’s first run, the automation found 47 unused permission findings and 4 unused roles. That’s manageable. But organizations with hundreds of accounts and thousands of roles might see significantly more findings on initial deployment.

This is especially true with an organization-level analyzer. A single-account deployment might surface dozens of findings; an organization-level analyzer across multiple accounts could surface hundreds or thousands on the first run. The throttling controls become critical at this scale.

Two throttling controls prevent the automation from overwhelming teams:

• max_findings_per_run (default 50): Caps the total UnusedPermission findings processed per Lambda function execution. Remaining findings are picked up on the next scheduled run.
• MAX_UNUSED_ROLE_ISSUES (default 10): Caps unused role issues per run. This is especially important during initial deployment when you might have a large backlog of roles that haven’t been assumed in months.

Start with conservative limits and increase them as your team builds confidence in the review process. A team that can review 10 PRs per week shouldn’t receive 50 on Monday morning.

Not every role should receive automated PRs. Roles with administrative permissions or access to sensitive data might warrant manual review before any remediation is created. The exclusion configuration supports this through the approval_required_for_tags field:

{
  "approval_required_for_tags": {
    "Sensitive": ["true"],
    "Admin": ["true"]
  }
}

Roles matching these tags generate issues for manual review instead of automated PRs, regardless of whether they’re IaC-managed. This gives security teams a checkpoint for high-risk roles while still automating remediation for standard application roles.

The metrics published after each Lambda function run (covered in the Technical details section) feed into CloudWatch dashboards and alarms. A few patterns worth setting up:

• Alert on errors > 5 per run to catch API throttling, expired CI/CD tokens, or Amazon Bedrock availability issues.
• Track prs_created + issues_created over time. A healthy trend shows this number decreasing as your environment converges toward least privilege.
• Monitor unused_roles_found as a leading indicator. A sudden increase might signal a team spinning up roles for a project and not cleaning up afterward.
• Compare iac_roles_found to manual_roles_found over time. As teams adopt IaC, the ratio should shift toward IaC-managed roles, which means more automated remediation and less manual work.

The solution uses Lambda (minimal cost at daily execution), CloudTrail (typically already enabled), IAM Access Analyzer (charges per IAM role or user analyzed per month for the unused access analyzer), and Amazon Bedrock (pay-per-token for AWS CDK code generation and explanations). For most organizations the ongoing cost is low, and Amazon Bedrock token usage is the largest variable, scaling with the number of findings processed per day and the complexity of each policy. Review the pricing pages for each service for current rates.

For organization-level deployments, the IAM Access Analyzer cost scales with the number of IAM roles analyzed across all member accounts. The ORGANIZATION_UNUSED_ACCESS analyzer charges per role per month across the organization, so an organization with 500 roles across 20 accounts will see higher analyzer costs than a single account with 50 roles. Review the IAM Access Analyzer pricing page for current rates.

To remove the solution, run cdk destroy --all from the infrastructure/ directory. This removes the Lambda function, EventBridge rule, CloudWatch alarms, and IAM roles created by the stacks.

If you stored a CI/CD platform API token in Secrets Manager as part of deployment, delete it with aws secretsmanager delete-secret --secret-id <your-secret-name> --recovery-window-in-days 7. The 7-day recovery window lets you restore the secret if the deletion was accidental. After 7 days, the secret is permanently deleted and can’t be recovered. To delete immediately without a recovery window, add --force-delete-without-recovery.

Lambda automatically creates a CloudWatch Logs log group at /aws/lambda/<function-name> that persists after cdk destroy --all and continues to incur log storage charges. To remove it, run aws logs delete-log-group --log-group-name /aws/lambda/<function-name>. WARNING: This permanently deletes all execution logs.

The IAM Access Analyzer isn’t created by the AWS CDK stacks. WARNING: Deleting the analyzer permanently removes all findings, analysis history, and unused permission data. Export any findings you need to retain before deletion. After exporting, run aws accessanalyzer delete-analyzer --analyzer-name <your-analyzer-name> to delete it. The ACCOUNT_UNUSED_ACCESS and ORGANIZATION_UNUSED_ACCESS analyzer types incur charges based on the number of IAM roles and users analyzed per month.

If you deployed in organization mode and created cross-account roles (default name: OrganizationAccountAccessRole) in member accounts solely for this solution, remove them from those accounts.

Any PRs or issues already created in your CI/CD platform remain after stack deletion; they’re artifacts in your repository, not AWS resources. See the repository README for detailed cleanup instructions.,

Automating IAM permission remediation turns least privilege from a periodic compliance exercise into an operational practice. By connecting IAM Access Analyzer findings and recommendations to your CI/CD pipeline, remediation shifts from manual security tasks to code review processes that your teams already follow.

The three-path strategy acknowledges how infrastructure evolves. IaC-managed roles receive pull requests with production-ready AWS CDK code and plain-English explanations. Manually created roles receive actionable issues with recommended policies and IaC migration guidance. Unused roles are put on a controlled decommission path that protects against accidental disruption. Over time, the manual role count decreases as teams adopt IaC, and remediation becomes a routine part of your deployment pipeline.

Start with a pilot. Choose 10–20 non-production roles, deploy in dry-run mode, and review the classification results. Tune your exclusions, confirm the CloudTrail attribution is accurate for your environment, and then enable live remediation. Expand to production roles after your team is comfortable with the review cadence.

When you’re ready to scale beyond a single account, switch to an organization-level analyzer and the same Lambda function will process findings across all member accounts with no architectural changes required, only a configuration toggle.

The complete source code, AWS CDK stacks, and configuration templates are available in the accompanying GitHub repository.

If you have feedback about this post, submit comments in the Comments section below.

Amazon Web Services (AWS) is excited to announce the publication of the AWS Security Reference Architecture (AWS SRA) Payment Card Industry (PCI) Data Security Standard (DSS) Deep Dive. This new guide extends the core AWS SRA to provide prescriptive, architecture-level guidance for organizations that store, process, or transmit cardholder data on AWS.

Organizations subject to PCI DSS have long asked for a comprehensive reference that bridges the gap between general AWS security best practices and the specific technical and organizational controls required to achieve and maintain PCI DSS compliance. This guide answers that need by showing how AWS SRA patterns address PCI DSS intent from account scoping and network segmentation to encryption, logging, and access control.

The AWS SRA is a holistic, prescriptive security architecture guide that describes how AWS security services fit together across a multi-account AWS environment. It’s built around a modular, three-tier web architecture and is intentionally designed to be adapted as needed. Not every workload needs every service, but the AWS SRA provides the full range of options and their architectural relationships.

This PCI DSS deep dive doesn’t replace the AWS SRA, it extends it:

• Mapping AWS SRA account types to PCI DSS scoping boundaries showing which accounts are in scope, connected-to or security-impacting, or out-of-scope in a typical payment architecture.
• Layering PCI-specific controls onto existing AWS SRA service configurations. For example, additional logging granularity, encryption requirements, or network restrictions that go beyond the AWS SRA baseline.

The architectural patterns and controls described in this guide apply equally to merchants and service providers.

The guide is intended for:

• Security architects designing or extending an AWS multi-account landing zone for workloads under PCI DSS scope.
• Compliance engineers mapping AWS controls to PCI DSS requirements during assessment.
• Cloud platform teams building shared security services that must accommodate a cardholder data environment (CDE).
• Qualified Security Assessors (QSAs) and Internal Security Assessors (ISAs) who want to understand how AWS SRA patterns address PCI DSS intent.

The guide applies six foundational AWS SRA design principles that are particularly relevant to PCI DSS compliance:

• Implement a strong identity foundation: Enforce least privilege, separation of duties, and centralized identity management. Eliminate reliance on long-term static credentials.
• Enable traceability: Monitor, alert, and audit actions in real time. Integrate log and metric collection with automated investigation and response systems.
• Apply security at all layers: Defense-in-depth with preventive and detective controls at edge, virtual private cloud (VPC), load balancing, compute, OS, application, and code layers.
• Protect data in transit and at rest: Classify data by sensitivity and apply encryption, tokenization, and access control mechanisms.
• Keep people away from data: Reduce or eliminate direct access to cardholder data through automation and tooling.
• Prepare for security events: Establish incident management processes, run simulations, and implement automated detection and recovery.

The AWS SRA PCI DSS deep dive can be consumed in two ways:

• As a narrative: Read the guide from beginning to end, starting with the PCI DSS primer, through the architecture and account scoping model, to the detailed requirement mappings. This approach gives you a complete understanding of how AWS SRA and PCI DSS intersect.
• As a reference: Navigate directly to specific PCI DSS requirements or AWS SRA account types relevant to your current project. The guide includes architecture diagrams, requirement mapping tables, and service-specific configurations that you can use independently.

The guide includes downloadable architecture diagrams and detailed control mapping tables that complement the narrative content, making it straightforward to reference during security reviews and PCI DSS assessments.

Security is a journey, not a destination. Review the AWS SRA PCI DSS Deep Dive guide and begin mapping its patterns to your own cardholder data environment and then validate existing environments against SRA best practices using SRA verify.

If you need assistance, contact AWS Professional Services, your AWS account team, or the AWS Partner Network, who can work with you to translate the reference architecture into a customized AWS environment that you can then operate.

If you have feedback about this post, submit comments in the Comments section below. If you need assistance architecting or implementing a PCI DSS-compliant AWS environment, contact the AWS Security Assurance Services team.