Amazon RDS for SQL Server supports 18 additional SQL trace flags that you can enable through database parameter groups. Trace flags are configuration switches that modify SQL Server engine behavior — such as query optimizer cardinality estimation, lock escalation, statistics management, and memory handling — to allow database administrators to fine-tune performance and address workload-specific challenges. With this expansion, you have greater flexibility to optimize and stabilize your SQL Server workloads directly within your managed RDS environment.

The newly supported trace flags include: 647, 652, 1448, 3654, 4138, 4139, 7745, 8285, 8780, 9432, 9481, 9492, 9592, 11024, 11042, 12502, 12618, and 12656. These trace flags address scenarios such as query plan optimization, DDL performance improvements, availability group replication, Query Store behavior, automatic plan correction, and known engine bug mitigations. Because trace flags modify core SQL Server engine behavior, you should test them in a non-production environment before applying them to production instances. Some trace flags can impact system performance, increase memory usage, or change query execution plans in unexpected ways.

Trace flags are available in all AWS Regions where Amazon RDS for SQL Server is supported. To get started, update your RDS parameter group to enable the desired trace flags and apply it to your DB instance. To learn more, see Amazon RDS for SQL Server User Guide.

 

​Amazon RDS for SQL Server supports 18 additional SQL trace flags that you can enable through database parameter groups. Trace flags are configuration switches that modify SQL Server engine behavior — such as query optimizer cardinality estimation, lock escalation, statistics management, and memory handling — to allow database administrators to fine-tune performance and address workload-specific challenges. With this expansion, you have greater flexibility to optimize and stabilize your SQL Server workloads directly within your managed RDS environment.
The newly supported trace flags include: 647, 652, 1448, 3654, 4138, 4139, 7745, 8285, 8780, 9432, 9481, 9492, 9592, 11024, 11042, 12502, 12618, and 12656. These trace flags address scenarios such as query plan optimization, DDL performance improvements, availability group replication, Query Store behavior, automatic plan correction, and known engine bug mitigations. Because trace flags modify core SQL Server engine behavior, you should test them in a non-production environment before applying them to production instances. Some trace flags can impact system performance, increase memory usage, or change query execution plans in unexpected ways.
Trace flags are available in all AWS Regions where Amazon RDS for SQL Server is supported. To get started, update your RDS parameter group to enable the desired trace flags and apply it to your DB instance. To learn more, see Amazon RDS for SQL Server User Guide.  

Starting today, AWS Lambda supports SnapStart for functions packaged as container images, reducing startup times from several seconds to as low as sub-second. Lambda SnapStart is an opt-in capability that makes it easier for you to build highly responsive and scalable applications without provisioning resources or implementing complex performance optimizations.

Customers deploy Lambda functions with container images to align with their organization’s container-based deployment standards, or to package larger dependencies up to 10 GB. However, larger container images can experience startup times of several seconds as Lambda downloads image layers and initializes the runtime and application code. SnapStart addresses this by taking a snapshot of the initialized execution environment during function deployment, caching it, and resuming from it on invocation, instead of initializing from scratch. Previously, SnapStart was only supported for managed runtimes (Python, .NET, and Java). Starting today, customers can use SnapStart for container images to improve startup times for latency-sensitive workloads such as ML inference and interactive APIs.

Lambda SnapStart for container images is available in all commercial AWS Regions, except Asia Pacific (New Zealand) and Asia Pacific (Taipei). 

You can activate SnapStart for new or existing container image functions using AWS Lambda API, AWS Console, AWS Command Line Interface (AWS CLI), AWS CloudFormation, AWS Serverless Application Model (AWS SAM), AWS SDK, and AWS Cloud Development Kit (AWS CDK). If you use an AWS base image for Lambda with Java (version 11+), Python (version 3.12+), or .NET (version 8+), the experience remains the same as with functions deployed as .zip file archives. For all other AWS base images for Lambda (for example, Node.js or Ruby) or custom base images, refer to the developer guide. For more information about SnapStart, see Lambda documentation. To learn more about pricing for SnapStart for container image functions, visit AWS Lambda Pricing.

 

