Amazon Lightsail now offers new Node.js, LAMP, and Ruby on Rails blueprints. These new blueprint have Instance Metadata Service Version 2 (IMDSv2) enforced by default, and support IPv6-only instances. With just a few clicks, you can create a Lightsail virtual private server (VPS) of your preferred size with Node.js, LAMP, or Ruby on Rails preinstalled.

With Lightsail, you can easily get started on the cloud by choosing a blueprint and an instance bundle to build your web application. Lightsail instance bundles include instances preinstalled with your preferred operating system, storage, and monthly data transfer allowance, giving you everything you need to get up and running quickly.

These new blueprints are now available in all AWS Regions where Lightsail is available. For more information on blueprints supported on Lightsail, see Lightsail documentation. For more information on pricing, or to get started with your free trial, click here.

​Amazon Lightsail now offers new Node.js, LAMP, and Ruby on Rails blueprints. These new blueprint have Instance Metadata Service Version 2 (IMDSv2) enforced by default, and support IPv6-only instances. With just a few clicks, you can create a Lightsail virtual private server (VPS) of your preferred size with Node.js, LAMP, or Ruby on Rails preinstalled. With Lightsail, you can easily get started on the cloud by choosing a blueprint and an instance bundle to build your web application. Lightsail instance bundles include instances preinstalled with your preferred operating system, storage, and monthly data transfer allowance, giving you everything you need to get up and running quickly. These new blueprints are now available in all AWS Regions where Lightsail is available. For more information on blueprints supported on Lightsail, see Lightsail documentation. For more information on pricing, or to get started with your free trial, click here.  

Amazon Bedrock now supports a 1-hour time-to-live (TTL) option for prompt caching for select Anthropic Claude models. With this update, you can extend the persistence of cached prompt prefixes from the default 5 minutes to 1 hour, improving cost efficiency and performance for long-running agentic workflows and multi-turn conversations.

Previously, cached content remained active for a fixed 5-minute window and refreshed when reused. With the new 1-hour TTL option, you can maintain context for users who interact less frequently, or for complex agents that require more time between steps—such as tool use, retrieval, and orchestration. The 1-hour TTL is also useful for longer sessions and batch processing where you want cached content to persist across extended periods.

1-hour TTL prompt caching is generally available for Anthropic’s Claude Sonnet 4.5, Claude Haiku 4.5, and Claude Opus 4.5 in all commercial AWS Regions and AWS GovCloud (US) Regions where these models are available. The 1-hour cache is billed at a different rate than the standard 5-minute cache. To learn more, refer to the Amazon Bedrock documentation and Amazon Bedrock Pricing page.

​Amazon Bedrock now supports a 1-hour time-to-live (TTL) option for prompt caching for select Anthropic Claude models. With this update, you can extend the persistence of cached prompt prefixes from the default 5 minutes to 1 hour, improving cost efficiency and performance for long-running agentic workflows and multi-turn conversations. Previously, cached content remained active for a fixed 5-minute window and refreshed when reused. With the new 1-hour TTL option, you can maintain context for users who interact less frequently, or for complex agents that require more time between steps—such as tool use, retrieval, and orchestration. The 1-hour TTL is also useful for longer sessions and batch processing where you want cached content to persist across extended periods. 1-hour TTL prompt caching is generally available for Anthropic’s Claude Sonnet 4.5, Claude Haiku 4.5, and Claude Opus 4.5 in all commercial AWS Regions and AWS GovCloud (US) Regions where these models are available. The 1-hour cache is billed at a different rate than the standard 5-minute cache. To learn more, refer to the Amazon Bedrock documentation and Amazon Bedrock Pricing page.  

Amazon Managed Grafana is now available in both AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions, enabling government customers and regulated industries to securely visualize and analyze their operational data while meeting stringent compliance requirements. Amazon Managed Grafana is a fully managed service based on open-source Grafana that makes it easier for you to visualize and analyze your operational data at scale.

