Amazon Quick connectors let users leverage tools and services such as Outlook, Slack, Salesforce, Jira, and homegrown MCP servers directly into their workflows across chat, agents, apps, flows, and deep research. Today, Amazon Quick introduces new tool settings and MCP sync support that give admins and connector owners more control over how connectors are deployed and kept up to date.
Connector owners and admins can now selectively enable or disable individual tools within a connector to ensure only approved tools are available to end users. Additionally, new tool permission settings let connector owners decide which tools require consent before proceeding or give end users the flexibility to decide for themselves. Lastly, MCP sync keeps connectors current as external MCP servers add new tools, update descriptions, and evolve their capabilities, ensuring users always have the latest information to get their work done.
These features are available in all AWS Regions where Amazon Quick is available. To learn more, visit the Amazon Quick User Guide.
Amazon Quick connectors let users leverage tools and services such as Outlook, Slack, Salesforce, Jira, and homegrown MCP servers directly into their workflows across chat, agents, apps, flows, and deep research. Today, Amazon Quick introduces new tool settings and MCP sync support that give admins and connector owners more control over how connectors are deployed and kept up to date.
Connector owners and admins can now selectively enable or disable individual tools within a connector to ensure only approved tools are available to end users. Additionally, new tool permission settings let connector owners decide which tools require consent before proceeding or give end users the flexibility to decide for themselves. Lastly, MCP sync keeps connectors current as external MCP servers add new tools, update descriptions, and evolve their capabilities, ensuring users always have the latest information to get their work done.
These features are available in all AWS Regions where Amazon Quick is available. To learn more, visit the Amazon Quick User Guide.
AWS Config now supports 60 additional AWS resource types across key services including Amazon Bedrock, Amazon EC2, Amazon SageMaker, and AWS Organizations. This expansion provides greater coverage over your AWS environment, enabling you to more effectively discover, assess, audit, and remediate an even broader range of resources.
With this launch, if you have enabled recording for all resource types, then AWS Config will automatically track these new additions. The newly supported resource types are also available in Config rules and Config aggregators.
You can now use AWS Config to monitor the following newly supported resource types in all AWS Regions where the resources are available:
Resource Types:
AWS::AppSync::ChannelNamespace
AWS::EC2::RouteServer
AWS::Organizations::Policy
AWS::AppSync::SourceApiAssociation
AWS::EC2::RouteServerEndpoint
AWS::Organizations::ResourcePolicy
AWS::Bedrock::EnforcedGuardrailConfiguration
AWS::EC2::RouteServerPeer
AWS::QuickSight::RefreshSchedule
AWS::Bedrock::Flow
AWS::EKS::PodIdentityAssociation
AWS::RDS::DBProxy
AWS::Bedrock::FlowVersion
AWS::ElasticLoadBalancingV2::ListenerRule
AWS::S3Vectors::Index
AWS::Bedrock::PromptVersion
AWS::GameLiftStreams::Application
AWS::SageMaker::Action
AWS::BedrockAgentCore::OAuth2CredentialProvider
AWS::GameLiftStreams::StreamGroup
AWS::SageMaker::Algorithm
AWS::BedrockAgentCore::PaymentManager
AWS::IdentityStore::Group
AWS::SageMaker::App
AWS::BedrockAgentCore::Policy
AWS::IoT::TopicRuleDestination
AWS::SageMaker::Context
AWS::BedrockAgentCore::PolicyEngine
AWS::Lightsail::Container
AWS::SageMaker::Hub
AWS::BedrockAgentCore::TokenVault
AWS::Lightsail::Database
AWS::SageMaker::MlflowApp
AWS::Chime::AppInstance
AWS::Lightsail::Distribution
AWS::SageMaker::ModelCard
AWS::CloudTrail::ResourcePolicy
AWS::Lightsail::Domain
AWS::SageMaker::ModelPackage
AWS::CodePipeline::Webhook
AWS::Lightsail::Instance
AWS::SES::MailManagerArchive
AWS::Config::OrganizationConformancePack
AWS::Lightsail::LoadBalancer
AWS::Transfer::WebApp
AWS::Connect::AgentStatus
AWS::Logs::ResourcePolicy
AWS::WorkSpacesWeb::TrustStore
AWS::Connect::EvaluationForm
AWS::MediaConnect::Bridge
AWS::WorkSpacesWeb::UserAccessLoggingSettings
AWS::Connect::View
AWS::NetworkManager::CoreNetwork
AWS::XRay::Group
AWS::Connect::ViewVersion
AWS::Organizations::Account
AWS::XRay::ResourcePolicy
AWS::EC2::NetworkPerformanceMetricSubscription
AWS::Organizations::Organization
AWS::XRay::SamplingRule
AWS Config now supports 60 additional AWS resource types across key services including Amazon Bedrock, Amazon EC2, Amazon SageMaker, and AWS Organizations. This expansion provides greater coverage over your AWS environment, enabling you to more effectively discover, assess, audit, and remediate an even broader range of resources.
With this launch, if you have enabled recording for all resource types, then AWS Config will automatically track these new additions. The newly supported resource types are also available in Config rules and Config aggregators.
You can now use AWS Config to monitor the following newly supported resource types in all AWS Regions where the resources are available:
Resource Types:
Tres decisiones de arquitectura detrás de la plataforma legal de IA de PONS en Microsoft Azure
Resumen: PONS comparte tres decisiones de diseño detrás de su plataforma legal de IA en Microsoft Azure, desde separar el conocimiento jurídico público y los datos de los clientes hasta el uso de servicios gestionados e implementación de controles de seguridad y cumplimiento. El artículo destaca consideraciones prácticas para startups que desarrollan IA para clientes empresariales regulados.
Construir IA legal para industrias reguladas requiere mucho más que conectar un modelo a los documentos. Para las startups que sirven a industrias reguladas, el reto no es solo la capacidad del modelo, sino cómo el sistema gestiona fuentes confiables, datos privados, prioridades de infraestructura y requisitos de cumplimiento.
PONS construyó su plataforma de IA legal en torno a esas limitaciones. Al correr en Microsoft Azure, soporta investigación, redacción, revisión de contratos, diligencia debida y gestión de asuntos para despachos de abogados, equipos legales internos y otras organizaciones reguladas.
Este texto examina tres decisiones de diseño detrás de la plataforma y qué pueden aprender de ellas las startups que desarrollan IA para clientes regulados.
A través de Microsoft for Startups, PONS pudo acceder a créditos de startup, orientación técnica y presentaciones oportunas mientras desarrollaba su arquitectura Azure alojada en la UE. Según PONS, este soporte ayudó a su pequeño equipo a probar decisiones arquitectónicas frente a cargas reales y a abordar los requisitos técnicos para clientes regulados.
¿Construir IA para clientes empresariales regulados? Las startups elegibles pueden solicitar a Microsoft for Startups acceso a créditos de startup que se desbloquean a medida que crean, herramientas para desarrolladores, orientación técnica y oportunidades para llegar a clientes.
Dentro de la arquitectura legal de IA PONS en Azure
La parte difícil de la IA legal son los datos. Nuestro Data Factory responde con legislación real, actual y jurisprudencia, y luego los conecta a tus propios asuntos y archivos, sin salir de nuestro arrendamiento de Azure ni pasar por un modelo público. Tus datos son nuestra máxima prioridad: están cifrados con AES-256 antes de llegar a la base de datos, en reposo en Azure y en tránsito—por defecto en tres capas.
Tobias Zimmergren, CTO y cofundador técnico de PONS
La plataforma PONS consta de dos componentes principales: la PONS Data Factory y el PONS AI Engine.
PONS Data Factory es una cadena continua que valida, recopila, limpia e indexa fuentes jurídicas públicas, incluidas legislación, jurisprudencia y precedentes. Añade metadatos semánticos, estructura jerárquica, incrustaciones vectoriales y referencias enlazadas a fuentes para crear un corpus legal curado disponible en múltiples jurisdicciones.
El motor de IA PONS soporta razonamiento citado, redacción, revisión de contratos y extracción estructurada. Funciona tanto contra el corpus de Data Factory como contra documentos de clientes almacenados por separado (que no entran en Data Factory), con resultados evaluados para precisión legal, cobertura contextual, lenguaje y estructura, y que se reejecutan en automático en caso de fallo. El backend no llama directo al motor: el trabajo se publica en una cola que el AI Engine consulta, por lo que escala de manera independiente de la ruta de solicitud. Está impulsado por Azure OpenAI y alojado en Azure Sweden Central.
Los clientes también configuran asuntos, manuales, plantillas y una base de conocimiento conectada, lo que crea el contexto necesario para los flujos de trabajo específicos de la firma y el análisis legal.
Decisión de diseño uno: Separar el conocimiento confiable del contexto privado
PONS separa de manera intencionada su corpus legal público de los datos de los clientes. La Data Factory está diseñada para recopilar y actualizar de manera continua, fuentes legales públicas en diferentes jurisdicciones. Según PONS, los documentos de los clientes permanecen separados, y el flujo de datos unidireccional significa que no entran en la Data Factory y se procesan de manera independiente a través del AI Engine. Los datos de cada empresa permanecen en almacenamiento aislado y contenedores de bases de datos dentro de su entorno Azure de la región de la UE, cifrados en tránsito y en reposo, con el acceso asignado por defecto a los usuarios individuales.
Este límite permite a PONS actualizar y validar su corpus legal sin incorporar material privado de clientes en esa canalización. También proporciona a la plataforma un control arquitectónico claro para demostrar dónde residen los datos del cliente y evitar que se conviertan en parte de la capa de conocimiento legal público.
Las startups deberían tener en cuenta este patrón cuando su producto combina un cuerpo de información fiable actualizado de manera continua, con datos específicos o sensibles para el cliente, en especial cuando ambos requieren controles de acceso, residencia o gobernanza diferentes. Establecer el límite desde el principio puede reducir el riesgo de que los datos privados se entrelacen con las canaletas compartidas de ingestión e indexación a medida que el producto crece.
Segunda decisión: Utilizar servicios gestionados de Azure para centrar el esfuerzo de ingeniería en la diferenciación
Para ONS, elegir servicios gestionados fue una decisión de priorización de ingeniería: comprar la infraestructura indiferenciada y concentrar al equipo en la calidad de datos legales, razonamiento, evaluación y flujo de trabajo del cliente.
Este principio moldeó la arquitectura de Azure. Azure App Service gestiona la aplicación, por lo que no operan servidores ni gestionan despliegues de manera manual. Azure SQL Database y Microsoft Azure Storage almacenan datos estructurados y archivos de clientes con la residencia europea fijada en Sweden Central, lo que convierte la localización de datos en una decisión de configuración y no en un proyecto de ingeniería. Azure Key Vault mantiene secretos y certificados fuera del código de la aplicación.
Azure App Configuration mantiene configuraciones compartidas no sensibles, y las conexiones de servicio a servicio funcionan con identidad gestionada, por lo que no hay credenciales que rotar de manera manual. El trabajo de análisis se transfiere a través de un Azure Queue Storage en lugar de una llamada directa, lo que permite que el AI Engine escale de manera independiente de la ruta de la solicitud, y Azure Web PubSub envía resultados y notificaciones de vuelta a la aplicación web en tiempo real.
Para la capa de IA, Azure OpenAI proporciona los modelos base, mientras que Microsoft Foundry aloja los modelos ajustados y de soporte detrás de Data Factory y AI Engine. Esto proporciona a PONS capacidades de frontera sin necesidad de crear su propia pila de servicio de modelos.
El beneficio práctico es que hay menos infraestructura para que un equipo pequeño opere. PONS puede basarse en las capacidades de Azure para escalado, despliegues, identidad, registro y configuración regional, mientras dirige más esfuerzo de ingeniería hacia las partes del producto que evalúan los clientes. PONS aceptó menos control de bajo nivel a cambio de servicios Azure gestionados que apoyen sus requisitos de despliegue regional, identidad, registro y evidencia de cumplimiento.
Este enfoque es más útil cuando la diferenciación de una startup reside en datos específicos de dominio, flujos de trabajo o comportamiento del producto más que en operaciones de infraestructura. Evalúa un servicio gestionado por el trabajo recurrente que elimina, los controles que soporta y cómo su nivel de flexibilidad se alinea con los requisitos del producto.
Los servicios gestionados de Azure nos permiten centrarnos en nuestros clientes y sus necesidades en lugar de en la infraestructura. Escalado, despliegues, identidad, registros—esos son problemas que Azure ya ha resuelto a gran escala empresarial. Podemos dedicar nuestro tiempo a las partes del producto que solo nosotros podemos construir.
Tobias Zimmergren, CTO y cofundador técnico de PONS
Decisión tres: Convertir los requisitos de cumplimiento y seguridad en controles exigibles
El asesor jurídico general y los equipos de compras evalúan más que las capacidades de la IA. Para PONS, su arquitectura debe responder preguntas clave, como:
¿Dónde residen los datos?
¿Quién puede acceder a ella?
¿Se puede auditar el sistema?
¿Acabarán los documentos de los clientes entrenando el modelo de alguien?
¿Esto se mantiene en todas las jurisdicciones en las que operamos?
PONS afirma que aborda la localización y acceso de datos mediante aislamiento regional y permisos con alcance. Los registros de procedencia vinculada a citas y auditoría soportan la trazabilidad, mientras que las puertas de evaluación reejecutan en automático salidas fallidas y aplican rechazo por diseño cuando el sistema no puede conectar a tierra una respuesta. Los documentos del cliente no entran en Data Factory ni se utilizan para el entrenamiento de modelos. El corpus legal de Data Factory abarca múltiples jurisdicciones y sigue expandiéndose, mientras que los controles de aislamiento, acceso, registro y evaluación de la plataforma proporcionan una línea técnica común de referencia.
PONS también cita sus controles SOC 2 Tipo II, ISO 27001, el Reglamento General de Protección de Datos (GDPR, por sus siglas en inglés) y las pruebas de penetración como criterios de entrada importantes para la adquisición empresarial, pero los requisitos subyacentes continúan con el moldeado de la arquitectura y los controles de la plataforma.
Para startups que construyen para empresas en mercados regulados, estas preguntas son más útiles cuando se plantean desde el principio, mientras que los límites sobre datos, acceso y comportamiento del modelo pueden seguir diseñándose en el sistema en lugar de documentarse después. Para una orientación más amplia sobre cómo preparar soluciones Azure para clientes empresariales, consulten LA preparación empresarial para startups en Azure.
Exploren la plataforma de IA legal PONS
PONS funciona en producción con clientes en múltiples jurisdicciones de la UE, donde sirve de manera primordial a despachos de abogados y equipos legales internos, con pilotos activos en marcha en otros sectores. Si ustedes exploran cómo construir IA basada en citas con los requisitos de seguridad, privacidad y gobernanza en mente, pueden leer más sobre lo que hace PONS, la plataforma y la arquitectura que hay detrás en pons.io.
Construir para clientes empresariales regulados con Microsoft para startups
A medida que la plataforma se desarrollaba, los créditos de startups a través de Microsoft for Startups dieron a PONS la flexibilidad para probar decisiones arquitectónicas en cargas reales mientras gestionaba los costes de la nube durante el crecimiento inicial. Los especialistas de Microsoft proporcionaron orientación sobre decisiones técnicas complejas, mientras que las presentaciones oportunas ayudaron al equipo a abordar los requisitos de producción y mantener el impulso a medida que la plataforma escalaba.
Si se encuentran en el proceso de desarrollo de soluciones de IA para clientes empresariales en sectores regulados, Microsoft for Startups puede ayudarlos a construir rápido, escalar de manera inteligente y vender más. Empiecen hoy mismo con Microsoft for Startups.
Amazon Connect Customer announces the general availability of agentic CX designer, a no-code canvas for designing and deploying AI-powered self-service experiences. You can now build and launch voice and digital experiences that bring agentic and deterministic AI together to transform how you serve customers with the control and reliability enterprises demand. Your business teams users can go from designing conversations and integrating with the systems that run your business, to testing, to launching production-ready experiences in weeks, not months.
Agentic CX designer gives you the clarity of a flowchart with the power of a large language model. On a visual canvas you define the logic, guardrails, and integrations, and the model handles the natural conversation. For outcomes that have to be exact, such as eligibility, approvals, routing, or compliance, you define the workflow and the conversation follows it. You build, test, and deploy in the same place, so the team that designs an experience can validate it and put it into production without writing code or handing the work to engineering.
Amazon Connect Customer announces the general availability of agentic CX designer, a no-code canvas for designing and deploying AI-powered self-service experiences. You can now build and launch voice and digital experiences that bring agentic and deterministic AI together to transform how you serve customers with the control and reliability enterprises demand. Your business teams users can go from designing conversations and integrating with the systems that run your business, to testing, to launching production-ready experiences in weeks, not months.
Agentic CX designer gives you the clarity of a flowchart with the power of a large language model. On a visual canvas you define the logic, guardrails, and integrations, and the model handles the natural conversation. For outcomes that have to be exact, such as eligibility, approvals, routing, or compliance, you define the workflow and the conversation follows it. You build, test, and deploy in the same place, so the team that designs an experience can validate it and put it into production without writing code or handing the work to engineering.
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.