​Starting today, AWS Lambda supports SnapStart for functions packaged as container images, reducing startup times from several seconds to as low as sub-second. Lambda SnapStart is an opt-in capability that makes it easier for you to build highly responsive and scalable applications without provisioning resources or implementing complex performance optimizations.
Customers deploy Lambda functions with container images to align with their organization’s container-based deployment standards, or to package larger dependencies up to 10 GB. However, larger container images can experience startup times of several seconds as Lambda downloads image layers and initializes the runtime and application code. SnapStart addresses this by taking a snapshot of the initialized execution environment during function deployment, caching it, and resuming from it on invocation, instead of initializing from scratch. Previously, SnapStart was only supported for managed runtimes (Python, .NET, and Java). Starting today, customers can use SnapStart for container images to improve startup times for latency-sensitive workloads such as ML inference and interactive APIs.
Lambda SnapStart for container images is available in all commercial AWS Regions, except Asia Pacific (New Zealand) and Asia Pacific (Taipei). 
You can activate SnapStart for new or existing container image functions using AWS Lambda API, AWS Console, AWS Command Line Interface (AWS CLI), AWS CloudFormation, AWS Serverless Application Model (AWS SAM), AWS SDK, and AWS Cloud Development Kit (AWS CDK). If you use an AWS base image for Lambda with Java (version 11+), Python (version 3.12+), or .NET (version 8+), the experience remains the same as with functions deployed as .zip file archives. For all other AWS base images for Lambda (for example, Node.js or Ruby) or custom base images, refer to the developer guide. For more information about SnapStart, see Lambda documentation. To learn more about pricing for SnapStart for container image functions, visit AWS Lambda Pricing.  

AWS Deadline Cloud now supports sharing job bundles, giving teams a simple way to distribute and reuse render job templates without manual file distribution. Deadline Cloud is a fully managed service that helps teams run compute-intensive workloads in the cloud for visual effects, animation, product design, simulation, and gaming. 

Job bundles define the jobs you submit to Deadline Cloud, including the job template, parameters, and asset references. Previously, sharing a bundle with teammates meant distributing files through shared drives or manual copying. Now, you can publish a bundle to your queue directly from the submitter or the command line, and it immediately becomes available to everyone with access to that queue. Shared bundles are packaged as portable archives and stored in the queue’s existing job attachments bucket in Amazon S3, so there is no additional infrastructure or configuration to set up. This makes it easy for pipeline teams to publish standard, ready-to-submit job templates that artists can pick up and use.

You can browse bundles shared on your queue, on your local filesystem, or from your job submission history. You can preview each bundle’s name, description, steps, and parameters before selecting it. New CLI commands let you manage shared bundles from the command line and integrate bundle sharing into pipeline scripts.

This feature is available in all AWS Regions where Deadline Cloud is available. To get started, visit the AWS Deadline Cloud documentation.

 

​AWS Deadline Cloud now supports sharing job bundles, giving teams a simple way to distribute and reuse render job templates without manual file distribution. Deadline Cloud is a fully managed service that helps teams run compute-intensive workloads in the cloud for visual effects, animation, product design, simulation, and gaming. 
Job bundles define the jobs you submit to Deadline Cloud, including the job template, parameters, and asset references. Previously, sharing a bundle with teammates meant distributing files through shared drives or manual copying. Now, you can publish a bundle to your queue directly from the submitter or the command line, and it immediately becomes available to everyone with access to that queue. Shared bundles are packaged as portable archives and stored in the queue’s existing job attachments bucket in Amazon S3, so there is no additional infrastructure or configuration to set up. This makes it easy for pipeline teams to publish standard, ready-to-submit job templates that artists can pick up and use.
You can browse bundles shared on your queue, on your local filesystem, or from your job submission history. You can preview each bundle’s name, description, steps, and parameters before selecting it. New CLI commands let you manage shared bundles from the command line and integrate bundle sharing into pipeline scripts.
This feature is available in all AWS Regions where Deadline Cloud is available. To get started, visit the AWS Deadline Cloud documentation.  