All Amazon Managed Grafana features are supported in AWS GovCloud (US) Regions except for Enterprise plugins. To get started with Amazon Managed Grafana, visit the AWS Console and Amazon Managed Grafana user guide. To learn more about Amazon Managed Grafana, visit the product page and pricing page.

​Amazon Managed Grafana is now available in both AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions, enabling government customers and regulated industries to securely visualize and analyze their operational data while meeting stringent compliance requirements. Amazon Managed Grafana is a fully managed service based on open-source Grafana that makes it easier for you to visualize and analyze your operational data at scale. All Amazon Managed Grafana features are supported in AWS GovCloud (US) Regions except for Enterprise plugins. To get started with Amazon Managed Grafana, visit the AWS Console and Amazon Managed Grafana user guide. To learn more about Amazon Managed Grafana, visit the product page and pricing page.  

AWS Transfer Family customers can now access file system data stored in Amazon FSx for NetApp ONTAP over SFTP, FTPS, and FTP. 

AWS Transfer Family provides fully managed file transfers over SFTP, FTP, FTPS, AS2, and web browser-based interfaces. With this launch, you can now access FSx for ONTAP file systems over Transfer Family’s supported protocols through S3 Access Points, while maintaining access via native file protocols (NFS/SMB). This allows you to maintain existing file system workflows while adding secure access via industry-standard protocols for external partners and internal users. Access is controlled through standard IAM policies and S3 Access Point configurations, helping you meet data security and compliance requirements.

Transfer Family support for FSx for ONTAP is available in select AWS Regions. To get started, visit the AWS Transfer Family console, or use AWS CLI/SDK. To learn more, visit the Transfer Family User Guide.

​AWS Transfer Family customers can now access file system data stored in Amazon FSx for NetApp ONTAP over SFTP, FTPS, and FTP.  AWS Transfer Family provides fully managed file transfers over SFTP, FTP, FTPS, AS2, and web browser-based interfaces. With this launch, you can now access FSx for ONTAP file systems over Transfer Family’s supported protocols through S3 Access Points, while maintaining access via native file protocols (NFS/SMB). This allows you to maintain existing file system workflows while adding secure access via industry-standard protocols for external partners and internal users. Access is controlled through standard IAM policies and S3 Access Point configurations, helping you meet data security and compliance requirements. Transfer Family support for FSx for ONTAP is available in select AWS Regions. To get started, visit the AWS Transfer Family console, or use AWS CLI/SDK. To learn more, visit the Transfer Family User Guide.  

• Categoría: Noticias de Microsoft

enero 26, 2026

Maia 200: El acelerador de IA diseñado para la inferencia

Por: Scott Guthrie, vicepresidente ejecutivo, Cloud + IA.

El acelerador de IA de próxima generación de Microsoft da a Azure una ventaja para ejecutar modelos de IA de forma más rápida y rentable.

Hoy, nos enorgullece presentar Maia 200, un acelerador de inferencia revolucionario diseñado para mejorar de manera importante la economía de la generación de tokens con IA. Maia 200 es una potencia en inferencia de IA: un acelerador construido sobre el proceso de 3nm de TSMC con núcleos tensoriales nativos FP8/FP4, un sistema de memoria rediseñado con 216GB HBM3e a 7 TB/s y 272MB de SRAM integrada, además de motores de movimiento de datos que mantienen los modelos masivos alimentados, rápidos y con una alta utilización. Esto convierte a Maia 200 en el silicio de primera mano más eficiente de cualquier hiperescalador, con tres veces el rendimiento FP4 del Amazon Train de tercera generación y un rendimiento FP8 superior al TPU de séptima generación de Google. Maia 200 es también el sistema de inferencia más eficiente que Microsoft ha desplegado jamás, con un 30% de rendimiento por dólar superior al hardware de última generación de nuestra flota actual.

