AWS Backup is expanding support for Amazon FSx for Windows File Server, Amazon FSx for OpenZFS, and Amazon FSx for Lustre with two regional enhancements.
First, AWS Backup now supports backup and restore of these FSx file systems in 5 additional AWS Regions: Asia Pacific (Malaysia, Taipei, Thailand), Canada West (Calgary), and Mexico (Central). You can now centrally manage FSx backup policies, automate backup schedules, and monitor backup activity through AWS Backup in these Regions.
Second, AWS Backup now supports cross-Region and cross-account copy of FSx backups in 14 Regions: Africa (Cape Town), Asia Pacific (Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Taipei, Thailand), Canada West (Calgary), Europe (Milan, Spain, Zurich), Israel (Tel Aviv), and Mexico (Central). This capability is available for both on-demand copies and scheduled backup plans with copy rules. With support in opt-in Regions, you can also store FSx backups in AWS Backup logically air-gapped vaults, providing additional defense against inadvertent or malicious deletions and helping you recover from ransomware events.
You can now configure cross-Region and cross-account copy rules to meet your compliance and business continuity requirements. To learn more, visit the AWS Backup feature availability page.
AWS Backup is expanding support for Amazon FSx for Windows File Server, Amazon FSx for OpenZFS, and Amazon FSx for Lustre with two regional enhancements.
First, AWS Backup now supports backup and restore of these FSx file systems in 5 additional AWS Regions: Asia Pacific (Malaysia, Taipei, Thailand), Canada West (Calgary), and Mexico (Central). You can now centrally manage FSx backup policies, automate backup schedules, and monitor backup activity through AWS Backup in these Regions.
Second, AWS Backup now supports cross-Region and cross-account copy of FSx backups in 14 Regions: Africa (Cape Town), Asia Pacific (Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Taipei, Thailand), Canada West (Calgary), Europe (Milan, Spain, Zurich), Israel (Tel Aviv), and Mexico (Central). This capability is available for both on-demand copies and scheduled backup plans with copy rules. With support in opt-in Regions, you can also store FSx backups in AWS Backup logically air-gapped vaults, providing additional defense against inadvertent or malicious deletions and helping you recover from ransomware events.
You can now configure cross-Region and cross-account copy rules to meet your compliance and business continuity requirements. To learn more, visit the AWS Backup feature availability page.
De la revista Signal: Cómo el Vaticano piensa sobre la IA en un mundo cambiante
Signal visita la Ciudad Eterna para hablar con el padre Paolo Benanti sobre la Llamada de Roma a la Ética en la IA, las ventajas del vibe-coding y las perspectivas de un nuevo Renacimiento
Roma está en medio de un aguacero torrencial. Turistas con ponchos de lluvia de 2€ se refugian en los cafés que bordean la Via Cavour, cuyas aceras se han convertido en afluentes improvisados del Tíber. El agua cae por las empinadas escaleras de la Via Magnanapoli, donde un restaurante emprendedor muestra imágenes de IA del Papa Francisco que come en un cuenco de espaguetis de la casa. Quienes se refugien dentro del local, verán más e improbables avalaciones fotográficas de Charlie Chaplin, Marilyn Monroe y una serie de caballeros medievales que disfrutan de una buena carbonara.
Mientras tanto, un poco más abajo en la calle, en un rincón tranquilo de un monasterio franciscano, estamos acogidos, secos y discutimos algunos usos menos frívolos de la inteligencia artificial. Mi anfitrión es Paolo Benanti, sacerdote, autor, profesor de teología moral, asesor técnico del Vaticano y una de las fuerzas impulsoras detrás de la influyente Llamada de Roma a la Ética en IA. Sin embargo, antes de encontrar su vocación, comenzó a formarse como ingeniero. «Estudié al otro lado de la calle de aquí, en la Universidad La Sapienza», dice. «Hice las clases, pero no terminé porque encontré lo que buscaba en el orden. Dije: ‘Vale, ingeniería, máquinas, ordenadores, todo eso es cosa de mi pasado.’»
Pero la tecnología resultó ser más difícil de patear de lo que pensaba. Tras completar sus seis años de educación religiosa para unirse a la orden, los demás frailes ofrecieron a Benanti la oportunidad de continuar sus estudios. Para entonces ya se había dado cuenta de qué asignatura le entusiasmaba más. «Quería reconciliar ambos lados, mezclar filosofía y tecnología», dice. Esta idea novedosa no fue muy bien recibida al principio. «¿Te imaginas las caras de la gente en la iglesia, mirándome en 2007 y preguntándome ‘¿Por qué querrías hacer esto?’» pregunta. Benanti logró convencerles y comenzó un doctorado centrado en la ética de la neurotecnología, los implantes cerebrales y la inteligencia artificial. «La idea de que 18 años después lo primero que haría el nuevo Papa [León XIV] sería identificar la IA como un tema clave para la iglesia… digamos que hubo un poco de transformación en ese tiempo», dice con una sonrisa. «La IA no solo transforma la sociedad, también ha transformado la percepción de la iglesia.»
En 2017, tras completar su doctorado y comenzar a dar clases en la universidad junto a sus devociones religiosas, Benanti conoció a Pier Luigi Dal Pino, director regional senior de asuntos gubernamentales para Europa Occidental de Microsoft. «Empezamos a hablar sobre el avance de la IA, y encontramos mucha coincidencia entre la perspectiva de Microsoft, mi perspectiva filosófica y ética y los intereses de la Santa Sede», dice. «Nos miramos y dijimos: ‘¡Intentemos hacer algo juntos!’ Y aquí fue donde Microsoft, la academia y el Vaticano empezaron a trabajar en algo que se convirtió en el llamado de Roma para la ética en IA.»
La Convocatoria consagra seis principios diseñados para promover un enfoque ético en el desarrollo de sistemas de IA de vanguardia: transparencia, inclusión, responsabilidad, imparcialidad, fiabilidad y seguridad y privacidad. Fue firmado por representantes de la Academia Pontificia para la Vida, Microsoft, IBM, la Organización de las Naciones Unidas para la Alimentación y la Agricultura y el Ministerio de Innovación italiano el 28 de febrero de 2020. «Fue un evento enorme con 2.000 personas», dice Benanti. Gracias a la pandemia, sería la última reunión de este tipo ese año. «Firmamos y solo unos días después, Roma entró en confinamiento.
El Covid-19 puso en pausa los planes para ganar más seguidores durante un par de años. «Pero tras un diálogo con [el vicepresidente y presidente de Microsoft] Brad Smith, volvimos a empezar en 2022», dice Benanti. «El poder de esta Llamada es que es para todos. Su verdadero éxito sería llegar al día en el que es [aceptada de manera tan amplia que] ya no es necesario.» Como siguiente paso, el grupo se propuso obtener un amplio apoyo cultural y religioso. «Pudimos obtener comentarios positivos de líderes del judaísmo y el islam», dice Benanti. «En enero de 2023, el Rome Call se convirtió en el primer documento de la historia en el que las tres religiones monoteístas estuvieron de acuerdo.»
En la firma de líderes judíos y musulmanes, Benanti pronunció un discurso principal. «En la relación hombre-máquina, el verdadero experto y portador de valores es el hombre», dijo a los dignatarios reunidos. «La dignidad y los derechos humanos señalan que el hombre debe ser protegido en la relación hombre-máquina.»
Sus comentarios fueron respaldados por Brad Smith. «Debemos asegurarnos de que la IA siga como una herramienta creada por la humanidad para la humanidad», afirmó. «Es imprescindible que guiemos este trabajo con un fuerte compromiso con altos estándares éticos y un amplio sentido de responsabilidad social.»
El siguiente paso de Benanti, en 2024, fue un viaje a Hiroshima, donde representantes de 21 religiones del mundo firmaron la Llamada, y Amandeep Singh Gill, enviado del Secretario General de la ONU para Tecnología, expresó su aprobación. «Dijo: ‘¡Habéis construido algo que queríamos construir!’», dice Benanti con orgullo.
A pesar de todo el apoyo que se recibió, no existe una fuerza legal para la Llamada a Roma. «No es una lista de cumplimiento; no comprobamos ni marcamos lo que la gente hace o no hace», dice Benanti. «Mi perspectiva es la de un ético, así que de alguna manera puedo hacer preguntas y huir antes de dar respuestas. Pero la idea de abrir el debate es, en esencia, preguntar a la gente: ‘¿Por qué te gustaría que te recordaran?’ Así que, a cada ingeniero que ahora trabaja en una empresa tecnológica, nos preguntamos cuál de dos modelos prefiere: IA frente a humanos o IA como mejora. Queremos esta relación simbiótica en la que las herramientas son un copiloto, no un piloto automático.»
Existen ventajas prácticas claras para las organizaciones que se inscriben. «Queremos que los CEOs vean la ética no como enemiga de los negocios, sino como algo que puede darles valor», dice Benanti. «Hoy en día, la gente quiere ver un compromiso ético por parte de su empresa para sentir que su trabajo tiene verdadero mérito. Firmar el Rome Call puede ser un gran imán para que las empresas atraigan al mejor talento.»
Benanti suele llevar un Apple Watch y un anillo inteligente y se entusiasma con la fuerza democratizadora de la tecnología. «Somos ocho mil millones de personas en la Tierra», dice. «Unos seis mil millones de nosotros tenemos un smartphone. Pero solo 27 millones de personas saben programar. Eso significa que el 99,65 por ciento de las personas están excluidas. Pero ahora puedo usar lenguaje natural, y la IA puede traducirlo a código – y puedo tomar posesión de la máquina.»
El fraile ha experimentado él mismo con código generado por IA. Señala con deleite un nuevo conjunto de ventanas en su despacho. «¡Bienvenidos a las ganancias de mi vibe-coding!» dice. «Diseñé cuatro aplicaciones, que se vendieron en el mercado y nos dieron el dinero para cambiar las ventanas.» Las aplicaciones, que incluyen una que ayuda a la gente a usar el método del cerebro Zettelkasten para memorizar notas y otra para crear folletos para celebraciones religiosas, «me dan la propiedad de la máquina para no depender del software de otra persona», dice Benanti. «Imagina que nos dirigimos hacia un futuro en el que devolvemos silicio a la gente. Ya no serán clientes del silicio, sino sus propietarios. Eso podría suponer una gran evolución, al pasar del 0,35 por ciento de la población capaz de programar al 25 por ciento, muy parecido a la revolución que tuvimos con la invención de la imprenta durante el Renacimiento, cuando la gente empezó a saber leer y estudiar.»
Además, Benanti dice: «Un compañero IA podría ser el mejor servidor para cualquiera; podría ser una forma de democratizar el privilegio, incluida la educación, que antes estaba reservado para un pequeño número de personas. Podría ser la herramienta que nos permita expresar una mejor humanidad para un número mucho mayor de personas.» Sin embargo, muestra un tono de cautela. «También tenemos que ser realistas, que esto no siempre ha ocurrido con grandes cambios en la historia y que no es una calle de sentido único. En Europa, alcanzamos un nivel superior de comprensión de lo que significa ser humano con la Revolución Francesa. Teníamos estos principios: Liberté, Egalité, Fraternité (Libertad, Igualdad, Fraternidad). Pero luego se puede ver lo que pasó con el nazismo y el fascismo. El hecho de que no sea una calle de sentido único es justo la razón por la que es tan importante tener un debate ético sobre esta tecnología. Porque la IA podría ser la mejor herramienta para dar a la humanidad la mejor calidad de vida de la historia, o podría ser la peor pesadilla que permita que unas pocas élites dominen a los demás.»
Al igual que con los avances tecnológicos del Renacimiento y posteriores, Benanti puede ver cómo la IA desata nueva creatividad. «Si fuéramos a París en el siglo XIX, verías a algunos artistas que pintan lo que vieron, punto por punto, y trabajan durante un mes. Entonces apareció un hombre extraño con una caja y una capa, hizo un clic y en cinco segundos había capturado el mismo sujeto de las imágenes que la pintura. ¿La fotografía mató la pintura? ¡No! Democratizó la creación de imágenes.»
Benanti prevé un papel en distinguir los productos de IA de la creación humana. «Tenemos que desarrollar herramientas que nos permitan conectar un activo digital con su productor», afirma. «Si hago una foto, debería poder poner un plano criptográfico que la conecte con mi nombre, para hacerme responsable de ella. Las empresas que fabrican modelos de IA también pueden hacer planos de cualquier imagen generada por IA, de modo que tengamos dos barreras de seguridad: producida por humanos y producida por IA. Será como el pequeño candado que ves en una página web. No te garantiza que el contenido de la web sea perfecto, pero ¿pondrías tu número de tarjeta de crédito en una web que no tenga ese bloqueo? ¡No! La gente tiene derecho a saber si hay una máquina o un ser humano detrás del contenido.»
Benanti establece un paralelismo adicional, esta vez con el periodismo, basándose en su experiencia como presidente de la Comisión de Inteligencia Artificial para la Información del gobierno italiano. «Puedes escribir algo que no es verdad como periodista, pero si puedes relacionar tu nombre con ello, creas una cadena de responsabilidad. ¿Cuál es tu nombre profesional? ¿Cuál es tu área de especialización? ¿Tu reputación? Tenemos que hacer lo mismo para todas las creaciones digitales.»
¿Existe la preocupación, sin embargo, de que la gente, en especial las futuras generaciones, deje de preocuparse por si los artefactos culturales —música, cine, fotografía, escritura— han sido creados por la IA o no? «Creo que habrá creatividad procesada y será como la comida procesada», dice Benanti. «Hoy has comido muchas Pringles, pero no saben a comida hecha por la mamá!»
La mañana que volé a Roma para reunirme con el padre Benanti, empecé a hablar con el taxista camino al aeropuerto. Cuando supo que iba a reunirme con el experto vaticano en IA, me dijo lo alterado que estaba por los titulares recientes sobre la tecnología que socava los empleos de cuello blanco, y me pidió que planteara la pregunta de qué deberían aspirar sus hijas adolescentes en su educación y carreras.
Benanti considera el asunto con cuidado. «Estamos en un momento de transición y no podemos dar garantías a nadie», afirma. Sin embargo, advierte contra proyectar hacia adelante basándose en algunos de los primeros indicadores de pérdidas de empleo relacionadas con la IA. «Por razones evolutivas, nuestro cerebro piensa de forma lineal y puedes tener procesos no lineales en la IA, así que no es tan fácil hacer predicciones y puedes tomar decisiones en verdad malas si solo extrapolas tendencias recientes en dirección al mañana.»
«El punto clave es que no tenemos otra opción que apostar por la próxima generación y permitir que sean la mejor versión de la humanidad que puedan, lo que significa equiparlos con las mejores capacidades de razonamiento. El pensamiento humano será tal vez el recurso más necesario en los próximos años. Por eso es vital permitirles desarrollar el pensamiento crítico, incluida la ética.»
En los últimos años de su reinado, el Papa Francisco se pronunció a favor de un enfoque ético hacia la IA, al enviar un mensaje contundente a los delegados en la conferencia de Hiroshima. «Les pido que demuestren al mundo que estamos unidos en pedir un compromiso proactivo para proteger la dignidad humana en esta nueva era de máquinas», dijo. El nuevo Papa, León XIV, también ha intervenido sobre la tecnología, al elogiar su potencial en la sanidad y la ciencia, pero también al decir a los escolares en Estados Unidos que «Usar la IA de forma responsable significa usarla de manera que te ayude a crecer, nunca de formas que te distraigan de tu dignidad o de tu llamado a la santidad.»
«Este Papa es en verdad de mente abierta», dice Benanti. «Sabe que la IA es una de las cosas más transformadoras que tenemos ahora. Dice que adoptó el nombre de León XIV porque fue él quien abrió la doctrina social de la iglesia con la Rerum Novarum [una carta encíclica de 1891 que abordaba cuestiones de la era industrial producidas por la adopción de nuevas tecnologías].» Aunque Benanti dice que tendremos que «esperar y ver» qué políticas finales sobre IA llevará a cabo el nuevo Papa, espera y cree que continuarán en una dirección de apertura a todos en lugar de centrarse de manera estrecha en la comunidad católica. «Queremos tener una alianza de todas las personas diferentes en IA», dice. «Queremos empujar las cosas hacia el mayor bien para todos.»
Esta es una versión digital de un artículo de muestra del número 3 de la revista Signal. Para explorar el número completo, consulten el flipbook completo aquí.
AWS Private Certificate Authority (AWS Private CA) now supports customer managed permissions in AWS Resource Access Manager (AWS RAM). AWS Private CA lets you share certificate authorities (CAs) across accounts using AWS RAM so you can centralize your PKI instead of creating separate CAs in every account. With customer managed permissions, you can now select exactly which AWS Private CA API operations to allow when sharing a CA, granting only the specific operations each consuming account needs.
Previously, you could only use AWS managed permissions, which provide predefined sets of actions and restrict cross-account issuers to specific certificate templates. Now you can select from read operations (e.g., DescribeCertificateAuthority, GetCertificate, and GetCertificateAuthorityCertificate) and write operations (e.g., IssueCertificate and RevokeCertificate) to tailor access for each consuming account or organizational unit. With customer managed permissions, cross-account issuers are not restricted to a specific certificate template.
AWS Private Certificate Authority (AWS Private CA) now supports customer managed permissions in AWS Resource Access Manager (AWS RAM). AWS Private CA lets you share certificate authorities (CAs) across accounts using AWS RAM so you can centralize your PKI instead of creating separate CAs in every account. With customer managed permissions, you can now select exactly which AWS Private CA API operations to allow when sharing a CA, granting only the specific operations each consuming account needs. Previously, you could only use AWS managed permissions, which provide predefined sets of actions and restrict cross-account issuers to specific certificate templates. Now you can select from read operations (e.g., DescribeCertificateAuthority, GetCertificate, and GetCertificateAuthorityCertificate) and write operations (e.g., IssueCertificate and RevokeCertificate) to tailor access for each consuming account or organizational unit. With customer managed permissions, cross-account issuers are not restricted to a specific certificate template. Customer managed permissions for AWS Private CA are available in all AWS Regions where AWS Private CA and AWS RAM are available. To learn more, see Customer managed permissions in RAM in the AWS Private CA User Guide and Creating and using customer managed permissions in the AWS RAM User Guide.
AWS Billing and Cost Management Dashboards now support scheduled email delivery for your reports. You can now automate report distribution on flexible recurring schedules, eliminating manual compilation work and ensuring financial insights reach decision-makers without requiring console access.»
Scheduled email reports enable you to configure daily, weekly, or monthly delivery schedules for your dashboards. Recipients receive emails containing secure links to password-protected PDF reports optimized for offline viewing. Manage recipients through AWS User Notifications, and once configured, reports generate and distribute automatically on your chosen schedule. You can also access these capabilities programmatically through AWS SDKs and CLI tools.
This feature is available at no additional cost in all commercial AWS Regions, excluding AWS China Regions. To get started, open the AWS Billing and Cost Management console, navigate to Dashboards, select a dashboard, and choose ‘Manage email reports’ from the Actions menu. For more information, see the Dashboards user guide and announcement blog post.
AWS Billing and Cost Management Dashboards now support scheduled email delivery for your reports. You can now automate report distribution on flexible recurring schedules, eliminating manual compilation work and ensuring financial insights reach decision-makers without requiring console access.»
Scheduled email reports enable you to configure daily, weekly, or monthly delivery schedules for your dashboards. Recipients receive emails containing secure links to password-protected PDF reports optimized for offline viewing. Manage recipients through AWS User Notifications, and once configured, reports generate and distribute automatically on your chosen schedule. You can also access these capabilities programmatically through AWS SDKs and CLI tools.
This feature is available at no additional cost in all commercial AWS Regions, excluding AWS China Regions. To get started, open the AWS Billing and Cost Management console, navigate to Dashboards, select a dashboard, and choose ‘Manage email reports’ from the Actions menu. For more information, see the Dashboards user guide and announcement blog post.
Amazon Timestream for InfluxDB now supports customer-defined maintenance windows, giving you control over when routine maintenance is performed on your InfluxDB databases. This feature is available for both InfluxDB 2 instances and InfluxDB 3 clusters across all supported editions.
With this launch, you can specify a weekly maintenance window using a day-and-time format in your preferred timezone. Timestream for InfluxDB supports IANA timezone identifiers such as America/New_York, Europe/London, and Asia/Tokyo, and automatically handles Daylight Saving Time transitions so you don’t need to manually adjust your schedule. If you don’t specify a maintenance window, the service continues to manage maintenance timing automatically.
You can set or update your preferred maintenance window when creating or modifying a resource using the Amazon Timestream for InfluxDB console, AWS CLI, or AWS SDKs. You can use Amazon Timestream for InfluxDB Customer-Defined Maintenance Windows in all Regions where Timestream for InfluxDB is offered.
Amazon Timestream for InfluxDB now supports customer-defined maintenance windows, giving you control over when routine maintenance is performed on your InfluxDB databases. This feature is available for both InfluxDB 2 instances and InfluxDB 3 clusters across all supported editions. With this launch, you can specify a weekly maintenance window using a day-and-time format in your preferred timezone. Timestream for InfluxDB supports IANA timezone identifiers such as America/New_York, Europe/London, and Asia/Tokyo, and automatically handles Daylight Saving Time transitions so you don’t need to manually adjust your schedule. If you don’t specify a maintenance window, the service continues to manage maintenance timing automatically. You can set or update your preferred maintenance window when creating or modifying a resource using the Amazon Timestream for InfluxDB console, AWS CLI, or AWS SDKs. You can use Amazon Timestream for InfluxDB Customer-Defined Maintenance Windows in all Regions where Timestream for InfluxDB is offered. To get started with Amazon Timestream for InfluxDB, visit the Amazon Timestream for InfluxDB console. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.
Amazon Bedrock now supports cost allocation by IAM principal, such as IAM users and IAM roles, in AWS Cost and Usage Report 2.0 (CUR 2.0) and Cost Explorer. This enables customers to understand and attribute Bedrock model inference costs across users, teams, projects, and applications.
With this launch, customers can tag their IAM users and roles with attributes like team, project, or cost center, activate them as cost allocation tags, and analyze Bedrock model inference costs by the tags in Cost Explorer or at the line-item level in CUR 2.0. To get started, tag your IAM users and roles and activate them as cost allocation tags in the Billing and Cost Management console. Then create a CUR 2.0 data export and select «Include caller identity (IAM principal) allocation data» or filter by tags in Cost Explorer.
Amazon Bedrock now supports cost allocation by IAM principal, such as IAM users and IAM roles, in AWS Cost and Usage Report 2.0 (CUR 2.0) and Cost Explorer. This enables customers to understand and attribute Bedrock model inference costs across users, teams, projects, and applications. With this launch, customers can tag their IAM users and roles with attributes like team, project, or cost center, activate them as cost allocation tags, and analyze Bedrock model inference costs by the tags in Cost Explorer or at the line-item level in CUR 2.0. To get started, tag your IAM users and roles and activate them as cost allocation tags in the Billing and Cost Management console. Then create a CUR 2.0 data export and select «Include caller identity (IAM principal) allocation data» or filter by tags in Cost Explorer. This feature is available in all AWS commercial Regions where Amazon Bedrock is available. To learn more, see Using IAM principal for Cost Allocation documentation. To get started with Amazon Bedrock, visit Amazon Bedrock documentation.
Amazon OpenSearch Serverless now supports Zstandard codecs for index storage, giving customers greater control over the trade-off between storage costs and query performance. With this launch, customers can configure Zstandard compression to achieve up to 32% reduction in index size compared to the default LZ4 codec, helping lower managed storage costs for data-intensive workloads.
Customers running large-scale log analytics, observability pipelines, and time-series workloads on Amazon OpenSearch Serverless can benefit most from Zstandard compression where high data volumes make storage efficiency a significant cost driver. The Zstandard compression algorithm is available in two different modes in Amazon OpenSearch Serverless: zstd and zstd_no_dict. Customers can tune the compression level to balance their specific needs: lower levels (e.g., level 1) deliver meaningful storage savings with minimal impact on indexing throughput and query latency, while higher levels (e.g., level 6) maximize compression ratios at the cost of slower indexing speeds.
Zstandard codec support is available today in all AWS Regions where Amazon OpenSearch Serverless is supported. To get started, you can specify these codecs in your index settings at creation time. For more information, see the Amazon OpenSearch Serverless documentation.
Amazon OpenSearch Serverless now supports Zstandard codecs for index storage, giving customers greater control over the trade-off between storage costs and query performance. With this launch, customers can configure Zstandard compression to achieve up to 32% reduction in index size compared to the default LZ4 codec, helping lower managed storage costs for data-intensive workloads.
Customers running large-scale log analytics, observability pipelines, and time-series workloads on Amazon OpenSearch Serverless can benefit most from Zstandard compression where high data volumes make storage efficiency a significant cost driver. The Zstandard compression algorithm is available in two different modes in Amazon OpenSearch Serverless: zstd and zstd_no_dict. Customers can tune the compression level to balance their specific needs: lower levels (e.g., level 1) deliver meaningful storage savings with minimal impact on indexing throughput and query latency, while higher levels (e.g., level 6) maximize compression ratios at the cost of slower indexing speeds.
Zstandard codec support is available today in all AWS Regions where Amazon OpenSearch Serverless is supported. To get started, you can specify these codecs in your index settings at creation time. For more information, see the Amazon OpenSearch Serverless documentation.
Amazon OpenSearch Service now provides a unified observability experience that brings together metrics, logs, traces, and AI agent tracing in a single interface. This release introduces native integration with Amazon Managed Service for Prometheus and comprehensive agent tracing capabilities, addressing the dual challenges of prohibitive costs from premium observability platforms and operational complexity from fragmented tooling. Site Reliability Engineers, DevOps Engineers, and Platform Engineering teams can now consolidate their observability stack without costly data duplication or constant context switching between multiple tools.
You can now query Prometheus metrics directly using native PromQL syntax alongside logs and traces in OpenSearch UI’s observability workspace—without duplicating data. Combined with new application monitoring workflows powered by RED metrics (Rate, Errors, Duration) and AI agent tracing using OpenTelemetry GenAI semantic conventions, operations teams can correlate slow traces to application logs, overlay Prometheus metrics on service dashboards, and trace LLM agent execution—all without switching tools. This live query architecture delivers significant cost reduction compared to premium platforms while maintaining operational excellence.
The new unified observability experience is available on OpenSearch UI in 20 AWS regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm), Canada (Central), and South America (São Paulo).
Amazon OpenSearch Service now provides a unified observability experience that brings together metrics, logs, traces, and AI agent tracing in a single interface. This release introduces native integration with Amazon Managed Service for Prometheus and comprehensive agent tracing capabilities, addressing the dual challenges of prohibitive costs from premium observability platforms and operational complexity from fragmented tooling. Site Reliability Engineers, DevOps Engineers, and Platform Engineering teams can now consolidate their observability stack without costly data duplication or constant context switching between multiple tools.
You can now query Prometheus metrics directly using native PromQL syntax alongside logs and traces in OpenSearch UI’s observability workspace—without duplicating data. Combined with new application monitoring workflows powered by RED metrics (Rate, Errors, Duration) and AI agent tracing using OpenTelemetry GenAI semantic conventions, operations teams can correlate slow traces to application logs, overlay Prometheus metrics on service dashboards, and trace LLM agent execution—all without switching tools. This live query architecture delivers significant cost reduction compared to premium platforms while maintaining operational excellence.
The new unified observability experience is available on OpenSearch UI in 20 AWS regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm), Canada (Central), and South America (São Paulo).
To learn more, visit the OpenSearch Service observability documentation and direct query documentation.
Amazon S3 Lifecycle now prevents expiration and transition actions on objects that failed replication, helping you to coordinate replication configuration or permissions changes with actions defined in your lifecycle rules.
Incorrect permissions or replication configuration can prevent objects from being replicated. With this change, S3 Lifecycle no longer expires or transitions objects that have failed replication, even if they match one of the lifecycle rules that you have defined. Once you have corrected your replication configuration or permissions, you can use S3 Batch Replication to replicate objects that previously failed. After successful replication, S3 Lifecycle will automatically process these objects according to your configured rules.
This change applies automatically to all existing and new S3 Lifecycle configurations, across 37 AWS Regions, including the AWS China and AWS GovCloud (US) Regions. We are in the process of deploying this change and plan to complete the deployment in the coming days. To learn more, visit S3 Lifecycle documentation and S3 Replication troubleshooting documentation.
Amazon S3 Lifecycle now prevents expiration and transition actions on objects that failed replication, helping you to coordinate replication configuration or permissions changes with actions defined in your lifecycle rules.
Incorrect permissions or replication configuration can prevent objects from being replicated. With this change, S3 Lifecycle no longer expires or transitions objects that have failed replication, even if they match one of the lifecycle rules that you have defined. Once you have corrected your replication configuration or permissions, you can use S3 Batch Replication to replicate objects that previously failed. After successful replication, S3 Lifecycle will automatically process these objects according to your configured rules.
This change applies automatically to all existing and new S3 Lifecycle configurations, across 37 AWS Regions, including the AWS China and AWS GovCloud (US) Regions. We are in the process of deploying this change and plan to complete the deployment in the coming days. To learn more, visit S3 Lifecycle documentation and S3 Replication troubleshooting documentation.
Amazon RDS Blue/Green Deployments now supports Amazon RDS Proxy, enabling faster application recovery during switchover by eliminating DNS propagation delays. Blue/Green Deployments create a fully managed staging environment (Green) that allows you to deploy and test production changes, keeping your current production database (Blue) safe. When ready, you can switchover to the new production environment and your applications begin accessing it immediately without any configuration changes.
During a Blue/Green Deployment switchover for single-Region configurations, RDS Proxy actively monitors database instances and detects when the Green environment becomes the new production environment. This allows RDS Proxy to quickly redirect connections to the Green environment, enabling faster application recovery. You don’t need to modify your drivers or change your existing application setup.
Amazon RDS Blue/Green Deployments with Amazon RDS Proxy is available for Amazon Aurora with MySQL compatibility, Amazon Aurora with PostgreSQL compatibility, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, and Amazon RDS for MariaDB in all commercial AWS Regions where RDS Proxy is available.
In a few clicks, update your databases using RDS Blue/Green Deployments via the Amazon RDS Console or Amazon CLI. To learn more, see Blue/Green Deployments overview in the Amazon RDS documentation.
Amazon RDS Blue/Green Deployments now supports Amazon RDS Proxy, enabling faster application recovery during switchover by eliminating DNS propagation delays. Blue/Green Deployments create a fully managed staging environment (Green) that allows you to deploy and test production changes, keeping your current production database (Blue) safe. When ready, you can switchover to the new production environment and your applications begin accessing it immediately without any configuration changes. During a Blue/Green Deployment switchover for single-Region configurations, RDS Proxy actively monitors database instances and detects when the Green environment becomes the new production environment. This allows RDS Proxy to quickly redirect connections to the Green environment, enabling faster application recovery. You don’t need to modify your drivers or change your existing application setup. Amazon RDS Blue/Green Deployments with Amazon RDS Proxy is available for Amazon Aurora with MySQL compatibility, Amazon Aurora with PostgreSQL compatibility, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, and Amazon RDS for MariaDB in all commercial AWS Regions where RDS Proxy is available. In a few clicks, update your databases using RDS Blue/Green Deployments via the Amazon RDS Console or Amazon CLI. To learn more, see Blue/Green Deployments overview in the Amazon RDS documentation.
