Amazon Elastic Compute Cloud (Amazon EC2) T8i instances are now available in South America (São Paulo). These instances are powered by custom sixth generation Intel Xeon 6 processors, available exclusively on AWS, and built on the latest sixth generation AWS Nitro cards. T8i instances deliver up to 30% better price performance compared to previous generation T3 instances, and offer four sizes: nano, micro, small, and medium. These instances are designed for workloads requiring low to moderate CPU utilization, including data processing, login gateways, small databases, batch processing, event driven functions, CI/CD pipelines, microservices, and low traffic websites.
T8i instances deliver up to 70% higher compute performance, 1.25x higher network bandwidth, and 2.4x higher EBS bandwidth compared to T3 instances. They use the same CPU credit system as T3 with Standard and Unlimited modes, so existing T3 customers can upgrade to T8i and immediately benefit from better price performance, enabling them to lower their TCO. For customers new to AWS or migrating from on-premises, T8i instances provide one of the most cost-effective entry points to run a variety of workloads.
T8i.micro and T8i.small are available under the AWS Free Tier. T8i instances are available in US East (N. Virginia, Ohio), US West (Oregon, N. California), Europe (Frankfurt, Ireland, London, Paris), Asia Pacific (Hyderabad, Malaysia, Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central) and South America (São Paulo) regions. T8i instances are available to purchase via On-Demand instances, and Spot instances with Savings Plan option coming soon. To learn more, visit the Amazon EC2 T8i instances page.
Amazon Elastic Compute Cloud (Amazon EC2) T8i instances are now available in South America (São Paulo). These instances are powered by custom sixth generation Intel Xeon 6 processors, available exclusively on AWS, and built on the latest sixth generation AWS Nitro cards. T8i instances deliver up to 30% better price performance compared to previous generation T3 instances, and offer four sizes: nano, micro, small, and medium. These instances are designed for workloads requiring low to moderate CPU utilization, including data processing, login gateways, small databases, batch processing, event driven functions, CI/CD pipelines, microservices, and low traffic websites.
T8i instances deliver up to 70% higher compute performance, 1.25x higher network bandwidth, and 2.4x higher EBS bandwidth compared to T3 instances. They use the same CPU credit system as T3 with Standard and Unlimited modes, so existing T3 customers can upgrade to T8i and immediately benefit from better price performance, enabling them to lower their TCO. For customers new to AWS or migrating from on-premises, T8i instances provide one of the most cost-effective entry points to run a variety of workloads.
T8i.micro and T8i.small are available under the AWS Free Tier. T8i instances are available in US East (N. Virginia, Ohio), US West (Oregon, N. California), Europe (Frankfurt, Ireland, London, Paris), Asia Pacific (Hyderabad, Malaysia, Mumbai, Seoul, Singapore, Sydney, Tokyo), Canada (Central) and South America (São Paulo) regions. T8i instances are available to purchase via On-Demand instances, and Spot instances with Savings Plan option coming soon. To learn more, visit the Amazon EC2 T8i instances page.
Today, AWS announces the general availability of the AWS Lambda Durable Execution SDK for Go, enabling Go developers to build resilient, long-running workflows using Lambda durable functions. With this SDK, developers can create multi-step applications like infrastructure automation, deployment rollouts with approval gates, and pipelines that call AI models and pause for human review directly in their Go code without implementing custom progress tracking.
Lambda durable functions extend Lambda’s event-driven programming model with operations that checkpoint progress automatically and pause execution for up to an year when waiting on external events. The AWS Lambda Durable Execution SDK for Go provides a native Go experience for building with Lambda durable functions. It includes steps for progress tracking, callback integration for human and agent-in-the-loop workflows, durable invocation for reliable function chaining, and waits for efficient suspension.
The SDK works with the Go tools developers already use. Developers add it to a Go module with go get and deploy their function as a single static binary on the provided.al2023 runtime, like any other Go function on Lambda. Before deploying, they can locally test complete workflows on their own machine with the durabletest package, without requiring network access or AWS credentials, and use the durablelint analyzer to catch code that could break a workflow when it resumes.
Today, AWS announces the general availability of the AWS Lambda Durable Execution SDK for Go, enabling Go developers to build resilient, long-running workflows using Lambda durable functions. With this SDK, developers can create multi-step applications like infrastructure automation, deployment rollouts with approval gates, and pipelines that call AI models and pause for human review directly in their Go code without implementing custom progress tracking.
Lambda durable functions extend Lambda’s event-driven programming model with operations that checkpoint progress automatically and pause execution for up to an year when waiting on external events. The AWS Lambda Durable Execution SDK for Go provides a native Go experience for building with Lambda durable functions. It includes steps for progress tracking, callback integration for human and agent-in-the-loop workflows, durable invocation for reliable function chaining, and waits for efficient suspension.
The SDK works with the Go tools developers already use. Developers add it to a Go module with go get and deploy their function as a single static binary on the provided.al2023 runtime, like any other Go function on Lambda. Before deploying, they can locally test complete workflows on their own machine with the durabletest package, without requiring network access or AWS credentials, and use the durablelint analyzer to catch code that could break a workflow when it resumes.
To get started, see the Lambda durable functions developer guide and the AWS Lambda Durable Execution SDK for Go on GitHub. For Regional availability and pricing details for Lambda durable functions, see the AWS Capabilities by Region page and AWS Lambda Pricing.
Amazon DynamoDB Streams now supports timestamp-based stream processing, enabling you to begin reading stream records from a specific point in time. Previously, you could only start from the oldest retained record (up to 24 hours old) or from new records written after you start consuming the stream. Now, you can supply a timestamp and begin processing at the first record written at or after that time using the AT_TIMESTAMP shard iterator type.
Timestamp-based stream processing can be used with the Amazon Kinesis Client Library (KCL) through the DynamoDB Streams Kinesis adapter. It helps you avoid reprocessing entire retained streams or missing records when resuming stream consumption, supporting common use cases such as recovery after an interruption, data replay for debugging and auditing by reading from a specific point in the past, skipping a backlog by resuming from a recent timestamp near the latest records, and synchronizing after a restore by beginning at the export timestamp following a point-in-time recovery (PITR) export.
Timestamp-based stream processing is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and the China Regions. There is no additional charge for this feature beyond standard GetRecords API request charges. To get started, see Amazon DynamoDB Streams timestamp documentation in the DynamoDB developer guide.
Amazon DynamoDB Streams now supports timestamp-based stream processing, enabling you to begin reading stream records from a specific point in time. Previously, you could only start from the oldest retained record (up to 24 hours old) or from new records written after you start consuming the stream. Now, you can supply a timestamp and begin processing at the first record written at or after that time using the AT_TIMESTAMP shard iterator type.
Timestamp-based stream processing can be used with the Amazon Kinesis Client Library (KCL) through the DynamoDB Streams Kinesis adapter. It helps you avoid reprocessing entire retained streams or missing records when resuming stream consumption, supporting common use cases such as recovery after an interruption, data replay for debugging and auditing by reading from a specific point in the past, skipping a backlog by resuming from a recent timestamp near the latest records, and synchronizing after a restore by beginning at the export timestamp following a point-in-time recovery (PITR) export.
Timestamp-based stream processing is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and the China Regions. There is no additional charge for this feature beyond standard GetRecords API request charges. To get started, see Amazon DynamoDB Streams timestamp documentation in the DynamoDB developer guide.
Acelerar la capacidad humana en el ámbito sanitario con IA
7 minutos
Por: Jonathon Dreyer, director general de Marketing de Producto, Salud Global y Ciencias de la Vida en Microsoft.
Cada gran avance en la sanidad ha ampliado lo que las personas pueden lograr: ofrecer nuevas maneras de tratar enfermedades, ayudar a las organizaciones a llegar a más personas y crear mejores condiciones para el descubrimiento, el servicio y la atención. Los avances médicos transformaron condiciones que antes eran intratables. Los registros digitales de salud hicieron la información más accesible. Las herramientas digitales ayudaron a las organizaciones sanitarias a operar con mayor escala y eficiencia.
La IA representa ahora el siguiente paso en esa evolución, no porque solo introduzca otra tecnología, sino porque puede ampliar la capacidad de las personas en todo el ecosistema sanitario.
En el ámbito sanitario y de las ciencias de la vida, las organizaciones van más allá de la experimentación e integran la IA en los flujos de trabajo cotidianos. A medida que lo hacen, descubren que el valor de la IA va más allá de las ganancias de eficiencia. Puede ayudar a los clínicos a pasar más tiempo con los pacientes, permitir que los empleados tomen decisiones más rápido, acelerar el descubrimiento científico y crear nuevas oportunidades de innovación.
El cambio ya no es teórico. Proveedores, pagadores, organizaciones de ciencias de la vida y empresas MedTech ya han comenzado a adoptar nuevas maneras de trabajar que combinan la experiencia humana con capacidades impulsadas por IA, para ayudar a los empleados a centrar más su tiempo y energía en el trabajo que más importa.
Ayudar a los clínicos a dedicar más tiempo donde más importa
Los profesionales sanitarios siguen enfrentándose a un desafío persistente: los clínicos dedican una parte significativa de su día a tareas de documentación y administración. Para los equipos que ya atraviesan un agotamiento prolongado, estas cargas aumentan la presión diaria y les quitan tiempo a interacciones significativas con los pacientes.
La IA puede ayudar a aliviar esa carga al agilizar la documentación, mejorar el acceso a la información y apoyar los flujos de trabajo directo dentro de los sistemas que los clínicos ya utilizan a diario.
Intermountain Health utiliza Microsoft Dragon Copilot dentro de su flujo de trabajo de historial médico electrónico (EHR, por sus siglas en inglés), Epic, para capturar conversaciones paciente-clínico y redactar automáticamente las notas clínicas. La organización ha escalado la adopción a más de 2.500 usuarios activos de Dragon Copilot, lo que ayudó a reducir el tiempo dedicado a la documentación y ha permitido interacciones con pacientes más enfocadas.
Al reducir el trabajo administrativo, la IA puede ayudar a los clínicos a prestar más atención al cuidado del paciente, las conversaciones y la toma de decisiones clínicas. Al hacerlo, crea más capacidad para la experiencia, la empatía y la conexión humana que están en el corazón de la atención sanitaria.
Ayudar a los planes de salud a ofrecer respuestas más rápidas y mejores experiencias
Las organizaciones pagadoras gestionan procesos cada vez más complejos en reclamaciones, gestión de cuidados, cumplimiento, compromiso con los proveedores y servicios a los miembros. Los empleados a menudo necesitan navegar por grandes volúmenes de información mientras responden de manera rápida y precisa a las necesidades de los miembros.
La IA puede ayudar a los empleados a encontrar información más rápido, a sacar a la luz información relevante y a tomar decisiones más informadas, lo que mejora tanto la eficiencia operativa como la experiencia del cliente.
Premera Blue Cross fortaleció la base digital de su negocio al migrar Facets, su plataforma crítica de administración de pagadores, a Microsoft Azure. La migración se completó sin pérdida de datos ni requerimiento de retroceso, mejoró el procesamiento por lotes en un 38% y creó una base más escalable y resiliente para futuras iniciativas en reclamaciones, IA y automatización.
Ampliación de la capacidad para el descubrimiento científico
Las organizaciones sanitarias y de ciencias de la vida generan enormes volúmenes de conocimiento científico y datos de investigación. Encontrar conocimientos significativos dentro de esa información ha requerido por lo general de un tiempo y esfuerzo significativos.
La IA ayuda a los investigadores a analizar la información de manera más eficiente, descubrir patrones en grandes conjuntos de datos, explorar oportunidades emergentes y acelerar el descubrimiento.
Pierre Fabre creó PLA. I.GROUND, una plataforma de IA generativa empresarial segura, contextualizada y multimodelo basada en Microsoft Azure y Azure OpenAI. Hoy en día, más de la mitad de los empleados de oficina de la empresa utilizan PLA. I.GROUND a diario para resumir documentos, generar contenido y acelerar el desarrollo de código, para ayudar a los empleados a dedicar menos tiempo a tareas de bajo valor y liberar tiempo para la innovación.
A medida que la IA se integra más a profundidad en los flujos de trabajo de investigación, las organizaciones pueden amplificar la experiencia científica y crear mayor capacidad para perseguir el próximo avance. Cuando los investigadores dedican menos tiempo a buscar, recopilar y sintetizar información, ganan más tiempo para explorar ideas, poner a prueba hipótesis y avanzar en el descubrimiento.
Acelerar la innovación en MedTech
Las organizaciones MedTech operan en la intersección de la investigación, la fabricación, la prestación de servicios sanitarios, las operaciones comerciales y los requisitos regulatorios. Los empleados a menudo necesitan acceder a información de toda la organización mientras colaboran con equipos que abarcan funciones y geografías.
La IA puede ayudar a simplificar esta complejidad a través de facilitar la obtención de información, resumir discusiones clave, crear contenido y colaborar de manera más eficaz.
KARL STORZ implementó Microsoft 365 Copilot para resúmenes de reuniones, redacción y recuperación de información. La organización logró un 97% de uso activo en alrededor de 2.000 usuarios con licencia, con un 93% que regresó mes a mes.
Estos resultados demuestran cómo la IA puede ayudar a las organizaciones a acelerar la ejecución, mejorar la colaboración y empoderar a los empleados para que dediquen más tiempo a la innovación y al trabajo estratégico. Al reducir la fricción en los procesos cotidianos, la IA permite a los equipos pasar de la información a la acción más rápido y presentar nuevas ideas con mayor velocidad.
Innovación basada en la confianza
A medida que las organizaciones sanitarias amplían el uso de la IA, la confianza se mantiene como algo esencial.
Los líderes deben equilibrar la innovación con seguridad, privacidad, cumplimiento normativo y prácticas responsables de IA, lo que asegura que los empleados se sientan seguros al usar nuevas tecnologías en su trabajo diario. Las organizaciones que tienen mayor éxito no tratan la confianza como una iniciativa puntual, sino como un compromiso continuo que apoya la adopción y el valor a largo plazo.
En última instancia, el valor de la IA en la sanidad no se medirá por la rapidez con la que se implemente, sino por la confianza con la que las personas puedan usarla para marcar la diferencia. Cuando la innovación se basa en la confianza, la IA puede empoderar a las personas que ofrecen, apoyan y avanzan la atención mientras protegen lo que más importa.
Poner a trabajar la IA de confianza
La confianza es lo que convierte la adopción de la IA en un valor duradero. La siguiente pregunta es dónde aplicarla y cómo pasar de un caso de uso prometedor a un impacto medible.
Exploren la infografía de IA en Acción para obtener una visión concisa de cómo las organizaciones ponen la IA en acción hoy y los resultados que han logrado.
La próxima era de la sanidad estará definida por cómo la IA de confianza amplíe la capacidad para ofrecer atención, avanzar en el descubrimiento y llevar la innovación al mercado.
Meta’s Muse Spark Open is now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. This coding-optimized open-weight model from Meta is purpose-built for agentic coding workflows, bringing multi-step reasoning and tool calling to enterprise software engineering on AWS infrastructure.
Muse Spark Open is designed for long-running coding agents and multimodal engineering workflows. Built on a Mixture-of-Experts (MoE) architecture with 816B total parameters and 42B active per token, it delivers the capacity of a very large network while keeping per-token compute closer to that of a much smaller dense model. The model holds a 1M-token context window, enabling it to ingest an entire project—including dependencies, legacy code, and thousands of files—without splitting tasks into smaller pieces. It accepts text, images, documents, audio, and audio-video as input and generates text output. Trained on real developer workflows such as multi-file refactors and long debugging sessions, it plans, acts, observes results, and self-corrects over long horizons rather than making single tool calls. SageMaker JumpStart offers two variants: BF16 (Muse-Spark-Open-816B-A42B) and NVFP4 quantized (Muse-Spark-Open-816B-A42B-NVFP4), with the NVFP4 variant requiring roughly a quarter of the memory for cost-efficient deployment.
With SageMaker JumpStart, customers can deploy Muse Spark Open with just a few clicks, with the endpoint running in their own AWS account for full control over source code and prompts.
To get started with this model, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the model to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
Meta’s Muse Spark Open is now available on Amazon SageMaker JumpStart, expanding the portfolio of foundation models available to AWS customers. This coding-optimized open-weight model from Meta is purpose-built for agentic coding workflows, bringing multi-step reasoning and tool calling to enterprise software engineering on AWS infrastructure.
Muse Spark Open is designed for long-running coding agents and multimodal engineering workflows. Built on a Mixture-of-Experts (MoE) architecture with 816B total parameters and 42B active per token, it delivers the capacity of a very large network while keeping per-token compute closer to that of a much smaller dense model. The model holds a 1M-token context window, enabling it to ingest an entire project—including dependencies, legacy code, and thousands of files—without splitting tasks into smaller pieces. It accepts text, images, documents, audio, and audio-video as input and generates text output. Trained on real developer workflows such as multi-file refactors and long debugging sessions, it plans, acts, observes results, and self-corrects over long horizons rather than making single tool calls. SageMaker JumpStart offers two variants: BF16 (Muse-Spark-Open-816B-A42B) and NVFP4 quantized (Muse-Spark-Open-816B-A42B-NVFP4), with the NVFP4 variant requiring roughly a quarter of the memory for cost-efficient deployment.
With SageMaker JumpStart, customers can deploy Muse Spark Open with just a few clicks, with the endpoint running in their own AWS account for full control over source code and prompts.
To get started with this model, navigate to the SageMaker JumpStart model catalog in the SageMaker console or use the SageMaker Python SDK to deploy the model to your AWS account. For more information about deploying and using foundation models in SageMaker JumpStart, see the Amazon SageMaker JumpStart documentation.
AWS HealthOmics now supports sharing VPCs across accounts, enabling your workflows to access resources in Amazon Virtual Private Clouds (VPCs) managed by other AWS accounts with AWS Resource Access Manager (RAM). 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 shared VPCs, customers can centralize networking administration by sharing subnets and security groups from a single VPC across multiple accounts in their organization, and HealthOmics then places each account’s workflows directly into those shared subnets. With cross-account VPC sharing, multiple accounts run inside one centrally managed VPC, instead of duplicating endpoints across VPCs. Workflows in participating accounts can access data privately without separate VPC peering connections or duplicated VPC endpoints. Previously, customers with centralized networking had to create separate AWS PrivateLink VPC endpoints in each VPC and maintain individual route tables using VPC peering. Cross-account VPC sharing reduces infrastructure overhead and simplifies network management for organizations with centralized networking while allowing researchers and developers to run bioinformatics workflows in their own accounts.
Shared VPCs is available in all Regions where AWS HealthOmics is available: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul, Tokyo). To get started, see the AWS HealthOmics User Guide.
AWS HealthOmics now supports sharing VPCs across accounts, enabling your workflows to access resources in Amazon Virtual Private Clouds (VPCs) managed by other AWS accounts with AWS Resource Access Manager (RAM). 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 shared VPCs, customers can centralize networking administration by sharing subnets and security groups from a single VPC across multiple accounts in their organization, and HealthOmics then places each account’s workflows directly into those shared subnets. With cross-account VPC sharing, multiple accounts run inside one centrally managed VPC, instead of duplicating endpoints across VPCs. Workflows in participating accounts can access data privately without separate VPC peering connections or duplicated VPC endpoints. Previously, customers with centralized networking had to create separate AWS PrivateLink VPC endpoints in each VPC and maintain individual route tables using VPC peering. Cross-account VPC sharing reduces infrastructure overhead and simplifies network management for organizations with centralized networking while allowing researchers and developers to run bioinformatics workflows in their own accounts.
Shared VPCs is available in all Regions where AWS HealthOmics is available: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), and Asia Pacific (Singapore, Seoul, Tokyo). To get started, see the AWS HealthOmics User Guide.
Today, AWS Transform for full-stack Windows modernization adds support for cross-region deployment of converted Amazon Aurora PostgreSQL databases and is available in seven additional AWS Regions. Together these changes give customers more control over where their modernized databases are deployed after SQL Server modernization, supporting data residency, latency, and disaster recovery requirements.
Customers can upload SQL Server Database Design Language (DDL) files and set a target AWS Region in the transformation plan to convert the database and deploy the resulting Aurora PostgreSQL cluster to a different AWS Region. The same workflow makes dependent .NET applications PostgreSQL compatible, updating connection strings and ADO.NET and Entity Framework data-access calls.
With this expansion, AWS Transform for full-stack Windows modernization is now available in the following Regions:
US East (N. Virginia), Europe (Frankfurt), Europe (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Tokyo), Asia Pacific (Sydney), and Canada (Montreal).
Today, AWS Transform for full-stack Windows modernization adds support for cross-region deployment of converted Amazon Aurora PostgreSQL databases and is available in seven additional AWS Regions. Together these changes give customers more control over where their modernized databases are deployed after SQL Server modernization, supporting data residency, latency, and disaster recovery requirements.
Customers can upload SQL Server Database Design Language (DDL) files and set a target AWS Region in the transformation plan to convert the database and deploy the resulting Aurora PostgreSQL cluster to a different AWS Region. The same workflow makes dependent .NET applications PostgreSQL compatible, updating connection strings and ADO.NET and Entity Framework data-access calls.
With this expansion, AWS Transform for full-stack Windows modernization is now available in the following Regions:
US East (N. Virginia), Europe (Frankfurt), Europe (London), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Tokyo), Asia Pacific (Sydney), and Canada (Montreal).
To get started, you can go to AWS Transform product page or see AWS Transform for full-stack Windows documentation.
AWS Security Hub CSPM (https://aws.amazon.com/security-hub/) now supports automated security checks that align with the Cyber Risk Institute (CRI) profile. The CRI Profile is a cybersecurity framework developed by the Cyber Risk Institute, a non-profit coalition of financial institutions and trade associations. The framework harmonizes cybersecurity and regulatory expectations that apply to the financial services sector into a common set of requirements, so that an organization can assess itself once and report against multiple regulations. AWS Security Hub CSPM provides 404 controls that support a subset of CRI Profile v2.2 requirements; the controls don’t support requirements that require manual checks.
The new standard is now available in all AWS Regions where Security Hub CSPM is currently available, including the AWS GovCloud (US) and the China Regions. To quickly enable the standard across your AWS environment, we recommend that you use Security Hub central configuration. With this approach, you can enable the standard in all or only some of your organization’s accounts and across all AWS Regions that are linked to Security Hub with a single action.
AWS Security Hub CSPM (https://aws.amazon.com/security-hub/) now supports automated security checks that align with the Cyber Risk Institute (CRI) profile. The CRI Profile is a cybersecurity framework developed by the Cyber Risk Institute, a non-profit coalition of financial institutions and trade associations. The framework harmonizes cybersecurity and regulatory expectations that apply to the financial services sector into a common set of requirements, so that an organization can assess itself once and report against multiple regulations. AWS Security Hub CSPM provides 404 controls that support a subset of CRI Profile v2.2 requirements; the controls don’t support requirements that require manual checks.
The new standard is now available in all AWS Regions where Security Hub CSPM is currently available, including the AWS GovCloud (US) and the China Regions. To quickly enable the standard across your AWS environment, we recommend that you use Security Hub central configuration. With this approach, you can enable the standard in all or only some of your organization’s accounts and across all AWS Regions that are linked to Security Hub with a single action.
To learn more, see CRI Profile v2.2 (https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference-cri-profile.html) in the AWS Security Hub CSPM user guide. To receive notifications about new Security Hub CSPM features and controls subscribe to the Security Hub SNS topic (https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-announcements.html). You can also try Security Hub CSPM at no cost for 30 days (https://aws.amazon.com/security-hub/cspm/pricing/) with the AWS Free Tier offering.
Amazon CloudWatch now supports conditional log routing and chained parsers via pipelines, giving you more control over how log data is transformed and which CloudWatch log group it’s sent to. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.
Log pipelines often carry a mix of event types that belong in different places, and individual events can nest one log format inside another. With conditional log routing, you define routes that send each event to a different CloudWatch log group based on conditions evaluated against processed fields, so you can separate events by severity, source, or type and apply the right retention and access controls to each. With chained parsers, you can apply multiple parser processors in sequence, where later parsers consume fields produced by earlier ones. For example, you can parse a JSON envelope first, then apply a Grok parser to a field it extracts. Together, these capabilities let you structure diverse log formats and route them to the right log groups in a single pipeline.
Conditional routing and chained parsers are available in all commercial AWS Regions where CloudWatch pipelines is generally available. You can configure these capabilities using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.
Amazon CloudWatch now supports conditional log routing and chained parsers via pipelines, giving you more control over how log data is transformed and which CloudWatch log group it’s sent to. CloudWatch pipelines is a fully managed service that ingests, transforms, and routes telemetry to CloudWatch without managing infrastructure.
Log pipelines often carry a mix of event types that belong in different places, and individual events can nest one log format inside another. With conditional log routing, you define routes that send each event to a different CloudWatch log group based on conditions evaluated against processed fields, so you can separate events by severity, source, or type and apply the right retention and access controls to each. With chained parsers, you can apply multiple parser processors in sequence, where later parsers consume fields produced by earlier ones. For example, you can parse a JSON envelope first, then apply a Grok parser to a field it extracts. Together, these capabilities let you structure diverse log formats and route them to the right log groups in a single pipeline.
Conditional routing and chained parsers are available in all commercial AWS Regions where CloudWatch pipelines is generally available. You can configure these capabilities using the AWS Management Console, AWS CLI, or AWS SDKs. To get started, see the Amazon CloudWatch pipelines documentation.
The AWS Transfer Family console now supports SVG files for logos and ICO files for favicons in web apps, with upload limits increased to 2 MB. This gives you more flexibility to use existing branding assets when customizing your web app.
Previously, the console accepted only JPG and PNG files and limited logo uploads to 50 KB and favicon uploads to 20 KB. The console automatically resizes images and converts them to JPG or PNG before saving them. Existing API upload limits and format requirements remain unchanged.
These capabilities are available in all AWS Regions where Transfer Family web apps are offered. To learn more, see the Transfer Family web apps tutorial.
The AWS Transfer Family console now supports SVG files for logos and ICO files for favicons in web apps, with upload limits increased to 2 MB. This gives you more flexibility to use existing branding assets when customizing your web app.
Previously, the console accepted only JPG and PNG files and limited logo uploads to 50 KB and favicon uploads to 20 KB. The console automatically resizes images and converts them to JPG or PNG before saving them. Existing API upload limits and format requirements remain unchanged.
These capabilities are available in all AWS Regions where Transfer Family web apps are offered. To learn more, see the Transfer Family web apps tutorial.