Maia 200 forma parte de nuestra heterogénea infraestructura de IA y servirá para múltiples modelos, incluidos los últimos modelos GPT-5.2 de OpenAI, para aportar una ventaja de rendimiento por dólar a Microsoft Foundry y Microsoft 365 Copilot. El equipo de Microsoft Superintelligence utilizará Maia 200 para la generación de datos sintéticos y el aprendizaje por refuerzo para mejorar los modelos internos de próxima generación. Para casos de uso de pipelines de datos sintéticos, el diseño único de Maia 200 ayuda a acelerar la velocidad a la que se pueden generar y filtrar datos de alta calidad y específicos de dominio, para alimentar la formación posterior con señales más frescas y específicas.

Maia 200 está desplegado en nuestra región de centros de datos US Central, cerca de Des Moines, Iowa, con la región de centros de datos US West 3 cerca de Phoenix, Arizona, a continuación y futuras regiones que vendrán después. Maia 200 se integra a la perfección con Azure, y presentamos el SDK de Maia con un conjunto completo de herramientas para construir y optimizar modelos para Maia 200. Incluye un conjunto completo de capacidades, incluida la integración con PyTorch, un compilador Triton y una biblioteca optimizada del kernel, así como acceso al lenguaje de programación de bajo nivel de Maia. Esto ofrece a los desarrolladores un control detallado cuando es necesario, al tiempo que facilita el portabilidad de modelos a través de aceleradores de hardware heterogéneos.

Click here to load media

Diseñado para la inferencia de IA

Fabricado con el avanzado proceso de 3 nanómetros de TSMC, cada chip Maia 200 contiene más de 140 mil millones de transistores y está adaptado para cargas de trabajo de IA a gran escala, además de ofrecer un rendimiento eficiente por dólar. En ambos aspectos, Maia 200 está diseñado para destacar. Está diseñado para los modelos más recientes que utilizan computación de baja precisión, con cada chip Maia 200 que entrega más de 10 petaFLOPS en precisión de 4 bits (FP4) y más de 5 petaFLOPS de rendimiento de 8 bits (FP8), todo dentro de un envolvente TDP SoC de 750W. En términos prácticos, Maia 200 puede correr sin esfuerzo los modelos más grandes de hoy, con mucho margen para modelos aún más grandes en el futuro.

Lo crucial es que los FLOPS no son el único ingrediente para una IA más rápida. La alimentación de datos es por igual importante. Maia 200 ataca este cuello de botella con un subsistema de memoria rediseñado. El subsistema de memoria Maia 200 está centrado en tipos de datos de precisión estrecha, un motor DMA especializado, SRAM integrada en el chip y una estructura NoC especializada para el movimiento de datos de alto ancho de banda, aumentando el rendimiento de los tokens.

Sistemas de IA optimizados

A nivel de sistemas, Maia 200 introduce un diseño novedoso de red de dos niveles de escalado construido sobre Ethernet estándar. Una capa de transporte personalizada y una tarjeta de red integrada de manera estrecha desbloquean rendimiento, gran fiabilidad y ventajas de coste significativas sin depender de tejidos propietarios.

Cada acelerador expone:

• 2,8 TB/s de ancho de banda bidireccional dedicado a escalar
• Operaciones colectivas predecibles y de alto rendimiento en clústeres de hasta 6.144 aceleradores

Esta arquitectura ofrece un rendimiento escalable para clústeres de inferencia densos mientras reduce el consumo de energía y el costo total de atención al consumo total de energía en toda la flota global de Azure.

Dentro de cada bandeja, cuatro aceleradores Maia están conectados por completo con enlaces directos y no conmutados, para mantener la comunicación de alto ancho de banda local, lo que permite una eficiencia óptima de inferencia. Los mismos protocolos de comunicación se utilizan para redes intra-rack e inter-rack por medio del protocolo de transporte AI-AI, lo que permite una escalabilidad fluida entre nodos, racks y clústeres de aceleradores con saltos mínimos en red. Este tejido unificado simplifica la programación, mejora la flexibilidad de la carga de trabajo y reduce la capacidad bloqueada, lo que mantiene al mismo tiempo un rendimiento y eficiencia de costes consistentes a escala en la nube.

