Tag Archives: Foundational (100)

Introducing the Snowflake and AWS Custom Lens for the AWS Well-Architected Framework

Post Syndicated from Nidhi Gupta original https://aws.amazon.com/blogs/architecture/introducing-the-snowflake-and-aws-custom-lens-for-the-aws-well-architected-framework/

Running Snowflake on AWS means navigating two distinct sets of best practices simultaneously: AWS Well-Architected guidance for infrastructure, and Snowflake Well-Architected Framework guidance for compute, data organization, and governance. Without a unified review framework, security controls go unmapped to Snowflake configurations. Production readiness timelines stretch as teams reconcile guidance from two separate review processes, and compliance posture becomes difficult to demonstrate when audit evidence spans disconnected sources. The Snowflake and AWS Custom Well-Architected Framework Lens closes that gap.

The lens brings together AWS Well-Architected best practices and Snowflake guidance into a single review experience, with integrated recommendations that reflect how the two services compose in production. It evaluates your architecture across the seven AWS Well-Architected pillars: security, reliability, performance efficiency, cost optimization, operational excellence, and sustainability. A single review surfaces findings like misconfigured Snowflake network policies alongside Amazon Virtual Private Cloud (Amazon VPC) controls, or cost inefficiencies that span both Snowflake virtual warehouse sizing and Amazon Elastic Compute Cloud (Amazon EC2) instance selection. In this post, we walk through each pillar, the three access points (AWS Management Console, Kiro, and Snowflake Cortex Code), and how to run your first review.

What’s in the lens?

The Snowflake and AWS Custom WAF Lens defines seven pillars for joint Snowflake-on-AWS architectures, drawing from both the seven-pillar AWS Well-Architected Framework and the five-pillar Snowflake Well-Architected Framework.

Pillar 1: Security and identity

Security for Snowflake on AWS requires coordinated identity and access controls across two distinct planes. On the AWS infrastructure side, services like AWS Key Management Service (AWS KMS), AWS IAM Identity Center, and Amazon VPC configurations govern access and encryption. On the Snowflake side, network policies, role-based access control (RBAC) hierarchies, and OAuth or key pair authentication control who can access data. The following table maps the most critical security domains (identity, network, authentication, and authorization) across both services, with integrated recommendations for where the two layers must align to help prevent unauthorized access.

Domain AWS guidance Snowflake guidance Integrated recommendation
Network security Amazon VPC design, AWS PrivateLink endpoints, AWS service endpoints, Amazon EC2 security groups Network policies, IP allow lists Use AWS PrivateLink between Amazon VPC and Snowflake; layer Snowflake network policies on top of EC2 security groups for defense-in-depth
Identity and access AWS Identity and Access Management (IAM) roles, federation, least privilege Database roles, role hierarchy, MFA Federate Snowflake authentication through AWS IAM Identity Center; map identity provider groups to Snowflake database roles for consistent RBAC
Authentication MFA for human IAM users; integrate with corporate IdP via IAM Identity Center RSA key pair for service accounts; SAML SSO or OAuth for humans; disable-password only Store private keys in AWS Secrets Manager; rotate via automation; unified IdP for both systems via SAML federation
Authorization Service control policies at organization level as hard guardrails; permission boundaries on delegated roles Role hierarchy with inheritance; SECURITYADMIN for grants separate for SYSADMIN Map AWS IAM roles 1:1 to Snowflake functional roles with workload identity federation

Pillar 2: Data governance and compliance

Protecting data itself, independent of who accesses it, spans two complementary layers. On the AWS infrastructure side, services like AWS KMS, AWS IAM Identity Center, and Amazon Simple Storage Service (Amazon S3) lifecycle policies govern encryption, classification, and retention of data at rest. On the Snowflake side, dynamic data masking, row access policies, Tri-Secret Secure, and automatic classification protect sensitive data at the query layer. The following table maps the most critical governance domains (classification, dynamic data masking, lineage, retention, and compliance) across both systems, with integrated recommendations for maintaining consistent data protection end-to-end.

Domain AWS guidance Snowflake guidance Integrated recommendation
Data protection AWS KMS customer-managed keys, Amazon S3 encryption Dynamic masking, row access policies, Tri-Secret Secure Use AWS KMS with Snowflake Tri-Secret Secure for dual-custody encryption; apply Snowflake masking policies for column-level protection
Audit and compliance AWS CloudTrail, AWS Config, AWS Security Hub Event tables, Account Usage, Access History, Sensitive data classification Stream Snowflake audit logs to Amazon CloudWatch or Amazon OpenSearch Service using Amazon S3 and Amazon EventBridge for consolidated compliance monitoring. AWS provides compliance-enabling capabilities; your team uses them to support and demonstrate compliance.
Row access policies AWS Lake Formation row-level filters, Amazon S3 Access Points for team-scoped access Row access policies for multi-tenant isolation or regional data residency; role-based row visibility Define row-level security once in Snowflake (single enforcement point); restrict AWS-side to pipeline service account

Pillar 3: Reliability

Reliability in a Snowflake on AWS architecture depends on how well the two systems coordinate during failure scenarios, from AWS infrastructure disruptions to Snowflake service availability events. The following table covers the key reliability domains, including cross-Region replication, failover configuration, and workload isolation, with integrated guidance for building a resilient architecture across both systems.

Domain AWS guidance Snowflake guidance Integrated recommendation
Disaster recovery Multi-AZ, cross-Region replication, Amazon Route 53 failover Database replication, failover groups, client redirect Configure Snowflake cross-Region replication to a secondary AWS Region; use Snowflake client redirect for automated failover to the secondary Region
Data durability Amazon S3 11-nines durability, versioning Time Travel, Fail-safe, zero-copy clones Align Snowflake Time Travel retention with Amazon S3 versioning policies; use zero-copy clones for pre-deployment testing without storage overhead
Recovery objectives RTO and RPO planning, backup strategies Replication lag monitoring, failover SLAs Define joint RTO and RPO targets that account for both Snowflake replication lag and AWS infrastructure recovery time

Pillar 4: Performance optimization

Performance efficiency for Snowflake on AWS requires tuning at both the infrastructure and application levels. AWS instance selection, network throughput, and storage configuration directly affect how Snowflake warehouses perform. Snowflake-specific patterns like warehouse sizing, query optimization, and clustering keys determine how efficiently compute is used. The following table covers the primary performance domains with integrated recommendations for both layers.

Domain AWS guidance Snowflake guidance Integrated recommendation
Compute sizing Amazon EC2 instance selection, automatic scaling Warehouse sizing, multi-cluster warehouses, auto-suspend Right-size Snowflake warehouses based on query profiling; use multi-cluster warehouses for concurrency scaling aligned with application tier automatic scaling
Data organization Amazon S3 partitioning, file format optimization Clustering keys, search optimization, materialized views Optimize Amazon S3 staging file sizes for Snowpipe ingestion; apply clustering keys on frequently filtered columns, ordered from lowest to highest cardinality Note: This ordering is specific to Snowflake’s micro-partition architecture. Unlike traditional databases where high-cardinality columns are typically indexed first, Snowflake achieves better partition pruning when the lowest-cardinality column leads the clustering key.
Caching and latency Amazon CloudFront, Amazon ElastiCache Result cache, warehouse cache, query acceleration Design query patterns to maximize Snowflake result cache hits; use Amazon ElastiCache for application-layer caching of frequently accessed Snowflake results

Pillar 5: Cost optimization and FinOps

Cost optimization across Snowflake and AWS involves two distinct billing models that you must manage together. AWS infrastructure costs follow a consumption and reservation model, and Snowflake charges are driven by compute credits and storage. Without a unified view, teams often optimize one application at the expense of the other. The following table addresses the key cost domains with integrated recommendations for reducing spend across both billing models.

Domain AWS guidance Snowflake guidance Integrated recommendation
Cost visibility AWS Cost Explorer, AWS Budgets, AWS Cost and Usage Reports (CUR) Resource monitors, account usage views, credit tracking Combine AWS Cost Explorer data with Snowflake credit consumption in an integrated FinOps dashboard; tag resources with matching cost-center labels
Compute efficiency

AWS Savings Plans, Amazon EC2 Spot Instances

Note: Savings Plans and Spot apply to customer-managed AWS compute (ETL pipelines, application tier) that feeds Snowflake, not to Snowflake warehouse compute itself.

Auto-suspend, warehouse right-sizing, serverless features Pair Snowflake capacity commitments with AWS Savings Plans for predictable baseline; use auto-suspend aggressively for development warehouses
Storage efficiency Amazon S3 lifecycle policies, S3 Intelligent-Tiering Time Travel retention optimization, transient tables Align Snowflake Time Travel retention (1 day for development, 90 days for regulated data) with Amazon S3 lifecycle transitions to Amazon S3 Glacier

Pillar 6: Operational excellence

Operational excellence for Snowflake on AWS means building observability, automation, and incident response workflows that span both applications. Amazon CloudWatch, AWS Systems Manager, and Snowflake’s query history and task monitoring each provide partial visibility, but a well-operated architecture connects them into a coherent operational picture. The following table covers the core operational domains with integrated guidance for managing both applications as a single system.

Domain AWS guidance Snowflake guidance Integrated recommendation
Monitoring Amazon CloudWatch, AWS X-Ray, Amazon OpenSearch Service Snowsight dashboards, Account Usage, query history Export Snowflake metrics to Amazon CloudWatch using Amazon S3 integration for unified operational dashboards
Automation and IaC AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform Snowflake Terraform provider, CI/CD pipelines Manage Snowflake objects alongside AWS infrastructure in the same Terraform state; use CI/CD pipelines for database migration workflows
Incident response Amazon EventBridge, Amazon Simple Notification Service (Amazon SNS), AWS Lambda auto-remediation Alerts, resource monitors, task monitoring Trigger AWS Lambda auto-remediation from Snowflake resource monitor alerts via notification integrations and Amazon SNS

Pillar 7: Sustainability

This is the first joint ISV-AWS WAF lens to treat the sustainability pillar as a first-class concern. For Snowflake on AWS, sustainability decisions span AWS Region selection and energy efficiency choices on the infrastructure side, and warehouse consolidation, query efficiency, and data lifecycle management on the Snowflake side. The following table covers the sustainability domains with integrated recommendations that reduce the environmental footprint of your combined architecture.

Domain AWS guidance Snowflake guidance Integrated recommendation
Region selection AWS Customer Carbon Footprint Tool, region-level carbon intensity Snowflake Region availability Select AWS Regions aligned with sustainability goals for non-latency-sensitive Snowflake workloads; prefer secondary Regions with high renewable energy percentages for DR
Compute efficiency AWS Compute Optimizer, Amazon EC2 Auto Scaling Warehouse auto-suspend, serverless tasks Enforce aggressive auto-suspend policies for development and batch workloads to alleviate idle compute; prefer serverless features for intermittent workloads
Data lifecycle Amazon S3 Intelligent-Tiering, Amazon S3 Glacier lifecycle policies Time Travel retention, transient tables, zero-copy clones Minimize storage footprint by aligning Time Travel retention to actual recovery needs; replace full data copies with zero-copy clones for development and testing
Query efficiency Batch and real-time processing best practices Query profiling, clustering keys, materialized views, result caching Optimize query patterns to reduce total compute-seconds; apply clustering keys to avoid full table scans

Three ways to use the lens

You can access the lens across three environments, each designed for a different workflow and team preference. Whether your team works primarily in the AWS Management Console, prefers an AI-assisted review inside an IDE, or operates within Snowflake, you can run a full Well-Architected review without switching contexts.

1. AWS Well-Architected Tool console

The lens is available directly in the AWS Well-Architected Tool console for structured reviews against your Snowflake on AWS workloads. A structured questionnaire covers all seven pillars with Snowflake-specific questions, and each best practice is risk-rated as High Risk, Medium Risk, or No Risk Identified. The review generates an improvement plan with prioritized actions and links to AWS and Snowflake documentation, milestone tracking to measure progress over time, and PDF or JSON export for stakeholder reporting and compliance evidence.

AWS Well-Architected Tool console showing the Snowflake and AWS custom lens applied to a workload

To get started:

  1. Download the Snowflake AWS Custom Lens JSON file to your local computer.
  2. Sign in to the AWS Well-Architected Tool console and choose Custom lenses in the navigation pane.
  3. Choose Create custom lens, upload the downloaded JSON file, and choose Submit.

2. Kiro

For teams that prefer an AI-assisted, conversational approach, the Snowflake and AWS WAF Lens is available as a Kiro Power, an integrated capability within Kiro, the AI-powered IDE of AWS. The review runs conversationally inside the IDE with checkbox-based questions for each pillar, so you can avoid navigating a separate console. Findings are classified using a Red, Yellow, Green system for quick risk identification. Recommendations are organized into three time horizons: Now (1–2 weeks), Next (30–60 days), and Later (90 or more days). The output includes automation mapping for Proactive Health Checks and Blueprint defaults, and supports both customer-ready and internal delivery plan formats. Guidance is context-aware, accounting for your specific workload type, compliance requirements, and multi-Region needs.

