Amazon Timestream for InfluxDB now lets you run your own custom Python plugins on the managed versions of InfluxDB 3 Core and Enterprise editions. You host your plugin code in public or private repositories you control and the engine fetches and runs it in response to triggers, letting you implement logic specific to your workload without standing up separate external infrastructure.
Plugins run on the trigger types the processing engine already supports and with them, you can build custom data transformations, alerting, aggregation, and integrations with your own services, all running close to your data. Plugins execute in a managed Python environment that includes the standard library and Amazon-vetted packages , so you can move workload-specific processing into the database instead of operating a separate pipeline to do it.
To get started, set a plugin repository on a DB parameter group, apply that parameter group to your cluster, and create triggers that reference your plugin using the influxdb3 CLI or HTTP API; private repositories are authenticated with a token stored in AWS Secrets Manager. Custom plugins are available in all AWS Regions where Amazon Timestream for InfluxDB is available. To get started with Amazon Timestream for InfluxDB 3, visit the Amazon Timestream for InfluxDB console. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.
Amazon Timestream for InfluxDB now lets you run your own custom Python plugins on the managed versions of InfluxDB 3 Core and Enterprise editions. You host your plugin code in public or private repositories you control and the engine fetches and runs it in response to triggers, letting you implement logic specific to your workload without standing up separate external infrastructure.
Plugins run on the trigger types the processing engine already supports and with them, you can build custom data transformations, alerting, aggregation, and integrations with your own services, all running close to your data. Plugins execute in a managed Python environment that includes the standard library and Amazon-vetted packages , so you can move workload-specific processing into the database instead of operating a separate pipeline to do it.
To get started, set a plugin repository on a DB parameter group, apply that parameter group to your cluster, and create triggers that reference your plugin using the influxdb3 CLI or HTTP API; private repositories are authenticated with a token stored in AWS Secrets Manager. Custom plugins are available in all AWS Regions where Amazon Timestream for InfluxDB is available. To get started with Amazon Timestream for InfluxDB 3, visit the Amazon Timestream for InfluxDB console. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.
Amazon SageMaker Feature Store is a fully managed capability that makes it easy to compute, store, and retrieve features for training and deploying AI models. SageMaker Feature Store now supports feature-level writes, a new capability for updating individual features in a record. Data scientists can now update one or more feature values in a single request, without rewriting the entire record.
Data scientists can use a single update call to replace the read-modify-write pattern their pipelines run today. Each write updates only the features in the request and leaves every other feature in the record unchanged, which lowers write latency and cost. When multiple pipelines write to the same feature group, each pipeline updates only the features it computes, so a streaming job and a nightly batch job can update the same record independently. This capability enables data scientists to update a single feature at high processing volumes, without building merge logic in their data ingestion pipelines.
Amazon SageMaker Feature Store is a fully managed capability that makes it easy to compute, store, and retrieve features for training and deploying AI models. SageMaker Feature Store now supports feature-level writes, a new capability for updating individual features in a record. Data scientists can now update one or more feature values in a single request, without rewriting the entire record.
Data scientists can use a single update call to replace the read-modify-write pattern their pipelines run today. Each write updates only the features in the request and leaves every other feature in the record unchanged, which lowers write latency and cost. When multiple pipelines write to the same feature group, each pipeline updates only the features it computes, so a streaming job and a nightly batch job can update the same record independently. This capability enables data scientists to update a single feature at high processing volumes, without building merge logic in their data ingestion pipelines.
This capability is now available in all AWS Regions where Amazon SageMaker Feature Store is available. For more information, see Amazon Feature Store Runtime, Standard V2 documentation and launch blog.
AWS Transform is now available in the AWS GovCloud (US-West) Region, enabling government agencies and regulated organizations to plan and execute large-scale migrations to AWS. With this launch, customers operating in AWS GovCloud (US) can use the migration capabilities of AWS Transform to automate server migrations within an isolated environment designed to host sensitive data and regulated workloads. AWS Transform in this Region supports migrating servers to both AWS GovCloud (US-East) and AWS GovCloud (US-West) as target Regions.
Organizations migrating VMware, bare metal, Hyper-V, or database workloads can use AWS Transform to automate server replication and cutover, reducing the manual effort and risk involved in large-scale moves. This is particularly valuable for federal agencies, defense contractors, and regulated industries that must operate within the AWS GovCloud (US) boundary. Modernization, custom transformation, and assessment capabilities are not included in this regional launch and remain available in supported commercial Regions.
AWS Transform is now available in the AWS GovCloud (US-West) Region, enabling government agencies and regulated organizations to plan and execute large-scale migrations to AWS. With this launch, customers operating in AWS GovCloud (US) can use the migration capabilities of AWS Transform to automate server migrations within an isolated environment designed to host sensitive data and regulated workloads. AWS Transform in this Region supports migrating servers to both AWS GovCloud (US-East) and AWS GovCloud (US-West) as target Regions.
Organizations migrating VMware, bare metal, Hyper-V, or database workloads can use AWS Transform to automate server replication and cutover, reducing the manual effort and risk involved in large-scale moves. This is particularly valuable for federal agencies, defense contractors, and regulated industries that must operate within the AWS GovCloud (US) boundary. Modernization, custom transformation, and assessment capabilities are not included in this regional launch and remain available in supported commercial Regions.
To get started, see the AWS Transform documentation or visit the AWS Transform product page.
Today, AWS HealthOmics introduces the resource fallback directive, enabling you to define an ordered list of preferred accelerator types, including an option to fallback to CPU instances, for tasks in your Workflow Description Language (WDL) workflows. Researchers and bioinformaticians can use this directive to reduce time spent diagnosing and resubmitting runs due to accelerator constraints and keep production workflows running. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
With resource fallback, you can prioritize your preferred accelerator for your task. When your preferred accelerator is unavailable, HealthOmics automatically moves through your specified alternatives in the fallback without resubmission. Each accelerator profile has a configurable timeout, giving you control over how long HealthOmics searches for that accelerator before moving to the next. Shorter timeouts help you move quickly through the fallback order, while longer timeouts increase the probability of reserving your preferred accelerator. You can also include a CPU profile as a final fallback to increase the likelihood of your task reserving an instance.
You can now use resource fallback for WDL workflows in all AWS HealthOmics Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Seoul, Singapore, Tokyo). To learn more, visit the advanced resource configuration documentation.
Today, AWS HealthOmics introduces the resource fallback directive, enabling you to define an ordered list of preferred accelerator types, including an option to fallback to CPU instances, for tasks in your Workflow Description Language (WDL) workflows. Researchers and bioinformaticians can use this directive to reduce time spent diagnosing and resubmitting runs due to accelerator constraints and keep production workflows running. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs at scale with fully managed bioinformatics workflows.
With resource fallback, you can prioritize your preferred accelerator for your task. When your preferred accelerator is unavailable, HealthOmics automatically moves through your specified alternatives in the fallback without resubmission. Each accelerator profile has a configurable timeout, giving you control over how long HealthOmics searches for that accelerator before moving to the next. Shorter timeouts help you move quickly through the fallback order, while longer timeouts increase the probability of reserving your preferred accelerator. You can also include a CPU profile as a final fallback to increase the likelihood of your task reserving an instance.
You can now use resource fallback for WDL workflows in all AWS HealthOmics Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Seoul, Singapore, Tokyo). To learn more, visit the advanced resource configuration documentation.
Amazon Bedrock AgentCore Memory now lets developers submit content directly for long-term memory extraction without persisting it as a short-term memory event. The new IngestData API accepts content, fans it out to the memory’s configured long-term memory strategies, and makes the resulting memory records available through the same retrieval operations used for any other long-term memory records, all without creating a short-term event.
Until now, all content had to be stored as a short-term memory event before extraction strategies could process it into long-term memory records. IngestData removes this requirement, enabling developers to adopt long-term memory independently of short-term memory.
IngestData supports both conversational payloads (messages with USER/ASSISTANT roles) and JSON payloads (behavioral events, activity logs, system events), and accepts optional metadata that feeds the same extraction pipeline as CreateEvent. After processing, developers can verify extraction results with ListMemoryRecords or RetrieveMemoryRecords, stream real-time notifications via Kinesis, and redrive failed extractions with ListMemoryExtractionJobs. To get started, see Direct ingestion to long-term memory in the Amazon Bedrock AgentCore Developer Guide. IngestData is available in all AWS Regions where Amazon Bedrock AgentCore Memory is supported.
Amazon Bedrock AgentCore Memory now lets developers submit content directly for long-term memory extraction without persisting it as a short-term memory event. The new IngestData API accepts content, fans it out to the memory’s configured long-term memory strategies, and makes the resulting memory records available through the same retrieval operations used for any other long-term memory records, all without creating a short-term event. Until now, all content had to be stored as a short-term memory event before extraction strategies could process it into long-term memory records. IngestData removes this requirement, enabling developers to adopt long-term memory independently of short-term memory. IngestData supports both conversational payloads (messages with USER/ASSISTANT roles) and JSON payloads (behavioral events, activity logs, system events), and accepts optional metadata that feeds the same extraction pipeline as CreateEvent. After processing, developers can verify extraction results with ListMemoryRecords or RetrieveMemoryRecords, stream real-time notifications via Kinesis, and redrive failed extractions with ListMemoryExtractionJobs. To get started, see Direct ingestion to long-term memory in the Amazon Bedrock AgentCore Developer Guide. IngestData is available in all AWS Regions where Amazon Bedrock AgentCore Memory is supported.
Today, AWS announced four new features for Dynamic Image Transformation for Amazon CloudFront (DIT). Customers can now use enhanced smart cropping with custom label detection and advanced composition controls that preserve products, text, logos, and custom objects within cropped images. In addition, customers benefit from enhanced automatic image optimization that delivers appropriately sized images across every browser and device type, from phones and tablets to smart TVs, using CloudFront’s multi-tier device detection to maximize optimization reach regardless of how users access content. DIT also introduces an interactive image transformation playground for testing and validating transformations, and achieves full feature parity between it’s ECS and Lambda architectures.
DIT’s expanded smart cropping enables customers to combine multiple detection methods including faces, labels, text, logos, and custom Amazon Rekognition models, in a single request with configurable aspect ratios, padding, and gravity constraints prioritized by business need. Enhanced automatic optimization now uses a tiered detection approach, layering CloudFront’s device classification headers and configurable fallbacks behind Client Hints, to eliminate the browser-support gap that left ~30% of traffic previously served unoptimized and extend right-sized image delivery beyond browsers to all device types. The image transformation playground displays transformed images with extended metrics including original and output dimensions, format, file size, compression ratios, and processing time, enabling customers to validate the performance of their transformation policies.
Today, AWS announced four new features for Dynamic Image Transformation for Amazon CloudFront (DIT). Customers can now use enhanced smart cropping with custom label detection and advanced composition controls that preserve products, text, logos, and custom objects within cropped images. In addition, customers benefit from enhanced automatic image optimization that delivers appropriately sized images across every browser and device type, from phones and tablets to smart TVs, using CloudFront’s multi-tier device detection to maximize optimization reach regardless of how users access content. DIT also introduces an interactive image transformation playground for testing and validating transformations, and achieves full feature parity between it’s ECS and Lambda architectures.
DIT’s expanded smart cropping enables customers to combine multiple detection methods including faces, labels, text, logos, and custom Amazon Rekognition models, in a single request with configurable aspect ratios, padding, and gravity constraints prioritized by business need. Enhanced automatic optimization now uses a tiered detection approach, layering CloudFront’s device classification headers and configurable fallbacks behind Client Hints, to eliminate the browser-support gap that left ~30% of traffic previously served unoptimized and extend right-sized image delivery beyond browsers to all device types. The image transformation playground displays transformed images with extended metrics including original and output dimensions, format, file size, compression ratios, and processing time, enabling customers to validate the performance of their transformation policies.
AWS Builder ID, your personal profile for accessing AWS applications including AWS Builder Center, AWS Training and Certification, Amazon Quick and Kiro, now offers new ways to protect and recover your profile. You can add a recovery email and use new self-service options to regain access if you’re locked out. You can also register multi-factor authentication (MFA) devices for any sign-in method, including third-party logins such as Google or Apple.
With these enhancements, you have more self-service options to recover your AWS Builder ID. Adding a recovery email provides a second verification factor that makes self-service recovery possible for more scenarios without the need to contact AWS Support. You can reset a forgotten password using a link sent to your primary or recovery email. If you lose access to your MFA device, you can regain access by verifying both your primary and recovery emails. If you use Google, Apple, GitHub or Amazon to sign in to Builder ID, you can now register MFA devices directly in AWS Builder ID, bringing the same strong account protection previously available to email and password users, and you can permanently switch your sign-in method to an email address and password if you lose access to the third-party account.
To learn more about AWS Builder ID and how to set up account recovery and MFA, visit the AWS Builder ID documentation.
AWS Builder ID, your personal profile for accessing AWS applications including AWS Builder Center, AWS Training and Certification, Amazon Quick and Kiro, now offers new ways to protect and recover your profile. You can add a recovery email and use new self-service options to regain access if you’re locked out. You can also register multi-factor authentication (MFA) devices for any sign-in method, including third-party logins such as Google or Apple.
With these enhancements, you have more self-service options to recover your AWS Builder ID. Adding a recovery email provides a second verification factor that makes self-service recovery possible for more scenarios without the need to contact AWS Support. You can reset a forgotten password using a link sent to your primary or recovery email. If you lose access to your MFA device, you can regain access by verifying both your primary and recovery emails. If you use Google, Apple, GitHub or Amazon to sign in to Builder ID, you can now register MFA devices directly in AWS Builder ID, bringing the same strong account protection previously available to email and password users, and you can permanently switch your sign-in method to an email address and password if you lose access to the third-party account.
To learn more about AWS Builder ID and how to set up account recovery and MFA, visit the AWS Builder ID documentation.
El imperativo de maximizar el valor de la IA: convertir la infraestructura en inteligencia útil
Por Rani Borkar, presidenta, sistemas de hardware e infraestructura de Azure.
Al entrar en la próxima era, ¿cuál será la medida definitoria de nuestro progreso?
Cada sector tiene una palabra que moldea su manera de pensar. Para los pilotos, es la seguridad. Para las aseguradoras, es el riesgo.
Para la industria de semiconductores, es el rendimiento útil.
El rendimiento útil no pregunta cuán elegante es la solución, cuántos años tardó o qué prometió la hoja de ruta. Más bien, plantea una pregunta sencilla: ¿Qué resultado útil producimos?
Durante más de 60 años, la industria de semiconductores se ha hecho esa pregunta, al maximizar de manera incansable el número de chips utilizables producidos a partir de cada oblea. Generación tras generación, oblea tras oblea, es justo esa disciplina la que convirtió al transistor de una curiosidad de laboratorio en la base de la vida moderna.
Hoy en día, debemos aplicar el mismo principio a los recursos sin precedentes que el mundo invierte en la IA: capital a una escala que antes estaba reservada para naciones, gigavatios de energía y fábricas y centros de datos récord.
La pregunta que definirá esta década es la misma que esta industria siempre se ha planteado: ¿Qué es lo que en realidad resulta? No solo chips y tokens, sino como inteligencia asequible, como trabajo que importa y como resultados que mejoran vidas.
Ese es el imperativo del rendimiento útil.
El límite de obtener más
La IA se ha proliferado a una velocidad notable, a un ritmo de adopción más rápido que internet, el PC o incluso el smartphone. Sin embargo, la penetración global se mantiene en solo el 18% de la población activa, y la gran mayoría de ese uso se basa en chats. A medida que los sistemas pasan de responder a preguntas individuales a razonar, planificar, usar herramientas y ejecutar flujos de trabajo agénticos más largos, la ecuación de infraestructura cambia de manera drástica. Una sola tarea agéntica puede usar más de 3.400 veces más tokens que una interacción típica de chat.
Fuente: Informe de difusión de IA de Microsoft
Estamos solo en las primeras etapas de la adopción agéntica, y la infraestructura ya está sobrecargada. El poder ha puesto límites a lo que podemos construir y cuándo. Los paquetes y racks crecen y se vuelven más densos. La memoria se ha comenzado a convertir en una restricción aún más estricta.
Durante años, la respuesta racional de la industria a cada nuevo requisito resultó en más: más silicio en el paquete, más memoria al lado, más potencia para alimentarlo y más fibra para conectarlo. Cada generación aportó un progreso significativo. Pero cuando cada nueva ganancia requiere más entrada que la anterior, estamos en una cinta de correr. Solo se mueve mientras le sumemos más.
Creo que debemos seguir dos caminos hacia adelante. El primero es evolutivo: seguir con las mejoras a las arquitecturas que tenemos hoy, a través de impulsar la eficiencia, la utilización y la economía incrementales dentro de cada generación. El segundo es transformador: cambiar la propia curva con innovación en nuevas arquitecturas, nuevos materiales y nuevos enfoques para el diseño de sistemas y modelos.
La historia de nuestra industria está definida por transformaciones como estas. Cuando las velocidades de reloj crecientes de la CPU se toparon con el power wall, pasamos a procesadores multinúcleo. Cuando la NAND planar alcanzó sus límites, la memoria pasó a ser vertical.
Y ahora, una vez más, tenemos la oportunidad de desafiar nuestras suposiciones y repensar los fundamentos. Porque el próximo capítulo de la IA no se definirá sólo por la cantidad de infraestructura que construyamos, sino por cuánta inteligencia podamos crear a partir de ella.
Rendimiento útil en ingeniería
Durante décadas, la industria informática ha optimizado el rendimiento en el contexto de la fabricación. Hoy en día, esa disciplina debe extenderse a través de capas, desde los centros de datos y el silicio hasta los modelos y los arneses agentes que los orquestan. Y el trabajo no se detiene una vez que la tecnología está desarrollada. Entonces debemos desplegarla y escalarla más rápido, mientras desarrollamos nuevas herramientas y sistemas para maximizar su utilización en toda nuestra flota.
Desde el desarrollo hasta la ejecución, cada capa tiene su propio rendimiento útil, y las pérdidas y ganancias se acumulan a lo largo de ellas. La capacidad en una capa es solo un punto de partida. La verdadera medida es con qué tanta eficacia trabajan esas capas juntas para producir resultados útiles del sistema en su conjunto.
Nuestra experiencia en Microsoft en la construcción y operación de infraestructuras de IA a gran escala ha reforzado dos lecciones clave. Primero, las mayores limitaciones rara vez se resuelven en la capa donde aparecen. Segundo, cuando atacamos una restricción en toda la pila, los sacrificios que parecían inherentes al problema a menudo resultan ser artefactos de la arquitectura.
Los mayores avances suelen llegar cuando aplicamos estos aprendizajes a través del co-diseño, al trabajar a través de capas para convertir límites aparentes en restricciones solucionables del sistema. Las innovaciones en memoria, redes y energía muestran cómo es este enfoque en la práctica.
Memoria: Más inteligencia de cada byte
Hoy en día, la memoria se considera un problema de suministro o de componentes. En realidad, es un problema de sistema.
En la inferencia de IA, la memoria marca ahora los límites al rendimiento del sistema. Debe albergar modelos más grandes, preservar contextos más largos y entregar datos con la suficiente para que el cómputo se alimente. Y los agentes elevan el listón aún más. La generación, recuperación, uso de herramientas y memoria persistente se desarrollan juntos en bucles que pueden durar minutos u horas. El resultado es un horizonte de memoria mucho más largo, con mucha más información mantenida cerca del cómputo y disponible a lo largo de una secuencia de turnos en expansión. Hacerlo de manera eficiente y a gran escala definirá la próxima generación de infraestructura de IA.
Nuestra experiencia en la construcción de la plataforma Azure Maia demuestra que los cuellos de botella de memoria no se resuelven con una sola capa.
La arquitectura del modelo, la ciencia de datos y la compresión pueden reducir la cantidad de caché KV, que almacena el contexto de trabajo del modelo durante la generación. El software puede gestionar las jerarquías de memoria de manera más eficaz, el silicio puede optimizarse para la eficiencia del movimiento de datos y los compiladores pueden situar los datos más cerca del cómputo. Ningún cambio elimina la restricción. Juntos, aumentan la inteligencia útil que el sistema puede ofrecer desde los mismos recursos de memoria.
Eso es un rendimiento útil: no tan solo añadir bytes, sino obtener más inteligencia útil de cada byte que ya tenemos.
Redes: Diseñar entre capas
Al ampliar el nivel del clúster, vemos que la inteligencia no proviene de un solo chip. Proviene de miles de chips que operan como un solo sistema. Los enlaces más rápidos importan, pero la productividad del sistema también depende de la gestión de la congestión, la recuperación de fallos, la colocación de cargas de trabajo, la complejidad de programación y los límites entre silicio, sistema y software. Juntos, determinan si la computación costosa produce inteligencia o se queda inactiva.
Al diseñar la plataforma para Maia, no comenzamos con un diseño de red existente. Empezamos con el resultado que queríamos ofrecer: inferencia eficiente a escala de flota, al diseñar a través de silicio, redes y software de sistema. En lugar de estructuras separadas de escalado y escalado, construimos una red de escalado de dos niveles, integramos la funcionalidad de la NIC directo en el chip y desarrollamos una capa de transporte personalizada.
El resultado es un rendimiento escalable y consistente a través de clústeres densos de inferencia, con una estructura unificada que simplifica la programación, mejora la flexibilidad de la carga de trabajo y aprovecha mejor la capacidad disponible. Y con menos hardware de red necesario para ofrecer este rendimiento, también hemos reducido el coste de ejecutar todo el sistema.
Nuestro objetivo no es solo mover datos más rápido. Es mantener más computación productiva y entregar más tokens con cada vatio y cada dólar.
Energía: Co-diseño para la eficiencia, desde la red hasta el chip
Al pasar del clúster a la red, la IA ha introducido nuevos retos en cuanto a la disponibilidad, distribución y utilización de la energía. Los racks han pasado de decenas de kilovatios a cientos de kilovatios, y los campus de los centros de datos pueden operar a la escala de gigavatios. La energía solía ser algo a lo que el sistema tan solo se conectaba. Ahora, es algo en torno a lo que diseñamos, desde la red hasta el chip.
Por eso la industria ha comenzado a replantear la potencia en todo el sistema. Los transformadores de estado sólido y la entrega de energía de corriente continua de 800 voltios pueden reducir las pérdidas de distribución a medida que la energía avanza por la infraestructura. La energía y la refrigeración ya no son aguas abajo del diseño, sino que forman parte de la definición del producto desde el principio. Y cada vez más, ese codiseño es necesario hasta el silicio.
Azure Cobalt 200, nuestra CPU de servidor basada en Arm, muestra cómo es esto en la práctica. Diseñamos Cobalt para que cada núcleo tenga sus propios controles de voltaje y frecuencia, combinados con un límite de potencia basado en software por máquina virtual. Este control más detallado permite ajustes de potencia específicos mientras protege el rendimiento de cargas de trabajo críticas, permitiéndonos operar más servidores dentro del mismo límite de energía.
Como demuestra Cobalt, el diseño conjunto de hardware-software nos permite convertir cada megavatio en valor para el cliente de forma más eficaz.
Los avances entre fronteras
El patrón que observamos en memoria, red y potencia se extiende por todo el sistema: empieza con la salida útil y luego optimiza el conjunto en lugar de una sola capa. Esto primero requiere que seamos precisos sobre la salida para la que optimizamos y qué restricciones de diseño son realmente fijas. ¿Optimizamos para el máximo rendimiento o para un rendimiento sostenido del sistema? ¿Se beneficiaría la carga de trabajo de tener mucha más capacidad con una redundancia menor a nivel marginal? ¿Qué genera más valor: un conjunto más amplio de capacidades o un despliegue mucho más temprano en el cliente?
No todas las limitaciones en los sistemas actuales son leyes de la física. Algunas se heredan de decisiones tomadas en otras partes del sistema y solo pueden cambiar cuando trabajamos más allá de fronteras tradicionales. La evolución surge de las ganancias constantes que cada empresa impulsa dentro de su propio ámbito, pero la transformación llega cuando desafiamos esas suposiciones juntos y rediseñamos el sistema en su conjunto.
Los avances que se avecinan surgirán de la colaboración a través del ecosistema, para abarcar hiperescaladores y proveedores de silicio, fabricantes de equipos e innovadores de materiales, operadores de infraestructura y centros de datos, constructores de modelos y desarrolladores de software.
Hacia el rendimiento total
Pero los tokens y la inteligencia no son la línea de meta. Lo que producimos se convierte en la entrada para el trabajo de otra persona.
Lo que importa a continuación es hasta qué punto esa información se traduce en productividad en toda la economía y en valor en la vida de las personas, ya sea que ayude a un científico a acelerar el descubrimiento, a un clínico a identificar una señal antes, a un estudiante a recibir ayuda en el momento adecuado o a una pequeña empresa a encontrar un nuevo camino de crecimiento.
Eso ocurre a medida que la IA se convierte en parte del trabajo cotidiano en diferentes sectores y en todo el mundo. La gente construye sobre ella, surgen nuevos usos, las herramientas mejoran y el valor se acumula.
Para que ese ciclo se extienda, la IA debe ser accesible de manera amplia. Y a gran escala, la accesibilidad depende de la eficiencia. Es la única forma de desplegar suficiente inteligencia, y a un coste que permita que llegue a todos.
Cuando cada persona y cada empresa puede acceder a inteligencia, construir sobre ella y crear valor propio, eso es el rendimiento total.
Seguiremos con la construcción de la capacidad porque el mundo la necesitará. Pero nuestra medida definitoria de progreso debe ser lo que salga: no solo chips o tokens, sino inteligencia útil traducida en empoderamiento, oportunidad y logros humanos.
Ese es el imperativo de la rentabilidad. Y es un trabajo que toda nuestra industria debe asumir de manera conjunta.
Rani Borkar lidera las organizaciones principales responsables de planificar, arquitectura, desarrollo e implementación de hardware e infraestructura para la principal plataforma de computación en la nube de Microsoft — desde el silicio, hasta los sistemas y la cadena de suministro.
Starting today, Amazon Relational Database Service (Amazon RDS) for MariaDB now supports MariaDB minor versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, and 12.3.3, the latest minors released by community MariaDB. In addition to operational improvements, these minor versions introduce support for post-quantum TLS (PQ-TLS) key exchange, providing you with post-quantum cryptography options for encrypting your data in-transit. We recommend upgrading to the newer minor versions to accept fixes for Common Vulnerabilities and Exposures (CVEs) in prior versions of MariaDB and to benefit from bug fixes, performance improvements, and new functionality added by the MariaDB community. Learn more about the enhancements in RDS for MariaDB in the RDS MariaDB release notes.
Amazon RDS for MariaDB makes it simple to set up, operate, and scale MariaDB deployments in the cloud. Create or update a fully managed Amazon RDS for MariaDB database in the Amazon RDS Management Console.
Starting today, Amazon Relational Database Service (Amazon RDS) for MariaDB now supports MariaDB minor versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, and 12.3.3, the latest minors released by community MariaDB. In addition to operational improvements, these minor versions introduce support for post-quantum TLS (PQ-TLS) key exchange, providing you with post-quantum cryptography options for encrypting your data in-transit. We recommend upgrading to the newer minor versions to accept fixes for Common Vulnerabilities and Exposures (CVEs) in prior versions of MariaDB and to benefit from bug fixes, performance improvements, and new functionality added by the MariaDB community. Learn more about the enhancements in RDS for MariaDB in the RDS MariaDB release notes.
You can upgrade your database using Amazon RDS Blue/Green Deployments, in-place upgrade, or restore from a snapshot. To simplify operations at scale, enable automatic minor version upgrades and use the AWS Organizations Upgrade Rollout Policy to orchestrate upgrades across your clusters in phases. Learn more about performing version upgrades in the Amazon RDS User Guide. You can also migrate to RDS for MariaDB from external MariaDB sources using AWS Database Migration Service. Learn more about pricing details and regional availability at Amazon RDS for MariaDB.
Amazon RDS for MariaDB makes it simple to set up, operate, and scale MariaDB deployments in the cloud. Create or update a fully managed Amazon RDS for MariaDB database in the Amazon RDS Management Console.
Amazon Managed Workflows for Apache Airflow (MWAA) Serverless is now available in AWS GovCloud (US-East) and AWS GovCloud (US-West). Amazon MWAA Serverless eliminates the operational overhead of managing Apache Airflow infrastructure by automatically provisioning and scaling compute resources on demand, with a pay-per-use model that charges only for actual workflow run time.
Amazon Managed Workflows for Apache Airflow (MWAA) Serverless is now available in AWS GovCloud (US-East) and AWS GovCloud (US-West). Amazon MWAA Serverless eliminates the operational overhead of managing Apache Airflow infrastructure by automatically provisioning and scaling compute resources on demand, with a pay-per-use model that charges only for actual workflow run time.
For a full list of supported regions, see the Amazon MWAA Serverless regions page. To learn more, see the Amazon MWAA Serverless documentation.
