You can now attach Amazon Simple Storage Service (Amazon S3) Access Points to your Amazon FSx for OpenZFS file systems so that you can access your file data as if it were in S3. With this new capability, your file data in FSx for OpenZFS is accessible for use with the broad range of artificial intelligence, machine learning, and analytics services and applications that work with S3 while your file data continues to reside on the FSx for OpenZFS file system.

An S3 Access Point is an endpoint that helps control and simplify how different applications or users can access data. S3 Access Points now work with FSx for OpenZFS so that applications and services can access file data in FSx for OpenZFS using the S3 API and as if the data were in S3. You can discover new insights, innovate faster, and make even better data-driven decisions with your data in FSx for OpenZFS. For example, you can use your file data to augment generative AI applications with Amazon Bedrock, train machine learning models with Amazon SageMaker, run analyses using Amazon Glue, a wide range of AWS Data and Analytics Competency Partner solutions, and S3-based cloud-native applications.

Get started with this capability by creating and attaching S3 Access Points to your FSx for OpenZFS file systems using the Amazon FSx console, the AWS Command Line Interface (AWS CLI), or the AWS Software Development Kit (AWS SDK) in the following AWS Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, Stockholm), and Asia Pacific (Hong Kong, Singapore, Sydney, Tokyo). To learn more, visit the product page, user guide, and AWS News Blog. 

 

​You can now attach Amazon Simple Storage Service (Amazon S3) Access Points to your Amazon FSx for OpenZFS file systems so that you can access your file data as if it were in S3. With this new capability, your file data in FSx for OpenZFS is accessible for use with the broad range of artificial intelligence, machine learning, and analytics services and applications that work with S3 while your file data continues to reside on the FSx for OpenZFS file system.
An S3 Access Point is an endpoint that helps control and simplify how different applications or users can access data. S3 Access Points now work with FSx for OpenZFS so that applications and services can access file data in FSx for OpenZFS using the S3 API and as if the data were in S3. You can discover new insights, innovate faster, and make even better data-driven decisions with your data in FSx for OpenZFS. For example, you can use your file data to augment generative AI applications with Amazon Bedrock, train machine learning models with Amazon SageMaker, run analyses using Amazon Glue, a wide range of AWS Data and Analytics Competency Partner solutions, and S3-based cloud-native applications.
Get started with this capability by creating and attaching S3 Access Points to your FSx for OpenZFS file systems using the Amazon FSx console, the AWS Command Line Interface (AWS CLI), or the AWS Software Development Kit (AWS SDK) in the following AWS Regions: US East (N. Virginia, Ohio), US West (Oregon), Europe (Frankfurt, Ireland, Stockholm), and Asia Pacific (Hong Kong, Singapore, Sydney, Tokyo). To learn more, visit the product page, user guide, and AWS News Blog.   

Amazon Bedrock Flows enables you to link foundation models (FMs), Amazon Bedrock Prompts, Amazon Bedrock Agents, Amazon Bedrock Knowledge Bases, Amazon Bedrock Guardrails and other AWS services together to build and scale pre-defined generative AI workflows. Today, we announce the preview of persistent execution for long running workflows, and inline-code execution support within the flows.

Bedrock Flows customers currently encounter three key limitations when authoring, executing and monitoring workflows: a two-minute idle timeout restriction per step, the need for custom API-based monitoring solutions, and the requirement to create Lambda functions for basic data processing tasks. Starting today, we’re addressing these challenges with new preview features that extend workflow step execution times to 15 minutes. The new capabilities include built-in execution tracking directly in the AWS Management Console, eliminating the need for custom monitoring code. You can now execute Python scripts using the new inline-code node type, removing the overhead of setting up Lambda functions for simple data processing. These enhancements significantly streamline workflow development and management in Amazon Bedrock Flows, helping you focus on building your generative AI applications.

Long-running Flows executions are now available in all supported commercial regions where Flows operates. The inline code node is available in US East (N. Virginia), US West (Oregon), and Europe (Frankfurt). To get started, see the AWS user guide.

 

