All posts by Sébastien Stormacq

Opening the AWS European Sovereign Cloud

2026-01-15 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud/

Deutsch | English | Español | Français | Italiano

As a European citizen, I understand first-hand the importance of digital sovereignty, especially for our public sector organisations and highly regulated industries. Today, I’m delighted to share that the AWS European Sovereign Cloud is now generally available to all customers. We first announced our plans to build this new independent cloud infrastructure in 2023, and today it’s ready to meet the most stringent sovereignty requirements of European customers with a comprehensive set of AWS services.

Berlin, Brandenburg Gate at sunset

Meeting European sovereignty requirements
Organizations across Europe face increasingly complex regulatory requirements around data residency, operational control, and governance independence. Too often today, European organisations with the highest sovereignty requirements are stuck in legacy on-premises environments or offerings with reduced services and functionality. In response to this critical need, the AWS European Sovereign Cloud is the only fully featured and independently operated sovereign cloud backed by strong technical controls, sovereign assurances, and legal protections. Public sector entities and businesses in highly regulated industries need cloud infrastructure that provides enhanced sovereignty controls that maintain the innovation, security, and reliability they expect from modern cloud services. These organisations require assurance that their data and operations remain under European jurisdiction, with clear governance structures and operational autonomy within the European Union (EU).

A new independent cloud infrastructure for Europe
The AWS European Sovereign Cloud represents a physically and logically separate cloud infrastructure, with all components located entirely within the EU. The first AWS Region in the AWS European Sovereign Cloud is located in the state of Brandenburg, Germany, and is generally available today. This Region operates independently from existing AWS Regions. The infrastructure features multiple Availability Zones with redundant power and networking, designed to operate continuously even if connectivity with the rest of the world is interrupted.

We plan to extend the AWS European Sovereign Cloud footprint from Germany across the EU to support stringent isolation, in-country data residency, and low latency requirements. This will start with new sovereign Local Zones located in Belgium, the Netherlands, and Portugal. In addition, you will be able to extend the AWS European Sovereign Cloud infrastructure with AWS Dedicated Local Zones, AWS AI Factories, or AWS Outposts in locations you select, including your own on-premises data centres.

The AWS European Sovereign Cloud and its Local Zones provide enhanced sovereign controls through its unique operational model. The AWS European Sovereign Cloud will be operated exclusively by EU residents located in the EU. This covers activities such as day-to-day operations, technical support, and customer service. We’re gradually transitioning the AWS European Sovereign Cloud to be operated exclusively by EU citizens located in the EU. During this transition period, we will continue to work with a blended team of EU residents and EU citizens located in the EU.

The infrastructure is managed through dedicated European legal entities established under German law. In October 2025, AWS appointed Stéphane Israël, an EU citizen residing in the EU, as managing director. Stéphane will be responsible for the management and operations of the AWS European Sovereign Cloud, including infrastructure, technology, and services, as well as leading AWS broader digital sovereignty efforts. In January 2026, AWS also appointed Stefan Hoechbauer (Vice President, Germany and Central Europe, AWS) as a managing director of the AWS European Sovereign Cloud. He will work alongside Stéphane Israel to lead the AWS European Sovereign Cloud.

An advisory board comprised exclusively of EU citizens, and including two independent third-party representatives, provides additional oversight and expertise on sovereignty matters.

Enhanced data residency and control
The AWS European Sovereign Cloud provides comprehensive data residency assurances so you can meet the most stringent data residency requirements. As with our existing AWS Regions around the world, all your content remains within the Region you select unless you choose otherwise. Beyond content, customer-created metadata including roles, permissions, resource labels, and configurations also stays within the EU. The infrastructure features its own dedicated AWS Identity and Access Management (IAM) and billing system, all operating independently within European borders.

Technical controls built into the infrastructure prevent access to the AWS European Sovereign Cloud from outside the EU. The infrastructure includes a dedicated European trust service provider for certificate authority operations and uses dedicated Amazon Route 53 name servers. These servers will only use European Top-Level Domains (TLDs) for their own names. The AWS European Sovereign Cloud has no critical dependencies on non-EU personnel or infrastructure.

Security and compliance framework
The AWS European Sovereign Cloud maintains the same core security capabilities you expect from AWS, including encryption, key management, access governance, and the AWS Nitro System for compute isolation. This means your EC2 instances benefit from cryptographically verified platform integrity and hardware-enforced boundaries that prevent unauthorized access to your data without compromising on performance, giving you both the sovereignty controls and the computational power your workloads require. The infrastructure undergoes independent third-party audits, with compliance programs including ISO/IEC 27001:2013, SOC 1/2/3 reports, and Federal Office for Information Security (BSI) C5 attestation.

The AWS European Sovereign Cloud: Sovereign Reference Framework defines the specific sovereignty controls across governance independence, operational control, data residency, and technical isolation. This framework is available in AWS Artifact and provides end-to-end visibility through SOC 2 attestation.

Comprehensive service availability
You can access a broad range of AWS services in the AWS European Sovereign Cloud from launch, including Amazon SageMaker and Amazon Bedrock for artificial intelligence and machine learning (AI/ML) workloads. For compute, you can use Amazon Elastic Compute Cloud (Amazon EC2) and AWS Lambda. Container orchestration is available through Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Elastic Container Service (Amazon ECS). Database services include Amazon Aurora, Amazon DynamoDB, and Amazon Relational Database Service (Amazon RDS). Storage options include Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Block Store (Amazon EBS), with networking through Amazon Virtual Private Cloud (Amazon VPC) and security services including AWS Key Management Service (AWS KMS) and AWS Private Certificate Authority. For an up-to-date list of services, refer to the AWS Capabilities matrix recently published on the AWS Builder Center.

The AWS European Sovereign Cloud is supported by AWS Partners who are committed to helping you meet your sovereignty requirements. Partners including Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro, and Wiz are making their solutions available in the AWS European Sovereign Cloud, providing you with the tools and services you need across security, data analytics, application development, and industry-specific workloads. This broad partner support helps you build sovereign solutions that combine AWS services with trusted partner technologies.

Significant investment in European infrastructure
The AWS European Sovereign Cloud is backed by a €7.8 billion investment in infrastructure, jobs creation, and skills development. This investment is expected to contribute €17.2 billion to the European economy through 2040 and support roughly 2,800 full-time equivalent jobs annually in local businesses.

Some technical details
The AWS European Sovereign Cloud is available to all customers, regardless of where they are located. You can access the infrastructure using the partition name aws-eusc and the Region name eusc-de-east-1. A partition is a group of AWS Regions. Each AWS account is scoped to one partition.

The infrastructure supports all standard AWS access methods including the AWS Management Console, AWS SDKs, and the AWS Command Line Interface (AWS CLI), making it straightforward to integrate into your existing workflows and automation. After having created a new root account for the AWS European Sovereign Cloud partition, you start by creating new IAM identities and roles specific to this infrastructure, giving you complete control over access management within the European sovereign environment.

Getting started
The AWS European Sovereign Cloud provides European organisations with enhanced sovereignty controls whilst maintaining access to AWS innovation and capabilities. You can contract for services through Amazon Web Services EMEA SARL, with pricing in EUR and billing in any of the eight currencies we support today. The infrastructure uses familiar AWS architecture, service portfolio, and APIs, making it straightforward to build and migrate applications.

The AWS European Sovereign Cloud addendum contains the additional contractual commitments for the AWS European Sovereign Cloud.

For me as a European, this launch represents the AWS commitment to meeting the specific needs of our continent and providing the cloud capabilities that drive innovation across industries. I invite you to find out more about the AWS European Sovereign Cloud and how it can help your organisation meet its sovereignty requirements. Read Overview of the AWS European Sovereign Cloud to learn more about the design goals and approach, sign up for a new account, and plan for the deployment of your first workload today.

— seb

German version

Start der AWS European Sovereign Cloud

Als Bürger Europas weiß ich aus eigener Erfahrung, wie wichtig digitale Souveränität ist, insbesondere für unsere öffentlichen Einrichtungen und stark regulierten Branchen. Ich freue mich, Ihnen heute mitteilen zu können, dass die AWS European Sovereign Cloud nun für alle Kunden allgemein verfügbar ist. Wir haben unsere Pläne zum Aufbau dieser neuen unabhängigen Cloud-Infrastruktur erstmals im Jahr 2023 vorgestellt. Heute ist diese Infrastruktur bereit, mit einem umfassenden Angebot an AWS-Services die strengsten Souveränitätsanforderungen europäischer Kunden zu erfüllen.

Berlin, Brandenburger Tor bei Sonnenuntergang

Erfüllung europäischer Souveränitätsanforderungen
Organisationen in ganz Europa sehen sich mit zunehmend komplexen regulatorischen Anforderungen in Bezug auf Datenresidenz, operative Kontrolle und Unabhängigkeit der Governance konfrontiert. Europäische Organisationen mit höchsten Souveränitätsanforderungen sind heutzutage allzu oft in veralteten lokalen Umgebungen oder Angeboten mit eingeschränkten Services und Funktionen gefangen. Die AWS European Sovereign Cloud ist die Antwort auf diesen dringenden Bedarf. Sie ist die einzige unabhängig betriebene souveräne Cloud mit vollem Funktionsumfang, die durch strenge technische Kontrollen, Souveränitätszusicherungen und rechtlichen Schutz abgesichert ist. Einrichtungen des öffentlichen Sektors und Unternehmen in stark regulierten Branchen benötigen eine Cloud-Infrastruktur, die erweiterte Souveränitätskontrollen bietet und gleichzeitig die von modernen Cloud-Services erwartete Innovation, Sicherheit und Zuverlässigkeit gewährleistet. Diese Organisationen benötigen die Zusicherung, dass ihre Daten und Aktivitäten unter europäischer Zuständigkeit bleiben, mit klaren Governance-Strukturen und operativer Autonomie innerhalb der Europäischen Union (EU).

Eine neue unabhängige Cloud-Infrastruktur für Europa
Die AWS European Sovereign Cloud ist eine physisch und logisch getrennte Cloud-Infrastruktur, deren Komponenten sich vollständig innerhalb der EU befinden. Die erste AWS-Region in der AWS European Sovereign Cloud befindet sich im deutschen Bundesland Brandenburg und ist ab heute allgemein verfügbar. Diese Region arbeitet unabhängig von bestehenden AWS-Regionen. Die Infrastruktur umfasst mehrere Availability Zones mit redundanter Stromversorgung und Netzwerkverbindung, die auch bei einer Unterbrechung der Verbindung zum Rest der Welt einen kontinuierlichen Betrieb gewährleisten.

Wir beabsichtigen, die Präsenz der AWS European Sovereign Cloud von Deutschland aus EU-weit auszuweiten, um strenge Anforderungen hinsichtlich Isolierung, Datenresidenz innerhalb einzelner Länder und geringer Latenz zu erfüllen. Dies beginnt mit neuen souveränen Local Zones in Belgien, den Niederlanden und Portugal. Darüber hinaus können Sie die Infrastruktur der AWS European Sovereign Cloud mit dedizierten AWS Local Zones, AWS AI Factories oder AWS Outposts an Standorten Ihrer Wahl, einschließlich Ihrer eigenen lokalen Rechenzentren, erweitern.

Dank ihres einzigartigen Betriebsmodells bieten die AWS European Sovereign Cloud und ihre Local Zones erweiterte Souveränitätskontrollen. Der Betrieb der AWS European Sovereign Cloud wird ausschließlich von EU-Bürgern mit Wohnsitz in der EU sichergestellt. Dies umfasst Aktivitäten wie den täglichen Betrieb, den technischen Support und den Kundenservice. Wir stellen die AWS European Sovereign Cloud schrittweise so um, dass als Betriebspersonal ausschließlich EU-Bürger mit Wohnsitz in der EU zum Einsatz kommen. Während dieser Übergangsphase werden wir weiterhin mit einem gemischten Team aus in der EU ansässigen Personen und in der EU lebenden EU-Bürgern arbeiten.

Die Infrastruktur wird durch spezielle europäische juristische Personen nach deutschem Recht verwaltet. Im Oktober 2025 berief AWS Stéphane Israël, einen in der EU ansässigen EU-Bürger, zum Geschäftsführer. Stéphane wird für das Management und den Betrieb der AWS European Sovereign Cloud verantwortlich zeichnen. Dies umfasst die Bereiche Infrastruktur, Technologie und Services sowie die Federführung bei den breit angelegten Initiativen von AWS auf dem Gebiet der digitalen Souveränität. Im Januar 2026 ernannte AWS zudem Stefan Hoechbauer (Vice President, Germany and Central Europe, AWS) zum Geschäftsführer der AWS European Sovereign Cloud. Er wird gemeinsam mit Stéphane Israel die Leitung der AWS European Sovereign Cloud innehaben.

Ein Beirat, dem ausschließlich EU-Bürger, einschließlich zwei unabhängigen externen Vertretern, angehören, fungiert als zusätzliche Kontrollinstanz und bringt Fachwissen in Fragen der Souveränität ein.

Verbesserte Datenresidenz und -kontrolle
Die AWS European Sovereign Cloud bietet umfassende Garantien hinsichtlich der Datenresidenz, sodass Sie selbst die strengsten Anforderungen in diesem Bereich erfüllen können. Wie auch bei unseren bestehenden AWS-Regionen weltweit verbleiben alle Ihre Inhalte in der von Ihnen ausgewählten Region, sofern Sie keine anderen Einstellungen vornehmen. Neben den Inhalten verbleiben auch die vom Kunden erstellten Metadaten, einschließlich Rollen, Berechtigungen, Ressourcenbezeichnungen und Konfigurationen, innerhalb der EU. Die Infrastruktur verfügt über ein eigenes AWS Identity and Access Management (IAM) und ein eigenes Abrechnungssystem – beides wird innerhalb der europäischen Grenzen unabhängig betrieben.

In die Infrastruktur integrierte technische Kontrollen verhindern den Zugriff auf die AWS European Sovereign Cloud von außerhalb der EU. Die Infrastruktur umfasst einen dedizierten europäischen Trust Service Provider für Zertifizierungsstellen und nutzt dedizierte Amazon-Route-53-Namenserver. Diese Server verwenden ausschließlich europäische Top-Level-Domains (TLDs) für ihre eigenen Namen. Die AWS European Sovereign Cloud unterliegt keinen kritischen Abhängigkeiten hinsichtlich Personal oder Infrastruktur außerhalb der EU.

Sicherheits- und Compliance-Framework
Die AWS European Sovereign Cloud bietet dieselben zentralen Sicherheitsfunktionen, die Sie von AWS erwarten. Dazu gehören Verschlüsselung, Schlüsselverwaltung, Zugriffskontrolle und das AWS Nitro System für die Isolierung von Rechenressourcen. Dies bedeutet, dass Ihre EC2-Instanzen von einer kryptografisch verifizierten Plattformintegrität und hardwaregestützten Grenzen profitieren, die unbefugten Zugriff auf Ihre Daten verhindern, ohne die Leistung zu beeinträchtigen. So erhalten Sie sowohl die Souveränitätskontrollen als auch die Rechenleistung, die Ihre Workloads erfordern. Die Infrastruktur wird unabhängigen Audits durch Dritte unterzogen. Die Compliance-Programme umfassen ISO/IEC 27001:2013, SOC-1/2/3-Berichte und das C5-Zertifikat des Bundesamtes für Sicherheit in der Informationstechnik (BSI).

Das AWS European Sovereign Cloud: Sovereign Reference Framework definiert spezifische Souveränitätskontrollen in den Bereichen Governance-Unabhängigkeit, operative Kontrolle, Datenresidenz und technische Isolierung. Dieses Framework ist in AWS Artifact verfügbar und bietet durch SOC-2-Zertifizierung durchgängige Transparenz.

Umfassende Serviceverfügbarkeit
Von Beginn an steht Ihnen in der AWS European Sovereign Cloud eine breite Palette von AWS-Services zur Verfügung – darunter Amazon SageMaker und Amazon Bedrock für Workloads im Bereich Künstliche Intelligenz und Machine Learning (KI/ML). Für die Rechenleistung stehen Ihnen Amazon Elastic Compute Cloud (Amazon EC2) und AWS Lambda zur Verfügung. Die Container-Orchestrierung ist über den Amazon Elastic Kubernetes Service (Amazon EKS) und den Amazon Elastic Container Service (Amazon ECS) verfügbar. Zu den Datenbank-Services gehören Amazon Aurora, Amazon DynamoDB und Amazon Relational Database Service (Amazon RDS). Die Speicheroptionen umfassen Amazon Simple Storage Service (Amazon S3) und Amazon Elastic Block Store (Amazon EBS) mit Vernetzung über Amazon Virtual Private Cloud (Amazon VPC) und Sicherheits-Services wie AWS Key Management Service (AWS KMS) und AWS Private Certificate Authority. Eine aktuelle Liste der Services finden Sie in der AWS-Funktionsmatrix, die kürzlich im AWS Builder Center veröffentlicht wurde.

Die AWS European Sovereign Cloud wird von AWS-Partnern unterstützt, die es sich zur Aufgabe gemacht haben, Ihnen bei der Erfüllung Ihrer Souveränitätsanforderungen zur Seite zu stehen. Partner wie Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro und Wiz stellen ihre Lösungen in der AWS European Sovereign Cloud zur Verfügung und bieten Ihnen die Tools und Services, die Sie in den Bereichen Sicherheit, Datenanalyse, Entwicklung von Anwendungen und branchenspezifische Workloads benötigen. Dank dieser umfassenden Unterstützung durch Partner können Sie eigenständige Lösungen, die AWS-Services mit bewährten Partnertechnologien kombinieren, entwickeln.

Erhebliche Investitionen in die europäische Infrastruktur
Hinter der AWS European Sovereign Cloud steht eine Investition in Höhe von 7,8 Milliarden Euro in Infrastruktur, die Schaffung von Arbeitsplätzen und die Entwicklung von Kompetenzen. Diese Investition wird bis 2040 voraussichtlich 17,2 Milliarden Euro zur europäischen Wirtschaftsleistung beitragen und jährlich rund 2 800 Vollzeitstellen in lokalen Unternehmen sichern.

Einige technische Details
Die AWS European Sovereign Cloud steht allen Kunden zur Verfügung, unabhängig davon, wo sie sich befinden. Sie können mit dem Partitionsnamen aws-eusc und dem Regionsnamen eusc-de-east-1 auf die Infrastruktur zugreifen. Eine Partition ist eine Gruppe von AWS-Regionen. Jedes AWS-Konto ist auf eine Partition beschränkt.

Die Infrastruktur unterstützt alle gängigen AWS-Zugriffsmethoden, einschließlich der AWS Management Console, AWS SDKs und der AWS Command Line Interface (AWS CLI), sodass sie sich problemlos in Ihre bestehenden Workflows und Automatisierungsprozesse integrieren lässt. Nachdem Sie ein neues Root-Konto für die Partition der AWS European Sovereign Cloud erstellt haben, beginnen Sie mit der Erstellung neuer IAM-Identitäten und -Rollen, die speziell für diese Infrastruktur vorgesehen sind. Dadurch erhalten Sie die vollständige Kontrolle über die Zugriffsverwaltung innerhalb der europäischen souveränen Umgebung.

Erste Schritte
Die AWS European Sovereign Cloud bietet europäischen Organisationen erweiterte Souveränitätskontrollen und gewährleistet gleichzeitig den Zugriff auf die Innovationen und Funktionen von AWS. Sie können Services über Amazon Web Services EMEA SARL in Auftrag geben. Die Preise werden in Euro angegeben und die Abrechnung erfolgt in einer der acht Währungen, die wir derzeit unterstützen. Die Infrastruktur basiert auf der bekannten AWS-Architektur, dem AWS-Serviceportfolio und den AWS-APIs, wodurch die Entwicklung und Migration von Anwendungen vereinfacht wird.

Der AWS European Sovereign Cloud Addendum enthält die zusätzlichen vertraglichen Verpflichtungen für die AWS European Sovereign Cloud.

Für mich als Europäer symbolisiert dieser Launch das Engagement von AWS, den spezifischen Anforderungen unseres Kontinents gerecht zu werden und Cloud-Funktionen bereitzustellen, die Innovationen in allen Branchen vorantreiben. Ich lade Sie ein, mehr über die AWS European Sovereign Cloud zu erfahren und zu entdecken, wie sie Ihrer Organisation dabei helfen kann, ihre Souveränitätsanforderungen zu erfüllen. Lesen Sie die Übersicht über die AWS European Sovereign Cloud und erfahren Sie mehr über die Designziele und den Ansatz. Registrieren Sie sich für ein neues Konto und planen Sie noch heute die Bereitstellung Ihrer ersten Workload.

— seb

French version

Ouverture de l’AWS European Souvereign Cloud

En tant que citoyen européen, je mesure personnellement l’importance de la souveraineté numérique, en particulier pour nos organisations du secteur public et les industries fortement réglementées. Aujourd’hui, j’ai le plaisir d’annoncer que l’AWS European Sovereign Cloud est désormais disponible pour l’ensemble de nos clients. Nous avions annoncé pour la première fois notre projet de construction de cette nouvelle infrastructure cloud indépendante en 2023, et elle est aujourd’hui prête à répondre aux exigences de souveraineté les plus strictes des clients européens, avec un large ensemble de services AWS.

Berlin, porte de Brandebourg au coucher du soleil

Répondre aux exigences européennes en matière de souveraineté
Partout en Europe, les organisations sont confrontées à des exigences réglementaires de plus en plus complexes en matière de résidence des données, de contrôle opérationnel et d’indépendance de la gouvernance. Trop souvent aujourd’hui, les organisations européennes ayant les besoins de souveraineté les plus élevés se retrouvent contraintes de rester sur des environnements sur site, ou de recourir à des offres cloud aux services et fonctionnalités limités. Pour répondre à cet enjeu critique, l’AWS European Sovereign Cloud est le seul cloud souverain entièrement fonctionnel, exploité de manière indépendante, et reposant sur des contrôles techniques robustes, des garanties de souveraineté et des protections juridiques solides. Les acteurs du secteur public et les entreprises des secteurs fortement réglementés ont besoin d’une infrastructure cloud offrant des contrôles de souveraineté renforcés, sans renoncer à l’innovation, à la sécurité et à la fiabilité attendues des services cloud modernes. Ces organisations doivent avoir l’assurance que leurs données et leurs opérations restent sous juridiction européenne, avec des structures de gouvernance claires et une autonomie opérationnelle au sein de l’Union européenne (UE).

Une nouvelle infrastructure cloud indépendante pour l’Europe
L’AWS European Sovereign Cloud repose sur une infrastructure cloud physiquement et logiquement distincte, dont l’ensemble des composants est situé exclusivement au sein de l’UE. La première région AWS de l’AWS European Sovereign Cloud est implantée dans le Land de Brandebourg, en Allemagne, et est disponible dès aujourd’hui. Cette région fonctionne de façon indépendante par rapport aux autres régions AWS existantes. L’infrastructure comprend plusieurs zones de disponibilité, avec des systèmes redondants d’alimentation et de réseau, conçus pour fonctionner en continu même en cas d’interruption de la connectivité avec le reste du monde.

Nous prévoyons d’étendre l’empreinte de l’AWS European Sovereign Cloud depuis l’Allemagne à l’ensemble de l’UE, afin de répondre aux exigences strictes d’isolation, de résidence des données dans certains pays et de faible latence. Cette extension débutera avec de nouvelles Local Zones souveraines situées en Belgique, aux Pays-Bas et au Portugal. En complément, vous pourrez étendre l’infrastructure de l’AWS European Sovereign Cloud à l’aide des AWS Dedicated Local Zones, des AWS AI Factories ou d’AWS Outposts, dans les sites de votre choix, y compris au sein de vos propres centres de données sur site.

L’AWS European Sovereign Cloud et ses Local Zones offrent des contrôles de souveraineté renforcés grâce à un modèle opérationnel unique. L’AWS European Sovereign Cloud est exploité exclusivement par des résidents de l’UE basés dans l’UE. Cela couvre notamment les opérations quotidiennes, le support technique et le service client. Nous sommes en train d’opérer une transition progressive afin que l’AWS European Sovereign Cloud soit exploité exclusivement par des citoyens de l’UE résidant dans l’UE. Durant cette période de transition, nous continuons de travailler avec une équipe mixte composée de résidents de l’UE et de citoyens de l’UE basés dans l’UE.