Un enfoque de desarrollo nativo en la nube

Un principio fundamental de los programas de desarrollo de silicio de Microsoft es validar la mayor parte posible del sistema de extremo a extremo antes de la disponibilidad final del silicio.

Un sofisticado entorno pre-silicio guio la arquitectura Maia 200 desde sus primeras etapas, para modelar los patrones de cálculo y comunicación de los LLMs con alta fidelidad. Este entorno temprano de co-desarrollo nos permitió optimizar el silicio, las redes y el software de sistema como un todo unificado, mucho antes del primer silicio.

También diseñamos Maia 200 para una disponibilidad rápida y fluida en el centro de datos desde el principio, para construir la validación temprana de algunos de los elementos más complejos del sistema, incluida la red backend y nuestra Unidad de Intercambiador de Calor de Refrigeración líquida de segunda generación, en circuito cerrado. La integración nativa con el plano de control de Azure ofrece seguridad, telemetría, diagnóstico y capacidades de gestión tanto a nivel de chip como de rack, lo que maximiza la fiabilidad y el tiempo de actividad para cargas de trabajo críticas en producción de IA.

Como resultado de estas inversiones, los modelos de IA funcionaban con silicio Maia 200 a los pocos días de la llegada de la primera pieza empaquetada. El tiempo desde el primer silicio hasta el primer despliegue en racks de centros de datos se redujo a menos de la mitad que el de programas de infraestructura de IA comparables. Y este enfoque de extremo a extremo, desde el chip hasta el software y el centro de datos, se traduce de manera directa en una mayor utilización, tiempos de producción más rápidos y mejoras sostenidas en el rendimiento por dólar y por vatio a escala de nube.

Regístrense para la vista previa del SDK de Maia

La era de la IA a gran escala apenas comienza, y la infraestructura definirá lo que es posible. Nuestro programa acelerador de IA Maia está diseñado para ser multigeneracional. A medida que desplegamos Maia 200 en toda nuestra infraestructura global, ya hemos comenzado a diseñar para las futuras generaciones y esperamos que cada generación establezca de manera continua nuevos estándares para lo que es posible y ofrezca un rendimiento y eficiencia cada vez mejores para las cargas de trabajo de IA más importantes.

Hoy invitamos a desarrolladores, startups de IA y académicos a comenzar a explorar la optimización temprana de modelos y cargas de trabajo con el nuevo kit de desarrollo de software (SDK, por sus siglas en inglés) Maia 200. El SDK incluye un compilador Triton, soporte para PyTorch, programación de bajo nivel en NPL y un simulador Maia y calculadora de costes para optimizar eficiencias más temprano en el ciclo de vida del código. Regístrense para la vista previa aquí.

Consigan más fotos, vídeos y recursos en nuestro sitio Maia 200 y lean más detalles.

Scott Guthrie es responsable de soluciones y servicios de computación en la nube a gran escala, incluida Azure, la plataforma de computación en la nube de Microsoft, soluciones de IA generativa, plataformas de datos y seguridad de la información y ciberseguridad. Estas plataformas y servicios ayudan a organizaciones de todo el mundo a resolver desafíos urgentes e impulsar la transformación a largo plazo.

Etiquetas:

• Anuncios
• Desarrollo de productos
• IA
• Tecnología

The post Maia 200: El acelerador de IA diseñado para la inferencia appeared first on Source LATAM.

​The post Maia 200: El acelerador de IA diseñado para la inferencia appeared first on Source LATAM.  

AWS is announcing flexible billing for Amazon WorkSpaces Core managed instances, adding monthly flat-rate pricing alongside existing hourly billing. Customers can now choose the optimal pricing model based on their end user usage patterns. Monthly billing is ideal for predictable full-time desktops and hourly billing is ideal for variable usage patterns. Both options are pay-as-you-go with no long-term commitments.

