AWS Security Hub now supports Amazon Route 53 Resolver DNS Firewall, allowing you to receive security findings for DNS queries made from your Amazon VPCs for domains suspected as malicious or identified as low-reputation. Route 53 Resolver DNS Firewall is a managed firewall that enables you to block DNS queries made for malicious domains and to allow queries for trusted domains.
Today, AWS Security Hub gives you a comprehensive view of your security alerts and compliance status across your AWS accounts. This integration allows you to enable three new finding types for Security Hub. You can now receive security findings for queries blocked or alerted on for domains associated with AWS Managed Domain Lists, customer domain lists, and threats identified by Route 53 Resolver DNS Firewall Advanced. With this launch, you now have a single place to view security findings for your accounts that may be associated with malicious DNS queries, alongside findings from multiple AWS services, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie.
The feature is available in all AWS Regions where Amazon Route 53 Resolver DNS Firewall is available. See here for the list of AWS Regions where Route 53 Resolver DNS Firewall is available. To learn more about AWS Security Hub capabilities, see the AWS Security Hub documentation. To learn more about Route 53 Resolver DNS Firewall, see the product page or documentation.
AWS Security Hub now supports Amazon Route 53 Resolver DNS Firewall, allowing you to receive security findings for DNS queries made from your Amazon VPCs for domains suspected as malicious or identified as low-reputation. Route 53 Resolver DNS Firewall is a managed firewall that enables you to block DNS queries made for malicious domains and to allow queries for trusted domains. Today, AWS Security Hub gives you a comprehensive view of your security alerts and compliance status across your AWS accounts. This integration allows you to enable three new finding types for Security Hub. You can now receive security findings for queries blocked or alerted on for domains associated with AWS Managed Domain Lists, customer domain lists, and threats identified by Route 53 Resolver DNS Firewall Advanced. With this launch, you now have a single place to view security findings for your accounts that may be associated with malicious DNS queries, alongside findings from multiple AWS services, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie. The feature is available in all AWS Regions where Amazon Route 53 Resolver DNS Firewall is available. See here for the list of AWS Regions where Route 53 Resolver DNS Firewall is available. To learn more about AWS Security Hub capabilities, see the AWS Security Hub documentation. To learn more about Route 53 Resolver DNS Firewall, see the product page or documentation.
In addition to the currencies already supported, AWS US customers can choose to pay in Chilean Peso (CLP), Colombian Peso (COP), and Uruguayan Peso (UYU). Similarly, AWS Europe customers can pay in Egyptian Pound (EGP), Nigerian Naira (NGN), Polish Zloty (PLN), Romanian Leu (RON), Ukrainian Hryvnia (UAH).
Local currencies are important in localizing the payment experience for customers. With payments in their local currencies, customers can avoid foreign exchange costs associated making foreign currency payments. Also, it removes payment friction for customers in countries where local regulations put limits on the foreign currency amount a customer can access.
Log in to your AWS account, go to the “Billing and Cost Management“ page, and select “Payment Preferences” under Preferences and Settings“ from the left navigation menu . Click ”Edit“ to change your default payment preferences, and select your preferred currency from the ”Payment currency“ drop down. Once you save your changes, AWS will generate your future invoices in the selected currency.
In addition to the currencies already supported, AWS US customers can choose to pay in Chilean Peso (CLP), Colombian Peso (COP), and Uruguayan Peso (UYU). Similarly, AWS Europe customers can pay in Egyptian Pound (EGP), Nigerian Naira (NGN), Polish Zloty (PLN), Romanian Leu (RON), Ukrainian Hryvnia (UAH). Local currencies are important in localizing the payment experience for customers. With payments in their local currencies, customers can avoid foreign exchange costs associated making foreign currency payments. Also, it removes payment friction for customers in countries where local regulations put limits on the foreign currency amount a customer can access. Log in to your AWS account, go to the “Billing and Cost Management“ page, and select “Payment Preferences” under Preferences and Settings“ from the left navigation menu . Click ”Edit“ to change your default payment preferences, and select your preferred currency from the ”Payment currency“ drop down. Once you save your changes, AWS will generate your future invoices in the selected currency. Learn more about managing your AWS payments.
Satya Nadella, presidente y director ejecutivo, compartió la siguiente comunicación con los empleados de Microsoft esta mañana.
Al comenzar el nuevo año, está claro que hemos ingresado en las próximas entradas de este cambio de plataforma de IA. 2025 se tratará de aplicaciones de modelo avanzado que remodelarán todas las categorías de aplicaciones. Más que cualquier cambio de plataforma anterior, todas las capas de la pila de aplicaciones se verán afectadas. Es similar a la interfaz gráfica de usuario, los servidores de Internet y las bases de datos nativas de la nube que se introducen en la pila de aplicaciones de manera simultánea. ¡Treinta años de cambio se han comenzado a comprimir en tres años!
Crearemos aplicaciones agenticas con memoria, derechos y espacio de acción que heredarán potentes capacidades de modelo. Y adaptaremos estas capacidades para mejorar el rendimiento y la seguridad en todos los roles, procesos de negocio y dominios de la industria. Además, la forma en que construimos, implementamos y mantenemos el código para estas aplicaciones de IA también ha comenzado a cambiar de manera fundamental y se ha comenzado a convertir en una forma enfocada en agentes.
Esto da lugar a una nueva pila de aplicaciones que da prioridad a la IA, con nuevos patrones de interfaz de usuario y experiencia de usuario, tiempos de ejecución para crear con agentes, orquestar varios agentes y una capa de gestión y observabilidad reinventada. En este mundo, Azure debe convertirse en la infraestructura para la IA, mientras construimos nuestra plataforma de IA y nuestras herramientas de desarrollo, que abarcan Azure AI Foundry, GitHub y VS Code, sobre ella. En otras palabras, nuestra plataforma y herramientas de IA se unirán para crear agentes, y estos agentes se unirán para cambiar todas las categorías de aplicaciones SaaS, y la creación de aplicaciones personalizadas será impulsada por software (es decir, «servicio como software»).
La buena noticia es que hemos trabajado en esto durante más de dos años y hemos aprendido mucho en términos de los sistemas, la plataforma de aplicaciones y las herramientas necesarias para la era de la IA. Para avanzar de manera más rápida y audaz en nuestra hoja de ruta en cada una de estas capas, hemos creado una nueva organización de ingeniería: CoreAI – Plataforma y Herramientas.
Esta nueva división reunirá a Dev Div, AI Platform y algunos equipos clave de la Oficina del CTO (AI Supercomputer, AI Agentic Runtimes e Engineering Thrive), con la misión de construir la pila de Copilot e IA de extremo a extremo para que nuestros clientes propios y de terceros creen y ejecuten aplicaciones y agentes de IA. Este grupo también desarrollará GitHub Copilot, por lo que tendrá un estrecho ciclo de retroalimentación entre el producto líder de IA y la plataforma de IA para motivar la pila y su hoja de ruta.
Jay Parikh liderará este grupo como vicepresidente ejecutivo de CoreAI – Plataforma y Herramientas, con Eric Boyd, Jason Taylor, Julia Liuson, Tim Bozarth y sus respectivos equipos que reportarán a Jay.
Jay trabajará en estrecha colaboración con Scott, Rajesh, Charlie, Mustafa y Kevin para optimizar toda nuestra pila tecnológica tanto en rendimiento como en eficiencia. Además, Jay y su equipo liderarán nuestro progreso y trabajarán en torno a la productividad de los desarrolladores y el desarrollo de la ingeniería en toda la empresa.
A medida que nuestro negocio de infraestructura en la nube continúa con su crecimiento y escala para convertirse en el negocio más grande de Microsoft, Scott continuará como líder de Cloud + AI para garantizar que brindemos la calidad, la seguridad y la innovación con las que cuentan nuestros clientes y socios para sus aplicaciones, bases de datos y cargas de trabajo de IA de misión más crítica.
En última instancia, debemos recordar que nuestros límites organizativos internos no tienen sentido ni para nuestros clientes ni para nuestros competidores. Cuando hablamos de operar como One Microsoft, hablamos de cómo aumentamos de manera continua nuestro enfoque en el cliente, elevamos el nivel de nuestra innovación e impulsamos la responsabilidad, para que en verdad podamos estar a la altura de nuestra misión.
Nuestro éxito en esta próxima fase estará determinado por contar con la mejor plataforma, herramientas e infraestructura de IA. Tenemos mucho trabajo por hacer y una tremenda oportunidad por delante, y juntos, estoy ansioso por construir lo que viene a continuación.
El equipo rojo de IA se formó en 2018 para abordar el creciente panorama de los riesgos de seguridad y protección de la IA. Desde entonces, hemos ampliado de manera significativa el alcance y la escala de nuestro trabajo. Somos uno de los primeros equipos rojos de la industria que cubre tanto la seguridad como la IA responsable, y realizar acciones de equipo rojo (red teaming) se ha convertido en una parte clave del enfoque de Microsoft para el desarrollo de productos de IA generativa. El trabajo en equipo rojo es el primer paso para identificar daños potenciales y es seguido por importantes iniciativas en la empresa para medir, gestionar y gobernar el riesgo de IA para nuestros clientes. El año pasado, también anunciamos PyRIT (The Python Risk Identification Tool for generative AI), un conjunto de herramientas de código abierto para ayudar a los investigadores a identificar vulnerabilidades en sus propios sistemas de IA.
Gráfico circular que muestra el desglose porcentual de los productos probados por el equipo rojo de Microsoft AI. Hasta octubre de 2024, habíamos hecho equipo rojo con más de 100 productos de IA generativa.
Con un enfoque en nuestra misión ampliada, ahora hemos creado un equipo rojo de más de 100 productos de IA generativa. El documento técnico que publicamos ahora proporciona más detalles sobre nuestro enfoque del equipo rojo de IA e incluye los siguientes aspectos destacados:
Nuestra ontología de equipo rojo de IA, que utilizamos para modelar los componentes principales de un ciberataque, incluidos los actores adversarios o benignos, los TTP (Tácticas, Técnicas y Procedimientos), las debilidades del sistema y los impactos posteriores. Esta ontología proporciona una forma coherente de interpretar y diseminar una amplia gama de hallazgos de seguridad y protección.
Ocho lecciones principales aprendidas de nuestra experiencia en la creación de equipos de más de 100 productos de IA generativa. Estas lecciones están dirigidas a los profesionales de la seguridad que buscan identificar riesgos en sus propios sistemas de IA y arrojan luz sobre cómo alinear los esfuerzos de equipo rojo con los daños potenciales en el mundo real.
Cinco estudios de caso de nuestras operaciones, que destacan la amplia gama de vulnerabilidades que buscamos, incluida la seguridad tradicional, la IA responsable y los daños psicosociales. Cada caso de estudio demuestra cómo se utiliza nuestra ontología para capturar los componentes principales de un ataque o vulnerabilidad del sistema.
El equipo rojo de IA de Microsoft aborda una multitud de escenarios
A lo largo de los años, el equipo rojo de IA ha abordado una amplia variedad de escenarios con los que tal vez también se hayan encontrado otras organizaciones. Nos centramos en las vulnerabilidades que tienen más probabilidades de causar daño en el mundo real, y nuestro documento técnico comparte estudios de casos de nuestras operaciones que destacan cómo lo hemos hecho en cuatro escenarios, incluida la seguridad, la IA responsable, las capacidades peligrosas (como la capacidad de un modelo para generar contenido peligroso) y los daños psicosociales. Como resultado, somos capaces de reconocer una variedad de posibles amenazas cibernéticas y adaptarnos con rapidez cuando nos enfrentamos a otras nuevas.
Esta misión le ha dado a nuestro equipo rojo una amplia gama de experiencias para enfrentar con habilidad los riesgos, sin importar:
Tipo de sistema, incluido Microsoft Copilot, modelos integrados en sistemas y modelos de código abierto.
Modalidad, ya sea de texto a texto, de texto a imagen o de texto a vídeo.
Tipo de usuario: el riesgo del usuario empresarial, por ejemplo, es diferente de los riesgos del consumidor y requiere un enfoque único de acciones de equipo rojo. Las audiencias de nicho, como las de una industria específica como la atención médica, también merecen un enfoque matizado.
Las tres principales conclusiones del documento técnico
El equipo rojo de IA es una práctica para sondear la seguridad de los sistemas de IA generativa. En pocas palabras, «rompemos» la tecnología para que otros puedan reconstruirla más fuerte. Años de aplicar acciones de equipo rojo nos han dado una visión invaluable de las estrategias más efectivas. Al reflexionar sobre las ocho lecciones discutidas en el documento técnico, podemos destilar tres puntos principales que los líderes empresariales deben saber.
Conclusión 1: Los sistemas de IA generativa amplifican los riesgos de seguridad existentes e introducen otros nuevos
La integración de modelos de IA generativa en aplicaciones modernas ha introducido nuevos vectores de ciberataque. Sin embargo, muchas discusiones en torno a la seguridad de la IA pasan por alto las vulnerabilidades existentes. Los equipos rojos de IA deben prestar atención a los vectores de ciberataque, tanto antiguos como nuevos.
Riesgos de seguridad existentes: Los riesgos de seguridad de las aplicaciones a menudo se derivan de prácticas de ingeniería de seguridad inadecuadas, incluidas dependencias obsoletas, manejo inadecuado de errores, credenciales en el origen, falta de saneamiento de entrada y salida y cifrado de paquetes inseguro. Uno de los casos de estudio de nuestro documento técnico describe cómo un componente FFmpeg obsoleto en una aplicación de IA de procesamiento de video introdujo una vulnerabilidad de seguridad conocida llamada falsificación de solicitudes del lado del servidor (SSRF), que podría permitir a un adversario escalar los privilegios de su sistema.
Ilustración de la vulnerabilidad SSRF en la aplicación de IA generativa de procesamiento de vídeo.
Debilidades a nivel de modelo: Los modelos de IA han ampliado la superficie de ciberataque mediante la introducción de nuevas vulnerabilidades. Las inyecciones rápidas, por ejemplo, explotan el hecho de que los modelos de IA a menudo tienen dificultades para distinguir entre las instrucciones a nivel de sistema y los datos del usuario. Nuestro documento técnico incluye un estudio de caso de acciones de equipo rojo sobre cómo utilizamos las inyecciones rápidas para engañar a un modelo de lenguaje de visión.
Consejo del equipo rojo: Los equipos rojos de IA deben estar atentos a los nuevos vectores de ciberataque mientras permanecen atentos a los riesgos de seguridad existentes. Las mejores prácticas de seguridad de la IA deben incluir una higiene cibernética básica.
Conclusión 2: Los humanos están en el centro de la mejora y la seguridad de la IA
Si bien las herramientas de automatización son útiles para crear avisos, orquestar ciberataques y calificar respuestas, las acciones de equipo rojo no se puede automatizar por completo. Las acciones de equipo rojo de IA dependen en gran medida de la experiencia humana.
Los seres humanos son importantes por varias razones, entre ellas:
Experiencia en la materia: los LLM son capaces de evaluar si la respuesta de un modelo de IA contiene discurso de odio o contenido sexual explícito, pero no son tan fiables a la hora de evaluar el contenido en áreas especializadas como la medicina, la ciberseguridad y la CBRN (química, biológica, radiológica y nuclear). Estas áreas requieren expertos en la materia que puedan evaluar el riesgo del contenido para los equipos rojos de IA.
Competencia cultural: Los modelos de lenguaje moderno utilizan de manera principal datos de entrenamiento en inglés, puntos de referencia de rendimiento y evaluaciones de seguridad. Sin embargo, a medida que los modelos de IA se despliegan en todo el mundo, es crucial diseñar sondas de equipo rojo que no solo tengan en cuenta las diferencias lingüísticas, sino que también redefinan los daños en diferentes contextos políticos y culturales. Estos métodos solo pueden desarrollarse a través del esfuerzo colaborativo de personas con diversos antecedentes culturales y experiencia.
Inteligencia emocional: En algunos casos, se requiere inteligencia emocional para evaluar los resultados de los modelos de IA. Uno de los estudios de caso de nuestro documento técnico analiza cómo investigamos los daños psicosociales mediante la investigación de cómo responden los chatbots a los usuarios en apuros. En última instancia, solo los humanos pueden evaluar por completo la gama de interacciones que los usuarios pueden tener con los sistemas de IA en la naturaleza.
Consejo del equipo rojo: Adopten herramientas como PyRIT para ampliar las operaciones, pero mantengan a los humanos en el circuito de equipo rojo para tener el mayor éxito en la identificación de vulnerabilidades impactantes de seguridad y protección de la IA.
Conclusión 3: La defensa en profundidad es clave para mantener seguros los sistemas de IA
Se han desarrollado numerosas mitigaciones para abordar los riesgos de seguridad que plantean los sistemas de IA. Sin embargo, es importante recordar que las mitigaciones no eliminan el riesgo por completo. En última instancia, aplicar acciones de equipo rojo de IA es un proceso continuo que debe adaptarse a la rápida evolución del panorama de riesgos y tener como objetivo aumentar el coste de atacar con éxito un sistema tanto como sea posible.
Nuevas categorías de daño: A medida que los sistemas de IA se vuelven más sofisticados, a menudo introducen categorías de daño nuevas. Por ejemplo, uno de nuestros estudios de caso explica cómo probamos un LLM de última generación en busca de capacidades persuasivas riesgosas. Los equipos rojos de IA deben actualizar de manera constante sus prácticas para anticipar y sondear estos nuevos riesgos.
Economía de la ciberseguridad: Todos los sistemas son vulnerables porque los humanos son falibles y los adversarios son persistentes. Sin embargo, pueden disuadir a los adversarios a través de aumentar el costo de atacar un sistema más allá del valor que se obtendría. Una forma de aumentar el coste de los ciberataques es mediante el uso de ciclos de reparación de averías.1 Esto implica llevar a cabo múltiples rondas de acciones de equipo rojo, medición y mitigación, a veces denominadas «purple teaming», para fortalecer el sistema para manejar una variedad de ataques.
Acción del gobierno: La acción de la industria para defenderse contra los ciberatacantes y los fracasos es una cara de la moneda de la seguridad de la IA. El otro lado es la acción del gobierno de una manera que podría disuadir y desalentar estos fracasos más amplios. Tanto el sector público como el privado deben demostrar compromiso y vigilancia, para garantizar que los ciberatacantes ya no tengan la sartén por el mango y que la sociedad en general pueda beneficiarse de los sistemas de IA que son seguros de manera inherente.
Consejo del equipo rojo: Actualicen de manera continua sus prácticas para tener en cuenta los daños novedosos, utilicen ciclos de reparación de averías para que los sistemas de IA sean lo más seguros posible e inviertan en técnicas sólidas de medición y mitigación.
Mejoren su experiencia en equipos rojos de IA
El documento técnico «Lessons From Red Teaming 100 Generative AI Products» incluye nuestra ontología de equipo rojo de IA, lecciones aprendidas adicionales y cinco estudios de casos de nuestras operaciones. Esperamos que el artículo y la ontología les resulten útiles para organizar sus propios ejercicios de red teaming de IA y desarrollar más estudios de casos para aprovechar las ventajas de PyRIT, nuestro marco de automatización de código abierto.
Juntos, la comunidad de ciberseguridad puede refinar sus enfoques y compartir las mejores prácticas para abordar de manera efectiva los desafíos que se avecinan. Descarguen nuestro documento técnico de acciones de equipo rojo para obtener más información sobre lo que hemos aprendido. A medida que avanzamos en nuestro propio recorrido de aprendizaje continuo, agradeceríamos sus comentarios y escuchar sobre sus propias experiencias de equipo rojo de IA.
Más información de Microsoft Security
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.
You can now evaluate agent performance on emails in Amazon Connect, enabling managers to assess agent performance across contact channels (voice, chat, email, and tasks) in a single easy-to-use web interface, and get aggregated insights across cohorts of agents over time. With this launch, managers can evaluate agent performance by reviewing email threads and additional details of the email interaction (e.g., handle time) in a single UI. Contact centers can also use public APIs to incorporate data from third-party systems (e.g., CSAT, sales volumes, customer retention, etc.) into performance evaluations of email contacts, providing managers with comprehensive insights on agent performance.
This feature is available in all regions where Contact Lens performance evaluations is already available. To learn more, please visit our documentation and our webpage. For information about Contact Lens pricing, please visit our pricing page.
You can now evaluate agent performance on emails in Amazon Connect, enabling managers to assess agent performance across contact channels (voice, chat, email, and tasks) in a single easy-to-use web interface, and get aggregated insights across cohorts of agents over time. With this launch, managers can evaluate agent performance by reviewing email threads and additional details of the email interaction (e.g., handle time) in a single UI. Contact centers can also use public APIs to incorporate data from third-party systems (e.g., CSAT, sales volumes, customer retention, etc.) into performance evaluations of email contacts, providing managers with comprehensive insights on agent performance. This feature is available in all regions where Contact Lens performance evaluations is already available. To learn more, please visit our documentation and our webpage. For information about Contact Lens pricing, please visit our pricing page.
Today, AWS End User Messaging launched self-service Sender ID registrations for 19 additional countries, helping developers correctly configure SMS messaging for their applications. The new countries include Australia, Belarus, Egypt, India, Indonesia, Jordan, Kenya, Kuwait, Kazakhstan, Philippines, Qatar, Russia, Saudi Arabia, Singapore, Sri Lanka, Thailand, Turkey, United Arab Emirates, Vietnam, and Zambia.
Phone numbers and sender IDs act as an extension of a business’s brand, and mobile carriers and governments worldwide have implemented SMS registrations as a form of «know your customer» check to protect end-users from unwanted and spam messages. By registering, application developers ensure a higher level of deliverability and ensure their use-cases comply with local rules and regulations, avoiding message filtering.
Previously, customers needed to open a support case to request these sender IDs, but now they can self-service via the AWS Management Console or programmatically via the APIs, saving time-to-onboard. The registration support is available in all commercial regions where AWS End User Messaging is generally available.
Today, AWS End User Messaging launched self-service Sender ID registrations for 19 additional countries, helping developers correctly configure SMS messaging for their applications. The new countries include Australia, Belarus, Egypt, India, Indonesia, Jordan, Kenya, Kuwait, Kazakhstan, Philippines, Qatar, Russia, Saudi Arabia, Singapore, Sri Lanka, Thailand, Turkey, United Arab Emirates, Vietnam, and Zambia. Phone numbers and sender IDs act as an extension of a business’s brand, and mobile carriers and governments worldwide have implemented SMS registrations as a form of «know your customer» check to protect end-users from unwanted and spam messages. By registering, application developers ensure a higher level of deliverability and ensure their use-cases comply with local rules and regulations, avoiding message filtering. Previously, customers needed to open a support case to request these sender IDs, but now they can self-service via the AWS Management Console or programmatically via the APIs, saving time-to-onboard. The registration support is available in all commercial regions where AWS End User Messaging is generally available.
Amazon RDS for MariaDB now supports MariaDB Innovation Release 11.7 in the Amazon RDS Database Preview Environment, allowing you to evaluate the latest Innovation Release on Amazon RDS for MariaDB. You can deploy MariaDB 11.7 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database, making it simpler to set up, operate, and monitor databases.
MariaDB 11.7 is the latest Innovation Release from the MariaDB community, and includes support for vector datatype, indexing, and search capabilities. MariaDB Innovation releases are supported by the community until the next Innovation release, whereas MariaDB Long Term Maintenance Releases, such as MariaDB 10.11 and MariaDB 11.4, are supported by the community for up to five years. Please refer to the MariaDB 11.7 release notes for more details about this release.
The Amazon RDS Database Preview Environment supports both Single-AZ and Multi-AZ deployments on the latest generation of instance classes. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment.
Amazon RDS for MariaDB now supports MariaDB Innovation Release 11.7 in the Amazon RDS Database Preview Environment, allowing you to evaluate the latest Innovation Release on Amazon RDS for MariaDB. You can deploy MariaDB 11.7 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database, making it simpler to set up, operate, and monitor databases. MariaDB 11.7 is the latest Innovation Release from the MariaDB community, and includes support for vector datatype, indexing, and search capabilities. MariaDB Innovation releases are supported by the community until the next Innovation release, whereas MariaDB Long Term Maintenance Releases, such as MariaDB 10.11 and MariaDB 11.4, are supported by the community for up to five years. Please refer to the MariaDB 11.7 release notes for more details about this release. The Amazon RDS Database Preview Environment supports both Single-AZ and Multi-AZ deployments on the latest generation of instance classes. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment. Amazon RDS Database Preview Environment database instances are priced the same as production RDS instances created in the US East (Ohio) Region.
AWS CodeBuild has expanded its batch build capabilities to include support for reserved capacity fleets and Lambda compute. This enhancement allows you to select a mix of on-demand instances, reserved capacity fleets, or Lambda compute resources for your build batches. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment.
Batch builds in CodeBuild enable the simultaneous execution of multiple, coordinated builds within a project. This feature is particularly beneficial for developers working on multi-platform projects or those with interdependent build processes. You can define the build sequence using various methods, such as a build list, a build matrix, or a dependency graph of build definitions. CodeBuild then manages the orchestration of these builds, streamlining the overall development and integration process.
The new compute options are now available in US East (N. Virginia), US East (Ohio), US West (Oregon), South America (Sao Paulo), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Mumbai), Europe (Ireland), and Europe (Frankfurt). For more information about the AWS Regions where CodeBuild is available, see the AWS Regions page.
To learn more about running batch builds in CodeBuild, please visit our documentation. To learn more about how to get started with CodeBuild, visit the AWS CodeBuild product page.
AWS CodeBuild has expanded its batch build capabilities to include support for reserved capacity fleets and Lambda compute. This enhancement allows you to select a mix of on-demand instances, reserved capacity fleets, or Lambda compute resources for your build batches. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages ready for deployment. Batch builds in CodeBuild enable the simultaneous execution of multiple, coordinated builds within a project. This feature is particularly beneficial for developers working on multi-platform projects or those with interdependent build processes. You can define the build sequence using various methods, such as a build list, a build matrix, or a dependency graph of build definitions. CodeBuild then manages the orchestration of these builds, streamlining the overall development and integration process. The new compute options are now available in US East (N. Virginia), US East (Ohio), US West (Oregon), South America (Sao Paulo), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Mumbai), Europe (Ireland), and Europe (Frankfurt). For more information about the AWS Regions where CodeBuild is available, see the AWS Regions page. To learn more about running batch builds in CodeBuild, please visit our documentation. To learn more about how to get started with CodeBuild, visit the AWS CodeBuild product page.
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C8g instances are available in AWS Europe (Ireland) and AWS Europe (Spain) regions. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 C8g instances are built for general-purpose workloads, such as application servers, microservices, gaming servers, midsize data stores, and caching fleets. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads.
AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. These instances offer larger instance sizes with up to 3x more vCPUs and memory compared to Graviton3-based Amazon C7g instances. AWS Graviton4 processors are up to 40% faster for databases, 30% faster for web applications, and 45% faster for large Java applications than AWS Graviton3 processors. C8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).
Starting today, Amazon Elastic Compute Cloud (Amazon EC2) C8g instances are available in AWS Europe (Ireland) and AWS Europe (Spain) regions. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 C8g instances are built for general-purpose workloads, such as application servers, microservices, gaming servers, midsize data stores, and caching fleets. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads. AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. These instances offer larger instance sizes with up to 3x more vCPUs and memory compared to Graviton3-based Amazon C7g instances. AWS Graviton4 processors are up to 40% faster for databases, 30% faster for web applications, and 45% faster for large Java applications than AWS Graviton3 processors. C8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). To learn more, see Amazon EC2 C8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.
AWS Marketplace launched email notification and Amazon EventBridge event that informs AWS Marketplace selling partners, including ISVs and Channel Partners, when their disbursements have been paused due to invalid bank account information. With this launch, selling partners can be alerted to these events and take immediate action to update their banking details so they receive their disbursements promptly.
Until now, AWS Marketplace selling partners had to check disbursement status in Insights tab in AMMP. With this release, disbursement paused events that are caused by invalid bank accounts will be sent to Amazon EventBridge and AWS Marketplace sellers can subscribe to these events by defining appropriate rule patterns. Each event will contain a failure reason, payment instrument ARN that is invalid, and a link to the remediation steps. The source for these EventBridge events is aws.marketplace and the possible detail-type value is Disbursement Paused.
AWS Marketplace launched email notification and Amazon EventBridge event that informs AWS Marketplace selling partners, including ISVs and Channel Partners, when their disbursements have been paused due to invalid bank account information. With this launch, selling partners can be alerted to these events and take immediate action to update their banking details so they receive their disbursements promptly. Until now, AWS Marketplace selling partners had to check disbursement status in Insights tab in AMMP. With this release, disbursement paused events that are caused by invalid bank accounts will be sent to Amazon EventBridge and AWS Marketplace sellers can subscribe to these events by defining appropriate rule patterns. Each event will contain a failure reason, payment instrument ARN that is invalid, and a link to the remediation steps. The source for these EventBridge events is aws.marketplace and the possible detail-type value is Disbursement Paused. To learn more about this new email notification, see Managing email notifications for AWS Marketplace events – AWS Marketplace and to get started with creating event rules in Amazon EventBridge, see Amazon EventBridge events – AWS Marketplace.