L’infrastructure est gérée par des entités juridiques européennes dédiées, établies conformément au droit allemand. En octobre 2025, AWS a nommé Stéphane Israël, citoyen de l’UE résidant dans l’UE, au poste de directeur général. Stéphane est responsable de la gestion et de l’exploitation de l’AWS European Sovereign Cloud, couvrant l’infrastructure, la technologie et les services, ainsi que de la direction des initiatives plus larges d’AWS en matière de souveraineté numérique. En janvier 2026, AWS a également nommé Stefan Hoechbauer (Vice-président, Allemagne et Europe centrale, AWS) comme directeur général de l’AWS European Sovereign Cloud. Il travaillera aux côtés de Stéphane Israël pour piloter l’AWS European Sovereign Cloud.

Un conseil consultatif, composé exclusivement de citoyens de l’UE et incluant deux représentants indépendants, apporte un niveau supplémentaire de supervision et d’expertise sur les questions de souveraineté.

Résidence des données et contrôle renforcés
L’AWS European Sovereign Cloud fournit des garanties complètes en matière de résidence des données afin de répondre aux exigences les plus strictes. Comme dans les régions AWS existantes à travers le monde, l’ensemble de vos contenus reste dans la région que vous sélectionnez, sauf indication contraire de votre part. Au-delà des contenus, les métadonnées créées par les clients — telles que les rôles, les autorisations, les étiquettes de ressources et les configurations — restent également au sein de l’UE. L’infrastructure dispose de son propre système dédié de AWS Identity and Access Management (IAM) et de facturation, opérant de manière totalement indépendante à l’intérieur des frontières européennes.

Des contrôles techniques intégrés à l’infrastructure empêchent tout accès à l’AWS European Sovereign Cloud depuis l’extérieur de l’UE. L’infrastructure comprend un prestataire européen de services de confiance dédié pour les opérations d’autorité de certification et utilise des serveurs de noms Amazon Route 53 dédiés. Ces serveurs n’utilisent que des domaines de premier niveau (TLD) européens pour leurs propres noms. L’AWS European Sovereign Cloud ne présente aucune dépendance critique vis-à-vis de personnels ou d’infrastructures situés en dehors de l’UE.

Cadre de sécurité et de conformité
L’AWS European Sovereign Cloud conserve les capacités de sécurité fondamentales attendues d’AWS, notamment le chiffrement, la gestion des clés, la gouvernance des accès et le système AWS Nitro pour l’isolation des charges de calcul. Concrètement, vos instances EC2 bénéficient d’une intégrité de plateforme vérifiée cryptographiquement et de frontières matérielles, empêchant tout accès non autorisé à vos données sans compromis sur les performances. Vous bénéficiez ainsi à la fois des contrôles de souveraineté et de la puissance de calcul nécessaires à vos charges de travail. L’infrastructure fait l’objet d’audits indépendants réalisés par des tiers, et s’inscrit dans des programmes de conformité incluant ISO/IEC 27001:2013, les rapports SOC 1/2/3, ainsi que l’attestation C5 de l’Office fédéral allemand pour la sécurité de l’information (BSI).

Le AWS European Sovereign Cloud: Sovereign Reference Framework définit précisément les contrôles de souveraineté couvrant l’indépendance de la gouvernance, le contrôle opérationnel, la résidence des données et l’isolation technique. Ce cadre est disponible dans AWS Artifact et offre une visibilité de bout en bout via une attestation SOC 2.

Disponibilité étendue des services
Dès son lancement, l’AWS European Sovereign Cloud donne accès à un large éventail de services AWS, notamment Amazon SageMaker et Amazon Bedrock pour les charges de travail d’intelligence artificielle et de machine learning (IA/ML). Pour le calcul, vous pouvez utiliser Amazon Elastic Compute Cloud (Amazon EC2) et AWS Lambda. L’orchestration de conteneurs est disponible via Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon Elastic Container Service (Amazon ECS). Les services de bases de données incluent Amazon Aurora, Amazon DynamoDB et Amazon Relational Database Service (Amazon RDS). Les options de stockage comprennent Amazon Simple Storage Service (Amazon S3) et Amazon Elastic Block Store (Amazon EBS), avec des capacités réseau via Amazon Virtual Private Cloud (Amazon VPC) et des services de sécurité tels que AWS Key Management Service (AWS KMS) et AWS Private Certificate Authority. Pour obtenir la liste la plus à jour des services disponibles, consultez la matrice des capacités AWS récemment publiée sur l’AWS Builder Center.

L’AWS European Sovereign Cloud est supporté par de nombreux partenaires AWS engagés à vous aider à répondre à vos exigences de souveraineté. Des partenaires tels qu’Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro et Wiz rendent leurs solutions disponibles sur l’AWS European Sovereign Cloud, vous offrant ainsi les outils et services nécessaires dans les domaines de la sécurité, de l’analyse de données, du développement applicatif et des charges de travail spécifiques à certains secteurs industriels. Cet ensemble de partenaires vous permet de construire des solutions souveraines combinant les services AWS et des technologies de partenaires de confiance.

Un investissement majeur dans l’infrastructure européenne
L’AWS European Sovereign Cloud s’appuie sur un investissement de 7,8 milliards d’euros dans l’infrastructure, la création d’emplois et le développement des compétences. Cet investissement devrait contribuer à hauteur de 17,2 milliards d’euros à l’économie européenne d’ici 2040 et soutenir environ 2.800 emplois équivalent temps plein par an au sein des entreprises locales.

Quelques détails techniques
L’AWS European Sovereign Cloud est accessible à tous les clients, quel que soit leur lieu d’implantation. Vous pouvez accéder à l’infrastructure en utilisant le nom de partition aws-eusc et le nom de région eusc-de-east-1. Une partition correspond à un ensemble de régions AWS. Chaque compte AWS est rattaché à une seule partition.

L’infrastructure prend en charge toutes les méthodes d’accès AWS standards, y compris la console de gestion AWS, les AWS SDKs et la AWS Command Line Interface (AWS CLI), ce qui facilite son intégration dans vos flux de travail et vos automatisations existants. Après avoir créé un nouveau compte racine pour la partition AWS European Sovereign Cloud, vous commencez par définir de nouvelles identités et rôles IAM spécifiques à cette infrastructure, vous donnant un contrôle total sur la gestion des accès au sein de l’environnement souverain européen.

Pour commencer
L’AWS European Sovereign Cloud offre aux organisations européennes des contrôles de souveraineté renforcés tout en leur permettant de continuer à bénéficier de l’innovation et des capacités d’AWS. Vous pouvez contractualiser les services via Amazon Web Services EMEA SARL, avec une tarification en euros et une facturation possible dans l’une des huit devises que nous prenons en charge aujourd’hui. L’infrastructure repose sur une architecture, un portefeuille de services et des API AWS familiers, ce qui simplifie le développement et la migration des applications.

L’avenant AWS European Sovereign Cloud précise les engagements contractuels supplémentaires propres à l’AWS European Sovereign Cloud.

En tant qu’Européen, ce lancement illustre l’engagement d’AWS à répondre aux besoins spécifiques de notre continent et à fournir les capacités cloud qui stimulent l’innovation dans tous les secteurs. Je vous invite à découvrir l’AWS European Sovereign Cloud et à comprendre comment il peut aider votre organisation à satisfaire ses exigences de souveraineté. Consultez Overview of the AWS European Sovereign Cloud (en anglais) pour en savoir plus sur les objectifs de conception et l’approche retenue, créez un nouveau compte et planifiez dès aujourd’hui le déploiement de votre première charge de travail.

— seb

Italian version

Lancio di AWS European Sovereign Cloud

Come cittadino europeo, conosco benissimo l’importanza della sovranità digitale, in particolare per le nostre organizzazioni del settore pubblico e dei settori altamente regolamentati. Oggi sono lieto di annunciare che AWS European Sovereign Cloud è ora generalmente disponibile per tutti i clienti. Abbiamo annunciato per la prima volta i nostri piani per la creazione di questa nuova infrastruttura cloud indipendente nel 2023. Finalmente oggi è pronta a soddisfare i più rigorosi requisiti di sovranità dei clienti europei con un set completo di servizi AWS.

Berlino, Porta di Brandeburgo al tramonto

Soddisfare i requisiti di sovranità europea
Le organizzazioni di tutta Europa devono far fronte a requisiti normativi sempre più complessi in materia di residenza dei dati, controllo operativo e indipendenza della governance. Troppo spesso, le organizzazioni europee con i più elevati requisiti di sovranità sono bloccate a causa di offerte o ambienti on-premises legacy con funzionalità e servizi ridotti. In risposta a questa esigenza fondamentale, l’AWS European Sovereign Cloud rappresenta l’unico cloud sovrano con funzionalità complete e a gestione autonoma. supportato da solidi controlli tecnici, garanzie di sovranità e protezioni legali. Gli enti pubblici e le aziende di settori altamente regolamentati necessitano di un’infrastruttura cloud che fornisca controlli di sovranità avanzati che garantiscano l’innovazione, la sicurezza e l’affidabilità che si aspettano dai moderni servizi cloud. Queste organizzazioni devono essere certe che i propri dati e le proprie operazioni restino sotto la giurisdizione europea, con chiare strutture di governance e autonomia operativa nell’ambito dell’Unione europea (UE).

Una nuova infrastruttura cloud indipendente per l’Europa
L’AWS European Sovereign Cloud rappresenta un’infrastruttura cloud separata fisicamente e logicamente, con tutti i componenti situati interamente all’interno dell’UE. La prima Regione AWS nell’AWS European Sovereign Cloud, situata nello stato di Brandeburgo (Germania) e ora disponibile a livello generale, opera indipendentemente dalle Regioni AWS esistenti. L’infrastruttura presenta diverse zone di disponibilità con risorse di alimentazione e rete ridondanti, progettate per funzionare continuamente anche in caso di interruzione della connettività con il resto del mondo.

Abbiamo intenzione di estendere la presenza dell’AWS European Sovereign Cloud dalla Germania all’intera UE per supportare i rigorosi requisiti di isolamento, residenza dei dati all’interno di un determinato Paese e bassa latenza. Inizieremo con nuove zone locali sovrane situate in Belgio, nei Paesi Bassi e in Portogallo. Inoltre, sarà possibile estendere l’infrastruttura AWS European Sovereign Cloud con Zone locali AWS dedicate, AWS AI Factories o AWS Outposts in posizioni selezionate, inclusi i data center on-premises.

L’AWS European Sovereign Cloud e le relative zone locali forniscono controlli sovrani avanzati tramite un modello operativo esclusivo. L’AWS European Sovereign Cloud sarà gestito esclusivamente da residenti UE che si trovano nell’UE. Ciò copre attività come operazioni quotidiane, supporto tecnico e servizio clienti. Stiamo gradualmente trasformando l’AWS European Sovereign Cloud in modo che sia gestito esclusivamente da cittadini UE che si trovano nell’UE. Durante questo periodo di transizione, continueremo a lavorare con un team misto di residenti e cittadini comunitari che si trovano nell’UE.

L’infrastruttura è gestita da entità giuridiche europee dedicate, costituite secondo il diritto tedesco. Nell’ottobre 2025, AWS ha assegnato l’incarico di managing director a Stéphane Israël, cittadino comunitario residente nell’UE. Sarà responsabile della gestione e delle operazioni dell’AWS European Sovereign Cloud, inclusi infrastruttura, tecnologia e servizi, oltre a guidare le più ampie iniziative di sovranità digitale di AWS. Nel gennaio 2026, AWS ha inoltre nominato managing director dell’AWS European Sovereign Cloud Stefan Höchbauer (vicepresidente, Germania ed Europa centrale, AWS). Collaborerà con Stéphane Israël per guidare l’AWS European Sovereign Cloud.

Un comitato consultivo composto esclusivamente da cittadini comunitari, inclusi due rappresentanti terzi indipendenti, fornirà ulteriore supervisione e competenza in materia di sovranità.

Ottimizzazione del controllo e della residenza dei dati
L’AWS European Sovereign Cloud offre garanzie complete sulla residenza dei dati in modo da poter soddisfare i requisiti più rigorosi in materia. Come per le nostre Regioni AWS esistenti a livello mondiale, tutti i contenuti restano all’interno della Regione selezionata, a meno che non si scelga diversamente. Oltre ai contenuti, anche i metadati creati dai clienti, tra cui ruoli, autorizzazioni, etichette delle risorse e configurazioni, restano nell’ambito dell’UE. L’infrastruttura è dotata di un proprio sistema AWS Identity and Access Management (AWS IAM) e di fatturazione dedicato, completamente gestito in modo indipendente all’interno dei confini europei.

I controlli tecnici integrati nell’infrastruttura impediscono l’accesso all’AWS European Sovereign Cloud dall’esterno dell’UE. L’infrastruttura include un provider di servizi fiduciari europeo dedicato per le operazioni delle autorità di certificazione e utilizza nameserver Amazon Route 53 dedicati. Questi server utilizzeranno solo domini di primo livello (TLD) europei per i propri nomi. L’AWS European Sovereign Cloud non ha dipendenze fondamentali da personale o infrastrutture non UE.

Framework di sicurezza e conformità
L’AWS European Sovereign Cloud mantiene le stesse funzionalità di sicurezza di base di AWS, tra cui crittografia, gestione delle chiavi, governance degli accessi e AWS Nitro System per l’isolamento computazionale. Ciò significa che le istanze EC2 beneficiano dell’integrità della piattaforma verificata a livello di crittografia e dei limiti imposti dall’hardware che impediscono l’accesso non autorizzato ai dati senza compromettere le prestazioni, offrendo i controlli di sovranità e la potenza di calcolo richiesti dai carichi di lavoro. L’infrastruttura è sottoposta ad audit di terze parti indipendenti, con programmi di conformità che includono ISO/IEC 27001:2013, report SOC 1/2/3 e attestazione C5 dell’Ufficio Federale per la Sicurezza Informatica (BSI).

L’AWS European Sovereign Cloud: Sovereign Reference Framework definisce i controlli di sovranità specifici in termini di indipendenza della governance, controllo operativo, residenza dei dati e isolamento tecnico. Questo framework è disponibile in AWS Artifact e fornisce visibilità end-to-end tramite l’attestazione SOC 2.

Disponibilità completa del servizio
Dal momento del lancio, sarà possibile accedere a un’ampia gamma di servizi AWS nell’AWS European Sovereign Cloud, tra cui Amazon SageMaker e Amazon Bedrock per carichi di lavoro di intelligenza artificiale e machine learning (IA/ML). Per i calcoli, è possibile utilizzare Amazon Elastic Compute Cloud (Amazon EC2) e AWS Lambda. L’orchestrazione di container è disponibile tramite Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service (Amazon ECS). I servizi di database includono Amazon Aurora, Amazon DynamoDB e Amazon Relational Database Service (Amazon RDS). Le opzioni di storage includono Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Block Store (Amazon EBS), con connessione in rete tramite Amazon Virtual Private Cloud (Amazon VPC) e servizi di sicurezza tra cui Servizio AWS di gestione delle chiavi (AWS KMS) e Autorità di certificazione privata AWS (AWS Private CA). Per un elenco aggiornato dei servizi, è possibile consultare l’elenco delle funzionalità AWS pubblicato di recente su AWS Builder Center.

L’AWS European Sovereign Cloud è supportato dai partner AWS, che aiutano a soddisfare i propri requisiti di sovranità. Partner come Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro e Wiz stanno rendendo disponibili le loro soluzioni nell’AWS European Sovereign Cloud, fornendo gli strumenti e i servizi necessari per la sicurezza, l’analisi dei dati, lo sviluppo di applicazioni e i carichi di lavoro specifici del settore. Questo ampio supporto dei partner aiuta a creare soluzioni sovrane che combinano i servizi AWS con tecnologie di partner affidabili.

Investimenti significativi nelle infrastrutture europee
L’AWS European Sovereign Cloud è sostenuto da un investimento di 7,8 miliardi di euro destinati a infrastrutture, creazione di posti di lavoro e sviluppo delle competenze. Si prevede che questo investimento contribuirà con 17,2 miliardi di euro all’economia europea fino al 2040 e sosterrà circa 2.800 posti di lavoro equivalenti a tempo pieno all’anno nelle aziende locali.

Alcuni dettagli tecnici
L’AWS European Sovereign Cloud è disponibile per tutti i clienti, indipendentemente da dove si trovino. È possibile accedere all’infrastruttura utilizzando il nome della partizione aws-eusc e il nome della Regione eusc-de-east-1. Una partizione è un gruppo di Regioni AWS. Ogni account AWS è associato a una partizione.

L’infrastruttura supporta tutti i metodi di accesso AWS standard, tra cui la Console di gestione AWS, gli SDK AWS e l’interfaccia della linea di comando AWS (AWS CLI), semplificando l’integrazione nell’automazione e nei flussi di lavoro esistenti. Dopo aver creato un nuovo account root per la partizione Di AWS European Sovereign Cloud, si inizia creando nuove identità e ruoli IAM specifici per questa infrastruttura, che consentiranno di avere il controllo completo sulla gestione degli accessi all’interno dell’ambiente sovrano europeo.

Nozioni di base
L’AWS European Sovereign Cloud fornisce alle organizzazioni europee controlli di sovranità avanzati pur mantenendo l’accesso all’innovazione e alle funzionalità di AWS. È possibile contrattare servizi tramite Amazon Web Services EMEA SARL, con prezzi in EUR e fatturazione in una delle otto valute supportate oggi. L’infrastruttura utilizza l’architettura AWS, il portafoglio di servizi e le API tradizionali, semplificando la creazione e la migrazione delle applicazioni.

L’addendum di AWS European Sovereign Cloud include gli impegni contrattuali aggiuntivi per l’AWS European Sovereign Cloud.

Per me come europeo, questo lancio rappresenta l’impegno di AWS per soddisfare le esigenze specifiche del nostro continente e fornire le funzionalità cloud che guidano l’innovazione in tutti i settori. Invito tutti a scoprire di più sull’AWS European Sovereign Cloud e su come può aiutare le organizzazioni a soddisfare i requisiti di sovranità. Nella Panoramica di AWS European Sovereign Cloud sono disponibili maggiori informazioni sugli obiettivi e sull’approccio di progettazione, creare un nuovo account e pianificare l’implementazione del primo carico di lavoro oggi stesso.

— seb

Spanish version

Apertura de AWS European Sovereign Cloud

Como ciudadano europeo, comprendo de primera mano la importancia de la soberanía digital, especialmente para las organizaciones de nuestro sector público y las industrias altamente reguladas. Hoy me complace anunciar que la AWS European Sovereign Cloud ya está disponible de forma generalizada para todos los clientes. Anunciamos por primera vez nuestros planes de crear esta nueva infraestructura de nube independiente en 2023, y hoy está lista para cumplir los requisitos de soberanía más estrictos de los clientes europeos con un exhaustivo conjunto de servicios de AWS.

Berlín, Puerta de Brandeburgo al atardecer

Cumplimiento de los requisitos de soberanía europeos
Las organizaciones de toda Europa se enfrentan a unos requisitos normativos cada vez más complejos en relación con la residencia de los datos, el control operativo y la independencia de la gobernanza. Hoy en día, con demasiada frecuencia, las organizaciones europeas con los requisitos de soberanía más estrictos se ven atrapadas en entornos locales heredados u ofertas con servicios y funcionalidades reducidos. En respuesta a esta necesidad crítica, la AWS European Sovereign Cloud es la única nube soberana independiente con todas las características que está respaldada por sólidos controles técnicos, garantías de soberanía y protecciones legales. Las entidades del sector público y las empresas de industrias altamente reguladas necesitan una infraestructura en la nube que proporcione controles de soberanía mejorados que mantengan la innovación, la seguridad y la fiabilidad que se esperan de los servicios modernos en la nube. Estas organizaciones necesitan la garantía de que sus datos y operaciones permanecen bajo la jurisdicción europea, con estructuras de gobernanza claras y autonomía operativa dentro de la Unión Europea (UE).

Una nueva infraestructura de nube independiente para Europa
La AWS European Sovereign Cloud es una infraestructura de nube separada de manera física y lógica, en la que todos los componentes están ubicados íntegramente dentro de la UE. La primera región de AWS de la AWS European Sovereign Cloud se encuentra en el estado de Brandeburgo (Alemania) y ya está disponible para el público en general. Esta región opera de forma independiente de las regiones de AWS existentes. La infraestructura cuenta con varias zonas de disponibilidad con fuentes de alimenacion y redes redundantes, diseñadas para funcionar de forma continua incluso si se interrumpe la conectividad con el resto del mundo.

Tenemos previsto ampliar la presencia de la AWS European Sovereign Cloud de Alemania a toda la UE para cumplir los requisitos de aismlamiento estrictos, residencia de los datos dentro del país y baja latencia. Esto comenzará con nuevas zonas locales soberanas ubicadas en Bélgica, los Países Bajos y Portugal. Además, podrá ampliar la infraestructura de la AWS European Sovereign Cloud con zonas locales dedicadas de AWS, AWS AI Factories o AWS Outposts en las ubicaciones que elija, incluidos sus propios centros de datos locales.

La AWS European Sovereign Cloud y sus zonas locales proporcionan controles soberanos mejorados a través de su modelo operativo único. La AWS European Sovereign Cloud será operada exclusivamente por residentes de la UE ubicados en la UE. Abarca actividades como las operaciones diarias, la asistencia técnica y el servicio de atención al cliente. Estamos realizando una transición gradual de la AWS European Sovereign Cloud para que se opere exclusivamente por ciudadanos de la UE ubicados en la UE. Durante este período de transición, seguiremos trabajando con un equipo mixto de residentes de la UE y ciudadanos de la UE ubicados en la UE.

La infraestructura se administra a través de entidades jurídicas europeas especializadas constituidas en el marco de la legislación alemana. En octubre de 2025, AWS nombró director general a Stéphane Israël, ciudadano de la UE que reside en la UE. Stéphane será responsable de la administración y las operaciones de la AWS European Sovereign Cloud, lo que incluye la infraestructura, la tecnología y los servicios, además de liderar los esfuerzos más amplios de AWS en materia de soberanía digital. En enero de 2026, AWS también nombró a Stefan Hoechbauer (vicepresidente de AWS para Alemania y Europa Central) director general de la AWS European Sovereign Cloud. Stefan dirigirá la AWS European Sovereign Cloud junto con Stéphane Israël.

Un consejo consultivo compuesto exclusivamente por ciudadanos de la UE, que incluye a dos representantes independientes externos, proporciona supervisión y experiencia adicional en materia de soberanía.

Mejor control y residencia de datos
La AWS European Sovereign Cloud ofrece amplias garantías de residencia de datos para que pueda cumplir los requisitos más estrictos en materia de residencia de datos. Al igual que ocurre con nuestras regiones de AWS existentes en todo el mundo, todo el contenido permanece dentro la región que elija, a menos que decida lo contrario. Además del contenido, los metadatos creados por los clientes, incluidos los roles, los permisos, las etiquetas de recursos y las configuraciones, también permanecen dentro de la UE. La infraestructura cuenta con su propio sistema dedicado de AWS Identity and Access Management (AWS IAM) y facturación, que funciona de forma independiente dentro de las fronteras europeas.

Los controles técnicos integrados en la infraestructura impiden el acceso a la AWS European Sovereign Cloud desde fuera de la UE. La infraestructura incluye un proveedor de servicios de confianza europeo dedicado para las operaciones de las autoridades de certificación y utiliza servidores de nombres de Amazon Route 53 dedicados. Estos servidores solo usarán dominios de nivel superior europeos para sus propios nombres. La AWS European Sovereign Cloud no tiene dependencias críticas de personal o infraestructura fuera de la UE.