​Amazon Bedrock Flows enables you to link foundation models (FMs), Amazon Bedrock Prompts, Amazon Bedrock Agents, Amazon Bedrock Knowledge Bases, Amazon Bedrock Guardrails and other AWS services together to build and scale pre-defined generative AI workflows. Today, we announce the preview of persistent execution for long running workflows, and inline-code execution support within the flows. Bedrock Flows customers currently encounter three key limitations when authoring, executing and monitoring workflows: a two-minute idle timeout restriction per step, the need for custom API-based monitoring solutions, and the requirement to create Lambda functions for basic data processing tasks. Starting today, we’re addressing these challenges with new preview features that extend workflow step execution times to 15 minutes. The new capabilities include built-in execution tracking directly in the AWS Management Console, eliminating the need for custom monitoring code. You can now execute Python scripts using the new inline-code node type, removing the overhead of setting up Lambda functions for simple data processing. These enhancements significantly streamline workflow development and management in Amazon Bedrock Flows, helping you focus on building your generative AI applications.
Long-running Flows executions are now available in all supported commercial regions where Flows operates. The inline code node is available in US East (N. Virginia), US West (Oregon), and Europe (Frankfurt). To get started, see the AWS user guide.  

AWS Glue now supports read and write operations from AWS Glue 5.0 Apache Spark jobs on AWS Lake Formation registered tables when the job role has full table access. This capability enables Data Manipulation Language (DML) operations including CREATE, ALTER, DELETE, UPDATE, and MERGE INTO statements on Apache Hive and Iceberg tables from within the same Apache Spark application.

While Lake Formation’s fine-grained access control (FGAC) offers granular security controls at row, column, and cell levels, many ETL workloads simply need full table access. This new feature enables AWS Glue 5.0 Spark jobs to directly read and write data when full table access is granted, removing limitations that previously restricted certain Extract, Transform, and Load (ETL) operations. You can now leverage advanced Spark capabilities including Resilient Distributed Datasets (RDDs), custom libraries, and User Defined Functions (UDFs) with Lake Formation tables. Additionally, data teams can run complex, interactive Spark applications through SageMaker Unified Studio in compatibility mode while maintaining Lake Formation’s table-level security boundaries.

This feature is available in all AWS Regions where AWS Glue and AWS Lake Formation are supported. To learn more, visit the AWS Glue product page and documentation.

 

​AWS Glue now supports read and write operations from AWS Glue 5.0 Apache Spark jobs on AWS Lake Formation registered tables when the job role has full table access. This capability enables Data Manipulation Language (DML) operations including CREATE, ALTER, DELETE, UPDATE, and MERGE INTO statements on Apache Hive and Iceberg tables from within the same Apache Spark application. While Lake Formation’s fine-grained access control (FGAC) offers granular security controls at row, column, and cell levels, many ETL workloads simply need full table access. This new feature enables AWS Glue 5.0 Spark jobs to directly read and write data when full table access is granted, removing limitations that previously restricted certain Extract, Transform, and Load (ETL) operations. You can now leverage advanced Spark capabilities including Resilient Distributed Datasets (RDDs), custom libraries, and User Defined Functions (UDFs) with Lake Formation tables. Additionally, data teams can run complex, interactive Spark applications through SageMaker Unified Studio in compatibility mode while maintaining Lake Formation’s table-level security boundaries. This feature is available in all AWS Regions where AWS Glue and AWS Lake Formation are supported. To learn more, visit the AWS Glue product page and documentation.  

Amazon GameLift Servers, a fully managed service for deploying, operating, and scaling game servers for multiplayer games, is now available in two additional AWS Regions: Asia Pacific (Thailand) and Asia Pacific (Malaysia). With this launch, customers can now deploy GameLift fleets closer to players in Thailand and Malaysia, helping reduce latency and improve gameplay responsiveness.

This regional expansion supports both Amazon GameLift Servers managed EC2 and container-based hosting options. Developers can take advantage of features such as FlexMatch for customizable matchmaking, FleetIQ for cost-optimized instance management, and auto-scaling to manage player demand dynamically. The addition of these new regions enables game developers and publishers to better server growing player communities across Southeast Asia while maintaining high performance and reliability.

To get started, visit the Amazon GameLift console or refer to the Amazon GameLift Servers developer guide.

 