Now generally available, Amazon Quick lets you build custom applications by simply describing them in natural language. Create project trackers, customer dashboards, and training portals in minutes instead of months. Whether you’re a product manager, finance lead, HR partner, or ops analyst, you can now turn ideas into fully functional apps without writing any code. Tell Quick what you need, and it builds a live, connected application with real-time data from your existing business systems.

Quick connects directly to the tools and data your business already uses, including Salesforce, Jira, Asana, ServiceNow, Microsoft 365, Google Workspace, databases, and data warehouses. Your apps stay current automatically as underlying data changes, and every connection respects your organization’s existing identity, authorization, and access control policies. Once built, you can publish and share apps instantly with specific users or your entire organization. Need to make a change like adding AI, updating the visual style, or connecting to another system? Just describe what you want and Quick handles it.

During preview, customers used Quick to replace spreadsheets and disconnected tools with purpose-built applications. New York Life built an e-learning portal for their Institutional Life team that consolidates onboarding, training, and compliance courses into a single experience. The Amazon Quick team tracks pipeline, customer requests, and adoption metrics in a weekly leadership review app that replaced manual data pulls from four different systems.

Building apps in Quick is available to Plus, Professional, and Enterprise customers starting September 1, 2026. To learn more, visit the Apps in Quick getting-started guide.

 

​Now generally available, Amazon Quick lets you build custom applications by simply describing them in natural language. Create project trackers, customer dashboards, and training portals in minutes instead of months. Whether you’re a product manager, finance lead, HR partner, or ops analyst, you can now turn ideas into fully functional apps without writing any code. Tell Quick what you need, and it builds a live, connected application with real-time data from your existing business systems.
Quick connects directly to the tools and data your business already uses, including Salesforce, Jira, Asana, ServiceNow, Microsoft 365, Google Workspace, databases, and data warehouses. Your apps stay current automatically as underlying data changes, and every connection respects your organization’s existing identity, authorization, and access control policies. Once built, you can publish and share apps instantly with specific users or your entire organization. Need to make a change like adding AI, updating the visual style, or connecting to another system? Just describe what you want and Quick handles it.
During preview, customers used Quick to replace spreadsheets and disconnected tools with purpose-built applications. New York Life built an e-learning portal for their Institutional Life team that consolidates onboarding, training, and compliance courses into a single experience. The Amazon Quick team tracks pipeline, customer requests, and adoption metrics in a weekly leadership review app that replaced manual data pulls from four different systems.
Building apps in Quick is available to Plus, Professional, and Enterprise customers starting September 1, 2026. To learn more, visit the Apps in Quick getting-started guide.  

Amazon Kinesis Data Streams now supports a dry run feature to check whether an API request would succeed without executing the operation. Customers can now set the new optional parameter ‘DryRun’ to true in their API requests to validate permissions before interacting with a stream in production.

Previously, customers had no safe way to test whether their application had the correct permissions to access a stream. They would often send a request engineered to fail after checking permissions, such as a PutRecord request with a payload deliberately larger than the maximum supported size. This approach was fragile as it depended on current service limits, and if those limits ever changed, the request could unexpectedly succeed, writing unintended records into the production stream and into any downstream consumers. Now, customers can simply set the parameter ‘DryRun’ to true to indicate they only want to validate the API request. If all checks complete successfully, the API returns a ‘DryRunOperationException’, confirming the request would have succeeded without the ‘DryRun’ parameter.

The dry run feature is available for five APIs (PutRecord, PutRecords, GetRecords, GetShardIterator, and SubscribeToShard) in all AWS Regions where Amazon Kinesis Data Streams is available. For more information about dry run, see Test your permissions and request inputs with dry run in the Amazon Kinesis Data Streams Developer Guide. To get started with dry run, see the Amazon Kinesis Data Streams API Reference.

 

