Tag Archives: Foundational (100)

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 ClustersCluster 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 ClustersCluster 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.

            Enhanced access denied error messages with policy ARNs

            Post Syndicated from Stella Hie original https://aws.amazon.com/blogs/security/enhanced-access-denied-error-messages-with-policy-arns/

            To help you troubleshoot access denied errors, we recently added the Amazon Resource Name (ARN) of the denying policy to access denied error messages. This builds on our 2021 enhancement that added the type of the policy denying the access to access denied error messages. The ARN of the denying policy is only provided in same-account and same-organization scenarios. This change is gradually rolling out across all AWS services in all AWS Regions.

            What changed?

            We added the policy ARN to access denied error messages for AWS Identity and Access Management (IAM) and AWS Organizations policies. Because of this change, you can now pinpoint the exact policy causing the denial. You don’t have to evaluate all the policies of the same type in your AWS environment to identify the culprit. The policy types covered in this update are service control policies (SCPs), resource control policies (RCPs), permissions boundaries policies, session policies, and identity-based policies.

            For example, when a developer attempts to perform the ListRoles action in IAM and is denied because of an SCP:

            Before:
            An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::123456789012:user/Matt is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::123456789012:role/* with an explicit deny in a service control policy

            Enhanced:
            An error occurred (AccessDenied) when calling the ListRoles operation: User: arn:aws:iam::123456789012:user/Matt is not authorized to perform: iam:ListRoles on resource: arn:aws:iam::123456789012:role/* with an explicit deny in a service control policy: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-2kgnabcd

            How this enhancement works

            This enhancement is designed with three principles:

            • Limited scope – Same account and same organization only: Policy ARNs are only included when the request originates from either the same AWS account or the same organization as the policy. This limits the scope of the flow of information.
            • Additional context in the form of ARN only and not policy content: The additional context covers only the policy ARN, which is a resource identifier, not the policy document itself. It does not reveal the policy’s permissions or conditions that you would have to update to grant access. Users would still need appropriate permissions to read the policy content or take actions.
            • No change to authorization logic: This enhancement only affects the error message displayed, not the authorization decision-making process. The same policies deny or allow access as before, and we are not changing how the decision is made.

            How this benefits you

            This accelerates troubleshooting across your organization. Previously, when you received an access denied error from a policy, for example an SCP, you had to review all SCPs in your organization, determine which applied to the account, and evaluate each one—a process that could take time. Now, with the specific SCP ARN included in the error message, whoever has the necessary permission can review the identified SCP and more quickly resolve the issue. This precision reduces the investigative burden. Clear error messages with policy ARNs also improve communication between teams who need access and teams who troubleshoot issues by providing a common reference point, eliminating ambiguity and reducing back-and-forth communication. Lastly, when validating security controls, the policy ARN in access denied errors provides immediate confirmation of which policy is enforcing the restriction, enabling customers to quickly verify their policies are correctly denying access.

            How you can use the new information

            Let’s say you’re trying to describe your Amazon Relational Database Service (Amazon RDS) snapshots in the us-east-2 Region by calling this API:
            aws rds describe-db-snapshots --region us-east-2

            Unfortunately you get an access denied error. The error message shows:
            An error occurred (AccessDenied) when calling the DescribeDBSnapshots operation: User: arn:aws:sts::123456789012:assumed-role/ReadOnly/ReadOnlySession is not authorized to perform: rds:DescribeDBSnapshots on resource: arn:aws:rds:us-east-2:123456789012:snapshot:* with an explicit deny in a service control policy: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-lvi9abcd

            You can see the context to understand what happens:

            • It’s an explicit deny. This means there’s a policy that denies this action for a specific context
            • The deny comes from the SCP with this ARN: arn:aws:organizations::987654321098:policy/o-qv5af4abcd/service_control_policy/p-lvi9abcd

            Here’s how you can troubleshoot this error:

            1. Ensure you have necessary permission to view the SCP. If you don’t, contact your administrator and provide the message that includes the policy ARN.
            2. If you have the necessary permission, go to the AWS Management Console for AWS Organizations to access the SCP.
            3. Check for a Deny statement for the action. In the preceding example, the action is rds:DescribeDBSnapshots.
            4. You can alter the statement to remove the Deny if it’s no longer applicable. For more information, see Update a service control policy (SCP).
            5. Re-try your operation. Repeat the troubleshooting process if you get other access denied errors due to different reasons or policies.

            When will this change become available?

            This update is gradually rolling out across all AWS services in all AWS Regions, beginning early 2026.

            Need more assistance?

            If you have any questions or issues, contact AWS Support or your Technical Account Manager (TAM).

            Stella Hie

            Stella Hie

            Stella is a Senior Technical Product Manager for AWS Identity and Access Management (IAM). She specializes in improving developer experience and tooling while maintaining strong security standards. Her work focuses on making IAM straightforward to use and improving the troubleshooting experience for AWS customers. In her free time, she enjoys playing piano and bouldering.

            2025 FINMA ISAE 3000 Type II attestation report available with 183 services in scope

            Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/2025-finma-isae-3000-type-ii-attestation-report-available-with-183-services-in-scope/

            Amazon Web Services (AWS) is pleased to announce the issuance of the Swiss Financial Market Supervisory Authority (FINMA) Type II attestation report with 183 services in scope.

            The Swiss Financial Market Supervisory Authority (FINMA) has published several requirements and guidelines about engaging with outsourced services for the regulated financial services customers in Switzerland.

            An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to support of adherence with FINMA requirements.

            The latest report covers the 12-month period from October 1, 2024 to September 30, 2025 for the following circulars:

            • 2018/03 Outsourcing – banks, insurance companies and selected financial institutions under FinIA
            • 2023/01 Operational risks and resilience – banks
            • Business Continuity Management (BCM) minimum standards proposed by the Swiss Insurance Association.

            AWS has added the following five services to the current FINMA scope:

            Customers can find the FINMA ISAE 3000 report on AWS Artifact. 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.
            Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

            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 PiTuKri ISAE 3000 Type II attestation report available with 183 services in scope

            Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/2025-pitukri-isae-3000-type-ii-attestation-report-available-with-183-services-in-scope/

            Amazon Web Services (AWS) is pleased to announce the issuance of the Criteria to Assess the Information Security of Cloud Services (PiTuKri) Type II attestation report with 183 services in scope.

            The Finnish Transport and Communications Agency (Traficom) Cyber Security Centre published PiTuKri, which consists of 52 criteria that provide guidance across 11 domains for assessing the security of cloud service providers.

            An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to demonstrate adherence with PiTuKri requirements. This attestation demonstrates the AWS commitment to meet security expectations for cloud service providers set by Traficom.

            The latest report covers a 12-month period from October 1, 2024 to September 30, 2025. AWS has added the following five services to the current PiTuKri scope:

            Customers can find the PiTuKri ISAE 3000 report on AWS Artifact. 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.

            Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.

            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.

            AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings

            Post Syndicated from Atulsing Patil original https://aws.amazon.com/blogs/security/aws-successfully-completed-its-first-surveillance-audit-for-iso-420012023-with-no-findings/

            In November 2024, Amazon Web Services (AWS) was the first major cloud service provider to announce the ISO/IEC 42001 accredited certification for AI services, covering: Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe.

            In November 2025, AWS successfully completed its first surveillance audit for ISO 42001:2023, Artificial Intelligence Management System with no findings.

            This demonstrates the continual commitment of AWS to responsible AI practices. With this independent validation, our customers can gain further assurances around the AWS commitment to responsible AI and their ability to build and operate AI applications responsibly using AWS services.

            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.
             

            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, Archer Certified Consultant, and AWS CCP.

            IAM Identity Center now supports IPv6

            Post Syndicated from Suchintya Dandapat original https://aws.amazon.com/blogs/security/iam-identity-center-now-supports-ipv6/

            Amazon Web Services (AWS) recommends using AWS IAM Identity Center to provide your workforce access to AWS managed applications—such as Amazon Q Developer—and AWS accounts. Today, we announced IAM Identity Center support for IPv6. To learn more about the advantages of IPv6, visit the IPv6 product page.

            When you enable IAM Identity center, it provides an access portal for workforce users to access their AWS applications and accounts either by signing in to the access portal using a URL or by using a bookmark for the application URL. In either case, the access portal handles user authentication before granting access to applications and accounts. Supporting both IPv4 and IPv6 connectivity to the access portal helps facilitate seamless access for clients, such as browsers and applications, regardless of their network configuration.

            The launch of IPv6 support in IAM Identity Center introduces new dual-stack endpoints that support both IPv4 and IPv6, so that users can connect using IPv4, IPv6, or dual-stack clients. Current IPv4 endpoints continue to function with no action required. The dual stack capability offered by Identity Center extends to managed applications. When users access the application dual-stack endpoint, the application automatically routes to the Identity Center dual-stack endpoint for authentication. To use Identity Center from IPv6 clients, you must direct your workforce to use the new dual-stack endpoints, and update configurations on your external identity provider (IdP), if you use one.

            In this post, we show you how to update your configuration to allow IPv6 clients to connect directly to IAM Identity Center endpoints without requiring network address translation services. We also show you how to monitor which endpoint users are connecting to. Before diving into the implementation details, let’s review the key phases of the transition process.

            Transition overview

            To use IAM Identity Center from an IPv6 network and client, you need to use the new dual-stack endpoints. Figure 1 shows what the transition from IPv4 to IPv6 over dual-stack endpoints looks like when using Identity Center. The figure shows:

            • A before state where clients use the IPv4 endpoints.
            • The transition phase, when your clients use a combination of IPv4 and dual-stack endpoints.
            • After the transition is complete, your clients will connect to dual-stack endpoints using their IPv4 or IPv6, depending on their preferences.

            Figure 1: Transition from IPv4-only to dual-stack endpoints

            Figure 1: Transition from IPv4-only to dual-stack endpoints

            Prerequisites

            You must have the following prerequisites in place to enable IPv6 access for your workforce users and administrators:

            • An existing IAM Identity Center instance
            • Updated firewalls or gateways to include the new dual-stack endpoints
            • IPv6 capable clients and networks

            Work with your network administrators to update the configuration of your firewalls and gateways and to verify that your clients, such as laptops or desktops, are ready to accept IPv6 connectivity. If you have already enabled IPv6 connectivity for other AWS services, you might be familiar with these changes. Next, implement the two steps that follow.

            Step 1: Update your IdP configuration

            You can skip this step If you don’t use an external IdP as your identity source.

            In this step, you update the Assertion Consumer Service (ACS) URL from your IAM Identity Center instance into your IdP’s configuration for single sign-on and the SCIM configuration for user provisioning. Your IdP’s capability determines how you update the ACS URLs. If your IdP supports multiple ACS URLs, configure both IPv4 and dual-stack URLs to enable a flexible transition. With that configuration, some users can continue using IPv4-only endpoints while others use dual-stack endpoints for IPv6. If your IdP supports only one ACS URL, to use IPv6 you must update the new dual-stack ACS URL in your IdP and transition all users to using dual-stack endpoints. If you don’t use an external IdP, you can skip this step and go to the next step.

            Update both the SAML single sign-on and the SCIM provisioning configurations:

            1. Update the single sign-on settings in your IdP to use the new dual-stack URLs. First, locate the URLs in the AWS Management Console for IAM Identity Center.
              1. Choose Settings in the navigation pane and then select Identity source.
              2. Choose Actions and select Manage authentication.
              3. in Under Manage SAML 2.0 authentication, you will find the following URLs under Service provider metadata:
                • AWS access portal sign-in URL
                • IAM Identity Center Assertion Consumer Service (ACS) URL
                • IAM Identity Center issuer URL
            2. If your IdP supports multiple ACS URLs, then add the dual-stack URL to your IdP configuration alongside existing IPv4 one. With this setting, you and your users can decide when to start using the dual-stack endpoints, without all users in your organization having to switch together.

              Figure 2: Dual-stack single sign-on URLs

              Figure 2: Dual-stack single sign-on URLs

            3. If your IdP does not support multiple ACS URLs, replace the existing IPv4 URL with the new dual-stack URL, and switch your workforce to use only the dual-stack endpoints.
            4. Update the provisioning endpoint in your IdP. Choose Settings in the navigation pane and under Identity source, choose Actions and select Manage provisioning. Under Automatic provisioning, copy the new SCIM endpoint that ends in api.aws. Update this new URL in your external IdP.

              Figure 3: Dual-stack SCIM endpoint URL

              Figure 3: Dual-stack SCIM endpoint URL

            Step 2: Locate and share the new dual-stack endpoints

            Your organization needs two kinds of URLs for IPv6 connectivity. The first is the new dual-stack access portal URL that your workforce users use to access their assigned AWS applications and accounts. The dual-stack access portal URL is available in the IAM Identity Center console, listed as the Dual-stack in the Settings summary (you might need to expand the Access portal URLs section, shown in Figure 4).

            Figure 4: Locate dual-stack access portal endpoints

            Figure 4: Locate dual-stack access portal endpoints

            This dual-stack URL ends with app.aws as its top-level domain (TLD). Share this URL with your workforce and ask them to use this dual-stack URL to connect over IPv6. As an example, if your workforce uses the access portal to access AWS accounts, they will need to sign in through the new dual-stack access portal URL when using IPv6 connectivity. Alternately, if your workforce accesses the application URL, you need to enable the dual-stack application URL following application-specific instructions. For more information, see AWS services that support IPv6.

            The URLs that administrators use to manage IAM Identity Center are the second kind of URL your organization needs. The new dual-stack service endpoints end in api.aws as their TLD and are listed in the Identity Center service endpoints. Administrators can use these service endpoints to manage users and groups in Identity Center, update their access to applications and resources, and perform other management operations. As an example, if your administrator uses identitystore.{region}.amazonaws.com to manage users and groups in Identity Center, they should now use the dual-stack version of the same service endpoint which is identitystore.{region}.api.aws, so they can connect to service endpoints using IPv6 clients and networks.

            If your users or administrators use an AWS SDK to access AWS applications and accounts or manage services, follow Dual-stack and FIPS endpoints to enable connectivity to the dual-stack endpoints.

            After completing these two steps, your workforce and administrators can connect to IAM Identity Center using IPv6. Remember, these endpoints also support IPv4, so clients not yet IPv6-capable can continue to connect using IPv4.

            Monitoring dual-stack endpoint usage

            You can optionally monitor AWS CloudTrail logs to track usage of dual-stack endpoints. The key difference between IPv4-only and dual-stack endpoint usage is the TLD and appears in the clientProvidedHostHeader field. The following example shows the difference between these CloudTrail events for the CreateTokenWithIAM API call.

            IPv4-only endpoints Dual-stack endpoints
            "CloudTrailEvent": {
              "eventName": "CreateToken",
              "tlsDetails": {
                 "tlsVersion": "TLSv1.3",
                 "cipherSuite": "TLS_AES_128_GCM_SHA256",
                 "clientProvidedHostHeader": "oidc.us-east-1.amazonaws.com"
              }
            }

            "CloudTrailEvent": {
              "eventName": "CreateToken",
              "tlsDetails": {
                 "tlsVersion": "TLSv1.3",
                 "cipherSuite": "TLS_AES_128_GCM_SHA256",
                 "clientProvidedHostHeader": "oidc.us-east-1.api.aws"
              }
            }

            Conclusion

            IAM Identity Center now allows clients to connect over IPv6 natively with no network address translation infrastructure. This post showed you how to transition your organization to use IPv6 with Identity Center and its integrated applications. Remember that existing IPv4 endpoints will continue to function, so you can transition at your own pace. Also, no immediate action is required by you. However, we recommend planning your transition to take advantage of IPv6 benefits and meet compliance requirements. If you have questions, comments, or concerns, contact AWS Support, or start a new thread in the IAM Identity Center re:Post channel.

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

            Suchintya Dandapat
            Suchintya Dandapat

            Suchintya Dandapat is a Principal Product Manager for AWS where he partners with enterprise customers to solve their toughest identity challenges, enabling secure operations at global scale.

            Updated PCI PIN compliance package for AWS CloudHSM now available

            Post Syndicated from Tushar Jain original https://aws.amazon.com/blogs/security/updated-pci-pin-compliance-package-for-aws-cloudhsm-now-available/

            Amazon Web Services (AWS) is pleased to announce the successful completion of Payment Card Industry Personal Identification Number (PCI PIN) audit for the AWS CloudHSM service.

            With CloudHSM, you can manage and access your keys on FIPS 140-3 Level 3 validated hardware, protected with customer-owned, single-tenant hardware security module (HSM) instances that run in your own virtual private cloud (VPC). This PCI PIN attestation gives you the flexibility to deploy your regulated workloads with reduced compliance overhead. CloudHSM might be suitable when operations supported by the service are integrated into a broader solution that requires PCI-PIN compliance. For payment operations, such as PIN translation, we encourage you to consider AWS Payment Cryptography as a fully managed alternative for PCI-PIN compliance.

            The PCI PIN compliance report package for AWS CloudHSM includes two key components:

            • PCI PIN Attestation of Compliance (AOC) – demonstrating that AWS CloudHSM 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

            AWS was evaluated by Coalfire, a third-party Qualified Security Assessor (QSA). Customers can access the PCI PIN Attestation of Compliance (AOC) and PCI PIN Responsibility Summary reports through AWS Artifact.

            To learn more about our PCI program and other compliance and security programs, see the AWS Compliance Programs page. 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. If you have questions about this post, contact AWS Support.

            Tushar Jain

            Tushar Jain

            Tushar is a Compliance Program Manager at AWS. He leads multiple security and privacy initiatives within AWS. 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 CCSK and CSXF certifications.

            Will Black

            Will Black

            Will is a Compliance Program Manager at Amazon Web Services. He leads multiple security and compliance initiatives within AWS. He has ten years of experience in compliance and security assurance and holds a degree in Management Information Systems from Temple University. Additionally, he holds the CCSK and ISO 27001 Lead Implementer certifications.