Marco de seguridad y cumplimiento
La AWS European Sovereign Cloud mantiene las mismas capacidades de seguridad básicas que cabe esperar de AWS, como el cifrado, la administración de claves, la gobernanza del acceso y AWS Nitro System para el aislamiento de la computación. Esto significa que sus instancias de EC2 se benefician de la integridad de la plataforma verificada criptográficamente y de los límites impuestos por el hardware que impiden el acceso no autorizado a sus datos sin comprometer el rendimiento, lo que le proporciona tanto los controles de soberanía como la potencia computacional que requieren sus cargas de trabajo. La infraestructura se somete a auditorías independientes externas, con programas de cumplimiento que incluyen la norma ISO/IEC 27001:2013, informes SOC 1/2/3 y la certificación C5 de la Oficina Federal de Seguridad de la Información.

El marco de referencia de soberanía de la AWS European Sovereign Cloud define los controles de soberanía específicos en relación con la independencia de la gobernanza, el control operativo, la residencia de datos y el aislamiento técnico. Este marco está disponible en AWS Artifact y proporciona visibilidad total a través de la certificación SOC 2.

Disponibilidad total del servicio
Puede acceder a una amplia variedad de servicios de AWS en la AWS European Sovereign Cloud desde su lanzamiento, incluidos Amazon SageMaker y Amazon Bedrock para cargas de trabajo de inteligencia artificial y machine learning. Para el procesamiento, puede usar Amazon Elastic Compute Cloud (Amazon EC2) y AWS Lambda. La orquestación de contenedores está disponible a través de Amazon Elastic Kubernetes Service (Amazon EKS) y Amazon Elastic Container Service (Amazon ECS). Los servicios de bases de datos incluyen Amazon Aurora, Amazon DynamoDB y Amazon Relational Database Service (Amazon RDS). Dispone de opciones de almacenamiento como Amazon Simple Storage Service (Amazon S3) y Amazon Elastic Block Store (Amazon EBS), con redes a través de Amazon Virtual Private Cloud (Amazon VPC) y servicios de seguridad como AWS Key Management Service (AWS KMS) y AWS Private Certificate Authority. Para obtener una lista actualizada de los servicios, consulte la matriz de capacidades de AWS que se ha publicado recientemente en AWS Builder Center.

La AWS European Sovereign Cloud cuenta con el respaldo de los socios de AWS, que se comprometen a ayudarle a cumplir sus requisitos de soberanía. Socios como Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro y Wiz ofrecen sus soluciones en la AWS European Sovereign Cloud, lo que le proporciona las herramientas y los servicios que necesita en materia de seguridad, análisis de datos, desarrollo de aplicaciones y cargas de trabajo específicas del sector. Este amplio apoyo de los socios le ayuda a crear soluciones soberanas que combinan los servicios de AWS con tecnologías de socios de confianza.

Inversión importante. en la infraestructura europea
La AWS European Sovereign Cloud está respaldada por una inversión de 7.800 millones de EUR en infraestructura, creación de empleo y desarrollo de habilidades. Se espera que esta inversión aporte 17.200 millones de EUR a la economía europea para 2040 y ayude a crear el equivalente a aproximadamente 2.800 puestos de trabajo a tiempo completo por año en empresas locales.

Algunos detalles técnicos
La AWS European Sovereign Cloud está disponible para todos los clientes, independientemente de dónde se encuentren. Puede acceder a la infraestructura utilizando el nombre de partición aws-eusc y el nombre de región eusc-de-east-1. Una partición es un grupo de regiones de AWS. Cada cuenta de AWS tiene limitado su alcance a una sola partición.

La infraestructura admite todos los métodos de acceso estándar de AWS, como la Consola de administración de AWS, los AWS SDK y la Interfaz de la línea de comandos de AWS (AWS CLI), lo que facilita la integración en sus flujos de trabajo y automatización existentes. Tras crear una nueva cuenta raíz para la partición de la AWS European Sovereign Cloud, primero deberá crear nuevas identidades y roles de IAM específicos para esta infraestructura, lo que le permitirá tener un control total sobre la administración del acceso en el entorno soberano europeo.

Cómo empezar
La AWS European Sovereign Cloud proporciona a las organizaciones europeas controles de soberanía mejorados, al tiempo que mantiene el acceso a la innovación y las capacidades de AWS. Puede contratar los servicios a través de Amazon Web Services EMEA SARL, con precios en EUR y facturación en cualquiera de las ocho divisas que admitimos actualmente. La infraestructura utiliza la arquitectura, la cartera de servicios y las API habituales de AWS, lo que facilita la creación y la migración de aplicaciones.

La adenda de la AWS European Sovereign Cloud contiene los compromisos contractuales adicionales para la AWS European Sovereign Cloud.

Para mí, como europeo, este lanzamiento representa el compromiso de AWS de satisfacer las necesidades específicas de nuestro continente y proporcionar las capacidades en la nube que impulsan la innovación en todos los sectores. Le invito a descubrir más sobre la AWS European Sovereign Cloud y cómo puede ayudar a su organización a cumplir sus requisitos de soberanía. Lea la descripción general de la AWS European Sovereign Cloud para obtener más información sobre los objetivos y el enfoque del diseño, regístrese para obtener una nueva cuenta y planifique hoy mismo el despliegue de su primera carga de trabajo.

— seb

Announcing replication support and Intelligent-Tiering for Amazon S3 Tables

2025-12-02 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/announcing-replication-support-and-intelligent-tiering-for-amazon-s3-tables/

Today, we’re announcing two new capabilities for Amazon S3 Tables: support for the new Intelligent-Tiering storage class that automatically optimizes costs based on access patterns, and replication support to automatically maintain consistent Apache Iceberg table replicas across AWS Regions and accounts without manual sync.

Organizations working with tabular data face two common challenges. First, they need to manually manage storage costs as their datasets grow and access patterns change over time. Second, when maintaining replicas of Iceberg tables across Regions or accounts, they must build and maintain complex architectures to track updates, manage object replication, and handle metadata transformations.

S3 Tables Intelligent-Tiering storage class
With the S3 Tables Intelligent-Tiering storage class, data is automatically tiered to the most cost-effective access tier based on access patterns. Data is stored in three low-latency tiers: Frequent Access, Infrequent Access (40% lower cost than Frequent Access), and Archive Instant Access (68% lower cost compared to Infrequent Access). After 30 days without access, data moves to Infrequent Access, and after 90 days, it moves to Archive Instant Access. This happens without changes to your applications or impact on performance.

Table maintenance activities, including compaction, snapshot expiration, and unreferenced file removal, operate without affecting the data’s access tiers. Compaction automatically processes only data in the Frequent Access tier, optimizing performance for actively queried data while reducing maintenance costs by skipping colder files in lower-cost tiers.

By default, all existing tables use the Standard storage class. When creating new tables, you can specify Intelligent-Tiering as the storage class, or you can rely on the default storage class configured at the table bucket level. You can set Intelligent-Tiering as the default storage class for your table bucket to automatically store tables in Intelligent-Tiering when no storage class is specified during creation.

Let me show you how it works
You can use the AWS Command Line Interface (AWS CLI) and the put-table-bucket-storage-class and get-table-bucket-storage-class commands to change or verify the storage tier of your S3 table bucket.

# Change the storage class
aws s3tables put-table-bucket-storage-class \
   --table-bucket-arn $TABLE_BUCKET_ARN  \
   --storage-class-configuration storageClass=INTELLIGENT_TIERING

# Verify the storage class
aws s3tables get-table-bucket-storage-class \
   --table-bucket-arn $TABLE_BUCKET_ARN  \

{ "storageClassConfiguration":
   { 
      "storageClass": "INTELLIGENT_TIERING"
   }
}

S3 Tables replication support
The new S3 Tables replication support helps you maintain consistent read replicas of your tables across AWS Regions and accounts. You specify the destination table bucket and the service creates read-only replica tables. It replicates all updates chronologically while preserving parent-child snapshot relationships. Table replication helps you build global datasets to minimize query latency for geographically distributed teams, meet compliance requirements, and provide data protection.

You can now easily create replica tables that deliver similar query performance as their source tables. Replica tables are updated within minutes of source table updates and support independent encryption and retention policies from their source tables. Replica tables can be queried using Amazon SageMaker Unified Studio or any Iceberg-compatible engine including DuckDB, PyIceberg, Apache Spark, and Trino.

You can create and maintain replicas of your tables through the AWS Management Console or APIs and AWS SDKs. You specify one or more destination table buckets to replicate your source tables. When you turn on replication, S3 Tables automatically creates read-only replica tables in your destination table buckets, backfills them with the latest state of the source table, and continually monitors for new updates to keep replicas in sync. This helps you meet time-travel and audit requirements while maintaining multiple replicas of your data.

Let me show you how it works
To show you how it works, I proceed in three steps. First, I create an S3 table bucket, create an Iceberg table, and populate it with data. Second, I configure the replication. Third, I connect to the replicated table and query the data to show you that changes are replicated.

For this demo, the S3 team kindly gave me access to an Amazon EMR cluster already provisioned. You can follow the Amazon EMR documentation to create your own cluster. They also created two S3 table buckets, a source and a destination for the replication. Again, the S3 Tables documentation will help you to get started.

I take a note of the two S3 Tables bucket Amazon Resource Names (ARNs). In this demo, I refer to these as the environment variables SOURCE_TABLE_ARN and DEST_TABLE_ARN.

First step: Prepare the source database

I start a terminal, connect to the EMR cluster, start a Spark session, create a table, and insert a row of data. The commands I use in this demo are documented in Accessing tables using the Amazon S3 Tables Iceberg REST endpoint.

sudo spark-shell \
--packages "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160" \
--master "local[*]" \
--conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \
--conf "spark.sql.defaultCatalog=spark_catalog" \
--conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog" \
--conf "spark.sql.catalog.spark_catalog.type=rest" \
--conf "spark.sql.catalog.spark_catalog.uri=https://s3tables.us-east-1.amazonaws.com/iceberg" \
--conf "spark.sql.catalog.spark_catalog.warehouse=arn:aws:s3tables:us-east-1:012345678901:bucket/aws-news-blog-test" \
--conf "spark.sql.catalog.spark_catalog.rest.sigv4-enabled=true" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-name=s3tables" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-region=us-east-1" \
--conf "spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO" \
--conf "spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider" \
--conf "spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled=false"

spark.sql("""
CREATE TABLE s3tablesbucket.test.aws_news_blog (
customer_id STRING,
address STRING
) USING iceberg
""")

spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust1', 'val1')")

spark.sql("SELECT * FROM s3tablesbucket.test.aws_news_blog LIMIT 10").show()
+-----------+-------+
|customer_id|address|
+-----------+-------+
|      cust1|   val1|
+-----------+-------+

So far, so good.

Second step: Configure the replication for S3 Tables

Now, I use the CLI on my laptop to configure the S3 table bucket replication.

Before doing so, I create an AWS Identity and Access Management (IAM) policy to authorize the replication service to access my S3 table bucket and encryption keys. Refer to the S3 Tables replication documentation for the details. The permissions I used for this demo are:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "s3tables:*",
                "kms:DescribeKey",
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}

After having created this IAM policy, I can now proceed and configure the replication:

aws s3tables-replication put-table-replication \
--table-arn ${SOURCE_TABLE_ARN} \
--configuration  '{
    "role": "arn:aws:iam::<MY_ACCOUNT_NUMBER>:role/S3TableReplicationManualTestingRole", 
    "rules":[
        {
            "destinations": [
                {
                    "destinationTableBucketARN": "${DST_TABLE_ARN}"
                }]
        }
    ]

The replication starts automatically. Updates are typically replicated within minutes. The time it takes to complete depends on the volume of data in the source table.

Third step: Connect to the replicated table and query the data

Now, I connect to the EMR cluster again, and I start a second Spark session. This time, I use the destination table.

To verify the replication works, I insert a second row of data on the source table.

spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust2', 'val2')")

I wait a few minutes for the replication to trigger. I follow the status of the replication with the get-table-replication-status command.

aws s3tables-replication get-table-replication-status \
--table-arn ${SOURCE_TABLE_ARN} \
{
    "sourceTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test/table/e0fce724-b758-4ee6-85f7-ca8bce556b41",
    "destinations": [
        {
            "replicationStatus": "pending",
            "destinationTableBucketArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst",
            "destinationTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst/table/5e3fb799-10dc-470d-a380-1a16d6716db0",
            "lastSuccessfulReplicatedUpdate": {
                "metadataLocation": "s3://e0fce724-b758-4ee6-8-i9tkzok34kum8fy6jpex5jn68cwf4use1b-s3alias/e0fce724-b758-4ee6-85f7-ca8bce556b41/metadata/00001-40a15eb3-d72d-43fe-a1cf-84b4b3934e4c.metadata.json",
                "timestamp": "2025-11-14T12:58:18.140281+00:00"
            }
        }
    ]
}

When replication status shows ready, I connect to the EMR cluster and I query the destination table. Without surprise, I see the new row of data.

Additional things to know
Here are a couple of additional points to pay attention to:

Replication for S3 Tables supports both Apache Iceberg V2 and V3 table formats, giving you flexibility in your table format choice.
You can configure replication at the table bucket level, making it straightforward to replicate all tables under that bucket without individual table configurations.
Your replica tables maintain the storage class you choose for your destination tables, which means you can optimize for your specific cost and performance needs.
Any Iceberg-compatible catalog can directly query your replica tables without additional coordination—they only need to point to the replica table location. This gives you flexibility in choosing query engines and tools.

Pricing and availability
You can track your storage usage by access tier through AWS Cost and Usage Reports and Amazon CloudWatch metrics. For replication monitoring, AWS CloudTrail logs provide events for each replicated object.

There are no additional charges to configure Intelligent-Tiering. You only pay for storage costs in each tier. Your tables continue to work as before, with automatic cost optimization based on your access patterns.

For S3 Tables replication, you pay the S3 Tables charges for storage in the destination table, for replication PUT requests, for table updates (commits), and for object monitoring on the replicated data. For cross-Region table replication, you also pay for inter-Region data transfer out from Amazon S3 to the destination Region based on the Region pair.

As usual, refer to the Amazon S3 pricing page for the details.

Both capabilities are available today in all AWS Regions where S3 Tables are supported.

To learn more about these new capabilities, visit the Amazon S3 Tables documentation or try them in the Amazon S3 console today. Share your feedback through AWS re:Post for Amazon S3 or through your AWS Support contacts.

— seb

Amazon S3 Vectors now generally available with increased scale and performance

2025-12-02 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/amazon-s3-vectors-now-generally-available-with-increased-scale-and-performance/

Today, I’m excited to announce that Amazon S3 Vectors is now generally available with significantly increased scale and production-grade performance capabilities. S3 Vectors is the first cloud object storage with native support to store and query vector data. You can use it to help you reduce the total cost of storing and querying vectors by up to 90% when compared to specialized vector database solutions.

Since we announced the preview of S3 Vectors in July, I’ve been impressed by how quickly you adopted this new capability to store and query vector data. In just over four months, you created over 250,000 vector indexes and ingested more than 40 billion vectors, performing over 1 billion queries (as of November 28th).

You can now store and search across up to 2 billion vectors in a single index, that’s up to 20 trillion vectors in a vector bucket and a 40x increase from 50 million per index during preview. This means that you can consolidate your entire vector dataset into one index, removing the need to shard across multiple smaller indexes or implement complex query federation logic.

Query performance has been optimized. Infrequent queries continue to return results in under one second, with more frequent queries now resulting in latencies around 100ms or less, making it well-suited for interactive applications such as conversational AI and multi-agent workflows. You can also retrieve up to 100 search results per query, up from 30 previously, providing more comprehensive context for retrieval augmented generation (RAG) applications.

The write performance has also improved substantially, with support for up to 1,000 PUT transactions per second when streaming single-vector updates into your indexes, delivering significantly higher write throughput for small batch sizes. This higher throughput supports workloads where new data must be immediately searchable, helping you ingest small data corpora quickly or handle many concurrent sources writing simultaneously to the same index.

The fully serverless architecture removes infrastructure overhead—there’s no infrastructure to set up or resources to provision. You pay for what you use as you store and query vectors. This AI-ready storage provides you with quick access to any amount of vector data to support your complete AI development lifecycle, from initial experimentation and prototyping through to large-scale production deployments. S3 Vectors now provides the scale and performance needed for production workloads across AI agents, inference, semantic search, and RAG applications.

Two key integrations that were launched in preview are now generally available. You can use S3 Vectors as a vector storage engine for Amazon Bedrock Knowledge Base. In particular, you can use it to build RAG applications with production-grade scale and performance. Moreover, S3 Vectors integration with Amazon OpenSearch is now generally available, so that you can use S3 Vectors as your vector storage layer while using OpenSearch for search and analytics capabilities.

You can now use S3 Vectors in 14 AWS Regions, expanding from five AWS Regions during the preview.

Let’s see how it works
In this post, I demonstrate how to use S3 Vectors through the AWS Console and CLI.

First, I create an S3 Vector bucket and an index.

echo "Creating S3 Vector bucket..."
aws s3vectors create-vector-bucket \
    --vector-bucket-name "$BUCKET_NAME"

echo "Creating vector index..."
aws s3vectors create-index \
    --vector-bucket-name "$BUCKET_NAME" \
    --index-name "$INDEX_NAME" \
    --data-type "float32" \
    --dimension "$DIMENSIONS" \
    --distance-metric "$DISTANCE_METRIC" \
    --metadata-configuration "nonFilterableMetadataKeys=AMAZON_BEDROCK_TEXT,AMAZON_BEDROCK_METADATA"

The dimension metric must match the dimension of the model used to compute the vectors. The distance metric indicates to the algorithm to compute the distance between vectors. S3 Vectors supports cosine and euclidian distances.

I can also use the console to create the bucket. We’ve added the capability to configure encryption parameters at creation time. By default, indexes use the bucket-level encryption, but I can override bucket-level encryption at the index level with a custom AWS Key Management Service (AWS KMS) key.

I also can add tags for the vector bucket and vector index. Tags at the vector index help with access control and cost allocation.

And I can now manage Properties and Permissions directly in the console.

Similarly, I define Non-filterable metadata and I configure Encryption parameters for the vector index.

Next, I create and store the embeddings (vectors). For this demo, I ingest my constant companion: the AWS Style Guide. This is an 800-page document that describes how to write posts, technical documentation, and articles at AWS.

I use Amazon Bedrock Knowledge Bases to ingest the PDF document stored on a general purpose S3 bucket. Amazon Bedrock Knowledge Bases reads the document and splits it in pieces called chunks. Then, it computes the embeddings for each chunk with the Amazon Titan Text Embeddings model and it stores the vectors and their metadata on my newly created vector bucket. The detailed steps for that process are out of the scope of this post, but you can read the instructions in the documentation.

When querying vectors, you can store up to 50 metadata keys per vector, with up to 10 marked as non-filterable. You can use the filterable metadata keys to filter query results based on specific attributes. Therefore, you can combine vector similarity search with metadata conditions to narrow down results. You can also store more non-filterable metadata for larger contextual information. Amazon Bedrock Knowledge Bases computes and stores the vectors. It also adds large metadata (the chunk of the original text). I exclude this metadata from the searchable index.

There are other methods to ingest your vectors. You can try the S3 Vectors Embed CLI, a command line tool that helps you generate embeddings using Amazon Bedrock and store them in S3 Vectors through direct commands. You can also use S3 Vectors as a vector storage engine for OpenSearch.

Now I’m ready to query my vector index. Let’s imagine I wonder how to write “open source”. Is it “open-source”, with a hyphen, or “open source” without a hyphen? Should I use uppercase or not? I want to search the relevant sections of the AWS Style Guide relative to “open source.”

# 1. Create embedding request
echo '{"inputText":"Should I write open source or open-source"}' | base64 | tr -d '\n' > body_encoded.txt

# 2. Compute the embeddings with Amazon Titan Embed model
aws bedrock-runtime invoke-model \
  --model-id amazon.titan-embed-text-v2:0 \
  --body "$(cat body_encoded.txt)" \
  embedding.json

# Search the S3 Vectors index for similar chunks
vector_array=$(cat embedding.json | jq '.embedding') && \
aws s3vectors query-vectors \
  --index-arn "$S3_VECTOR_INDEX_ARN" \
  --query-vector "{\"float32\": $vector_array}" \
  --top-k 3 \
  --return-metadata \
  --return-distance | jq -r '.vectors[] | "Distance: \(.distance) | Source: \(.metadata."x-amz-bedrock-kb-source-uri" | split("/")[-1]) | Text: \(.metadata.AMAZON_BEDROCK_TEXT[0:100])..."'

The first result shows this JSON:

        {
            "key": "348e0113-4521-4982-aecd-0ee786fa4d1d",
            "metadata": {
                "x-amz-bedrock-kb-data-source-id": "0SZY6GYPVS",
                "x-amz-bedrock-kb-source-uri": "s3://sst-aws-docs/awsstyleguide.pdf",
                "AMAZON_BEDROCK_METADATA": "{\"createDate\":\"2025-10-21T07:49:38Z\",\"modifiedDate\":\"2025-10-23T17:41:58Z\",\"source\":{\"sourceLocation\":\"s3://sst-aws-docs/awsstyleguide.pdf\"",
                "AMAZON_BEDROCK_TEXT": "[redacted] open source (adj., n.) Two words. Use open source as an adjective (for example, open source software), or as a noun (for example, the code throughout this tutorial is open source). Don't use open-source, opensource, or OpenSource. [redacted]",
                "x-amz-bedrock-kb-document-page-number": 98.0
            },
            "distance": 0.63120436668396
        }

It finds the relevant section in the AWS Style Guide. I must write “open source” without a hyphen. It even retrieved the page number in the original document to help me cross-check the suggestion with the relevant paragraph in the source document.

One more thing
S3 Vectors has also expanded its integration capabilities. You can now use AWS CloudFormation to deploy and manage your vector resources, AWS PrivateLink for private network connectivity, and resource tagging for cost allocation and access control.

Pricing and availability
S3 Vectors is now available in 14 AWS Regions, adding Asia Pacific (Mumbai, Seoul, Singapore, Tokyo), Canada (Central), and Europe (Ireland, London, Paris, Stockholm) to the existing five Regions from preview (US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Sydney), and Europe (Frankfurt))

Amazon S3 Vectors pricing is based on three dimensions. PUT pricing is calculated based on the logical GB of vectors you upload, where each vector includes its logical vector data, metadata, and key. Storage costs are determined by the total logical storage across your indexes. Query charges include a per-API charge plus a $/TB charge based on your index size (excluding non-filterable metadata). As your index scales beyond 100,000 vectors, you benefit from lower $/TB pricing. As usual, the Amazon S3 pricing page has the details.

To get started with S3 Vectors, visit the Amazon S3 console. You can create vector indexes, start storing your embeddings, and begin building scalable AI applications. For more information, check out the Amazon S3 User Guide or the AWS CLI Command Reference.

I look forward to seeing what you build with these new capabilities. Please share your feedback through AWS re:Post or your usual AWS Support contacts.

— seb

AWS DevOps Agent helps you accelerate incident response and improve system reliability (preview)

2025-12-02 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-devops-agent-helps-you-accelerate-incident-response-and-improve-system-reliability-preview/

Today, we’re announcing the public preview of AWS DevOps Agent, a frontier agent that helps you respond to incidents, identify root causes, and prevent future issues through systematic analysis of past incidents and operational patterns.

Frontier agents represent a new class of AI agents that are autonomous, massively scalable, and work for hours or days without constant intervention.

When production incidents occur, on-call engineers face significant pressure to quickly identify root causes while managing stakeholder communications. They must analyze data across multiple monitoring tools, review recent deployments, and coordinate response teams. After service restoration, teams often lack bandwidth to transform incident learnings into systematic improvements.

AWS DevOps Agent is your always-on, autonomous on-call engineer. When issues arise, it automatically correlates data across your operational toolchain, from metrics and logs to recent code deployments in GitHub or GitLab. It identifies probable root causes and recommends targeted mitigations, helping reduce mean time to resolution. The agent also manages incident coordination, using Slack channels for stakeholder updates and maintaining detailed investigation timelines.