​Amazon GameLift Servers, a fully managed service for deploying, operating, and scaling game servers for multiplayer games, is now available in two additional AWS Regions: Asia Pacific (Thailand) and Asia Pacific (Malaysia). With this launch, customers can now deploy GameLift fleets closer to players in Thailand and Malaysia, helping reduce latency and improve gameplay responsiveness. This regional expansion supports both Amazon GameLift Servers managed EC2 and container-based hosting options. Developers can take advantage of features such as FlexMatch for customizable matchmaking, FleetIQ for cost-optimized instance management, and auto-scaling to manage player demand dynamically. The addition of these new regions enables game developers and publishers to better server growing player communities across Southeast Asia while maintaining high performance and reliability. To get started, visit the Amazon GameLift console or refer to the Amazon GameLift Servers developer guide.  

Starting today, domain name system (DNS) delegation for private hosted zone subdomains can be used with Route 53 inbound and outbound Resolver endpoints. This allows you to delegate the authority for a subdomain from your on-premises infrastructure to the Route 53 Resolver cloud service and vice versa, enabling a simplified cloud experience across namespaces in AWS and on your own local infrastructure.

AWS customers allow multiple organizations within their enterprise to individually manage their respective subdomains and subzones, whereas apex domains and parent hosted zones are typically overseen by a central team. Previously, these customers had to create and maintain conditional forwarding rules in their existing network infrastructure to enable services to discover one another across subdomains. However, conditional forwarding rules are difficult to maintain across large organizations and, in many cases, are not supported by on-premises infrastructure. With today’s release, customers can instead delegate authority of subdomains to Route 53 using name server records and vice versa, achieving compatibility with common, on-premises DNS infrastructure and removing the need for teams to use conditional forwarding rules throughout their organization.

Inbound and outbound delegation for Resolver endpoints is available globally in all AWS Regions, where Resolver endpoints are available, except in AWS GovCloud and Amazon Web Services in China. Inbound and outbound delegation is provided at no additional cost to Resolver endpoints usage. For more details on pricing, visit the Route 53 pricing page, and to learn more about this feature, visit the developer guide.
 

 

​Starting today, domain name system (DNS) delegation for private hosted zone subdomains can be used with Route 53 inbound and outbound Resolver endpoints. This allows you to delegate the authority for a subdomain from your on-premises infrastructure to the Route 53 Resolver cloud service and vice versa, enabling a simplified cloud experience across namespaces in AWS and on your own local infrastructure. AWS customers allow multiple organizations within their enterprise to individually manage their respective subdomains and subzones, whereas apex domains and parent hosted zones are typically overseen by a central team. Previously, these customers had to create and maintain conditional forwarding rules in their existing network infrastructure to enable services to discover one another across subdomains. However, conditional forwarding rules are difficult to maintain across large organizations and, in many cases, are not supported by on-premises infrastructure. With today’s release, customers can instead delegate authority of subdomains to Route 53 using name server records and vice versa, achieving compatibility with common, on-premises DNS infrastructure and removing the need for teams to use conditional forwarding rules throughout their organization. Inbound and outbound delegation for Resolver endpoints is available globally in all AWS Regions, where Resolver endpoints are available, except in AWS GovCloud and Amazon Web Services in China. Inbound and outbound delegation is provided at no additional cost to Resolver endpoints usage. For more details on pricing, visit the Route 53 pricing page, and to learn more about this feature, visit the developer guide.    

Today, Amazon EMR on EKS announces support for Service Quotas, improving visibility and control over EMR on EKS quotas.

Previously, to request an increase for EMR on EKS quotas, such as maximum number of StartJobRun API calls per second, customers had to open a support ticket and wait for the support team to process the increase. Now, customers can view and manage their EMR on EKS quota limits directly in the Service Quotas console. This enables automated limit increase approvals for eligible requests, improving response times and reducing the number of support tickets. Customers can also set up Amazon CloudWatch alarms to get automatically notified when their usage reaches a certain percentage of a maximum quota.

Amazon EMR on EKS support for Service Quotas is available in all Regions where Amazon EMR on EKS is currently available. To get started, visit the Service Quotas User Guide.

 