Amazon WorkSpaces Core managed instances simplifies virtual desktop infrastructure (VDI) migrations with highly customizable instance configurations. WorkSpaces Core managed instances provisions resources in your AWS account, handling infrastructure lifecycle management for both persistent and non-persistent workloads. Monthly pricing delivers savings vs hourly billing at always-on utilization, optimized for real-world VDI use cases.

With flexible billing, customers benefit from predictable costs for persistent desktop workloads and the flexibility to mix hourly and monthly billing within the same deployment. VDI partners utilizing WorkSpaces Core managed instances including Citrix, Workspot, Dizzion, and Leostream can now integrate with new WorkSpaces API billing features to enable the monthly billing option when instances are created. Hourly billing remains the default billing option for managed instances.

In addition, starting today, hourly utility rates for WorkSpaces Core managed instances will now be combined and billed by Amazon WorkSpaces to simplify pricing. Previously, hourly rates were split between Amazon EC2 and Amazon WorkSpaces on customer bills. There is no change to the effective rates for on-demand hourly usage of WorkSpaces Core Managed Instances with this announcement.

To learn more about Amazon WorkSpaces Core managed instances flexible billing, visit the WorkSpaces for VDI partners pricing page. For more information, see the WorkSpaces for VDI partners product page. For technical documentation, see the Amazon WorkSpaces Core Documentation.

​AWS is announcing flexible billing for Amazon WorkSpaces Core managed instances, adding monthly flat-rate pricing alongside existing hourly billing. Customers can now choose the optimal pricing model based on their end user usage patterns. Monthly billing is ideal for predictable full-time desktops and hourly billing is ideal for variable usage patterns. Both options are pay-as-you-go with no long-term commitments. Amazon WorkSpaces Core managed instances simplifies virtual desktop infrastructure (VDI) migrations with highly customizable instance configurations. WorkSpaces Core managed instances provisions resources in your AWS account, handling infrastructure lifecycle management for both persistent and non-persistent workloads. Monthly pricing delivers savings vs hourly billing at always-on utilization, optimized for real-world VDI use cases. With flexible billing, customers benefit from predictable costs for persistent desktop workloads and the flexibility to mix hourly and monthly billing within the same deployment. VDI partners utilizing WorkSpaces Core managed instances including Citrix, Workspot, Dizzion, and Leostream can now integrate with new WorkSpaces API billing features to enable the monthly billing option when instances are created. Hourly billing remains the default billing option for managed instances. In addition, starting today, hourly utility rates for WorkSpaces Core managed instances will now be combined and billed by Amazon WorkSpaces to simplify pricing. Previously, hourly rates were split between Amazon EC2 and Amazon WorkSpaces on customer bills. There is no change to the effective rates for on-demand hourly usage of WorkSpaces Core Managed Instances with this announcement. To learn more about Amazon WorkSpaces Core managed instances flexible billing, visit the WorkSpaces for VDI partners pricing page. For more information, see the WorkSpaces for VDI partners product page. For technical documentation, see the Amazon WorkSpaces Core Documentation.  

Amazon Route 53 Domains now supports registration and management of ten new top-level domains (TLDs): .ai, .nz, .shop, .bot, .moi, .spot, .free, .deal, .now, and .hot. This expansion enhances Route 53’s capabilities as a domain registration and DNS management service, offering customers more options to establish their online presence. With these additions, businesses and individuals can now leverage domain names tailored to specific industries, regions, or purposes directly through Amazon Web Services (AWS).

The new TLDs cater to various use cases. To name a few, the .ai domain, originally for Anguilla, has become popular among artificial intelligence companies. E-commerce sites can utilize .shop for their online storefronts. The .bot domain suits chatbot and AI-related services. The .now domain works well for time-sensitive services and instant delivery platforms. Users can register these domains through the Route 53 console, AWS CLI, or SDKs, enjoying integrated DNS management and automatic renewal features. This seamless integration allows for efficient domain administration alongside existing Route 53 hosted zones and DNS records.

To learn more about Amazon Route 53 Domains and start registering new domains, visit the Amazon Route 53 page. Domain registration pricing varies by TLD. Visit the pricing page for detailed pricing information.

