Amazon Bedrock Custom Model Import enables customers to import and run their customized foundation models on-demand without managing the underlying infrastructure. Customers can now get full transparency into the compute resources being used and calculate inference costs in real-time.

With this launch, customers are able to see the minimum compute resources, custom model units (CMUs), required to run their model prior to model invocation in the Bedrock console and through Bedrock APIs. As the model scales to handle more traffic, CloudWatch metrics provide real-time visibility into the inference costs by showing the total number of CMUs used. This enables customers to better control spend through near-instant cost visibility and take actions like making on-the fly model configuration changes to optimize for costs.

This feature is available in all regions where Amazon Bedrock Custom Model Import is supported. To learn more and get started, visit the Amazon Bedrock Custom Model Import page and see the documentation page for more details.

 

​Amazon Bedrock Custom Model Import enables customers to import and run their customized foundation models on-demand without managing the underlying infrastructure. Customers can now get full transparency into the compute resources being used and calculate inference costs in real-time. With this launch, customers are able to see the minimum compute resources, custom model units (CMUs), required to run their model prior to model invocation in the Bedrock console and through Bedrock APIs. As the model scales to handle more traffic, CloudWatch metrics provide real-time visibility into the inference costs by showing the total number of CMUs used. This enables customers to better control spend through near-instant cost visibility and take actions like making on-the fly model configuration changes to optimize for costs. This feature is available in all regions where Amazon Bedrock Custom Model Import is supported. To learn more and get started, visit the Amazon Bedrock Custom Model Import page and see the documentation page for more details.  

Amazon DynamoDB Streams now comes with AWS PrivateLink support, allowing you to invoke DynamoDB Streams APIs from within your Amazon Virtual Private Cloud (VPC) without traversing the public internet.

With AWS PrivateLink, you can simplify private network connectivity between virtual private clouds (VPCs), DynamoDB, and your on-premises data centers using interface VPC endpoints and private IP addresses. AWS PrivateLink is compatible with AWS Direct Connect and AWS Virtual Private Network (VPN) to facilitate private network connectivity, and helps you eliminate the need to use public IP addresses, configure firewall rules, or configure an internet gateway to access DynamoDB from your on-premises data centers. As a result, AWS PrivateLink helps you maintain compliance for your DynamoDB workloads over the private network.

AWS PrivateLink for Amazon DynamoDB is available in all AWS commercial Regions. You can get started with the feature by using the AWS Management Console, AWS API, AWS CLI, AWS SDK, or AWS CloudFormation. To learn more about using AWS PrivateLink, see the Amazon DynamoDB developer guide and Creating an Interface Endpoint. Please see AWS PrivateLink pricing for pricing details.

 

​Amazon DynamoDB Streams now comes with AWS PrivateLink support, allowing you to invoke DynamoDB Streams APIs from within your Amazon Virtual Private Cloud (VPC) without traversing the public internet. With AWS PrivateLink, you can simplify private network connectivity between virtual private clouds (VPCs), DynamoDB, and your on-premises data centers using interface VPC endpoints and private IP addresses. AWS PrivateLink is compatible with AWS Direct Connect and AWS Virtual Private Network (VPN) to facilitate private network connectivity, and helps you eliminate the need to use public IP addresses, configure firewall rules, or configure an internet gateway to access DynamoDB from your on-premises data centers. As a result, AWS PrivateLink helps you maintain compliance for your DynamoDB workloads over the private network. AWS PrivateLink for Amazon DynamoDB is available in all AWS commercial Regions. You can get started with the feature by using the AWS Management Console, AWS API, AWS CLI, AWS SDK, or AWS CloudFormation. To learn more about using AWS PrivateLink, see the Amazon DynamoDB developer guide and Creating an Interface Endpoint. Please see AWS PrivateLink pricing for pricing details.  

AWS Fault Injection Service (FIS) now supports a recovery action for Amazon Application Recovery Controller (ARC) zonal autoshift. A recovery action is a new FIS action type that allows customers to demonstrate how AWS responds during an availability incident. For example, when AWS detects potential infrastructure issues in an Availability Zone (AZ), such as power or network disruptions, zonal autoshift automatically shifts traffic away from the AZ. With the new FIS recovery action, customers that have enabled zonal autoshift can run the FIS AZ Availability: Power Interruption scenario to induce the expected symptoms of a complete interruption of power in an AZ and demonstrate how AWS would trigger zonal autoshift. This allows customers to tune their monitoring and recovery process to improve resiliency and application availability.

