Today, Amazon Location Service announced new enhancements to its Places APIs that give developers greater control over address name formatting, multilingual address, travel-optimized POI search, and drive-through data. These capabilities span the Geocode, ReverseGeocode, GetPlace, Suggest, Autocomplete, SearchNearby, and SearchText APIs. Amazon Location Service is a mapping service that offers geospatial data and location functionality such as maps, places search and geocoding, route planning, device tracking, and geofencing.

Developers can now control how address component names are returned using the new AddressNamesMode parameter — choosing between matched (echoing input), normalized (canonical names), or administrative (government hierarchy names) — and override behavior per component with AddressNamesVariant. The new AddressTranslations parameter returns place name translations in 50+ languages, making it easier to build multilingual applications. A TravelMode parameter optimizes Suggest and SearchText results for users on the move, improving relevance for navigation and in-vehicle scenarios. Additionally, GetPlace, Suggest, SearchNearby, and SearchText now return a DriveThrough attribute indicating whether a place offers drive-through service — useful for logistics, food delivery, and navigation applications. The Geocode API also now supports a new Parsing.AdditionalInfo response field with additional detail about how the input address was interpreted.

Amazon Location Service is available in the following AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Spain), Europe (Stockholm), South America (São Paulo), and AWS GovCloud (US-West).

To get started, see the Amazon Location Service Places API reference, or learn more about Places in the Amazon Location Service Developer Guide.

 

​Today, Amazon Location Service announced new enhancements to its Places APIs that give developers greater control over address name formatting, multilingual address, travel-optimized POI search, and drive-through data. These capabilities span the Geocode, ReverseGeocode, GetPlace, Suggest, Autocomplete, SearchNearby, and SearchText APIs. Amazon Location Service is a mapping service that offers geospatial data and location functionality such as maps, places search and geocoding, route planning, device tracking, and geofencing. Developers can now control how address component names are returned using the new AddressNamesMode parameter — choosing between matched (echoing input), normalized (canonical names), or administrative (government hierarchy names) — and override behavior per component with AddressNamesVariant. The new AddressTranslations parameter returns place name translations in 50+ languages, making it easier to build multilingual applications. A TravelMode parameter optimizes Suggest and SearchText results for users on the move, improving relevance for navigation and in-vehicle scenarios. Additionally, GetPlace, Suggest, SearchNearby, and SearchText now return a DriveThrough attribute indicating whether a place offers drive-through service — useful for logistics, food delivery, and navigation applications. The Geocode API also now supports a new Parsing.AdditionalInfo response field with additional detail about how the input address was interpreted. Amazon Location Service is available in the following AWS Regions: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Sydney), Asia Pacific (Tokyo), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Spain), Europe (Stockholm), South America (São Paulo), and AWS GovCloud (US-West). To get started, see the Amazon Location Service Places API reference, or learn more about Places in the Amazon Location Service Developer Guide.  

AWS Database Migration Service (DMS) Schema Conversion now supports offline source conversion for Microsoft SQL Server, enabling you to convert SQL Server schemas and code without direct connectivity to your source databases. You extract metadata using standard database commands in your own environment, then upload it to DMS Schema Conversion for processing. This eliminates security reviews, firewall changes, and VPN setup that delay migration projects, while delivering the same conversion results as the connected approach.

Offline Source is ideal for organizations with security policies that restrict external tool access to production SQL Server databases. Database administrators generate human-readable metadata files within their existing environment, and security teams can review the commands and output before uploading, making approval straightforward. By removing the connectivity requirement, Offline Source transforms weeks of security reviews into a simple command-and-upload workflow.

Offline Source supports all DMS Schema Conversion targets at no additional conversion charge. For regional availability, see the Supported AWS Regions page. To get started, see Using Offline Source in the DMS Schema Conversion documentation.

 

