Publicado el — Deja un comentario

AWS Elemental MediaTailor now offers Yield Optimization to automatically fill ad breaks with Amazon Ads demand

AWS Elemental MediaTailor now offers Yield Optimization, a new capability that automatically monetizes unused ad inventory with Amazon Ads demand during server-side ad insertion (SSAI) for livestreams. Available exclusively to publishers in the Amazon Publisher Services (APS) Streaming TV program, yield optimization turns unfilled ad breaks into monetized impressions at zero cost to enable and with no additional infrastructure required.

Because ads are stitched directly into the stream before reaching the viewer, they play seamlessly on every device. Key highlights:

– Built for scale: yield optimization is designed for large-scale live events such as professional league championships, with low latency and fast response times to maximize ad fill during peak viewership.

– Brand safe: demand is filtered by category to avoid competitive conflicts within the same ad break. publishers set their own price floors and category rules to maintain full control over which ads run in their streams.

– Simple to enable: configure yield optimization through the MediaTailor API or Console. No additional infrastructure or client-side changes are required.

– Performance visibility: monitor ad fill rate improvements using MediaTailor metrics in Amazon CloudWatch. Track revenue and earnings through the APS Publisher portal.

AWS Elemental MediaTailor yield optimization is available at no additional cost in all AWS Regions where MediaTailor is available, including US East (Ohio), US East (N. Virginia), US West (Oregon); Africa (Cape Town); Asia Pacific (Hyderabad, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo); Canada (Central); Europe (Frankfurt, Ireland, London, Paris, Stockholm); Middle East (UAE); and South America (São Paulo). To learn more, visit the AWS Elemental MediaTailor documentation.

 

​AWS Elemental MediaTailor now offers Yield Optimization, a new capability that automatically monetizes unused ad inventory with Amazon Ads demand during server-side ad insertion (SSAI) for livestreams. Available exclusively to publishers in the Amazon Publisher Services (APS) Streaming TV program, yield optimization turns unfilled ad breaks into monetized impressions at zero cost to enable and with no additional infrastructure required.
Because ads are stitched directly into the stream before reaching the viewer, they play seamlessly on every device. Key highlights:
– Built for scale: yield optimization is designed for large-scale live events such as professional league championships, with low latency and fast response times to maximize ad fill during peak viewership.
– Brand safe: demand is filtered by category to avoid competitive conflicts within the same ad break. publishers set their own price floors and category rules to maintain full control over which ads run in their streams.
– Simple to enable: configure yield optimization through the MediaTailor API or Console. No additional infrastructure or client-side changes are required.
– Performance visibility: monitor ad fill rate improvements using MediaTailor metrics in Amazon CloudWatch. Track revenue and earnings through the APS Publisher portal.
AWS Elemental MediaTailor yield optimization is available at no additional cost in all AWS Regions where MediaTailor is available, including US East (Ohio), US East (N. Virginia), US West (Oregon); Africa (Cape Town); Asia Pacific (Hyderabad, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo); Canada (Central); Europe (Frankfurt, Ireland, London, Paris, Stockholm); Middle East (UAE); and South America (São Paulo). To learn more, visit the AWS Elemental MediaTailor documentation.  

Publicado el — Deja un comentario

Amazon Connect Customer now lets you set specific capacity limits for different types of Tasks and Emails

Amazon Connect Customer now gives contact center managers the ability to set specific capacity limits for different kinds of work. Previously, concurrency settings were applied at the channel level so all contacts within a channel were treated the same regardless of complexity or effort required. With this launch, managers can classify Task and Email contacts into workload types based on complexity, priority, or business function, each with its own concurrency and interruption rules. For example, a manager can configure agents to handle up to 3 simple, low-effort Tasks concurrently while limiting complex, high-attention Tasks to 1 at a time.

Specific capacity limits for Task and Email channels are available in all AWS commercial and AWS GovCloud (US-West) regions where Amazon Connect Customer is offered. To learn more, see the Amazon Connect Customer Administrator Guide. To learn more about Amazon Connect Customer, visit the Amazon Connect Customer website.

 