To get started, you connect AWS DevOps Agent to your existing tools through the AWS Management Console. The agent works with popular services such as Amazon CloudWatch, Datadog, Dynatrace, New Relic, and Splunk for observability data, while integrating with GitHub Actions and GitLab CI/CD to track deployments and their impact on your cloud resources. Through the bring your own (BYO) Model Context Protocol (MCP) server capability, you can also integrate additional tools such as your organization’s custom tools, specialized platforms or open source observability solutions, such as Grafana and Prometheus into your investigations.

The agent acts as a virtual team member and can be configured to automatically respond to incidents from your ticketing systems. It includes built-in support for ServiceNow, and through configurable webhooks, can respond to events from other incident management tools like PagerDuty. As investigations progress, the agent updates tickets and relevant Slack channels with its findings. All of this is powered by an intelligent application topology the agent builds—a comprehensive map of your system components and their interactions, including deployment history that helps identify potential deployment-related causes during investigations.

Let me show you how it works
To show you how it works, I deployed a straigthforward AWS Lambda function that intentionally generates errors when invoked. I deployed it in an AWS CloudFormation stack.

Step 1: Create an Agent Space

An Agent Space defines the scope of what AWS DevOps Agent can access as it performs tasks.

You can organize Agent Spaces based on your operational model. Some teams align an Agent Space with a single application, others create one per on-call team managing multiple services, and some organizations use a centralized approach. For this demonstration, I’ll show you how to create an Agent Space for a single application. This setup helps isolate investigations and resources for that specific application, making it easier to track and analyze incidents within its context.

In the AWS DevOps Agent section of the AWS Management Console, I select Create Agent Space, enter a name for this space and create the AWS Identity and Access Management (IAM) roles it uses to introspect AWS resources in my or others’ AWS accounts.

For this demo, I choose to enable the AWS DevOps Agent web app; more about this later. This can be done at a later stage.

When ready, I choose Create.

After it has been created, I choose the Topology tab.

This view shows the key resources, entities, and relationships AWS DevOps Agent has selected as a foundation for performing its tasks efficiently. It doesn’t represent everything AWS DevOps Agent can access or see, only what the Agent considers most relevant right now. By default, the Topology includes the AWS resources that are contained in my account. As your agent completes more tasks, it will discover and add new resources to this list.

Step 2: Configure the AWS DevOps web app for the operators

The AWS DevOps Agent web app provides a web interface for on-call engineers to manually trigger investigations, view investigation details including relevant topology elements, steer investigations, and ask questions about an investigation.

I can access the web app directly from my Agent Space in the AWS console by choosing the Operator access link. Alternatively, I can use AWS IAM Identity Center to configure user access for my team. IAM Identity Center lets me manage users and groups directly or connect to an identity provider (IdP), providing a centralized way to control who can access the AWS DevOps Agent web app.

At this stage, I have an Agent Space all set up to focus investigations and resources for this speciﬁc application, and I’ve enabled the DevOps team to initiate investigations using the web app.

Now that the one-time setup for this application is done, I start invoking the faulty Lambda function. It generates errors at each invocation. The CloudWatch alarm associated with the Lambda errors count turns on to ALARM state. In real life, you might receive an alert from external services, such as ServiceNow. You can configure AWS DevOps Agent to automatically start investigations when receiving such alerts.

For this demo, I manually start the investigation by selecting Start Investigation.

You can also choose from several preconfigured starting points to quickly begin your investigation: Latest alarm to investigate your most recent triggered alarm and analyze the underlying metrics and logs to determine the root cause, High CPU usage to investigate high CPU utilization metrics across your compute resources and identify which processes or services are consuming excessive resources, or Error rate spike to investigate the recent increase in application error rates by analyzing metrics, application logs, and identifying the source of failures.

I enter some information, such as Investigation details, Investigation starting point, the Date and time of the incident, the AWS Account ID for the incident.

In the AWS DevOps Agent web app, you can watch the investigation unfold in real time. The agent identifies the application stack. It correlates metrics from CloudWatch, examines logs from CloudWatch Logs or external sources, such as Splunk, reviews recent code changes from GitHub, and analyzes traces from AWS X-Ray.

It identifies the error patterns and provides a detailed investigation summary. In the context of this demo, the investigation reveals that these are intentional test exceptions, shows the timeline of function invocations leading to the alarm, and even suggests monitoring improvements for error handling.

The agent uses a dedicated incident channel in Slack, notifies on-call teams if needed, and provides real-time status updates to stakeholders. Through the investigation chat interface, you can interact directly with the agent by asking clarifying questions such as “which logs did you analyze?” or steering the investigation by providing additional context, such as “focus on these specific log groups and rerun your analysis.” If you need expert assistance, you can create an AWS Support case with a single click, automatically populating it with the agent’s findings, and engage with AWS Support experts directly through the investigation chat window.

For this demo, the AWS DevOps Agent correctly identified manual activities in the Lambda console to invoke a function that intentionally triggers errors .

Beyond incident response, AWS DevOps Agent analyzes my recent incidents to identify high-impact improvements that prevent future issues.

During active incidents, the agent offers immediate mitigation plans through its incident mitigations tab to help restore service quickly. Mitigation plans consist of specs that provide detailed implementation guidance for developers and agentic development tools like Kiro.

For longer-term resilience, it identifies potential enhancements by examining gaps in observability, infrastructure configurations, and deployment pipeline. My straightforward demo that triggered intentional errors was not enough to generate relevant recommendations though.

For example, it might detect that a critical service lacks multi-AZ deployment and comprehensive monitoring. The agent then creates detailed recommendations with implementation guidance, considering factors like operational impact and implementation complexity. In an upcoming quick follow-up release, the agent will expand its analysis to include code bugs and testing coverage improvements.

Availability
You can try AWS DevOps Agent today in the US East (N. Virginia) Region. Although the agent itself runs in US East (N. Virginia) (us-east-1), it can monitor applications deployed in any Region, across multiple AWS accounts.

During the preview period, you can use AWS DevOps Agent at no charge, but there will be a limit on the number of agent task hours per month.

As someone who has spent countless nights debugging production issues, I’m particularly excited about how AWS DevOps Agent combines deep operational insights with practical, actionable recommendations. The service helps teams move from reactive firefighting to proactive system improvement.

To learn more and sign up for the preview, visit AWS DevOps Agent. I look forward to hearing how AWS DevOps Agent helps improve your operational efficiency.

— seb

AWS Partner Central now available in AWS Management Console

2025-12-01 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-partner-central-now-available-in-aws-management-console/

Today, we’re announcing that AWS Partner Central is now available directly in the AWS Management Console, creating a unified experience that transforms how you engage with AWS as both customers and AWS Partners.

As someone who has worked with countless AWS customers over the years, I’ve observed how organizations evolve in their AWS journey. Many of our most successful Partners began as AWS customers—first using our services to build their own infrastructure and solutions, then expanding to create offerings for others. Seeing this natural progression from customer to Partner, we recognized an opportunity to streamline these traditionally separate experiences into one unified journey.

As AWS evolved, so did the needs of our Partner community. Organizations today operate in multiple capacities: using AWS services for their own infrastructure while simultaneously building and delivering solutions for their customers. Modern businesses need streamlined workflows that support their growth from AWS customer to Partner to AWS Marketplace Seller, with enterprise-grade security features that match how they actually work with AWS today.

A new unified console experience
The integration of AWS Partner Central into the Console represents a fundamental shift in partnership accessibility. For existing AWS customers, such as you, becoming an AWS Partner is now as clear as accessing any other AWS service. The familiar console interface provides direct access to partnership opportunities, program benefits, and AWS Marketplace capabilities without needing separate logins or navigation between different systems.

Getting started as an AWS Partner now takes only a few clicks within your existing console environment. You can discover partnership opportunities, understand program requirements, and begin your Partner journey without leaving the AWS interface you already know and trust.

The console integration creates an intuitive pathway for existing customers to transition into AWS Marketplace Sellers. You can now access AWS Marketplace Seller capabilities alongside your existing AWS services, managing both your infrastructure and AWS Marketplace business from a single interface. Private offer requests and negotiations can be managed directly within AWS Partner Central, and you can manage your AWS Marketplace listings alongside your other AWS activities through streamlined workflows.

Becoming an AWS Partner
The unified console experience provides access to comprehensive partnership benefits designed to accelerate your business growth.

Join the AWS Partner Network (APN) and complete your Partner and AWS Marketplace Seller requirements seamlessly within the same interface. Enroll in Partner Paths that align with your customer solutions to build, market, list, and sell in AWS Marketplace while growing alongside AWS. When you are established, use the Partner programs to differentiate your solution, list in AWS Marketplace to improve your go-to-market discoverability, and build AWS expertise through certifications to drive profitability by capturing new revenue streams. Scale your business by selling or reselling software and professional services in AWS Marketplace, helping you accelerate deals, boost revenue, and expand your customer reach to new geographies, industries, and segments.

Throughout your journey, you can continue using Amazon Q in the console, which provides personalized guidance through AWS Partner Assistant.

Let’s see the new Partner Central console
The new AWS Partner Central is accessible like any other AWS service from the console. Among many new capabilities, it provides four key sections that support Partner operations and business growth within the AWS Partner Network:

1. It helps you sell your solutions

You can create and publish solutions that address specific customer needs through AWS Marketplace. Solutions are made up of products such as software as a service (SaaS), Amazon Machine Images (AMI), containers, professional services, AI agents and tools, and more. The solutions management capability guides you through building offerings that include both products you own and those you are authorized to resell. You can craft compelling value propositions and descriptions that clearly communicate your solution benefits to potential buyers browsing AWS Marketplace.

I choose Create solution to start listing a new solution in the AWS Marketplace, as shown in the following figure.

2. It helps you update and manage your Partner profile

Your Partner profile showcases your organization’s expertise and capabilities to the AWS community. You control how your business appears to potential customers and Partners by highlighting the industry segments you serve and describing your primary products or services. Profile visibility settings provide you with the option to choose whether your information is public or private.

3. It helps you track opportunities

You can manage your pipeline of AWS customers, supporting joint collaborations with AWS on customer engagements. You monitor these prospects using clear status indicators: approved, rejected, draft, and pending approval. The opportunity dashboard shows stages, estimated AWS Monthly Recurring Revenue, and other key metrics that help you understand your pipeline. You can create more opportunities directly within the console and export data for your own reporting and analysis.

4. It provides you with the ability to discover and connect with other Partners

After becoming an AWS Partner, you get access to the AWS Partners network, where you can search for other Partners. You can connect with them to collaborate on sales opportunities and expand your customer outreach.

You search through available Partners using filters for industry, location, Partner program type, and specialization. The centralized dashboard shows your active connections, pending requests, and connection history, so that you can manage business relationships and identify collaboration opportunities that can expand your reach. Like all other AWS services, these Partner connection capabilities are now available as APIs, which provide automation and integration into your existing workflows.

These capabilities work together within the new AWS Partner Central console, accessible directly from the console, helping you transition from AWS customer to successful Partner with enterprise-grade security and streamlined workflows.

The technical foundation: Migrating the identity system
This unified console experience is made possible by our migration to a modern identity system built on AWS Identity and Access Management (IAM). We’ve transitioned from legacy identity infrastructure to IAM Identity Center, providing enterprise-grade security capabilities including single sign-on capabilities and multi-factor authentication. With security as job zero, this migration provides new and existing Partners with the possibility to connect their own identity providers to AWS Partner Central. It provides seamless integration with existing enterprise authentication systems while removing the complexity of managing separate credentials across different services.

One more thing
APIs are the core of what we do at AWS, and AWS Partner Central is no different. You can automate and streamline your co-sell workflows by connecting your business tools to AWS Partner Central. The APIs offered by AWS Partner Central help you accelerate APN benefits—from Account Management (Account API) and Solution Management (Solution API) to co-selling with Opportunity and Leads APIs, and Benefits APIs for faster benefit activation.

You can use these APIs to engage with AWS and grow your Partner business from your own CRM tools.

Get started today
This integration between the console and AWS Partner Central reflects our commitment to reducing complexity and improving the Partner experience. We’re bringing AWS Partner Central into the console to create a more intuitive path for organizations to grow with AWS from initial customer adoption through to full partnership engagement and AWS Marketplace success.

Your journey from AWS customer to successful AWS Partner and AWS Marketplace Seller starts with a few clicks in your console. I encourage you to explore the new unified experience today and discover how AWS Partner Central in the console can accelerate your organization’s growth and success within the AWS community.

Ready to get started? Visit AWS Partner Central in your console to learn more about the AWS Partner Network and discover the partnership path that’s right for your organization.

— seb

Introducing VPC encryption controls: Enforce encryption in transit within and across VPCs in a Region

2025-11-21 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region/

Today, we’re announcing virtual private cloud (VPC) encryption controls, a new capability of Amazon Virtual Private Cloud (Amazon VPC) that helps you audit and enforce encryption in transit for all traffic within and across VPCs in a Region.

Organizations across financial services, healthcare, government, and retail face significant operational complexity in maintaining encryption compliance across their cloud infrastructure. Traditional approaches require piecing together multiple solutions and managing complex public key infrastructure (PKI), while manually tracking encryption across different network paths using spreadsheets—a process prone to human error that becomes increasingly challenging as infrastructure scales.

Although AWS Nitro based instances automatically encrypt traffic at the hardware layer without affecting performance, organizations need simple mechanisms to extend these capabilities across their entire VPC infrastructure. This is particularly important for demonstrating compliance with regulatory frameworks such as Health Insurance Portability and Accountability (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), and Federal Risk and Authorization Management Program (FedRAMP), which require proof of end-to-end encryption across environments. Organizations need centralized visibility and control over their encryption status, without having to manage performance trade-offs or complex key management systems.

VPC encryption controls address these challenges by providing two operational modes: monitor and enforce. In monitor mode, you can audit the encryption status of your traffic flows and identify resources that allow plaintext traffic. The feature adds a new encryption-status field to VPC flow logs, giving you visibility into whether traffic is encrypted using Nitro hardware encryption, application-layer encryption (TLS), or both.

After you’ve identified resources that need modification, you can take steps to implement encryption. AWS services, such as Network Load Balancer, Application Load Balancer, and AWS Fargate tasks, will automatically and transparently migrate your underlying infrastructure to Nitro hardware without any action required from you and with no service interruption. For other resources, such as the previous generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, you will need to switch to modern Nitro based instance types or configure TLS encryption at application level.

You can switch to enforce mode after all resources have been migrated to encryption-compliant infrastructure. This migration to encryption-compliant hardware and communication protocols is a prerequisite for enabling enforce mode. You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of your VPC or the AWS network).

Other resources must be encryption-compliant and can’t be excluded. After activation, enforce mode provides that all future resources are only created on compatible Nitro instances, and unencrypted traffic is dropped when incorrect protocols or ports are detected.

Let me show you how to get started

For this demo, I started three EC2 instances. I use one as a web server with Nginx installed on port 80, serving a clear text HTML page. The other two are continuously making HTTP GET requests to the server. This generates clear text traffic in my VPC. I use the m7g.medium instance type for the web server and one of the two clients. This instance type uses the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. I use a t4g.medium instance for the other web client. The network traffic of that instance is not encrypted at the hardware level.

To get started, I enable encryption controls in monitor mode. In the AWS Management Console, I select Your VPCs in the left navigation pane, then I switch to the VPC encryption controls tab. I choose Create encryption control and select the VPC I want to create the control for.

Each VPC can have only one VPC encryption control associated with it, creating a one-to-one relationship between the VPC ID and the VPC encryption control Id. When creating VPC encryption controls, you can add tags to help with resource organization and management. You can also activate VPC encryption control when you create a new VPC.

I enter a Name for this control. I select the VPC I want to control. For existing VPCs, I have to start in Monitor mode, and I can turn on Enforce mode when I’m sure there is no unencrypted traffic. For new VPCs, I can enforce encryption at the time of creation.

Optionally, I can define tags when creating encryption controls for an existing VPC. However, when enabling encryption controls during VPC creation, separate tags can’t be created for VPC encryption controls—because they automatically inherit the same tags as the VPC. When I’m ready, I choose Create encryption control.

Alternatively, I can use the AWS Command Line Interface (AWS CLI):

aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789

Next, I audit the encryption status of my VPC using the console, command line, or flow logs:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-123456789 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \
  --log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
{
    "ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=",
    "FlowLogIds": [
        "fl-0667848f2d19786ca"
    ],
    "Unsuccessful": []
}

After a few minutes, I see this traffic in my logs:

flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status
ingress - 10.0.133.8 10.0.128.55 43236 80 1 # <-- HTTP between web client and server. Encrypted at hardware-level
egress 1 10.0.128.55 10.0.133.8 80 43236 1
ingress - 10.0.133.8 10.0.128.55 36902 80 1
egress 1 10.0.128.55 10.0.133.8 80 36902 1
ingress - 10.0.130.104 10.0.128.55 55016 80 0 # <-- HTTP between web client and server. Not encrypted at hardware-level
egress 1 10.0.128.55 10.0.130.104 80 55016 0
ingress - 10.0.130.104 10.0.128.55 60276 80 0
egress 1 10.0.128.55 10.0.130.104 80 60276 0

10.0.128.55 is the web server with hardware-encrypted traffic, serving clear text traffic at application level.
10.0.133.8 is the web client with hardware-encrypted traffic.
10.0.130.104 is the web client with no encryption at the hardware level.

The encryption-status field tells me the status of the encryption for the traffic between the source and destination address:

0 means the traffic is in clear text
1 means the traffic is encrypted at the network layer (Level 3) by the Nitro system
2 means the traffic is encrypted at the application layer (Level7, TCP Port 443 and TLS/SSL)
3 means the traffic is encrypted both at the application layer (TLS) and the network layer (Nitro)
“-” means VPC encryption controls are not enabled, or AWS Flow Logs don’t have the status information.

The traffic originating from the web client on the instance that isn’t Nitro based (10.0.130.104), is flagged as 0. The traffic initiated from the web client on the Nitro- ased instance (10.0.133.8) is flagged as 1.

I also use the console to identify resources that need modification. It reports two nonencrypted resources: the internet gateway and the elastic network interface (ENI) of the instance that isn’t based on Nitro.

I can also check for nonencrypted resources using the CLI:

aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789

After updating my resources to support encryption, I can use the console or the CLI to switch to enforce mode.

In the console, I select the VPC encryption control. Then, I select Actions and Switch mode.

Or the equivalent CLI:

aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce

How to modify the resources that are identified as nonencrypted?

All your VPC resources must support traffic encryption, either at the hardware layer or at the application layer. For most resources, you don’t need to take any action.

AWS services accessed through AWS PrivateLink and gateway endpoints automatically enforce encryption at the application layer. These services only accept TLS-encrypted traffic. AWS will automatically drop any traffic that isn’t encrypted at the application layer.

When you enable monitor mode, we automatically and gradually migrate your Network Load Balancers, Application Load Balancers, AWS Fargate clusters, and Amazon Elastic Kubernetes Service (Amazon EKS) clusters to hardware that inherently supports encryption. This migration happens transparently without any action required from you.

Some VPC resources require you to select the underlying instances that support modern Nitro hardware-layer encryption. These include EC2 Instances, Auto Scaling groups, Amazon Relational Database Service (Amazon RDS) databases (including Amazon DocumentDB), Amazon ElastiCache node-based clusters, Amazon Redshift provisioned clusters, EKS clusters, ECS with EC2 capacity, MSK Provisioned, Amazon OpenSearch Service, and Amazon EMR. To migrate your Redshift clusters, you must create a new cluster or namespace from a snapshot.

If you use newer-generation instances, you likely already have encryption-compliant infrastructure because all recent instance types support encryption. For older-generation instances that don’t support encryption-in transit, you’ll need to upgrade to supported instance types.

Something to know when using AWS Transit Gateway

When creating a Transit Gateway through AWS CloudFormation with VPC encryption enabled, you need two additional AWS Identity and Access Management (IAM) permissions: ec2:ModifyTransitGateway and ec2:ModifyTransitGatewayOptions. These permissions are required because CloudFormation uses a two-step process to create a Transit Gateway. It first creates the Transit Gateway with basic configuration, then calls ModifyTransitGateway to enable encryption support. Without these permissions, your CloudFormation stack will fail during creation when attempting to apply the encryption configuration, even if you’re only performing what appears to be a create operation.

Pricing and availability

You can start using VPC encryption controls today in these AWS Regions: US East (Ohio, N. Virginia), US West (N. California, Oregon), Africa (Cape Town), Asia Pacific (Hong Kong, Hyderabad, Jakarta, Melbourne, Mumbai, Osaka, Singapore, Sydney, Tokyo), Canada (Central), Canada West (Calgary), Europe (Frankfurt, Ireland, London, Milan, Paris, Stockholm, Zurich), Middle East (Bahrain, UAE), and South America (São Paulo).

VPC encryption controls is free of cost until March 1, 2026. The VPC pricing page will be updated with details as we get closer to that date.

To learn more, visit the VPC encryption controls documentation or try it out in your AWS account. I look forward to hearing how you use this feature to strengthen your security posture and help you meet compliance standards.

— seb

New Amazon Bedrock service tiers help you match AI workload performance with cost

2025-11-19 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/new-amazon-bedrock-service-tiers-help-you-match-ai-workload-performance-with-cost/

Today, Amazon Bedrock introduces new service tiers that give you more control over your AI workload costs while maintaining the performance levels your applications need.

I’m working with customers building AI applications. I’ve seen firsthand how different workloads require different performance and cost trade-offs. Many organizations running AI workloads face challenges balancing performance requirements with cost optimization. Some applications need rapid response times for real-time interactions, whereas others can process data more gradually. With these challenges in mind, today we’re announcing additional options pricing that give you more flexibility in matching your workload requirements with cost optimization.

Amazon Bedrock now offers three service tiers for workloads: Priority, Standard, and Flex. Each tier is designed to match specific workload requirements. Applications have varying response time requirements based on the use case. Some applications—such as financial trading systems—demand the fastest response times, others need rapid response times to support business processes like content generation, and applications such as content summarization can process data more gradually.

The Priority tier processes your requests ahead of other tiers, providing preferential compute allocation for mission-critical applications like customer-facing chat-based assistants and real-time language translation services, though at a premium price point. The Standard tier provides consistent performance at regular rates for everyday AI tasks, ideal for content generation, text analysis, and routine document processing. For workloads that can handle longer latency, the Flex tier offers a more cost-effective option with lower pricing, which is well suited for model evaluations, content summarization, and multistep analysis and agentic workflows.

You can now optimize your spending by matching each workload to the most appropriate tier. For example, if you’re running a customer service chat-based assistant that needs quick responses, you can use the Priority tier to get the fastest processing times. For content summarization tasks that can tolerate longer processing times, you can use the Flex tier to reduce costs while maintaining reliable performance. For most models that support Priority Tier, customers can realize up to 25% better output tokens per second (OTPS) latency compared to standard tier.

Check the Amazon Bedrock documentation for an up-to-date list of models supported for each service tier.

Choosing the right tier for your workload

Here is a mental model to help you choose the right tier for your workload.

Category	Recommended service tier	Description
Mission-critical	Priority	Requests are handled ahead of other tiers. Lower latency responses for user-facing apps (for example, customer service chat assistants, real-time language translation, interactive AI assistants)
Business-standard	Standard	Responsive performance for important workloads (for example, content generation, text analysis, routine document processing)
Business-noncritical	Flex	Cost-efficient for less urgent workloads (for example, model evaluations, content summarization, multistep agentic workflows)

Start by reviewing with application owners your current usage patterns. Next, identify which workloads need immediate responses and which ones can process data more gradually. You can then begin routing a small portion of your traffic through different tiers to test performance and cost benefits.

The AWS Pricing Calculator helps you estimate costs for different service tiers by entering your expected workload for each tier. You can estimate your budget based on your specific usage patterns.

To monitor your usage and costs, you can use the AWS Service Quotas console or turn on model invocation logging in Amazon Bedrock and observe the metrics with Amazon CloudWatch. These tools provide visibility into your token usage and help you track performance across different tiers.