The FIS AZ Availability: Power Interruption scenario now includes the expected recovery from zonal autoshift in addition to the power interruption symptoms, including loss of zonal compute (Amazon EC2, EKS, and ECS), RDS and ElastiCache failover, and more. Running the scenario lets customers test and build confidence that their application responds as intended when an AZ is unavailable.

To get started, select the AZ Availability: Power Interruption scenario from the FIS scenario library. The action is available in all AWS Regions where FIS and zonal autoshift are available, including the AWS GovCloud (US) Regions. To learn more, visit the documentation.
 

 

​AWS Fault Injection Service (FIS) now supports a recovery action for Amazon Application Recovery Controller (ARC) zonal autoshift. A recovery action is a new FIS action type that allows customers to demonstrate how AWS responds during an availability incident. For example, when AWS detects potential infrastructure issues in an Availability Zone (AZ), such as power or network disruptions, zonal autoshift automatically shifts traffic away from the AZ. With the new FIS recovery action, customers that have enabled zonal autoshift can run the FIS AZ Availability: Power Interruption scenario to induce the expected symptoms of a complete interruption of power in an AZ and demonstrate how AWS would trigger zonal autoshift. This allows customers to tune their monitoring and recovery process to improve resiliency and application availability. The FIS AZ Availability: Power Interruption scenario now includes the expected recovery from zonal autoshift in addition to the power interruption symptoms, including loss of zonal compute (Amazon EC2, EKS, and ECS), RDS and ElastiCache failover, and more. Running the scenario lets customers test and build confidence that their application responds as intended when an AZ is unavailable. To get started, select the AZ Availability: Power Interruption scenario from the FIS scenario library. The action is available in all AWS Regions where FIS and zonal autoshift are available, including the AWS GovCloud (US) Regions. To learn more, visit the documentation.    

Today, we are excited to announce the general availability of Jihye – new Korean Neural Text-to-Speech (NTTS) female voice for Amazon Polly.

Amazon Polly is a fully-managed service that turns text into lifelike speech, allowing you to create applications that talk and to build entirely new categories of speech-enabled products.

Jihye is our new Korean voice that has a unique personality and style. We have trained it as a primarily conversational voice using carefully designed text and fully conversational speech recordings. Jihye can be adopted for a variety of speech products depending on the customer needs. It will perform at the highest quality in the interactive voice response (IVR) use cases, and will be most suitable for customer service, marketing, or education purposes.

Jihye and all the other NTTS voices are available in AWS regions supporting Neural TTS. For more details, please read the Amazon Polly documentation and visit our pricing page.

 

​Today, we are excited to announce the general availability of Jihye – new Korean Neural Text-to-Speech (NTTS) female voice for Amazon Polly. Amazon Polly is a fully-managed service that turns text into lifelike speech, allowing you to create applications that talk and to build entirely new categories of speech-enabled products. Jihye is our new Korean voice that has a unique personality and style. We have trained it as a primarily conversational voice using carefully designed text and fully conversational speech recordings. Jihye can be adopted for a variety of speech products depending on the customer needs. It will perform at the highest quality in the interactive voice response (IVR) use cases, and will be most suitable for customer service, marketing, or education purposes. Jihye and all the other NTTS voices are available in AWS regions supporting Neural TTS. For more details, please read the Amazon Polly documentation and visit our pricing page.  

We’re excited to introduce multi-head node support for Amazon SageMaker HyperPod clusters. This new capability enhances fault tolerance and availability for large scale generative AI model development workloads.

When a single head node manages job scheduling and resource allocation, it can become a critical bottleneck for customers running large scale AI workloads. When this node fails or becomes unresponsive, it can lead to job failures and downtime ultimately impacting the time to train.

With this launch, customers can now configure multiple head nodes within a single HyperPod Slurm cluster—one primary head (controller) node to control all compute (worker) nodes and manage Slurm operations, and additional backup head nodes in standby. If the primary head node fails, Slurm automatically transitions cluster operations to a backup node minimizing downtime and ensuring continuous workload availability. Additionally, customers can still manage their own accounting databases and Slurm configuration while ensuring workloads remain continuously available.