​Today, Amazon EMR on EKS announces support for Service Quotas, improving visibility and control over EMR on EKS quotas. Previously, to request an increase for EMR on EKS quotas, such as maximum number of StartJobRun API calls per second, customers had to open a support ticket and wait for the support team to process the increase. Now, customers can view and manage their EMR on EKS quota limits directly in the Service Quotas console. This enables automated limit increase approvals for eligible requests, improving response times and reducing the number of support tickets. Customers can also set up Amazon CloudWatch alarms to get automatically notified when their usage reaches a certain percentage of a maximum quota. Amazon EMR on EKS support for Service Quotas is available in all Regions where Amazon EMR on EKS is currently available. To get started, visit the Service Quotas User Guide.  

Today, Amazon SageMaker HyperPod announces the general availability of Amazon EC2 P6-B200 instances powered by NVIDIA B200 GPUs. Amazon EC2 P6-B200 instances offer up to 2x performance compared to P5en instances for AI training.

P6-B200 instances feature 8 Blackwell GPUs with 1440 GB of high-bandwidth GPU memory and a 60% increase in GPU memory bandwidth compared to P5en, 5th Generation Intel Xeon processors (Emerald Rapids), and up to 3.2 terabits per second of Elastic Fabric Adapter (EFAv4) networking. P6-B200 instances are powered by the AWS Nitro System, so you can reliably and securely scale AI workloads within Amazon EC2 UltraClusters to tens of thousands of GPUs.

The instances are available through SageMaker HyperPod flexible training plans in US West (Oregon) AWS Region. For on-demand reservation of B200 instances, please reach out to your account manager.

Amazon SageMaker AI lets you easily train machine learning models at scale using fully managed infrastructure optimized for performance and cost. To get started with SageMaker HyperPod, visit the webpage and documentation.
 

 

​Today, Amazon SageMaker HyperPod announces the general availability of Amazon EC2 P6-B200 instances powered by NVIDIA B200 GPUs. Amazon EC2 P6-B200 instances offer up to 2x performance compared to P5en instances for AI training. P6-B200 instances feature 8 Blackwell GPUs with 1440 GB of high-bandwidth GPU memory and a 60% increase in GPU memory bandwidth compared to P5en, 5th Generation Intel Xeon processors (Emerald Rapids), and up to 3.2 terabits per second of Elastic Fabric Adapter (EFAv4) networking. P6-B200 instances are powered by the AWS Nitro System, so you can reliably and securely scale AI workloads within Amazon EC2 UltraClusters to tens of thousands of GPUs. The instances are available through SageMaker HyperPod flexible training plans in US West (Oregon) AWS Region. For on-demand reservation of B200 instances, please reach out to your account manager. Amazon SageMaker AI lets you easily train machine learning models at scale using fully managed infrastructure optimized for performance and cost. To get started with SageMaker HyperPod, visit the webpage and documentation.    

We’re excited to announce the general availability of UDP ping beacons for Amazon GameLift Servers, a new feature that enables game developers to measure real-time network latency between game clients and game servers hosted on Amazon GameLift Servers. With UDP ping beacons, you can now accurately measure latency for UDP (User Datagram Protocol) packet payloads across all AWS Regions and Local Zones where Amazon GameLift Servers is available.

Most multiplayer games use UDP as their primary packet transmission protocol due to its performance benefits for real-time gaming and optimizing network latency is crucial for delivering the best possible player experience. UDP ping beacons provide a reliable way to measure actual UDP packet latency between players and game servers, helping make better decisions about player-to-server matching and game session placement.

The beacon endpoints are available in all AWS Global Regions and Local Zones supported by Amazon GameLift Servers, except AWS China, and through the ListLocations API, making it easy to programmatically access the endpoints.

To learn more, visit the Amazon GameLift Servers Release Notes.
 

 

​We’re excited to announce the general availability of UDP ping beacons for Amazon GameLift Servers, a new feature that enables game developers to measure real-time network latency between game clients and game servers hosted on Amazon GameLift Servers. With UDP ping beacons, you can now accurately measure latency for UDP (User Datagram Protocol) packet payloads across all AWS Regions and Local Zones where Amazon GameLift Servers is available. Most multiplayer games use UDP as their primary packet transmission protocol due to its performance benefits for real-time gaming and optimizing network latency is crucial for delivering the best possible player experience. UDP ping beacons provide a reliable way to measure actual UDP packet latency between players and game servers, helping make better decisions about player-to-server matching and game session placement. The beacon endpoints are available in all AWS Global Regions and Local Zones supported by Amazon GameLift Servers, except AWS China, and through the ListLocations API, making it easy to programmatically access the endpoints. To learn more, visit the Amazon GameLift Servers Release Notes.    