​Amazon Connect Customer now gives contact center managers the ability to set specific capacity limits for different kinds of work. Previously, concurrency settings were applied at the channel level so all contacts within a channel were treated the same regardless of complexity or effort required. With this launch, managers can classify Task and Email contacts into workload types based on complexity, priority, or business function, each with its own concurrency and interruption rules. For example, a manager can configure agents to handle up to 3 simple, low-effort Tasks concurrently while limiting complex, high-attention Tasks to 1 at a time. Specific capacity limits for Task and Email channels are available in all AWS commercial and AWS GovCloud (US-West) regions where Amazon Connect Customer is offered. To learn more, see the Amazon Connect Customer Administrator Guide. To learn more about Amazon Connect Customer, visit the Amazon Connect Customer website.  

Publicado el — Deja un comentario

AWS Transform for .NET modernization is now generally available via CLI

Today, AWS announced the general availability of an AWS-managed transformation for .NET modernization in AWS Transform custom that you can trigger with a single one-line CLI command. You can run this transformation interactively, or script it into any existing pipeline or workflow to run autonomously. The CLI experience complements the existing AWS Transform for .NET experiences: the web application, Visual Studio IDE, Kiro Power, and MCP agents.

AWS Transform custom enables organizations to modernize and transform code at scale using AWS-managed and custom transformations. You can upgrade language versions, migrate frameworks, optimize performance, and analyze code bases using transformations that are ready to use or can be customized to meet your organization’s specific requirements. These transformations benefit from continuous improvement, learning from each engagement to deliver more accurate and efficient results.

AWS Transform custom and AWS Transform for .NET are available in eight AWS Regions: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central), and Europe (Frankfurt, London).

The .NET modernization transformation includes 50,000 free agent minutes per month. View AWS Transform Pricing for pricing details and examples. To learn more, see AWS-Managed Transformations in the AWS Transform User Guide.

 

​Today, AWS announced the general availability of an AWS-managed transformation for .NET modernization in AWS Transform custom that you can trigger with a single one-line CLI command. You can run this transformation interactively, or script it into any existing pipeline or workflow to run autonomously. The CLI experience complements the existing AWS Transform for .NET experiences: the web application, Visual Studio IDE, Kiro Power, and MCP agents.
AWS Transform custom enables organizations to modernize and transform code at scale using AWS-managed and custom transformations. You can upgrade language versions, migrate frameworks, optimize performance, and analyze code bases using transformations that are ready to use or can be customized to meet your organization’s specific requirements. These transformations benefit from continuous improvement, learning from each engagement to deliver more accurate and efficient results.
AWS Transform custom and AWS Transform for .NET are available in eight AWS Regions: US East (N. Virginia), Asia Pacific (Mumbai, Tokyo, Seoul, Sydney), Canada (Central), and Europe (Frankfurt, London).
The .NET modernization transformation includes 50,000 free agent minutes per month. View AWS Transform Pricing for pricing details and examples. To learn more, see AWS-Managed Transformations in the AWS Transform User Guide.  

Publicado el — Deja un comentario

AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances

AWS Lambda now supports a 90-minute function timeout for asynchronous and event source mapping (ESM) invocations on Lambda Managed Instances (LMI), a 6x increase from the previous 15-minute limit. You can now run data processing, media transcoding, financial calculations, AI inference, and batch workloads on Lambda for jobs that require longer continuous execution, without re-architecting your applications.

Customers use Lambda to build serverless applications like event-driven processors, API backends, and data processing pipelines. For data-intensive workloads like media transcoding, financial calculations (such as Monte Carlo simulations), and AI inference that need longer continuous execution, Lambda’s 15-minute function timeout limit required customers to adopt architectural workarounds. With today’s launch, you can configure a function timeout of up to 90 minutes for asynchronous and ESM invocations on Lambda Managed Instances. Lambda Managed Instances lets you process multiple concurrent requests per instance, access specialized compute configurations, and drive cost efficiency through EC2 pricing advantages, without managing infrastructure. The increased function timeout also applies to invocations within Lambda durable functions, which allow you to checkpoint and replay steps for longer-running invocations. When invoked asynchronously, a multi-step durable execution can run for up to 1 year.

You can configure up to a 90-minute function timeout for asynchronous and ESM invocations via the AWS Lambda Console, AWS CLI, Lambda APIs, Infrastructure as Code tooling, or the Agent Toolkit for AWS. Synchronous invocations retain the existing 15-minute maximum timeout. This feature is available in all AWS Regions where Lambda Managed Instances is available.