Kiro IDE running the Snowflake WAF Power with checkbox questions for the security pillar

To get started:

  1. Download the Snowflake WAF Power to your local computer and unzip it.
  2. In Kiro, choose Open Folder and select the unzipped folder.
  3. Enter “Run a Snowflake and AWS WAF review” in the chat to begin.

3. Snowflake Cortex Code

In addition to using the AWS Well-Architected Tool and Kiro, you can also opt for the Cortex Code coding assistant path. The joint Well-Architected review is packaged as a Cortex Code skill that you can invoke to start the review process. When invoked, the skill opens with an architecture overview and asks how you want to proceed. You can run the full review interactively with AI-guided recommendations. Cortex Code is available as both a CLI and directly within Snowsight, so you can choose whichever fits your workflow.

Option A: Cortex Code CLI (local terminal)

Cortex Code CLI prompt running the joint-waf-aws-lens skill in a terminal window

To get started:

    1. Download the Cortex Code zip file for AWS WAF Lens to a location that you want on your local computer and unzip it.

 

 

  1. Open a terminal window on your computer and enter cortex skill add <path_to_the_unzipped_folder> at the shell prompt. The following screenshot shows an example.

Terminal output confirming successful addition of the joint-waf-aws-lens skill to Cortex Code

  • Launch Cortex Code CLI by entering cortex at the shell prompt.
  • In the Cortex Code CLI chat window, enter invoke the joint-waf-aws-lens skill to get started.

Option B: Cortex Code in Snowsight (browser-based)

For teams that prefer to stay within the Snowflake UI, Cortex Code is also available directly in Snowsight, with no local install required.

Cortex Code assistant panel in Snowsight with the joint-waf skill loaded as context

To get started:

  • Download the Cortex Code zip file for AWS WAF Lens and unzip it.
  • In Snowsight, navigate to Projects > Workspaces and open (or create) a workspace where you want to run this skill.
  • Choose the Cortex Code icon in the lower-right corner of Snowsight to open the assistant panel.
  • Choose + Add context in the chat area of the assistant panel and select Upload Skill Folder(s), then choose the unzipped skill folder.
  • In the message box, enter run the joint-waf skill and press Enter to begin the review.

How the pillars come together

What makes this lens unique is that it integrates AWS infrastructure guidance directly into Snowflake-specific best practices.

Rather than running separate reviews for each application, the lens helps identify Snowflake architectural risks alongside the corresponding AWS remediation paths, showing where both layers need to be aligned.

Built for Snowflake on AWS

This lens reflects integrated expertise across both services:

  1. Unified security model – AWS provides network isolation, encryption infrastructure, and identity federation. Snowflake provides data-layer protections like dynamic masking, row access policies, and Tri-Secret Secure. The lens shows how these layers compose into a coherent security posture.
  2. FinOps integration – The cost pillar addresses the challenge of optimizing spend across two billing models: AWS infrastructure costs and Snowflake consumption costs.
  3. Operational coherence – The operational excellence pillar bridges AWS-native observability (Amazon CloudWatch, Amazon OpenSearch Service) and Snowflake-native monitoring (Snowsight, Account Usage), so you can build connected dashboards and incident response workflows that span both services.
  4. Sustainability as a first-class pillar – This is the first joint ISV-AWS WAF lens to include sustainability as a first-class pillar. It combines AWS Region selection strategies with warehouse consolidation, query efficiency optimization, and data lifecycle management.

Getting started with the Snowflake and AWS WAF Lens

To get the most out of your first review, start with the Security and Reliability pillars, where integrated AWS and Snowflake guidance surfaces the highest-impact findings for most production workloads. Use the improvement plan output to prioritize actions across your team, and export the results as PDF or JSON for stakeholder reporting and compliance evidence.

The following resources will help you go deeper on the AWS services and Snowflake capabilities referenced throughout this post.

  1. AWS Well-Architected Tool
  2. AWS Well-Architected Framework
  3. Kiro Documentation
  4. Snowflake Cortex Code
  5. Snowflake WAF
  6. Tri-Secret Secure in Snowflake
  7. Snowflake Snowpipe
  8. Snowflake zero-copy cloning
  9. Snowflake Workload Identity Federation
  10. Snowflake sensitive data classification

What’s next

This is the first release of the Snowflake and AWS WAF Lens, and we’re actively expanding its coverage with deeper guidance on Snowflake on AWS architecture.

We’re committed to making Snowflake on AWS well-architected in the cloud. Start your first review in either the AWS Well-Architected Tool or Snowflake Cortex Code CLI today, or reach out to your AWS account team or Snowflake account team to schedule a guided workshop.


About the authors

ICYMI: May 2026 @AWS Security

Post Syndicated from Rodolfo Brenes original https://aws.amazon.com/blogs/security/icymi-may-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, network protection, identity management, compliance frameworks, and supply chain security. Read on for practical guidance on securing agentic AI workflows, filtering network traffic by category, defending against supply chain attacks, and more.

AI Security

Security posture improvement in the AI era
Author: Celeste Bishop | Published: May 1, 2026
Learn to use the Security Health Improvement Program (SHIP) to strengthen security fundamentals across 10 core use cases for confident AI adoption.

Enabling AI sovereignty on AWS
Author: Stéphane Israël | Published: May 12, 2026
Learn how AWS delivers control and choice across the AI stack to help customers meet digital and AI sovereignty requirements.

The AWS AI Security Framework: Securing AI with the right controls, at the right layers, at the right phases
Authors: Riggs Goodman III, Christopher Rae | May 15, 2026
A structured framework that helps security leaders align the right security controls to the right AI use case, at the right layer, at the right deployment phase.

Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows
Authors: Liana Hadarean, Jean-Baptiste Tristan | May 20, 2026
Learn how Cedar’s deterministic authorization, automated reasoning, and formal verification capabilities secure agentic AI tool invocations through Amazon Bedrock AgentCore Gateway.

Infrastructure security

Securing open proxies in your AWS environment
Author: Dodd Mitchell | Published: May 4, 2026
Learn to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP reputation, and control costs.

Introducing AI traffic analysis dashboards for AWS WAF
Authors: Christopher Jen, Eitav Arditti, Kaustubh Phatak | Published: May 5, 2026
A new dashboard providing visibility into AI bot and agent activity including bot identification, intent classification, and access pattern analysis.