​AWS Database Migration Service (DMS) Schema Conversion now supports offline source conversion for Microsoft SQL Server, enabling you to convert SQL Server schemas and code without direct connectivity to your source databases. You extract metadata using standard database commands in your own environment, then upload it to DMS Schema Conversion for processing. This eliminates security reviews, firewall changes, and VPN setup that delay migration projects, while delivering the same conversion results as the connected approach.
Offline Source is ideal for organizations with security policies that restrict external tool access to production SQL Server databases. Database administrators generate human-readable metadata files within their existing environment, and security teams can review the commands and output before uploading, making approval straightforward. By removing the connectivity requirement, Offline Source transforms weeks of security reviews into a simple command-and-upload workflow.
Offline Source supports all DMS Schema Conversion targets at no additional conversion charge. For regional availability, see the Supported AWS Regions page. To get started, see Using Offline Source in the DMS Schema Conversion documentation.  

Amazon DocumentDB (with MongoDB compatibility) now supports R8g.24xlarge and R8g.48xlarge database instances. R8g instances are powered by AWS Graviton4 processors and feature DDR5 memory, enabling customers to achieve higher throughput and support larger working sets in memory. With R8g.24xlarge (96 vCPUs, 768 GiB memory) and R8g.48xlarge (192 vCPUs, 1,536 GiB memory), customers can run more demanding workloads such as high-concurrency transactional applications, large-scale document processing, and memory-intensive operational workloads.

Customers can get started with R8g.24xlarge and R8g.48xlarge instances through the AWS Management Console, CLI, and SDK by modifying their existing Amazon DocumentDB database cluster or creating a new one. R8g instances are available for Amazon DocumentDB 5.0+ on both Standard and IO-Optimized cluster storage configurations. For more information including region availability, visit our pricing page and documentation.

 

​Amazon DocumentDB (with MongoDB compatibility) now supports R8g.24xlarge and R8g.48xlarge database instances. R8g instances are powered by AWS Graviton4 processors and feature DDR5 memory, enabling customers to achieve higher throughput and support larger working sets in memory. With R8g.24xlarge (96 vCPUs, 768 GiB memory) and R8g.48xlarge (192 vCPUs, 1,536 GiB memory), customers can run more demanding workloads such as high-concurrency transactional applications, large-scale document processing, and memory-intensive operational workloads. Customers can get started with R8g.24xlarge and R8g.48xlarge instances through the AWS Management Console, CLI, and SDK by modifying their existing Amazon DocumentDB database cluster or creating a new one. R8g instances are available for Amazon DocumentDB 5.0+ on both Standard and IO-Optimized cluster storage configurations. For more information including region availability, visit our pricing page and documentation.  

AWS Database Migration Service (DMS) Schema Conversion now supports AI agent automation through the AWS MCP Server. You can connect AI coding agents, including Kiro, Claude Code, and Cursor, to DMS Schema Conversion and run complete migration workflows using natural language directly from your IDE. Agents create projects, browse source metadata, convert schemas, generate assessment reports, and export results autonomously.

The DMS Schema Conversion skill, dms-schema-conversion, loads on demand and provides agents with predefined procedures, including API patterns, schema exclusions, and operational sequencing rules. Agents follow these procedures rather than improvising from general knowledge, reducing trial-and-error loops. They can also help convert remaining code objects such as stored procedures, functions, and triggers, building on the generative AI capabilities launched at re:Invent 2024.

AI agent automation is available for all existing DMS Schema Conversion source and target engine pairs at no additional charge. For regional availability, see the Supported AWS Regions page. To get started, see Using AI agents with DMS Schema Conversion in the documentation.

 

​AWS Database Migration Service (DMS) Schema Conversion now supports AI agent automation through the AWS MCP Server. You can connect AI coding agents, including Kiro, Claude Code, and Cursor, to DMS Schema Conversion and run complete migration workflows using natural language directly from your IDE. Agents create projects, browse source metadata, convert schemas, generate assessment reports, and export results autonomously.
The DMS Schema Conversion skill, dms-schema-conversion, loads on demand and provides agents with predefined procedures, including API patterns, schema exclusions, and operational sequencing rules. Agents follow these procedures rather than improvising from general knowledge, reducing trial-and-error loops. They can also help convert remaining code objects such as stored procedures, functions, and triggers, building on the generative AI capabilities launched at re:Invent 2024.
AI agent automation is available for all existing DMS Schema Conversion source and target engine pairs at no additional charge. For regional availability, see the Supported AWS Regions page. To get started, see Using AI agents with DMS Schema Conversion in the documentation.  

