Amazon EMR Serverless makes it simple to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. Today, we are excited to announce support for specifying permissions inline when submitting a job run. This allows you to define fine-grained, tenant-specific permission scopes per job run for multi-tenant use cases.
When submitting a job run on EMR Serverless, you can specify a runtime role that the job run can assume when calling other AWS services. In multi-tenant environments, such as those managed by SaaS providers, job runs are often submitted on behalf of specific tenants. To ensure security and least privileges, it is necessary to scope down the permissions of the runtime role to the specific context of a tenant for a given job run. Achieving this requires creating a separate role for each tenant with restricted permissions. The proliferation of such roles can push the account limits of IAM as well as get unwieldy to manage. Now you can specify an inline permission policy when submitting a job run in addition to the runtime role. The effective permissions for a job run is the intersection of the inline policy and the runtime role. You can define the fine-grained, tenant-specific permissions for a job run in the inline policy removing the need to manage a growing number of roles in multi-tenant environments as well as easily adjust the policy definition for tenant-specific workloads.
This feature is available for all supported EMR releases and in all regions where EMR Serverless is available. To learn more, visit Runtime Policy.
Amazon EMR Serverless makes it simple to run open-source big data analytics frameworks without configuring, managing, and scaling clusters or servers. Today, we are excited to announce support for specifying permissions inline when submitting a job run. This allows you to define fine-grained, tenant-specific permission scopes per job run for multi-tenant use cases. When submitting a job run on EMR Serverless, you can specify a runtime role that the job run can assume when calling other AWS services. In multi-tenant environments, such as those managed by SaaS providers, job runs are often submitted on behalf of specific tenants. To ensure security and least privileges, it is necessary to scope down the permissions of the runtime role to the specific context of a tenant for a given job run. Achieving this requires creating a separate role for each tenant with restricted permissions. The proliferation of such roles can push the account limits of IAM as well as get unwieldy to manage. Now you can specify an inline permission policy when submitting a job run in addition to the runtime role. The effective permissions for a job run is the intersection of the inline policy and the runtime role. You can define the fine-grained, tenant-specific permissions for a job run in the inline policy removing the need to manage a growing number of roles in multi-tenant environments as well as easily adjust the policy definition for tenant-specific workloads. This feature is available for all supported EMR releases and in all regions where EMR Serverless is available. To learn more, visit Runtime Policy.
Lago de datos de Microsoft Sentinel: unifiquen las señales, reduzcan los costos y potencien la IA de agentes
Por: Scott Woodgate y Krishna Kumar Parthasarathy.
No se puede proteger lo que no se ve. Los equipos de operaciones de seguridad se han enfrentado durante mucho tiempo al desafío de administrar conjuntos de datos masivos y de rápido crecimiento, y el costo de escalar las herramientas tradicionales de administración de datos para manejar estos volúmenes de datos se ha vuelto insostenible. Evolucionamos nuestra solución de administración de eventos e incidentes de seguridad (SIEM, por sus siglas en inglés) líder en la industria, Microsoft Sentinel, para incluir un lago de datos moderno y rentable. Al unificar todos sus datos de seguridad, el lago de datos de Microsoft Sentinel, ahora en versión preliminar pública, acelera la adopción de la IA agentiva e impulsa una visibilidad sin precedentes, lo que permite a los equipos detectar y responder más rápido. Con el lago de datos Sentinel, ya no se verán obligados a elegir entre conservar datos críticos y mantenerse dentro del presupuesto.
Microsoft Sentinel comenzó este camino hace cinco años con la introducción del primer SIEM nativo de la nube para simplificar la incorporación de datos y llevar el poder de la IA a la detección de amenazas.¹ Desde entonces, hemos integrado Sentinel con Microsoft Defender y lo hemos enriquecido con inteligencia de amenazas en tiempo real, recomendaciones guiadas y capacidades de respuesta automatizada. El lago de datos Microsoft Sentinel es el siguiente paso en ese recorrido, creado para ayudar a los líderes de seguridad a superar las limitaciones de los SIEM tradicionales al poner los datos de seguridad en el centro del centro de operaciones de seguridad (SOC, por sus siglas en inglés), a escala y sin concesiones. Ahora, pueden continuar su propio recorrido e incorporar el lago de datos de Microsoft Sentinel.
Eliminación de los silos de datos para mejorar la seguridad
Con el rápido crecimiento de los volúmenes de registros de seguridad, los equipos se ven obligados a hacer dolorosas concesiones: reducir el registro y arriesgar puntos ciegos, acortar la retención con la posibilidad de comprometer la profundidad forense o absorber costes insostenibles cuando pretenden gestionar todos sus datos de seguridad dentro de un SIEM. Esta es la paradoja de la seguridad moderna: cuantos más datos tienen, más difícil se vuelve usarlos de manera efectiva. Y sin una visibilidad unificada a largo plazo, incluso los modelos de IA más avanzados no pueden desarrollar todo su potencial. Los datos aislados significan amenazas cibernéticas perdidas, investigaciones retrasadas y herramientas infrautilizadas.
El lago de datos de Microsoft Sentinel se creó en específico para resolver este desafío y proporciona la base para la defensa de agentes. Reúne todos sus datos de seguridad, de Microsoft y de terceros, en un único lago de datos rentable, con más de 350 conectores nativos. Con un precio de retención de datos de menos del 15% de los registros de análisis tradicionales, permite un enriquecimiento sin problemas con inteligencia de amenazas y detección impulsada por IA en todo su entorno. No se trata solo de un nuevo producto, sino de una nueva arquitectura para las operaciones de seguridad, que permite a los equipos de seguridad perseguir las ciberamenazas durante meses o años, reconstruir incidentes con precisión y desbloquear todo el valor de la IA.
La visión de Microsoft para el lago de datos Sentinel refleja lo que más importa en ciberseguridad: claridad, escala e impacto en el mundo real. Con más de 1.200 despliegues de Sentinel en todo el mundo, BlueVoyant ha visto la necesidad de primera mano. Los desafíos de datos a gran escala son ahora la norma. El lago de datos de Sentinel marca una evolución natural del modelo SIEM y SOAR, que respalda de manera crítica la analítica moderna, la ciencia de datos y la estrategia de ingesta flexible. Es un paso crítico hacia adelante para los clientes que buscan modernizar sus operaciones de seguridad.
—Milan Patel, director de ingresos de BlueVoyant
Para ayudar aún más a los defensores a sacar el máximo provecho de sus datos, democratizamos la inteligencia de amenazas mediante la convergencia de las capacidades de Inteligencia de amenazas de Microsoft Defender (MDTI, por sus siglas en inglés) en Defender XDR y Sentinel sin costo adicional; esto significa que los equipos de seguridad ya no necesitarán comprar una SKU independiente para acceder a estas características eficaces. El valor de MDTI se combinará en Sentinel y Defender XDR a lo largo del tiempo, a partir de octubre de 2025, cuando todos los informes de amenazas propias de Microsoft, incluidos los perfiles de Intel y los indicadores de riesgo (IoC, por sus siglas en inglés), estarán disponibles en Defender XDR. Además, los IoC se incorporarán a la gestión de casos de Sentinel para que los clientes puedan colaborar y compartir inteligencia de amenazas entre los equipos de su organización. El resto de las funciones estarán disponibles con el tiempo.
Con este cambio, los equipos de seguridad pueden acceder con facilidad a un potente repositorio de inteligencia de amenazas de primera línea, procedente de 84 billones de señales diarias y respaldada por la experiencia de más de 10 mil especialistas en seguridad de Microsoft. Obtengan más información sobre cómo este valor agregado en Sentinel y Defender mejorará en gran medida las capacidades con datos de amenazas de alta calidad y en tiempo real.
Capacitar a los equipos de seguridad para que hagan más
La promesa de la IA en la ciberseguridad siempre ha sido audaz: detección más rápida, respuesta más inteligente y la capacidad de superar incluso a los ciberatacantes más sofisticados. Pero la mayoría de los equipos de seguridad se ven frenados por datos fragmentados y un contexto incompleto. La centralización de sus datos en un lago de datos enriquecido con Intel para amenazas elimina los silos y garantiza que los modelos de IA como Security Copilot tengan el contexto completo que necesitan para detectar patrones sutiles de ciberataques, correlacionar señales a través del tiempo y el espacio, y mostrar alertas de alta fidelidad. Esto crea la base para el futuro de la defensa agentica, en la que la IA no solo ayuda, sino que actúa. Este cambio ahora permite a los equipos de seguridad:
Descubrir el comportamiento de los ciberatacantes que se remonta a años atrás sin preocuparse tanto por los límites de almacenamiento
Abordar los casos de uso previos y posteriores a la violación al correlacionar los datos de activos, actividad y TI
Utilizar la información de amenazas en tiempo real para clasificar más rápido y buscar datos históricos de forma retroactiva
Desencadenar detecciones de manera automática, en función de los IoC más recientes y las tácticas, técnicas y procedimientos (TTP)
Usar el lenguaje de consulta Kusto (KQL, por sus siglas en inglés) y Apache Spark para realizar consultas en horizontes temporales extendidos y detectar patrones sutiles de ciberataques
Respaldar las necesidades normativas y de cumplimiento con una retención de datos escalable y rentable
Estos son los trabajos que más importan en las operaciones de seguridad modernas y ahora son más fáciles, rápidos y rentables de ejecutar.
Para los equipos cibernéticos, la proliferación masiva de datos puede desviar el enfoque o retrasar las respuestas a las amenazas [cibernéticas] genuinas. El lago de datos de Microsoft Sentinel puede ser una herramienta valiosa para la centralización y visibilidad de datos, así como para el análisis histórico de grandes volúmenes de conjuntos de datos. Junto con Microsoft, Accenture puede ayudar a nuestros clientes a aprovechar el lago de datos para ampliar el poder de Microsoft Sentinel para potenciar la detección de ataques y la corrección proactiva.
—Rex Thexton, director de tecnología, Accenture Security
Simplificación de las operaciones a la vez que se está preparado para la IA
El lago de datos de Microsoft Sentinel simplifica la administración de datos con una experiencia flexible y centralizada en el portal de Microsoft Defender, al reunir sus datos de seguridad junto con las herramientas que sus defensores usan para prevenir, detectar y responder a las ciberamenazas todos los días. Los analistas pueden moverse sin problemas entre los niveles de análisis y lago de datos, lo que permite una respuesta en tiempo real y una investigación profunda desde una única interfaz. Al mismo tiempo, todos los datos almacenados en el nivel de análisis están disponibles de manera automática en el nivel de lago de datos, y debido a que se basa en formatos abiertos, las organizaciones pueden adaptar los flujos de trabajo de análisis, crear modelos personalizados de aprendizaje automático (ML, por sus siglas en inglés) y aprovechar las herramientas conocidas, en lugar de una sola copia de sus datos de seguridad, para ampliar el valor del lago de datos y satisfacer sus necesidades únicas. Ya sea que estén en el proceso de consolidación de herramientas, ampliación de su SOC o preparándose para la defensa impulsada por IA, el lago de datos Sentinel se adapta a su estrategia y recorrido de seguridad.
El lago de datos de Sentinel permite a los equipos de SOC entrar en la próxima era de operaciones de seguridad. Ser capaz de garantizar la cobertura de su patrimonio de seguridad, en todas las fuentes de datos de seguridad y en amplios horizontes temporales, permite a los equipos de seguridad detectar de forma proactiva los ciberataques latentes, detectar las ciberamenazas emergentes con modelos impulsados por IA, reconstruir las líneas de tiempo de los ciberataques con detalles forenses y descubrir de manera retroactiva, indicadores de compromiso que, de otro modo, podrían pasar desapercibidos.
La superficie de ataque cibernético se expande con cada aplicación y aplicación de IA implementadas en entornos de nube híbrida, y los ataques impulsados por IA evolucionan con la misma rapidez. Lo que a muchas organizaciones todavía les falta no es solo mejores herramientas, sino visibilidad en tiempo real de su patrimonio de TI, sus configuraciones y contexto empresarial. Para comprender su exposición completa, las organizaciones necesitan la inteligencia de activos adecuada y un esfuerzo compartido de la industria. El nuevo lago de datos de Microsoft Sentinel representa un paso valioso en esa dirección; IBM se compromete a trabajar en todo el ecosistema para ayudar a resolver ese desafío.
—Srini Tummalapenta, ingeniero distinguido de IBM, director de tecnología de IBM Consulting Cybersecurity Services
Este lanzamiento marca más que una evolución del producto, al permitir a los equipos de operaciones de seguridad responder más rápido y con la máxima visibilidad. Microsoft Sentinel sigue con la ampliación de los límites con una arquitectura escalable que combina SIEM, detección y respuesta extendidas (XDR, por sus siglas en inglés) e inteligencia sobre amenazas en una única experiencia integrada. El lago de datos Sentinel es la base de esta evolución, ya que permite a los equipos de seguridad procesar más datos, de forma más inteligente y más asequible que nunca.
Comiencen hoy mismo
El lago de datos de Microsoft Sentinel ya está en versión preliminar. Únanse a nosotros para redefinir lo que es posible en las operaciones de seguridad:
Para obtener más información sobre las soluciones de seguridad de Microsoft, visiten nuestro sitio web. Agreguen a Favoritos el blog de Seguridad para mantenerse al día con nuestra cobertura experta en asuntos de seguridad. Además, síganos en LinkedIn (Microsoft Security) y X (@MSFTSecurity) para conocer las últimas noticias y actualizaciones sobre ciberseguridad.
AWS Organizations Tag Policies announces wildcard support for Tag Policies using ALL_SUPPORTED in the Resource element. With this, you can simplify your policy authoring experience and reduce your policy size. You can now specify that your Tag Policy applies to all supported resource types for a given AWS service in a single line, instead of individually adding them to your policy.
Tag Policies enable you to enforce consistent tagging across your AWS accounts with proactive compliance, governance and control. For example, you can define a policy that all EC2 instances with “Environment” tag key must use only «Prod» or «Non-Prod» values. Previously, you had to list each EC2 resource type individually in a Tag Policy, such as instances, volumes, and snapshots. With ALL_SUPPORTED wildcard, you can now apply the same rule to all supported EC2 or S3 resource types in a single line.
You can use this feature via AWS Management Console, AWS Command Line Interface, and AWS Software Development Kit. This feature is available with AWS Organizations Tag Policies in AWS Regions where Tag Policies is available. To learn more, visit Tag Policies documentation.
AWS Organizations Tag Policies announces wildcard support for Tag Policies using ALL_SUPPORTED in the Resource element. With this, you can simplify your policy authoring experience and reduce your policy size. You can now specify that your Tag Policy applies to all supported resource types for a given AWS service in a single line, instead of individually adding them to your policy. Tag Policies enable you to enforce consistent tagging across your AWS accounts with proactive compliance, governance and control. For example, you can define a policy that all EC2 instances with “Environment” tag key must use only «Prod» or «Non-Prod» values. Previously, you had to list each EC2 resource type individually in a Tag Policy, such as instances, volumes, and snapshots. With ALL_SUPPORTED wildcard, you can now apply the same rule to all supported EC2 or S3 resource types in a single line. You can use this feature via AWS Management Console, AWS Command Line Interface, and AWS Software Development Kit. This feature is available with AWS Organizations Tag Policies in AWS Regions where Tag Policies is available. To learn more, visit Tag Policies documentation.
Amazon Simple Queue Service (Amazon SQS) now offers fair queues, a new feature that mitigates noisy neighbor impact in multi-tenant standard queues. When one tenant (such as a customer, client application, or request type) sends too many messages or has messages that require longer processing time, fair queues help keep other tenants’ messages flowing without long delays. This preserves quality of service for all tenants while maintaining the scalability and throughput of standard queues.
To enable fair queues, include a message group ID when sending messages to your Amazon SQS standard queues. No changes to message consumers are required, allowing you to adopt fair queues in live systems with no interruption or migration. Fair queues are particularly valuable for SaaS applications serving multiple customers through shared queues, microservices processing events from multiple resources, and applications handling messages for different request types. Fair queues help maintain consistent dwell time (the time a message spends in the queue between being sent and received) across tenants by reordering messages when a single tenant causes the queue to build a backlog. The queue then prioritizes delivering messages from other tenants. Messages from the tenant causing the backlog continue to be delivered to consumers, but their dwell time increases based on your available consumer capacity.
Fair queues are available in all AWS commercial and AWS GovCloud (US) Regions. For more information about Amazon SQS fair queues, read our blog post and visit Amazon SQS Developer Guide.
Amazon Simple Queue Service (Amazon SQS) now offers fair queues, a new feature that mitigates noisy neighbor impact in multi-tenant standard queues. When one tenant (such as a customer, client application, or request type) sends too many messages or has messages that require longer processing time, fair queues help keep other tenants’ messages flowing without long delays. This preserves quality of service for all tenants while maintaining the scalability and throughput of standard queues. To enable fair queues, include a message group ID when sending messages to your Amazon SQS standard queues. No changes to message consumers are required, allowing you to adopt fair queues in live systems with no interruption or migration. Fair queues are particularly valuable for SaaS applications serving multiple customers through shared queues, microservices processing events from multiple resources, and applications handling messages for different request types. Fair queues help maintain consistent dwell time (the time a message spends in the queue between being sent and received) across tenants by reordering messages when a single tenant causes the queue to build a backlog. The queue then prioritizes delivering messages from other tenants. Messages from the tenant causing the backlog continue to be delivered to consumers, but their dwell time increases based on your available consumer capacity. Fair queues are available in all AWS commercial and AWS GovCloud (US) Regions. For more information about Amazon SQS fair queues, read our blog post and visit Amazon SQS Developer Guide.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7gd instances with up to 3.8 TB of local NVMe-based SSD block-level storage are available in the Asia Pacific (Seoul) and Europe (Paris) Regions.
These Graviton3-based instances with DDR5 memory are built on the AWS Nitro System and are a great fit for applications that need access to high-speed, low latency local storage, including those that need temporary storage of data for scratch space, temporary files, and caches. They have up to 45% improved real-time NVMe storage performance than comparable Graviton2-based instances. Graviton3-based instances also use up to 60% less energy for the same performance than comparable EC2 instances, enabling you to reduce your carbon footprint in the cloud.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C7gd instances with up to 3.8 TB of local NVMe-based SSD block-level storage are available in the Asia Pacific (Seoul) and Europe (Paris) Regions. These Graviton3-based instances with DDR5 memory are built on the AWS Nitro System and are a great fit for applications that need access to high-speed, low latency local storage, including those that need temporary storage of data for scratch space, temporary files, and caches. They have up to 45% improved real-time NVMe storage performance than comparable Graviton2-based instances. Graviton3-based instances also use up to 60% less energy for the same performance than comparable EC2 instances, enabling you to reduce your carbon footprint in the cloud. To learn more, see Amazon C7gd Instances. To get started, see the AWS Management Console.
Amazon Connect external voice connectors are now priced at $100 per connector per day. The new daily rate provides customers with more granular billing options. The per-day rate is effective today for new and existing connectors.
Amazon Connect offers two types of external voice connectors. The transfer connector enables voice calls and metadata to be transferred to another voice system, so you can use Amazon Connect telephony and self-service AI with your existing voice system. The analytics connector enables Amazon Connect Contact Lens to ingest streaming voice and meta data from other voice systems and create contact records, call recordings, real-time and post-call analytics, and agent evaluations.
Amazon Connect external voice connectors are now priced at $100 per connector per day. The new daily rate provides customers with more granular billing options. The per-day rate is effective today for new and existing connectors. Amazon Connect offers two types of external voice connectors. The transfer connector enables voice calls and metadata to be transferred to another voice system, so you can use Amazon Connect telephony and self-service AI with your existing voice system. The analytics connector enables Amazon Connect Contact Lens to ingest streaming voice and meta data from other voice systems and create contact records, call recordings, real-time and post-call analytics, and agent evaluations. For AWS Regional availability of Amazon Connect external voice connectors, refer to Availability of Amazon Connect features by Region in the Amazon Connect Administrator Guide. To learn more about Amazon Connect and external voice connectors, review the following resources:
Amazon Connect website and pricing
External voice transfer – Amazon Connect Administrator Guide
Contact Lens with external voice – Amazon Connect Administrator Guide
Amazon Relational Database Service (RDS) for Db2 now supports group-based authorization with customer’s self-managed Microsoft Active Directory. This enables a secure and consistent access experience across on-premises and RDS for DB2 workloads.
Customers can now keep their user credentials and groups securely managed in their self-managed Active Directory and use them to access RDS for Db2. To set this up, customers can simply configure their RDS for Db2 instance to use an AWS Managed Active Directory, and then establish a one-way forest trust with their self-managed Active Directory. This integration allows them to access RDS for DB2 using the same group-based authorization experience as on-premises, without the need to manage separate user accounts and permissions for RDS for DB2.
Amazon RDS makes it simple to set up, operate, and scale Db2 deployments in the cloud. To learn more about Amazon RDS for Db2, check Amazon RDS for Db2 User Guide and Amazon RDS for Db2 pricing page for pricing details and regional availability. To learn more about using self-managed Active Directory to access RDS Db2, refer to documentation.
Amazon Relational Database Service (RDS) for Db2 now supports group-based authorization with customer’s self-managed Microsoft Active Directory. This enables a secure and consistent access experience across on-premises and RDS for DB2 workloads. Customers can now keep their user credentials and groups securely managed in their self-managed Active Directory and use them to access RDS for Db2. To set this up, customers can simply configure their RDS for Db2 instance to use an AWS Managed Active Directory, and then establish a one-way forest trust with their self-managed Active Directory. This integration allows them to access RDS for DB2 using the same group-based authorization experience as on-premises, without the need to manage separate user accounts and permissions for RDS for DB2.
Amazon RDS makes it simple to set up, operate, and scale Db2 deployments in the cloud. To learn more about Amazon RDS for Db2, check Amazon RDS for Db2 User Guide and Amazon RDS for Db2 pricing page for pricing details and regional availability. To learn more about using self-managed Active Directory to access RDS Db2, refer to documentation.
Amazon Relational Database Service (Amazon RDS) for PostgreSQL, MySQL, and MariaDB now supports M7i database (DB) instances in AWS Asia Pacific (Melbourne) region. M7i is the latest Intel based offering and is available with a new maximum instance size of 48xlarge, which brings 50% more vCPU and memory than the maximum size of M6i instance type.
M7i DB instances are available for Amazon RDS for PostgreSQL version 17.1 and higher, 16.1 and higher, 15.4 and higher, 14.9 and higher, and 13.11 and higher. M7i DB instances are also available for Amazon RDS for MySQL version 8.0.32 and higher, and Amazon RDS for MariaDB version 11.4, 10.11, 10.6, 10.5, and 10.4.
For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. Get started by creating any of these fully managed database instance using the Amazon RDS Management Console. For more details, refer to the Amazon RDS User Guide.
Amazon Relational Database Service (Amazon RDS) for PostgreSQL, MySQL, and MariaDB now supports M7i database (DB) instances in AWS Asia Pacific (Melbourne) region. M7i is the latest Intel based offering and is available with a new maximum instance size of 48xlarge, which brings 50% more vCPU and memory than the maximum size of M6i instance type. M7i DB instances are available for Amazon RDS for PostgreSQL version 17.1 and higher, 16.1 and higher, 15.4 and higher, 14.9 and higher, and 13.11 and higher. M7i DB instances are also available for Amazon RDS for MySQL version 8.0.32 and higher, and Amazon RDS for MariaDB version 11.4, 10.11, 10.6, 10.5, and 10.4. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. Get started by creating any of these fully managed database instance using the Amazon RDS Management Console. For more details, refer to the Amazon RDS User Guide.
Amazon Aurora with MySQL compatibility and PostgreSQL compatibility now supports R7i database instances in Asia Pacific (Osaka), Asia Pacific (Melbourne), Asia Pacific (Thailand) and Mexico (Central) regions. R7i database instances are powered by custom 4th Generation Intel Xeon Scalable processors. R7i instances offer larger instance sizes, up to 48xlarge and features an 8:1 ratio of memory to vCPU, and the latest DDR5 memory.
You can launch R7i database instances in the Amazon RDS Management Console or using the AWS CLI. Upgrading a database instance to R7i instance family requires a simple instance type modification. For more details, refer to the Aurora documentation.
Amazon Aurora is designed for unparalleled high performance and availability at global scale with PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
Amazon Aurora with MySQL compatibility and PostgreSQL compatibility now supports R7i database instances in Asia Pacific (Osaka), Asia Pacific (Melbourne), Asia Pacific (Thailand) and Mexico (Central) regions. R7i database instances are powered by custom 4th Generation Intel Xeon Scalable processors. R7i instances offer larger instance sizes, up to 48xlarge and features an 8:1 ratio of memory to vCPU, and the latest DDR5 memory. You can launch R7i database instances in the Amazon RDS Management Console or using the AWS CLI. Upgrading a database instance to R7i instance family requires a simple instance type modification. For more details, refer to the Aurora documentation. Amazon Aurora is designed for unparalleled high performance and availability at global scale with PostgreSQL compatibility. It provides built-in security, continuous backups, serverless compute, up to 15 read replicas, automated multi-Region replication, and integrations with other AWS services. To get started with Amazon Aurora, take a look at our getting started page.
Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB now supports AWS Graviton3-based R7g in AWS GovCloud (US-East), Asia Pacific (Osaka), Europe (Zurich), Asia Pacific (Jakarta), Israel (Tel Aviv) and Canada West (Calgary) regions. Graviton3-based instances provide up to a 30% performance improvement over Graviton2-based instances on RDS for open-source databases depending on database engine, version, and workload.
Graviton3 processors offer several improvements over the second-generation Graviton2 processors. Graviton3-based R7g is the first AWS database instances to feature the latest DDR5 memory, which provides 50% more memory bandwidth compared to DDR4, enabling high-speed access to data in memory. R7g database instances offer up to 30Gbps enhanced networking bandwidth and up to 20 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). R7g on Amazon RDS for MySQL and MariaDB will also support Optimized Writes. With Optimized Writes you can improve write throughout by up to 2x at no additional cost.
R7g database instances are supported on RDS for MySQL versions 8.0 and 8.4, RDS for PostgreSQL versions 13.4 (and higher), 14.5 (and higher), 15, 16 and 17 and RDS for MariaDB versions 10.4, 10.5, 10.6, 10.11 and 11.4. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. Get started using the Amazon RDS Management Console.
Amazon Relational Database Service (RDS) for PostgreSQL, MySQL, and MariaDB now supports AWS Graviton3-based R7g in AWS GovCloud (US-East), Asia Pacific (Osaka), Europe (Zurich), Asia Pacific (Jakarta), Israel (Tel Aviv) and Canada West (Calgary) regions. Graviton3-based instances provide up to a 30% performance improvement over Graviton2-based instances on RDS for open-source databases depending on database engine, version, and workload. Graviton3 processors offer several improvements over the second-generation Graviton2 processors. Graviton3-based R7g is the first AWS database instances to feature the latest DDR5 memory, which provides 50% more memory bandwidth compared to DDR4, enabling high-speed access to data in memory. R7g database instances offer up to 30Gbps enhanced networking bandwidth and up to 20 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). R7g on Amazon RDS for MySQL and MariaDB will also support Optimized Writes. With Optimized Writes you can improve write throughout by up to 2x at no additional cost. R7g database instances are supported on RDS for MySQL versions 8.0 and 8.4, RDS for PostgreSQL versions 13.4 (and higher), 14.5 (and higher), 15, 16 and 17 and RDS for MariaDB versions 10.4, 10.5, 10.6, 10.11 and 11.4. For complete information on pricing and regional availability, please refer to the Amazon RDS pricing page. Get started using the Amazon RDS Management Console.