You can start using the new service tiers today. You choose the tier on a per-API call basis. Here is an example using the ChatCompletions OpenAI API, but you can pass the same service_tier parameter in the body of InvokeModel, InvokeModelWithResponseStream, Converse, andConverseStream APIs (for supported models):

from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1",
    api_key="$AWS_BEARER_TOKEN_BEDROCK" # Replace with actual API key
)

completion = client.chat.completions.create(
    model= "openai.gpt-oss-20b-1:0",
    messages=[
        {
            "role": "developer",
            "content": "You are a helpful assistant."
        },
        {
            "role": "user",
            "content": "Hello!"
        }
    ]
    service_tier= "priority"  # options: "priority | default | flex"
)

print(completion.choices[0].message)

To learn more, check out the Amazon Bedrock User Guide or contact your AWS account team for detailed planning assistance.

I’m looking forward to hearing how you use these new pricing options to optimize your AI workloads. Share your experience with me online on social networks or connect with me at AWS events.

— seb

AWS Weekly Roundup: AWS Lambda for Rust, NLB for QUIC protocol, Amazon DCV for Mac, and more (November 17, 2025)

2025-11-17 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-aws-lambda-load-balancers-amazon-dcv-amazon-linux-2023-and-more-november-17-2025/

The weeks before AWS re:Invent, my team is full steam ahead preparing content for the conference. I can’t wait to meet you at one of my three talks: CMP346 : Supercharge AI/ML on Apple Silicon with EC2 Mac, CMP344: Speed up Apple application builds with CI/CD on EC2 Mac, and DEV416: Develop your AI Agents and MCP Tools in Swift.

Last week, AWS announced three new AWS Heroes. The AWS Heroes program recognizes a vibrant, worldwide group of AWS experts whose enthusiasm for knowledge-sharing has a real impact within the community. Welcome to the community, Dimple, Rola, and Vivek.

We also opened the GenAI Loft in Tel Aviv, Israel. AWS Gen AI Lofts are collaborative spaces and immersive experiences for startups and developers. The Loft content is tailored to address local customer needs – from startups and enterprises to public sector organizations, bringing together developers, investors, and industry experts under one roof.

The loft is open in Tel Aviv until Wednesday, November 19. If you’re in the area, check the list of sessions, workshops, and hackathons today.

If you are a serverless developer, last week was really rich with news. Let’s start with these.

Last week’s launches
Here are the launches that got my attention this week:

AWS Lambda officially supports Rust , AWS Lambda supports Java 25, and AWS Lambda adds an experimental runtime interface client for Swift – What a busy time for the Lambda service team! The support for the Rust programming language is now generally available. Although the runtime interface client existed for years, it has just been graduated to version 1.0.0. My colleagues Julian and Darko wrote a blog post to showcase the benefits of using Rust for your Lambda functions. Java 25 also has changes that make Lambda functions written in Java more efficient. My colleague Lefteris wrote a blog post to describe these benefits.
AWS Lambda announces Provisioned Mode for SQS event source mapping – This provides you with the benefits to optimize throughput and handle traffic spikes by provisioning event polling resources.
Amazon EventBridge introduces enhanced visual rule builder – The Amazon EventBridge enhanced visual rule builder simplifies event-driven application development with an intuitive interface, comprehensive event catalog, and integration with the EventBridge Schema Registry.
AWS Service Reference Information now supports SDK Operation to Action mapping – Besides the serverless news, this is the biggest announcement of the week in my opinion. The service reference information now includes which operations are supported by AWS services and which IAM permissions are needed to call a given operation. This will help you answer questions such as “I want to call a specific AWS service operation, which IAM permissions do I need?” You can automate the retrieval of service reference information through a simple JSON based API.
AWS Network Load Balancer (NLB) now supports QUIC protocol in passthrough mode – This provides ultra-low latency traffic forwarding with session stickiness using QUIC Connection IDs. This capability reduces application latency by 25-30% for mobile-first applications through minimized handshakes and connection resilience. NLB operates in passthrough mode, forwarding QUIC traffic directly to targets while maintaining customer control over TLS certificates and end-to-end encryption. The blog post has the details.
Application Load Balancer (ALB) support client credential flow with JWT verification – This one is important for API developers too. This simplifies the deployment of secure machine-to-machine (M2M) and service-to-service (S2S) communications. This provides ALB with the ability to verify JWTs, reducing architectural complexity and simplifying security implementation.
AWS KMS now supports Edwards-curve Digital Signature Algorithm (EdDSA) – This capability provides 128-bit security equivalent to NIST P-256 with faster signing performance and compact sizes (64-byte signatures, 32-byte public keys). Ed25519 is ideal for IoT devices and blockchain applications requiring small key and signature sizes.
Amazon DCV now supports Amazon EC2 Mac instances – This provides high-performance remote desktop access with 4K resolution and 60 FPS performance. You can connect from Windows, Linux, macOS, or web clients with features including time zone redirection and audio output.
Amazon Linux 2023 version 2025110 is released – It now includes packages for Mountpoint for Amazon S3, the Swift 6.2.1 toolchain, and Node.js 24. Installing Swift on Amazon Linux 2023 virtual machines or containers is now as easy as sudo dnf install -y swiftlang.

Additional updates
Here are some additional projects, blog posts, and news items that I found interesting:

Amazon Elastic Kubernetes Service gets independent affirmation of its zero operator access design – Amazon EKS offers a zero operator access posture. AWS personnel cannot access your content. This is achieved through a combination of AWS Nitro System-based instances, restricted administrative APIs, and end-to-end encryption. An independent review by NCC Group confirmed the effectiveness of these security measures.
Make your web apps hands-free with Amazon Nova Sonic – Amazon Nova Sonic, a foundation model from AAmazon Bedrock, provides you with the ability to create natural, low-latency, bidirectional speech conversations for applications. This provides users with the ability to collaborate with applications through voice and embedded intelligence, unlocking new interaction patterns and enhancing usability. This blog post demonstrates a reference app, Smart Todo App. It shows how voice can be integrated to provide a hands-free experience for task management.
AWS X-Ray SDKs & Daemon migration to OpenTelemetry – AWS X-Ray is transitioning to OpenTelemetry as its primary instrumentation standard for application tracing. OpenTelemetry-based instrumentation solutions are recommended for producing traces from applications and sending them to AWS X-Ray. X-Ray’s existing console experience and functionality continue to be fully supported and remains unchanged by this transition.
Powering the world’s largest events: How Amazon CloudFront delivers at scale – Amazon CloudFront achieved a record-breaking peak of 268 terabits per second on November 1, 2025, during major game delivery workloads—enough bandwidth to simultaneously stream live sports in HD to approximately 45 million concurrent viewers. This milestone demonstrates the CloudFront massive scale, powered by 750+ edge locations across 440+ cities globally and 1,140+ embedded PoPs within 100+ ISPs, with the latest generation delivering 3x the performance of previous versions.

Upcoming AWS events
Check your calendars so that you can sign up for these upcoming events:

AWS Builder Loft – A community tech space in San Francisco where you can learn from expert sessions, join hands-on workshops, explore AI and emerging technologies, and collaborate with other builders to accelerate your ideas. Browse the upcoming sessions and join the events that interest you.
AWS Community Days – Join community-led conferences that feature technical discussions, workshops, and hands-on labs led by experienced AWS users and industry leaders from around the world. I will deliver the opening keynote at the last Community Day of the year in Kinshasa, Democratic Republic of Congo (November 22). The next Community Day will be in Timişoara, România (April 2026). The call for papers is now open.
AWS Skills Center Seattle 4th Anniversary Celebration – A free, public event on November 20 with a keynote, learned panels, recruiter insights, raffles, and virtual participation options.

Join the AWS Builder Center to learn, build, and connect with builders in the AWS community. Browse here for upcoming in-person events, developer-focused events, and events for startups.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— seb

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

Introducing Amazon EBS Volume Clones: Create instant copies of your EBS volumes

2025-10-15 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/introducing-amazon-ebs-volume-clones-create-instant-copies-of-your-ebs-volumes/

As someone that used to work at Sun Microsystems, where ZFS was invented, I’ve always loved working with storage systems that offer instant volume copies for my development and testing needs.

Today, I’m excited to share that AWS is bringing similar capabilities to Amazon Elastic Block Store (Amazon EBS) with the launch of Amazon EBS Volume Clones, a new capability that lets you create instant point-in-time copies of your EBS volumes within the same Availability Zone.

Many customers need to create copies of their production data to support development and testing activities in a separate nonproduction environment. Until now, this process required taking an EBS snapshot (stored in Amazon Simple Storage Service (Amazon S3)) and then creating a new volume from that snapshot. Although this approach works, the process creates operational overhead due to multiple steps.

With Amazon EBS Volume Clones, you can now create copies of your EBS volumes with a single API call or console click. The copied volumes are available within seconds and provide immediate access to your data with single-digit millisecond latency. This makes Volume Clones particularly useful for quickly setting up test environments with production data or creating temporary copies of databases for development purposes.

Let me show you how Volume Clones works
For this post, I created a small Amazon Elastic Compute Cloud (Amazon EC2) instance, with an attached volume. I created a file on the root file system with the command echo "Hello CopyVolumes" > hello.txt.

To initiate the copy, I open a browser on the AWS Management Console and I navigate to EC2, Elastic Block Store, Volumes. I select the volume I want to copy.

Note that, at the time of publication of this post, only encrypted volumes can be copied.

On the Actions menu, I choose the Copy Volume option.

Next, I choose the details of the target volume. I can change the Volume type and adjust the Size, IOPS, and Throughput parameters. I choose Copy volume to start the Volume Clone operation.

The copied volume enters the Creating state and becomes available within seconds. I can then attach it to an EC2 instance and start using it immediately.

Data blocks are copied from the source volume and written to the volume copy in the background. The volume remains in the Initializing state until the process is complete. I can monitor its progress with the describe-volume-status API. The initializing operation doesn’t affect the performance of the source volume. I can continue using it normally during the copy process.

I love that the copied volume is available immediately. I don’t need to wait for its initialization to complete. During the initialization phase, my copied volume delivers performance based on the lowest of: a baseline of 3,000 IOPS and 125 MiB/s, the source volume’s provisioned performance, or the copied volume’s provisioned performance.

After initialization is completed, the copied volume becomes fully independent of the source volume and delivers its full provisioned performance.

Alternatively, I can use the AWS Command Line Interface (AWS CLI) to initiate the copy:

aws ec2 copy-volumes                          \
     --source-volume-id vol-1234567890abcdef0 \
     --size 500                               \
     --volume-type gp3

After the volume copy is created, I attach it to my EC2 instance and mount it. I can check the file I created at start is present.

First, I attach the volume from my laptop, using the attach-volume command:

aws ec2 attach-volume \
         --volume-id 'vol-09b700e3a23a9b4ad' \
         --instance-id 'i-079e6504ad25b029e'   \
         --device '/dev/sdb'

Then, I connect to the instance, and I type these commands:

$ sudo lsblk -f
NAME          FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1                                                                              
├─nvme0n1p1   xfs          /     49e26d9d-0a9d-4667-b93e-a23d1de8eacd    6.2G    22% /
└─nvme0n1p128 vfat   FAT16       3105-2F44                               8.6M    14% /boot/efi
nvme1n1                                                                              
├─nvme1n1p1   xfs          /     49e26d9d-0a9d-4667-b93e-a23d1de8eacd                
└─nvme1n1p128 vfat   FAT16       3105-2F44     

$ sudo mount -t xfs /dev/nvme1n1p1 /data

$ df -h
Filesystem        Size  Used Avail Use% Mounted on
devtmpfs          4.0M     0  4.0M   0% /dev
tmpfs             924M     0  924M   0% /dev/shm
tmpfs             370M  476K  369M   1% /run
/dev/nvme0n1p1    8.0G  1.8G  6.2G  22% /
tmpfs             924M     0  924M   0% /tmp
/dev/nvme0n1p128   10M  1.4M  8.7M  14% /boot/efi
tmpfs             185M     0  185M   0% /run/user/1000
/dev/nvme1n1p1    8.0G  1.8G  6.2G  22% /data

$ cat /data/home/ec2-user/hello.txt 
Hello CopyVolumes

Things to know
Volume Clones creates copies within the same Availability Zone as your source volume. You can create copies from encrypted volumes only, and the size of your copy must be equal to or greater than the source volume.

Volume Clones creates crash-consistent copies of your volumes, exactly like snapshots. For application consistency, you need to pause application I/O operations before creating the copy. For example, with PostgreSQL databases, you can use the pg_start_backup() and pg_stop_backup() functions to pause writes and create a consistent copy. At the operating system level on Linux with XFS, you can use the xfs_freeze command to temporarily suspend and resume access to the file system and ensure all cached updates are written to disk.

Although Volume Clones creates point-in-time copies, it complements rather than replaces EBS snapshots for backup purposes. EBS snapshots remain the recommended solution for data backup and protection against AZ-level and volume failures. Snapshots provide incremental backups to Amazon S3 with 11 nines of durability, compared to Volume Clones which maintains EBS volume durability (99.999% for io2, 99.9% for other volume types). Consider using Volume Clones specifically for test and development environment scenarios where you need instant access to volume copies.

Copied volumes exist independently of their source volumes and continue to incur standard EBS volume charges until you delete them. To manage costs effectively, implement governance rules to identify and remove copied volumes that are no longer needed for your development or testing activities.

Pricing and availability
Volume Clones supports all EBS volume types and works with volumes in the same AWS account and Availability Zone. This new capability is available in all AWS commercial Regions, selected Local Zones, and in the AWS GovCloud (US).

For pricing, you’re charged a one-time fee per GiB of data on the source volume at initiation and standard EBS pricing for the new volume.

I find Volume Clones particularly valuable for database workloads and continuous integration (CI) scenarios. For instance, you can quickly create a copy of your production database for testing new features or troubleshooting issues without impacting your production environment or waiting for data to hydrate from Amazon S3.

To get started with Amazon EBS Volume Clones, visit the Amazon EBS section on the console or check out the EBS documentation. I look forward to hearing how you use this capability to improve your development workflows.

— seb

AWS IAM Identity Center now supports customer-managed KMS keys for encryption at rest

2025-10-06 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-iam-identity-center-now-supports-customer-managed-kms-keys-for-encryption-at-rest/

Starting today, you can use your own AWS Key Management Service (AWS KMS) keys to encrypt identity data, such as user and group attributes, stored in AWS IAM Identity Center organization instances.

Many organizations operating in regulated industries need complete control over encryption key management. While Identity Center already encrypts data at rest using AWS-owned keys, some customers require the ability to manage their own encryption keys for audit and compliance purposes.

With this launch, you can now use customer-managed KMS keys (CMKs) to encrypt Identity Center identity data at rest. CMKs provide you with full control over the key lifecycle, including creation, rotation, and deletion. You can configure granular access controls to keys with AWS Key Management Service (AWS KMS) key policies and IAM policies, helping to ensure that only authorized principals can access your encrypted data. At launch time, the CMK must reside in the same AWS account and Region as your IAM Identity Center instance. The integration between Identity Center and KMS provides detailed AWS CloudTrail logs for auditing key usage and helps meet regulatory compliance requirements.

Identity Center supports both single-Region and multi-Region keys to match your deployment needs. While Identity Center instances can currently only be deployed in a single Region, we recommend using multi-Region AWS KMS keys unless your company policies restrict you to single-Region keys. Multi-Region keys provide consistent key material across Regions while maintaining independent key infrastructure in each Region. This gives you more flexibility in your encryption strategy and helps future-proof your deployment.

Let’s get started
Let’s imagine I want to use a CMK to encrypt the identity data of my Identity Center organization instance. My organization uses Identity Center to give employees access to AWS managed applications, such as Amazon Q Business or Amazon Athena.

As of today, some AWS managed applications cannot be used with Identity Center configured with a customer managed KMS key. See AWS managed applications that you can use with Identity Center to keep you updated with the ever evolving list of compatible applications.

The high-level process requires first to create a symmetric customer managed key (CMK) in AWS KMS. The key must be configured for encrypt and decrypt operations. Next, I configure the key policies to grant access to Identity Center, AWS managed applications, administrators, and other principals who need access the Identity Center and IAM Identity Center service APIs. Depending on your usage of Identity Center, you’ll have to define different policies for the key and IAM policies for IAM principals. The service documentation has more details to help you cover the most common use cases.

This demo is in three parts. I first create a customer managed key in AWS KMS and configure it with permissions that will authorize Identity Center and AWS managed applications to use it. Second, I update the IAM policies for the principals that will use the key from another AWS account, such as AWS applications administrators. Finally, I configure Identity Center to use the key.

Part 1: Create the key and define permissions

First, let’s create a new CMK in AWS KMS.

The key must be in the same AWS Region and AWS account as the Identity Center instance. You must create the Identity Center instance and the key in the management account of your organization within AWS Organization.

I navigate to the AWS Key Management Service (AWS KMS) console in the same Region as my Identity Center instance, then I choose Create a key. This launches me into the key creation wizard.

Under Step 1–Configure key, I select the key type–either Symmetric (a single key used for both encryption and decryption) or Asymmetric (a public-private key pair for encryption/decryption and signing/verification). Identity Center requires symmetric keys for encryption at rest. I select Symmetric.

For key usage, I select Encrypt and decrypt which allows the key to be used only for encrypting and decrypting data.

Under Advanced options, I select KMS – recommended for Key material origin, so AWS KMS creates and manages the key material.

For Regionality, I choose between Single-Region or Multi-Region key. I select Multi-Region key to allow key administrators to replicate the key to other Regions. As explained already, Identity Center doesn’t require this today but it helps to future-proof your configuration. Remember that you can not transform a single-Region key to a multi-Region one after its creation (but you can change the key used by Identity Center).

Then, I choose Next to proceed with additional configuration steps, such as adding labels, defining administrative permissions, setting usage permissions, and reviewing the final configuration before creating the key.

Under Step 2–Add Labels, I enter an Alias name for my key and select Next.

In this demo, I am editing the key policy by adding policy statements using templates provided in the documentation. I skip Step 3 and Step 4 and navigate to Step 5–Edit key policy.

Identity Center requires, at the minimum, permissions allowing Identity Center and its administrators to use the key. Therefore, I add three policy statements, the first and second authorize the administrators of the service, the third one to authorize the Identity Center service itself.

{
	"Version": "2012-10-17",
	"Id": "key-consolepolicy-3",
	"Statement": [
		{
			"Sid": "Allow_IAMIdentityCenter_Admin_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore",
			"Effect": "Allow",
			"Principal": {
				"AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE"
			},
			"Action": [
				"kms:Decrypt",
				"kms:Encrypt",
				"kms:GenerateDataKeyWithoutPlaintext"
			],
			"Resource": "*",
			"Condition": {
				"StringLike": {
					"kms:ViaService": [
						"sso.*.amazonaws.com",
						"identitystore.*.amazonaws.com"
					]
				}
			}
		},
		{
			"Sid": "Allow_IdentityCenter_admin_to_describe_the_KMS_key",
			"Effect": "Allow",
			"Principal": {
				"AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE"
			},
			"Action": "kms:DescribeKey",
			"Resource": "*"
		},
		{
			"Sid": "Allow_IdentityCenter_and_IdentityStore_to_use_the_KMS_key",
			"Effect": "Allow",
			"Principal": {
				"Service": [
					"sso.amazonaws.com",
					"identitystore.amazonaws.com"
				]
			},
			"Action": [
				"kms:Decrypt",
				"kms:ReEncryptTo",
				"kms:ReEncryptFrom",
				"kms:GenerateDataKeyWithoutPlaintext"
			],
			"Resource": "*",
            "Condition": {
    	       "StringEquals": { 
                      "aws:SourceAccount": "<Identity Center Account ID>" 
	           }
            }		
		},
		{
			"Sid": "Allow_IdentityCenter_and_IdentityStore_to_describe_the_KMS_key",
			"Effect": "Allow",
			"Principal": {
				"Service": [
					"sso.amazonaws.com",
					"identitystore.amazonaws.com"
				]
			},
			"Action": [
				"kms:DescribeKey"
			],
			"Resource": "*"
		}		
	]
}

I also have to add additional policy statements to allow my use case: the use of AWS managed applications. I add these two policy statements to authorize AWS managed applications and their administrators to use the KMS key. The document lists additional use cases and their respective policies.

{
    "Sid": "Allow_AWS_app_admins_in_the_same_AWS_organization_to_use_the_KMS_key",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
        "kms:Decrypt"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals" : {
           "aws:PrincipalOrgID": "MY_ORG_ID (format: o-xxxxxxxx)"
        },
        "StringLike": {
            "kms:ViaService": [
                "sso.*.amazonaws.com", "identitystore.*.amazonaws.com"
            ]
        }
    }
},
{
   "Sid": "Allow_managed_apps_to_use_the_KMS_Key",
   "Effect": "Allow",
   "Principal": "*",
   "Action": [
      "kms:Decrypt"
    ],
   "Resource": "*",
   "Condition": {
      "Bool": { "aws:PrincipalIsAWSService": "true" },
      "StringLike": {
         "kms:ViaService": [
             "sso.*.amazonaws.com", "identitystore.*.amazonaws.com"
         ]
      },
      "StringEquals": { "aws:SourceOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" }
   }
}

You can further restrict the key usage to a specific Identity Center instance, specific application instances, or specific application administrators. The documentation contains examples of advanced key policies for your use cases.

To help protect against IAM role name changes when permission sets are recreated, use the approach described in the Custom trust policy example.

Part 2: Update IAM policies to allow use of the KMS key from another AWS account

Any IAM principal that uses the Identity Center service APIs from another AWS account, such as Identity Center delegated administrators and AWS application administrators, need an IAM policy statement that allows use of the KMS key via these APIs.

I grant permissions to access the key by creating a new policy and attaching the policy to the IAM role relevant for my use case. You can also add these statements to the existing identity-based policies of the IAM role.

To do so, after the key is created, I locate its ARN and replace the key_ARNin the template below. Then, I attach the policy to the managed application administrator IAM principal. The documentation also covers IAM policies that grants Identity Center delegated administrators permissions to access the key.

Here is an example for managed application administrators:

{
      "Sid": "Allow_app_admins_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore",
      "Effect": "Allow",
      "Action": 
        "kms:Decrypt",
      "Resource": "<key_ARN>",
      "Condition": {
        "StringLike": {
          "kms:ViaService": [
            "sso.*.amazonaws.com",
            "identitystore.*.amazonaws.com"
          ]
        }
      }
    }

The documentation shares IAM policies template for the most common use cases.

Part 3: Configure IAM Identity Center to use the key

I can configure a CMK either during the enablement of an Identity Center organization instance or on an existing instance, and I can change the encryption configuration at any time by switching between CMKs or reverting to AWS-owned keys.

Please note that an incorrect configuration of KMS key permissions can disrupt Identity Center operations and access to AWS managed applications and accounts through Identity Center. Proceed carefully to this final step and ensure you have read and understood the documentation.

After I have created and configured my CMK, I can select it under Advanced configuration when enabling Identity Center.

To configure a CMK on an existing Identity Center instance using the AWS Management Console, I start by navigating to the Identity Center section of the AWS Management Console. From there, I select Settings from the navigation pane, then I select the Management tab, and select Manage encryption in the Key for encrypting IAM Identity Center data at rest section.

At any time, I can select another CMK from the same AWS Account, or switch back to an AWS-managed key.

After choosing Save, the key change process takes a few seconds to complete. All service functionalities continue uninterrupted during the transition. If, for whatever reasons, Identity Center can not access the new key, an error message will be returned and Identity Center will continue to use the current key, keeping your identity data encrypted with the mechanism it is already encrypted with.

Things to keep in mind
The encryption key you create becomes a crucial component of your Identity Center. When you choose to use your own managed key to encrypt identity attributes at rest, you have to verify the following points.

Have you configured the necessary permissions to use the KMS key? Without proper permissions, enabling the CMK may fail or disrupt IAM Identity Center administration and AWS managed applications.
Have you verified that your AWS managed applications are compatible with CMK keys? For a list of compatible applications, see AWS managed applications that you can use with IAM Identity Center. Enabling CMK for Identity Center that is used by AWS managed applications incompatible with CMK will result in operational disruption for those applications. If you have incompatible applications, do not proceed.
Is your organization using AWS managed applications that require additional IAM role configuration to use the Identity Center and Identity Store APIs? For each such AWS managed application that’s already deployed, check the managed application’s User Guide for updated KMS key permissions for IAM Identity Centre usage and update them as instructed to prevent application disruption.