You can now connect AI agents directly to the AWS MCP Server using AWS Sign-In. Agents connect using industry-standard OAuth without requiring additional authentication software. Existing AWS identities, sign-in methods, IAM permissions, and governance controls you have already set up continue to apply.

Developers can authorize agents interactively through a browser or programmatically using non-interactive (headless) authorization. Administrators can govern OAuth access using familiar IAM policies together with new OAuth capabilities, including global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events.

To learn more, see the OAuth Support for the AWS MCP Server blogpost, Sign-In with OAuth 2.0 in the AWS Sign-In User Guide, and Setting up the AWS MCP Server in the Agent Toolkit for AWS User Guide.

 

​You can now connect AI agents directly to the AWS MCP Server using AWS Sign-In. Agents connect using industry-standard OAuth without requiring additional authentication software. Existing AWS identities, sign-in methods, IAM permissions, and governance controls you have already set up continue to apply.
Developers can authorize agents interactively through a browser or programmatically using non-interactive (headless) authorization. Administrators can govern OAuth access using familiar IAM policies together with new OAuth capabilities, including global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events.
To learn more, see the OAuth Support for the AWS MCP Server blogpost, Sign-In with OAuth 2.0 in the AWS Sign-In User Guide, and Setting up the AWS MCP Server in the Agent Toolkit for AWS User Guide.  

Amazon Timestream for InfluxDB now publishes events to Amazon EventBridge when your database instances or clusters undergo state changes. Events are emitted for lifecycle operations including creation, deletion, compute and storage scaling, parameter group updates, maintenance windows, and reboot — covering both successful completions and failures.

With this capability, customers can use Amazon EventBridge rules to programmatically react to database operations without polling the API for status. DevOps teams can build automation workflows that trigger when a scaling operation completes, operations teams can route failure events for immediate alerting, and compliance teams can persist all events to Amazon CloudWatch Logs or Amazon S3 for audit trails. Events are published to the default Amazon EventBridge event bus in your account with source aws.timestream-influxdb, supporting content-based filtering and routing to any EventBridge target including AWS Lambda functions, AWS Step Functions, Amazon SQS queues, Amazon SNS topics, and cross-account event buses.

This capability is available in all AWS Regions where Amazon Timestream for InfluxDB is available. Standard Amazon EventBridge pricing applies for rule evaluation and target delivery. To get started, open the Amazon EventBridge console and create a rule with source aws.timestream-influxdb. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.

 

​Amazon Timestream for InfluxDB now publishes events to Amazon EventBridge when your database instances or clusters undergo state changes. Events are emitted for lifecycle operations including creation, deletion, compute and storage scaling, parameter group updates, maintenance windows, and reboot — covering both successful completions and failures. With this capability, customers can use Amazon EventBridge rules to programmatically react to database operations without polling the API for status. DevOps teams can build automation workflows that trigger when a scaling operation completes, operations teams can route failure events for immediate alerting, and compliance teams can persist all events to Amazon CloudWatch Logs or Amazon S3 for audit trails. Events are published to the default Amazon EventBridge event bus in your account with source aws.timestream-influxdb, supporting content-based filtering and routing to any EventBridge target including AWS Lambda functions, AWS Step Functions, Amazon SQS queues, Amazon SNS topics, and cross-account event buses. This capability is available in all AWS Regions where Amazon Timestream for InfluxDB is available. Standard Amazon EventBridge pricing applies for rule evaluation and target delivery. To get started, open the Amazon EventBridge console and create a rule with source aws.timestream-influxdb. For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.  

Amazon SageMaker HyperPod now supports deep health checks for Slurm-orchestrated clusters created with continuous provisioning, enabling you to proactively verify GPU accelerator health on running instances at any time. Continuous provisioning lets you start training quickly and scale instance groups asynchronously without all-or-nothing failures, and you can now pair that flexibility with comprehensive hardware validation as instances come online. This capability addresses a critical challenge where even a single unhealthy node can waste hours of compute time and delay critical workloads.