​Amazon Route 53 Domains now supports registration and management of ten new top-level domains (TLDs): .ai, .nz, .shop, .bot, .moi, .spot, .free, .deal, .now, and .hot. This expansion enhances Route 53’s capabilities as a domain registration and DNS management service, offering customers more options to establish their online presence. With these additions, businesses and individuals can now leverage domain names tailored to specific industries, regions, or purposes directly through Amazon Web Services (AWS). The new TLDs cater to various use cases. To name a few, the .ai domain, originally for Anguilla, has become popular among artificial intelligence companies. E-commerce sites can utilize .shop for their online storefronts. The .bot domain suits chatbot and AI-related services. The .now domain works well for time-sensitive services and instant delivery platforms. Users can register these domains through the Route 53 console, AWS CLI, or SDKs, enjoying integrated DNS management and automatic renewal features. This seamless integration allows for efficient domain administration alongside existing Route 53 hosted zones and DNS records. To learn more about Amazon Route 53 Domains and start registering new domains, visit the Amazon Route 53 page. Domain registration pricing varies by TLD. Visit the pricing page for detailed pricing information.
   

Amazon RDS for Oracle now supports database replicas for instances set up in Oracle multi-tenant configuration. Oracle multi-tenant configuration allows customers to host multiple, isolated pluggable databases in a single container database, which allows for cost reduction through consolidation and easier management. With support for replicas in Oracle multi-tenant configuration, customers can now distribute read workloads to a replica to scale workloads, or setup cross-Region replicas. In disaster recovery situations, customers can promote replicas to serve as a new standalone database, or execute a switchover to reverse roles between the primary database and the replica for a quick recovery.

To set up replicas in Oracle multi-tenant configuration, customers can create a replica in either mounted or read-only mode using the AWS management console, AWS CLI, or AWS SDK. Once a replica is set up, Amazon RDS for Oracle manages asynchronous physical replication between primary and replica database instances using Oracle Data Guard.

Amazon RDS for Oracle read replicas use Oracle Data Guard. Using mounted mode replicas require an Oracle Database Enterprise Edition (EE) license, and using read-only mode replicas require additional Oracle Active Data Guard licenses. We recommend customers to consult their Oracle licensing expert to determine Oracle licensing requirements. Refer to RDS for Oracle User Guide for more information, and Amazon RDS for Oracle pricing for available instance configurations, pricing, and region availability.

​Amazon RDS for Oracle now supports database replicas for instances set up in Oracle multi-tenant configuration. Oracle multi-tenant configuration allows customers to host multiple, isolated pluggable databases in a single container database, which allows for cost reduction through consolidation and easier management. With support for replicas in Oracle multi-tenant configuration, customers can now distribute read workloads to a replica to scale workloads, or setup cross-Region replicas. In disaster recovery situations, customers can promote replicas to serve as a new standalone database, or execute a switchover to reverse roles between the primary database and the replica for a quick recovery.
To set up replicas in Oracle multi-tenant configuration, customers can create a replica in either mounted or read-only mode using the AWS management console, AWS CLI, or AWS SDK. Once a replica is set up, Amazon RDS for Oracle manages asynchronous physical replication between primary and replica database instances using Oracle Data Guard.
Amazon RDS for Oracle read replicas use Oracle Data Guard. Using mounted mode replicas require an Oracle Database Enterprise Edition (EE) license, and using read-only mode replicas require additional Oracle Active Data Guard licenses. We recommend customers to consult their Oracle licensing expert to determine Oracle licensing requirements. Refer to RDS for Oracle User Guide for more information, and Amazon RDS for Oracle pricing for available instance configurations, pricing, and region availability.  

EC2 Auto Scaling is introducing a new policy condition key autoscaling:ForceDelete. This condition key is used with the DeleteAutoScalingGroup action to control whether the ForceDelete parameter can be used during deletion, which determines if an Auto Scaling group (ASG) can be deleted while it still contains running instances. You can use this condition key in IAM policies to restrict deletion permissions. This provides a safety measure to prevent accidental deletion of ASGs that still have running instances.