This capability is available in all regions where HyperPod is generally available. To learn more about the new multi-head node feature and set up your first HyperPod cluster with multiple head nodes, visit the Amazon SageMaker HyperPod documentation.

 

​We’re excited to introduce multi-head node support for Amazon SageMaker HyperPod clusters. This new capability enhances fault tolerance and availability for large scale generative AI model development workloads. When a single head node manages job scheduling and resource allocation, it can become a critical bottleneck for customers running large scale AI workloads. When this node fails or becomes unresponsive, it can lead to job failures and downtime ultimately impacting the time to train. With this launch, customers can now configure multiple head nodes within a single HyperPod Slurm cluster—one primary head (controller) node to control all compute (worker) nodes and manage Slurm operations, and additional backup head nodes in standby. If the primary head node fails, Slurm automatically transitions cluster operations to a backup node minimizing downtime and ensuring continuous workload availability. Additionally, customers can still manage their own accounting databases and Slurm configuration while ensuring workloads remain continuously available. This capability is available in all regions where HyperPod is generally available. To learn more about the new multi-head node feature and set up your first HyperPod cluster with multiple head nodes, visit the Amazon SageMaker HyperPod documentation.  

Amazon Route 53 Profiles introduces dual stack support for the Route 53 Profiles API endpoints, enabling you to connect using Internet Protocol Version 6 (IPv6), Internet Protocol Version 4 (IPv4), or dual stack clients. The existing Route 53 Profiles endpoints supporting IPv4 will remain available for backwards compatibility.

Route 53 Profiles makes it easy for you can create one or more configurations for VPC-related DNS settings, such as private hosted zones and Route 53 Resolver rules, and share them across VPCs and AWS accounts. The urgency to transition to Internet Protocol version 6 (IPv6) is driven by the continued growth of internet, which is exhausting available Internet Protocol version 4 (IPv4) addresses. With simultaneous support for both IPv4 and IPv6 clients on Route 53 Profiles endpoints, you are able to gradually transition from IPv4 to IPv6 based systems and applications, without needing to switch all over at once. This enables you to meet IPv6 compliance requirements and removes the need for expensive networking equipment to handle the address translation between IPv4 and IPv6.

Support for IPv6 on Route 53 Profiles is available in all AWS Commercial and AWS GovCloud (US) Regions where Route 53 Profiles is available. See here for a full listing of our Regions. You can get started with the feature through AWS CLI or AWS Management Console. To learn more about Route 53 Profiles, visit the Route 53 documentation. To learn more about pricing, you can visit the Route 53 pricing page.

 

​Amazon Route 53 Profiles introduces dual stack support for the Route 53 Profiles API endpoints, enabling you to connect using Internet Protocol Version 6 (IPv6), Internet Protocol Version 4 (IPv4), or dual stack clients. The existing Route 53 Profiles endpoints supporting IPv4 will remain available for backwards compatibility. Route 53 Profiles makes it easy for you can create one or more configurations for VPC-related DNS settings, such as private hosted zones and Route 53 Resolver rules, and share them across VPCs and AWS accounts. The urgency to transition to Internet Protocol version 6 (IPv6) is driven by the continued growth of internet, which is exhausting available Internet Protocol version 4 (IPv4) addresses. With simultaneous support for both IPv4 and IPv6 clients on Route 53 Profiles endpoints, you are able to gradually transition from IPv4 to IPv6 based systems and applications, without needing to switch all over at once. This enables you to meet IPv6 compliance requirements and removes the need for expensive networking equipment to handle the address translation between IPv4 and IPv6. Support for IPv6 on Route 53 Profiles is available in all AWS Commercial and AWS GovCloud (US) Regions where Route 53 Profiles is available. See here for a full listing of our Regions. You can get started with the feature through AWS CLI or AWS Management Console. To learn more about Route 53 Profiles, visit the Route 53 documentation. To learn more about pricing, you can visit the Route 53 pricing page.  