With deep health checks, you can target entire instance groups or specific instances to run comprehensive hardware stress tests and connectivity tests before committing compute resources to a job. Because continuous provisioning adds worker nodes to your Slurm cluster asynchronously as capacity becomes available, you can run deep health checks on each new node as it comes online, validating hardware before scheduling jobs on it and without interrupting workloads already running on healthy nodes. Progress and results are visible at both the instance group and instance level through the SageMaker console and APIs, providing complete visibility into GPU health, network connectivity, and multi-node communication performance. Instances undergoing checks are automatically isolated from workload scheduling and returned to service upon passing. When paired with HyperPod’s automatic node recovery capability, instances that fail are automatically rebooted or replaced, ensuring cluster health.

This capability is available in all regions where Amazon SageMaker HyperPod is available. To learn more about on-demand deep health checks and continuous provisioning, see the Amazon SageMaker HyperPod User Guide.

 

​Amazon SageMaker HyperPod now supports deep health checks for Slurm-orchestrated clusters created with continuous provisioning, enabling you to proactively verify GPU accelerator health on running instances at any time. Continuous provisioning lets you start training quickly and scale instance groups asynchronously without all-or-nothing failures, and you can now pair that flexibility with comprehensive hardware validation as instances come online. This capability addresses a critical challenge where even a single unhealthy node can waste hours of compute time and delay critical workloads. With deep health checks, you can target entire instance groups or specific instances to run comprehensive hardware stress tests and connectivity tests before committing compute resources to a job. Because continuous provisioning adds worker nodes to your Slurm cluster asynchronously as capacity becomes available, you can run deep health checks on each new node as it comes online, validating hardware before scheduling jobs on it and without interrupting workloads already running on healthy nodes. Progress and results are visible at both the instance group and instance level through the SageMaker console and APIs, providing complete visibility into GPU health, network connectivity, and multi-node communication performance. Instances undergoing checks are automatically isolated from workload scheduling and returned to service upon passing. When paired with HyperPod’s automatic node recovery capability, instances that fail are automatically rebooted or replaced, ensuring cluster health. This capability is available in all regions where Amazon SageMaker HyperPod is available. To learn more about on-demand deep health checks and continuous provisioning, see the Amazon SageMaker HyperPod User Guide.  

Amazon SageMaker Feature Store is a fully managed capability that makes it easy to compute, store, and retrieve features for training and deploying AI models. SageMaker Feature Store now supports new capabilities for high-throughput feature ingestion, record discovery, and offline store cataloging. Data scientists can now write multiple records across multiple feature groups in a single request with BatchWriteRecord, list the records stored in a feature group without knowing each record identifier in advance with ListRecords, and create tables and databases with custom names in the offline store.

Data scientists can use BatchWriteRecord to ingest feature data at scale with fewer API calls and lower latency than writing one record at a time. BatchWriteRecord targets the online store, the offline store, or both, returns individual record failures without failing the entire request, and supports time-to-live settings at the record, request, and feature group level. With ListRecords, data scientists can retrieve the record identifiers in a feature group, one page at a time, to browse and audit feature group contents, recover record identifiers, and manage the record lifecycle. When configuring an offline store, data scientists can also create Glue and Iceberg tables with custom names. These capabilities enable data scientists to ingest features at scale and manage the records stored in SageMaker Feature Store without building custom tooling.

These capabilities are available in all AWS Regions where Amazon SageMaker Feature Store is available. For more information, see Amazon Feature Store Runtime and Offline Store Configuration documentation.

 

​Amazon SageMaker Feature Store is a fully managed capability that makes it easy to compute, store, and retrieve features for training and deploying AI models. SageMaker Feature Store now supports new capabilities for high-throughput feature ingestion, record discovery, and offline store cataloging. Data scientists can now write multiple records across multiple feature groups in a single request with BatchWriteRecord, list the records stored in a feature group without knowing each record identifier in advance with ListRecords, and create tables and databases with custom names in the offline store. Data scientists can use BatchWriteRecord to ingest feature data at scale with fewer API calls and lower latency than writing one record at a time. BatchWriteRecord targets the online store, the offline store, or both, returns individual record failures without failing the entire request, and supports time-to-live settings at the record, request, and feature group level. With ListRecords, data scientists can retrieve the record identifiers in a feature group, one page at a time, to browse and audit feature group contents, recover record identifiers, and manage the record lifecycle. When configuring an offline store, data scientists can also create Glue and Iceberg tables with custom names. These capabilities enable data scientists to ingest features at scale and manage the records stored in SageMaker Feature Store without building custom tooling.
These capabilities are available in all AWS Regions where Amazon SageMaker Feature Store is available. For more information, see Amazon Feature Store Runtime and Offline Store Configuration documentation.  