To learn more about configuring the 90-minute function timeout, see the Lambda developer guide. For combining extended timeouts with checkpoint-and-replay resilience, see the durable functions documentation. For pricing details, see AWS Lambda Pricing. To learn more about AWS Lambda, visit aws.amazon.com/lambda. 

 

​AWS Lambda now supports a 90-minute function timeout for asynchronous and event source mapping (ESM) invocations on Lambda Managed Instances (LMI), a 6x increase from the previous 15-minute limit. You can now run data processing, media transcoding, financial calculations, AI inference, and batch workloads on Lambda for jobs that require longer continuous execution, without re-architecting your applications.
Customers use Lambda to build serverless applications like event-driven processors, API backends, and data processing pipelines. For data-intensive workloads like media transcoding, financial calculations (such as Monte Carlo simulations), and AI inference that need longer continuous execution, Lambda’s 15-minute function timeout limit required customers to adopt architectural workarounds. With today’s launch, you can configure a function timeout of up to 90 minutes for asynchronous and ESM invocations on Lambda Managed Instances. Lambda Managed Instances lets you process multiple concurrent requests per instance, access specialized compute configurations, and drive cost efficiency through EC2 pricing advantages, without managing infrastructure. The increased function timeout also applies to invocations within Lambda durable functions, which allow you to checkpoint and replay steps for longer-running invocations. When invoked asynchronously, a multi-step durable execution can run for up to 1 year.
You can configure up to a 90-minute function timeout for asynchronous and ESM invocations via the AWS Lambda Console, AWS CLI, Lambda APIs, Infrastructure as Code tooling, or the Agent Toolkit for AWS. Synchronous invocations retain the existing 15-minute maximum timeout. This feature is available in all AWS Regions where Lambda Managed Instances is available.
To learn more about configuring the 90-minute function timeout, see the Lambda developer guide. For combining extended timeouts with checkpoint-and-replay resilience, see the durable functions documentation. For pricing details, see AWS Lambda Pricing. To learn more about AWS Lambda, visit aws.amazon.com/lambda.   

Publicado el — Deja un comentario

AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances

AWS Lambda now supports AWS Graviton5-powered C9g, C9gd, M9g, and M9gd instances on Lambda Managed Instances. You can now run your Lambda functions on the latest generation of Graviton processors, delivering up to 25% better compute performance compared to Graviton4-powered instances.

AWS Lambda Managed Instances lets you run Lambda functions on your AWS EC2 instances while maintaining Lambda’s operational simplicity. With Lambda Managed Instances, you can access specialized compute configurations and drive cost efficiency through EC2 pricing advantages, without managing infrastructure. Lambda Managed Instances fully manages all infrastructure tasks, including instance lifecycle, OS and runtime patching, built-in routing, load balancing, and auto-scaling based on configurable parameters – so you can focus on writing code. Starting today, you can leverage Lambda Managed Instances with the latest Graviton5-powered instances, which deliver up to 25% better compute performance compared to the previous generation Graviton4-powered instances.

To get started, you can specify the desired Graviton5 instance type (C9g, C9gd, M9g, or M9gd) when you create a capacity provider. When you set the instance type to default, Lambda automatically includes Graviton5 instances in the list of instances it chooses from, based on your function’s configured architecture, memory size, and memory-to-vCPU ratio.

AWS Lambda Managed Instances supports C9g, C9gd, M9g, and M9gd instance types in all AWS Regions where both Lambda Managed Instances and these EC2 instances are available. To learn more, visit the Lambda Managed Instances documentation and AWS Lambda pricing. 

 

​AWS Lambda now supports AWS Graviton5-powered C9g, C9gd, M9g, and M9gd instances on Lambda Managed Instances. You can now run your Lambda functions on the latest generation of Graviton processors, delivering up to 25% better compute performance compared to Graviton4-powered instances.
AWS Lambda Managed Instances lets you run Lambda functions on your AWS EC2 instances while maintaining Lambda’s operational simplicity. With Lambda Managed Instances, you can access specialized compute configurations and drive cost efficiency through EC2 pricing advantages, without managing infrastructure. Lambda Managed Instances fully manages all infrastructure tasks, including instance lifecycle, OS and runtime patching, built-in routing, load balancing, and auto-scaling based on configurable parameters – so you can focus on writing code. Starting today, you can leverage Lambda Managed Instances with the latest Graviton5-powered instances, which deliver up to 25% better compute performance compared to the previous generation Graviton4-powered instances.
To get started, you can specify the desired Graviton5 instance type (C9g, C9gd, M9g, or M9gd) when you create a capacity provider. When you set the instance type to default, Lambda automatically includes Graviton5 instances in the list of instances it chooses from, based on your function’s configured architecture, memory size, and memory-to-vCPU ratio.
AWS Lambda Managed Instances supports C9g, C9gd, M9g, and M9gd instance types in all AWS Regions where both Lambda Managed Instances and these EC2 instances are available. To learn more, visit the Lambda Managed Instances documentation and AWS Lambda pricing.   