​Amazon Kinesis Data Streams now supports a dry run feature to check whether an API request would succeed without executing the operation. Customers can now set the new optional parameter ‘DryRun’ to true in their API requests to validate permissions before interacting with a stream in production.
Previously, customers had no safe way to test whether their application had the correct permissions to access a stream. They would often send a request engineered to fail after checking permissions, such as a PutRecord request with a payload deliberately larger than the maximum supported size. This approach was fragile as it depended on current service limits, and if those limits ever changed, the request could unexpectedly succeed, writing unintended records into the production stream and into any downstream consumers. Now, customers can simply set the parameter ‘DryRun’ to true to indicate they only want to validate the API request. If all checks complete successfully, the API returns a ‘DryRunOperationException’, confirming the request would have succeeded without the ‘DryRun’ parameter.
The dry run feature is available for five APIs (PutRecord, PutRecords, GetRecords, GetShardIterator, and SubscribeToShard) in all AWS Regions where Amazon Kinesis Data Streams is available. For more information about dry run, see Test your permissions and request inputs with dry run in the Amazon Kinesis Data Streams Developer Guide. To get started with dry run, see the Amazon Kinesis Data Streams API Reference.  

AWS Backup now supports backup and restore of more than 1,000 Amazon S3 buckets per account, matching the Amazon S3 bucket quota configured for your account.

Previously, AWS Backup for Amazon S3 supported up to 1,000 buckets per account. With this launch, AWS Backup supports backing up all general purpose buckets in your account. Existing backup plans and configurations continue to work with no changes required if you are using default AWS Backup managed policies. For details on the required permissions for custom policies, see the AWS Backup documentation.

This capability is available in all AWS commercial and AWS GovCloud (US) Regions. To get started, visit the AWS Backup console.

 

​AWS Backup now supports backup and restore of more than 1,000 Amazon S3 buckets per account, matching the Amazon S3 bucket quota configured for your account.
Previously, AWS Backup for Amazon S3 supported up to 1,000 buckets per account. With this launch, AWS Backup supports backing up all general purpose buckets in your account. Existing backup plans and configurations continue to work with no changes required if you are using default AWS Backup managed policies. For details on the required permissions for custom policies, see the AWS Backup documentation.
This capability is available in all AWS commercial and AWS GovCloud (US) Regions. To get started, visit the AWS Backup console.  

Today, AWS announces support for self-managed PostgreSQL databases in Amazon CloudWatch Database Insights. Using CloudWatch Database Insights, you can now monitor your self-managed PostgreSQL instances running on Amazon EC2, alongside Amazon RDS and Amazon Aurora, to give you a complete view of your database fleet in a single console. 

Amazon CloudWatch Database Insights is a database observability solution that provides a curated experience to help you monitor database fleet health, diagnose issues, and resolve performance bottlenecks. With support for self-managed databases, you use the Amazon CloudWatch agent to collect health and performance data from your self-managed PostgreSQL instances. Your database appears in the Database Insights fleet view with live performance data, including database load, wait event analysis, query-level statistics, and host metrics. Monitor and troubleshoot your self-managed PostgreSQL instances using the same familiar Database Insights console and workflows you already use for your AWS-managed databases.

Amazon CloudWatch Database Insights support for self-managed PostgreSQL is available in all AWS Commercial Regions. To get started, see Monitoring Self-Managed Databases in the Amazon CloudWatch User Guide. For pricing details, see the Amazon CloudWatch pricing page.

 

​Today, AWS announces support for self-managed PostgreSQL databases in Amazon CloudWatch Database Insights. Using CloudWatch Database Insights, you can now monitor your self-managed PostgreSQL instances running on Amazon EC2, alongside Amazon RDS and Amazon Aurora, to give you a complete view of your database fleet in a single console. 
Amazon CloudWatch Database Insights is a database observability solution that provides a curated experience to help you monitor database fleet health, diagnose issues, and resolve performance bottlenecks. With support for self-managed databases, you use the Amazon CloudWatch agent to collect health and performance data from your self-managed PostgreSQL instances. Your database appears in the Database Insights fleet view with live performance data, including database load, wait event analysis, query-level statistics, and host metrics. Monitor and troubleshoot your self-managed PostgreSQL instances using the same familiar Database Insights console and workflows you already use for your AWS-managed databases.
Amazon CloudWatch Database Insights support for self-managed PostgreSQL is available in all AWS Commercial Regions. To get started, see Monitoring Self-Managed Databases in the Amazon CloudWatch User Guide. For pricing details, see the Amazon CloudWatch pricing page.  