Amazon S3 now supports sort and z-order compaction for Apache Iceberg tables, available both in Amazon S3 Tables and general purpose S3 buckets using AWS Glue Data Catalog optimization. Sort compaction in Iceberg tables minimizes the number of data files scanned by query engines, leading to improved query performance and reduced costs. Z-order compaction provides additional performance benefits through efficient file pruning when querying across multiple columns simultaneously.

S3 Tables provide a fully managed experience where hierarchical sorting is automatically applied on columns during compaction when a sort order is defined in table metadata. When multiple query predicates need to be prioritized equally, you can enable z-order compaction through the S3 Tables maintenance API. If you are using Iceberg tables in general purpose S3 buckets, optimization can be enabled in the AWS Glue Data Catalog console, where you can specify your preferred compaction method.

These additional compaction capabilities are available in all AWS Regions where S3 Tables or optimization with the AWS Glue Data Catalog are available. To learn more, read the AWS News Blog, and visit the S3 Tables maintenance documentation and AWS Glue Data Catalog optimization documentation.
 

 

​Amazon S3 now supports sort and z-order compaction for Apache Iceberg tables, available both in Amazon S3 Tables and general purpose S3 buckets using AWS Glue Data Catalog optimization. Sort compaction in Iceberg tables minimizes the number of data files scanned by query engines, leading to improved query performance and reduced costs. Z-order compaction provides additional performance benefits through efficient file pruning when querying across multiple columns simultaneously. S3 Tables provide a fully managed experience where hierarchical sorting is automatically applied on columns during compaction when a sort order is defined in table metadata. When multiple query predicates need to be prioritized equally, you can enable z-order compaction through the S3 Tables maintenance API. If you are using Iceberg tables in general purpose S3 buckets, optimization can be enabled in the AWS Glue Data Catalog console, where you can specify your preferred compaction method. These additional compaction capabilities are available in all AWS Regions where S3 Tables or optimization with the AWS Glue Data Catalog are available. To learn more, read the AWS News Blog, and visit the S3 Tables maintenance documentation and AWS Glue Data Catalog optimization documentation.    

The Customer Carbon Footprint Tool (CCFT) and Data Exports now show emissions calculated using the location-based method (LBM), alongside emissions calculated using the market-based method (MBM) which were already present. In addition, you can now see the estimated emissions from CloudFront usage in the service breakdown, alongside EC2 and S3 estimates.

LBM reflects the average emissions intensity of grids on which energy consumption occurs. Electricity grids in different parts of the world use various sources of power, from carbon-intense fuels like coal, to renewable energy like solar. With LBM, you can view and validate trends in monthly carbon emissions that more directly align to your cloud usage, and get insights into the carbon intensity of the underlying electricity grids in which AWS data centers operate. This empowers you to make more informed decisions about optimizing your cloud usage and achieving your overall sustainability objectives. To learn more about the differences between LBM and MBM see the GHG Protocol Scope 2 Guidance.

Check out your LBM emissions today in the Customer Carbon Footprint Tool and Data Exports; the updates are explained in detail in the user guide.
 

 

​The Customer Carbon Footprint Tool (CCFT) and Data Exports now show emissions calculated using the location-based method (LBM), alongside emissions calculated using the market-based method (MBM) which were already present. In addition, you can now see the estimated emissions from CloudFront usage in the service breakdown, alongside EC2 and S3 estimates. LBM reflects the average emissions intensity of grids on which energy consumption occurs. Electricity grids in different parts of the world use various sources of power, from carbon-intense fuels like coal, to renewable energy like solar. With LBM, you can view and validate trends in monthly carbon emissions that more directly align to your cloud usage, and get insights into the carbon intensity of the underlying electricity grids in which AWS data centers operate. This empowers you to make more informed decisions about optimizing your cloud usage and achieving your overall sustainability objectives. To learn more about the differences between LBM and MBM see the GHG Protocol Scope 2 Guidance. Check out your LBM emissions today in the Customer Carbon Footprint Tool and Data Exports; the updates are explained in detail in the user guide.