Reading view

ICYMI: April 2026 @AWS Security

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

AWS Security Blog posts

This month’s AWS Security Blog posts covered AI security, identity and access management, threat intelligence, data protection, and multicloud operations. Whether you’re securing agentic AI systems, upgrading to post-quantum cryptography, or streamlining forensic collection, these posts offer practical guidance across the security landscape.

Identity

    Access control with IAM Identity Center session tags
    Author: Rashmi Iyer | Published: April 28, 2026
    Learn to combine AWS IAM Identity Center permission sets with session tags from Microsoft Entra ID to implement fine-grained attribute-based access control (ABAC) across multiple AWS accounts.

    Can I do that with policy? Understanding the AWS Service Authorization Reference
    Authors: Anshu Bathla, Prafful Gupta | Published: April 27, 2026
    Learn to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios needing alternative solutions, and build more effective security controls.

    AI Security

    Secure AI agent access patterns to AWS resources using Model Context Protocol
    Author: Riggs Goodman III | Published: April 14, 2026
    Learn to secure AI agent access to AWS resources via MCP using three principles: least privilege, organizational role governance, and differentiating AI-driven from human-initiated actions.

    Four security principles for agentic AI systems
    Authors: Mark Ryland, Riggs Goodman III, Todd MacDermid | Published: April 2, 2026
    Learn four security principles from AWS’s NIST response for securing agentic AI: secure development lifecycle, traditional controls, deterministic external enforcement, and earned autonomy through evaluation.

    Designing trust and safety into Amazon Bedrock powered applications
    Author: Victor Lungu | Published: April 29, 2026
    Learn to integrate responsible AI concepts into Amazon Bedrock applications, including abuse detection, Amazon CloudWatch monitoring, Bedrock Guardrails configuration, and the abuse response process.

    Building AI defenses at scale: before the threats emerge
    Author: Amy Herzog | Published: April 7, 2026
    AWS CISO announces Project Glasswing with Anthropic, introducing Claude Mythos Preview for vulnerability research, plus the general availability of AWS Security Agent for autonomous penetration testing.

    Governance and compliance

      Shift-Left Tag Compliance using AWS Organizations and Terraform
      Authors: Welly Siauw, Sourav Kundu, Manu Chandrasekhar | Published: April 27, 2026
      Learn to validate tag compliance during development using AWS Organizations tag policies, a reusable Terraform tagging module, and a test-driven approach that dynamically validates against live organizational policies.

      Detection and incident response

      What the March 2026 Threat Technique Catalog update means for your AWS environment
      Authors: Shannon Brazil, Cydney Stude | Published: April 28, 2026
      The AWS CIRT’s latest Threat Technique Catalog update covers Amazon Cognito refresh token abuse, AMI image deletion targeting recovery, and trust policy modifications for persistence and privilege escalation.

      A framework for securely collecting forensic artifacts into S3 buckets
      Authors: Jason Garman, Vaishnav Murthy | Published: April 8, 2026
      Learn to securely collect forensic artifacts into Amazon S3 using time-limited, least-privilege credentials with AWS STS session policies and automated AWS Step Functions workflows.

      Transform security logs into OCSF format using a configuration-driven ETL solution
      Authors: Vivek Gautam, Arpit Gupta, Ryan Gomes | Published: April 17, 2026
      Learn to transform custom security logs into OCSF format using an AWS ProServe configuration-driven ETL solution with AWS Step Functions, AWS Glue or Amazon EMR Serverless, and Amazon Security Lake integration.

      A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended
      Authors: Matt Meck, Michael Fuller | Published: April 22, 2026
      Learn how AWS Security Hub Extended simplifies multicloud security procurement and operations through curated partner solutions, unified billing, and OCSF-based findings consolidation.

      Data protection

        Protecting your secrets from tomorrow’s quantum risks
        Authors: Stéphanie Mbappe, Tobias Nickl | Published: April 24, 2026
        Learn to upgrade AWS Secrets Manager clients to use hybrid post-quantum TLS with ML-KEM, protecting secrets against harvest-now-decrypt-later attacks, and verify connections via AWS CloudTrail.

        How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds
        Authors: Panos Kampanakis, Matthew Campagna, Patrick Palmer | Published: April 3, 2026
        Learn how AWS Key Management Service and the AWS Encryption SDK use derived key methods to automatically handle AES-GCM encryption limits, eliminating the need to manually track bounds or rotate keys.

        How to clone an AWS CloudHSM cluster across Regions
        Authors: Desiree Brunner, Rickard Löfström | Published: April 20, 2026
        Learn to clone an AWS CloudHSM cluster to another Region using CopyBackupToRegion, then synchronize keys—including non-exportable keys—across cloned clusters for disaster recovery.

        April Security Bulletins

        Investigations of reported security vulnerabilities affecting Amazon and AWS services, software, and products.

        AWS Samples

        This month brings 16 new AWS samples spanning identity, governance, compliance, detection and incident response, AI Security, data protection, and infrastructure security. From beginner-friendly AI agent development on Amazon Bedrock to automated Control Tower re-registration at scale, these ready-to-deploy repositories help you implement security best practices across your AWS environment.

        Identity

          Amazon Cognito OAuth2 Token Proxy with Caching
          Learn to deploy an Amazon API Gateway proxy for Cognito’s OAuth2 token endpoint with intelligent caching and AWS WAF protection, reducing M2M authentication costs by over 90%.

          Cognito API Gateway Authorization Demo
          Learn to implement user-specific data protection using Amazon Cognito, API Gateway, and an AWS Lambda authorizer that enforces JWT sub claim matching to prevent cross-user data access.

          Securely Connecting On-Premises Data Systems to Amazon Redshift with IAM Roles Anywhere
          Learn to deploy a fully private environment connecting on-premises workloads to Amazon Redshift using X.509 certificate authentication via IAM Roles Anywhere for short-lived credentials.

          AWS IAM Access Key Lifecycle Management with Human Approval
          Learn to automate organization-wide detection, disabling, and deletion of unused IAM access keys using Step Functions, IAM Access Analyzer, and a secure human-in-the-loop approval workflow.

          Secrets Manager Audit
          Learn to resolve and report who can access your AWS Secrets Manager secrets—across accounts, through Identity Center, and down to the human behind the IAM role—in a single command.

          Governance

          Control Tower Organization Re-Registration Automation
          Learn to automate AWS Control Tower OU re-registration and account updates at scale using lifecycle events, Amazon EventBridge, and AWS Lambda to resolve mixed governance after landing zone changes.

          Sample Agent Skills for Builders
          A curated collection of installable agent skills that extend AI coding agents (Claude Code, Cursor, Copilot) with production-ready AWS, CDK, security scanning, and engineering workflows.

          How to Stop AI Agent Hallucinations: 5 Techniques + Production on Amazon Bedrock AgentCore
          Learn to detect, prevent, and self-correct AI agent hallucinations using Graph-RAG, semantic tool selection, multi-agent validation, neurosymbolic guardrails, and agent steering with Strands Agents.

          Compliance

          Compliance Lens
          Learn to deploy a serverless solution that analyzes AWS Config snapshots across an AWS Organization, compares them against conformance pack rule sets, and visualizes compliance posture via Amazon QuickSight dashboards.

          AWS Security Agent Terraform Configuration
          Learn to provision AWS Security Agent resources using the AWSCC Terraform provider, automating agent space creation, IAM roles, target domain registration, and penetration test setup.

          Detection and incident response

          AWS Security Agent Demo Suite
          Learn to use AWS Security Agent across three scenarios: automated design reviews, AI-generated infrastructure code review via GitHub, and penetration testing against intentionally vulnerable applications.

          Agentic SOC Workshop — CDK Infrastructure
          Learn to build an AI-powered Security Operations Center agent that investigates Amazon GuardDuty findings, queries CloudTrail logs, and takes automated containment actions using Amazon Bedrock AgentCore.

          Data Protection

          Implementing Kerberos Authentication for Apache Spark Jobs on Amazon EMR on EKS to Access a Kerberos-Enabled Hive Metastore
          Learn to configure Kerberos authentication for Spark jobs on Amazon EMR on Amazon Elastic Kubernetes Service, connecting to a Kerberos-enabled Hive Metastore using Microsoft Active Directory as the KDC.

          AWS Nitro Enclaves with Kubernetes – Hello World Example
          Learn to deploy a Hello World application inside an AWS Nitro Enclave on Amazon EKS, covering cluster creation, device plugin setup, and enclave image building.

          Infrastructure security

            Multi-Tenant OpenClaw on Firecracker
            Learn to deploy isolated, multi-tenant OpenClaw AI agents on AWS using Firecracker microVMs with per-tenant kernel/network isolation, auto-scaling, backup/restore, and a web management console.

            AI Security

            Amazon Bedrock for Beginners – From First Prompt to AI Agent
            Learn to build AI applications on Amazon Bedrock, from basic API calls to a full agent with RAG, guardrails, tool use, and the Strands Agents SDK.

            Conclusion

            April 2026 reinforces that securing AI workloads now requires the same rigor applied to traditional infrastructure. The posts and samples in this edition provide concrete patterns for enforcing least privilege on agentic systems, automating governance at organizational scale, and preparing cryptographic implementations for post-quantum requirements. The security bulletins address vulnerabilities across compute, networking, and developer tooling, reinforcing the need to apply patches consistently. Each resource includes deployment steps or runnable code so you can validate the approach in your own environment before adopting it. 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. If you have questions about this post, contact AWS Support.

            Rodolfo Brenes

            Rodolfo Brenes

            Rodolfo is a Principal Solutions Architect focused on Cloud Governance and Compliance. With over 18 years of experience, he currently leads a technical field community in AWS helping customers scale and improve their security and governance frameworks. Besides work, Rodolfo enjoys video games, playing with his four cats, and won’t say no to a good outdoor adventure.

            Anna Brinkmann

            Anna Brinkmann

            Anna is a project manager and editor with more than 18 years of experience with content management in the technology space. For the past 6 years, she has run the AWS Security Blog. In her free time, Anna gardens, spends time with family and friends, and learns new slang words from her kids.

            •  

            AWS achieves SNI 27017, SNI 27018, and SNI 9001 certifications for the AWS Asia Pacific (Jakarta) Region

            Amazon Web Services (AWS) achieved three Standar Nasional Indonesia (SNI) certifications for the AWS Asia Pacific (Jakarta) Region: SNI ISO/IEC 27017:2015, SNI ISO/IEC 27018:2019, and SNI ISO 9001:2015. SNI represents Indonesia’s national standards framework, comprising standards that are broadly applicable across industries within the country. These certifications further demonstrate that AWS services meet nationally recognized requirements.

            The certifications were assessed by an independent third-party auditor accredited by the Komite Akreditasi Nasional (KAN), Indonesia’s National Accreditation Committee, in accordance with applicable local regulatory requirements, helping customers rely on trusted, locally recognized validation for their compliance needs.

            All three certifications are based on international ISO standards adapted for Indonesia:

            • SNI 27017 adds cloud-specific security controls that complement ISO/IEC 27001, helping you run workloads securely while reducing security assessment overhead.
            • SNI 27018 focuses on protecting personally identifiable information (PII) in public clouds. This certification confirms that AWS handles your data according to international privacy standards.
            • SNI 9001 establishes quality management systems that ensure consistent service delivery and continuous improvement across AWS operations.

            Together with the existing SNI 27001 certification achieved in 2023, AWS is now the first cloud service provider (CSP) to hold all four SNI certifications—SNI 27001, SNI 27017, SNI 27018, and SNI 9001—demonstrating comprehensive alignment with Indonesia’s national standards for information security, cloud security, privacy, and quality management, and helping customers address a broad range of regulatory and risk management requirements.

            Customers can access the corresponding certificates through AWS Artifact, a self-service portal that provides on-demand access to AWS compliance documentation. For a full list of AWS services covered under the SNI certification, see the Services in Scope compliance page

            AWS continues to expand the scope of its compliance programs to help customers meet their architectural, business, and regulatory requirements. For more information regarding these certifications, contact your AWS Accounts team.

            Ignatius Lee

            Ignatius Lee

            Ignatius is a Security Assurance professional based in Singapore, responsible for third-party audits in Indonesia. He joined Security Assurance in early 2025 and has delivered and contributed to key audit programs across Hong Kong, Singapore, and Australia.

            •  

            New compliance guide available: ISO/IEC 42001:2023 on AWS

            We have released our latest compliance guide, ISO/IEC 42001:2023 on AWS, which provides practical guidance for organizations designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.

            As organizations deploy AI and generative AI workloads in the cloud, aligning with globally recognized standards such as ISO/IEC 42001:2023 becomes an important step toward strengthening AI governance, risk management, and responsible AI practices. This guide helps cloud architects, AI/ML engineers, security teams, compliance leaders, and DevOps practitioners understand how to implement and operate ISO 42001-aligned controls using AWS services while applying the AWS Shared Responsibility Model for AI.

            The guide explains how organizations can integrate AWS services into their AIMS to support the requirements defined in ISO 42001:2023 clauses 4–10 and the Annex A control specific to AI systems. It also highlights how AWS AI services, security capabilities, monitoring, and automation can help customers maintain visibility over AI systems, improve operational consistency, and prepare audit-ready evidence.

            While AWS provides a secure and compliant cloud infrastructure with built-in responsible AI capabilities, customers remain responsible for defining their AIMS scope, implementing controls, and demonstrating conformity during certification audits.

            Inside the guide:

            • Overview of the ISO/IEC 42001:2023 framework, including understanding ISO 42001 and its Annexes, and how it relates to the broader ISO AI standards family
            • Guidance for integrating with AWS security architecture and applying the AWS Shared Responsibility Model for AI workloads
            • Context and scoping considerations for establishing an AIMS on AWS, including defining AI system boundaries within your environment
            • Mapping of ISO 42001:2023 clauses 4–10 to AWS services and architectural capabilities, covering organizational context, leadership, planning, support, operation, performance evaluation, and improvement
            • Implementation guidance for specific Annex A controls (A.2–A.10), including AI policies, internal organization, resources for AI systems, impact assessments, AI system life cycle management, data governance, transparency for interested parties, use of AI systems, and third-party and customer relationships
            • Recommendations for evidence collection, documentation, and audit readiness using AWS native tooling
            • Best practices for operationalizing AI compliance activities through automation and infrastructure-as-code

            Use this guide to map ISO 42001 clauses and Annex A controls to your AWS environment, automate evidence collection, and reduce the effort involved in preparing for a certification audit.

            Download: ISO/IEC 42001:2023 on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

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

            Abdul Javid

            Abdul Javid

            Abdul is a Senior Security Assurance Consultant and a PECB ISO 42001 Lead Auditor, IAPP Certified AI Governance Professional and ISACA Advanced in AI Security Management. He draws on his extensive experience of over 25 years to guide AWS customers on compliance matters. He holds an M.S. in Computer Science from IIT Chicago and numerous certifications from IAPP, AWS, ISO, HITRUST, ISACA, CMMC, PMI, PCI DSS, and ISC2.

            Satish Uppalapati

            Satish is an Associate Assurance Consultant with AWS Security Assurance Services and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to help align cloud environments with frameworks such as ISO 27001, SOC 2, and FFIEC. Satish also focuses on advancing governance for AI systems, including emerging standards such as ISO/IEC 42001.

            Amber Welch

            Amber Welch

            Amber is an AWS Security Assurance Services Senior Privacy Consultant, advising AWS customers on their AI and privacy risk management and compliance. She has an M.A. in English and ISO 42001 Lead Auditor, IAPP CIPM, and IAPP CIPP/E certifications. Amber has spoken and written extensively on AI and privacy topics, and is an AWS Privacy Reference Architecture primary author.

            Jonathan-Jenkyn

            Jonathan Jenkyn

            Jonathan (“JJ”) is a Sr Security Assurance Solution Architect with AWS Security Assurance Services. With over 30 years of experience, he is a proven security leader who delivers robust cloud security outcomes. JJ is also an active member of the AWS People with Disabilities affinity group and enjoys running, cycling, and spending time with his family.

            Muhammad Sharief

            Muhammad Sharief

            Muhammad is a Security Assurance Consultant with AWS Security Assurance Services (SAS) and a PECB-certified ISO/IEC 42001 Lead Auditor. He helps enterprise customers across AWS GovCloud (US) and commercial environments achieve and maintain compliance with FedRAMP, CMMC, ISO 27001, ISO 42001, and NIST 800-53. Muhammad works closely with customers, partners, and AWS service teams to design automated evidence collection architectures, advance AI governance, and align cloud security and compliance requirements with business objectives.

            •  

            Introducing AI traffic analysis dashboards for AWS WAF

            As AI agents, bots, and programmatic access become an increasingly significant portion of web traffic, organizations need better tools to understand, analyze, and manage this activity. Today, we’re excited to announce AI Traffic Analysis dashboards for AWS WAF protection packs—also known as web access control lists (web ACLs)—providing comprehensive visibility into AI bot and agent behavior across your applications.

            The challenge: Understanding AI bot traffic

            The rapid proliferation of AI bots—from search engine crawlers to research agents—has fundamentally changed the nature of web traffic. Organizations across industries are discovering that AI agents now represent 30–60% of their total traffic, driving significant infrastructure costs without always generating business value.

            Traditional bot management tools weren’t designed for the nuances of AI traffic. Teams need to answer critical questions such as: Which AI organizations are accessing our content? What are they trying to accomplish? Which endpoints are most frequently targeted? How has this activity changed over time? Most importantly, how can we turn this visibility into actionable business decisions?

            Introducing the AI Traffic Analysis dashboard

            The new AI Traffic Analysis dashboard provides specialized visibility into AI bot and agent activity, available directly within your AWS WAF protection pack (web ACL) console. With this launch, AWS WAF Bot Control expands its detection coverage to track more than 650 unique bots and agents, offering one of the most comprehensive AI bot detection catalogs available. A detection catalog that will keep growing and be updated to align with the pace of the industry’s changes.

            This dashboard goes beyond standard security metrics to deliver AI-specific insights that help you understand and manage this critical traffic segment.

            Key capabilities

            • Bot identification and verification: See which AI bots are accessing your applications, including bot names, owning organizations, and verification status. Quickly distinguish between legitimate AI agents from known organizations and potentially suspicious activity.
            • Intent classification: Understand the purpose behind AI bot requests. The dashboard categorizes bot behavior patterns—whether crawling for search indexing, conducting research, gathering training data, or other activities—helping you align access policies with business objectives.
            • Access pattern analysis: Identify your most frequently accessed URLs and endpoints by AI agents. This visibility helps you understand which content is most valuable to AI organizations and optimize your infrastructure accordingly.
            • Temporal trends and historical analysis: Track AI bot activity patterns by time of day and analyze historical trends over the past 14 days. Detect anomalies, understand peak usage periods, and identify emerging patterns in AI traffic.
            • Organization breakdown: View traffic volume segmented by bot owner organization, giving you clear visibility into which AI companies are accessing your content and at what scale.

            How it works

            AI Traffic Analysis dashboards integrate seamlessly with AWS WAF Bot Control for common bots using the same traffic evaluation engine while providing specialized analytics for AI-specific patterns. The dashboards display near real-time summaries based on Amazon CloudWatch metrics collected as AWS WAF evaluates your web traffic.

            To access the AI Traffic Analysis dashboard:

            1. Navigate to your protection pack (web ACL) in the AWS Management Console for AWS WAF.
            2. Select the AI Traffic Analysis tab.
            3. Apply filters for bot organization, intent type, or verification status as needed.
            4. Analyze the comprehensive visualizations across bot identity, intent classification, access patterns, and temporal trends.

            The dashboard populates automatically once your protection pack begins receiving AI bot traffic, so you have visibility exactly when you need it.

            From visibility to action

            This new capability addresses a critical need as organizations navigate the evolving landscape of AI-driven web traffic. With detailed insights into AI bot behavior, you can:

            • Make informed access decisions: Understand bot intent before implementing allow or block rules.
            • Optimize infrastructure investment: Identify high-traffic endpoints and plan capacity accordingly. Know whether your infrastructure costs are supporting business value or used without programmatic compensation mechanism.
            • Implement tiered access strategies: Serve different content or pricing based on AI agent verification and intent.
            • Detect anomalies and emerging patterns: Spot unusual patterns that might indicate emerging threats or opportunities. Real-time visibility helps you respond quickly to changes in AI bot behavior.
            • Support cross-organizational strategy: Provide data to stakeholders across security, product, and business teams for informed decisions about AI bot access policies and monetization opportunities.
            • Customize as needed: AI Traffic analyses are emitted as CloudWatch metrics that an organization can use to customize CloudWatch or another supported observability product as needed. Moreover, by using CloudWatch metrics, an organization can build proactive measures such as alerts or business actions such as rate or limit changes.
            • Monetize AI traffic at the edge: For a reference architecture that combines WAF Bot Control AI visibility, traffic control, and content monetization using the x402 payment protocol, see the sample-x402-content-monetization-with-cloudfront-and-waf project on GitHub. It demonstrates how to classify AI bot traffic, enforce per-path pricing policies, and settle payments at the edge using Amazon CloudFront and Lambda@Edge – with zero changes to your existing origins.

              Note: This AWS Samples solution is not a supported product in their own right, but educational examples to help our customers use our products for their applications. As our customer, any applications you integrate this example into should be thoroughly tested, secured, and optimized according to your business’s security standards & policies before deploying to production or handling production workloads. Deploying it will provision resources that incur additional AWS charges, so review costs before deploying and delete the stack when no longer needed.

            Programmatic access: Automate your AI traffic insights

            In addition to the console dashboard, you can programmatically query AI bot traffic data using the GetTopPathStatisticsByTraffic action, available through the AWS WAF API, AWS SDKs, and AWS CLI. This action returns the top URI paths by bot traffic volume for a given web ACL and time window. Each path in the response includes request counts, traffic percentages, and the top bots accessing it. You can filter results by bot category (for example, ai), organization, or specific bot name, and use a URI path prefix (for example, /api/) to drill down into specific areas of your application. The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL.

            The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL:

            aws wafv2 get-top-path-statistics-by-traffic \
              --web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:global/webacl/ExampleWebACL/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \
              --scope "CLOUDFRONT" \
              --time-window StartTime=2026-02-25T00:00:00Z,EndTime=2026-02-26T00:00:00Z \
              --bot-category "ai" \
              --uri-path-prefix "/api/" \
              --limit 5 \
              --number-of-top-traffic-bots-per-path 3

            A sample response:

            {
              "TopPathStatistics": [
                {
                  "Path": "/api/v1/products",
                  "RequestCount": 145320,
                  "TrafficPercentage": 32.4,
                  "TopBots": [
                    { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 98210 },
                    { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 47110 },
                    { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 0 }
                  ]
                },
                {
                  "Path": "/api/v2/search",
                  "RequestCount": 87650,
                  "TrafficPercentage": 19.5,
                  "TopBots": [
                    { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 52300 },
                    { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 35350 },
                    { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 0 }
                  ]
                }
              ],
              "TimeWindow": {
                "StartTime": "2026-02-25T00:00:00Z",
                "EndTime": "2026-02-26T00:00:00Z"
              }
            }

            Programmatic access enables you to:

            • Build custom dashboards or integrate AI traffic data into existing observability platforms.
            • Automate alerting when specific paths see unusual bot traffic spikes.
            • Feed traffic data into business intelligence pipelines for content monetization decisions.
            • Investigate and debug AI bot activity within a specific timeframe to identify the root cause of traffic anomalies or incidents.

            For detailed usage information, see the GetTopPathStatisticsByTraffic API reference and the AWS CLI command reference. This API pairs naturally with the CloudWatch metrics approach described above, giving you both real-time metric streams and on-demand path-level analytics for comprehensive AI traffic management.

            Availability

            For customers on flat-rate pricing plans, the AI Traffic Analysis dashboard is included with all paid plans. Read more about CloudFront flat-rate pricing in the launch blog post. For AWS WAF customers not subscribed to flat-rate plans, the AI traffic analysis dashboard is available at no additional cost. See AWS WAF pricing for details.

            Get started today

            The AI Traffic Analysis dashboard represents a significant step forward in managing the intersection of AI and web security. As AI agents continue to grow as a percentage of overall web traffic, having the right visibility tools becomes essential for both security and business success.

            To learn more about AWS WAF Bot Control and AI Traffic Analysis dashboards, visit the AWS WAF Developer Guide or explore the feature directly in your AWS WAF console.

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

            Christopher Jen

            Christopher Jen

            Christopher is a go-to-market leader at Amazon Web Services (AWS), specializing in Edge Services, Cyber Security, AI Security, and Agentic Identification. Based in London, he’s a seasoned business development and partnerships executive with a track record of driving growth across cloud, security, and emerging technology domains.

            Eitav Arditti

            Eitav Arditti

            Eitav is an AWS Senior Solutions Architect with over 15 years of experience in the AdTech industry. He specializes in Edge computing, Serverless, Containers, and Platform Engineering. Eitav helps organizations design cost-efficient, large-scale AWS architectures that integrate cloud-focused and Edge services such as CloudFront and WAF to deliver secure, performant, and globally scalable solutions that accelerate business growth.

            Author

            Kaustubh Phatak

            Kaustubh is a product leader specializing in AI/ML systems and enterprise security solutions. He has led cross-functional teams in deploying AI-powered products at scale, working closely with security architects and CISOs to address the intersection of AI innovation and cybersecurity risk. His work focuses on translating complex technical capabilities into business value, particularly in emerging technology domains where traditional frameworks don’t apply.

            •  

            Five ways to use Kiro and Amazon Q to strengthen your security posture

            A Monday morning security alert flags unauthorized access attempts, security group misconfigurations, and AWS Identity and Access Management (IAM) policy violations. Your team needs answers fast.

            Security teams are using Kiro and Amazon Q Developer to handle repetitive tasks—scanning resources, drafting policies, and researching Common Vulnerabilities and Exposures (CVEs)—so engineers can focus on risk decisions and complex scenarios that require human judgment, resulting in faster threat response and more consistent security coverage.

            This post shows you five ways to use Kiro and Amazon Q Developer to strengthen your AWS security posture based on the AWS Well-Architected Framework Security Pillar. Each technique builds on a common foundation described after the tool overview below.

            About these tools

            Amazon Web Services (AWS) gives customers choices when it comes to AI-assisted development and security automation. Whether you prefer Kiro’s agentic integrated development environment (IDE) experience or the deep integration of Amazon Q Developer into your existing AWS environment, both tools can help you implement the security practices described in this post. The right choice depends on your team’s workflow, and in many cases both tools are complementary and can be used together.

            Kiro is an AI-powered, agentic, IDE designed by AWS for specification-driven development, combining natural language prompting with structured, intentional coding to generate, test, and deploy applications.

            Amazon Q Developer is the generative AI assistant integrated into AWS development and cloud environments, designed to answer questions, generate code, troubleshoot issues, and automate operational tasks across AWS services.

            For setup instructions and to learn more, see the Kiro documentation and Amazon Q Developer documentation.

            1. Embed security best practices with persistent context

            Providing AI assistants with the right context helps them produce more consistent and relevant results. Each of the five techniques in this post becomes significantly more powerful when your AI assistant already understands your organization’s security standards. Setting up persistent context first means every subsequent interaction builds on that foundation, and the results you get from triage, remediation, reviews, and policy development will better reflect your specific environment rather than generic best practices.

            Without persistent context, you need to repeat the same security requirements in every prompt such as "enable encryption, use least privilege IAM settings, and enable logging," which leads to inconsistent results and missed controls. Amazon Q Developer IDE Plugin rules and Kiro steering files (CLI and IDE) solve exactly this problem: you can use them to codify your organization’s security standards so AI automatically builds secure infrastructure consistently, without requiring you to repeat requirements in every prompt. Both tools support this capability independently, so you can configure whichever fits your workflow, or use both together for coverage across your full development environment. The following steps show you how to get started with each.

            For Amazon Q Developer:

            1. Create directory: .amazonq/rules/ in your project root.
            2. Create file: .amazonq/rules/security-standards.md.
            3. Paste your organization’s security standards in natural language (see “Example security standards context file” below).

            For Kiro (steering files):

            In Kiro, persistent context documents are called steering files. They give the agent ongoing awareness of your architecture decisions, coding standards, and security requirements across every interaction and every session.

            1. Create file: security-standards.md in your project root.
            2. Reference it in prompts: Using security-standards.md as context, create....

            Pro tip: You can use Kiro itself to help you create steering files. Describe your security requirements in natural language and ask Kiro to generate a structured steering file for your review before saving and activating it. This means your AI assistant can help you build the very context it will later use, making the setup process faster and more thorough.

            Example security standards context file:

            # AWS Security Standards
            
            ## Identity and Access Management
            - All IAM roles must use least privilege principles
            - Require MFA for console access
            - Enable IAM Access Analyzer for all accounts
            - Rotate access keys every 90 days
            - Use IAM roles for EC2 instances, never embed access keys
            
            ## Data Protection
            - Enable encryption at rest for all storage services (S3, EBS, RDS)
            - Use AWS KMS customer-managed keys for sensitive data
            - Enable encryption in transit with TLS 1.2 minimum
            - Implement S3 bucket policies denying unencrypted uploads
            - Enable versioning and MFA delete for critical S3 buckets
            
            ## Infrastructure Protection
            - Security groups must follow least privilege (no 0.0.0.0/0 on sensitive ports)
            - Deploy resources in private subnets when possible
            - Enable VPC Flow Logs for network monitoring
            - Use AWS WAF for public-facing applications
            - Implement Network ACLs as additional defense layer
            
            ## Detective Controls
            - Enable CloudTrail in all regions with log file validation
            - Configure CloudWatch alarms for security events
            - Enable GuardDuty for threat detection
            - Set up AWS Config rules for compliance monitoring
            - Implement centralized logging with retention policies
            
            ## Incident Response
            - Create SNS topics for security alerts
            - Configure automated responses with AWS Lambda
            - Maintain runbooks for common security incidents
            - Enable AWS Systems Manager for secure instance access
            - Implement automated backup and recovery procedure

            What this unlocks:

            Without persistent context, a prompt like Create a Lambda function to process customer data could produce a basic function with no encryption, logging, or IAM configuration. AI output is non-deterministic, meaning that without guidance it might or might not include those controls. Steering files and rules documents minimize those variables by providing stronger guidance as part of every prompt and inference input.

            With your security standards embedded as in the example above, however, the same prompt generates a function with KMS-encrypted environment variables, a CloudWatch log group with 90-day retention, least-privilege IAM, VPC placement in private subnets, a dead-letter queue, and AWS X-Ray tracing—all automatically.

            Where it works:

            This persistent context approach applies across both tools and all infrastructure generation workflows:

            • Amazon Q Developer IDE Plugin: Rules in .amazonq/rules/ apply automatically to every code generation and review interaction.
            • Kiro: Steering files provide the agent with continuous architectural and security awareness across sessions and projects.

            The shift-left impact:

            This approach isn’t a replacement for your existing continuous integration and delivery (CI/CD) security automation. It’s a powerful complement to it, and that distinction matters. By embedding security standards directly into the development workflow, you shift security validation further left than pipeline checks can reach. Developers across your organization, not just security specialists, can generate infrastructure that meets your security standards from the first line of code. This scales security expertise into non-security roles, empowers development teams to self-serve on compliance requirements, and reduces the volume of findings that ever reach your automated pipeline checks.

            The result is security functioning as an enabler of faster development rather than a gate that slows it down, and security engineers spending their time on policy design and complex risk decisions rather than remediating avoidable misconfigurations.

            Measurable impact:

            Track these metrics to quantify the value of persistent context:

            • Security findings during code review: Establish a 30–60 day baseline before enabling context files, then compare
            • Time from development to deployment: Track average cycle time before and after
            • Remediation cost: Research consistently shows defects fixed in development cost significantly less than those fixed in production. Track your own ratio for 60 days
            • Standards consistency: Audit a random sample of infrastructure pull requests for compliance with your top 10 policies

            Implementation recommendation: Start by codifying your top 10 most frequently violated security policies as context. Measure the reduction in these specific findings over 30–60 days to quantify the impact on your team.

            2. Accelerate security finding triage and investigation

            AWS Security Hub consolidates findings from services such as Amazon GuardDuty, AWS Config, Amazon Inspector, and third-party security tools into a single dashboard, providing centralized security finding visibility and built-in triage capabilities across your AWS environment. AWS Security Hub Extended will bring even more capabilities into this mix, giving customers expanded control and additional opportunities to leverage the AI-assisted workflows described in this post at greater scale and with deeper integration across your security toolchain.

            Kiro can complement Security Hub by helping you correlate findings across accounts, understand CVE context, and develop remediation approaches, including:

            • Query findings using natural language across multiple AWS accounts and AWS Regions
            • Understand specific CVEs and their potential impact on your infrastructure
            • Generate investigation queries for AWS CloudTrail and Amazon Virtual Private Cloud (Amazon VPC) Flow Logs
            • Correlate security events across different time periods and services
            • Access the latest AWS security documentation and best practices

            How it works – Model Context Protocols:

            To enable these capabilities, Kiro uses Model Context Protocols (MCPs)—a standardized way for AI assistants to securely connect with external tools, services, and data sources, enabling them to take actions, retrieve real-time information, and interact with APIs beyond their built-in capabilities.

            Open source MCP servers for AWS are a suite of specialized MCP servers that enable Kiro to interact with AWS security services, providing real-time visibility into your security posture. To get started, configure security-focused MCP servers in your Kiro settings file (as shown in the following example). For full instructions on configuring MCP servers in Kiro, see the Kiro MCP documentation.

            Note on authentication: Before querying Security Hub, verify you have configured valid AWS credentials for the target account. Set the AWS_PROFILE value to a named profile in your ~/.aws/credentials file that has the appropriate permissions, or configure credentials using the AWS Command Line Interface (AWS CLI) (aws configure). Without valid credentials for the target account, Kiro will not be able to retrieve findings.

            {
                "mcpServers": {
                    "awslabs.aws-api-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.aws-api-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>",
                            "AWS_REGION": "us-east-1"
                        },
                        "timeout": 120000,
                        "disabled": false
                    },
                    "awslabs.cloudtrail-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.cloudtrail-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>"
                        },
                        "disabled": false
                    },
                    "awslabs.iam-mcp-server": {
                        "command": "uvx",
                        "args": ["awslabs.iam-mcp-server@latest"],
                        "env": {
                            "FASTMCP_LOG_LEVEL": "ERROR",
                            "AWS_PROFILE": "<PROFILE>"
                        },
                        "disabled": false
                    }
                }
            }

            Configure the following security-focused MCP servers to get started:

            • AWS API MCP Server: Interact with Security Hub, GuardDuty, IAM Access Analyzer, and AWS Config through AWS CLI commands
            • CloudTrail MCP Server: Audit trail analysis and compliance monitoring
            • AWS IAM MCP Server: Manage IAM users, roles, policies, and permissions
            • AWS Knowledge MCP Server: Access up-to-date AWS security documentation and best practices

            For a full list of available MCP servers, see the awslabs/mcp GitHub repository.

            Example: querying Security Hub with Kiro:

            1. Open your terminal or Kiro IDE.
            2. Enter the following command:
            "Show me all critical security findings from Security Hub in my production account ID <ACCOUNT ID>"

            Example output:

            > Found 4 critical security findings in account 123456789012:
            
            ## Configuration Issues (2)
            
            1. SSM.7 - SSM documents block public sharing disabled
            - Status: FAILED (since July 17, 2025)
            - Impact: Systems Manager documents can be publicly shared
            - Remediation: Enable block public sharing setting for SSM documents
            - [Documentation](https://docs.aws.amazon.com/console/securityhub/SSM.7/remediation)
            
            2. Config.1 - AWS Config not properly configured
            - Status: FAILED (since March 4, 2025)
            - Issue: Config isn't recording required IAM resource types (User, Role, Group, Policy)
            - Standards affected: CIS, NIST 800-53, PCI DSS, AWS Foundational Security
            - Remediation: Enable recording for IAM resources in AWS Config
            - [Documentation](https://docs.aws.amazon.com/console/securityhub/Config.1/remediation)
            
            ## Vulnerabilities (2)
            
            3. CVE-2020-36242 in Lambda function: MyLambdaOne
            - Package: cryptography version 3.2.1
            - CVSS Score: 9.1 (Critical)
            - Issue: Integer/buffer overflow in Fernet encryption class
            - Fix: Upgrade to cryptography 3.3.2
            - Function: SPC-1233HH5R-MyLambdaOne-lUh3ESH0MdXF
            
            4. CVE-2020-36242 in Lambda function: AutoUpdateMyLambdaOne
            - Package: cryptography version 3.2.1
            - CVSS Score: 9.1 (Critical)
            - Same vulnerability as above
            - Function: SPC-1233HH5R-AutoUpdateMyLambdaOne-d9HIBfxThbFW

            Real-world impact:
            Security finding triage that previously required navigating multiple consoles, correlating logs manually, and researching CVE databases can be accelerated significantly. Teams that have integrated AI-assisted triage into their Security Hub workflows report reducing mean time to triage for critical findings from hours to minutes, enabling faster containment and more consistent coverage across accounts.

            3. Accelerate remediation of security findings in your infrastructure as code

            AI assistants can scan your infrastructure code and flag security issues with specific fix recommendations. However, implementing these changes requires careful review, testing, and validation before any changes reach production.

            Important: AI-generated remediation suggestions must be reviewed by a qualified security engineer before implementation. Automated application of AI-generated changes without human validation can introduce unintended misconfigurations or service disruptions. Treat AI output as a starting point, not a finished product.

            The workflow:
            You can execute this workflow in either Kiro or Amazon Q Developer, depending on which tool fits your existing development environment:

            1. Ask Kiro or Amazon Q Developer to scan your infrastructure files and identify security gaps.
            2. Review AI-generated remediation suggestions with your security team.
            3. Test changes in non-production environments.
            4. Validate using AWS security services such as IAM Access Analyzer, AWS Config, and Security Hub.
            5. Deploy to production with monitoring and rollback procedures in place.

            Example prompt:

            "Scan my infrastructure at /path/to/templates, identify all S3 buckets without encryption, enable AES-256 encryption, add bucket policies to deny unencrypted uploads, and provide the deployment command"

            What happens:

            The AI assistant analyzes your infrastructure files, whether written in AWS CloudFormation, Terraform , or AWS Cloud Development Kit (AWS CDK), and identifies resources that violate security best practices. It then implements controls such as encryption at rest using AWS Key Management Service (AWS KMS) or Amazon Simple Storage Service (Amazon S3)-managed keys, adds bucket policies enforcing encryption in transit, configures public access blocks, and generates the exact deployment command with a change preview so you can review what will be modified before anything is applied.

            Based on the example security standards context file above, the following controls would be applied across all generated infrastructure: encryption at rest and in transit, least-privilege IAM policies, security group optimizations, VPC configurations, logging enablement, and backup and recovery settings.

            Validation required:
            AI-generated configurations deserve the same thoughtful review as other infrastructure code. Even a policy that looks correct on the surface might need tuning to match your organization’s least-privilege standards, or encryption settings might need adjusting to satisfy specific compliance requirements. Running those changes through a non-production environment and having a human confirm the results before anything reaches production are part of good infrastructure practices, whether the code was written by a person or generated by AI.

            Real-world impact:

            Identifying non-compliant resources across multiple accounts manually can take many hours and generating remediation templates for each resource can add significant time. Security teams that have adopted AI-assisted infrastructure scanning report spending less time on manual identification and template generation, and with AI assistance the same identification and drafting work can be completed in much less time. Customers report that a full remediation cycle that previously occupied their team for the better part of a day can be completed in under an hour when AI handles the scanning and template generation. It is worth noting that manual remediation time grows considerably at scale, as remediating dozens of non-compliant resources is not a linear exercise. Validation time in non-production environments remains essential regardless of how the remediation was generated, and should always be factored into your planning.

            4. Perform in-depth security reviews

            Amazon Q Developer and Kiro can analyze your infrastructure code and identify potential security issues across multiple categories aligned with the AWS Well-Architected Framework Security Pillar.

            Using Amazon Q Developer:

            1. Open your infrastructure file in your IDE.
            2. Select the code you want to review.
            3. Open the context menu and choose Send to Amazon Q, then choose Optimize.
            4. Select Focus on security best practices.

            Using Kiro:

            1. Open your infrastructure file in Kiro.
            2. Enter a natural language prompt such as: Perform a comprehensive security review of this CloudFormation template and identify all deviations from our standards.
            3. Kiro will automatically apply your steering files as additional context when generating its response.
            4. Review the findings and iterate with follow-up prompts.

            Security categories evaluated: For the complete, up-to-date list of security categories and controls, see the AWS Well-Architected Framework Security Pillar documentation. Current categories include but are not limited to:

            • Identity and access management: Overly permissive IAM policies, missing multi-factor authentication (MFA) requirements, unused credentials and access keys, cross-account access risks
            • Detective controls: CloudTrail logging configuration, Amazon CloudWatch alarm coverage, GuardDuty enablement status, and AWS Config rule implementation
            • Infrastructure protection: Security group misconfigurations, public subnet exposure, missing AWS WAF rules, unencrypted network traffic
            • Data protection: Storage encryption status, KMS key rotation policies, backup configurations, S3 bucket access controls
            • Incident response: Amazon Simple Notification Service (Amazon SNS) alerting setup, log retention policies, automated response mechanisms

            Example output:

            Security Recommendations:
            - Enable S3 bucket encryption with KMS: Critical
            - Implement least privilege IAM policies: High
            - Enable GuardDuty threat detection: High
            - Configure VPC Flow Logs: Medium
            - Add WAF rules for API Gateway: Medium
            - Enable CloudTrail in all regions: Critical
            - Implement automated backup policies: High
            
            Total security improvements: 23 findings across 5 Well-Architected pillars

            Keeping your configuration files current:

            A security architect review remains valuable for keeping your steering files and rules documents complete and current. The goal is an AI assistant that already understands your environment, not one that needs correcting after every interaction. Treat your configuration files as living documents and update them when your security standards evolve, when new services are adopted, or when post-incident reviews reveal gaps. As this post notes, project rules reduce architectural drift and help maintain consistency as AI agents operate more autonomously.

            Real-world impact:

            Security reviews that previously required a security engineer to manually inspect infrastructure templates line by line can be completed in significantly less time with AI assistance. Teams using AI-assisted security reviews as a pre-commit gate—before code reaches CI/CD pipeline checks—report catching a meaningful portion of security findings earlier in the development cycle where they are faster and less costly to address. Integrating this review step into pull request workflows means security validation happens continuously rather than only at deployment gates.

            5. Assist with service control policy development

            You can use AWS Organizations Service Control Policies (SCPs) to apply preventive controls consistently across every account in your organization, enforcing security baselines without relying on individual account administrators. Kiro can generate initial SCP drafts from natural language security requirements, speeding up the drafting and iteration process considerably. Because SCPs are preventive controls that can’t be bypassed by administrators, misconfigurations can cause organization-wide service disruptions, making expert validation and staged testing essential before any SCP reaches production.

            Step 1: Generate an SCP draft:

            Describe your security requirements in natural language:

            "Create an SCP with these security controls:
            - Deny creation of S3 buckets without encryption
            - Require MFA for IAM user console access
            - Prevent public RDS snapshots
            - Deny security group rules allowing 0.0.0.0/0 on sensitive ports
            - Enforce encryption for all EBS volumes
            - Require VPC Flow Logs on all VPCs
            - Deny IAM policy creation without approval tags
            - Restrict resource creation to approved regions only"

            Kiro generates a complete SCP policy JSON with proper deny statements, condition keys for MFA and encryption enforcement, resource-level restrictions, and regional compliance requirements.

            Step 2: Validate and lint the SCP:

            Use Kiro or Amazon Q Developer to assist with policy linting and initial testing as a first layer of validation. IAM Policy Autopilot, available as a Kiro Power with one-click installation directly from the Kiro IDE, can analyze your application’s usage and generate necessary permissions based on the SDK calls it discovers. IAM Policy Autopilot also integrates as an MCP server with Kiro, Amazon Q Developer, and other MCP-compatible coding assistants, making it a natural part of your existing workflow rather than a separate tool.

            "Review this SCP JSON for syntax errors, overly broad deny statements, and missing condition keys. Flag any statements that could unintentionally block legitimate operations."

            The IAM Policy Simulator then adds another layer of validation on top of the AI-assisted linting, so you can test policy behavior, verify condition keys are correctly applied, and confirm that no legitimate operations are unintentionally blocked. IAM Policy Autopilot complements existing IAM tools such as IAM Access Analyzer by providing functional policies as a starting point, which you can then validate using IAM Access Analyzer policy validation or refine over time with unused access analysis. Together, these tools form a layered validation approach where each one strengthens the output of the previous step.

            Step 3: Test in a sandbox environment:

            Create a test organizational unit (OU) with non-production accounts and apply the SCP to the test OU. Attempt operations that should be blocked and confirm that no legitimate operations are unintentionally blocked. Use Kiro to pre-validate your infrastructure code against the proposed SCP before sandbox testing:

            "Analyze my current infrastructure against this proposed SCP and identify resources that would be non-compliant"

            This scan covers your infrastructure code files. For live account scanning across your organization, use the following AWS services:

            • AWS Config with the Config Aggregator and Conformance Packs for continuous compliance monitoring across your organization.
            • IAM Access Analyzer for automated reasoning-based analysis of external access, internal access, and unused permissions.
            • Account Assessment for AWS Organizations for bulk scanning of identity-based, resource-based, and service control policies across all accounts.
            • Security Hub for centralized aggregation of compliance findings and security scores across your entire organization.

            Step 4: Security architect review:

            Engage your security architects to identify potential risks and verify the policy aligns with your security framework. Check for conflicts with existing SCPs by reviewing all SCPs attached to parent OUs and the root in the AWS Organizations console. Use the IAM Policy Simulator to test interactions between policies and verify that emergency access procedures ( SEC03-BP03 Establish emergency access process – Security Pillar and SEC10-BP05 Pre-provision access – Security Pillar) remain functional before any production rollout.

            Step 5: Staged rollout:

            Deploy to development accounts first and monitor for policy violations and operational issues. Gradually expand to additional environments and maintain documented rollback procedures throughout the process.

            Important: It’s strongly recommended not to deploy AI-generated SCPs directly to production without thorough expert review and staged testing. A misconfigured SCP can cause organization-wide service disruptions affecting every account in your organization.

            Real-world impact:

            SCP drafting that previously required security architects to write and iterate on complex JSON policy documents manually, often spanning multiple review cycles over several days, can be condensed when AI handles the initial drafting and linting. Your architects can then focus their time on policy design, edge case analysis, and organizational impact assessment rather than JSON syntax and structure.

            Responsible implementation framework

            Adopting AI-assisted security workflows is most effective when introduced gradually, with clear validation gates at each stage. The following two-phase approach gives your team time to build confidence, measure results, and establish the internal practices needed before expanding to production environments.

            • Phase 1: Development and testing (weeks 1–4): Start by testing AI-generated security controls in isolated development accounts. Validate functionality, identify edge cases, and deploy to a dedicated testing environment with thorough security validation. Use IAM Access Analyzer, AWS Config, and Security Hub to verify that generated controls behave as expected. This phase is also the right time to build internal expertise across both your security team and your development teams, so that knowledge of what works and what requires human review is shared broadly from the start.
            • Phase 2: Staging and production (week 5 and later): Apply the validated controls to a staging environment that mirrors production. Conduct penetration testing where appropriate and validate that monitoring and alerting function correctly before expanding further. Gradually roll out to production accounts with continuous monitoring in place. Maintain rollback procedures throughout and establish feedback loops so that lessons learned in production flow back into your steering files, rules documents, and validation processes over time.

            Key takeaways

            What distinguishes the approach in this post from general guidance on AI coding assistants is the specificity of the security integration. There’s no shortage of content about how AI assistants accelerate development. What this post focuses on is how to configure both Kiro and Amazon Q Developer to perform security-specific tasks: triaging findings from Security Hub, remediating infrastructure code vulnerabilities against your organization’s defined standards, conducting Well-Architected security reviews, drafting and validating SCPs, and generating secure-by-default infrastructure through persistent context that reflects your environment rather than generic defaults.

            Kiro is an agentic IDE that helps you go from prototype to production with spec-driven development, and its steering files give the agent persistent awareness of your security standards across every session. Amazon Q Developer complements this by providing deep integration into your existing AWS environment and IDE workflows. Together, these tools extend your security team’s reach into every stage of the development lifecycle, scale security expertise into development teams, and reduce the gap between when vulnerabilities are introduced and when they are caught. As the AWS Well-Architected Framework Security Pillar establishes, embedding security early and consistently across the development process is foundational to a strong security posture.

            These five techniques aren’t about replacing your security controls. They’re about making security a natural part of how your teams build on AWS, regardless of whether they’re security specialists or application developers. In addition to the five techniques covered in this post, the following AWS capabilities complement this approach and are worth exploring for a more complete picture:

            • Amazon Inspector is a vulnerability management service that continually scans AWS workloads for software vulnerabilities, code vulnerabilities, and unintended network exposure. It automatically discovers and scans Amazon EC2 instances, container images in Amazon ECR, AWS Lambda functions, and first-party code repositories. Amazon Inspector integrates directly into CI/CD pipelines through plugins for Jenkins, TeamCity, GitHub Actions, and Amazon CodeCatalyst, which teams can use to catch vulnerabilities before deployment. Its code security capabilities include Static Application Security Testing (SAST), Software Composition Analysis (SCA), and infrastructure as code (IaC) scanning, with native integration to GitHub and GitLab. All findings are surfaced directly in Security Hub for centralized visibility and response across your organization.
            • Amazon Q Developer security scanning provides real-time security issue detection in the IDE, including SAST scanning for security vulnerabilities, secrets detection, IaC security evaluation, and software composition analysis for third-party dependencies. These capabilities are available across JetBrains, Visual Studio Code, and Visual Studio.
            • Kiro Powers are curated and pre-packaged MCP servers, steering files, and hooks validated by Kiro partners to accelerate specialized development and deployment use cases. Security-relevant Kiro Powers include the IAM Policy Autopilot Kiro Power for baseline IAM policy generation and the real-time coding security validation MCP server pattern for Kiro.
            • AWS Security Agent is a frontier AI agent that proactively secures your applications throughout the development lifecycle. Security teams define organizational security requirements once in the AWS Security Agent console, such as approved encryption libraries, authentication frameworks, and logging standards, and AWS Security Agent then automatically validates these requirements throughout development by evaluating architectural documents and code against your defined standards. It provides three core capabilities: design security review for architecture documents, code security review that automatically analyzes pull requests against your defined standards across connected repositories, and on-demand penetration testing that discovers, validates, and reports vulnerabilities through sophisticated multi-step attack scenarios customized for each application. When vulnerabilities are found, AWS Security Agent creates pull requests with ready-to-implement fixes directly in your code repository. Customers report that AWS Security Agent compresses penetration testing timelines from weeks to hours, transforming penetration testing from a periodic bottleneck into an on-demand capability that reduces risk exposure and scales security reviews to match development velocity.
            • AWS Security Hub automated response and remediation provides pre-built playbooks for common findings using AWS Systems Manager Automation, enabling your team to act on findings faster and more consistently.

            Getting started

            If you’re new to AI-assisted security workflows, the following week-by-week approach gives your team a practical path forward without overextending before the foundation is in place.

            • Weeks 1 and 2: Set up your persistent context files with your top 10 security policies as described in the foundational setup section above. Configure MCP servers in Kiro for Security Hub and CloudTrail access and verify that credentials are correctly configured for your target accounts.
            • Weeks 3 and 4: Run your first AI-assisted security review on a non-production infrastructure template. Compare the findings against your last manual review to establish a baseline for measuring impact over time.
            • Weeks 5 and 6: pilot AI-assisted SCP drafting for one new preventive control. Run the full validation workflow including AI-assisted linting, IAM Policy Autopilot, and the IAM Policy Simulator before any production application.
            • From that point forward: Measure the metrics outlined in the foundational setup section, update your steering files and rules documents as your standards evolve, and share findings across your security team, development teams, and platform engineering teams. The knowledge of what works and what requires human judgment is valuable to everyone who touches infrastructure in your organization.

            Conclusion

            Kiro and Amazon Q Developer give security teams practical tools to accelerate threat response and maintain consistent security coverage by handling the tasks that consume the most time with the least strategic value: scanning for known misconfigurations, drafting policy JSON, researching CVEs, and generating secure infrastructure. These AI assistants are most effective when paired with security engineers, as they accelerate assessments and code generation while human review, policy design, and risk judgment remain essential throughout.

            By implementing the five techniques outlined in this post, starting with embedding security best practices through persistent context and then applying that foundation to Security Hub finding triage, infrastructure code remediation, in-depth Well-Architected security reviews, and SCP development, your team can strengthen your AWS security posture while maintaining the standards your organization requires.

            AWS services such as Security Hub, IAM Access Analyzer, AWS Config, and CloudTrail provide the foundation for these AI-assisted workflows, enabling centralized visibility and automated validation of security controls across your environment. Emergency access procedures should be established and validated before deploying any preventive controls such as SCPs, following the break-glass guidance in the AWS Well-Architected Security Pillar and the AWS Prescriptive Guidance for break-glass access.

            Start small with non-production environments, establish clear validation processes, measure results, and gradually expand your use of AI assistants as your team builds expertise and confidence. The result is faster threat response, more consistent security coverage, and security engineers focused on complex decisions rather than repetitive tasks.

            Additional resources

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


            Roger Nem

            Roger Nem

            Roger is an Enterprise Technical Account Manager (TAM) supporting Healthcare & Life Science customers at Amazon Web Services (AWS). As a Security Technical Field community specialist, he helps enterprise customers design secure cloud architectures aligned with industry best practices. Beyond his professional pursuits, Roger finds joy in quality time with family and friends, nurturing his passion for music, and exploring new destinations through travel.

            •  

            Securing open proxies in your AWS environment

            This article shows you how to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP address reputation, and control costs.

            An open proxy is a server that forwards traffic on behalf of internet users without requiring authentication. While proxies can support legitimate use cases such as load balancing or caching, open proxies allow unrestricted access that threat actors can use to hide harmful activity. In Amazon Web Services (AWS) environments, open proxies often result from misconfigured Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, or compute resources such as AWS Lambda functions. These resources expose proxy functionality without access controls.

            Open proxies come in several forms. Common open proxies can include:

            • HTTP proxies: HTTP proxies forward HTTP requests to web servers, making them useful for web traffic management. These proxies can create potential issues when they’re unsecured.
            • SOCKS proxies: SOCKS proxies support a wider range of traffic types and provide more flexibility. These proxies create a broader potential for misuse.
            • Transparent proxies: Transparent proxies intercept traffic without the client’s knowledge and are often used to filter content. These proxies can become security liabilities when misconfigured.
            • Reverse proxies: Reverse proxies help with internal routing. Unauthorized users can misuse these proxies if they’re exposed.

            Knowing these risks can help you better protect your AWS environment.

            Security risks

            Because of the unrestricted configuration of open proxy servers, threat actors target them to conduct denial of service (DoS) events, intrusion attempts, distribute spam, and other forms of unauthorized activity. These open proxy servers allow threat actors to hide their actual IP address and other forms of identification from the intended targets.

            When your AWS infrastructure hosts an open proxy, several risks emerge that can affect both your operations and customers:

            • Threat actors can misuse your resources, which can result in your IP address being added to security service and reputation system block lists. This can affect your legitimate business operations and customer access. When external parties use your infrastructure for harmful activities, the reputation damage extends beyond immediate technical concerns to affect your ability to reach customers and partners.
            • Unexpected costs from resource consumption occur when threat actors use your bandwidth and compute capacity. The traffic patterns that proxy abuse generate can also alert AWS security monitoring systems and create additional operational overhead as you investigate and respond to these alerts.
            • Service disruptions might affect your legitimate workloads because unauthorized traffic competes for resources with your business-critical applications. This competition for resources can potentially degrade performance or cause availability issues for your customers.

            Implementing security measures

            To prevent the risks associated with open proxies, it’s essential to implement proper security controls for proxy services in AWS environments. The following guidance is a comprehensive approach that you can follow to secure your proxy infrastructure.

            Access control implementation

            An important security step is to use passwords and authentication mechanisms to restrict access to proxy services. Configure your proxies to accept connections only from known, trusted IP address ranges. For Elastic Load Balancing (ELB), limit access based on source IP addresses and add authentication to proxies behind the load balancers. When you create new instances in Amazon Elastic Kubernetes Service (Amazon EKS), limit access to your balancer in each instance. If instances don’t have public IP addresses, then you can limit access to the balancer instead. If instances have public IP addresses, then you must limit access to those IP addresses.

            When possible, use AWS PrivateLink virtual private cloud (VPC) endpoints to provide private connectivity to AWS services without exposing them to the internet. Deploy proxy services in private subnets with controlled outbound access through NAT gateways or other controlled channels. For Amazon EC2 and Amazon Lightsail resources, update the attached security group to prevent public internet access. To secure the proxy, you must either limit access to specific IP addresses or implement authentication on the endpoint.

            Authentication and authorization

            Turn on authentication for the proxy software and use strong credentials, certificates, or integration with AWS Identity and Access Management (IAM) and AWS Directory Service. Apply IAM policies with the principle of least privilege to limit access to only what users need to perform their tasks. This approach reduces the potential effects of credential compromise and helps maintain clear accountability for resource access.

            Monitoring and detection

            To detect unusual proxy activity, configure Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty. Use Amazon CloudWatch alarms to notify you of abnormal traffic patterns that might indicate unauthorized use of your proxy services. These monitoring capabilities provide visibility into your network traffic patterns and help you identify both legitimate usage and potential security concerns.

            Deployment best practices

            Use HTTPS for ELB traffic to protect data in transit, and restrict security groups to necessary ports to minimize the surface area for potential misuse. Integrate AWS WAF with balancers to filter web traffic based on rules that you define. You can also use AWS Network Firewall for advanced traffic filtering capabilities. For APIs, deploy Amazon API Gateway with authentication and authorization controls to manage access to your backend services. This layered approach to security helps protect your infrastructure at multiple points in the traffic flow.

            Regular security assessments

            Run Amazon Inspector to scan for misconfigurations in your infrastructure, and use AWS Security Hub to centralize security findings across your AWS environment. Conduct penetration tests in accordance with AWS policy to identify potential security issues before they can result in unintended access.

            Incident response planning

            Automate remediation with AWS Config rules and Automation, a capability of AWS Systems Manager, to respond rapidly to security events. Maintain incident response runbooks that outline clear steps for addressing proxy-related security incidents, and decommission unused resources that could become security liabilities.

            Documented procedures and automated responses reduce the time between detection and remediation and minimizes the potential effects of security incidents on your operations.

            Benefits of proper proxy security

            When you implement these security measures, you gain the following advantages for your AWS environment:

            • Protection of your IP address reputation helps maintain customer trust and prevents security services from blocking your legitimate traffic. When your infrastructure maintains a positive reputation, your business communications reach their intended recipients without interference.
            • Cost control prevents unauthorized users from consuming your AWS resources and generating unexpected charges on your account. When you restrict access to legitimate users and use cases, you maintain predictable costs that align with your business needs.
            • Operational stability reduces the risk of service disruptions that abuse of your proxy infrastructure can cause. When you dedicate your resources to serving your customers rather than supporting unauthorized activity, you can deliver consistent performance and availability.
            • Enhanced visibility into your network traffic patterns helps you identify both legitimate usage and potential security concerns. This awareness allows you to make informed decisions about capacity planning, security improvements, and operational optimizations.

            Conclusion

            Open proxies present a serious risk in AWS environments, but you can effectively secure proxies with the right measures. By implementing strict access controls and additional security practices such as authentication, monitoring, and regular assessments, you can prevent misuse, protect your infrastructure, and maintain your IP address reputation.

            Taking proactive steps strengthens your own environment and supports the broader security of the internet ecosystem. Under the AWS shared responsibility model, you’re responsible for the configuration and maintenance of these security controls, while AWS provides the underlying secure infrastructure. By following the guidance in this article, you can build a robust security posture that protects your proxy infrastructure while supporting your legitimate business needs.

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

            Dodd Mitchell

            Dodd Mitchell

            Dodd is a member of the AWS Trust and Safety team in Virginia, supporting customers in navigating abuse, phishing, and content-related risks. He works closely with partners to strengthen response processes and build more resilient, trustworthy platforms.

            •  

            Announcing the ISO 31000:2018 Risk Management on AWS Compliance Guide

            AWS Security Assurance Services is announcing the release of our latest compliance guide, ISO 31000:2018 Risk Management on AWS, which provides practical guidance for organizations establishing and operating a risk management program in AWS environments using ISO 31000:2018 principles.

            The guide explains how organizations can integrate AWS services into their risk management processes to support the core components of ISO 31000:2018, including establishing context and criteria, conducting risk assessments, implementing risk treatments, and enabling continuous monitoring and review. It also highlights how AWS security, automation, and monitoring capabilities can help customers identify areas for improvement and help enforce controls at large. The guide includes:

            • An overview of the ISO 31000:2018 risk management framework, including context and criteria, risk assessment, risk treatment, and monitoring and review. You will learn how to apply ISO 31000’s core principles within AWS environments and use AWS services for risk identification, detection, treatment, and monitoring.
            • Governance and risk treatment considerations aligned with the AWS Shared Responsibility Model. This includes strategies for risk avoidance, mitigation, transfer, and acceptance.

            By combining ISO 31000 risk management principles with AWS security services, organizations can build scalable, automated environments that help support continuous risk identification, proactive treatment, operational visibility, and ongoing compliance readiness.

            Download Available: ISO 31000:2018 Risk Management on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

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

            Jesse McMahan

            Jesse McMahan

            Jesse is a Sr. Security Assurance Consultant at AWS with over a decade of experience in information security, risk management, and compliance. He holds multiple industry and AWS certifications and leads security assessment and advisory engagements covering standards such as PCI DSS, NIST, SOC 2, HIPAA, and ISO 27001. A United States Marine Corps veteran, Jesse brings a disciplined, mission-focused approach to helping organizations align their security posture with regulatory and business objectives.

            Juan Rodriguez

            Juan Rodriguez

            Juan is a Security Assurance Consultant at AWS, where he works with Strategic Services and customers to assess and secure cloud environments against frameworks including CMMC, FedRAMP, GovRAMP, and NIST based practices. He holds his CMMC Certified Professional and AWS Certified Security – Specialty certifications. Juan pairs technical expertise with a research-driven mindset to help organizations strengthen and architect their security posture and align with federal and industry standards.

            Akanksha Chaturvedi

            Akanksha Chaturvedi

            Akanksha is a Senior Security Assurance Consultant with over 10 years of specialized experience in risk-based security assessments and regulatory compliance across highly regulated industries. Expert practitioner in HIPAA, PCI-DSS, GDPR, FedRAMP, and IRAP frameworks, with demonstrated success in architecting and deploying enterprise security programs from conception through full implementation. Known for delivering innovative, scalable solutions that strengthen security posture while streamlining operational processes aimed at reducing compliance overhead.

            Sana Rahman

            Sana Rahman

            Sana is a Senior Assurance Consultant with AWS Security Assurance Services, and has been a PCI DSS Qualified Security Assessor (QSA) for over a decade. She has extensive knowledge and experience in information security and governance, and deep compliance knowledge in both cloud and hybrid environments. She uses all of this to remove compliance roadblocks for AWS customers and provide guidance in their cloud journey.

            Mayur Jadhav

            Mayur Jadhav

            Mayur is a Senior Assurance Consultant at AWS with over a decade of experience in cloud security, governance, risk management, and compliance. He holds AWS Certified Solutions Architect and Zero Trust Certified Architect (ZTCA) certifications. His career spans leadership roles across organizations including Amazon, AWS, EY-Parthenon, and PwC, where he has advised senior executives on cybersecurity and compliance initiatives across healthcare, financial services, and technology sectors.

            •  

            Designing trust and safety into Amazon Bedrock powered applications

            Generative AI brings promising innovation, transforming how individuals and organizations approach everything from customer service to content creation and more. As AI continues to expand its capabilities, organizations are increasingly focused on how they can integrate the responsible AI concepts into the development lifecycle of their AI applications.

            Research from Accenture and Amazon Web Services (AWS) reveals compelling evidence for the business value of responsible AI practices, both internally within their organizations and externally to their users. Organizations that communicate a mature approach to responsible AI see an 82% improvement in employee trust in AI adoption, which directly leads to increased innovation. Additionally, companies that offer responsible AI-enabled products and services experience a 25% increase in customer loyalty and satisfaction.

            Understanding the core dimensions of responsible AI

            AWS identifies these key dimensions that form the backbone of responsible AI implementation:

            • Safety focuses on preventing harmful system output and misuse. This dimension focuses on steering AI systems to prioritize user and system safety.
            • Controllability focuses on mechanisms that monitor and steer AI system behavior. This dimension refers to the ability to manage, guide, and constrain AI systems to operate within specific parameters.
            • Fairness considers the impacts of AI on different groups of users.
            • Explainability focuses on understanding and evaluating system outputs.
            • Security and privacy focuses on making sure that data and models are appropriately obtained, used, and protected.
            • Veracity and robustness focuses on achieving correct system outputs, even with unexpected or adversarial inputs.
            • Governance makes sure that development, deployment, and management of AI systems align with ethical standards, legal requirements, and societal values.
            • Transparency focuses on understanding how AI systems make decisions, why the systems produce specific results, and what data the systems use.

            It’s a best practice to review and apply all these dimensions to your AI implementation. For more information, see Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications.

            The responsible AI lifecycle

            When you implement AI systems, you should build safety into every phase of the AWS responsible AI lifecycle. The responsible AI lifecycle consists of the following three phases, each with distinct responsibility considerations for the safety dimension:

            1. In the design and development phases, thoroughly evaluate potential safety risks. Understand what you want your AI application to do, what you don’t want it to do, and what you want to prevent it from doing. You should build safety guardrails into your systems from the beginning and make sure that your development teams understand the capabilities and limits of your AI application.
            2. In the deployment phase, theory meets reality. During this phase, you should implement robust safety measures through multiple layers, from comprehensive user training to proactive monitoring and review processes. Every application, product, and feature must include clear safety protocols and user guidelines. You must think beyond the launch of an application and consider how to launch a holistic safety framework. This framework—which can contain steps such as red team testing—must protect your brand, users, and stakeholders.
            3. In the operations phase, it’s important to maintain vigilance. Safety, like security, isn’t something you set up once and then ignore. Safety requires continuous monitoring and adaptation. To catch potential safety issues early, you can implement real-time feedback mechanisms to conduct regular performance evaluations. You can also continuously monitor for shifts in how your application is used, or functions that could compromise safety. Because safety considerations and risks evolve as technology evolves, it’s crucial to understand that adjustments are necessary over time.

            For more information, see the Responsible use of AI guide.

            Abuse detection

            Foundation models in Amazon Bedrock are inherently designed with safety mechanisms to prevent harmful outputs. However, you can implement additional input safety systems in production environments to provide critical early detection capabilities to identify problematic content, users, or patterns.

            Note: Amazon Bedrock might implement automated abuse detection mechanisms to identify potential violations of the AWS Acceptable Use Policy (AUP) and Service Terms, including the Responsible AI Policy or a third-party model provider’s AUP.

            See the Amazon Bedrock abuse detection document for more information.

            AI abuse prevention tools and techniques

            To maintain trust in your AI services, preventative action is key, while also efficiently planning and managing development resources. Introduce observability and safety guardrails early in development to support long-term scalability and help identify potential issues before they affect your users. To begin this process, thoroughly scope your AI use case with the following actions:

            • Understand your users
            • Anticipate potential misuse scenarios
            • Define your risk tolerance

            This scope guides your development of a precise safety framework that addresses the specific risks of your AI implementation while you maintain expected performance. For this scope, you can use AWS specialized tools designed specifically to monitor and protect Amazon Bedrock applications.

            Using CloudWatch to monitor Amazon Bedrock

            Amazon CloudWatch provides essential visibility into AI system behavior and performance. When you configure comprehensive logging, you can capture important information across user segments and interaction types, such as the following:

            • Request volumes
            • Response latencies
            • Rejection rates
            • Content filtering triggers

            You can use this information to identify potential abuse patterns or unexpected behaviors before they affect operations. CloudWatch dashboards visualize metrics according to monitoring priorities, and automated alerts provide prompt notification when you exceed thresholds. This infrastructure transforms interaction data into actionable insights and supports continuous safety improvement.

            Note: By default, Amazon Bedrock logging is turned off. You must turn on logging for your application. To configure this, contact your account manager.

            Using Amazon Bedrock Guardrails to customize safeguards

            Amazon Bedrock Guardrails offers configurable protection mechanisms tailored to specific risk profiles and content policies. You can customize Bedrock Guardrails to match your application requirements, such as:

            • Define domain-relevant undesirable topics
            • Configure appropriate content filtering thresholds
            • Configure sensitive information detection and redaction parameters aligned with data policies

            Additionally, you can configure controls that prioritize accuracy and prevent hallucinations while maintaining creative flexibility based on your application needs. When you thoughtfully configure Guardrails, you can balance performance and safety according to your specific use case requirements and risk factors.

            The abuse response process

            As AI safety evolves and new risks emerge, abuse might still occur even if you implement safety mechanisms. If you receive an abuse report from the AWS Trust & Safety team, then complete the following steps to help effectively address the issue:

            1. Acknowledge receipt: Acknowledge the receipt of the abuse report within 24 hours. If your team is still conducting their investigation, then inform AWS that the investigation is ongoing. Provide the number of days expected to complete the investigation.
            2. Investigate the issue: Thoroughly investigate the issue, including examining the logs (if enabled), reviewing Amazon Bedrock inputs, and checking for unauthorized access. While AWS abuse reports include a small sample of prompt IDs for you to investigate, investigate usage of your Amazon Bedrock application. Check for patterns to see if there’s a systemic issue that’s leading to abuse.
            3. Take appropriate action: If appropriate, take action to implement fixes, update safeguards, address violating users, or redesign features. Consider if you need systemic or root-cause fixes, rather than addressing one abusive end user. An abuse incident by one user could indicate vulnerabilities in your safety mechanisms that can lead to continuous abuse.
            4. Report back to AWS Trust & Safety: Following your investigation and implementation of fixes, provide an update to AWS Trust & Safety on your findings and remediation steps. Be transparent about what happened and how you addressed the issue. If you think that no violation occurred, then provide context on how you came to this conclusion. Include examples of the prompts and your business use case where possible.

            Conclusion

            To learn more about safety and responsible AI development, explore AWS resources, including the Responsible AI portal and machine learning best practices documentation. These resources provide additional tools and frameworks to build safe, effective AI systems that drive innovation and maintain safety standards.

            Victor Lungu Victor Lungu
            Victor is a Trust & Safety AI Abuse Specialist at AWS, based in Dublin. Victor works across a broad range of AI safety domains including content safety and emerging AI risks
            •  

            What the March 2026 Threat Technique Catalog update means for your AWS environment

            The AWS Customer Incident Response Team (AWS CIRT) regularly encounters patterns that repeat across their engagements when helping customers respond to security incidents. We’re passionate about making sure that information is widely accessible so that everyone can improve their security posture and their organization’s resilience to disruption. The primary method we use to share this information is the Threat Technique Catalog for AWS (TTC). The latest update to the catalog for March 2026 addresses identity, persistence, infrastructure destruction, and privilege escalation. Each new entry reflects something we’ve encountered in practice, and each provides straightforward mitigations. This post breaks down what changed, why it matters, and what you can do about it today.

            What we’re seeing

            Based on recent observations, we’ve added three new entries to the TTC.

            Cognito refresh token abuse: The quiet persistence mechanism

            Amazon Cognito refresh tokens are designed for convenience. They let applications obtain new access and ID tokens without requiring users to re-authenticate. The default lifetime is 30 days and is configurable up to 10 years. Cognito provides the flexibility to address a wide range of use cases, however the AWS CIRT has seen this lifetime window used by threat actors in an unauthorized way to maintain persistence by refreshing credentials.

            When a threat actor obtains a valid refresh token—through credential theft, compromised client-side storage, or elevated permissions—they can call cognito-idp:GetTokensFromRefreshToken to silently generate fresh tokens. The legitimate user’s session continues normally because their application independently refreshes tokens as needed—the threat actor’s refresh calls don’t invalidate the user’s token. This creates a parallel, persistent foothold that’s invisible to the user. In environments where refresh token rotation isn’t enabled, the same token can be reused indefinitely within its validity window.

            This method of gaining persistent access is often overlooked by response teams who were confident that the initial compromise was contained, only to discover ongoing unauthorized access weeks later through a refresh token they didn’t know existed.

            Enabling refresh token rotation and reducing the lifetime of tokens can help mitigate this risk. Dive deeper in the TTC (T1098.A006).

            AMI image deletion: Targeting recovery capabilities

            Amazon Machine Images (AMI) are a core part of many solutions and foundational to disaster recovery. They often contain the operating system, application configurations, and everything needed to rebuild your infrastructure. Threat actors know this, and we’re seeing ec2:DeregisterImage used to make it more difficult to recover from an incident.

            By default, when an AMI is deregistered, it’s gone. Recycle Bin retention rules can allow the recovery of the AMI, but if you haven’t explicitly enabled that functionality, there’s no way to undo the deregister action. Working with customers, we’ve seen cases where the impact of this action goes beyond the immediate loss because the threat actors have also removed the golden images the teams planned to restore from.

            The TTC has more information about how to detect and mitigate this technique, including how to enable Recycle Bin retention rules for key AMIs (T1485.A002).

            Additional cloud roles: The trust policy blind spot

            We’ve updated T1098.003: Additional Cloud Roles to now include UpdateAssumeRolePolicy as a tracked API call. We’ve seen an increase in the use of this call to avoid detections set to flag new role creation (iam:CreateRole). By modifying the trust policy of an existing role, a threat actor with sufficient permissions can use UpdateAssumeRolePolicy to subtly add an external account or an identity they control. No new roles appear. No new policies are created. The existing role simply trusts a new principal which the threat actor can assume.

            This persistence and privilege escalation technique blends into the volume of normal AWS Identity and Access Management (IAM) operations. It’s especially effective in environments with a large number of roles where trust policy changes aren’t actively monitored.

            The current trend

            A common thread runs through all three of these updates: threat actors are using subtle, default, or unexpected behaviors to sidestep detection. Refresh tokens working as designed. AMI deregistration completing without guardrails. Trust policies being modified through legitimate API calls. These actions might not trigger alarms in most environments because they look like normal operations.

            This is a shift worth paying attention to. Rather than relying on novel exploits or zero-days, the techniques we’re cataloging reflect threat actors who understand how cloud services work and use that knowledge to hide in plain sight. The implication for security teams is clear: prevention and detection strategies need to mature beyond monitoring for obviously malicious actions. Customers need to be watching for legitimate actions happening in illegitimate context—such as the right API call, made by the wrong principal, at the wrong time.

            The Threat Technique Catalogue for AWS is designed to help with exactly this. Each technique entry includes detection guidance and mitigations specific to AWS environments. We encourage teams to review the relevant entries and assess whether their current monitoring would catch these patterns:

            • T1098.A006: Cognito Refresh Token Abuse: Are you monitoring for cognito-idp:GetTokensFromRefreshToken from unexpected sources? Is refresh token rotation enabled?
            • T1485.A002: AMI Image Deletion: Do you have Recycle Bin retention rules protecting your critical AMIs? Would you know if a production AMI was deregistered outside a maintenance window?
            • T1098.003: Additional Cloud Roles: Are trust policy modifications tracked and alerted on? Could an external account be added to an existing role without anyone noticing?

            Each of these techniques leaves traces in AWS CloudTrail, and the TTC provides specific guidance on what to watch for and how to respond.

            Looking ahead

            The Threat Technique Catalog for AWS exists because we believe the patterns we observe during security engagements shouldn’t stay behind closed doors. When we see techniques repeating across customers, the most effective thing we can do is document them and make that knowledge available so you can act on it before you’re in the middle of an incident.

            This March update adds three new entries, and the catalog will continue to evolve. Our team regularly updates it based on what we’re seeing in the real world when helping customers respond to security events. We encourage security teams to review the catalog regularly, incorporate its techniques into threat modeling exercises, and use it as a shared vocabulary for discussing cloud-specific threats.

            Explore the full catalog: Threat Technique Catalog for AWS

            Additional resources

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


            Shannon Brazil

            Shannon Brazil

            Shannon is a security engineer on the AWS Customer Incident Response Team (CIRT), specializing in digital forensics and cloud security investigations. Known in the community as 4n6lady, she is passionate about security education and mentoring the next generation of defenders.

            Cydney Stude

            Cydney Stude

            Cydney is a security engineer specializing in threat intelligence and incident response at AWS. Cydney works on the ground in incident response and is passionate about turning observables into security outcomes. Cydney is an author and maintainer of the Threat Technique Catalog for AWS.

            •  

            Access control with IAM Identity Center session tags

            As organizations expand their Amazon Web Services (AWS) footprint, managing secure, scalable, and cost-efficient access across multiple accounts becomes increasingly important. AWS IAM Identity Center offers a centralized, unified solution for managing workforce access to AWS accounts. It simplifies authentication, enhances security, and provides a seamless user sign-in experience to AWS services across diverse environments.

            By combining IAM Identity Center permission sets with session tags, organizations can unlock powerful capabilities for fine-grained access control and resource optimization. You can use session tags to pass dynamic attributes from your external identity provider into AWS, enabling more context-aware permissions and better cost visibility. This integration makes it possible to use advanced AWS features such as AWS Glue usage profiles and AWS Systems Manager Session Manager run as to enforce fine-grained access control, so that administrators can dynamically map permissions and runtime configurations based on user attributes passed during federated access.

            In this post, I demonstrate how session tags derived from directory group attributes in Microsoft Entra ID can deliver functionality equivalent to AWS Identity and Access Management (IAM) role tags. Using role tags, you can implement attribute-based access control (ABAC) using IAM Identity Center, while maintaining centralized and efficient access management. To demonstrate this, you can configure an AWS Glue usage profile, as described in Introducing AWS Glue usage profiles for flexible cost control, where session tags can be passed through Identity Center and an external identity provider like Microsoft Entra ID. This approach is extensible to other AWS services such as AWS Systems Manager Session Manager (run as) and can also be used with other identity providers.

            User authentication and IAM Identity Center Federation flow

            The following figure shows the architecture and workflow of the solution.

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            The user authentication and federation flow includes the following steps:

            1. User accesses application using a browser.
            2. The enterprise application (configured in Azure) initiates authentication.
            3. Microsoft Entra ID handles sign-in.
            4. Users and groups are managed in Entra ID.
            5. A SAML trust is established between Entra ID and IAM Identity Center.
            6. SCIM provisioning syncs users and groups from Entra ID to AWS.
            7. Synced users and groups appear in Identity Center.
            8. Session tags are passed during SAML authentication.
              • Entra ID can send user attributes (department, role, cost center, project ID, and so on) as SAML attributes.
              • Identity Center consumes these as session tags, which are used for fine-grained access control and attribute-based access control inside AWS.
            9. Admins define permission sets for users and groups in Identity Center.
            10. Users get federated access to AWS using their Entra ID credentials.
            11. Users sign in through AWS Management Console or AWS Command Line Interface (AWS CLI) using those permissions.
            12. Access is granted to specific AWS accounts under AWS Organizations.

            Prerequisites

            To follow the steps in this post, you need the following prerequisites:

            1. An organization instance of IAM Identity Center enabled.
            2. A Microsoft Entra ID tenant. For more information, see Quickstart: Create a new tenant in Microsoft Entra ID.
            3. Access to an external identity provider such as Microsoft Entra ID to federate users into AWS. You can enable federated access between Microsoft Entra ID and IAM Identity Center by completing the steps in Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center. They include configuring SAML and SCIM integration between the two systems, testing the SAML connection to help ensure authentication is functioning correctly, and enabling SCIM synchronization to automate user and group provisioning.

            Solution implementation

            With the prerequisites in place, you’re ready to configure access control through IAM Identity center tags by using the following steps.

            1. Create an AWS Glue usage profile as described in Introducing AWS Glue usage profiles for flexible cost control in Create an AWS Glue usage profile. For the purposes of this post, create a profile named developer.
              1. On the AWS Management Console for AWS Glue, choose Cost management in the navigation pane.
              2. Choose Create usage profile.
              3. For Usage profile name, enter developer.
              4. Under Customize configurations for jobs, for Number of workers, for Default, enter 20.
              5. For Default worker type, select G.1X.
              6. For Allowed worker types, select G.1XG.2XG.4X, and G.8X.
              7. For Customize configurations for sessions, configure the same values.
              8. Choose Create usage profile.

              Figure 2 – Glue usage profile creation on the console

              Figure 2 – Glue usage profile creation on the console

            2. Create a custom permission set instead of using predefined ones. Attach the following AWS Managed Policies to the custom permission set:
              • AWSGlueConsoleFullAccess
              • IAMReadOnlyAccess

              Note: For fine-grained access control, you can create custom permission sets by combining AWS managed, customer managed, and inline policies in IAM. In this post, you use AWS managed policies with intentionally broad permissions for simplicity. In production, always follow the principles of least privilege and scope permissions appropriately.

              By default, when you create a permission set, the permission set isn’t provisioned (used in any AWS accounts). To provision a permission set in an AWS account, you must assign IAM Identity Center access to users or groups in the account and then apply the permission set to those users and groups. For more information, see Assign user or group access to AWS accounts.

            3. Configure user attributes in Microsoft Entra ID for access control in IAM Identity Center as described in Step 5 of Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center to set up ABAC. Add claim conditions for attribute mapping based on Entra ID group membership. Assign the developer value for users in a corresponding group. This enables logic such as Users in this group receive this profile or All users receive this profile. When using an AWS Glue profile and when making API calls to create AWS Glue resources, admins need to tag the user or role with glue:UsageProfile as the key and the profile name as the value.
            4. Next, sign in to the enterprise application that you created in the previous step, which has SCIM and SAML connections set up to IAM Identity Center:
              1. Sign in to Azure.
              2. Choose Enterprise applications.
              3. Select the application that you created
                Figure 3 – An enterprise application created in Microsoft Entra ID

                Figure 3 – An enterprise application created in Microsoft Entra ID

            5. When you’re signed in to your application, select Manage and then Single sign-on in the navigation pane, then select Attributes & Claims.
              Figure 4 – Attributes & Claims section in Microsoft Entra ID

              Figure 4 – Attributes & Claims section in Microsoft Entra ID

            6. Configure the key value pair that will used as session tags by selecting Add new claim.
              Figure 5 – Configuring attributes by adding a new claim

              Figure 5 – Configuring attributes by adding a new claim

            7. For Name, enter AccessControl:<AttributeName>. Replace <AttributeName> with the name of the attribute you are expecting in IAM Identity Center. For this example, use AccessControl:glue:UsageProfile.
            8. In Claim conditions set the following:
              • User type, select Members
              • Source, select Attribute.
              • Value, enter developer (without quotation marks).

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

            It’s important to note that the tags are being assigned based on group membership in Microsoft Entra ID. This approach lets you manage access and configuration dynamically without needing to set tags individually for each user. By assigning the tag to a Microsoft Entra ID group, anyone signing in to IAM Identity Center and who is in that group will automatically have the tag value applied to their session.

            Test the solution

            Now that the required configuration is complete, test the setup using the developer usage profile created as part of the Solution implementation section. Sign in as your user through Microsoft Entra ID using https://myapps.microsoft.com/ and verify the job creation using the following steps mentioned.

            To verify successful job creation:

            1. Open the AWS Glue console using the developer usage profile.
            2. In the navigation pane, choose ETL jobs.
            3. Select Script editor, then choose Create script.
            4. Create a new job using the values you want to validate.

            The green banner at the top of the screen should say Successfully updated job.

            Figure 7 – Successful AWS Glue job creation with configured parameters for the <em>developer</em> usage profile

            Figure 7 – Successful AWS Glue job creation with configured parameters for the developer usage profile

            Validation using AWS CloudTrail

            Examine the AssumeRoleWithSAML event using AWS Cloudtrail. Use the following steps to verify the sequence of events.

            1. Navigate to the CloudTrail console.
            2. Select Event history.
            3. In the Lookup attributes dropdown, select Event name.
            4. Set the event name to AssumeRoleWithSAML.
            5. Open a relevant event and inspect the requestParameters section.
            6. Confirm that the expected session tags appear under PrincipalTags.
            Figure 8 – ABAC tags passed during the role assumption

            Figure 8 – ABAC tags passed during the role assumption

            Using session tags for other use cases

            The concepts discussed in this post can be extended to configure AWS Systems Manager Session Manager Run As support for federated users using session tags. By default, Session Manager launches sessions using a system-generated ssm-user account. For Linux instances, you can optionally configure sessions to run as a specific OS-level user through Session Manager preferences. You can configure your identity provider to pass the user attribute (AccessControl: SSMSessionRunAs and name of an OS user account for the key value during federation and the session will be tagged using the attribute value.

            Clean up

            To avoid incurring future charges, delete any resources created during this walkthrough if they’re no longer needed:

            1. Remove the IAM Identity Center instance and clean up the associated enterprise application in Microsoft Entra.
            2. Delete the AWS Glue usage profile.
            3. Remove any other AWS resources you provisioned for testing the solution.

            Conclusion

            In this post, you learned how to federate access to AWS using AWS IAM Identity Center and SAML 2.0 identity providers like Microsoft Entra ID, enabling a secure, scalable, and centralized approach to managing user access across multiple AWS accounts. By using permission sets, reserved IAM roles, and session tags, organizations can implement fine-grained ABAC without the complexity of managing individual IAM users or static roles.

            As cloud environments become more complex, adopting modern identity federation and ABAC through IAM Identity Center helps security teams maintain control while providing users with seamless, context-aware access to the resources they need.

            Resources

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

            Rashmi Iyer

            Rashmi Iyer

            Rashmi is a Senior Solutions Architect at AWS, supporting financial services enterprises in building secure, resilient, and scalable cloud architectures while ensuring compliance with industry best practices. With over 15 years of experience in the private telco cloud, she has designed and architected complex telecom solutions, specializing in the packet core domain, the backbone of mobile data networks.

            •  

            Optimize security operations through an AWS Security Hub POC

            April 27, 2026: This post was first published in September 2025 when the enhanced AWS Security Hub was in public preview. It has since been updated to reflect the general availability of Security Hub. This revision also provides a more detailed, step-by-step framework for planning your POC.


            AWS Security Hub prioritizes your critical security issues and helps you respond at scale to protect your environment. The service sharpens findings through aggregation, correlation, and enrichment of AWS native security signals into actionable insights, enabling faster and more efficient response times. You can use these capabilities to gain visibility across your cloud environment through centralized management in a unified cloud security solution. Security Hub creates a cloud-native application protection platform (CNAPP) and through the AWS free trial, you can create a comprehensive proof of concept (POC) evaluation without significant upfront investment in time or resources.

            In this blog post, we guide you through planning and implementation POC for Security Hub to assess the implementation, functionality, cost estimate, and value of Security Hub in your environment. We walk you through the following steps:

            1. Understand the value of Security Hub
            2. Determine success criteria for the POC
            3. Define Security Hub configuration
            4. Prepare for deployment
            5. Enable Security Hub
            6. Validate deployment

            Understand the value of Security Hub

            Figure1: AWS Security Hub overview

            Figure 1: AWS Security Hub overview

            Figure 1 provides a visualization of how Security Hub unifies signals from multiple AWS security services, partner solutions capabilities. The signals, which are ingested by Security Hub from multiple AWS security services and curated partner solutions include:

            At its core, Security Hub provides four key capabilities in one unified solution:

            1. Unified security operations: Security Hub delivers a unified security operations experience, bringing your security signals into a single consolidated view and avoiding the need to switch between multiple security tools. This provides comprehensive visibility across your entire estate, including AWS, multi-cloud, and on-premises, so your security teams can efficiently detect, prioritize, and respond to potential security risks.
            2. Intelligent prioritization helps focus on what matters most: Security Hub helps you identify and prioritize critical security risks that might be missed when viewing findings in isolation. Security findings are correlated by analyzing resource relationships and signals from AWS security services and capabilities.
            3. Actionable insights guide security teams on next steps: Gain actionable insights through advanced analytics to transform correlated findings into clear, prioritized insights that highlight the most critical security risks in your environment. You can quickly understand potential impacts, visualize relationships, and identify which security issues pose the greatest risk to critical resources.
            4. Streamlined security response and automation capabilities: Security Hub enhances your security operations by enabling streamlined response capabilities. It seamlessly integrates with your existing ticketing systems to help facilitate efficient incident management.

            With this integrated approach your security team can:

            • Investigate critical risks that need immediate attention from a single pane of glass
            • Monitor security trends and attack surface across your environments
            • Fix what really matters across the entire attack chain and path
            • Automate responses to streamline remediation

            Understand the Open Cybersecurity Schema Framework

            Security Hub uses the Open Cybersecurity Schema Framework (OCSF) to help standardize security data and analysis and enable better integration between security tools. This standardization helps simplify how security findings are structured and analyzed across your environment. This standardized data model enables seamless integration and data exchange across your security tooling, providing normalized and consistent data formats. When implementing your Security Hub POC, make sure that you’re familiar with the OCSF specifications Security Hub uses.

            Additionally, confirm that any analytics or security information and event management (SIEM) tools you plan to integrate with support the OCSF data format to maximize the value of the consolidated security insights provided by Security Hub.

            Determine success criteria

            Establishing success criteria helps benchmark the outcomes of the POC with the goals of the business. Some example criteria and key performance indicators (KPI) include:

            • Alert consolidation metrics: Determine what resources you’re currently using to correlate security events and signals to understand their relationship. Review the process and note if it’s completed outside of AWS or through a SIEM. By setting a benchmark to reduce correlation overhead you can significantly improve efficiency and accelerate security investigations and posture improvement.
            • Response time improvements: Reducing your time to detect, investigate, and resolve security events and improve security posture is essential to streamlined security operations. Security Hub provides visualizations for potential attack paths that adversaries could use to exploit resources and helps assess the potential blast radius.
              • Reduced mean time to detect (MTTD) security incidents.
              • Reduced mean time to response (MTTR) for critical findings.
              • Reduced time to identify potentially affected resources in blast radius.
              • Increased accuracy of attack path analysis.
              • Number of controls implemented based on attack path insights (post investigation).
            • Automation capabilities: Having response playbooks as part of your incident management and response plan helps ensure comprehensive investigations lead to improved security posture. Review your automation capabilities to see if portions of or entire playbooks can be automated.
              • Potentially increased percentage of security findings automatically routed to the correct teams by using Jira Cloud, ServiceNow, or a third-party tool.
              • Reduced average time from detection to ticket creation.
            • Severity and risk classification: Review your organization’s inventory of assets to determine if it’s complete and if you can use telemetry to determine the severity level and associated risks.
              • Reduced time to identify critical resources and service coverage gaps affected by new vulnerabilities, threats, and misconfigurations.
              • Faster and more accurate severity label and risk calculation of findings.
              • Reduced time to identify service gap coverage.

            After establishing your success criteria, it’s essential to evaluate organizational readiness and potential constraints that might impact your POC implementation. Begin by conducting a comprehensive assessment of your current environment: Determine if the foundational security services (GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie) are enabled across your accounts, and identify your critical workloads and if there are any excessive attack surfaces.

            Review your success criteria to make sure that your goals are realistic given your timeframe and potential constraints that are specific to your organization. For example:

            • Do you have full control over the configuration of AWS services that are deployed in an organization?
            • Do you have resources that can dedicate time to implement and test?
            • Is this time convenient for relevant stakeholders to evaluate the service?

            Maximize your POC value through service activation

            To get the most comprehensive evaluation of the capabilities of Security Hub, coordinate the activation of underlying security services to optimize the overlapping trial periods available at no additional cost. The following is a list of the underlying security services, and their free trial length:

            • Security Hub: 30-day trial (essential plan capabilities)
            • GuardDuty: 30-day trial (covers most protection plans except GuardDuty Malware Protection)
            • Security Hub CSPM: 30-day trial
            • Macie: 30-day trial
            • Amazon Inspector: 15-day trial

            Consider enabling these services simultaneously so that you have at least two weeks of overlapping coverage to evaluate the full correlation and risk prioritization capabilities of Security Hub across each service. Optionally, if you want to conduct a POC with minimal configuration because of limitations, you can enable only Security Hub CSPM and Amazon Inspector during the initial POC phase to properly assess the results and data.

            Note: Document your activation dates and trial expiration dates carefully. Create calendar reminders for trial end dates and schedule your key POC evaluation milestones to occur while services are active. This will help make sure that you can thoroughly assess the unified security operations capabilities of Security Hub when services are running at full capacity.

            If you already have one or more of these underlying services enabled, you can proceed to enable the new Security Hub. To fully use the new Security Hub capabilities, particularly the exposure findings feature, specific service dependencies must be met, both Security Hub CSPM and Amazon Inspector are essential because they provide the telemetry needed for the Security Hub correlation engine and exposure findings. The combination enables Security Hub to deliver comprehensive risk analysis and prioritization by correlating configuration risks with runtime vulnerabilities. If you have other security services already enabled (such as GuardDuty or Macie), you can maintain these existing services while enabling Security Hub, and it will automatically begin incorporating their findings into its consolidated view, enhancing your overall security posture visualization.

            Define your Security Hub configuration

            After your success criteria have been established, you’re ready to plan your configuration. Some important decisions include:

            • Select a delegated administrator: From the AWS Organizations management account, you can set a delegated administrator for your organization. As a best practice, we recommend using the same delegated administrator across security services for consistent governance and according to our AWS Security Reference Architecture (AWS SRA).
            • Select accounts in scope: Define accounts you want to have Security Hub enabled for.
            • Define AWS Regions: Determine Regional restrictions or considerations.
            • Determine AWS service integrations: In addition to the core security capabilities of posture management and vulnerability management, Security Hub integrates signals from other AWS security services such as GuardDuty and Macie.
            • Define third-party integrations:
              • For ticketing, Security Hub integrates with popular service management systems such as Atlassian’s Jira Service Management Cloud and ServiceNow.
              • Partners who already support or intend to support the OCSF schema to receive findings from Security Hub include companies such as Arctic Wolf, CrowdStrike, DataBee, Datadog, DTEX Systems, Dynatrace, Fortinet, IBM, Netskope, Orca Security, Palo Alto Neworks, Rapid7, Securonix, SentinelOne, Sophos, Splunk, Sumo Logic, Tines, Trellix, Wiz, and Zscaler.
              • Service partners such as Accenture, Caylent, Deloitte, IBM, and Optiv can help you adopt Security Hub and the OCSF schema.
            • Use the Security Hub cost estimator: Use the Security Hub Cost Estimation Tool for a pre-enablement cost estimate based on your current spend on Amazon Inspector, Security Hub CSPM, and GuardDuty.

            Prepare for deployment

            After determining your success criteria and Security Hub configuration, identify stakeholders, desired state, and timeframe. Prepare for deployment by completing:

            • Project plan and timeline: Develop a project plan with defined success criteria, scope boundaries, key milestones, and realistic implementation timelines. Suggested timeline of events:
              • Before enablement:
                • Validate core security service configuration for GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie
                • Request approvals for free trial from appropriate stakeholders
              • Day 0 – Enable the service, become comfortable with the Security Hub layout and begin training security personnel
              • Week 1 – Validate desired coverage of threat detection, vulnerability management, and posture management across accounts and Regions
              • Week 2 – Connect to IT service management (ITSM) tools and begin creating automations for critical workloads and resources
              • Week 3 – Execute a tabletop exercise in response to a selected exposure finding
              • Week 4 – Analyze trends of threats and exposures from day 1 through week 4
            • Identify stakeholders: Identify CISO, information security teams, SOC personnel, incident response teams, security engineers, finance, legal, compliance, external MSSPs, and business unit representatives.
            • Develop a RACI matric: Create a detailed RACI chart defining roles and responsibilities across the incident response lifecycle, facilitating accountability and proper communication channels.
            • Configure management account access: Secure authorization to delegate administrative access. For more information, see Permissions required to designate a delegated Security Hub administrator account.
            • Set up IAM roles and permissions: Use AWS Identity and Access Management (IAM) roles to implement role-based access controls aligned with the RACI chart, including case management, escalation, and read-only roles using AWS managed policies. For more information, see AWS Managed Policies

            Enable Security Hub

            AWS security services integrate with AWS Organizations to help you centrally manage Security Hub.

            1. If you haven’t already done so, enable Security Hub CSPM and Amazon Inspector at a minimum. Also enable any other AWS security services that you want to integrate with Security Hub.
            2. Enable Security Hub for your organization from the organization management account.
            3. If setting a delegated administrator for Security Hub, see Setting a delegated administrator account in Security Hub from the management account.

              Note: As a best practice, we recommend using the same delegated administrator across security services for consistent governance.

            4. Sign in to the delegated administrator with an IAM policy that gives you permission to enable and disable member accounts. With this policy, you will have granular control to decide what Regions you want enabled.
            5. Configure Security Hub plans for deployment. Security Hub comes with the Essentials, Threat Analytics, and Extended plans.
            6. Configure third-party integrations to create incidents or issues for Security Hub findings.

            Note: After you enable Security Hub, exposure findings in your environment are created and analyzed immediately. However, it can take up to 6 hours to receive an exposure finding for a resource.

            Validate deployment

            The final step is to confirm that Security Hub is configured correctly and to evaluate the solution against your success criteria.

            • Validate policy: Verify that you have the correct permissions to manage member accounts and Regional restrictions are configured correctly.
            • Validate integrations: Verify that tickets with ServiceNow or Jira Cloud are working correctly by signing in to the AWS Management Console for Security hub and choosing Inventory in the navigation pane. Select Findings and verify there is a ticket ID in your finding.
            • Assess success criteria: Determine if you achieved the success criteria that you defined at the beginning of the project.

            Conclusion

            In this post, we showed you how to plan and implement an effective Security Hub POC. You learned how to do so through phases, including defining success criteria, configuring Security Hub, and validating that Security Hub meets your business needs. Take advantage of the trial periods to maximize your testing window without incurring significant costs. Throughout the POC, maintain focus on your predefined success criteria while remaining open to unexpected benefits or challenges that might arise. Maintain open communication with your AWS account team to address any questions or concerns to help you get the most out of your Security Hub POC experience.

            Additional resources

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

            Kyle Shields

            Kyle Shields

            Kyle is a Security Specialist Solutions Architect focused on threat detection and incident response at AWS. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS Security Incident Response and improve their security posture.

            Ahmed Adekunle

            Ahmed is a Security Specialist Solutions Architect focused on detection and response services at AWS. Before AWS, his background was in business process management and AWS technology consulting, helping customers use cloud technology to transform their business. Outside of work, Ahmed enjoys playing soccer, supporting less privileged activities, traveling, and eating spicy food, specifically African cuisine.

            Author

            Marshall Jones

            Marshall is a Worldwide Security Specialist Solutions Architect at AWS. His background is in AWS consulting and security architecture and focused on a variety of security domains including edge, threat detection, and compliance. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS security services to increase security effectiveness and reduce risk.

            •  

            Can I do that with policy? Understanding the AWS Service Authorization Reference

            Understanding what AWS Identity and Access Management (IAM) policies can control helps you build better security controls and avoid spending time on approaches that won’t work. You’ve likely encountered questions like:

            • Can I use AWS Organizations service control policies (SCPs) to prevent the creation of security groups that allow traffic from 0.0.0.0/0?
            • Can I block uploads unless objects are encrypted?
            • Can I prevent functions with more than 512 MB of memory allocated?

            Some of these are possible with IAM policies. Others are not. The difference is determined by a fundamental principle of AWS authorization: Policies make decisions based on information available in the authorization context at the time of the API call.

            In this blog post, you learn how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios that need alternative solutions, and build more effective security controls in your AWS environment.

            Understanding AWS authorization context

            When you make an AWS API request through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDK, the specific AWS service (such as Amazon S3 or Amazon EC2) receiving the request assembles a request context containing information about that request. This context is used for policy evaluation decisions. Request context is structured using the Principal, Action, Resource, Condition (PARC) model, which has four key components.

            • Principal: Identifies the requester and their attributes (tags, session context)
            • Action: Specifies the AWS API operation being requested (for example, s3:PutObject, ec2:RunInstances)
            • Resource: Defines the target AWS resource using Amazon Resource Names (ARNs)
            • Condition: Provides additional context available at request time, such as IP address, time, encryption parameters, MFA status, and service-specific attributes

            The following example shows the typical request context for an Amazon S3 object upload:

            • Principal: AIDA123456789EXAMPLE
            • Action: s3:PutObject
            • Resource: arn:aws:s3:::my-bucket/documents/samplereport.pdf
            • Condition:
              • aws:PrincipalTag/Department=Finance
              • aws:RequestedRegion=us-east-1
              • aws:SourceIp=x.x.x.x
              • aws:MultiFactorAuthPresent=true
              • s3:x-amz-server-side-encryption=AES256
              • s3:x-amz-storage-class=STANDARD_IA

            IAM policies can evaluate request metadata like encryption method and storage class being specified. However, it cannot evaluate the actual file contents, object size, or specific data patterns. Policy evaluation occurs at the time of the request, using the information present in the authorization context.

            An essential resource: The Service Authorization Reference

            The Service Authorization Reference is the authoritative documentation for understanding what policies can control. For every AWS service, it documents:

            • Actions: Every controllable operation
            • Resources: Resource types that can be targeted
            • Condition keys: The exact context information available for policy decisions

            Condition keys are broadly divided into two categories. Global condition keys, which can be used across AWS services, and service-specific condition keys, which are defined for use with an individual AWS service. Use the Service Authorization Reference to find the global-condition keys or service-specific condition keys for each AWS service.

            How to use the Service Authorization Reference

            Follow these steps to determine if your requirement can be controlled with IAM policies:

            1. Navigate to your service: Go to the page for the specific AWS service you’re working with, such as Actions, resources, and condition keys for Amazon S3.
            2. Find the action you want: Find the API operation you want to control. Be precise, different actions have different available condition keys.
            3. Examine available condition keys: The Condition keys column shows what context information AWS makes available for that action.
            4. Make your feasibility determination: If the information you need isn’t listed as a condition key, you will not be able to control it with IAM policies alone.

            Let’s take an example from the Amazon Elastic Compute Cloud (Amazon EC2) ec2:RunInstances action to see what you can and can’t control. In the Service Authorization Reference under the Amazon EC2 section, examine the RunInstances action and check the Resource types column. The RunInstances action affects multiple resource types, each with its own set of condition keys.

            For the instance* resource type:

            • ec2:InstanceType: Can restrict instance types
            • ec2:EbsOptimized: Can require EBS optimization
            • aws:RequestTag/: Can enforce tagging requirements

            For the network-interface* resource type:

            • ec2:Subnet: Can control subnet placement
            • ec2:Vpc: Can limit to specific virtual private clouds (VPCs)
            • ec2:AssociatePublicIpAddress: Can control public IP assignment

            Note: These are a few examples from the many condition keys available for each resource type under the RunInstances action. The Service Authorization Reference lists dozens of condition keys across resource types (instance, network interface, security group, subnet, volume, and so on) that RunInstances affects. Consult the complete reference to see the available options for your specific use case.

            Access the Service Authorization Reference programmatically

            Beyond the human-readable documentation, AWS provides the Service Authorization Reference in machine-readable JSON format to streamline automation of policy management workflows. Use this programmatic access to incorporate authorization metadata into your development and security workflows.
            For detailed information about the JSON structure and field definitions, see the Simplified AWS service information for programmatic access.
            Developers can use tools like the IAM MCP Server for AWS IAM operations. This server provides AI assistants with the ability to manage IAM users, roles, policies, and permissions while following security best practices.

            Using IAM policies to control specific scenarios

            The following examples show how you can use IAM policies to control specific scenarios.

            Example 1: Enforce AES256 server-side encryption on S3 objects

            In the Amazon S3 Service Authorization Reference, under s3:PutObject action, the s3:x-amz-server-side-encryption condition key is available in the authorization context, which can be used to control the server-side encryption of S3 objects with AES-256. Here is the required policy.

            Policy 1: Deny Amazon S3 object upload if the encryption doesn’t use AES-256

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Sid": "DenyUnencryptedObjectUploads",
            			"Effect": "Deny",
            			"Action": "s3:PutObject",
            			"Resource": "arn:aws:s3:::my-bucket/*",
            			"Condition": {
            				"StringNotEquals": {
            					"s3:x-amz-server-side-encryption": "AES256"
            				}
            			}
            		}
            	]
            }

            Policy 1 is a resource-based policy that can be applied on an S3 bucket to restrict object uploads. It denies a PutObject request when the server-side encryption isn’t using the AES-256 encryption algorithm.

            Example 2: Allow different instance types based on the user’s cost center tag.

            When checking the Amazon EC2 Service Authorization Reference for ec2:RunInstances, the ec2:InstanceType condition key, which is resource specific, is available. To restrict instance types based on who is launching them (rather than just what is being launched), you can either combine this with a global condition key or attach different policies to different principals. By using aws:PrincipalTag/tag-key alongside ec2:InstanceType, you can identify the user’s cost center from their IAM identity tags and then apply different instance type restrictions accordingly. This allows a single policy to dynamically enforce different permissions based on the requester’s identity.

            Policy 2: Restricting EC2 instance types by cost center

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Sid": "AllowDevInstanceTypes",
            			"Effect": "Allow",
            			"Action": "ec2:RunInstances",
            			"Resource": "arn:aws:ec2:*:*:instance/*",
            			"Condition": {
            				"StringEquals": {
            					"aws:PrincipalTag/CostCenter": "Development"
            				},
            				"StringLike": {
            					"ec2:InstanceType": "t3.*"
            				}
            			}
            		},
            		{
            			"Sid": "AllowProdInstanceTypes",
            			"Effect": "Allow",
            			"Action": "ec2:RunInstances",
            			"Resource": "arn:aws:ec2:*:*:instance/*",
            			"Condition": {
            				"StringEquals": {
            					"aws:PrincipalTag/CostCenter": "Production"
            				},
            				"StringLike": {
            					"ec2:InstanceType": [
            						"m5.*",
            						"c5.*",
            						"r5.*"
            					]
            				}
            			}
            		}
            	]
            }

            This is an identity-based policy that you can attach to IAM users, groups, or roles to control EC2 instance launches based on cost allocation. In the first statement, aws:PrincipalTag, which is a global condition key (tags attached to the IAM user or role), is used to determine which instance types are allowed. Users tagged with CostCenter=Development can only launch cost-effective T3 instance types (t3.micro, t3.small, t3.medium, and so on)with the service specific key ec2:InstanceType.

            In the second statement, users tagged with CostCenter=Production can launch more powerful instance types from the M5 (general purpose), C5 (compute optimized), and R5 (memory optimized) families. This approach lets organizations enforce cost controls and allocate resources based on workload requirements. Each cost center maintains flexibility for its specific needs.

            Note: Additional resources are required in the IAM policy to successfully launch EC2 instances. For the complete list, see Launch Instances.

            Example 3: Users can only access and update DynamoDB items where the partition key matches their username.

            You have identified that GetItem, PutItem,and UpdateItem actions are required. Corresponding to these actions, you can use the condition key to expose partition key values in the authorization context as described in the Amazon DynamoDB Service Authorization Reference

            Policy 3: DynamoDB fine-grained access control

            {
            	"Version": "2012-10-17",
            	"Statement": [
            		{
            			"Effect": "Allow",
            			"Action": [
            				"dynamodb:GetItem",
            				"dynamodb:PutItem",
            				"dynamodb:UpdateItem"
            			],
            			"Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/UserProfiles",
            			"Condition": {
            				"ForAllValues:StringEquals": {
            					"dynamodb:LeadingKeys": ["${aws:username}"]
            				}
            			}
            		}
            	]
            }

            The policy allows users to perform read and write actions (GetItem, PutItem, and UpdateItem) on the UserProfiles table, but only for items where the partition key value equals their own username (using the ${aws:username} policy variable). For example, if user alice attempts to access an item with partition key bob, the request will be denied.

            Scenarios that need more than policies alone

            Some requirements can’t be met using IAM policies. Here are three common scenarios that aren’t achievable with IAM policies alone.

            Scenario 1: Block users from creating security group rules that allow traffic from 0.0.0.0/0 on TCP port 22

            Upon checking the Amazon EC2 Service Authorization Reference, you will find that the ec2:AuthorizeSecurityGroupIngress action is required in an IAM policy to add an inbound access rules to a security group.

            To verify this in the Service Authorization Reference, navigate to the Amazon EC2 Service Authorization Reference and search for the AuthorizeSecurityGroupIngress action, which is the action that creates security group rules. After you locate this action, review the Condition keys column and look for condition keys related to CIDR blocks, IP ranges, ports, or protocols. Available condition keys for ec2:AuthorizeSecurityGroupIngress include:

            Notice there are no condition keys for CIDR blocks (such as 0.0.0.0/0), port numbers (such as 22), or protocols (such as TCP). The authorization context doesn’t include information about the specific CIDR blocks, ports, or protocols being added to the security group rule, so IAM policies can’t control these attributes.

            Solution
            Take a reactive approach using the AWS Config managed rule INCOMING_SSH_DISABLED to detect overly permissive rules. You can also use a combination of Amazon EventBridge and Lambda to either send a notification to your security team for the non-compliant configuration or to restrict the security group through an automation. For more information, see How to Automatically Revert and Receive Notifications About Changes to Your Amazon VPC Security Groups.

            Scenario 2: Prevent creation of Lambda functions with more than 512 MB of memory allocated

            Following the same verification methodology described in Scenario 1, navigate to the AWS Lambda Service Authorization Reference and examine the CreateFunction action’s condition keys for the function* resource type.

            Available condition keys for lambda:CreateFunction with the function* resource type include:

            • lambda:CodeSigningConfigArn: Filters access by the ARN of the code signing
            • configuration-lambda:Layer: Filters access by the ARN of a version of an AWS Lambda layer
            • lambda:VpcIds: Filters access by the ID of the VPC configured for the Lambda function

            There is no condition key for memory allocation (MemorySize parameter), timeout settings, storage configuration (EphemeralStorage), or runtime selection. Because memory allocation isn’t exposed in the authorization context, IAM policies can’t restrict this parameter.

            Solution

            Key takeaways

            Keep these principles in mind when working with IAM policies:

            • Policies control what’s in the authorization context, not all elements you see in API documentation
            • The Service Authorization Reference is authoritative; if something isn’t listed as a condition key, you can’t control it with policies
            • Different actions have different available contexts even within the same service
            • Alternative approaches exist. AWS Config, EventBridge, and service-specific controls can be used to achieve your goals when policies alone can’t
            • Layered security is essential; combine preventive, detective, and responsive controls to help ensure that your data is secure

            Conclusion

            In this post, you learned how to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies and recognize scenarios that require alternative solutions. By understanding that policies can only make decisions based on information available in the authorization context, you can build more effective security controls and avoid spending time on approaches that won’t work.

            The Service Authorization Reference is your authoritative source for understanding policy capabilities. When you need to implement a control, start there to see if the required condition keys exist. If they don’t, you will need to layer in detective or responsive controls using services like AWS Config, Amazon EventBridge, or AWS Lambda.

            Remember that effective AWS security isn’t about finding one perfect control, it’s about combining preventive, detective, and responsive measures to create defense in depth. IAM policies are powerful tools for prevention and work as part of a comprehensive security strategy.

            Next steps:

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


            Author

            Anshu Bathla

            Anshu is a Senior Lead Consultant – SRC at AWS, based in Gurugram, India. He works with customers across diverse verticals to help strengthen their security infrastructure and achieve their security goals. Outside of work, Anshu enjoys reading books and gardening at his home garden.

            Author

            Prafful Gupta

            Prafful is an Associate Delivery Consultant at AWS, based in Gurugram, India. Having started his professional journey with Amazon, he specializes in DevOps and Generative AI solutions, helping customers navigate their cloud transformation journeys. Beyond work, he enjoys networking with fellow professionals and spending quality time with family.

            •  
            ❌