Publicado el — Deja un comentario

Amazon Bedrock Managed Knowledge Base adds APIs and console support for debugging document-level access control

AWS announces the CheckIngestedDocumentAcl and GetIngestedDocumentAcl APIs for Amazon Bedrock Managed Knowledge Base, giving customers a self-service way to debug document access issues and audit document-level permissions. When a user doesn’t see an expected document in retrieval results for ACL-enabled data sources, it can be difficult to determine whether the cause is an access control misconfiguration or something else entirely. These new APIs and the accompanying console experience close that gap, enabling you to quickly diagnose and resolve permission issues without opening a support case.

CheckIngestedDocumentAcl lets you verify whether a specific user has access to a given ingested document, while GetIngestedDocumentAcl returns the full ACL attached to a document so you can audit exactly what permissions are configured and catch misconfigurations. The console also introduces a new Document Access Control section on the data source details page, where you can check access by entering a document ID and user email or retrieve a document’s full ACL by document ID. Together, these capabilities give administrators the visibility they need to manage access control at scale across enterprise knowledge bases.

To learn more, see CheckIngestedDocumentAcl and GetIngestedDocumentAcl in the Amazon Bedrock API Reference. For more information about Amazon Bedrock Managed Knowledge Base, visit the Amazon Bedrock Knowledge Bases product page.

 

​AWS announces the CheckIngestedDocumentAcl and GetIngestedDocumentAcl APIs for Amazon Bedrock Managed Knowledge Base, giving customers a self-service way to debug document access issues and audit document-level permissions. When a user doesn’t see an expected document in retrieval results for ACL-enabled data sources, it can be difficult to determine whether the cause is an access control misconfiguration or something else entirely. These new APIs and the accompanying console experience close that gap, enabling you to quickly diagnose and resolve permission issues without opening a support case.
CheckIngestedDocumentAcl lets you verify whether a specific user has access to a given ingested document, while GetIngestedDocumentAcl returns the full ACL attached to a document so you can audit exactly what permissions are configured and catch misconfigurations. The console also introduces a new Document Access Control section on the data source details page, where you can check access by entering a document ID and user email or retrieve a document’s full ACL by document ID. Together, these capabilities give administrators the visibility they need to manage access control at scale across enterprise knowledge bases.
To learn more, see CheckIngestedDocumentAcl and GetIngestedDocumentAcl in the Amazon Bedrock API Reference. For more information about Amazon Bedrock Managed Knowledge Base, visit the Amazon Bedrock Knowledge Bases product page.  

Publicado el — Deja un comentario

Amazon Bedrock Managed Knowledge Base now supports Confluence Data Center as a native data source connector

AWS announces the Confluence Data Center data source connector for Amazon Bedrock Managed Knowledge Base, a fully managed retrieval-augmented generation (RAG) service. Customers running self-hosted Confluence Data Center instances can now crawl blogs and pages from their Confluence spaces directly into their managed knowledge base. Previously, bringing Confluence Data Center content into Bedrock Knowledge Bases required building custom ingestion pipelines—now, you provide your instance credentials, and the connector handles data crawling, metadata extraction, and incremental sync automatically.
The Confluence Data Center connector gives your AI agents access to the institutional knowledge your teams already maintain in Confluence, including wiki pages and blog posts across spaces. You can use filters to scope crawls to specific spaces or content types, ensuring only relevant content is ingested and keeping your knowledge base focused and cost-efficient. This makes it easy to power internal assistants grounded in engineering documentation, runbooks, or team knowledge bases hosted on Confluence Data Center.
To learn more, see Confluence Data Center data source connector in the Amazon Bedrock User Guide. For more information about Amazon Bedrock Managed Knowledge Base, visit the Amazon Bedrock Knowledge Bases product page.

 

