AWS IAM Identity Center now supports separate quotas for the number of AWS accounts and applications that can be configured in an IAM Identity Center instance. By default, you can configure up to 7,000 AWS accounts and up to 7,000 applications independently, so that using more of one does not consume capacity from the other. Quotas can be further increased by submitting a quota increase request through AWS Service Quotas console.
Customers with existing higher limits are automatically granted the same limit for both accounts and applications, with no action required. Organizations managing thousands of AWS accounts can now onboard applications without consuming account quota capacity.
This update is available in all AWS Regions where IAM Identity Center is available.
AWS IAM Identity Center now supports separate quotas for the number of AWS accounts and applications that can be configured in an IAM Identity Center instance. By default, you can configure up to 7,000 AWS accounts and up to 7,000 applications independently, so that using more of one does not consume capacity from the other. Quotas can be further increased by submitting a quota increase request through AWS Service Quotas console.
Customers with existing higher limits are automatically granted the same limit for both accounts and applications, with no action required. Organizations managing thousands of AWS accounts can now onboard applications without consuming account quota capacity.
This update is available in all AWS Regions where IAM Identity Center is available.
To learn more, see Quotas for IAM Identity Center. Visit the IAM Identity Center product page to get started.
AWS Network Firewall now uses «Application drop established (server-directed only)» as the default stateful action for all newly created firewall policies, replacing the previous default of «Application drop established (bidirectional)» (formerly named «Application layer drop established»). No action is required to benefit from this change when creating new policies.
AWS Network Firewall is a managed service that lets you deploy network protections across your Amazon VPCs. Previously, the “Application drop established (bidirectional)” default could silently drop legitimate server-to-client TCP packets, such as window updates, keep-alives, and resets — causing intermittent connection failures that were difficult to diagnose. With the safer default now in place, new policies avoid this issue.
If your existing environment requires “Application drop established (bidirectional)” to support post-quantum cryptography (PQC) fragmented TLS handshakes, refer to our documentation for guidance on on switching to «Application drop established (server-directed only)» or adding the “to_server” flag to your TCP drop rules so legitimate flow control packets are not blocked.
AWS Network Firewall now uses «Application drop established (server-directed only)» as the default stateful action for all newly created firewall policies, replacing the previous default of «Application drop established (bidirectional)» (formerly named «Application layer drop established»). No action is required to benefit from this change when creating new policies. AWS Network Firewall is a managed service that lets you deploy network protections across your Amazon VPCs. Previously, the “Application drop established (bidirectional)” default could silently drop legitimate server-to-client TCP packets, such as window updates, keep-alives, and resets — causing intermittent connection failures that were difficult to diagnose. With the safer default now in place, new policies avoid this issue. If your existing environment requires “Application drop established (bidirectional)” to support post-quantum cryptography (PQC) fragmented TLS handshakes, refer to our documentation for guidance on on switching to «Application drop established (server-directed only)» or adding the “to_server” flag to your TCP drop rules so legitimate flow control packets are not blocked. This update is available in all AWS Regions where AWS Network Firewall is offered. To get started, see Managing evaluation order for Suricata compatible rules in the AWS Network Firewall service documentation.
AWS Batch now offers the Best Fit Progressive Ordered (BFPO) and Spot Capacity Optimized Prioritized (SCOP) allocation strategies, giving you more control over instance type prioritization in your compute environments. BFPO and SCOP enable you to manually define instance type ordering based on your workload-specific performance characteristics.
To use these features in AWS Batch, specify BEST_FIT_PROGRESSIVE_ORDERED allocation strategy for your on-demand compute environments or SPOT_CAPACITY_OPTIMIZED_PRIORITIZED for your Amazon EC2 Spot compute environments and provide an ordered list of instance types or families. These features are available via the AWS Batch API (CreateComputeEnvironment or UpdateComputeEnvironment) or the AWS Batch Management Console.
BFPO and SCOP allocation strategies are supported today in all AWS Regions where AWS Batch is available. For more information, see the AWS Batch User Guide.
AWS Batch now offers the Best Fit Progressive Ordered (BFPO) and Spot Capacity Optimized Prioritized (SCOP) allocation strategies, giving you more control over instance type prioritization in your compute environments. BFPO and SCOP enable you to manually define instance type ordering based on your workload-specific performance characteristics. To use these features in AWS Batch, specify BEST_FIT_PROGRESSIVE_ORDERED allocation strategy for your on-demand compute environments or SPOT_CAPACITY_OPTIMIZED_PRIORITIZED for your Amazon EC2 Spot compute environments and provide an ordered list of instance types or families. These features are available via the AWS Batch API (CreateComputeEnvironment or UpdateComputeEnvironment) or the AWS Batch Management Console. BFPO and SCOP allocation strategies are supported today in all AWS Regions where AWS Batch is available. For more information, see the AWS Batch User Guide.
5 bases para transformar el futuro de la educación y la IA
Por: Mark Sparvell, director de Microsoft Education.
Pregunten a un responsable de contratación qué busca hoy y escucharán algo que hace dos años habría sonado inusual: no una lista más larga de herramientas, sino un conjunto más profundo de capacidades humanas. Una nueva investigación de Microsoft, Preparing Students for the Future of Work, revela que alrededor del 70% de las habilidades utilizadas en la mayoría de los empleos se espera que cambien para 2030, la alfabetización en IA aparece ahora en las ofertas de empleo unas seis veces más a menudo que hace un año, y el 66% de los líderes afirma que no contrataría a alguien sin habilidades en IA.
Para los educadores, es una oportunidad para moldear el futuro.
El éxito en la educación siempre ha dependido de la interacción entre conocimientos, aptitudes y habilidades. La formación de habilidades es la capacidad que convierte la nueva tecnología en una práctica segura y de confianza. La cuestión no es si preparar a los estudiantes para un mundo con forma de IA. Es cómo hacerlo de una manera que mantenga el florecimiento humano, no solo la empleabilidad, en el centro.
Esta frase, extraída de la conclusión del informe, merece la pena mantenerla. Las tecnologías van a continuar con los cambios. Lo que perdura es, con claridad, humano: curiosidad, juicio, capacidad de aprender y reaprender, y la sabiduría para aplicar bien el conocimiento. La OCDE presenta el mismo argumento en su marco de 2025, Educación para el Florecimiento Humano, que sostiene que la educación debe ayudar a cada alumno a vivir «una vida que tenga motivos para valorar», para ir más allá de una visión limitada basada en el capital humano sobre la educación.1
En conjunto, los informes señalan un patrón constante: el mercado laboral actual recompensa cada vez más a las personas que pueden aplicar su inteligencia, adaptarse al contexto y no dejar de aprender. Por tanto, el propósito duradero de la educación es desarrollar y perfeccionar esas habilidades y disposiciones.
La curiosidad, el juicio y la capacidad de aprender se desarrollan a través de una colaboración significativa, no solo de la tecnología.
Cinco nuevos fundamentos que remodelan lo que significa estar preparado
El informe de la OCDE identifica cinco cambios que redibujan de manera discreta la línea entre «nivel de entrada» y «experimentado». Para las escuelas y universidades, el informe señala que se construye la preparación para la IA no solo a través del acceso a la tecnología, sino también mediante capacidades humanas, gobernanza y experiencia práctica que ayudan a la IA a funcionar de forma responsable.
Expectativas elevadas para los niveles de entrada
Trabajar con IA como socio para convertirse en un «jefe agente»
Ingeniería del contexto
Juicio, voz y el estándar humano
Desde credenciales hasta capacidades
Habilidades de arraigo en el florecimiento humano
Si esos cinco fundamentos describen lo que ahora recompensa el lugar de trabajo, el marco de la OCDE describe la base humana que hay bajo ellos. Se centra en actuar en el mundo con la capacidad de moldear la propia vida y contribuir a los demás. Esto se apoya en cuatro competencias:
Resolución adaptativa de problemas
Competencia ética
Entender el mundo
Apreciar el mundo
La superposición es llamativa. La «ingeniería de contexto» y la mentalidad de «jefe agente» son soluciones adaptativas de problemas en un medio nuevo. «El juicio y el estándar humano» es competencia ética hecha práctica. Desarrollar habilidades para el futuro del trabajo y educar para una vida próspera no son objetivos en competencia; si se hace bien, son el mismo trabajo.
La autonomía, la resolución de problemas y el juicio ético crecen cuando los alumnos tienen el espacio y el apoyo para aplicarlos.
Cómo se ve esto en las aulas hoy en día
Esto no es teórico. Las escuelas y universidades ya han convertido estas ideas en la práctica cotidiana, y los primeros resultados son alentadores.
En las Escuelas del Condado de Fulton, los estudiantes utilizan la IA como un socio de reflexión para explorar ideas, generar confianza y abordar problemas del mundo real, para cambiar el aprendizaje del uso de la tecnología a la creación con ella en un distrito que atiende a casi 87.000 estudiantes.
En la Universidad de Sídney, la plataforma «Cogniti» permite a los educadores diseñar herramientas de IA que guían a los estudiantes a través del razonamiento—un ejemplo práctico de enseñar a los estudiantes a dirigir la IA, no solo a usarla.
La Universidad de California en San Diego rediseñó un curso introductorio de informática centrado en GitHub Copilot, para ayudar a los estudiantes a completar tareas de programación más rápido, construir proyectos más ambiciosos y desarrollar habilidades prácticas de IA para el entorno laboral.
En la educación K-12 y superior, el patrón es el mismo: la IA está integrada en el aprendizaje y la enseñanza cotidianos, para construir la alfabetización y adaptabilidad que los empleadores describen como «capacitada para toda la vida».
Empoderar a los educadores para que fomenten estas habilidades es uno de los objetivos del programa Microsoft Elevate for Educators. Está diseñado para proporcionar a educadores y líderes escolares acceso a una comunidad global, credenciales y oportunidades de formación para integrar con confianza la IA en la enseñanza y el aprendizaje.
Saber qué habilidades importan es el primer paso. Construirlas, a gran escala, es lo siguiente. Estén atentos a nuestras próximas entradas de blog que detallan los productos y programas que ayudan a los educadores a poner en práctica esta intención de capacitación, desde herramientas de IA listas para el aula hasta aprendizaje profesional que llega a los educadores donde se encuentran.
IA en el trabajo: Rediseñar primero. Luego la IA tan solo comienza a trabajar
Las organizaciones no se transforman mediante mejores modelos: lo hacen al volver a elaborar la manera en que se ejecutan las tareas, de modo que la tecnología se vuelve invisible dentro de ellas.
Por: Jared Spataro, CMO de IA en el Trabajo de Microsoft.
El comentario más compartido sobre la IA ahora mismo parte de una observación difícil de discutir: la brecha entre lo que pueden hacer los modelos actuales y lo que las empresas despliegan es enorme, y eso genera frustración. Ethan Mollick captó esa sensación de más más contundente en un artículo reciente para The Economist, donde argumenta que las empresas domestican la IA antes de que tenga la oportunidad de hacer su mejor trabajo—que la gobernanza de TI, los procesos aversos al riesgo y el impulso de adaptar la tecnología a las estructuras existentes son el principal cuello de botella. Erik Brynjolfsson en Stanford lleva 30 años en documentar por qué ocurre esto. Su marco de curvas en J—el patrón de caída antes del pago que suele seguir la adopción tecnológica—es la arquitectura intelectual detrás de la afirmación de que el retraso organizativo, y no la calidad del modelo, determina si una tecnología se acumula o se estanca.
Ambos tienen razón. El diagnóstico es grave y fundamentado. Lo que añadiría es una interpretación diferente de qué crea la brecha en primer lugar.
Aquí está la parte que yo insistiría. La fricción que Mollick argumenta que las empresas deberían desmantelar—el control burocrático, el impulso de sobreindexar pilotos y experimentación—no es la misma que la infraestructura que permite escalar a la IA. Identidad. Permisos. Una conexión con los datos sobre los que en verdad funciona su negocio. Un registro de lo que hicieron los agentes de IA y por qué. Integración con las herramientas donde ya hay trabajo. Esa capa no es donde la IA va a morir. Es lo que permite que la IA desaparezca dentro del trabajo, lo cual es una condición necesaria para la escala.
Cómo se difunde la tecnología
Geoffrey Moore documentó el patrón en Cruzando el Abismo: los comportamientos que definen a los primeros adoptantes —la disposición a realizar actos antinaturales para una tecnología que aún no es fluida— son justo lo que los hace poco representativos de los demás. Los pragmáticos no cruzan el abismo porque la tecnología se vuelve más capaz. La cruzan cuando la tecnología les encuentra dentro del trabajo que ya realizan.
La web no transformó el comercio mediante experimentos exóticos de navegadores. Transformó el comercio cuando se convirtió en la capa invisible bajo lo que Amazon construyó—cuando pedir pasta de dientes no requería entender en absoluto la tecnología subyacente. Esa invisibilidad se ganó. Amazon reconstruyó la infraestructura logística, de cumplimiento y precios desde cero antes de que la tecnología pudiera desaparecer en la compra. La invisibilidad fue el resultado del rediseño, no una alternativa. El móvil siguió el mismo arco. No ganaba cuando era nuevo y experimental, sino cuando la interfaz desaparecía en la tarea misma.
En cada caso, la tecnología se volvió relevante cuando la mayoría dejó de pensar en ella. El trabajo estructural deliberado ocurrió antes de que la experiencia se volviera sencilla. El principal indicador de madurez tecnológica empresarial nunca ha sido la novedad de la interfaz. Es lo indetectable que es la tecnología bajo el trabajo cotidiano. La IA no está exenta de este patrón.
La misma forma, siempre
La web, el móvil y ahora la IA siguen la curva: ruidosos y visibles al principio, soportantes e invisibles al final. El valor aumenta a medida que la interfaz desaparece.
La capa que soporta el peso
La visión desde arriba y la experimentación en toda la empresa importan. Pero ninguna de las dos da resultado sin lo que hay debajo: la capa que sabe quién pregunta, qué pueden ver, los datos sobre los que funciona el negocio y las herramientas donde ya se realiza el trabajo.
El problema que resuelve esa capa es el reaprendizaje. La IA actual aborda cada tarea como si fuera una nueva incorporación desde el primer día. En cada prompt o especificación, tienen que explicar dónde están los datos, cómo formatear la salida y qué estándares se aplican. Lo que las organizaciones aprenden ahora a construir son habilidades: conjuntos estructurados de instrucciones que codifican cómo se ejecuta un trabajo específico. Una habilidad es diferente de un prompt de la misma manera que un manual de proceso es diferente de un correo electrónico. Un prompt le pide a la IA que lo descubra. Una habilidad le dice a la IA cómo ha decidido hacer esta organización. Desarrollar esas habilidades a gran escala—decidir qué deben codificar, mantenerlas a medida que evolucionan los flujos de trabajo, distribuirlas para que los equipos no empiecen cada uno desde cero—es el trabajo de formalización que separa un modelo operativo de un piloto bien financiado.
La mayoría de las organizaciones están más cerca de esto de lo que se imaginan. La capacidad subyacente se ha acumulado en el software empresarial durante años: en funciones que no se utilizaron, flujos de trabajo demasiado complejos para adoptar, datos sin estructura en sistemas diseñados para la navegación humana. La IA generativa hace que esas capacidades sean accesibles a gran escala, pero solo cuando la infraestructura esté disponible para habilitarlas.
El problema del modelo operativo en el que los líderes están atascados
Los líderes entienden en gran medida que la integración de la IA requiere trabajo de rediseño. El problema más difícil es saber cómo. Los procesos que necesitan cambiar son los mismos de los que depende la organización hoy en día, y nadie tiene una pausa en dirigir el negocio para reconstruirlo.
Hay un momento en la IA escalable en el que se puede sentir el techo. El velocímetro dice que el coche puede ir más rápido, pero el motor ya está al máximo. Lo que desbloquea la siguiente marcha no es una mejora incremental. Es un paso atrás respecto a cómo está estructurado en la actualidad el trabajo y preguntarse si la estructura debería existir en absoluto.
Eso requiere una intervención deliberada. En Microsoft, los equipos de desarrollo de producto realizaron Camp AIR, un programa inmersivo de tres semanas que ofrecía a los participantes tiempo protegido, coaches internos y un conjunto compartido de herramientas de IA. Como dijo un líder, durante esas tres semanas su prioridad no fue entregar la funcionalidad en la que trabajaban, sino descubrir cómo trabajar de manera diferente con IA. El tiempo se había delimitado. Los flujos de trabajo se mapeaban de principio a fin. Había que construir nuevas prácticas antes de que las antiguas pudieran reafirmarse.
Los líderes que no creen esa estructura acabarán enfrentándose a una versión de ella impuesta por la presión competitiva, con menos tiempo y menos opciones. No hay un mapa terminado, y el ritmo de desarrollo de la IA ha hecho que cualquier plano sea provisional. Lo que está disponible en cambio es un dominio que se desarrolla de manera visible por delante: el desarrollo de software, donde los nuevos patrones de trabajo ya están documentados. No es una plantilla. Es un relé. Alguien delante por la misma carretera, envía señales sobre cómo es el terreno. Lo que muestran esas señales no es que la IA abrume a la gente. Son personas que rediseñan la obra para que la tecnología se convierta en la parte que nadie nota.
Lo que todo esto significa para los líderes
La curva en J se resuelve—siempre lo ha hecho. Mollick y Brynjolfsson tienen razón en eso. Lo que determina si una organización lidera o sigue es si construye el cableado mientras los demás siguen con discusiones sobre el interruptor.
La cuestión práctica no es cuánta capacidad de IA está disponible dentro de su organización. Depende de si la infraestructura bajo sus inversiones en IA es de carga o tan solo sirve de cobertura a más pilotos. El primer paso es más pequeño de lo que parece. Elige un flujo de trabajo recurrente que importe—un informe, un ciclo de revisión, un traspaso entre funciones—y hagan tres preguntas:
¿Dónde se queda el trabajo hoy?
¿Dónde intervienen los humanos solo para hacer avanzar las cosas?
¿Qué haría falta para que un agente manejara eso sin que le enseñen de nuevo cada vez?
Las respuestas son la base para crear la habilidad. Construir un pozo, distribuirlo y observar cómo funciona en condiciones reales es lo que se considera en la práctica al tratar la infraestructura como una decisión de modelo operativo. Una vez que lo han visto funcionar en un solo lugar, el patrón se vuelve visible en todas partes. Y entonces, si el trabajo se ha hecho bien, deja de ser visible por completo. La IA que nadie menciona en la reunión, el informe que llega sin que nadie lo saque, el resumen que estaba ahí—así es como funciona la IA.
Para más información sobre la IA y el futuro del trabajo, suscríbanse a este boletín.
Today, Amazon CloudWatch Synthetics announces support for multilocation canaries, allowing developers and site reliability engineers to run the same canary across multiple AWS Regions simultaneously from a single point of management. Previously, monitoring application availability from multiple geographic locations required creating and managing separate canaries in each Region, adding operational overhead and increasing the risk of configuration drift. With multilocation canaries, you create and manage a canary in one primary Region, and CloudWatch Synthetics automatically replicates it to the additional Regions you choose, consolidating all run data, metrics, and artifacts in the primary Region.
Multilocation canaries help you ensure consistent user experience worldwide, identify region-specific performance bottlenecks, and validate that third-party dependencies like CDNs and payment processors work across all locations. Replica canaries run independently, giving you resilient monitoring coverage across geographic locations. You can also configure alarms that activate only when issues are detected from multiple locations, increasing alert confidence and helping your team focus on real customer-impacting problems. Amazon CloudWatch Synthetics multilocation canaries are available in all AWS commercial Regions that support CloudWatch Synthetics. You can upgrade existing single-region canaries to multilocation by adding replica Regions without recreating them. For more information about regional availability, see the AWS Region table.
Today, Amazon CloudWatch Synthetics announces support for multilocation canaries, allowing developers and site reliability engineers to run the same canary across multiple AWS Regions simultaneously from a single point of management. Previously, monitoring application availability from multiple geographic locations required creating and managing separate canaries in each Region, adding operational overhead and increasing the risk of configuration drift. With multilocation canaries, you create and manage a canary in one primary Region, and CloudWatch Synthetics automatically replicates it to the additional Regions you choose, consolidating all run data, metrics, and artifacts in the primary Region.
Multilocation canaries help you ensure consistent user experience worldwide, identify region-specific performance bottlenecks, and validate that third-party dependencies like CDNs and payment processors work across all locations. Replica canaries run independently, giving you resilient monitoring coverage across geographic locations. You can also configure alarms that activate only when issues are detected from multiple locations, increasing alert confidence and helping your team focus on real customer-impacting problems. Amazon CloudWatch Synthetics multilocation canaries are available in all AWS commercial Regions that support CloudWatch Synthetics. You can upgrade existing single-region canaries to multilocation by adding replica Regions without recreating them. For more information about regional availability, see the AWS Region table.
To learn more about CloudWatch Synthetics, see Using synthetic monitoring in the Amazon CloudWatch User Guide. To get started, visit the Amazon CloudWatch product page.
Today, AWS announces the general availability of a new Local Zone in Hanoi, Vietnam, bringing AWS infrastructure closer to end users. This new Local Zone is one of the first AWS Local Zones in the Asia Pacific with support for Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Block Store (Amazon EBS) Local Snapshots, enabling customers to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The Hanoi Local Zone supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
Today, AWS announces the general availability of a new Local Zone in Hanoi, Vietnam, bringing AWS infrastructure closer to end users. This new Local Zone is one of the first AWS Local Zones in the Asia Pacific with support for Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Block Store (Amazon EBS) Local Snapshots, enabling customers to meet data residency requirements by storing and backing up data locally.
AWS Local Zones are AWS infrastructure deployments that extend core services, such as compute, storage, networking, and other select services, closer to metropolitan areas worldwide. AWS Local Zones help you achieve single-digit millisecond latency for end-user workloads, meet data residency requirements, support AI/ML inference workloads, and accelerate migration and modernization of legacy applications to the cloud, all while maintaining consistent AWS APIs, tools, and services as AWS Regions. AWS Local Zones are available in more than 30 metropolitan areas worldwide.
The Hanoi Local Zone supports Amazon Elastic Compute Cloud (Amazon EC2) with C7i, M7i, and R7i instances, Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS with Local Snapshots and volume types gp3, gp2, io1, sc1, and st1, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, and Application Load Balancer.
To get started, enable the Hanoi Local Zone (ap-southeast-1-han-1a) from the Regions and Zones tab in the AWS Global View or by using the ModifyAvailabilityZoneGroup API. For pricing information, visit the AWS Local Zones pricing page. To learn more, visit the AWS Local Zones overview page.
Amazon MSK Provisioned clusters with Express brokers now support Intelligent Rebalancing on all existing clusters, at no additional cost. Previously available only on newly created clusters, Intelligent Rebalancing is now available on all MSK Provisioned clusters running Express brokers, making it effortless for customers to benefit from automatic partition balancing when scaling their Express-based clusters up or down.
Intelligent Rebalancing maximizes the capacity utilization of MSK Express-based clusters by optimally rebalancing Kafka resources for better performance, eliminating the need for customers to manage partitions themselves or via third-party tools. Intelligent Rebalancing performs these operations up to 180 times faster compared to Standard brokers. Clusters are continuously monitored for resource imbalance or overload based on intelligent Amazon MSK defaults to maximize cluster performance. When required, brokers are efficiently scaled without affecting cluster availability for clients to produce and consume data.
Intelligent Rebalancing is now available on all MSK Provisioned clusters with Express brokers in all AWS Regions where Express brokers are available. To learn more, see the Amazon MSK Developer Guide.
Amazon MSK Provisioned clusters with Express brokers now support Intelligent Rebalancing on all existing clusters, at no additional cost. Previously available only on newly created clusters, Intelligent Rebalancing is now available on all MSK Provisioned clusters running Express brokers, making it effortless for customers to benefit from automatic partition balancing when scaling their Express-based clusters up or down.
Intelligent Rebalancing maximizes the capacity utilization of MSK Express-based clusters by optimally rebalancing Kafka resources for better performance, eliminating the need for customers to manage partitions themselves or via third-party tools. Intelligent Rebalancing performs these operations up to 180 times faster compared to Standard brokers. Clusters are continuously monitored for resource imbalance or overload based on intelligent Amazon MSK defaults to maximize cluster performance. When required, brokers are efficiently scaled without affecting cluster availability for clients to produce and consume data.
Intelligent Rebalancing is now available on all MSK Provisioned clusters with Express brokers in all AWS Regions where Express brokers are available. To learn more, see the Amazon MSK Developer Guide.
Today, AWS announces the general availability of Amazon Elastic Compute Cloud (Amazon EC2) G7 instances, accelerated by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs. G7 instances deliver up to 4.6x AI inference performance and up to 2.1x graphics performance compared to G6.
You can use G7 instances for AI inference workloads such as language translation, video and image analysis, speech recognition, and recommender systems. Additionally, G7 instances also accelerate graphics workloads such as creating and rendering real-time, cinematic-quality graphics, and game streaming, as well as data analytics workloads such as large-scale data processing pipelines. G7 instances feature up to 8 NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs with 32 GB of memory per GPU, custom Intel Xeon 6 processors, and up to 700 Gbps of Elastic Fabric Adapter (EFA) networking bandwidth.
You can start using Amazon EC2 G7 instances today in two AWS Regions: US East (Ohio) and US West (Oregon). You can purchase G7 instances as On-Demand Instances, as part of Savings Plans, or Spot Instances.
Today, AWS announces the general availability of Amazon Elastic Compute Cloud (Amazon EC2) G7 instances, accelerated by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs. G7 instances deliver up to 4.6x AI inference performance and up to 2.1x graphics performance compared to G6.
You can use G7 instances for AI inference workloads such as language translation, video and image analysis, speech recognition, and recommender systems. Additionally, G7 instances also accelerate graphics workloads such as creating and rendering real-time, cinematic-quality graphics, and game streaming, as well as data analytics workloads such as large-scale data processing pipelines. G7 instances feature up to 8 NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs with 32 GB of memory per GPU, custom Intel Xeon 6 processors, and up to 700 Gbps of Elastic Fabric Adapter (EFA) networking bandwidth.
You can start using Amazon EC2 G7 instances today in two AWS Regions: US East (Ohio) and US West (Oregon). You can purchase G7 instances as On-Demand Instances, as part of Savings Plans, or Spot Instances.
To get started, visit the AWS Management Console, AWS Command Line Interface (CLI), and AWS SDKs. To learn more, visit this blog post and the G7 instance page.
Amazon MQ for RabbitMQ now supports private networking, enabling your brokers to connect to private resources in your VPC without exposing those resources publicly.. This helps you meet your security and compliance requirements when your brokers need to reach private identity providers (such as LDAP and OAuth 2.0), other Amazon MQ for RabbitMQ brokers, or self-hosted RabbitMQ brokers. Previously, this connectivity for RabbitMQ Federation, Shovel, or authentication required Network Load Balancer and NAT Gateway workarounds.
Amazon MQ establishes this connectivity using Amazon VPC Lattice, AWS Resource Access Manager (AWS RAM), and AWS PrivateLink, and manages the underlying infrastructure on your behalf. To get started, create a VPC Lattice resource gateway, package your resource configurations into an AWS RAM resource share, and associate it with your broker.
Amazon MQ for RabbitMQ now supports private networking, enabling your brokers to connect to private resources in your VPC without exposing those resources publicly.. This helps you meet your security and compliance requirements when your brokers need to reach private identity providers (such as LDAP and OAuth 2.0), other Amazon MQ for RabbitMQ brokers, or self-hosted RabbitMQ brokers. Previously, this connectivity for RabbitMQ Federation, Shovel, or authentication required Network Load Balancer and NAT Gateway workarounds. Amazon MQ establishes this connectivity using Amazon VPC Lattice, AWS Resource Access Manager (AWS RAM), and AWS PrivateLink, and manages the underlying infrastructure on your behalf. To get started, create a VPC Lattice resource gateway, package your resource configurations into an AWS RAM resource share, and associate it with your broker. Private networking is available only for Amazon MQ for RabbitMQ brokers, in all AWS Regions where Amazon VPC Lattice is available. To learn more, see Private networking in the Amazon MQ Developer Guide and the Amazon MQ pricing page.