CloudWatch Database Insights announces support for customization of its metrics dashboard, allowing users to add or remove any database metric to the default dashboard provided. Database Insights is a database observability solution that provides a curated experience designed for DevOps engineers, application developers, and database administrators to expedite database troubleshooting and gain a holistic view into their database fleet health.

Database Insights consolidates logs and metrics from your applications, your databases, and the operating systems on which they run into a unified view in the console. Using its pre-built dashboards, recommended alarms, and automated telemetry collection, you can monitor the health of your database fleets and use a guided troubleshooting experience to drill down to individual instances for root-cause analysis. Now users can customize the Database Insights preset metrics dashboard by incorporating or removing metrics according to their preferences.

To customize the default metrics dashboard, navigate to the Database Instance Dashboard. From there, navigate to Database Telemetry and click on the Metrics tab. The new “Create widget” button that allows you to choose from a list of database, operating system, and CloudWatch metrics to add. You can also edit or remove existing metric widgets.

The ability to customize the metrics dashboard is now available for all Aurora and RDS database engines that Database Insights supports and in all regions where Database Insights is available, at no additional cost. For further information, visit the Database Insights documentation.
 

 

​CloudWatch Database Insights announces support for customization of its metrics dashboard, allowing users to add or remove any database metric to the default dashboard provided. Database Insights is a database observability solution that provides a curated experience designed for DevOps engineers, application developers, and database administrators to expedite database troubleshooting and gain a holistic view into their database fleet health. Database Insights consolidates logs and metrics from your applications, your databases, and the operating systems on which they run into a unified view in the console. Using its pre-built dashboards, recommended alarms, and automated telemetry collection, you can monitor the health of your database fleets and use a guided troubleshooting experience to drill down to individual instances for root-cause analysis. Now users can customize the Database Insights preset metrics dashboard by incorporating or removing metrics according to their preferences. To customize the default metrics dashboard, navigate to the Database Instance Dashboard. From there, navigate to Database Telemetry and click on the Metrics tab. The new “Create widget” button that allows you to choose from a list of database, operating system, and CloudWatch metrics to add. You can also edit or remove existing metric widgets. The ability to customize the metrics dashboard is now available for all Aurora and RDS database engines that Database Insights supports and in all regions where Database Insights is available, at no additional cost. For further information, visit the Database Insights documentation.    

Amazon CloudWatch RUM, which enables customers to monitor their web applications by collecting client side performance and error data in real time, is additionally available in the following AWS Regions starting today: Israel (Tel Aviv), and Asia Pacific (Hong Kong).

CloudWatch RUM provides curated dashboards for web application performance experienced by real end users including anomalies in page load steps, core web vitals, and JavaScript and Http errors across different geolocations, browsers, and devices. Custom events and metrics sent to CloudWatch RUM can be easily configured to monitor specific parts of the application for real user interactions, troubleshoot issues, and get alerted for anomalies. CloudWatch RUM comes integrated with the application performance monitoring (APM) capability, CloudWatch Application Signals. As a result, client-side data from your application can easily be correlated with performance metrics such as errors, faults, and latency observed in your APIs (service operations) and dependencies to address the root cause.

To get started, see the RUM User Guide. Usage of CloudWatch RUM is charged on the number of collected RUM events, which refers to each data item collected by the RUM web client, as detailed here.
 

 

​Amazon CloudWatch RUM, which enables customers to monitor their web applications by collecting client side performance and error data in real time, is additionally available in the following AWS Regions starting today: Israel (Tel Aviv), and Asia Pacific (Hong Kong). CloudWatch RUM provides curated dashboards for web application performance experienced by real end users including anomalies in page load steps, core web vitals, and JavaScript and Http errors across different geolocations, browsers, and devices. Custom events and metrics sent to CloudWatch RUM can be easily configured to monitor specific parts of the application for real user interactions, troubleshoot issues, and get alerted for anomalies. CloudWatch RUM comes integrated with the application performance monitoring (APM) capability, CloudWatch Application Signals. As a result, client-side data from your application can easily be correlated with performance metrics such as errors, faults, and latency observed in your APIs (service operations) and dependencies to address the root cause. To get started, see the RUM User Guide. Usage of CloudWatch RUM is charged on the number of collected RUM events, which refers to each data item collected by the RUM web client, as detailed here.    