​AWS announces the Confluence Data Center data source connector for Amazon Bedrock Managed Knowledge Base, a fully managed retrieval-augmented generation (RAG) service. Customers running self-hosted Confluence Data Center instances can now crawl blogs and pages from their Confluence spaces directly into their managed knowledge base. Previously, bringing Confluence Data Center content into Bedrock Knowledge Bases required building custom ingestion pipelines—now, you provide your instance credentials, and the connector handles data crawling, metadata extraction, and incremental sync automatically. The Confluence Data Center connector gives your AI agents access to the institutional knowledge your teams already maintain in Confluence, including wiki pages and blog posts across spaces. You can use filters to scope crawls to specific spaces or content types, ensuring only relevant content is ingested and keeping your knowledge base focused and cost-efficient. This makes it easy to power internal assistants grounded in engineering documentation, runbooks, or team knowledge bases hosted on Confluence Data Center. To learn more, see Confluence Data Center data source connector in the Amazon Bedrock User Guide. For more information about Amazon Bedrock Managed Knowledge Base, visit the Amazon Bedrock Knowledge Bases product page.  

Publicado el — Deja un comentario

AWS Systems Manager now diagnoses more issues that cause EC2 instances to be unmanaged

Today, AWS Systems Manager extends its diagnosis capability to identify six additional categories of issues that can prevent Amazon EC2 instances and hybrid-activated nodes from becoming managed by Systems Manager. An instance must be managed by Systems Manager before you can patch it, run commands, connect with Session Manager, or collect inventory, and when an instance is unmanaged the cause can be difficult to isolate. The diagnosis previously covered network connectivity, and it now also identifies issues with IAM permissions, SSM Agent version, instance status checks, operating system configuration, Default Host Management Configuration, and hybrid activation.

With this broader coverage, more of your instances return a specific, actionable cause instead of an unidentified result, so you can bring your fleet under management faster. You run a diagnosis across your instances in the Systems Manager unified console experience, and Systems Manager reports the specific issues it finds in each category. Every diagnosed issue comes with step-by-step guidance to help you resolve it, and for some issues you can also run an AWS Systems Manager Automation runbook from the console to remediate the issue directly.

AWS Systems Manager diagnosis capability is available in all AWS Regions that are enabled by default. The capability runs as AWS Systems Manager Automation runbooks, so you pay standard Automation usage charges for the runbooks you run; see AWS Systems Manager pricing for details. To learn more, see the AWS Systems Manager User Guide, or visit the AWS Systems Manager product page.

 

​Today, AWS Systems Manager extends its diagnosis capability to identify six additional categories of issues that can prevent Amazon EC2 instances and hybrid-activated nodes from becoming managed by Systems Manager. An instance must be managed by Systems Manager before you can patch it, run commands, connect with Session Manager, or collect inventory, and when an instance is unmanaged the cause can be difficult to isolate. The diagnosis previously covered network connectivity, and it now also identifies issues with IAM permissions, SSM Agent version, instance status checks, operating system configuration, Default Host Management Configuration, and hybrid activation.
With this broader coverage, more of your instances return a specific, actionable cause instead of an unidentified result, so you can bring your fleet under management faster. You run a diagnosis across your instances in the Systems Manager unified console experience, and Systems Manager reports the specific issues it finds in each category. Every diagnosed issue comes with step-by-step guidance to help you resolve it, and for some issues you can also run an AWS Systems Manager Automation runbook from the console to remediate the issue directly.
AWS Systems Manager diagnosis capability is available in all AWS Regions that are enabled by default. The capability runs as AWS Systems Manager Automation runbooks, so you pay standard Automation usage charges for the runbooks you run; see AWS Systems Manager pricing for details. To learn more, see the AWS Systems Manager User Guide, or visit the AWS Systems Manager product page.  

Publicado el — Deja un comentario

Amazon API Gateway now supports mutual TLS for backend integrations

You can now configure Amazon API Gateway REST APIs to present an AWS Certificate Manager (ACM) certificate to your backend during the TLS handshake, enabling mutual TLS (mTLS). Previously, API Gateway could present only a self-signed certificate that it generated; now you can use a certificate signed by a certificate authority you trust. Your integration endpoint validates this certificate during the handshake to confirm the connection comes from your API. 