Amazon Connect Customer now offers compact mode on the analytics dashboards, increasing data density so supervisors can see more of their operational data without scrolling. Compact mode reduces widget size, font, and minimizes filters to maximize screen space. For example, a supervisor on a 13-inch laptop toggles compact mode, which reduces row height, enabling them to view all team agents on the widget without scrolling and spot non-adherent agents faster.

Compact mode on dashboards is available in all AWS regions where Amazon Connect Customer is offered. To learn more about Amazon Connect Customer analytics dashboards, see the Amazon Connect Customer Administrator Guide.  To learn more about Amazon Connect Customer, visit the Amazon Connect Customer website.

 

​Amazon Connect Customer now offers compact mode on the analytics dashboards, increasing data density so supervisors can see more of their operational data without scrolling. Compact mode reduces widget size, font, and minimizes filters to maximize screen space. For example, a supervisor on a 13-inch laptop toggles compact mode, which reduces row height, enabling them to view all team agents on the widget without scrolling and spot non-adherent agents faster.
Compact mode on dashboards is available in all AWS regions where Amazon Connect Customer is offered. To learn more about Amazon Connect Customer analytics dashboards, see the Amazon Connect Customer Administrator Guide.  To learn more about Amazon Connect Customer, visit the Amazon Connect Customer website.  

Amazon Managed Workflows for Apache Airflow (MWAA) now supports Apache Airflow version 3.3.1, the latest release of the popular open-source workflow orchestration framework. Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier to set up and operate end-to-end data pipelines in the cloud.

Apache Airflow 3.3 introduces stateful tasks and multi-language support. With the new Task and Asset State Store, tasks can now persist durable state across retries and reruns, enabling cursor tracking and crash-safe reconnection to long-running jobs. The Language Task SDK (experimental) lets teams write task logic in Java or Go while keeping orchestration in Python. Additional improvements include expanded asset partitioning, pluggable retry policies, and bulk actions for DAG runs and task instances. Apache Airflow 3.3.1 also delivers stability, security, and UI improvements on top of these capabilities.

You can launch a new Apache Airflow 3.3.1 environment on Amazon MWAA, or upgrade from 3.2 or later, with a few clicks in the AWS Management Console in all currently supported Amazon MWAA regions. To learn more about Apache Airflow 3.3.1, visit the Amazon MWAA documentation and the Apache Airflow 3.3.1 change log in the Apache Airflow documentation.

Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.

 

​Amazon Managed Workflows for Apache Airflow (MWAA) now supports Apache Airflow version 3.3.1, the latest release of the popular open-source workflow orchestration framework. Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier to set up and operate end-to-end data pipelines in the cloud.
Apache Airflow 3.3 introduces stateful tasks and multi-language support. With the new Task and Asset State Store, tasks can now persist durable state across retries and reruns, enabling cursor tracking and crash-safe reconnection to long-running jobs. The Language Task SDK (experimental) lets teams write task logic in Java or Go while keeping orchestration in Python. Additional improvements include expanded asset partitioning, pluggable retry policies, and bulk actions for DAG runs and task instances. Apache Airflow 3.3.1 also delivers stability, security, and UI improvements on top of these capabilities.
You can launch a new Apache Airflow 3.3.1 environment on Amazon MWAA, or upgrade from 3.2 or later, with a few clicks in the AWS Management Console in all currently supported Amazon MWAA regions. To learn more about Apache Airflow 3.3.1, visit the Amazon MWAA documentation and the Apache Airflow 3.3.1 change log in the Apache Airflow documentation.
Apache, Apache Airflow, and Airflow are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.  

Etiquetas:

• Eventos
• IA
• México

The post De los experimentos con IA a la Frontier Transformation: lo que estamos viendo en América Latina appeared first on Source LATAM.

 

​The post De los experimentos con IA a la Frontier Transformation: lo que estamos viendo en América Latina appeared first on Source LATAM.