Simplifying policy management with URL and Domain Category filtering on AWS Network Firewall
Authors: Lawton Pittenger, Sofía Aluma-Santos, Eric Fortenbery, Mostafa Elkhouly | May 28, 2026
Learn to use AWS Network Firewall’s URL and domain category filtering to control access to website categories like AI services, manage exceptions for approved domains, and monitor traffic patterns with Amazon CloudWatch Logs Insights.

    Why and how to migrate to a Transit Gateway-attached AWS Network Firewall


    Authors: Frank Phillis, Lawton Pittenger | May 28, 2026

    Learn to migrate your centralized AWS Network Firewall deployment to a
    AWS Transit Gateway-attached model, eliminating the inspection
    Amazon VPC and enabling flexible cost allocation.

    Identity

    Regional routing for AWS access portals: Implementing custom vanity domains for IAM Identity Center
    Authors: Georgi Baghdasaryan, Laura Reith, Sowjanya Rajavaram | May 14, 2026
    Learn to build a custom vanity domain with latency-based routing and automated failover for IAM Identity Center multi-Region access portals.

    Automating identity lifecycle and security with AWS Directory Service APIs
    Authors: Ali Alzand, Kevin Sookhan | May 21, 2026
    Learn to use the new AWS Directory Service Data APIs with Amazon GuardDuty and AWS Step Functions to automate identity lifecycle management and respond to security threats.

    Governance and compliance

    Announcing the ISO 31000:2018 Risk Management on AWS compliance guide
    Authors: Jesse McMahan, Akanksha Chaturvedi, Mayur Jadhav, Juan Rodriguez, Sana Rahman | Published: May 1, 2026
    A compliance guide providing practical guidance for establishing a risk management program using ISO 31000:2018 principles in AWS environments.

    New compliance guide available: ISO/IEC 42001:2023 on AWS
    Authors: Abdul Javid, Amber Welch, Muhammad Sharief, Jonathan Jenkyn, Satish Uppalapati | Published: May 6, 2026
    A compliance guide providing practical guidance for designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.

    Introducing the updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption
    Authors: Krish De, Stephen James Martin, Brenda Fong, Kelvin Leung | May 13, 2026
    An updated guide providing FSI customers practical considerations for responsible AI adoption across governance, risk management, compliance, data management, and AI agent management.

    Governing infrastructure as code using pattern-based policy as code
    Authors: Guptaji Teegela, Paul Keastead | May 19, 2026
    Learn to use Open Policy Agent (OPA) in CI/CD pipelines to validate AWS infrastructure changes before deployment using recurring control patterns.

    Import historical data from AWS CloudTrail Lake to Amazon CloudWatch
    Authors: Isaiah Salinas, Erik Weber|Published: May 6, 2026
    Learn to import historical data from AWS CloudTrail Lake into Amazon CloudWatch for centralized log analysis.

    Data protection

    Automating post-quantum cryptography readiness using AWS Config
    Author: Pravin Nair | May 14, 2026
    Learn to use the PQC Readiness Scanner to inventory your ALB, NLB, and Amazon API Gateway endpoints and continuously monitor their TLS configurations for post-quantum cryptography readiness.

    Threat detection and response

    Detecting and preventing crypto mining in your AWS environment
    Authors: Jason Palmer, Nadia Mahmood | May 13, 2026
    Learn to use Amazon GuardDuty to identify and mitigate cryptocurrency mining threats in your AWS environment with a multi-layered defense strategy.

    Well-architected best practices for software supply chain security
    Authors: Trevor Schiavone, Desiree Brunner | May 26, 2026
    Learn to apply AWS Well-Architected Framework security best practices to defend against software supply chain attacks like Shai-Hulud using temporary credentials, centralized dependency management, artifact signing, and continuous scanning.

    AWS Security Hub Extended: Why enterprise security products should sell themselves
    Author: Michael Fuller | May 20, 2026
    A thought leadership piece on how AWS Security Hub Extended enables frictionless, pay-as-you-go adoption of curated partner security solutions alongside AWS-native services.

    Application Security

    Five ways to use Kiro and Amazon Q to strengthen your security posture
    Author: Roger Nem | Published: May 5, 2026
    Learn to use Kiro and Amazon Q Developer for security finding triage, infrastructure remediation, security reviews, and service control policies (SCP) development.

    AWS Security Agent full repository code scanning feature now available in preview
    Authors: Ayush Singh, Daniele Bonadiman | May 12, 2026
    Learn to use AWS Security Agent’s full repository code review to perform deep, context-aware security analysis of your entire code base.

    Training and enablement

    Complimentary virtual training: Get hands-on with AWS Security services
    Author: Ashley Nelson | Published: May 11, 2026
    Security Activation Days are free 3–6 hour virtual workshops providing hands-on practice with AWS security services guided by specialists.

    May Security Bulletins

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

    AWS Samples

    This month brings 8 new AWS samples spanning application security, data protection, infrastructure security, governance, and AI security. From AI-powered security agents on Amazon Bedrock AgentCore to centralized AWS Config monitoring at scale, these repositories help you implement security best practices across your AWS environment.

    Application Security

    Schedule AWS Security Agent penetration test
    Learn to deploy a AWS CloudFormation template that uses Amazon EventBridge and AWS Step Functions to schedule recurring AWS Security Agent penetration tests with Amazon Simple Notification Service
    (SNS) notifications on completion.

    Security review assistant
    Learn to deploy a multi-agent system on Amazon Bedrock AgentCore that automates Deliverable Security Reviews by combining architecture analysis, IaC code review, ASH vulnerability scanning, and compliance assessment into a single pipeline.

    AWS Security Agent Recorder
    Learn to use a cross-browser extension that records the unique domains your web app contacts and auto-fills them into the AWS Security Agent penetration test configuration.

    Data Protection

    KMS access audit
    Learn to resolve and report who can use your AWS Key Management Service (KMS) keys across IAM policies, key policies, and grants, with IAM Identity Center resolution to identify the humans behind SSO roles.

    Infrastructure security

    Building a conversational AI agent for AWS WAF analysis with AgentCore
    Learn to deploy an AI-powered agent using Amazon Bedrock AgentCore and Strands SDK that investigates AWS WAF security incidents, detects bypasses, and generates security reports through natural language.

    Governance

    Centralized AWS Config CI monitoring with Amazon CloudWatch
    Learn to centrally monitor AWS Config Configuration Item recording across all accounts in an AWS Organization using CloudWatch Cross-Account Observability, with dashboards showing top resource types, per-account volume, and conformance pack compliance.

    CloudFormation Guard security analyzer
    Learn to deploy an AI agent powered by Amazon Bedrock AgentCore that scans CloudFormation resource documentation, identifies security-critical properties with risk levels, and generates ready-to-use cfn-guard 3.x rules for your CI/CD pipeline.

    AI Security

    Guarded user-controlled attested runtime deployment (Guardian Platform)
    Learn to deploy LLM models securely in consumer AWS accounts while protecting model weights using AWS Nitro TPM attestation, KMS envelope encryption, and Zero Operator Access with immutable AMIs.

    AWS Labs

    This month brings 1 new AWS Labs repository focused on governance, helping research institutions deploy secure, tagged infrastructure with self-service access and multi-account controls.

    ResearchStack on AWS
    Learn to deploy research computing infrastructure on AWS in minutes — Amazon EC2, S3, EFS, Amazon SageMaker AI, and ParallelCluster — with built-in security, cost tracking, and governance using CloudFormation templates and optional AWS Service Catalog.

    Conclusion

    May 2026 shows AI security maturing from model-level controls to full-stack protection of agentic workflows. The posts and samples provide patterns for policy-based authorization with Cedar, network traffic filtering by category, and cross-account compliance monitoring. The security bulletins address vulnerabilities in SDKs, drivers, and developer tooling. Each resource includes deployment steps or runnable code so you can validate in your own environment before adopting. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.

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


    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 has 18 years of experience in the technical content space and has spent the last 6 years managing the AWS Security Blog. Outside of work, she enjoys spending time with her family.

    Spring 2026 SOC 1, 2, and 3 reports are now available with 188 services in scope

    Post Syndicated from Baj Bajwa original https://aws.amazon.com/blogs/security/spring-2026-soc-1-2-and-3-reports-are-now-available-with-188-services-in-scope/

    Amazon Web Services (AWS) is pleased to announce that the Spring 2026 System and Organization Controls (SOC) 1, 2, and 3 reports are now available. The reports cover 188 services over the 12-month period from April 1, 2025–March 31, 2026, giving customers a full year of assurance. These reports demonstrate our continuous commitment to adhering to the heightened expectations of cloud service providers.

    Customers can download the Spring 2026 SOC 1 and 2 reports through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact. The SOC 3 report can be found on the AWS SOC Compliance Page and AWS Artifact.

    AWS is excited to be the first cloud service provider to offer compliance reports to customers in NIST’s Open Security Controls Assessment Language (OSCAL), an open-source, machine-readable (JSON) format for security information. The SOC report package in OSCAL format is now available separately in AWS Artifact, marking a milestone towards open, standards-based compliance automation. This machine-readable version of the SOC 1 & 2 reports enables workflow automation to reduce manual processing time and modernize security and compliance processes. Your use-cases for this content are innovative and we want to hear about them via the contact information found in the OSCAL report package.

    AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.

    To learn more about AWS compliance and security programs, see AWS Compliance Programs.

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


    Baj Bajwa

    Baj Bajwa

    Baj is a Security Assurance Manager at AWS, where he leads the Global Third-Party Assurance product portfolio within the Compliance and Security Assurance (CSA) organization. He has over 15 years of experience in information security, compliance, and risk management, and holds a master’s degree in cybersecurity. Baj maintains CISSP, CISA, PMP, CCSK, GISF, and ICAgile certifications.

    Tushar-Jain

    Tushar Jain

    Tushar is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives Tushar holds a Master of Business Administration from Indian Institute of Management Shillong, India and a Bachelor of Technology in electronics and telecommunication engineering from Marathwada University, India. He has over 14 years of experience in information security and holds CISM, CCSK and CSXF certifications.

    Michael Murphy

    Michael is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Michael has over 14 years of experience in information security and holds a master’s degree and a bachelor’s degree in computer engineering from Stevens Institute of Technology. He also holds CISSP, CRISC, CISA, and CISM certifications.

    Atulsing Patil

    Atulsing is a Compliance Program Manager at AWS and has over 28 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 42001 Lead Auditor, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

    Jeff Cheung

    Jeff is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives across business lines. Jeff has Bachelors degrees in Information Systems, and Economics from SUNY Stony Brook, and has over 20 years of experience in information security and assurance. Jeff has held professional certifications such as CISA, CISM, and PCI-QSA.

    Noah Miller

    Noah is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Noah has 7 years of experience in information security. He has a master’s degree in Cybersecurity Risk Management and a bachelor’s degree in Informatics from Indiana University.

    Will Black

    Will is a Compliance Program Manager at AWS where he leads multiple security and compliance initiatives. Will has 10 years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he is a PCI Internal Security Assessor (ISA) for AWS and holds the CCSK and ISO 27001 Lead Implementer certifications.

    Allen Beam

    Allen is a Compliance Program Manager at AWS supporting third-party security and privacy compliance initiatives. He has over 10 years of experience in external IT security audits, security control design and implementation, and audit readiness and control deficiency remediation. He has a Bachelor’s Degree in Economics and Finance from James Madison University.

    Ziv Wand

    Ziv is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Ziv has over 6 years of experience in information security assurance, external IT security audits, security control design and implementation, and audit readiness. He holds a Bachelor of Science in Management Information Systems from Binghamton University.

    Shalini Mishra

    Shalini is a Compliance Program Manager at AWS. She has over 10 years of experience leading end-to-end compliance programs across ISO, SOC, and cloud security frameworks, with deep expertise in third-party risk management and enterprise governance. Shalini holds a Master of Science degree in Information Systems and CRISC certification.

    AWS KY3P report now available for third-party supplier due diligence

    Post Syndicated from Michael Murphy original https://aws.amazon.com/blogs/security/aws-ky3p-report-now-available-for-third-party-supplier-due-diligence/

    We’re excited to announce that Amazon Web Services (AWS) has completed the S&P Global Know Your Third Party (KY3P) assessment of its security posture. This assessment demonstrates our continued commitment to meet the heightened expectations of cloud service providers. Customers can now use the AWS KY3P assessment to reduce their supplier due diligence burden.

    KY3P, also known as the S&P Global Comprehensive Assessment (formerly TruSight), is a validated, evidence-based assessment designed to support regulatory compliance and efficient, standardized risk data exchange between AWS and our clients. KY3P’s globally recognized methodology provides organizations with enhanced visibility into supply chain risks by validating the actual implementation and operation of controls – not just policies or attestations.

    As cloud adoption accelerates across industries, AWS has become a critical component of customers’ third-party environments. Regulated customers, such as those in the financial services sector, are held to high standards by regulators and auditors when it comes to exercising effective due diligence on third parties.

    To better manage risks from their evolving third-party environments and drive operational efficiencies, many customers rely on third-party risk management services such as KY3P. In support of these efforts, AWS has completed its annual KY3P security posture assessment, conducted by KY3P security assessors.

    KY3P’s risk assessment methodology includes over 200 controls across 26 control categories and nine risk domains. These topics include Privacy, Network Management, Logical Access Management, and Physical and Environmental Security. The assessment criteria were developed by a consortium of leading financial institutions.

    Customers can use the KY3P results to map AWS against commonly used industry frameworks and standards, such as NIST CSF v2, PCI DSS 4.0, and ISO 27001:2022 to instantly gain visibility into controls coverage.

    For details on how to access the report, see our AWS KY3P assessment page.

    If you have feedback about this post, submit comments in the Comments section below. To learn more about our other compliance and security programs, see AWS Compliance Programs.

    Michael Murphy

    Michael is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Michael has over 14 years of experience in information security and holds a master’s degree and a bachelor’s degree in computer engineering from Stevens Institute of Technology. He also holds CISSP, CRISC, CISA, and CISM certifications.

    AWS Security Hub Extended: Why enterprise security products should sell themselves

    Post Syndicated from Michael Fuller original https://aws.amazon.com/blogs/security/aws-security-hub-extended-why-enterprise-security-products-should-sell-themselves/

    Our largest security services customers started the same way every customer does – with a click. They enabled Amazon GuardDuty, Amazon Inspector, AWS WAF, and AWS Security Hub, experienced the benefits in real time, and evaluated with transparent pay-as-you-go pricing. No RFP. No six-month evaluation. No multi-year commitment up front. Our field teams played a critical role in that growth, not by selling the first click, but by building the trusted relationships that turned early adoption into deep, long-term commitment. We believe customers should have this same frictionless adoption experience and flexibility for all best-in-class security products and that’s why we developed Security Hub Extended.

    In our first post, we introduced Security Hub Extended, a significant expansion of Security Hub that brings together curated partner solutions in a single, unified experience. In our second post, we walked through how it works technically, including the onboarding flow, the pricing model, the unified operations layer built on the Open Cybersecurity Schema Framework (OCSF). In this post, I want to step back and talk about why we built it the way we did and why I believe the way enterprises discover, evaluate, and adopt security solutions is ready for a fundamental shift.

    The shift

    If you’ve ever tried to evaluate a new enterprise security product, you know the drill. Request a demo. Wait. Take the demo. Request a PoC. Wait for professional services (or your team to stop building) to set it up. Negotiate pricing, which isn’t published, so you’re starting blind. Loop in procurement. Sign a multi-year commitment. Then, months later, find out whether the product actually solves your problem in your unique environment.

    Meanwhile, an ambitious security engineer on your team has already spun up an open-source tool, connected real data, and knows in two hours whether it’s going to work for your use cases. They didn’t need a slide deck. They needed a solution they could put their hands on.

    A Fortune 500 CISO recently told me: “I spent 9 months procuring a security solution and it still doesn’t work the way the demo showed.” That frustration isn’t unique. It’s the norm.

    This isn’t a criticism of the sales motion. Sales-led has evolved for good reason. Enterprise procurement is complex, products need customization, customers need support. I respect the craft and have poured a significant portion of my career into trying to perfect it. Even the most product-driven companies still need great sales, marketing, field enablement, and support.

    It doesn’t change the fact that threats are evolving constantly, and defenders need the flexibility to discover and deploy new solutions as fast as the landscape shifts. Having the best solutions discoverable and deployable in that moment of need isn’t just a convenience, it’s a competitive advantage that customers are demanding. A new threat emerges, security teams have access to industry-leading solutions, and in a few clicks they’ve found their answer and are already seeing value. That’s the model every security company should be building toward.

    What we’ve learned at AWS

    At AWS, we’ve spent two decades learning what it takes to let customers adopt complex enterprise technology on their own terms, at massive scale. We haven’t always gotten it right, but we learn fast and adjust. The result is one of the largest cloud businesses in the world. I bring up that scale for one reason. It’s proof that complex, enterprise-grade technology can be adopted without requiring a traditional procurement gauntlet. Compute, storage, databases, AI/ML, networking, and yes, security — adopted all through a console, on each customer’s own timeline, and scaled when they were ready.

    The proof is in the adoption

    Amazon GuardDuty, Amazon Inspector, AWS Shield, AWS Security Hub are all available through the AWS Management Console. All pay-as-you-go. All activated with a click. Tens of thousands of customers rely on these security services today. When you make it easy to get started and deliver outcomes that earn confidence, expansion follows naturally.

    These are sophisticated, enterprise-grade security solutions. And customers, from two-person startups to the world’s largest financial institutions, adopt them the same way. They try it, see the value, expand, and lean on the AWS team to go deeper.

    We didn’t get here by accident, and we definitely didn’t get here without making mistakes. Building products that can be adopted and scaled on their own, without a sales engineer explaining away UX problems, without a solutions architect doing the first deployment, requires a different kind of product mindset. Time-to-value becomes your most important metric. Onboarding friction becomes your biggest enemy. Transparent pricing becomes non-negotiable. It’s hard. We’ve gotten a lot wrong along the way. And we’re still iterating.

    But the results are clear. When customers adopt based on experience rather than commitment, they don’t just stay, they expand. They bring their teams. They become advocates. I’ve spent 15 years at AWS, the last 10 building security services like GuardDuty and Security Hub. When we launch a new security service or major feature, we consistently see rapid organic adoption at a pace that would be impossible through traditional sales cycles alone. These products are built to deliver value the moment customers turn them on and we make that as easy as we possibly can. That’s the scale a product-led motion unlocks.

    Security Hub Extended

    So, we asked ourselves: why can’t we build a similar approach that can expand to include industry leading partner solutions? Why can’t the CrowdStrikes, the Splunks, the Zscalers, and the fast-growing innovators solving tomorrow’s problems like Cyera, Noma, and 7AI also reach customers with the same frictionless motion that AWS services enjoy? Why can’t a security team that discovers a new threat on Monday have a proven solution deployed and delivering value by Tuesday? Our partners have built incredible products. What they haven’t always had is an avenue to put those products directly in the hands of the customers who need them most, at the moment they need them, at scale, in a way that feels as natural as turning on an AWS service. Not by replacing how our partners build or sell, but by giving them infrastructure that lets their products speak for themselves.

    That’s what Security Hub Extended is. Security teams already using Security Hub can discover curated partner solutions right alongside their AWS security services. One click to evaluate, one click to deploy, pay-as-you-go pricing on your existing AWS bill with Enterprise Discount Program (EDP) discounts automatically applied. No separate procurement cycle. No long-term commitments required. Start fast, validate at scale, and commit for deeper discounts when you’re ready, versus making a three-year bet based on a few months of testing.

    For customers, industry-leading enterprise security solutions become as easy to adopt as GuardDuty or WAF. For our partners, Security Hub Extended is a growth channel where the product leads and the customer experience mirrors what we’ve spent 20 years building at AWS. For the industry, it’s an invitation to reimagine what the relationship between a security product and a security practitioner can look like when you remove the friction standing between them.

    But Security Hub Extended isn’t just a simpler way to buy security products. It’s a unified solution. When a customer enables a solution through Extended, we’re working toward an experience where AWS handles the rest. Sensors that deploy automatically across Amazon EC2, Amazon EKS, and AWS Fargate workloads using the same mechanism that powers GuardDuty Runtime Monitoring. IAM roles that provision across a customer’s Organization in one click. Resource inventory is automated from day one – S3 buckets, databases, AI workloads – without manual work.

    Once enabled, solutions in Security Hub Extended emit findings in OCSF, automatically aggregated in Security Hub alongside findings from GuardDuty, Amazon Inspector, and every other AWS security service. Security Hub applies risk scoring and correlated risk analytics across all of them. AWS-native and third-party findings together, weighted and prioritized as a single view of your security posture. For example, an endpoint detection from CrowdStrike, correlated with a credential theft in GuardDuty, and a data access event from Cyera, produces an attack path that none of those solutions can produce alone. The correlation uses AWS context (IAM topology, VPC exposure, resource criticality) to improve the context of each attack path for security analysts. Deploying a solution through Security Hub Extended doesn’t add another pane of glass. It deepens the intelligence of the one you already have.

    We’re also building toward automated response. Customers will be able to opt in to pre-built playbooks that take action through AWS-native services when a threat is detected, such as isolating compromised resources, revoking credentials, or containing active threats. The goal is detect-to-respond in seconds, not the hours it takes to context-switch across five consoles and two ticketing systems.

    Where we are and where we’re headed

    We’re still in the first inning — or Day 1, as we like to say at Amazon. We launched in February 2026 with 14 partners, now 21, spanning endpoint, identity, email, network, data, browser, cloud, AI, and security operations, and we’re continuously working backwards from customers as we operationalize for scale. We are building this because our customers asked for it. We’re learning alongside our partners and customers every week, identifying what works, what needs improvement, where the friction still lives, and iterating quickly.

    We’re building and delivering at the speed of our customers. That means shipping fast, iterating faster, and not waiting for perfection. We’re not where we want to be just yet, and we need your feedback to get us there. What’s encouraging is that our partners aren’t waiting to be asked. They’re investing in this alongside us. Not because we’re demanding it, but because they see the same thing we do, that companies that make it effortless for customers to get started are the ones that will win at scale.

    The early signals are encouraging. Customer response has exceeded our expectations, and the feedback we hear most often is that the procurement simplification and flexibility of pay-as-you-go with public pricing alone, even before the unified operations and data normalization benefits, is a meaningful differentiator.

    If you’re a security leader: Security Hub Extended is live now. Log into Security Hub, look for the Security Hub Extended Plan (or visit the Security Hub Extended Pricing Page), and explore what’s available for your use cases. Start with what solves your most urgent problem. Pay-as-you-go, no commitment. Your team will tell you if it’s working in days, not months.

    The vision is bigger than what’s live today, and we’re iterating fast. Share your feedback on AWS re:Post for Security Hub, reach out through contact AWS Support, or connect with me directly.


    Michael Fuller

    Michael Fuller

    Michael has been with AWS for 16 years and led product for AWS Security Services for 11 years. Michael has 29 years in the industry and held several roles in product management, business development, and software development for IBM, Cisco, and Amazon. Michael has a Bachelor’s of Science in Computer Engineering from the University of Arizona and an MBA from the University of Washington.

     

    Introducing the updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption

    Post Syndicated from Krish De original https://aws.amazon.com/blogs/security/introducing-the-updated-aws-user-guide-to-governance-risk-and-compliance-for-responsible-ai-adoption/

    The financial services industry (FSI) is using AI to transform how financial institutions serve their customers. AI solutions can help proactively manage portfolios, automatically refinance mortgages when rates decrease, and negotiate insurance premiums for customers.

    However, this adoption brings new governance, risk, and compliance (GRC) considerations that organizations need to address. To help FSI customers navigate these challenges, AWS is excited to announce an updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption within Financial Services Industries.

    This comprehensive guide provides FSI customers practical considerations for responsible AI adoption across key dimensions including governance, risk management, compliance, data management, model management and AI agent management. It includes detailed AWS service capabilities that customers can use to address these considerations, such as Amazon Bedrock AgentCore, Amazon Bedrock Guardrails, Amazon Bedrock Agents, Amazon SageMaker Autopilot, and Amazon SageMaker Model Monitor.

    The guide is available at the AWS Whitepaper portal and is complementary to other AWS resources such as the AWS Responsible Use of AI Guide, AWS Cloud Adoption Framework for AI, AWS Well-Architected Framework – Responsible AI Lens, AWS Well-Architected Framework – Generative AI Lens, and AWS Well-Architected Framework – Machine Learning Lens.

    As the regulatory environment and leading practices continue to evolve, we will provide further updates on the AWS Security Blog and AWS Compliance Center. You can also reach out to your AWS account team for help finding the resources you need.

    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.

    Krish De

    Krish De

    Krish is a Principal FSI Governance, Risk, and Compliance (GRC) specialist. He works with AWS customers, their regulators, and AWS teams to safely accelerate customers’ AI and cloud adoption by providing prescriptive guidance on GRC. Krish has over 20 years of experience working in governance, risk, and technology across the financial services industry in Australia, New Zealand, and the United States.

    Brenda Fong

    Brenda Fong

    Brenda is a senior FSI risk and compliance specialist. She works with AWS customers in banking, insurance, and capital markets within the ASEAN region to help them meet regulatory, governance, risk, and compliance expectations. Brenda has over 20 years of experience working in governance, risk, and technology across the financial services industry within Asia Pacific.

    Stephen Martin

    Steve is the Head of Financial Services Compliance and Security for EMEA and APAC. Steve Joined AWS after working for over 20 years in financial service in senior leadership roles with responsibility across ASIA, the Middle East, and Europe. At AWS, he supports customers as they use the scale, security, and agility of AWS to transform the industry.

    Kelvin Leung

    Kelvin Leung

    Kelvin is the AWS FSI Security and Compliance Lead based in Hong Kong. He has 20 years of experience specializing in AI Governance, risk management and regulatory compliance within the financial services sector. Prior to joining AWS, Kelvin worked for a financial regulator where he was responsible for technology risk policy-making and IT regulatory examinations, with a particular focus on AI risk assessment and control frameworks.

    PCI PIN and P2PE compliance packages for AWS Payment Cryptography are now available

    Post Syndicated from Will Black original https://aws.amazon.com/blogs/security/pci-pin-and-p2pe-compliance-packages-for-aws-payment-cryptography-are-now-available/

    Amazon Web Services (AWS) is pleased to announce the successful completion of Payment Card Industry Personal Identification Number (PCI PIN) and PCI Point-to-Point Encryption (PCI P2PE) assessments for the AWS Payment Cryptography service. This assessment expands the AWS Payment Cryptography compliance portfolio, with AWS now validated as a component provider for Key Management (KMCP) and Key Loading (KLCP) in addition to the existing Decryption Management (DMCP) attestation, and extends PCI PIN and P2PE coverage to the South America (São Paulo) and Asia Pacific (Sydney) AWS Regions.

    With Payment Cryptography, your payment processing applications can use payment hardware security modules (HSMs) that are PCI PIN Transaction Security (PTS) HSM certified and fully managed by AWS, with PCI PIN and P2PE-compliant key management. These attestations give you the flexibility to deploy your regulated workloads with reduced compliance overhead.

    The PCI P2PE Decryption Component enables payment applications to use AWS to decrypt credit card transactions from payment terminals, and PCI PIN attestation is required for applications that process PIN-based debit transactions. The PCI P2PE Key Management and Key Loading Component attestations enable applications to use AWS for physical key exchange and to support key management use cases including key injection. To learn more about the new Physical Key Exchange feature, see the AWS What’s New announcement. With these capabilities, AWS Payment Cryptography enables customers to manage cryptographic keys in accordance with PCI standards and industry best practices, reducing the operational burden of maintaining compliant key management infrastructure.

    The PCI PIN and PCI P2PE compliance packages for AWS Payment Cryptography includes the following reports:

    • PCI PIN Attestation of Compliance (AOC) – Demonstrates that AWS Payment Cryptography was successfully validated against the PCI PIN standard with zero findings
    • PCI PIN Responsibility Summary – Provides guidance to help AWS customers understand their responsibilities in developing and operating a highly secure environment for handling PIN-based transactions
    • PCI P2PE DMCP Attestation of Validation (AOV) – Demonstrates that AWS Payment Cryptography was successfully validated against the requirements for a PCI P2PE Decryption Management System with zero findings
    • PCI P2PE KMCP Attestation of Validation (AOV) – Demonstrates that AWS Payment Cryptography was successfully validated against the requirements for a PCI P2PE Key Management Component Provider with zero findings
    • PCI P2PE KLCP Attestation of Validation (AOV) – Demonstrates that AWS Payment Cryptography was successfully validated against the requirements for a PCI P2PE Key Loading Component Provider with zero findings
    • P2PE Component User’s Guide and Annual Component Report – Describes the AWS Payment Cryptography service assessment scope as a PCI P2PE Decryption Component, Key Loading Component, and Key Management Component and illustrates PCI P2PE compliance responsibilities for both the service and customers using the service for point-to-point encryption processing

    AWS was evaluated by Coalfire, a third-party Qualified Security Assessor (QSA). Customers can access the PCI PIN Attestation of Compliance (AOC) report, the PCI PIN Shared Responsibility Summary, the PCI P2PE Attestation of Validation, and P2PE Decryption Component User’s Guide and Annual Decryption Component Report through AWS Artifact.

    To learn more about our PCI programs and other compliance and security programs, visit the AWS Compliance Programs page. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Compliance Support page.

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

    Will Black

    Will is a Compliance Program Manager at Amazon Web Services where he leads multiple security and compliance initiatives. Will has 10 years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he is a PCI Internal Security Assessor (ISA) for AWS and holds the CCSK and ISO 27001 Lead Implementer certifications.

    Tushar-Jain

    Tushar Jain

    Tushar is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives Tushar holds a Master of Business Administration from Indian Institute of Management Shillong, India and a Bachelor of Technology in electronics and telecommunication engineering from Marathwada University, India. He has over 13 years of experience in information security and holds CISM, CCSK and CSXF certifications.

    Jeff Cheung

    Jeff is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives across business lines. Jeff has Bachelors degrees in Information Systems and Economics from SUNY Stony Brook, and has over 20 years of experience in information security and assurance. Jeff has held professional certifications such as CISA, CISM, and PCI-QSA.

    Balaji Palanisamy

    Balaji is the Industry Engagement Lead for AWS Payment Cryptography, helping financial institutions and payment companies modernize their cryptographic infrastructure. He combines pragmatic security strategy with hands-on solution architecture expertise, believing the best solutions balance technical and business needs. Always curious about security challenges, he stays current by reviewing emerging payment security standards.

    AWS Security Agent full repository code scanning feature now available in preview

    Post Syndicated from Ayush Singh original https://aws.amazon.com/blogs/security/aws-security-agent-full-repository-code-scanning-feature-now-available-in-preview/

    Today, we’re excited to announce the preview release of full repository code review, a new capability in AWS Security Agent that performs deep, context-aware security analysis of your entire code base. AI-driven cybersecurity capabilities are advancing rapidly. AWS Security Agent can now find vulnerabilities and build working exploits across your entire code base at a scale and speed we haven’t seen before, reasoning like a human security researcher, but operating at machine velocity. Unlike traditional static analysis tools that match code against known vulnerability patterns, full repository code review reasons about your application’s architecture, trust boundaries, and data flows the way a human security researcher would and then produces developer-ready findings with transparent evidence and concrete remediation.

    AWS is prioritizing free early access for customers, giving defenders the opportunity to strengthen their code bases and share what they learn so the whole industry can benefit.

    The challenge: Security analysis that scales with your code

    Development teams today face persistent tension. Traditional static application security testing (SAST) tools are fast and reliable at catching known patterns such as a SQL injection sink, an unescaped output, or a hard-coded credential. But modern applications are complex systems of services, APIs, trust boundaries, and authorization logic. The most dangerous vulnerabilities often aren’t single-line pattern violations, rather they’re systemic gaps where a validation function covers four of five cases, one endpoint is missing the authorization annotation its neighbors have, or encoding is applied in one context but not another.

    Manual security reviews catch these issues, but they’re expensive, slow, and don’t scale to the pace of modern development. As code bases grow, teams are forced to choose between breadth and depth.

    Full repository code review is built to close this gap. It gives your team an automated security researcher that reads and reasons about your entire repository, not just individual lines or file, and surfaces findings that pattern-matching tools miss.

    How it works: Profile, search, triage, validate

    Full repository code review operates in four stages that mirror how an experienced security engineer conducts an engagement.

    1. Profile the application: The scanner begins by reading the entire repository and building a security model of the application including entry points, trust boundaries, data flows, authorization invariants, and the defenses already in place. This profiling step accounts for every source file, so coverage decisions are explicit rather than implicit. The result is a structured understanding of what the application does and where its attack surface lies.

    2. Search for vulnerabilities: An orchestrator reads the security profile, reasons about the attack surface, and dispatches specialized agents to the highest-risk components. Each agent receives a scoped assignment with specific modules, threat context, and adversarial questions. Agents are free to follow imports and callers beyond their starting scope when a lead takes them there.

    3. Triage and deduplicate: Candidate findings are deduplicated (same sink, same root cause) and low-confidence noise is filtered out before the validation phase.

    4. Validate independently: For every candidate, an independent validator re-reads the source code and traces the full attack chain. The validator argues both sides: it looks for reasons the finding might not be a vulnerability (compensating controls, intentional design), and it looks for reasons it is one (alternative attack paths, edge cases). A finding is only rejected when the evidence against it is as strong as the evidence that promoted it. This process produces findings with structured Verified and Could not verify sections, so your team knows exactly what the scanner confirmed in the code and what depends on your deployment environment.

    What makes this different

    Full repository code review differs from traditional static analysis in two fundamental ways. It reasons about your application’s actual behavior rather than matching against known vulnerability patterns, and it presents findings with structured evidence that makes uncertainty explicit rather than hidden.

    Context-aware reasoning, not pattern matching

    Because the scanner builds a security model before searching for vulnerabilities, it reasons about the application’s actual behavior, not only surface-level code patterns.

    Consider a real example: A stored procedure had a SQL injection vulnerability. A traditional SAST tool would flag the specific EXECUTE IMMEDIATE call. The scanner went deeper and it identified that the central validation function doesn’t block single quotes in any of its five regex profiles, listed all five profiles by name, explained why single quotes matter for the specific database engine, and noted that another stored procedure skips the validation function entirely. Instead of a point fix on one call site, the finding led to a comprehensive remediation of the systemic gap.

    In another case, the scanner found an XSS vulnerability where a value was added to a field without HTML encoding. The same value was properly encoded with Encode.forHtml() in a different context within the same file. Pattern-matching tools miss this because the encoding function is present, but the vulnerability is the inconsistency, which requires understanding the application’s behavior across code paths.

    Validated findings with transparent uncertainty

    Every finding is structured for efficient developer triage:

    • Problem: What the code does wrong, with specific file and line references.
    • Impact: What an attacker gains, with details about deployment context.
    • Verified and could not verify: What the scanner confirmed directly in code versus what depends on your environment (network segmentation, runtime behavior).
    • Remediation: Concrete fix suggestions with specific code changes, not generic guidance.
    • Severity and confidence: Calibrated independently. Severity reflects the impact if the vulnerability is exploitable; confidence reflects how much of the attack chain was verified in code.

    How full repository code review fits into your workflow

    Full repository code review is designed to complement, not replace, your existing security tooling. Here’s how it fits into a modern development workflow:

    • Before security reviews: Run a full repository code review before scheduling a penetration test or security review. The review surfaces the obvious and semi-obvious issues so your security team can focus their limited time on the subtle, design-level questions that require human judgment.
    • When onboarding acquired or open source code: Full repository code review is especially valuable when your team inherits code through acquisitions or vendor dependencies, or from open source components you’re integrating. The scanner builds a security model from scratch, so it doesn’t need institutional knowledge of the codebase.
    • During architecture reviews: Because the scanner reasons about trust boundaries, data flows, and authorization invariants, its findings often surface architectural issues, not only implementation bugs. Review the scan results alongside your threat models to validate assumptions about how components interact.

    Follow our Quickstart guide to set up and execute a full repo code review with AWS Security Agent.

    Preview availability and pricing

    Full repository code review is available today in preview at no additional charge for AWS Security Agent customers. During the preview, we welcome your feedback as we refine the experience. Use the built-in feedback mechanism in the Security Agent web application or reach out to your AWS account team.

    Get started today

    Visit the AWS Security Agent console to enable full repository code review and run your first scan. For more information, see the AWS Security Agent documentation.

    Ayush Singh

    Ayush Singh

    Ayush is a Senior Product Manager at AWS, where he leads the development of AWS Security Agent. Ayush has a proven record of scaling enterprise-grade, open source, and agentic AI products. He is dedicated to building tools that empower organizations to effectively scale their security practices. Ayush holds an MBA from the University of Rochester and a B.Tech in Computer Science from KIIT University.

    Daniele Bonadiman

    Daniele is a Senior Applied Scientist at AWS, where he works on AWS Security Agent. Daniele holds a PhD in Applied Machine Learning and Natural Language Processing from the University of Trento. During his time at AWS, Daniele has contributed to several AI initiatives focusing on conversational AI, multi-agent systems orchestration and code interpretation for AI agents.

    Complimentary virtual training: Get hands-on with AWS Security Services

    Post Syndicated from Ashley Nelson original https://aws.amazon.com/blogs/security/complimentary-virtual-training-get-hands-on-with-aws-security-services/

    If you’re looking to strengthen your organization’s security posture on Amazon Web Services (AWS) but aren’t sure where to start, then we’re here to help. Security Activation Days are complimentary, virtual, hands-on workshops designed to help you get practical experience with AWS security services in a single session.

    What to expect

    Each Security Activation Day is a 3–6 hour virtual workshop where you work directly with AWS security services in real-world scenarios. Through a combination of presentations, demos, and workshops, you will get hands-on practice guided by AWS security specialists either in your own environment or in an AWS-provided sandbox.

    Topics rotate across the full spectrum of AWS security, identity, and governance services, including threat detection and response, identity and access management, network and application protection, data protection, and governance and compliance. You will leave with actionable knowledge you can apply to your workloads immediately—not a to-do list of things to research later.

    Who should attend

    Security Activation Days are made for builders—security engineers, cloud architects, and DevOps teams who want to go deeper on specific AWS security capabilities. Whether you’re evaluating a service for the first time or looking to operationalize something you’ve already deployed, these sessions meet you where you are.

    What attendees are saying

    With over 6,400 attendees across 90 events so far in 2026, Security Activation Days consistently earn a 4.8 out of 5 satisfaction rating. Participants tell us the hands-on format is what makes the difference: there’s no substitute for actually configuring a service and seeing the results in real time.

    How to register

    We run Security Activation Days year-round across all time zones, with new sessions added regularly. Find a session, show up ready to learn, and start building today.

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

    Ashley Nelson

    Ashley Nelson

    Ashley is a Sr. WW Security Specialist at AWS, where she leads worldwide customer enablement programs for Security, Identity, and Governance services.

    ICYMI: April 2026 @AWS Security

    Post Syndicated from Rodolfo Brenes original https://aws.amazon.com/blogs/security/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

              Post Syndicated from Ignatius Lee original https://aws.amazon.com/blogs/security/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.

              Introducing AI traffic analysis dashboards for AWS WAF

              Post Syndicated from Christopher Jen original https://aws.amazon.com/blogs/security/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.

              Designing trust and safety into Amazon Bedrock powered applications

              Post Syndicated from Victor Lungu original https://aws.amazon.com/blogs/security/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

              PACIFIC enables multi-tenant, sovereign product carbon footprint exchange on the Catena-X data space using AWS

              Post Syndicated from Kevin S. Ridolfi original https://aws.amazon.com/blogs/architecture/pacific-enables-multi-tenant-sovereign-product-carbon-footprint-exchange-on-the-catena-x-data-space-using-aws/

              This post is cowritten by Anil Akarsu and Dr. Renè Holschuh from BASF.

              BASF is a global chemical industry leader and active member of the Catena-X Automotive Network. It pioneers sustainable solutions that enable automotive organizations to track carbon emissions across complex supply chains. CircularTree transforms sustainability reporting through innovative digital solutions that systematically identify and control Scope 3 greenhouse gas (GHG) emissions across global supply networks. They establish standardized data exchange protocols through participation in forward-thinking associations including PACT, Catena-X, and ESTAINIUM. BASF and CircularTree created PACIFIC, a product powered by AWS that streamlines transparent product carbon footprint (PCF) reporting across the value chain by automating PCF data exchange, reducing manual effort, and ensuring trustworthy data sharing. Through this unique relationship, AWS helps customers integrate software, services, and processes to accelerate business transformation. This post explores how PACIFIC enables multi-tenant, sovereign PCF exchange on the Catena-X data space using Amazon Elastic Container Service (Amazon ECS) on AWS Fargate, Amazon Cognito, and AWS Identity and Access Management (IAM) to deliver measurable environmental impact and competitive advantage in a carbon-conscious marketplace.

              Carbon data at scale, across company borders

              Sustainability is now an operational requirement, driven by growing regulatory pressure in the European Union and increasing customer expectations for credible and auditable emissions data. For manufacturers in the automotive supply chain, this is especially challenging because emissions data does not live in one place. It is distributed across fragmented tiers of suppliers, different internal systems, and partner-to-partner handoffs that still happen through spreadsheets, emails, and one-off integrations.

              At the same time, the industry is converging on shared ways to exchange data, with Catena-X setting expectations for interoperability and trust in cross-company collaboration. PACIFIC was built for this reality as a multi-tenant SaaS product that enables companies to manage and exchange PCFs while maintaining data sovereignty. Its Catena-X certification signals alignment with industry standards, and the partnership with BASF grounds the platform in real supply chain requirements.

              Data security, sovereignty, and interoperability

              To make PCF exchange work in the real world, PACIFIC needed to solve two problems at the same time: enable frictionless collaboration across companies, while guaranteeing that each company stays in full control of their data and credentials. The platform had to operate as a multi-tenant software as a service (SaaS) for the supply chain, serving organizations on shared infrastructure without introducing any possibility of cross-tenant access.

              They had to build an interoperable solution that could communicate with other solution providers on the Catena-X data space, using Eclipse Dataspace Components (EDC) connectors as a standard mechanism for cross-company data exchange. That meant enforcing strict data sovereignty, not only for PCF records but also for sensitive Catena-X integration configuration such as EDC and Digital Twin Registry (DTR) credentials. At the exchange layer, PACIFIC needed end-to-end authorization aligned with Catena-X expectations, where PCF data is shared only after explicit agreement and policy negotiation through EDC. Finally, the solution had to be practical to run and scale, so the following had to happen:

              • Onboard new companies without spinning up separate AWS accounts per tenant
              • Integrate suppliers’ PCF systems like BASF without tight coupling to the exchange workflow
              • Keep the platform secure, auditable, and operable as usage grows

              Solution overview

              Figure 1 gives a high-level view of how PACIFIC is built and deployed to enable secure, multi-tenant PCF exchange on the Catena-X data space. It shows the main building blocks of the product, how user traffic reaches the application, how tenant-aware identity and authorization are enforced, and how PACIFIC separates core platform features from integrations and exchange endpoints. The diagram also highlights the external connections enabling interoperability, including supplier PCF data sources like BASF services, and EDC and DTR “enablement service providers” for Catena-X based data sharing.

              AWS Cloud architecture diagram for the PACIFIC platform showing a multi-layered system. At the top, a PACIFIC Web Client connects to an Identity & Authorization layer containing Amazon Cognito, AWS IAM, and AWS Secrets Manager. Traffic flows through AWS WAF to an Application Load Balancer within a VPC, which distributes requests to Amazon ECS (AWS Fargate) hosting four containerized microservices: core-modules, integration-module, pcf-exchange-module, and edc-dtr-module. These modules connect to Amazon RDS for relational database storage and Amazon S3 for object storage. External integrations at the bottom include BASF Product Carbon Footprint Services, an EDC/DTR Service Provider, and the Catena-X Automotive Network. The diagram illustrates a secure, microservices-based architecture for automotive industry carbon footprint data exchange.

              Figure 1: PACIFIC high-level service architecture

              Data protection through IAM-based tenant isolation

              A core requirement for PACIFIC is maintaining data protection and security. Each company must have exclusive control over their PCF data, EDC connector, and DTR management credentials, without any possibility of cross-tenant access. Rather than provisioning separate AWS accounts per tenant PACIFIC implements a fine-grained IAM-based isolation model built on Amazon Cognito and AWS Secrets Manager. When a company joins the platform, PACIFIC automatically provisions a dedicated IAM role with a scoped policy that permits access only to that company’s secrets in Secrets Manager. Users are assigned to an Amazon Cognito user pool group linked to their company’s IAM role. When a user authenticates, the Amazon Cognito identity pool maps their group membership to the corresponding IAM role, and AWS Security Token Service (AWS STS) issues temporary credentials for that role. This means, a user’s credentials can only retrieve their own company’s EDC secrets and access to other tenants’ configuration is denied at the IAM policy level. This architecture delivers true multi-tenant isolation using native AWS identity services, without the overhead of managing dedicated accounts or Amazon Virtual Private Cloud (Amazon VPC) per customer.

              Securing PCF exchange with EDC-issued authorization tokens

              Beyond tenant isolation within PACIFIC, CircularTree enforces authorization at the data exchange layer through the pcf-exchange-module, a per-tenant endpoint that serves PCF data to authorized trading partners. When a consumer’s EDC connector requests PCF data from a supplier’s EDC, the two connectors negotiate and agree on usage policies governing how the exchanged information can be used. After this agreement is established, the supplier’s EDC issues a special authorization token to the consumer’s EDC. The token derives from the supplier company’s Cognito app client credentials stored within their EDC and grants access specifically to that supplier’s pcf-exchange-module endpoint in PACIFIC. The consumer’s EDC then uses this token to call the supplier’s dedicated endpoint and retrieve the authorized PCF data. Because each tenant’s pcf-exchange-module is published as an individual endpoint, which only accepts tokens issued through the EDC handshake process, unauthorized access is prevented at multiple levels. One level is through EDC policy negotiation, and the other is through company-scoped OAuth2 token validation. This ensures that PCF data is transmitted only after explicit consent and only to the specific trading partner authorized in the data exchange agreement. Figure 2 gives an overview of the communication flow.

              Data flow diagram showing a six-step secure token exchange process between Consumer EDC and Supplier EDC systems via the PACIFIC platform on AWS. The flow proceeds as follows: (1) Consumer EDC sends a Request PCF to Supplier EDC, (2) Policy Negotiation occurs between the two EDCs (shown as a dashed line), (3) a token is issued (marked with a key icon), (4) Supplier EDC provides a Data Space URL to the pcf-exchange-module, (5) Token Validation occurs between the pcf-exchange-module and the supplier-oauth2-client component (marked with a key icon), and (6) PCF Data flows back to the Consumer EDC. The PACIFIC layer at the bottom contains two AWS-hosted components: the pcf-exchange-module (orange icon) and the supplier-oauth2-client (red icon with checkmark), demonstrating OAuth2-based secure authentication for Product Carbon Footprint data exchange.

              Figure 2: EDC-to-EDC communication with Cognito Oauth2 Tokens

              Integrating supplier PCF systems through the integration module

              While the pcf-exchange-module handles secure data exchange between trading partners using the Catena-X data space, PACIFIC also needs to ingest PCF data from suppliers’ internal systems. Running on AWS Fargate, the integration-module provides a flexible, scalable integration layer that connects to proprietary supplier PCF systems, such as BASF’s internal PCF services. Each supplier integration requires handling unique authentication flows. This ranges from OAuth2 client credentials to certificate-based authentication or API key mechanisms, all of which are securely managed through AWS Secrets Manager. The integration-module expects incoming PCF data to already conform to the standardized Catena-X PCF JSON format, ensuring consistency at the point of ingestion. After received, PCF data is stored in Amazon Simple Storage Service (Amazon S3) under company-specific prefixes. This is where IAM policies make sure that only the PCF owner company can access their respective data. By decoupling supplier system integration from the data exchange layer, PACIFIC can onboard new supplier PCF data sources without impacting the downstream Catena-X data sharing workflows. This can be done while the S3-based storage model helps maintain strict data sovereignty, and each company’s PCF data remains isolated and accessible only to its rightful owner.

              Conclusion

              PACIFIC turns Catena-X PCF exchange from a specification into an interoperable, scalable workflow running on Amazon ECS and AWS Fargate without requiring companies to give up control of their data and credentials. The impact is measurable in both speed and operational scalability. From a business perspective, BASF highlights the most tangible improvement: when a requested PCF dataset is already available, a manual exchange can take up to around seven days, whereas PACIFIC responds in seconds, and can deliver automated updates when PCFs change. This capability delivers up to 75% time savings for both customers and BASF. It also reduces the time-to-data from days to seconds and making emissions information more visible and usable in day-to-day supply chain operations. PACIFIC’s multi-tenant architecture scales onboarding and operations without managing individual AWS accounts per company, while still enforcing strong tenant isolation through IAM-scoped access control and per-tenant exchange endpoints. This scalability translates into faster onboarding, enabling BASF to integrate significantly more partners into the data space. The results are measurable: an 80% increase in newly onboarded companies between 2024 and 2025, and 55% growth in requested products and shared PCFs over the same period. This provides a scalable baseline for expanding the number of onboarded organizations and increasing the volume of PCF data exchanged as adoption grows—without weakening data sovereignty or interoperability. These results underline PACIFIC’s role as a catalyst for accelerating decarbonization across supply chains.

              We encourage you to join BASF, CircularTree, and AWS in industry data sharing through emerging data spaces and transparent, trusted PCF exchange across global supply networks. To explore more sustainability solutions and AWS architecture patterns, visit the AWS Architecture Blog and get started with PACIFIC through the Cofinity-X App Marketplace.


              About the authors

              Winter 2025 SOC 1 report is now available with 184 services in scope

              Post Syndicated from Tushar Jain original https://aws.amazon.com/blogs/security/winter-2025-soc-1-report-is-now-available-with-184-services-in-scope/

              Amazon Web Services (AWS) is pleased to announce that the Winter 2025 System and Organization Controls (SOC) 1 report is now available. The report covers 184 services over the 12-month period from January 1, 2025 – December 31, 2025, giving customers a full year of assurance. This report demonstrates our continuous commitment to adhering to the heightened expectations of cloud service providers.

              Customers can download the Winter 2025 SOC 1 report through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

              AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.

              To learn more about AWS compliance and security programs, see AWS Compliance Programs. As always, we value feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

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

              Tushar Jain

              Tushar Jain
              Tushar is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives Tushar holds a Master of Business Administration from Indian Institute of Management Shillong, India and a Bachelor of Technology in electronics and telecommunication engineering from Marathwada University, India. He has over 14 years of experience in information security and holds CISM, CCSK and CSXF certifications.

              Michael Murphy

              Michael Murphy
              Michael is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Michael has over 14 years of experience in information security and holds a master’s degree and a bachelor’s degree in computer engineering from Stevens Institute of Technology. He also holds CISSP, CRISC, CISA, and CISM certifications.

              Atulsing Patil

              Atulsing Patil
              Atulsing is a Compliance Program Manager at AWS and has over 28 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 42001 Lead Auditor, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

              Nathan Samuel

              Nathan Samuel
              Nathan is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives. Nathan has a Bachelor of Commerce degree from the University of the Witwatersrand, South Africa, and has over 21 years of experience in security assurance. He holds the CISA, CRISC, CGEIT, CISM, CDPSE, and Certified Internal Auditor certifications.

              Jeff Cheung

              Jeff Cheung
              Jeff is a Compliance Program Manager at AWS where he leads multiple security and privacy initiatives across business lines. Jeff has Bachelors degrees in Information Systems, and Economics from SUNY Stony Brook, and has over 20 years of experience in information security and assurance. Jeff has held professional certifications such as CISA, CISM, and PCI-QSA.

              Noah Miller

              Noah Miller
              Noah is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Noah has 7 years of experience in information security. He has a master’s degree in Cybersecurity Risk Management and a bachelor’s degree in Informatics from Indiana University.

              Will Black
              Will Black

              Will is a Compliance Program Manager at Amazon Web Services where he leads multiple security and compliance initiatives. Will has 10 years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he is a PCI Internal Security Assessor (ISA) for AWS and holds the CCSK and ISO 27001 Lead Implementer certifications.
              Allen Beam
              Allen Beam

              Allen is a Compliance Program Manager at Amazon Web Services supporting third-party security and privacy compliance initiatives. He has over 10 years of experience in external IT security audits, security control design and implementation, and audit readiness and control deficiency remediation. He has a Bachelor’s Degree in Economics and Finance from James Madison University.
              Ziv Wand
              Ziv Wand

              Ziv is a Compliance Program Manager at AWS and leads multiple security and privacy initiatives. Ziv has over 6 years of experience in information security assurance, external IT security audits, security control design and implementation, and audit readiness. He holds a Bachelor of Science in Management Information Systems from Binghamton University.
              Shalini Mishra
              Shalini Mishra

              Shalini is a Compliance Program Manager at AWS. She has over 5 years of experience leading end-to-end compliance programs across ISO, SOC, and cloud security frameworks, with deep expertise in third-party risk management and enterprise governance. Shalini holds a Master of Science degree in Information Systems and a CRISC certification.

              Unlock efficient model deployment: Simplified Inference Operator setup on Amazon SageMaker HyperPod

              Post Syndicated from Shreya Gangishetty original https://aws.amazon.com/blogs/architecture/unlock-efficient-model-deployment-simplified-inference-operator-setup-on-amazon-sagemaker-hyperpod/

              Amazon SageMaker HyperPod offers an end-to-end experience supporting the full lifecycle of AI development—from interactive experimentation and training to inference and post-training workflows. The SageMaker HyperPod Inference Operator is a Kubernetes controller that manages the deployment and lifecycle of models on HyperPod clusters, offering flexible deployment interfaces (kubectl, Python SDK, SageMaker Studio UI, or HyperPod CLI), advanced autoscaling with dynamic resource allocation, and comprehensive observability that tracks critical metrics like time-to-first-token, latency, and GPU utilization.

              Deploying inference workloads on Kubernetes-native infrastructure has traditionally required AI teams to navigate a maze of Helm charts, IAM role configurations, dependency management, and manual upgrades — often taking hours before a single model can serve predictions. Today, we’re announcing the Amazon SageMaker HyperPod Inference Operator as a native EKS add-on, enabling one-click installation and managed upgrades directly from the SageMaker console. This eliminates the need for manual Helm charts, complex IAM configuration tweaks, and downtime during upgrades.

              In this post, we walk through the new installation experience, demonstrate three deployment methods (console, CLI, and Terraform), and show how features like multi-instance-type deployment and native node affinity give you fine-grained control over inference scheduling

              Simplified installation experience

              The new installation experience addresses three key customer scenarios with streamlined workflows:

              New HyperPod clusters: Automatic installation

              When creating new HyperPod clusters through the SageMaker console’s Quick Setup or Custom Setup workflows, the Inference Operator along with necessary dependencies is now installed through EKS add-on automatically as part of the cluster creation process. This eliminates the need for post-deployment configuration and ensures your cluster is ready for model deployments immediately upon creation along with one click upgrades.

              Existing clusters: One-click installation

              For existing HyperPod clusters, customers can install the Inference Operator with a single click through the SageMaker console. The installation automatically:

              • Creates required IAM roles with appropriate trust relationships and permissions
              • Sets up S3 buckets for TLS certificate storage
              • Configures VPC endpoints for secure S3 access
              • Installs dependency add-ons (cert-manager, S3 CSI driver, FSx CSI driver, metrics-server)
              • Deploys the Inference Operator as an EKS add-on

              Managed upgrades and lifecycle

              The EKS add-on integration provides standardized version management with one-click upgrades through the AWS console or CLI. This ensures customers can easily adopt new features and security updates without complex manual procedures.

              The below prerequisite resources are needed to be setup before installing the Inference operator add-on. These prerequisites will be setup if SageMaker AI console is used to setup Inference operator. However, if EKS cli or console is used, these prerequisites will need to be created manually and passed to the add-on through configuration parameters. We discuss these approaches in Installation Methods.

              List of prerequisites

              1. EKS add-ons (S3 Mountpoint csi driver add-on, FsX add-on, Cert Manager add-on, Metrics server add-on)
              2. IAM roles (Inference operator execution role, ALB role, KEDA role, Optional JumpStart Gated models role)
              3. Infrastructure (S3 bucket to manage TLS certificates, OIDC association on the cluster,

              For more information refer to this trouble shooting guide.

              Installation methods

              Method 1: Install SageMaker HyperPod Inference Add-on through SageMaker UI (Recommended)

              The SageMaker console provides the most streamlined experience with two installation options:

              Quick install: Automatically creates all required resources with optimized defaults, including IAM roles, S3 buckets, and dependency add-ons. This option is ideal for getting started quickly with minimal configuration decisions.

              Custom install: Provides flexibility to specify existing resources or customize configurations while maintaining the one-click experience. Customers can choose to reuse existing IAM roles, S3 buckets, or dependency add-ons based on their organizational requirements.

              Amazon SageMaker HyperPod Inference Operator installation page showing Quick install and Custom install options with component details including AWS Load Balancer Controller, KEDA, and CSI drivers

              Prerequisites

              • An existing Amazon SageMaker HyperPod cluster with EKS orchestration
              • IAM permissions for EKS cluster administration
              • kubectl configured for cluster access

              Installation steps

              1. Navigate to the SageMaker Console: Go to HyperPod Clusters → Cluster Management
              2. Select Your Cluster: Choose the cluster where you want to install the Inference Operator

              HyperPod Dashboard main page

              1. Choose Installation Type: Navigate to Inference tab. Select Quick Install for automated setup or Custom Install for configuration flexibility

              SageMaker HyperPod Inference tab interface showing disabled cluster role and installation options for managing inference workloads

              1. Configure Options: If choosing Custom Install, specify existing resources or customize settings as needed
              2. Install: Choose Install to begin the automated installation process
              3. Verify: Check the installation status through the console, or by running kubectl get pods -n hyperpod-inference-system, or by checking the add-on status with aws eks describe-addon --cluster-name CLUSTER-NAME --addon-name amazon-sagemaker-hyperpod-inference --region REGION

              After the add-on is successfully installed, you can deploy models using the Model deployments document or navigate to Deploying Your First Model section below.

              Method 2: Install SageMaker HyperPod Inference add-on through EKS APIs

              For customers preferring command-line workflows, the Inference Operator can be installed directly using the EKS CLI. Note that all prerequisite resources (IAM roles, S3 buckets, VPC endpoints) and dependency add-ons must be created manually before installing the Inference Operator add-on. For detailed setup instructions, see the installation guide.

              aws eks create-addon \
                --cluster-name my-hyperpod-cluster \
                --addon-name amazon-sagemaker-hyperpod-inference \
                --addon-version v1.0.0-eksbuild.1 \
                --configuration-values '{
                  "executionRoleArn": "arn:aws:iam::ACCOUNT-ID:role/SageMakerHyperPodInference-inference-role",
                  "tlsCertificateS3Bucket": "hyperpod-tls-certificate-bucket",
                  "hyperpodClusterArn": "arn:aws:sagemaker:REGION:ACCOUNT-ID:cluster/CLUSTER-ID",
                  "alb": {
                    "serviceAccount": {
                      "create": true,
                      "roleArn": "arn:aws:iam::ACCOUNT-ID:role/alb-controller-role"
                    }
                  },
                  "keda": {
                    "auth": {
                      "aws": {
                        "irsa": {
                          "roleArn": "arn:aws:iam::ACCOUNT-ID:role/keda-operator-role"
                        }
                      }
                    }
                  }
                }' \
                --region us-west-2
              

              Method 3: Install SageMaker HyperPod Inference add-on through Terraform deployment

              Organizations utilizing Terraform for Infrastructure as Code (IaC) can deploy HyperPod clusters using the provided modules in the awesome-distributed-training GitHub repository.

              To enable the HyperPod inference operator, set the create_hyperpod_inference_operator_module variable to true within your custom.tfvars file, as shown below:

              kubernetes_version    = "1.33"
              eks_cluster_name      = "tf-eks-cluster"
              hyperpod_cluster_name = "tf-hp-cluster"
              resource_name_prefix  = "tf-eks-test"
              aws_region            = "us-east-1"
              
              instance_groups = [
                  {
                      name                      = "accelerated-instance-group-1"
                      instance_type             = "ml.g5.8xlarge",
                      instance_count            = 2,
                      availability_zone_id      = "use1-az2",
                      ebs_volume_size_in_gb     = 100,
                      threads_per_core          = 1,
                      enable_stress_check       = false,
                      enable_connectivity_check = false,
                      lifecycle_script          = "on_create.sh"
                  }
              ]
              
              create_hyperpod_inference_operator_module = true
              

              In addition to the HyperPod inference operator add-on, the Terraform modules also support the task governance, training operator, and observability add-ons as well. Check out the documentation for enabling optional add-ons for more details.

              Dependency management

              The HyperPod inference operator includes several additional dependencies, which are enabled by default but can be toggled off if they already exist on your EKS cluster:

              Dependency Module/Variable Toggle to Disable
              cert-manager Installed via the HyperPod module enable_cert_manager = false
              Amazon FSx for Lustre CSI Installed via FSx module create_fsx_module = false
              Mountpoint for Amazon S3 CSI Bundled with Inference Operator Module enable_s3_csi_driver = false
              AWS Load Balancer Controller Bundled with Inference Operator EKS add-on enable_alb_controller = false
              KEDA Operator Bundled with Inference Operator EKS add-on enable_keda = false

              Key benefits

              Faster time to value

              Teams can now deploy their first inference endpoint within minutes of cluster creation, compared to the previous multi-hour setup process. This acceleration enables faster experimentation and reduces the barrier to adoption for new teams.

              Reduced complexity

              The new installation experience eliminates the need to manually create and configure multiple AWS resources. Previously, customers needed to create IAM roles, policies, S3 buckets, VPC endpoints, and install multiple Kubernetes operators. Now, a single action handles all these requirements automatically.

              Consistent configuration

              Automated resource creation ensures consistent, secure configurations across environments. The installation process follows AWS best practices for IAM permissions, network security, and resource naming conventions.

              Simplified upgrades

              EKS Add-on integration provides standardized upgrade paths with rollback capabilities. Customers can confidently adopt new features and security updates through the familiar AWS console or CLI interfaces.

              Advanced features integration

              The simplified installation experience seamlessly integrates with advanced HyperPod inference capabilities:

              Managed tiered KV cache

              During installation, customers can optionally enable managed tiered KV cache with intelligent memory allocation based on instance types. This feature can reduce inference latency by up to 40% for long-context workloads while optimizing memory utilization across the cluster.

              Intelligent routing

              The installation automatically configures intelligent routing capabilities with multiple strategies (prefix-aware, KV-aware, round-robin) to maximize cache efficiency and minimize inference latency based on workload characteristics.

              Observability integration

              Built-in integration with HyperPod Observability provides immediate visibility into inference metrics, cache performance, and routing efficiency through Amazon Managed Grafana dashboards.

              Deploying your first model

              Once the add-on is installed, you can deploy models using the InferenceEndpointConfig or JumpStart models custom resources. Here’s an example configuration for deploying a Llama model:

              apiVersion: inference.sagemaker.aws.amazon.com/v1
              kind: JumpStartModel
              metadata:
                name: deepseek-test-endpoint
              spec:
                model:
                  modelId: "deepseek-llm-r1-distill-qwen-1-5b"
                sageMakerEndpoint:
                  name: deepseek-test-endpoint
                server:
                  instanceType: "ml.g5.8xlarge"
              

              New features

              Multi-Instance Type Deployment HyperPod Inference supports multi-instance type deployment, enhancing deployment reliability and resource utilization. You can specify a prioritized list of instance types in your deployment configuration, and the system automatically selects from available alternatives when your preferred instance type lacks capacity. The Kubernetes scheduler evaluates instance types in priority order using node affinity rules based scheduling, seamlessly placing workloads on the highest-priority available instance type. In the example below, when deploying a model from S3, ml.p4d.24xlarge has the highest priority and will be selected first if memory capacity is available. If ml.p4d.24xlarge is unavailable, the scheduler automatically falls back to ml.g5.24xlarge, and finally to ml.g5.8xlarge as the last resort.

              apiVersion: inference.sagemaker.aws.amazon.com/v1
              kind: InferenceEndpointConfig
              metadata:
                name: lmcache-test-1
                namespace: default
              spec:
                replicas: 13
                modelName: Llama-3.1-8B-Instruct
                instanceTypes: ["ml.p4d.24xlarge","ml.g5.24xlarge","ml.g5.8xlarge"]
              

              This is implemented using Kubernetes node affinity rules with requiredDuringSchedulingIgnoredDuringExecution to restrict scheduling to the specified instance types, and preferredDuringSchedulingIgnoredDuringExecution with descending weights to enforce priority ordering.

              Node affinity
              For scenarios requiring more granular scheduling control — such as excluding spot instances, preferring specific availability zones, or targeting nodes with custom labels — HyperPod Inference exposes Kubernetes’ native nodeAffinity directly in the InferenceEndpointConfig spec. This gives you the full expressiveness of Kubernetes scheduling primitives.

              apiVersion: inference.sagemaker.aws.amazon.com/v1
              kind: InferenceEndpointConfig
              metadata:
                name: lmcache-test-1
                namespace: default
              spec:
                replicas: 15
                modelName: Llama-3.1-8B-Instruct
                nodeAffinity:
                  preferredDuringSchedulingIgnoredDuringExecution:
                  - weight: 100
                    preference:
                      matchExpressions:
                      - key: node.kubernetes.io/instanceType
                        operator: In
                        values: ["ml.g5.4xlarge"]
                worker:
                  resources:
                    limits:
                      nvidia.com/gpu: "1"
                    requests:
                      cpu: "6"
                      memory: 30Gi
                      nvidia.com/gpu: "1"
              

              Clean up

              To clean up your environment after completing this walkthrough, follow these steps to remove the deployed models and uninstall the Inference Operator add-on from your HyperPod cluster.

              Removing Inference Operator add-on

              Through the SageMaker console:

              1. Navigate to SageMaker Console → HyperPod Clusters → Cluster Management
              2. Select your cluster and go to the Inference tab
              3. Choose Remove to uninstall the Inference Operator add-on and associated resources

              Alternatively, using the AWS CLI:

              aws eks delete-addon \
              --cluster-name <my-hyperpod-cluster> \
              --addon-name amazon-sagemaker-hyperpod-inference \
              --region <region>

              Delete the deployed models

              # Delete JumpStartModel deployment
              kubectl delete jumpstartmodel <model-name> -n <namespace>
              
              # Or for InferenceEndpointConfig deployment
              kubectl delete inferenceendpointconfig <endpoint-name> -n <namespace>

              Migration path for existing users

              Automated migration script is hosted in public GitHub that transitions the HyperPod Inference Operator from Helm to EKS add-on with built-in rollback capabilities if add-on installation fails. Backup files are stored in /tmp/hyperpod-migration-backup-<timestamp>/ for manual rollback if needed.

              Key features

              • Auto-Discovery: Derives configuration from existing Helm deployment (roles, buckets, dependencies)
              • Safe Migration: Scales down Helm deployments before add-on installation, validates prerequisites
              • Dependency Handling: Migrates S3/FSx CSI drivers, cert-manager, and metrics-server to add-ons
              • Rollback Support: Preserves original resources and restores on failure

              IAM Roles created

              1. Execution Role (Inference Operator + S3 TLS access)
              2. JumpStart Gated Model Role
              3. ALB Controller Role
              4. KEDA Operator Role

              Examples for running the script

              # to follow step by step guide
              ./helm_to_addon.sh --cluster-name <my-cluster> --region us-east-1 
              
              # no prompts needed except for initiating rollback in case of failure
              ./helm_to_addon.sh --cluster-name <my-cluster> --region us-east-1 --auto-approve 
              
              # To skip the dependencies FSX, S3, Metricsserver, cert manager migration from Inference operator helm to respective add-ons
              ./helm_to_addon.sh --cluster-name my-cluster —region us-east-1 --skip-dependencies-migration
              

              Migration flow

              1. Validate existing Helm installation
              2. Auto-derive configuration and create new IAM roles
              3. Tag resources (ALBs, ACM certs, S3 objects) with CreatedBy: HyperPodInference
              4. Install dependency add-ons (S3, FSx, cert-manager) if dependent CRDs don’t exist
              5. Scale down Helm deployments for ALB, KEDA and Inference operator
              6. Install Inference Operator add-on with OVERWRITE flag
              7. Clean up old Helm resources
              8. Migrate Helm-installed dependencies that are installed through Inference operator main chart to add-ons. To skip this step provide --skip-dependencies flag.

              Benefits

              • Simplified management through EKS console/APIs
              • Automated updates via EKS add-on mechanisms
              • Native EKS integration
              • Zero downtime migration with rollback safety

              Conclusion

              The streamlined Inference Operator installation experience for Amazon SageMaker HyperPod eliminates infrastructure complexity and accelerates time to value for machine learning teams. With one-click installation, automated resource management, and seamless upgrade capabilities, teams can focus on deploying and optimizing their inference workloads rather than managing underlying infrastructure.

              The EKS Add-on integration provides enterprise-grade lifecycle management while maintaining the flexibility to customize configurations for specific organizational requirements. Combined with advanced features like managed tiered KV cache and intelligent routing, this simplified installation experience makes high-performance inference deployment accessible to teams of all sizes.

              Get started today by creating a new HyperPod cluster with the Inference Operator pre-installed, or add it to your existing clusters with a single click through the SageMaker console. For detailed add-on installation instructions and configuration options see this guide and for troubleshooting see this guide.

              Appendix


              About the authors

              AWS European Sovereign Cloud achieves first compliance milestone: SOC 2 and C5 reports plus seven ISO certifications

              Post Syndicated from Julian Herlinghaus original https://aws.amazon.com/blogs/security/aws-european-sovereign-cloud-achieves-first-compliance-milestone-soc-2-and-c5-reports-plus-seven-iso-certifications/

              In January 2026, we announced the general availability of the AWS European Sovereign Cloud, a new, independent cloud for Europe entirely located within the European Union (EU), and physically and logically separate from all other AWS Regions. The unique approach of the AWS European Sovereign Cloud provides the only fully featured, independently operated sovereign cloud backed by strong technical controls, sovereign assurances, and legal protections designed to meet the sensitive data needs of European governments and enterprises.

              One of the foundational components of how AWS European Sovereign Cloud enables verifiable trust of technical controls and delivers assurance is through our compliance programs and assurance frameworks. These programs help customers understand the robust controls in place at AWS European Sovereign Cloud to maintain security and compliance of the cloud. To meet the needs of our customers, we committed that the AWS European Sovereign Cloud will maintain key certifications such as ISO/IEC 27001:2022, System and Organization Controls (SOC) reports, and Cloud Computing Compliance Criteria Catalogue (C5) attestation, all validated regularly by independent auditors to assure our controls are designed appropriately, operate effectively, and can help customers satisfy their compliance obligations.

              Today, AWS European Sovereign Cloud is pleased to announce that SOC 2 and C5 Type 1 attestation reports, along with seven key ISO certifications (ISO 27001:2022, 27017:2015, 27018:2019, 27701:2019, 22301:2019, 20000-1:2018, and 9001:2015) are now available. These attestation reports and certifications cover 69 AWS services operating within the AWS European Sovereign Cloud, and this achievement marks a pivotal first step in our journey to establish the AWS European Sovereign Cloud as a trusted and compliant cloud for European organizations. By securing these foundational certifications and attestation reports early in our implementation, we are demonstrating our commitment to earning customer trust. AWS European Sovereign Cloud customers in Germany and across Europe can now run their applications with enhanced assurance and confidence that our infrastructure aligns with internationally recognized security standards and the AWS European Sovereign Cloud: Sovereign Reference Framework (ESC-SRF). These certifications and attestation reports provide independent validation of our security controls and operational practices, demonstrating our commitment to meeting the heightened expectations towards cloud service providers. Beyond compliance, these certifications and reports help customers meet regulatory requirements and innovate with confidence.

              SOC 2 Type 1 report

              SOC reports are independent third-party examinations that show how AWS European Sovereign Cloud meets compliance controls and sovereignty objectives. The AWS European Sovereign Cloud SOC 2 report addresses three critical AICPA Trust Services Criteria: Security, Availability, and Confidentiality and includes internal controls mapped to the ESC-SRF. The ESC-SRF establishes sovereignty criteria across key domains including governance independence, operational control, data residency, and technical isolation. As part of the SOC 2 Type 1 attestation, independent third-party auditors have validated suitability of the design and implementation of our controls addressing measures such as independent European Union (EU) corporate structures, operation by EU-resident AWS personnel, strict residency requirements for Customer Content and Customer-Created Metadata, and separation from all other AWS Regions. The ESC-SRF controls in our SOC 2 report show customers how AWS delivers on its sovereignty commitments.

              C5 Type 1 report

              C5 is a German Government-backed attestation scheme introduced in Germany by the Federal Office for Information Security (BSI) and represents one of the most comprehensive cloud security standards in Europe. The AWS European Sovereign Cloud C5 Type 1 report provides customers with independent third-party attestation on the suitability of the design and implementation of our controls to meet both C5 basic criteria and C5 additional criteria.

              The basic criteria establish fundamental security requirements for cloud service providers, covering areas such as organization of information security, human resources security, asset management, access control, cryptography, physical security, operations security, communications security, system acquisition and development, supplier relationships, incident management, business continuity, and compliance. The additional criteria address enhanced requirements for handling sensitive data and critical applications, making this attestation particularly valuable for AWS European Sovereign Cloud customers with stringent data security and sovereignty requirements.

              Key ISO certifications

              AWS European Sovereign Cloud has achieved seven key ISO certifications that collectively demonstrate comprehensive operational excellence:

              These certifications confirm that AWS European Sovereign Cloud has integrated rigorous security, privacy, continuity, service delivery, and quality programs into a comprehensive framework, helping to ensure sensitive information remains secure, services remain available, and operations meet the highest standards through systematic risk management processes and continuous improvement practices.

              How to access the reports

              To access SOC 2, C5 reports and ISO certifications, customers should sign in to their AWS European Sovereign Cloud account and navigate to AWS Artifact in the AWS Management Console. AWS Artifact is a self-service portal that provides on-demand access to AWS compliance reports and certifications.

              We recognize that compliance is not a destination but a continuous journey, and these initial SOC 2, C5 reports and ISO certifications represent the beginning of our certification portfolio. They lay the essential groundwork upon which we will continue to build to meet AWS European Sovereign Cloud customers’ compliance needs as they continue to evolve. As we expand our compliance coverage in the months ahead, customers can be confident that security, transparency, and regulatory alignment have been part of the very DNA of the AWS European Sovereign Cloud design from day one. To learn more about our compliance and security programs, visit AWS European Sovereign Cloud Compliance, or reach out to your AWS European Sovereign Cloud account team.

              Security and compliance is a shared responsibility between AWS European Sovereign Cloud and the customer. For more information, see the AWS Shared Security Responsibility Model.

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

              Julian Herlinghaus

              Julian Herlinghaus

              Julian is a Manager in AWS Compliance & Security Assurance based in Berlin, Germany. He is the third-party audit program lead for EMEA and has worked on compliance and assurance for the AWS European Sovereign Cloud. He previously worked as an information security department lead of an accredited certification body and has multiple years of experience in information security and security assurance and compliance.

              Tea Jioshvili

              Tea Jioshvili

              Tea is a Manager in AWS Compliance & Security Assurance based in Berlin, Germany. She leads various third-party audit programs across Europe. She previously worked in security assurance and compliance, business continuity, and operational risk management in the financial industry for 20 years.

              Atul Patil

              Atulsing Patil
              Atulsing is a Compliance Program Manager at AWS. He has 29 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, ISO 42001 Lead Auditor, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

              AWS Security Hub is expanding to unify security operations across multicloud environments

              Post Syndicated from Gee Rittenhouse original https://aws.amazon.com/blogs/security/aws-security-hub-is-expanding-to-unify-security-operations-across-multicloud-environments/

              After talking with many customers, one thing is clear: the security challenge has not gotten easier. Enterprises today operate across a complex mix of environments, including on-premises infrastructure, private data centers, and multiple clouds, often with tools that were never designed to work together. The result is enterprise security teams spend more time managing tools than managing risk, making it harder to stay ahead of threats across an increasingly complex environment.

              At Amazon Web Service (AWS), we believe security should be simple, integrated, and built for the way enterprises actually operate. This belief is what drove us to reimagine AWS Security Hub, delivering full-stack security through a single experience, and this vision is driving our next chapter.

              Building on a foundation of unified security

              We transformed Security Hub into a unified security operations solution by bringing together AWS security services, including Amazon GuardDuty, Amazon Inspector, AWS Security Hub Cloud Security Posture Management (Security Hub CSPM), and Amazon Macie, into a single experience that automatically and continuously analyzes security signals across threats, vulnerabilities, misconfigurations, and sensitive data. Security Hub delivers a common foundation, bringing together findings from across your AWS environment so your security team spends less time translating signals and more time acting on them. Built on top of that foundation, a unified operations layer gives security teams near real-time risk analytics, automated analysis, and prioritized insights, helping them focus on what matters most, at scale.

              We also introduced new capabilities (the Extended plan) that simplify how enterprises procure, deploy, and integrate a full-stack security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. Now, customers can use Security Hub to expand their security portfolio through a curated selection of AWS Partner solutions (at launch: 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk (a Cisco company), Upwind, and Zscaler), all through one unified experience. With AWS as the seller of record, you benefit from pay-as-you-go pricing, a single bill, and no long-term commitments. Our goal is simple: unified security, everywhere your enterprise operates.

              Freedom to innovate, wherever your workloads are

              At AWS, interoperability means giving customers the freedom to choose solutions that best suit their needs, and the ability to use them wherever their workloads run. But freedom to innovate across multicloud environments also means that it is critical to secure them consistently, and without adding operational complexity.

              What’s coming for Security Hub

              In the coming months, we are expanding Security Hub with new multicloud capabilities that extend unified security operations beyond AWS. The foundation of this expansion is a common data layer that unifies security signals from wherever your workloads run. On top of that, a unified policy and operations layer delivers consistent posture management, exposure analysis, and risk prioritization, so your security team operates from a single view of risk rather than a fragmented collection of consoles.

              Security Hub will deliver unified risk analytics that surface critical risks across your multicloud estate. You’ll be able to manage cloud security posture with Security Hub CSPM checks that give you consistent posture visibility, and extend vulnerability management with expanded Amazon Inspector capabilities, including virtual machine scanning, container image scanning, and serverless scanning. Security Hub will also deliver external network scanning that enriches security findings with context about internet-facing exposure across your multicloud environment, including for resources not running in AWS.

              The result is more comprehensive risk coverage across your enterprise. It’s about giving your security team a single, unified experience to detect and respond to risks, wherever you operate.

              Security as a business enabler

              The security leaders I speak with aren’t just asking for better tools. They’re asking for a way to get ahead of risk, not just manage it. They want security that keeps pace with the business, not security that slows it down.

              That’s the vision behind AWS Security Hub: unified security through a single, integrated security operations experience, built on a common data foundation, powered by intelligent analytics, and delivered through a consistent operations layer, to help reduce security risk, improve team productivity, and strengthen security operations across AWS and beyond.

              Our multicloud expansion is underway, and we are just getting started.

              You can learn more at aws.amazon.com/security-hub, or visit us at the AWS booth (S-0466) at RSA Conference, March 23–26 in San Francisco.

              Gee Rittenhouse
              Gee Rittenhouse

              Gee is the Vice President of Security Services at AWS, overseeing key services including Security Hub, GuardDuty, and Inspector. He holds a PhD from MIT and brings extensive leadership experience across enterprise security and cloud. He previously served as CEO of Skyhigh Security and Senior Vice President and General Manager of Cisco’s Security Business Group, where he was responsible for Cisco’s worldwide cybersecurity business.

              AWS completes the 2026 annual Dubai Electronic Security Centre (DESC) certification audit

              Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/aws-completes-the-2026-annual-dubai-electronic-security-centre-desc-certification-audit/

              We’re excited to announce that Amazon Web Services (AWS) has completed the annual Dubai Electronic Security Centre (DESC) certification audit to operate as a Tier 1 Cloud Service Provider (CSP) for the AWS Middle East (UAE) Region.

              This alignment with DESC requirements demonstrates our continued commitment to adhere to the heightened expectations for CSPs. Government customers of AWS can run their applications in AWS Cloud-certified Regions with confidence.

              The AWS compliance to the DESC Framework requirements were validated by an independent third-party auditor (BSI) prior to issuance of a renewed certificate by DESC. The updated DESC CSP certificate is available through AWS Artifact, and is valid for one year to January 22, 2027. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

              The certification includes the following 10 additional services in scope, for a total of 108 services:

              This is a 10% increase in the number of services in the Middle East (UAE) Region that are in scope of the DESC CSP certification.

              AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. You can also reach out to your AWS account team if you have any questions or feedback about DESC compliance.

              To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

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

              Tariro Dongo
              Tariro Dongo

              Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.

              2025 ISO and CSA STAR certificates are now available with one additional service and one new region

              Post Syndicated from Chinmaee Parulekar original https://aws.amazon.com/blogs/security/2025-iso-and-csa-star-certificates-are-now-available-with-one-additional-service-and-one-new-region/

              Amazon Web Services (AWS) successfully completed the annual recertification audit with no findings for ISO 9001:2015, 27001:2022, 27017:2015, 27018:2019, 27701:2019, 20000-1:2018, 22301:2019, and Cloud Security Alliance (CSA) STAR Cloud Controls Matrix (CCM) v4.0. The objective of the audit was to enable AWS to expand their ISO and CSA STAR certifications to include one new AWS Region and one new AWS service to the scope. The ISO standards cover areas including quality management, information security, cloud security, privacy protection, service management, and business continuity. The certifications demonstrate the commitment of AWS to maintaining robust security controls and protecting customer data across our services.

              As part of this recertification audit, one new Region [Asia Pacific (Taipei)] and one new service (AWS Deadline Cloud) were added into the scope since the last certification issued November 25, 2025.

              For a full list of AWS services that are certified under ISO and CSA Star, see the AWS
              ISO and CSA STAR Certified page.
              Customers can also access the certifications in the AWS Management Console through AWS Artifact.

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

              Chinmaee Parulekar

              Chinmaee Parulekar

              Chinmaee is a Compliance Program Manager at AWS. She has 6 years of experience in information security. Chinmaee holds a Master of Science degree in Management Information Systems and professional certifications such as CISA, HITRUST CCSF practitioner.

              Atul Patil

              Atulsing Patil
              Atulsing is a Compliance Program Manager at AWS. He has 27 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 27001 Lead Auditor, HITRUST CSF, ISO 42001 Lead Auditor, Archer Certified Consultant, and AWS CCP.