You can import a certificate into ACM from your existing public key infrastructure (PKI), or have ACM issue and manage one for you through AWS Private Certificate Authority. When a certificate is reimported or renewed in ACM, API Gateway propagates the update automatically, with no redeployment and no downtime. Combined with the existing inbound mTLS support for client connections, you can apply mutual authentication across both the client-to-API and API-to-backend connections, which is a common requirement in financial services, healthcare, and other regulated or zero-trust environments.

Mutual TLS for backend integrations is available in all commercial AWS Regions and the AWS GovCloud (US) Regions, where API Gateway REST APIs are available. You can configure it through the API Gateway console, AWS CLI, or AWS CloudFormation. To get started, see Amazon API Gateway documentation and AWS blog post. 

 

​You can now configure Amazon API Gateway REST APIs to present an AWS Certificate Manager (ACM) certificate to your backend during the TLS handshake, enabling mutual TLS (mTLS). Previously, API Gateway could present only a self-signed certificate that it generated; now you can use a certificate signed by a certificate authority you trust. Your integration endpoint validates this certificate during the handshake to confirm the connection comes from your API. 
You can import a certificate into ACM from your existing public key infrastructure (PKI), or have ACM issue and manage one for you through AWS Private Certificate Authority. When a certificate is reimported or renewed in ACM, API Gateway propagates the update automatically, with no redeployment and no downtime. Combined with the existing inbound mTLS support for client connections, you can apply mutual authentication across both the client-to-API and API-to-backend connections, which is a common requirement in financial services, healthcare, and other regulated or zero-trust environments.
Mutual TLS for backend integrations is available in all commercial AWS Regions and the AWS GovCloud (US) Regions, where API Gateway REST APIs are available. You can configure it through the API Gateway console, AWS CLI, or AWS CloudFormation. To get started, see Amazon API Gateway documentation and AWS blog post.   

Publicado el — Deja un comentario

OpenAI GPT-6 Astra is now generally available on Amazon Bedrock

Today, AWS announces the general availability of GPT-6 Astra from OpenAI on Amazon Bedrock. The latest and most capable model from OpenAI to date, GPT-6 Astra brings deeper reasoning and judgment, professional-quality writing and design, and advanced computer and browser use to demanding business workflows. It supports a context window of up to 1 million input tokens and can produce output aligned with organizational voice, templates, and standards. The Amazon Bedrock inference engine delivers the performance, security, and scale required for production workloads.

You can call GPT-6 Astra directly through supported Amazon Bedrock APIs or configure ChatGPT Work and Codex to use the model on Amazon Bedrock. Use it to build autonomous agents, analyze extensive document collections, investigate complex software issues, and create applications that require judgment across competing inputs. As part of this launch, OpenAI is also introducing new enterprise plugins for ChatGPT Work that extend Astra’s browser-use capabilities across common business applications. Established AWS controls help you secure workloads, govern access, and audit model invocation activity.

You can get started in the Amazon Bedrock console or programmatically supported Amazon Bedrock APIs. For information about supported AWS Regions, endpoints, APIs, features, inference profiles and pricing, see the Amazon Bedrock documentation. To explore what you can build with GPT-6 Astra, read the blog. 

 

​Today, AWS announces the general availability of GPT-6 Astra from OpenAI on Amazon Bedrock. The latest and most capable model from OpenAI to date, GPT-6 Astra brings deeper reasoning and judgment, professional-quality writing and design, and advanced computer and browser use to demanding business workflows. It supports a context window of up to 1 million input tokens and can produce output aligned with organizational voice, templates, and standards. The Amazon Bedrock inference engine delivers the performance, security, and scale required for production workloads.
You can call GPT-6 Astra directly through supported Amazon Bedrock APIs or configure ChatGPT Work and Codex to use the model on Amazon Bedrock. Use it to build autonomous agents, analyze extensive document collections, investigate complex software issues, and create applications that require judgment across competing inputs. As part of this launch, OpenAI is also introducing new enterprise plugins for ChatGPT Work that extend Astra’s browser-use capabilities across common business applications. Established AWS controls help you secure workloads, govern access, and audit model invocation activity.
You can get started in the Amazon Bedrock console or programmatically supported Amazon Bedrock APIs. For information about supported AWS Regions, endpoints, APIs, features, inference profiles and pricing, see the Amazon Bedrock documentation. To explore what you can build with GPT-6 Astra, read the blog.