Furthermore, EC2 Auto Scaling now offers deletion protection at the group level. The new deletion-protection configuration can be set either when you create your ASGs or update them. This new feature lets you set enhanced controls based on your workload’s criticality, with multiple protection levels available to safeguard against accidental deletions and help maintain application availability.

Combining the autoscaling:ForceDelete condition key with deletion protection at the group level provides a layered defense against unwanted ASG termination by allowing you to both restrict IAM permissions for force-delete operations and set enhanced protection controls directly on critical ASGs.

The features now available in all AWS Regions and AWS GovCloud (US) Regions. To get started, visit the EC2 Auto Scaling console or refer to our technical documentation for deletion protection and policy condition keys for Amazon EC2 Auto Scaling.

​EC2 Auto Scaling is introducing a new policy condition key autoscaling:ForceDelete. This condition key is used with the DeleteAutoScalingGroup action to control whether the ForceDelete parameter can be used during deletion, which determines if an Auto Scaling group (ASG) can be deleted while it still contains running instances. You can use this condition key in IAM policies to restrict deletion permissions. This provides a safety measure to prevent accidental deletion of ASGs that still have running instances. Furthermore, EC2 Auto Scaling now offers deletion protection at the group level. The new deletion-protection configuration can be set either when you create your ASGs or update them. This new feature lets you set enhanced controls based on your workload’s criticality, with multiple protection levels available to safeguard against accidental deletions and help maintain application availability. Combining the autoscaling:ForceDelete condition key with deletion protection at the group level provides a layered defense against unwanted ASG termination by allowing you to both restrict IAM permissions for force-delete operations and set enhanced protection controls directly on critical ASGs. The features now available in all AWS Regions and AWS GovCloud (US) Regions. To get started, visit the EC2 Auto Scaling console or refer to our technical documentation for deletion protection and policy condition keys for Amazon EC2 Auto Scaling.  

Today, we’re announcing that Amazon Elastic VMware Service (Amazon EVS) now supports the ability to deploy multiple VMware NSX Tier-0 Gateways within VMware Software-Defined Data Centers (SDDC), enabling enhanced network segmentation and more flexible routing configurations.

Multiple NSX Tier-0 Gateways allow for better performance and scale by distributing network traffic across multiple NSX Edge Clusters. This latest enhancement enables improved network segmentation, allowing you to isolate different workload environments and maintain distinct security policies for each gateway. You can also use multiple gateways to create separate test environments for validating network configurations and performing gateway upgrades with minimal impact to production workloads. This architecture flexibility helps you align your network topology with specific business requirements while maintaining operational efficiency in running your VMware workloads on AWS with Amazon EVS. 

To learn more about this newest enhancement, read this re:Post article that walks you through the process of deploying multiple NSX Edge Clusters within your EVS environment. To get started with Amazon EVS, visit the product detail page and user guide.

​Today, we’re announcing that Amazon Elastic VMware Service (Amazon EVS) now supports the ability to deploy multiple VMware NSX Tier-0 Gateways within VMware Software-Defined Data Centers (SDDC), enabling enhanced network segmentation and more flexible routing configurations. Multiple NSX Tier-0 Gateways allow for better performance and scale by distributing network traffic across multiple NSX Edge Clusters. This latest enhancement enables improved network segmentation, allowing you to isolate different workload environments and maintain distinct security policies for each gateway. You can also use multiple gateways to create separate test environments for validating network configurations and performing gateway upgrades with minimal impact to production workloads. This architecture flexibility helps you align your network topology with specific business requirements while maintaining operational efficiency in running your VMware workloads on AWS with Amazon EVS.  To learn more about this newest enhancement, read this re:Post article that walks you through the process of deploying multiple NSX Edge Clusters within your EVS environment. To get started with Amazon EVS, visit the product detail page and user guide.