Amazon Keyspaces (for Apache Cassandra) has expanded its Multi-Region Replication capabilities, now enabling you to replicate your tables beyond the previous quota of six AWS Regions to all available AWS Regions.

This enhancement to the existing multi-Region Replication provides even greater flexibility for organizations requiring broader global presence and data distribution. Customers can now automatically replicate their data across any number of AWS Regions supported within Amazon Keyspaces. With multi-Region replication, Amazon Keyspaces asynchronously replicates data between Regions, and data is typically propagated across Regions within a second.

The expanded regional support helps you to better serve your global user base, meet regional compliance requirements, and implement more robust disaster recovery strategies.

Getting started is easy through the AWS Management Console, AWS CLI, or AWS SDKs by selecting your desired destination AWS Regions. There are no upfront commitments; you only pay for the resources used in each Region.

To learn more about the enhanced Multi-Region Replication capabilities in Amazon Keyspaces, refer to the Multi-Region replication documentation. To get started with Amazon Keyspaces (for Apache Cassandra), please refer to the Amazon Keyspaces Developer Guide.

 

​Amazon Keyspaces (for Apache Cassandra) has expanded its Multi-Region Replication capabilities, now enabling you to replicate your tables beyond the previous quota of six AWS Regions to all available AWS Regions. This enhancement to the existing multi-Region Replication provides even greater flexibility for organizations requiring broader global presence and data distribution. Customers can now automatically replicate their data across any number of AWS Regions supported within Amazon Keyspaces. With multi-Region replication, Amazon Keyspaces asynchronously replicates data between Regions, and data is typically propagated across Regions within a second. The expanded regional support helps you to better serve your global user base, meet regional compliance requirements, and implement more robust disaster recovery strategies. Getting started is easy through the AWS Management Console, AWS CLI, or AWS SDKs by selecting your desired destination AWS Regions. There are no upfront commitments; you only pay for the resources used in each Region. To learn more about the enhanced Multi-Region Replication capabilities in Amazon Keyspaces, refer to the Multi-Region replication documentation. To get started with Amazon Keyspaces (for Apache Cassandra), please refer to the Amazon Keyspaces Developer Guide.  

Amazon Relational Database Service (Amazon RDS) for SQL Server now supports linked servers to Teradata databases. Linked server is a SQL Server feature that enables customers to read data and execute commands on remote database servers outside of the SQL Server instance. With this launch, customers can link their RDS for SQL Server instance to a Teradata database running on AWS or on premises.

To start setting up a linked server for Teradata, add the ODBC_TERADATA option to your RDS for SQL Server instance’s Option Group. Amazon RDS automatically installs and configures the Teradata ODBC driver, enabling you to run distributed queries, and execute SQL commands on your Teradata database from your RDS for SQL Server instance. Linked servers on RDS support distributed transactions through Microsoft Distributed Transaction Coordinator (MSDTC) and use TLS (Transport Layer Security) encryption for secure connections.

To learn more about setting up and using Teradata linked servers, refer to the Amazon RDS for SQL Server User Guide. This feature is available in all AWS Regions where Amazon RDS for SQL Server is available. See Amazon RDS for SQL Server Pricing for pricing details and regional availability.

 

​Amazon Relational Database Service (Amazon RDS) for SQL Server now supports linked servers to Teradata databases. Linked server is a SQL Server feature that enables customers to read data and execute commands on remote database servers outside of the SQL Server instance. With this launch, customers can link their RDS for SQL Server instance to a Teradata database running on AWS or on premises. To start setting up a linked server for Teradata, add the ODBC_TERADATA option to your RDS for SQL Server instance’s Option Group. Amazon RDS automatically installs and configures the Teradata ODBC driver, enabling you to run distributed queries, and execute SQL commands on your Teradata database from your RDS for SQL Server instance. Linked servers on RDS support distributed transactions through Microsoft Distributed Transaction Coordinator (MSDTC) and use TLS (Transport Layer Security) encryption for secure connections. To learn more about setting up and using Teradata linked servers, refer to the Amazon RDS for SQL Server User Guide. This feature is available in all AWS Regions where Amazon RDS for SQL Server is available. See Amazon RDS for SQL Server Pricing for pricing details and regional availability.