For brevity, the KMS key policy statements in this post omit the encryption context, which allows you to restrict the use of the KMS key to Identity Center including a specific instance. For your production scenarios, you can add a condition like this for Identity Center:

"Condition": {
   "StringLike": {
      "kms:EncryptionContext:aws:sso:instance-arn": "${identity_center_arn}",
      "kms:ViaService": "sso.*.amazonaws.com"
    }
}

or this for Identity Store:

"Condition": {
   "StringLike": {
      "kms:EncryptionContext:aws:identitystore:identitystore-arn": "${identity_store_arn}",
      "kms:ViaService": "identitystore.*.amazonaws.com"
    }
}

Pricing and availability
Standard AWS KMS charges apply for key storage and API usage. Identity Center remains available at no additional cost.

This capability is now available in all AWS commercial Regions, AWS GovCloud (US), and AWS China Regions. To learn more, visit the IAM Identity Center User Guide.

We look forward to learning how you use this new capability to meet your security and compliance requirements.

— seb

Announcing Amazon EC2 M4 and M4 Pro Mac instances

2025-09-12 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/announcing-amazon-ec2-m4-and-m4-pro-mac-instances/

As someone who has been using macOS since 2001 and Amazon EC2 Mac instances since their launch 4 years ago, I’ve helped numerous customers scale their continuous integration and delivery (CI/CD) pipelines on AWS. Today, I’m excited to share that Amazon EC2 M4 and M4 Pro Mac instances are now generally available.

Development teams building applications for Apple platforms need powerful computing resources to handle complex build processes and run multiple iOS simulators simultaneously. As development projects grow larger and more sophisticated, teams require increased performance and memory capacity to maintain rapid development cycles.

Apple M4 Mac mini at the core
EC2 M4 Mac instances (known as mac-m4.metal in the API) are built on Apple M4 Mac mini computers and are built on the AWS Nitro System. They feature Apple silicon M4 chips with 10-core CPU (four performance and six efficiency cores), 10-core GPU, 16-core Neural Engine, and 24 GB unified memory, delivering enhanced performance for iOS and macOS application build workloads. When building and testing applications, M4 Mac instances deliver up to 20 percent better application build performance compared to EC2 M2 Mac instances.

EC2 M4 Pro Mac (mac-m4pro.metal in the API) instances are powered by Apple silicon M4 Pro chips with 14-core CPU, 20-core GPU, 16-core Neural Engine, and 48 GB unified memory. These instances offer up to 15 percent better application build performance compared to EC2 M2 Pro Mac instances. The increased memory and computing power make it possible to run more tests in parallel using multiple device simulators.

Each M4 and M4 Pro Mac instance now comes with 2 TB of local storage, providing low-latency storage for improved caching and build and test performance.

Both instance types support macOS Sonoma version 15.6 and later as Amazon Machine Images (AMIs). The AWS Nitro System provides up to 10 Gbps of Amazon Virtual Private Cloud (Amazon VPC) network bandwidth and 8 Gbps of Amazon Elastic Block Store (Amazon EBS) storage bandwidth through high-speed Thunderbolt connections.

Amazon EC2 Mac instances integrate seamlessly with AWS services, which means you can:

Build automated CI/CD pipelines using AWS CodeBuild and AWS CodePipeline
Store and manage multiple versions of your build secrets, such as Apple development certificates and keys, on AWS Secrets Manager
Manage your development infrastructure using AWS CloudFormation
Monitor instance performance with Amazon CloudWatch

Let me show you how to get started
You can launch an EC2 M4 or M4 Pro Mac instances through the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDKs.

For this demo, let’s start an M4 Pro instance from the console. I first allocate a dedicated host to run my instances. On the AWS Management Console, I navigate to EC2, then Dedicated Hosts, and I select Allocate Dedicated Host.

Then, I enter a Name tag and I select the Instance family (mac-m4pro) and an Instance type (mac-m4pro.metal). I choose one Availability Zone and I clear Host maintenance.

Alternatively, I can use the command line interface:

aws ec2 allocate-hosts                          \
        --availability-zone-id "usw2-az4"       \
        --auto-placement "off"                  \
        --host-recovery "off"                   \
        --host-maintenance "off"                \
        --quantity 1                            \
        --instance-type "mac-m4pro.metal"

After the dedicated host is allocated to my account, I select the host I just allocated, then I select the Actions menu and choose Launch instance(s) onto host.

Notice the console gives you, among other information, the Latest supported macOS versions for this type of host. In this case, it’s macOS 15.6.

On the Launch an instance page, I enter a Name. I select a macOS Sequoia Amazon Machine Image (AMI). I make sure the Architecture is 64-bit Arm and the Instance type is mac-m4pro.metal.

The rest of the parameters arn’t specific to Amazon EC2 Mac: the network and storage configuration. When starting an instance for development use, make sure you select a volume with minimum 200 Gb or more. The default 100 Gb volume size isn’t sufficient to download and install Xcode.

When ready, I select the Launch instance orange button on the bottom of the page. The instance will rapidly appear as Running in the console. However, it might take up to 15 minutes to allow you to connect over SSH.

Alternatively, I can use this command:

aws ec2 run-instances \
    --image-id "ami-000420887c24e4ac8"  \ # AMI ID depends on the region !
    --instance-type "mac-m4pro.metal"   \
    --key-name "my-ssh-key-name"        \
    --network-interfaces '{"AssociatePublicIpAddress":true,"DeviceIndex":0,"Groups":["sg-0c2f1a3e01b84f3a3"]}' \ # Security Group ID depends on your config
    --tag-specifications '{"ResourceType":"instance","Tags":[{"Key":"Name","Value":"My Dev Server"}]}' \
    --placement '{"HostId":"h-0e984064522b4b60b","Tenancy":"host"}' \ # Host ID depends on your config 
    --private-dns-name-options '{"HostnameType":"ip-name","EnableResourceNameDnsARecord":true,"EnableResourceNameDnsAAAARecord":false}' \
    --count "1"

Install Xcode from the Terminal
After the instance is reachable, I can connect using SSH to it and install my development tools. I use xcodeinstall to download and install Xcode 16.4.

From my laptop, I open a session with my Apple developer credentials:

# on my laptop, with permissions to access AWS Secret Manager
» xcodeinstall authenticate -s eu-central-1                                                                                               

Retrieving Apple Developer Portal credentials...
Authenticating...
🔐 Two factors authentication is enabled, enter your 2FA code: 067785
✅ Authenticated with MFA.

I connect to the EC2 Mac instance I just launched. Then, I download and install Xcode:

» ssh [email protected]                                                                                                                                                                   