Amazon SageMaker Unified Studio now supports custom asset types for IAM-based domains. With custom asset types, domain administrators can catalog any format of asset within the SageMaker Unified Studio, such as medical imaging files in Amazon S3, revenue dashboards built in PowerBI, or PDF research reports generated by a third-party platform. Custom asset types bring all assets, regardless of their underlying format, into the SageMaker catalog so teams can search, discover, and subscribe to them without needing separate tools or processes.

To get started, an administrator can create a custom asset type with a name, description, and optional metadata forms that define the fields each asset should carry. Individual assets can then be created from that type, enriched with glossary terms and README documentation to add business context for humans and AI agents, and published for discovery. Once published, anyone in the domain can find the asset by name, type, or glossary term and request a subscription through the same governed workflow used for all other catalog assets.

Custom asset types for IAM-based domains are available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the SageMaker Unified Studio user guide. 

 

​Amazon SageMaker Unified Studio now supports custom asset types for IAM-based domains. With custom asset types, domain administrators can catalog any format of asset within the SageMaker Unified Studio, such as medical imaging files in Amazon S3, revenue dashboards built in PowerBI, or PDF research reports generated by a third-party platform. Custom asset types bring all assets, regardless of their underlying format, into the SageMaker catalog so teams can search, discover, and subscribe to them without needing separate tools or processes.
To get started, an administrator can create a custom asset type with a name, description, and optional metadata forms that define the fields each asset should carry. Individual assets can then be created from that type, enriched with glossary terms and README documentation to add business context for humans and AI agents, and published for discovery. Once published, anyone in the domain can find the asset by name, type, or glossary term and request a subscription through the same governed workflow used for all other catalog assets.
Custom asset types for IAM-based domains are available in all AWS Regions where Amazon SageMaker Unified Studio is available. To learn more, visit the SageMaker Unified Studio user guide.   

Amazon SageMaker Unified Studio Workflows now supports 19 new operators for Amazon Bedrock, Amazon S3 Tables, Amazon S3 Vectors, AWS Glue Data Catalog, and Amazon MWAA Serverless. With these operators, customers can add new tasks using the visual workflow creator to orchestrate these services without writing custom integration code.
With this launch, data workers and builders can create workflows that manage Bedrock guardrails, provision and delete S3 Tables and S3 Vectors resources, manage Glue Data Catalog tables and databases, and trigger MWAA Serverless workflow runs. This expands the breadth of AWS services you can orchestrate from SageMaker Unified Studio Workflows, reducing the need to switch between consoles or write custom DAG code.
This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. For more information, see the AWS Region table.
To learn more, see Supported operators for Amazon MWAA Serverless workflows. To get started, see Serverless visual workflows in the Amazon SageMaker Unified Studio User Guide.

 

​Amazon SageMaker Unified Studio Workflows now supports 19 new operators for Amazon Bedrock, Amazon S3 Tables, Amazon S3 Vectors, AWS Glue Data Catalog, and Amazon MWAA Serverless. With these operators, customers can add new tasks using the visual workflow creator to orchestrate these services without writing custom integration code. With this launch, data workers and builders can create workflows that manage Bedrock guardrails, provision and delete S3 Tables and S3 Vectors resources, manage Glue Data Catalog tables and databases, and trigger MWAA Serverless workflow runs. This expands the breadth of AWS services you can orchestrate from SageMaker Unified Studio Workflows, reducing the need to switch between consoles or write custom DAG code. This feature is available in all AWS Regions where Amazon SageMaker Unified Studio is available. For more information, see the AWS Region table. To learn more, see Supported operators for Amazon MWAA Serverless workflows. To get started, see Serverless visual workflows in the Amazon SageMaker Unified Studio User Guide.