Warning: Permanently added '44.234.115.119' (ED25519) to the list of known hosts.
Last login: Sat Aug 23 13:49:55 2025 from 81.49.207.77

    ┌───┬──┐   __|  __|_  )
    │ ╷╭╯╷ │   _|  (     /
    │  └╮  │  ___|\___|___|
    │ ╰─┼╯ │  Amazon EC2
    └───┴──┘  macOS Sequoia 15.6

ec2-user@ip-172-31-54-74 ~ % brew tap sebsto/macos
==> Tapping sebsto/macos
Cloning into '/opt/homebrew/Library/Taps/sebsto/homebrew-macos'...
remote: Enumerating objects: 227, done.
remote: Counting objects: 100% (71/71), done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 227 (delta 22), reused 63 (delta 14), pack-reused 156 (from 1)
Receiving objects: 100% (227/227), 37.93 KiB | 7.59 MiB/s, done.
Resolving deltas: 100% (72/72), done.
Tapped 1 formula (13 files, 61KB).

ec2-user@ip-172-31-54-74 ~ % brew install xcodeinstall 
==> Fetching downloads for: xcodeinstall
==> Fetching sebsto/macos/xcodeinstall
==> Downloading https://github.com/sebsto/xcodeinstall/releases/download/v0.12.0/xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz
Already downloaded: /Users/ec2-user/Library/Caches/Homebrew/downloads/9f68a7a50ccfdc479c33074716fd654b8528be0ec2430c87bc2b2fa0c36abb2d--xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz
==> Installing xcodeinstall from sebsto/macos
==> Pouring xcodeinstall-0.12.0.arm64_sequoia.bottle.tar.gz
🍺  /opt/homebrew/Cellar/xcodeinstall/0.12.0: 8 files, 55.2MB
==> Running `brew cleanup xcodeinstall`...
Disable this behaviour by setting `HOMEBREW_NO_INSTALL_CLEANUP=1`.
Hide these hints with `HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
==> No outdated dependents to upgrade!

ec2-user@ip-172-31-54-74 ~ % xcodeinstall download -s eu-central-1 -f -n "Xcode 16.4.xip"
                        Downloading Xcode 16.4
100% [============================================================] 2895 MB / 180.59 MBs
[ OK ]
✅ Xcode 16.4.xip downloaded

ec2-user@ip-172-31-54-74 ~ % xcodeinstall install -n "Xcode 16.4.xip"
Installing...
[1/6] Expanding Xcode xip (this might take a while)
[2/6] Moving Xcode to /Applications
[3/6] Installing additional packages... XcodeSystemResources.pkg
[4/6] Installing additional packages... CoreTypes.pkg
[5/6] Installing additional packages... MobileDevice.pkg
[6/6] Installing additional packages... MobileDeviceDevelopment.pkg
[ OK ]
✅ file:///Users/ec2-user/.xcodeinstall/download/Xcode%2016.4.xip installed

ec2-user@ip-172-31-54-74 ~ % sudo xcodebuild -license accept

ec2-user@ip-172-31-54-74 ~ %

Things to know
Select an EBS volume with minimum 200 Gb for development purposes. The 100 Gb default volume size is not sufficient to install Xcode. I usually select 500 Gb. When you increase the EBS volume size after the launch of the instance, remember to resize the APFS filesystem.

Alternatively, you can choose to install your development tools and framework on the low-latency local 2 Tb SSD drive available in the Mac mini. Pay attention that the content of that volume is bound to the instance lifecycle, not the dedicated host. This means that everything will be deleted from the internal SSD storage when you stop and restart the instance.

Themac-m4.metal and mac-m4pro.metal instances support macOS Sequoia 15.6 and later.

You can migrate your existing EC2 Mac instances when the migrated instance runs macOS 15 (Sequoia). Create a custom AMI from your existing instance and start an M4 or M4 Pro instance from this AMI.

Finally, I suggest checking the tutorials I wrote to help you to get started with Amazon EC2 Mac:

Start an Amazon EC2 Mac instance
Connect to an Amazon EC2 Mac instance (I show you three different methods to connect)
Build your applications faster with a CI/CD pipeline on Amazon EC2 Mac

Pricing and availability
EC2 M4 and M4 Pro Mac instances are currently available in US East (N. Virginia) and US West (Oregon), with additional Regions planned for the future.

Amazon EC2 Mac instances are available for purchase as Dedicated Hosts through the On-Demand and Savings Plans pricing models. Billing for EC2 Mac instances is per second with a 24-hour minimum allocation period to comply with the Apple macOS Software License Agreement. At the end of the 24-hour minimum allocation period, the host can be released at any time with no further commitment

As someone who works closely with Apple developers, I’m curious to see how you’ll use these new instances to accelerate your development cycles. The combination of increased performance, enhanced memory capacity, and integration with AWS services opens new possibilities for teams building applications for iOS, macOS, iPadOS, tvOS, watchOS, and visionOS platforms. Beyond application development, Apple silicon’s Neural Engine makes these instances cost-effective candidates for running machine learning (ML) inference workloads. I’ll be discussing this topic in detail at AWS re:Invent 2025, where I’ll share benchmarks and best practices for optimizing ML workloads on EC2 Mac instances.

To learn more about EC2 M4 and M4 Pro Mac instances, visit the Amazon EC2 Mac Instances page or refer to the EC2 Mac documentation. You can start using these instances today to modernize your Apple development workflows on AWS.

— seb

AWS Weekly Roundup: Amazon EC2, Amazon Q Developer, IPv6 updates, and more (September 1, 2025)

2025-09-01 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-amazon-ec2-amazon-q-developer-ipv6-updates-and-more-september-1-2025/

My LinkedIn feed was absolutely packed this week with pictures from the AWS Heroes Summit event in Seattle. It was heartwarming to see so many familiar faces and new Heroes coming together.

AWS Heroes Summit 2025

For those not familiar with the AWS Heroes program, it’s a global community recognition initiative that honors individuals who make outstanding contributions to the AWS community. These Heroes share their deep AWS knowledge through content creation, speaking at events, organizing community gatherings, and contributing to open-source projects.

The AWS Heroes Summit brings these exceptional community leaders together, providing a unique platform for knowledge exchange, networking, and collaboration. As someone who regularly interacts with Heroes through our AWS initiatives, I always find these summits invaluable – they offer deep technical discussions, early access to AWS roadmaps, and opportunities to provide direct feedback to AWS service teams. The insights and connections made at these events often translate into better resources and guidance for the broader AWS community.

Last week’s launches

In addition to this inspiring community, here are some AWS launches that caught my attention:

AWS expands Internet Protocol v6 (IPv6) support to AWS App Runner, AWS Client VPN, and RDS Data API — Three more AWS services now support IPv6 connectivity, helping you meet compliance requirements and removes the need for handling address translation between IPv4 and IPv6. AWS App Runner now supports IPv6-based inbound and outbound traffic on both public and private App Runner service endpoints. AWS Client VPN announced support for remote access to IPv6 workloads, allowing you to establish secure VPN connections to your IPv6-enabled VPC resources. Finally, RDS Data API now supports IPv6, enabling dual-stack configuration (IPv4 and IPv6) connectivity for your Aurora databases.
We launched two new instance families this week: the new storage-optimized I8ge and the general-purpose M8i instances —Our I8ge instances, powered by AWS Graviton4 processors, deliver up to 60% better compute performance compared to their Graviton2-based predecessors. These instances feature third-generation AWS Nitro SSDs, providing up to 55% better real-time storage performance per TB and significantly lower I/O latency. With 120 TB of storage and sizes up to 48xlarge (including two metal options), they offer the highest storage density among AWS Graviton-based storage optimized instances. We also launched M8i and M8i-flex instances with custom Intel Xeon 6 processors. These instances deliver up to 15% better price-performance and 2.5x more memory bandwidth than their predecessors. M8i-flex instances are ideal for general-purpose workloads, available from large to 16xlarge. For demanding applications, you can choose from our SAP-certified M8i instances in 13 sizes, including 2 bare metal options and a new 96xlarge size.
Amazon EC2 Mac Dedicated hosts now support Host Recovery and Reboot-based host maintenance — you can enable two new capabilities for your EC2 Mac Dedicated Hosts: Host Recovery and Reboot-based Host Maintenance. Host Recovery automatically detects potential hardware issues on Mac Dedicated Hosts and seamlessly migrates Mac instances to a new replacement host, minimizing disruption to workloads. Reboot-based Host Maintenance automatically stops and restarts instances on replacement hosts when scheduled maintenance events occur, eliminating the need for manual intervention during planned maintenance windows.
Amazon Q Developer now supports MCP admin control — Administrators have now the ability to enable or disable the MCP functionality for all the Q Developer clients in their organization. When an administrator disables the functionality, users will not be allowed to add any MCP servers, nor will any previously defined servers be initialized.

Other AWS news

Here are some additional projects and blog posts that you might find interesting:

Mastering Amazon Q Developer with Rules — I read an interesting article about Amazon Q Developer’s rules feature this weekend that I want to share with you. What caught my attention is how it solves a pain point I often encounter when working with AI assistants – having to repeatedly explain my coding preferences and standards. With rules, you define your preferences once in Markdown files, and Amazon Q Developer automatically follows them for every interaction. I particularly like how transparent the system is, showing which rules it’s following, and how it helps maintain consistency across teams. Since implementing rules in my projects, I’ve seen more consistent code quality, all while reducing the cognitive load of having to repeatedly explain our standards.
Strategies for excelling across all four exam domains of the AWS Certified Machine Learning – Specialty certification. The AWS Training & Certification team, where I spent my first three years at AWS, shared how to prepare for the AWS Certified Machine Learning – Specialty certification, whether you’re starting from scratch or building upon existing AWS Certifications. They share the prerequisites and guidance to help you get ready for this certification and demonstrate your expertise in building ML solutions with AWS.
As is now our tradition after Prime Day, we shared the impressive metrics showing how AWS services scaled to support one of the world’s largest shopping events. Amazon Prime Day 2025 was the biggest ever, setting records for both sales volume and total items sold during the 4-day event. This year was particularly special as we saw a significant transformation in the Prime Day experience through advancements in our generative AI offerings, with customers using Alexa+, Rufus, and AI Shopping Guides to discover deals and get product information. The numbers are staggering – Amazon DynamoDB handled tens of trillions of API calls while maintaining high availability, delivering single-digit millisecond responses and peaking at 151 million requests per second. Amazon API Gateway processed over 1 trillion internal service requests—a 30 percent increase in requests on average per day compared to Prime Day 2024.

Upcoming AWS events
Check your calendars and sign up for these upcoming AWS events:

AWS Summits — Join free online and in-person events that bring the cloud computing community together to connect, collaborate, and learn about AWS. Register in your nearest city: Toronto (September 4), Los Angeles (September 17), and Bogotá (October 9).
AWS re:Invent 2025 — This flagship annual conference is coming to Las Vegas from December 1–5. The event catalog is now available. Mark your calendars for this not to be missed gathering of the AWS community.
AWS Community Days — Join community-led conferences that feature technical discussions, workshops, and hands-on labs led by expert AWS users and industry leaders from around the world: Adria (September 5), Baltic (September 10), Aotearoa (September 18), South Africa (September 20), Bolivia (September 20), Portugal (September 27).

Join the AWS Builder Center to learn, build, and connect with builders in the AWS community. Browse here for upcoming in-person and virtual developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— seb

Celebrating 10 years of Amazon Aurora innovation

2025-08-15 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/celebrating-10-years-of-amazon-aurora-innovation/

Ten years ago, we announced the general availability of Amazon Aurora, a database that combined the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.

As Jeff described it in its launch blog post: “With storage replicated both within and across three Availability Zones, along with an update model driven by quorum writes, Amazon Aurora is designed to deliver high performance and 99.99% availability while easily and efficiently scaling to up to 64 TiB of storage.”

When we started developing Aurora over a decade ago, we made a fundamental architectural decision that would change the database landscape forever: we decoupled storage from compute. This novel approach enabled Aurora to deliver the performance and availability of commercial databases at one-tenth the cost.

This is one of the reasons why hundreds of thousands of AWS customers choose Aurora as their relational database.

Today, I’m excited to invite you to join us for a livestream event on August 21, 2025, to celebrate a decade of Aurora database innovation.

A brief look back at the past
Throughout the evolution of Aurora, we’ve focused on four core innovation themes: security as our top priority, scalability to meet growing workloads, predictable pricing for better cost management, and multi-Region capabilities for global applications. Let me walk you through some key milestones in the Aurora journey.

We previewed Aurora at re:Invent 2014, and made it generally available in July 2015. At launch, we presented Aurora as “a new cost-effective MySQL-compatible database engine.”

In June 2016, we introduced reader endpoints and cross-Region read replicas, followed by AWS Lambda integration and the ability to load tables directly from Amazon S3 in October. We added database cloning and export to Amazon S3 capabilities in June 2017 and full compatibility with PostgreSQL in October that year.

The journey continued with the serverless preview in November 2017, which became generally available in August 2018. Global Database launched in November 2018 for cross-Region disaster recovery. We introduced blue/green deployments to simplify database updates, and optimized read instances to improve query performance.

In 2023, we added vector capabilities with pgvector for similarity search for Aurora PostgreSQL, and Aurora I/O-Optimized to provide predictable pricing with up to 40 percent cost savings for I/O-intensive applications. We launched Aurora zero-ETL integration with Amazon Redshift which enables near real-time analytics and ML using Amazon Redshift on petabytes of transactional data from Aurora by removing the need for you to build and maintain complex data pipelines that perform extract, transform, and load (ETL) operations. This year we added Aurora MySQL zero-ETL integration with Amazon Sagemaker, enabling near real-time access of your data in the lakehouse architecture of SageMaker to run a broad range of analytics.

In 2024, we made it as effortless as just one click to select Aurora PostgreSQL as a vector store for Amazon Bedrock Knowledge Bases and launched Aurora PostgreSQL Limitless Database, a serverless horizontal scaling (sharding) capability.

To simplify scaling for customers, we also increased the maximum storage to 128 TiB in September 2020, allowing many applications to operate within a single instance. Last month, we’ve further simplified scaling by doubling the maximum storage to 256 TiB, with no upfront provisioning required and pay-as-you-go pricing based on actual storage used. This enables even more customers to run their growing workloads without the complexity of managing multiple instances while maintaining cost efficiency.

Most recently, at re:Invent 2024, we announced Amazon Aurora DSQL, which became generally available in May 2025. Aurora DSQL represents our latest innovation in distributed SQL databases, offering active-active high availability and multi-Region strong consistency. It’s the fastest serverless distributed SQL database for always available applications, effortlessly scaling to meet any workload demand with zero infrastructure management.

Aurora DSQL builds on our original architectural principles of separation of storage and compute, taking them further with independent scaling of reads, writes, compute, and storage. It provides 99.99% single-Region and 99.999% multi-Region availability, with strong consistency across all Regional endpoints.

And in June, we launched Model Context Protocol (MCP) servers for Aurora, so you can integrate your AI agents with your data sources and services.

Let’s celebrate 10 years of innovation
By attending the August 21 livestream event, you’ll hear from Aurora technical leaders and founders, including Swami Sivasubramanian, Ganapathy (G2) Krishnamoorthy, Yan Leshinsky, Grant McAlister, and Raman Mittal. You’ll learn directly from the architects who pioneered the separation of compute and storage in cloud databases, with technical insights into Aurora architecture and scaling capabilities. You’ll also get a glimpse into the future of database technology as Aurora engineers share their vision and discuss the complex challenges they’re working to solve on behalf of customers.

The event also offers practical demonstrations that show you how to implement key features. You’ll see how to build AI-powered applications using pgvector, understand cost optimization with the new Aurora DSQL pricing model, and learn how to achieve multi-Region strong consistency for global applications.

The interactive format includes Q&A opportunities with Aurora experts, so you’ll be able to get your specific technical questions answered. You can also receive AWS credits to test new Aurora capabilities.

If you’re interested in agentic AI, you’ll particularly benefit from the sessions on MCP servers, Strands Agents, and how to integrate Strands Agents with Aurora DSQL, which demonstrate how to safely integrate AI capabilities with your Aurora databases while maintaining control over database access.

Whether you’re running mission-critical workloads or building new applications, these sessions will help you understand how to use the latest Aurora features.

To the next decade of Aurora innovation!

— seb

Introducing Amazon Application Recovery Controller Region switch: A multi-Region application recovery service

2025-08-01 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/introducing-amazon-application-recovery-controller-region-switch-a-multi-region-application-recovery-service/

As a developer advocate at AWS, I’ve worked with many enterprise organizations who operate critical applications across multiple AWS Regions. A key concern they often share is the lack of confidence in their Region failover strategy—whether it will work when needed, whether all dependencies have been identified, and whether their teams have practiced the procedures enough. Traditional approaches often leave them uncertain about their readiness for Regional switch.

Today, I’m excited to announce Amazon Application Recovery Controller (ARC) Region switch, a fully managed, highly available capability that enables organizations to plan, practice, and orchestrate Region switches with confidence, eliminating the uncertainty around cross-Region recovery operations. Region switch helps you orchestrate recovery for your multi-Region applications on AWS. It gives you a centralized solution to coordinate and automate recovery tasks across AWS services and accounts when you need to switch your application’s operations from one AWS Region to another.

Many customers deploy business-critical applications across multiple AWS Regions to meet their availability requirements. When an operational event impacts an application in one Region, switching operations to another Region involves coordinating multiple steps across different AWS services, such as compute, databases, and DNS. This coordination typically requires building and maintaining complex scripts that need regular testing and updates as applications evolve. Additionally, orchestrating and tracking the progress of Region switches across multiple applications and providing evidence of successful recovery for compliance purposes often involves manual data gathering.

Region switch is built on a Regional data plane architecture, where Region switch plans are executed from the Region being activated. This design eliminates dependencies on the impacted Region during the switch, providing a more resilient recovery process since the execution is independent of the Region you’re switching from.

Building a recovery plan with ARC Region switch
With ARC Region switch, you can create recovery plans that define the specific steps needed to switch your application between Regions. Each plan contains execution blocks that represent actions on AWS resources. At launch, Region switch supports nine types of execution blocks:

ARC Region switch plan execution block–let you orchestrate the order in which multiple applications switch to the Region you want to activate by referencing other Region switch plans.
Amazon EC2 Auto Scaling execution block–Scales Amazon EC2 compute resources in your target Region by matching a specified percentage of your source Region’s capacity.
ARC routing controls execution block–Changes routing control states to redirect traffic using DNS health checks.
Amazon Aurora global database execution block–Performs database failover with potential data loss or switchover with zero data loss for Aurora Global Database.
Manual approval execution block–Adds approval checkpoints in your recovery workflow where team members can review and approve before proceeding.
Custom Action AWS Lambda execution block–Adds custom recovery steps by executing Lambda functions in either the activating or deactivating Region.
Amazon Route 53 health check execution block–Let you to specify which Regions your application’s traffic will be redirected to during failover. When executing your Region switch plan, the Amazon Route 53 health check state is updated and traffic is redirected based on your DNS configuration.
Amazon Elastic Kubernetes Service (Amazon EKS) resource scaling execution block–Scales Kubernetes pods in your target Region during recovery by matching a specified percentage of your source Region’s capacity.
Amazon Elastic Container Service (Amazon ECS) resource scaling execution block–Scales ECS tasks in your target Region by matching a specified percentage of your source Region’s capacity.

Region switch continually validates your plans by checking resource configurations and AWS Identity and Access Management (IAM) permissions every 30 minutes. During execution, Region switch monitors the progress of each step and provides detailed logs. You can view execution status through the Region switch dashboard and at the bottom of the execution details page.

To help you balance cost and reliability, Region switch offers flexibility in how you prepare your standby resources. You can configure the desired percentage of compute capacity to target in your destination Region during recovery using Region switch scaling execution blocks. For critical applications expecting surge traffic during recovery, you might choose to scale beyond 100 percent capacity, and setting a lower percentage can help achieve faster overall execution times. However, it’s important to note that using one of the scaling execution blocks does not guarantee capacity, and actual resource availability depends on the capacity in the destination Region at the time of recovery. To facilitate the best possible outcomes, we recommend regularly testing your recovery plans and maintaining appropriate Service Quotas in your standby Regions.

ARC Region switch includes a global dashboard you can use to monitor the status of Region switch plans across your enterprise and Regions. Additionally, there’s a Regional executions dashboard that only displays executions within the current console Region. This dashboard is designed to be highly available across each Region so it can be used during operational events.

Region switch allows resources to be hosted in an account that is separate from the account that contains the Region switch plan. If the plan uses resources from an account that is different from the account that hosts the plan, then Region switch uses the executionRole to assume the crossAccountRole to access those resources. Additionally, Region switch plans can be centralized and shared across multiple accounts using AWS Resource Access Manager (AWS RAM), enabling efficient management of recovery plans across your organization.

Let’s see how it works
Let me show you how to create and execute a Region switch plan. There are three parts in this demo. First, I create a Region switch plan. Then, I define a workflow. Finally, I configure the triggers.

Step 1: Create a plan

I navigate to the Application Recovery Controller section of the AWS Management Console. I choose Region switch in the left navigation menu. Then, I choose Create Region switch plan.

After I give a name to my plan, I specify a Multi-Region recovery approach (active/passive or active/active). In Active/Passive mode, two application replicas are deployed into two Regions, with traffic routed into the active Region only. The replica in the passive Region can be activated by executing the Region switch plan.

Then, I select the Primary Region and Standby Region. Optionally, I can enter a Desired recovery time objective (RTO). The service will use this value to provide insight into how long Region switch plan executions take in relation to my desired RTO.

I enter the Plan execution IAM role. This is the role that allows Region switch to call AWS services during execution. I make sure the role I choose has permissions to be invoked by the service and contains the minimum set of permissions allowing ARC to operate. Refer to the IAM permissions section of the documentation for the details.

Step 2: Create a workflow

When the two Plan evaluation status notifications are green, I create a workflow. I choose Build workflows to get started.

Plans enable you to build specific workflows that will recover your applications using Region switch execution blocks. You can build workflows with execution blocks that run sequentially or in parallel to orchestrate the order in which multiple applications or resources recover into the activating Region. A plan is made up of these workflows that allow you to activate or deactivate a specific Region.

For this demo, I use the graphical editor to create the workflow. But you can also define the workflow in JSON. This format is better suited for automation or when you want to store your workflow definition in a source code management system (SCMS) and your infrastructure as code (IaC) tools, such as AWS CloudFormation.

I can alternate between the Design and the Code views by selecting the corresponding tab next to the Workflow builder title. The JSON view is read-only. I designed the workflow with the graphical editor and I copied the JSON equivalent to store it alongside my IaC project files.

Region switch launches an evaluation to validate your recovery strategy every 30 minutes. It regularly checks that all actions defined in your workflows will succeed when executed. This proactive validation assesses various elements, including IAM permissions and resource states across accounts and Regions. By continually monitoring these dependencies, Region switch helps ensure your recovery plans remain viable and identifies potential issues before they impact your actual switch operations.

However, just as an untested backup is not a reliable backup, an untested recovery plan cannot be considered truly validated. While continuous evaluation provides a strong foundation, we strongly recommend regularly executing your plans in test scenarios to verify their effectiveness, understand actual recovery times, and ensure your teams are familiar with the recovery procedures. This hands-on testing is essential for maintaining confidence in your disaster recovery strategy.

Step 3: Create a trigger

A trigger defines the conditions to activate the workflows just created. It’s expressed as a set of CloudWatch alarms. Alarm-based triggers are optional. You can also use Region switch with manual triggers.

From the Region switch page in the console, I choose the Triggers tab and choose Add triggers.

For each Region defined in my plan, I choose Add trigger to define the triggers that will activate the Region.Finally, I choose the alarms and their state (OK or Alarm) that Region switch will use to trigger the activation of the Region.

I’m now ready to test the execution of the plan to switch Regions using Region switch. It’s important to execute the plan from the Region I’m activating (the target Region of the workflow) and use the data plane in that specific Region.

Here is how to execute a plan using the AWS Command Line Interface (AWS CLI):

aws arc-region-switch start-plan-execution \
--plan-arn arn:aws:arc-region-switch::111122223333:plan/resource-id \
--target-region us-west-2 \
--action activate

Pricing and availability
Region switch is available in all commercial AWS Regions at $70 per month per plan. Each plan can include up to 100 execution blocks, or you can create parent plans to orchestrate up to 25 child plans.

Having seen firsthand the engineering effort that goes into building and maintaining multi-Region recovery solutions, I’m thrilled to see how Region switch will help automate this process for our customers. To get started with ARC Region switch, visit the ARC console and create your first Region switch plan. For more information about Region switch, visit the Amazon Application Recovery Controller (ARC) documentation. You can also reach out to your AWS account team with questions about using Region switch for your multi-Region applications.

I look forward to hearing about how you use Region switch to strengthen your multi-Region applications’ resilience.

— seb

Amazon S3 Metadata now supports metadata for all your S3 objects

2025-07-16 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/amazon-s3-metadata-now-supports-metadata-for-all-your-s3-objects/

Amazon S3 Metadata now provides complete visibility into all your existing objects in your Amazon Simple Storage Service (Amazon S3) buckets, expanding beyond new objects and changes. With this expanded coverage, you can analyze and query metadata for your entire S3 storage footprint.

Today, many customers rely on Amazon S3 to store unstructured data at scale. To understand what’s in a bucket, you often need to build and maintain custom systems that scan for objects, track changes, and manage metadata over time. These systems are expensive to maintain and hard to keep up to date as data grows.

Since the launch of S3 Metadata at re:Invent 2024, you’ve been able to query new and updated object metadata using metadata tables instead of relying on Amazon S3 Inventory or object-level APIs such as ListObjects, HeadObject, and GetObject—which can introduce latency and impact downstream workflows.

To make it easier for you to work with this expanded metadata, S3 Metadata introduces live inventory tables that work with familiar SQL-based tools. After your existing objects are backfilled into the system, any updates like uploads or deletions typically appear within an hour in your live inventory tables.

With S3 Metadata live inventory tables, you get a fully managed Apache Iceberg table that provides a complete and current snapshot of the objects and their metadata in your bucket, including existing objects, thanks to backfill support. These tables are refreshed automatically within an hour of changes such as uploads or deletions, so you stay up to date. You can use them to identify objects with specific properties—like unencrypted data, missing tags, or particular storage classes—and to support analytics, cost optimization, auditing, and governance.

S3 Metadata journal tables, previously known as S3 Metadata tables, are automatically enabled when you configure live inventory tables, provide a near real-time view of object-level changes in your bucket—including uploads, deletions, and metadata updates. These tables are ideal for auditing activity, tracking the lifecycle of objects, and generating event-driven insights. For example, you can use them to find out which objects were deleted in the past 24 hours, identify the requester making the most PUT operations, or monitor updates to object metadata over time.

S3 Metadata tables are created in a namespace name that is similar to your bucket name for easier discovery. The tables are stored in AWS system table buckets, grouped by account and Region. After you enable S3 Metadata for a general purpose S3 bucket, the system creates and maintains these tables for you. You don’t need to manage compaction or garbage collection processes—S3 Tables takes care of table maintenance tasks in the background.

These new tables help avoid waiting for metadata discovery before processing can begin, making them ideal for large-scale analytics and machine learning (ML) workloads. By querying metadata ahead of time, you can schedule GPU jobs more efficiently and reduce idle time in compute-intensive environments.

Let’s see how it works
To see how this works in practice, I configure S3 Metadata for a general purpose bucket using the AWS Management Console.

After choosing a general purpose bucket, I choose the Metadata tab, then I choose Create metadata configuration.

For Journal table, I can choose the Server-side encryption option and the Record expiration period. For Live Inventory table, I choose Enabled and I can select the Server-side encryption options.

I configure Record expiration on the journal table. Journal table records expire after the specified number of days, 365 days (one year) in my example.

Then, I choose Create metadata configuration.

S3 Metadata creates the live inventory table and journal table. In the Live Inventory table section, I can observe the Table status: the system immediately starts to backfill the table with existing object metadata. It can take between minutes to hours. The exact time depends on the quantity of objects you have in your S3 bucket.

While waiting, I also upload and delete objects to generate data in the journal table.

Then, I navigate to Amazon Athena to start querying the new tables.

I choose Query table with Athena to start querying the table. I can choose between a couple of default queries on the console.

In Athena, I observe the structure of the tables in the AWSDataCatalog Data source and I start with a short query to check how many records are available in the journal table. I already have 6,488 entries:

SELECT count(*) FROM "b_aws_news_blog_metadata_inventory_ns"."journal";

# _col0
1 6488

Here are a couple of example queries I tried on the journal table:

# Query deleted objects in last 24 hours
# Use is_delete_marker=true for versioned buckets and record_type='DELETE' otherwise
SELECT bucket, key, version_id, last_modified_date
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."journal"
WHERE last_modified_date >= (current_date - interval '1' day) AND is_delete_marker = true;

# bucket key version_id last_modified_date is_delete_marker
1 aws-news-blog-metadata-inventory .build/index-build/arm64-apple-macosx/debug/index/store/v5/records/G0/NSURLSession.h-JET61D329FG0 
2 aws-news-blog-metadata-inventory .build/index-build/arm64-apple-macosx/debug/index/store/v5/records/G5/cdefs.h-PJ21EUWKMWG5 
3 aws-news-blog-metadata-inventory .build/index-build/arm64-apple-macosx/debug/index/store/v5/records/FX/buf.h-25EDY57V6ZXFX 
4 aws-news-blog-metadata-inventory .build/index-build/arm64-apple-macosx/debug/index/store/v5/records/G6/NSMeasurementFormatter.h-3FN8J9CLVMYG6 
5 aws-news-blog-metadata-inventory .build/index-build/arm64-apple-macosx/debug/index/store/v5/records/G8/NSXMLDocument.h-1UO2NUJK0OAG8 

# Query recent PUT requests IP addresses
SELECT source_ip_address, count(source_ip_address)
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."journal"
GROUP BY source_ip_address;

#	source_ip_address	_col1
1	my_laptop_IP_address	12488

# Query S3 Lifecycle expired objects in last 7 days
SELECT bucket, key, version_id, last_modified_date, record_timestamp
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."journal"
WHERE requester = 's3.amazonaws.com' AND record_type = 'DELETE' AND record_timestamp > (current_date - interval '7' day);

(not applicable to my demo bucket)

The results helped me track the specific objects that were removed, including their timestamps.

Now, I look at the live inventory table:

# Distribution of object tags
SELECT object_tags, count(object_tags)
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."inventory"
GROUP BY object_tags;

# object_tags    _col1
1 {Source=Swift} 1
2 {Source=swift} 1
3 {}             12486

# Query storage class and size for specific tags
SELECT storage_class, count(*) as count, sum(size) / 1024 / 1024 as usage
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."inventory"
GROUP BY object_tags['pii=true'], storage_class;

# storage_class count   usage
1 STANDARD      124884  165

# Find objects with specific user defined metadata
SELECT key, last_modified_date, user_metadata
FROM "s3tablescatalog/aws-managed-s3"."b_aws_news_blog_metadata_inventory_ns"."inventory"
WHERE cardinality(user_metadata) > 0 ORDER BY last_modified_date DESC;

(not applicable to my demo bucket)

These are just a few examples of what is possible with S3 Metadata. Your preferred queries will depend on your use cases. Refer to Analyzing Amazon S3 Metadata with Amazon Athena and Amazon QuickSight in the AWS Storage Blog for more examples.

Pricing and availability
S3 Metadata live inventory and journal tables are available today in US East (Ohio, N. Virginia) and US West (N. California).

The journal tables are charged $0.30 per million updates. This is a 33 percent drop from our previous price.

For inventory tables, there’s a one-time backfill cost of $0.30 for a million objects to set up the table and generate metadata for existing objects. There are no additional costs if your bucket has less than one billion objects. For buckets with more than a billion objects, there is a monthly fee of $0.10 per million objects per month.

As usual, the Amazon S3 pricing page has all the details.

With S3 Metadata live inventory and journal tables, you can reduce the time and effort required to explore and manage large datasets. You get an up-to-date view of your storage and a record of changes, and both are available as Iceberg tables you can query on demand. You can discover data faster, power compliance workflows, and optimize your ML pipelines.

You can get started by enabling metadata inventory on your S3 bucket through the AWS console, AWS Command Line Interface (AWS CLI), or AWS SDKs. When they’re enabled, the journal and live inventory tables are automatically created and updated. To learn more, visit the S3 Metadata Documentation page.

— seb

New: Improve Apache Iceberg query performance in Amazon S3 with sort and z-order compaction

2025-06-24 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/new-improve-apache-iceberg-query-performance-in-amazon-s3-with-sort-and-z-order-compaction/

You can now use sort and z-order compaction to improve Apache Iceberg query performance in Amazon S3 Tables and general purpose S3 buckets.

You typically use Iceberg to manage large-scale analytical datasets in Amazon Simple Storage Service (Amazon S3) with AWS Glue Data Catalog or with S3 Tables. Iceberg tables support use cases such as concurrent streaming and batch ingestion, schema evolution, and time travel. When working with high-ingest or frequently updated datasets, data lakes can accumulate many small files that impact the cost and performance of your queries. You’ve shared that optimizing Iceberg data layout is operationally complex and often requires developing and maintaining custom pipelines. Although the default binpack strategy with managed compaction provides notable performance improvements, introducing sort and z-order compaction options for both S3 and S3 Tables delivers even greater gains for queries filtering across one or more dimensions.

Two new compaction strategies: Sort and z-order
To help organize your data more efficiently, Amazon S3 now supports two new compaction strategies: sort and z-order, in addition to the default binpack compaction. These advanced strategies are available for both fully managed S3 Tables and Iceberg tables in general purpose S3 buckets through AWS Glue Data Catalog optimizations.

Sort compaction organizes files based on a user-defined column order. When your tables have a defined sort order, S3 Tables compaction will now use it to cluster similar values together during the compaction process. This improves the efficiency of query execution by reducing the number of files scanned. For example, if your table is organized by sort compaction along state and zip_code, queries that filter on those columns will scan fewer files, improving latency and reducing query engine cost.

Z-order compaction goes a step further by enabling efficient file pruning across multiple dimensions. It interleaves the binary representation of values from multiple columns into a single scalar that can be sorted, making this strategy particularly useful for spatial or multidimensional queries. For example, if your workloads include queries that simultaneously filter by pickup_location, dropoff_location, and fare_amount, z-order compaction can reduce the total number of files scanned compared to traditional sort-based layouts.

S3 Tables use your Iceberg table metadata to determine the current sort order. If a table has a defined sort order, no additional configuration is needed to activate sort compaction—it’s automatically applied during ongoing maintenance. To use z-order, you need to update the table maintenance configuration using the S3 Tables API and set the strategy to z-order. For Iceberg tables in general purpose S3 buckets, you can configure AWS Glue Data Catalog to use sort or z-order compaction during optimization by updating the compaction settings.

Only new data written after enabling sort or z-order will be affected. Existing compacted files will remain unchanged unless you explicitly rewrite them by increasing the target file size in table maintenance settings or rewriting data using standard Iceberg tools. This behavior is designed to give you control over when and how much data is reorganized, balancing cost and performance.

Let’s see it in action
I’ll walk you through a simplified example using Apache Spark and the AWS Command Line Interface (AWS CLI). I have a Spark cluster installed and an S3 table bucket. I have a table named testtable in a testnamespace. I temporarily disabled compaction, the time for me to add data into the table.

After adding data, I check the file structure of the table.

spark.sql("""
  SELECT 
    substring_index(file_path, '/', -1) as file_name,
    record_count,
    file_size_in_bytes,
    CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name,
    CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name
  FROM ice_catalog.testnamespace.testtable.files
  ORDER BY file_name
""").show(20, false)

+--------------------------------------------------------------+------------+------------------+----------------+----------------+
|file_name                                                     |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name|
+--------------------------------------------------------------+------------+------------------+----------------+----------------+
|00000-0-66a9c843-5a5c-407f-8da4-4da91c7f6ae2-0-00001.parquet  |1           |837               |Quinn           |Quinn           |
|00000-1-b7fa2021-7f75-4aaf-9a24-9bdbb5dc08c9-0-00001.parquet  |1           |824               |Tom             |Tom             |
|00000-10-00a96923-a8f4-41ba-a683-576490518561-0-00001.parquet |1           |838               |Ilene           |Ilene           |
|00000-104-2db9509d-245c-44d6-9055-8e97d4e44b01-0-00001.parquet|1000000     |4031668           |Anjali          |Tom             |
|00000-11-27f76097-28b2-42bc-b746-4359df83d8a1-0-00001.parquet |1           |838               |Henry           |Henry           |
|00000-114-6ff661ca-ba93-4238-8eab-7c5259c9ca08-0-00001.parquet|1000000     |4031788           |Anjali          |Tom             |
|00000-12-fd6798c0-9b5b-424f-af70-11775bf2a452-0-00001.parquet |1           |852               |Georgie         |Georgie         |
|00000-124-76090ac6-ae6b-4f4e-9284-b8a09f849360-0-00001.parquet|1000000     |4031740           |Anjali          |Tom             |
|00000-13-cb0dd5d0-4e28-47f5-9cc3-b8d2a71f5292-0-00001.parquet |1           |845               |Olivia          |Olivia          |
|00000-134-bf6ea649-7a0b-4833-8448-60faa5ebfdcd-0-00001.parquet|1000000     |4031718           |Anjali          |Tom             |
|00000-14-c7a02039-fc93-42e3-87b4-2dd5676d5b09-0-00001.parquet |1           |838               |Sarah           |Sarah           |
|00000-144-9b6d00c0-d4cf-4835-8286-ebfe2401e47a-0-00001.parquet|1000000     |4031663           |Anjali          |Tom             |
|00000-15-8138298d-923b-44f7-9bd6-90d9c0e9e4ed-0-00001.parquet |1           |831               |Brad            |Brad            |
|00000-155-9dea2d4f-fc98-418d-a504-6226eb0a5135-0-00001.parquet|1000000     |4031676           |Anjali          |Tom             |
|00000-16-ed37cf2d-4306-4036-98de-727c1fe4e0f9-0-00001.parquet |1           |830               |Brad            |Brad            |
|00000-166-b67929dc-f9c1-4579-b955-0d6ef6c604b2-0-00001.parquet|1000000     |4031729           |Anjali          |Tom             |
|00000-17-1011820e-ee25-4f7a-bd73-2843fb1c3150-0-00001.parquet |1           |830               |Noah            |Noah            |
|00000-177-14a9db71-56bb-4325-93b6-737136f5118d-0-00001.parquet|1000000     |4031778           |Anjali          |Tom             |
|00000-18-89cbb849-876a-441a-9ab0-8535b05cd222-0-00001.parquet |1           |838               |David           |David           |
|00000-188-6dc3dcca-ddc0-405e-aa0f-7de8637f993b-0-00001.parquet|1000000     |4031727           |Anjali          |Tom             |
+--------------------------------------------------------------+------------+------------------+----------------+----------------+
only showing top 20 rows

I observe the table is made of multiple small files and that the upper and lower bounds for the new files have overlap–the data is certainly unsorted.

I set the table sort order.

spark.sql("ALTER TABLE ice_catalog.testnamespace.testtable WRITE ORDERED BY name ASC")

I enable table compaction (it’s enabled by default; I disabled it at the start of this demo)

aws s3tables put-table-maintenance-configuration --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable --type icebergCompaction --value "status=enabled,settings={icebergCompaction={strategy=sort}}"

Then, I wait for the next compaction job to trigger. These run throughout the day, when there are enough small files. I can check the compaction status with the following command.

aws s3tables get-table-maintenance-job-status --table-bucket-arn ${S3TABLE_BUCKET_ARN} --namespace testnamespace --name testtable

When the compaction is done, I inspect the files that make up my table one more time. I see that the data was compacted to two files, and the upper and lower bounds show that the data was sorted across these two files.

spark.sql("""
  SELECT 
    substring_index(file_path, '/', -1) as file_name,
    record_count,
    file_size_in_bytes,
    CAST(UNHEX(hex(lower_bounds[2])) AS STRING) as lower_bound_name,
    CAST(UNHEX(hex(upper_bounds[2])) AS STRING) as upper_bound_name
  FROM ice_catalog.testnamespace.testtable.files
  ORDER BY file_name
""").show(20, false)

+------------------------------------------------------------+------------+------------------+----------------+----------------+
|file_name                                                   |record_count|file_size_in_bytes|lower_bound_name|upper_bound_name|
+------------------------------------------------------------+------------+------------------+----------------+----------------+
|00000-4-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|13195713    |50034921          |Anjali          |Kelly           |
|00001-5-51c7a4a8-194b-45c5-a815-a8c0e16e2115-0-00001.parquet|10804307    |40964156          |Liza            |Tom             |
+------------------------------------------------------------+------------+------------------+----------------+----------------+

There are fewer files, they have larger sizes, and there is a better clustering across the specified sort column.

To use z-order, I follow the same steps, but I set strategy=z-order in the maintenance configuration.

Regional availability
Sort and z-order compaction are now available in all AWS Regions where Amazon S3 Tables are supported and for general purpose S3 buckets where optimization with AWS Glue Data Catalog is available. There is no additional charge for S3 Tables beyond existing usage and maintenance fees. For Data Catalog optimizations, compute charges apply during compaction.

With these changes, queries that filter on the sort or z-order columns benefit from faster scan times and reduced engine costs. In my experience, depending on my data layout and query patterns, I observed performance improvements of threefold or more when switching from binpack to sort or z-order. Tell us how much your gains are on your actual data.

To learn more, visit the Amazon S3 Tables product page or review the S3 Tables maintenance documentation. You can also start testing the new strategies on your own tables today using the S3 Tables API or AWS Glue optimizations.

— seb

AWS Weekly Roundup: re:Inforce re:Cap, Valkey GLIDE 2.0, Avro and Protobuf or MCP Servers on Lambda, and more (June 23, 2025)

2025-06-23 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-reinforce-recap-valkey-glide-2-0-avro-and-protobuf-or-mcp-servers-on-lambda-and-more-june-23-2025/

Last week’s hallmark event was the security-focused AWS re:Inforce conference.

Now a tradition, the blog team wrote a re:Cap post to summarize the announcements and link to some of the top blog posts.

To further summarize, several new security innovations were announced, including enhanced IAM Access Analyzer capabilities, MFA enforcement for root users, and threat intelligence integration with AWS Network Firewall. Other notable updates include exportable public SSL/TLS certificates from AWS Certificate Manager, a simplified AWS WAF console experience, and a new AWS Shield feature for proactive network security (in preview). Additionally, AWS Security Hub has been enhanced for risk prioritization (Preview), and Amazon GuardDuty now supports Amazon EKS clusters.

But my favorite announcement came from the Amazon Verified Permissions team. They released an open source package for Express.js, enabling developers to implement external fine-grained authorization for web application APIs. This simplifies authorization integration, reducing code complexity and improving application security.

The team also published a blog post that outlines how to create a Verified Permissions policy store, add Cedar and Verified Permissions authorisation middleware to your app, create and deploy a Cedar schema, and create and deploy Cedar policies. The Cedar schema is generated from an OpenAPI specification and formatted for use with the AWS Command Line Interface (CLI).

Let’s look at last week’s other new announcements.

Last week’s launches
Apart from re:Inforce, here are the launches that got my attention.

AWS Lambda announces native support for Avro and Protobuf formatted Kafka events — AWS Lambda now provides native support for Avro and Protobuf formatted Kafka events with Apache Kafka’s event-source-mapping (ESM). This integration allows you to validate your schema, filter events, and process them using open source Kafka consumer interfaces. You can also use Powertools for AWS Lambda to process your Kafka events without writing custom deserialization code, making it easier to build your Kafka applications with AWS Lambda.

Kafka customers use Avro and Protobuf formats for efficient data storage, fast serialization and deserialization, schema evolution support, and interoperability between different programming languages. They utilize schema registries to manage, evolve, and validate schemas before data enters processing pipelines. Previously, you were required to write custom code within your Lambda function to validate, deserialize, and filter events when using these data formats. With this launch, Lambda natively supports Avro and Protobuf, as well as integration with GSR, CCSR, and SCSR. This enables you to process your Kafka events using these data formats without writing custom code. Additionally, you can optimize costs through event filtering to prevent unnecessary function invocations.

Amazon S3 Express One Zone now supports atomic renaming of objects with a single API call – The RenameObject API simplifies data management in S3 directory buckets by transforming a multi-step rename operation into a single API call. This means you can now rename objects in S3 Express One Zone by specifying an existing object’s name as the source and the new name as the destination within the same S3 directory bucket. With no data movement involved, this capability accelerates applications like log file management, media processing, and data analytics, while also lowering costs. For instance, renaming a 1-terabyte log file can now complete in milliseconds, instead of hours, significantly accelerating applications and reducing costs.
Valkey introduces GLIDE 2.0 with support for Go, OpenTelemetry, and pipeline batching – AWS, in partnership with Google and the Valkey community, announces the general availability of General Language Independent Driver for the Enterprise (GLIDE) 2.0. This is the latest release of one of AWS’s official open-source Valkey client libraries. Valkey, the most permissive open-source alternative to Redis, is stewarded by the Linux Foundation and will always remain open-source. Valkey GLIDE is a reliable, high-performance, multi-language client that supports all Valkey commands

GLIDE 2.0 introduces new capabilities that expand developer support, improve observability, and optimise performance for high-throughput workloads. Valkey GLIDE 2.0 extends its multi-language support to Go (contributed by Google), joining Java, Python, and Node.js to provide a consistent, fully compatible API experience across all four languages. More language support is on the way. With this release, Valkey GLIDE now supports OpenTelemetry, an open-source, vendor-neutral framework that enables developers to generate, collect, and export telemetry data and critical client-side performance insights. Additionally, GLIDE 2.0 introduces batching capabilities, reducing network overhead and latency for high-frequency use cases by allowing multiple commands to be grouped and executed as a single operation.

You can discover more about Valkey GLIDE in this recent episode of the AWS Developers Podcast: Inside Valkey GLIDE: building a next-gen Valkey client library with Rust.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Some other reading
My Belgian compatriot Alexis has written the first article of a two-part series explaining how to develop an MCP Tool server with a streamable HTTP transport and deploy it on Lambda and API Gateway. This is a must-read for anyone implementing MCP servers on AWS. I’m eagerly looking forward to the second part, where Alexis will discuss authentication and authorization for remote MCP servers.

Other AWS events
Check your calendar and sign up for upcoming AWS events.

AWS GenAI Lofts are collaborative spaces and immersive experiences that showcase AWS expertise in cloud computing and AI. They provide startups and developers with hands-on access to AI products and services, exclusive sessions with industry leaders, and valuable networking opportunities with investors and peers. Find a GenAI Loft location near you and don’t forget to register.

AWS Summits are free online and in-person events that bring the cloud computing community together to connect, collaborate, and learn about AWS. Register in your nearest city: Japan (this week June 25 – 26), Online in India (June 26), New-York City (July 16).

Save the date for these upcoming Summits in July and August: Taipei (July 29), Jakarta (August 7), Mexico (August 8), São Paulo (August 13), and Johannesburg (August 20) (and more to come in September and October).

Browse all upcoming AWS led in-person and virtual events here.

That’s all for this week. Check back next Monday for another Weekly Roundup!

— seb

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

Introducing Claude 4 in Amazon Bedrock, the most powerful models for coding from Anthropic

2025-05-22 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/claude-opus-4-anthropics-most-powerful-model-for-coding-is-now-in-amazon-bedrock/

Anthropic launched the next generation of Claude models today—Opus 4 and Sonnet 4—designed for coding, advanced reasoning, and the support of the next generation of capable, autonomous AI agents. Both models are now generally available in Amazon Bedrock, giving developers immediate access to both the model’s advanced reasoning and agentic capabilities.

Amazon Bedrock expands your AI choices with Anthropic’s most advanced models, giving you the freedom to build transformative applications with enterprise-grade security and responsible AI controls. Both models extend what’s possible with AI systems by improving task planning, tool use, and agent steerability.

With Opus 4’s advanced intelligence, you can build agents that handle long-running, high-context tasks like refactoring large codebases, synthesizing research, or coordinating cross-functional enterprise operations. Sonnet 4 is optimized for efficiency at scale, making it a strong fit as a subagent or for high-volume tasks like code reviews, bug fixes, and production-grade content generation.

When building with generative AI, many developers work on long-horizon tasks. These workflows require deep, sustained reasoning, often involving multistep processes, planning across large contexts, and synthesizing diverse inputs over extended timeframes. Good examples of these workflows are developer AI agents that help you to refactor or transform large projects. Existing models may respond quickly and fluently, but maintaining coherence and context over time—especially in areas like coding, research, or enterprise workflows—can still be challenging.

Claude Opus 4
Claude Opus 4 is the most advanced model to date from Anthropic, designed for building sophisticated AI agents that can reason, plan, and execute complex tasks with minimal oversight. Anthropic benchmarks show it is the best coding model available on the market today. It excels in software development scenarios where extended context, deep reasoning, and adaptive execution are critical. Developers can use Opus 4 to write and refactor code across entire projects, manage full-stack architectures, or design agentic systems that break down high-level goals into executable steps. It demonstrates strong performance on coding and agent-focused benchmarks like SWE-bench and TAU-bench, making it a natural choice for building agents that handle multistep development workflows. For example, Opus 4 can analyze technical documentation, plan a software implementation, write the required code, and iteratively refine it—while tracking requirements and architectural context throughout the process.

Claude Sonnet 4
Claude Sonnet 4 complements Opus 4 by balancing performance, responsiveness, and cost, making it well-suited for high-volume production workloads. It’s optimized for everyday development tasks with enhanced performance, such as powering code reviews, implementing bug ﬁxes, and new feature development with immediate feedback loops. It can also power production-ready AI assistants for near real-time applications. Sonnet 4 is a drop-in replacement from Claude Sonnet 3.7. In multi-agent systems, Sonnet 4 performs well as a task-speciﬁc subagent—handling responsibilities like targeted code reviews, search and retrieval, or isolated feature development within a broader pipeline. You can also use Sonnet 4 to manage continuous integration and delivery (CI/CD) pipelines, perform bug triage, or integrate APIs, all while maintaining high throughput and developer-aligned output.

Opus 4 and Sonnet 4 are hybrid reasoning models offering two modes: near-instant responses and extended thinking for deeper reasoning. You can choose near-instant responses for interactive applications, or enable extended thinking when a request benefits from deeper analysis and planning. Thinking is especially useful for long-context reasoning tasks in areas like software engineering, math, or scientific research. By configuring the model’s thinking budget—for example, by setting a maximum token count—you can tune the tradeoff between latency and answer depth to fit your workload.

How to get started
To see Opus 4 or Sonnet 4 in action, enable the new model in your AWS account. Then, you can start coding using the Bedrock Converse API with model IDanthropic.claude-opus-4-20250514-v1:0 for Opus 4 and anthropic.claude-sonnet-4-20250514-v1:0 for Sonnet 4. We recommend using the Converse API, because it provides a consistent API that works with all Amazon Bedrock models that support messages. This means you can write code one time and use it with different models.

For example, let’s imagine I write an agent to review code before merging changes in a code repository. I write the following code that uses the Bedrock Converse API to send a system and user prompts. Then, the agent consumes the streamed result.

private let modelId = "us.anthropic.claude-sonnet-4-20250514-v1:0"

// Define the system prompt that instructs Claude how to respond
let systemPrompt = """
You are a senior iOS developer with deep expertise in Swift, especially Swift 6 concurrency. Your job is to perform a code review focused on identifying concurrency-related edge cases, potential race conditions, and misuse of Swift concurrency primitives such as Task, TaskGroup, Sendable, @MainActor, and @preconcurrency.

You should review the code carefully and flag any patterns or logic that may cause unexpected behavior in concurrent environments, such as accessing shared mutable state without proper isolation, incorrect actor usage, or non-Sendable types crossing concurrency boundaries.

Explain your reasoning in precise technical terms, and provide recommendations to improve safety, predictability, and correctness. When appropriate, suggest concrete code changes or refactorings using idiomatic Swift 6
"""
let system: BedrockRuntimeClientTypes.SystemContentBlock = .text(systemPrompt)

// Create the user message with text prompt and image
let userPrompt = """
Can you review the following Swift code for concurrency issues? Let me know what could go wrong and how to fix it.
"""
let prompt: BedrockRuntimeClientTypes.ContentBlock = .text(userPrompt)

// Create the user message with both text and image content
let userMessage = BedrockRuntimeClientTypes.Message(
    content: [prompt],
    role: .user
)

// Initialize the messages array with the user message
var messages: [BedrockRuntimeClientTypes.Message] = []
messages.append(userMessage)

// Configure the inference parameters
let inferenceConfig: BedrockRuntimeClientTypes.InferenceConfiguration = .init(maxTokens: 4096, temperature: 0.0)

// Create the input for the Converse API with streaming
let input = ConverseStreamInput(inferenceConfig: inferenceConfig, messages: messages, modelId: modelId, system: [system])

// Make the streaming request
do {
    // Process the stream
    let response = try await bedrockClient.converseStream(input: input)

    // Iterate through the stream events
    for try await event in stream {
        switch event {
        case .messagestart:
            print("AI-assistant started to stream"")

        case let .contentblockdelta(deltaEvent):
            // Handle text content as it arrives
            if case let .text(text) = deltaEvent.delta {
                self.streamedResponse + = text
                print(text, termination: "")
            }

        case .messagestop:
            print("\n\nStream ended")
            // Create a complete assistant message from the streamed response
            let assistantMessage = BedrockRuntimeClientTypes.Message(
                content: [.text(self.streamedResponse)],
                role: .assistant
            )
            messages.append(assistantMessage)

        default:
            break
        }
    }

To help you get started, my colleague Dennis maintains a broad range of code examples for multiple use cases and a variety of programming languages.

Available today in Amazon Bedrock
This release gives developers immediate access in Amazon Bedrock, a fully managed, serverless service, to the next generation of Claude models developed by Anthropic. Whether you’re already building with Claude in Amazon Bedrock or just getting started, this seamless access makes it faster to experiment, prototype, and scale with cutting-edge foundation models—without managing infrastructure or complex integrations.

Claude Opus 4 is available in the following AWS Regions in North America: US East (Ohio, N. Virginia) and US West (Oregon). Claude Sonnet 4 is available not only in AWS Regions in North America but also in APAC, and Europe: US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Hyderabad, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), and Europe (Spain). You can access the two models through cross-Region inference. Cross-Region inference helps to automatically select the optimal AWS Region within your geography to process your inference request.

Opus 4 tackles your most challenging development tasks, while Sonnet 4 excels at routine work with its optimal balance of speed and capability.

Learn more about the pricing and how to use these new models in Amazon Bedrock today!

— seb

Configure System Integrity Protection (SIP) on Amazon EC2 Mac instances

2025-05-21 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/configure-system-integrity-protection-sip-on-amazon-ec2-mac-instances/

I’m pleased to announce developers can now programmatically disable Apple System Integrity Protection (SIP) on their Amazon EC2 Mac instances. System Integrity Protection (SIP), also known as rootless, is a security feature introduced by Apple in OS X El Capitan (2015, version 10.11). It’s designed to protect the system from potentially harmful software by restricting the power of the root user account. SIP is enabled by default on macOS.

SIP safeguards the system by preventing modification of protected files and folders, restricting access to system-owned files and directories, and blocking unauthorized software from selecting a startup disk. The primary goal of SIP is to address the security risk linked to unrestricted root access, which could potentially allow malware to gain full control of a device with just one password or vulnerability. By implementing this protection, Apple aims to ensure a higher level of security for macOS users, especially considering that many users operate on administrative accounts with weak or no passwords.

While SIP provides excellent protection against malware for everyday use, developers might occasionally need to temporarily disable it for development and testing purposes. For instance, when creating a new device driver or system extension, disabling SIP is necessary to install and test the code. Additionally, SIP might block access to certain system settings required for your software to function properly. Temporarily disabling SIP grants you the necessary permissions to fine-tune programs for macOS. However, it’s crucial to remember that this is akin to briefly disabling the vault door for authorized maintenance, not leaving it permanently open.

Disabling SIP on a Mac requires physical access to the machine. You have to restart the machine in recovery mode, then disable SIP with the csrtutil command line tool, then restart the machine again.

Until today, you had to operate with the standard SIP settings on EC2 Mac instances. The physical access requirement and the need to boot in recovery mode made integrating SIP with the Amazon EC2 control plane and EC2 API challenging. But that’s no longer the case! You can now disable and re-enable SIP at will on your Amazon EC2 Mac instances. Let me show you how.

Let’s see how it works
Imagine I have an Amazon EC2 Mac instance started. It’s a mac2-m2.metal instance, running on an Apple silicon M2 processor. Disabling or enabling SIP is as straightforward as calling a new EC2 API: CreateMacSystemIntegrityProtectionModificationTask. This API is asynchronous; it starts the process of changing the SIP status on your instance. You can monitor progress using another new EC2 API: DescribeMacModificationTasks. All I need to know is the instance ID of the machine I want to work with.

Prerequisites
On Apple silicon based EC2 Mac instances and more recent type of machines, before calling the new EC2 API, I must set the ec2-user user password and enable secure token for that user on macOS. This requires connecting to the machine and typing two commands in the terminal.

# on the target EC2 Mac instance
# Set a password for the ec2-user user
~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user
New Password: (MyNewPassw0rd)

# Enable secure token, with the same password, for the ec2-user
# old password is the one you just set with dscl
~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd
2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user…
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294)
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done

# The error about the KeyChain is expected. I never connected with the GUI on this machine, so the Login keychain does not exist
# you can ignore this error.  The command below shows the list of keychains active in this session
~ % security list
    "/Library/Keychains/System.keychain"

# Verify that the secure token is ENABLED
~ % sysadminctl -secureTokenStatus ec2-user
2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user

Change the SIP status
I don’t need to connect to the machine to toggle the SIP status. I only need to know its instance ID. I open a terminal on my laptop and use the AWS Command Line Interface (AWS CLI) to retrieve the Amazon EC2 Mac instance ID.

 aws ec2 describe-instances \
         --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" \
         --output text

i-012a5de8da47bdff7

Now, still from the terminal on my laptop, I disable SIP with the create-mac-system-integrity-protection-modification-task command:

echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' > tmpCredentials
aws ec2 create-mac-system-integrity-protection-modification-task \
--instance-id "i-012a5de8da47bdff7" \
--mac-credentials fileb://./tmpCredentials \
--mac-system-integrity-protection-status "disabled" && rm tmpCredentials

{
    "macModificationTask": {
        "instanceId": "i-012a5de8da47bdff7",
        "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
        "macSystemIntegrityProtectionConfig": {},
        "startTime": "2025-03-14T14:15:06Z",
        "taskState": "pending",
        "taskType": "sip-modification"
    }
}

After the task is started, I can check its status with the aws ec2 describe-mac-modification-tasks command.

{
    "macModificationTasks": [
        {
            "instanceId": "i-012a5de8da47bdff7",
            "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
            "macSystemIntegrityProtectionConfig": {
                "debuggingRestrictions": "",
                "dTraceRestrictions": "",
                "filesystemProtections": "",
                "kextSigning": "",
                "nvramProtections": "",
                "status": "disabled"
            },
            "startTime": "2025-03-14T14:15:06Z",
            "tags": [],
            "taskState": "in-progress",
            "taskType": "sip-modification"
        },
...

The instance initiates the process and a series of reboots, during which it becomes unreachable. This process can take 60–90 minutes to complete. After that, when I see the status in the console becoming available again, I connect to the machine through SSH or EC2 Instance Connect, as usual.

➜  ~ ssh [email protected]
Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts.
Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1

    ┌───┬──┐   __|  __|_  )
    │ ╷╭╯╷ │   _|  (     /
    │  └╮  │  ___|\___|___|
    │ ╰─┼╯ │  Amazon EC2
    └───┴──┘  macOS Sonoma 14.3.1

➜  ~ uname -a
Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64

➜ ~ csrutil --status 
System Integrity Protection status: disabled.

When to disable SIP
Disabling SIP should be approached with caution because it opens up the system to potential security risks. However, as I mentioned in the introduction of this post, you might need to disable SIP when developing device drivers or kernel extensions for macOS. Some older applications might also not function correctly when SIP is enabled.

Disabling SIP is also required to turn off Spotlight indexing. Spotlight can help you quickly find apps, documents, emails and other items on your Mac. It’s very convenient on desktop machines, but not so much on a server. When there is no need to index your documents as they change, turning off Spotlight will release some CPU cycles and disk I/O.

Things to know
There are a couple of additional things to know about disabling SIP on Amazon EC2 Mac:

Disabling SIP is available through the API and AWS SDKs, the AWS CLI, and the AWS Management Console.
On Apple silicon, the setting is volume based. So if you replace the root volume, you need to disable SIP again. On Intel, the setting is Mac host based, so if you replace the root volume, SIP will still be disabled.
After disabling SIP, it will be enabled again if you stop and start the instance. Rebooting an instance doesn’t change its SIP status.
SIP status isn’t transferable between EBS volumes. This means SIP will be disabled again after you restore an instance from an EBS snapshot or if you create an AMI from an instance where SIP is enabled.

These new APIs are available in all Regions where Amazon EC2 Mac is available, at no additional cost. Try them today.

— seb

How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

Introducing the AWS Product Lifecycle page and AWS service availability updates

2025-05-20 Sébastien Stormacq

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/introducing-the-aws-product-lifecycle-page-and-aws-service-availability-updates/

Today, we’re introducing the AWS Product Lifecycle page, a centralized resource that provides comprehensive information about service availability changes across AWS.

The new AWS Product Lifecycle page consolidates all service availability information in one convenient location. This dedicated resource offers detailed visibility into three key categories of changes: 1) services closing access to new customers, 2) services that have announced end of support, and 3) services that have reached their end of support date. For each service listed, you can access specific end-of-support dates, recommended migration paths, and links to relevant documentation, enabling more efficient planning for service transitions.

The AWS Product Lifecycle page helps you stay informed about changes that may affect your workloads and enables more efficient planning for service transitions. The centralized nature of this resource reduces the time and effort needed to track service lifecycle information, allowing you to focus more on your core business objectives and less on administrative overhead.

Today on the new Product Lifecycle page, you will see updates about the following changes to services and capabilities:

AWS service availability updates in 2025
After careful consideration, we’re announcing availability changes for a select group of AWS services and features. We understand that the decision to end support for a service or feature significantly impacts your operations. We approach such decisions only after thorough evaluation, and when end of support is necessary, we provide detailed guidance on available alternatives and comprehensive support for migration.

Services closing access to new customers
We’re closing access to new customers after June 20, 2025, for the following services or capabilities listed. Existing customers will be able to continue to use the service.

Amazon Timestream for LiveAnalytics

Services that have announced end of support
The following services will no longer be supported. To find out more about service specific end-of-support dates, as well as detailed migration information, please visit individual service documentation pages.

Services that have reached their end of support
The following services have reached their end of support date and can no longer be accessed:

AWS Private 5G
AWS DataSync Discovery

The AWS Product Lifecycle page is available and all the changes described in this post are listed on the new page now. We recommend that you bookmark this page and check out What’s New with AWS? for upcoming AWS service availability updates. For more information about using this new resource, contact us or your usual AWS Support contacts for specific guidance on transitioning affected workloads.

— seb

Noise

All posts by Sébastien Stormacq

Opening the AWS European Sovereign Cloud

German version

French version

Italian version

Spanish version

Announcing replication support and Intelligent-Tiering for Amazon S3 Tables

Amazon S3 Vectors now generally available with increased scale and performance

AWS DevOps Agent helps you accelerate incident response and improve system reliability (preview)

AWS Partner Central now available in AWS Management Console

Introducing VPC encryption controls: Enforce encryption in transit within and across VPCs in a Region

New Amazon Bedrock service tiers help you match AI workload performance with cost

AWS Weekly Roundup: AWS Lambda for Rust, NLB for QUIC protocol, Amazon DCV for Mac, and more (November 17, 2025)

Introducing Amazon EBS Volume Clones: Create instant copies of your EBS volumes

AWS IAM Identity Center now supports customer-managed KMS keys for encryption at rest

Announcing Amazon EC2 M4 and M4 Pro Mac instances

AWS Weekly Roundup: Amazon EC2, Amazon Q Developer, IPv6 updates, and more (September 1, 2025)

Celebrating 10 years of Amazon Aurora innovation

Introducing Amazon Application Recovery Controller Region switch: A multi-Region application recovery service

Amazon S3 Metadata now supports metadata for all your S3 objects

New: Improve Apache Iceberg query performance in Amazon S3 with sort and z-order compaction

AWS Weekly Roundup: re:Inforce re:Cap, Valkey GLIDE 2.0, Avro and Protobuf or MCP Servers on Lambda, and more (June 23, 2025)

Introducing Claude 4 in Amazon Bedrock, the most powerful models for coding from Anthropic

Configure System Integrity Protection (SIP) on Amazon EC2 Mac instances

Introducing the AWS Product Lifecycle page and AWS service availability updates

The collective thoughts of the interwebz