Amazon VPC now allows customers to route inbound internet traffic destined for large pools of public IP addresses, to a single elastic network interface (ENI) within a VPC.

Prior to this enhancement, internet gateways only accepted traffic destined to public IP addresses that were associated with network interfaces in the VPC. There are limits to the number of IP addresses that can be associated with network interfaces. These limits depend on the instance type and can be found in our documentation. There are use cases in Telco, Internet of Things (IoT) and other industries that require customers to route inbound traffic destined for public IP pools, larger than the allowed limits, to a single network interface. Customers would earlier perform address translation to consolidate traffic for such large number of IP addresses. This enhancement removes the need to perform address translation on inbound internet connections for these Telco and IoT use cases. Customers can bring their own public IP pools (BYOIP documentation) and configure their VPC Internet Gateway to accept traffic belonging to this BYOIP pool and route it to a network interface. They can also use this feature with VPC Route Server and dynamically update their routes in events of failure. Refer to our public documentation for details on VPC Route Server.

This enhancement is now available across all AWS commercial, AWS China and GovCloud regions. To learn more about this feature, please refer to our documentation.

 

​Amazon VPC now allows customers to route inbound internet traffic destined for large pools of public IP addresses, to a single elastic network interface (ENI) within a VPC. Prior to this enhancement, internet gateways only accepted traffic destined to public IP addresses that were associated with network interfaces in the VPC. There are limits to the number of IP addresses that can be associated with network interfaces. These limits depend on the instance type and can be found in our documentation. There are use cases in Telco, Internet of Things (IoT) and other industries that require customers to route inbound traffic destined for public IP pools, larger than the allowed limits, to a single network interface. Customers would earlier perform address translation to consolidate traffic for such large number of IP addresses. This enhancement removes the need to perform address translation on inbound internet connections for these Telco and IoT use cases. Customers can bring their own public IP pools (BYOIP documentation) and configure their VPC Internet Gateway to accept traffic belonging to this BYOIP pool and route it to a network interface. They can also use this feature with VPC Route Server and dynamically update their routes in events of failure. Refer to our public documentation for details on VPC Route Server. This enhancement is now available across all AWS commercial, AWS China and GovCloud regions. To learn more about this feature, please refer to our documentation.  

Today, we’re announcing the integration of Amazon Neptune Analytics with Cognee, a leading agentic memory framework designed to help AI agents structure, retrieve, and reason over information. With this launch, customers can use Neptune as the graph store behind Cognee’s memory layer, enabling long-term memory and reasoning capabilities for agentic AI applications.

This integration allows Cognee users to store and query memory graphs at scale, unlocking advanced use cases where AI agents become more personalized and effective over time by learning from ongoing interactions. Neptune supports multi-hop graph reasoning and hybrid retrieval across graph, vector, and keyword modalities—helping Cognee deliver richer, more context-aware AI experiences.

Cognee enables a self-improving memory system that helps developers build cost-efficient, personalized generative AI applications. To learn more about the Neptune–Cognee integration, visit the User Guide and the sample notebook.

 

​Today, we’re announcing the integration of Amazon Neptune Analytics with Cognee, a leading agentic memory framework designed to help AI agents structure, retrieve, and reason over information. With this launch, customers can use Neptune as the graph store behind Cognee’s memory layer, enabling long-term memory and reasoning capabilities for agentic AI applications. This integration allows Cognee users to store and query memory graphs at scale, unlocking advanced use cases where AI agents become more personalized and effective over time by learning from ongoing interactions. Neptune supports multi-hop graph reasoning and hybrid retrieval across graph, vector, and keyword modalities—helping Cognee deliver richer, more context-aware AI experiences. Cognee enables a self-improving memory system that helps developers build cost-efficient, personalized generative AI applications. To learn more about the Neptune–Cognee integration, visit the User Guide and the sample notebook.  

Amazon Relational Database Service (Amazon RDS) for MariaDB now supports community MariaDB minor versions 11.4.8, 10.11.14 and 10.6.23. We recommend that you upgrade to the latest minor versions to fix known security vulnerabilities in prior versions of MariaDB, and to benefit from the bug fixes, performance improvements, and new functionality added by the MariaDB community.

You can leverage automatic minor version upgrades to automatically upgrade your databases to more recent minor versions during scheduled maintenance windows. You can also leverage Amazon RDS Managed Blue/Green deployments for safer, simpler, and faster updates to your MariaDB instances. Learn more about upgrading your database instances, including automatic minor version upgrades and Blue/Green Deployments, in the Amazon RDS User Guide.

Amazon RDS for MariaDB makes it straightforward to set up, operate, and scale MariaDB deployments in the cloud. Learn more about pricing details and regional availability at Amazon RDS for MariaDB. Create or update a fully managed Amazon RDS database in the Amazon RDS Management Console.

 

​Amazon Relational Database Service (Amazon RDS) for MariaDB now supports community MariaDB minor versions 11.4.8, 10.11.14 and 10.6.23. We recommend that you upgrade to the latest minor versions to fix known security vulnerabilities in prior versions of MariaDB, and to benefit from the bug fixes, performance improvements, and new functionality added by the MariaDB community. You can leverage automatic minor version upgrades to automatically upgrade your databases to more recent minor versions during scheduled maintenance windows. You can also leverage Amazon RDS Managed Blue/Green deployments for safer, simpler, and faster updates to your MariaDB instances. Learn more about upgrading your database instances, including automatic minor version upgrades and Blue/Green Deployments, in the Amazon RDS User Guide. Amazon RDS for MariaDB makes it straightforward to set up, operate, and scale MariaDB deployments in the cloud. Learn more about pricing details and regional availability at Amazon RDS for MariaDB. Create or update a fully managed Amazon RDS database in the Amazon RDS Management Console.  

Amazon Web Services (AWS) announces the availability of Amazon EC2 I7ie instances in the AWS Europe (Stockholm), Asia Pacific (Jakarta), and US West (N. California) regions. Designed for large storage I/O intensive workloads, these new instances are powered by 5th generation Intel Xeon Scalable processors with an all-core turbo frequency of 3.2 GHz, offering up to 40% better compute performance and 20% better price performance over previous generation I3en instances.

I7ie instances offer up to 120TB local NVMe storage density—the highest available in the cloud for storage optimized instances—and deliver up to twice as many vCPUs and memory compared to prior generation instances. Powered by 3rd generation AWS Nitro SSDs, these instances achieve up to 65% better real-time storage performance, up to 50% lower storage I/O latency, and 65% lower storage I/O latency variability compared to I3en instances. Additionally, torn write prevention feature support up to 16KB block sizes, enables customers to eliminate performance bottlenecks for database workloads.

I7ie instances are high-density storage-optimized instances, for workloads that demand rapid local storage with high random read/write performance and consistently low latency for accessing large data sets. These instances are offered in eleven different sizes including 2 metal sizes, providing flexibility for customers computational needs. They deliver up to 100 Gbps of network performance bandwidth, and 60 Gbps of dedicated bandwidth for Amazon Elastic Block Store (EBS), ensuring fast and efficient data transfer for applications.

To learn more, visit the I7ie instances page.

 

​Amazon Web Services (AWS) announces the availability of Amazon EC2 I7ie instances in the AWS Europe (Stockholm), Asia Pacific (Jakarta), and US West (N. California) regions. Designed for large storage I/O intensive workloads, these new instances are powered by 5th generation Intel Xeon Scalable processors with an all-core turbo frequency of 3.2 GHz, offering up to 40% better compute performance and 20% better price performance over previous generation I3en instances. I7ie instances offer up to 120TB local NVMe storage density—the highest available in the cloud for storage optimized instances—and deliver up to twice as many vCPUs and memory compared to prior generation instances. Powered by 3rd generation AWS Nitro SSDs, these instances achieve up to 65% better real-time storage performance, up to 50% lower storage I/O latency, and 65% lower storage I/O latency variability compared to I3en instances. Additionally, torn write prevention feature support up to 16KB block sizes, enables customers to eliminate performance bottlenecks for database workloads. I7ie instances are high-density storage-optimized instances, for workloads that demand rapid local storage with high random read/write performance and consistently low latency for accessing large data sets. These instances are offered in eleven different sizes including 2 metal sizes, providing flexibility for customers computational needs. They deliver up to 100 Gbps of network performance bandwidth, and 60 Gbps of dedicated bandwidth for Amazon Elastic Block Store (EBS), ensuring fast and efficient data transfer for applications. To learn more, visit the I7ie instances page.  

SageMaker HyperPod task governance now supports Topology Aware Scheduling (TAS), enabling data scientists to schedule their large language model (LLM) tasks on an optimal network topology that minimizes network communication and enhances training efficiency.

LLM training and fine-tuning tasks that are distributed across multiple accelerated compute instances frequently exchange large volumes of data between them. Multiple network hops between instances can result in higher communication latency, impacting LLM task performance. SageMaker HyperPod task governance now enables data scientists to use network topology information when scheduling tasks with specific topology preferences. Using network topology in HyperPod, SageMaker HyperPod task governance automatically schedules tasks in optimal locations, reducing instance-to-instance communication and enhancing training efficiency.

SageMaker HyperPod task governance is available in all AWS Regions where HyperPod is available: US West (N. California), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm).

To learn more, visit SageMaker HyperPod webpage, and SageMaker HyperPod task governance documentation.

 

​SageMaker HyperPod task governance now supports Topology Aware Scheduling (TAS), enabling data scientists to schedule their large language model (LLM) tasks on an optimal network topology that minimizes network communication and enhances training efficiency.
LLM training and fine-tuning tasks that are distributed across multiple accelerated compute instances frequently exchange large volumes of data between them. Multiple network hops between instances can result in higher communication latency, impacting LLM task performance. SageMaker HyperPod task governance now enables data scientists to use network topology information when scheduling tasks with specific topology preferences. Using network topology in HyperPod, SageMaker HyperPod task governance automatically schedules tasks in optimal locations, reducing instance-to-instance communication and enhancing training efficiency.
SageMaker HyperPod task governance is available in all AWS Regions where HyperPod is available: US West (N. California), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm). To learn more, visit SageMaker HyperPod webpage, and SageMaker HyperPod task governance documentation.  

Amazon RDS for PostgreSQL 18 Beta 3 is now available in the Amazon RDS Database Preview Environment, allowing you to evaluate the pre-release of PostgreSQL 18 on Amazon RDS for PostgreSQL. You can deploy PostgreSQL 18 Beta 3 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database.

PostgreSQL 18 includes «skip scan» support for multicolumn B-tree indexes and improves WHERE clause handling for OR and IN conditions. It introduces parallel GIN index builds and updates join operations. Observability improvements show buffer usage counts and index lookups during query execution, along with per-connection I/O utilization metric. Please refer the RDS PostgreSQL release documentation for more details.

Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment. You can use the PostgreSQL dump and load functionality to import or export your databases from the preview environment.

Amazon RDS Database Preview Environment database instances are priced as per the pricing in the US East (Ohio) Region.

 

​Amazon RDS for PostgreSQL 18 Beta 3 is now available in the Amazon RDS Database Preview Environment, allowing you to evaluate the pre-release of PostgreSQL 18 on Amazon RDS for PostgreSQL. You can deploy PostgreSQL 18 Beta 3 in the Amazon RDS Database Preview Environment that has the benefits of a fully managed database. PostgreSQL 18 includes «skip scan» support for multicolumn B-tree indexes and improves WHERE clause handling for OR and IN conditions. It introduces parallel GIN index builds and updates join operations. Observability improvements show buffer usage counts and index lookups during query execution, along with per-connection I/O utilization metric. Please refer the RDS PostgreSQL release documentation for more details. Amazon RDS Database Preview Environment database instances are retained for a maximum period of 60 days and are automatically deleted after the retention period. Amazon RDS database snapshots that are created in the preview environment can only be used to create or restore database instances within the preview environment. You can use the PostgreSQL dump and load functionality to import or export your databases from the preview environment. Amazon RDS Database Preview Environment database instances are priced as per the pricing in the US East (Ohio) Region.  

Amazon Cloud Map now supports cross-account service discovery through integration with Amazon Resource Access Manager (Amazon RAM). This enhancement lets you seamlessly manage and discover cloud resources—such as Amazon ECS tasks, Amazon EC2 instances, and Amazon DynamoDB tables—across Amazon accounts. By sharing your Amazon Cloud Map namespace via Amazon RAM, workloads in other accounts can discover and manage resources registered in that namespace. This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service discovery across environments for organizations with multi-account architectures.

You can now share your Amazon Cloud Map namespaces using Amazon RAM with individual Amazon accounts, specific Organizational Units (OUs), or your entire Amazon Organization. To get started, create a resource share in Amazon RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to maintain a centralized service registry—or a small set of registries—and share them across multiple accounts, simplifying service discovery. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. Amazon Cloud Map’s cross-account service discovery support improves operational efficiency and makes it easier to scale service discovery as your organization grows by reducing duplication and streamlining access to namespaces.

This feature is available now in all commercial AWS Regions via the Amazon Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the Amazon Cloud Map documentation.

 

​Amazon Cloud Map now supports cross-account service discovery through integration with Amazon Resource Access Manager (Amazon RAM). This enhancement lets you seamlessly manage and discover cloud resources—such as Amazon ECS tasks, Amazon EC2 instances, and Amazon DynamoDB tables—across Amazon accounts. By sharing your Amazon Cloud Map namespace via Amazon RAM, workloads in other accounts can discover and manage resources registered in that namespace. This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service discovery across environments for organizations with multi-account architectures. You can now share your Amazon Cloud Map namespaces using Amazon RAM with individual Amazon accounts, specific Organizational Units (OUs), or your entire Amazon Organization. To get started, create a resource share in Amazon RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to maintain a centralized service registry—or a small set of registries—and share them across multiple accounts, simplifying service discovery. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. Amazon Cloud Map’s cross-account service discovery support improves operational efficiency and makes it easier to scale service discovery as your organization grows by reducing duplication and streamlining access to namespaces. This feature is available now in all commercial AWS Regions via the Amazon Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the Amazon Cloud Map documentation.  

SageMaker HyperPod task governance now supports fine-grained compute quota allocation of GPU, Trainium accelerator, vCPU, and vCPU memory within an instance. Administrators can allocate fine-grained compute quota across teams, optimizing compute resource distribution and staying within budget.

Data scientists often execute LLM tasks, like training or inference, that do not require entire HyperPod instances, leading to underutilization of accelerated compute resources. HyperPod task governance enables administrators to manage compute quota allocation across teams. With this capability, administrators can now strategically allocate compute resources, ensuring fair access, preventing resource monopolization, and maximizing cluster utilization. This capability enables fine-grained compute quota allocation in addition to instance-level allocation, aligning with organizational workload demands.

SageMaker HyperPod task governance is available in all AWS Regions where HyperPod is available: US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), and South America (São Paulo).

To learn more, visit SageMaker HyperPod webpage, and HyperPod task governance documentation.

 

​SageMaker HyperPod task governance now supports fine-grained compute quota allocation of GPU, Trainium accelerator, vCPU, and vCPU memory within an instance. Administrators can allocate fine-grained compute quota across teams, optimizing compute resource distribution and staying within budget. Data scientists often execute LLM tasks, like training or inference, that do not require entire HyperPod instances, leading to underutilization of accelerated compute resources. HyperPod task governance enables administrators to manage compute quota allocation across teams. With this capability, administrators can now strategically allocate compute resources, ensuring fair access, preventing resource monopolization, and maximizing cluster utilization. This capability enables fine-grained compute quota allocation in addition to instance-level allocation, aligning with organizational workload demands. SageMaker HyperPod task governance is available in all AWS Regions where HyperPod is available: US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), and South America (São Paulo). To learn more, visit SageMaker HyperPod webpage, and HyperPod task governance documentation.  

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R8g instances are available in AWS Asia Pacific (Jakarta)region. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 R8g instances are ideal for memory-intensive workloads such as databases, in-memory caches, and real-time big data analytics. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads.

AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. AWS Graviton4-based R8g instances offer larger instance sizes with up to 3x more vCPU (up to 48xlarge) and memory (up to 1.5TB) than Graviton3-based R7g instances. These instances are up to 30% faster for web applications, 40% faster for databases, and 45% faster for large Java applications compared to AWS Graviton3-based R7g instances. R8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS).

To learn more, see Amazon EC2 R8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.

 

​Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R8g instances are available in AWS Asia Pacific (Jakarta)region. These instances are powered by AWS Graviton4 processors and deliver up to 30% better performance compared to AWS Graviton3-based instances. Amazon EC2 R8g instances are ideal for memory-intensive workloads such as databases, in-memory caches, and real-time big data analytics. These instances are built on the AWS Nitro System, which offloads CPU virtualization, storage, and networking functions to dedicated hardware and software to enhance the performance and security of your workloads. AWS Graviton4-based Amazon EC2 instances deliver the best performance and energy efficiency for a broad range of workloads running on Amazon EC2. AWS Graviton4-based R8g instances offer larger instance sizes with up to 3x more vCPU (up to 48xlarge) and memory (up to 1.5TB) than Graviton3-based R7g instances. These instances are up to 30% faster for web applications, 40% faster for databases, and 45% faster for large Java applications compared to AWS Graviton3-based R7g instances. R8g instances are available in 12 different instance sizes, including two bare metal sizes. They offer up to 50 Gbps enhanced networking bandwidth and up to 40 Gbps of bandwidth to the Amazon Elastic Block Store (Amazon EBS). To learn more, see Amazon EC2 R8g Instances. To explore how to migrate your workloads to Graviton-based instances, see AWS Graviton Fast Start program and Porting Advisor for Graviton. To get started, see the AWS Management Console.  

Amazon FSx for NetApp ONTAP, a fully managed shared storage service built on NetApp’s popular ONTAP file system, now allows you to decrease your file system’s solid-state drive (SSD) storage capacity, enabling you to more efficiently run project-based workloads with varying active working sets. You can provision SSD capacity upfront to meet peak usage needs—for periodic reporting, analytics, or large-scale data ingestion and processing—and then easily decrease SSD capacity to reduce storage costs.

An FSx for ONTAP file system offers two storage tiers: a provisioned high-performance SSD tier for your workload’s active working set and a fully elastic capacity pool cost-optimized for infrequently accessed data. Until now, you could only increase your file system’s SSD capacity as your workload’s active working set grew. Starting today, you can decrease your file system’s SSD capacity in-place with just a few clicks in the Amazon FSx console, allowing you to deliver optimal performance during peak usage for workloads such as Electronic Design Automation and media processing, then scale down SSD capacity once data processing is complete. You can also accelerate data migrations by temporarily increasing SSD capacity to enable faster data ingestion, then right-sizing SSD capacity after data has been tiered to the capacity pool.

You can decrease SSD storage capacity on all FSx for ONTAP second-generation file systems in all AWS Regions where FSx for ONTAP second-generation file systems are available. For more information, see the FSx for ONTAP user guide.

 

​Amazon FSx for NetApp ONTAP, a fully managed shared storage service built on NetApp’s popular ONTAP file system, now allows you to decrease your file system’s solid-state drive (SSD) storage capacity, enabling you to more efficiently run project-based workloads with varying active working sets. You can provision SSD capacity upfront to meet peak usage needs—for periodic reporting, analytics, or large-scale data ingestion and processing—and then easily decrease SSD capacity to reduce storage costs. An FSx for ONTAP file system offers two storage tiers: a provisioned high-performance SSD tier for your workload’s active working set and a fully elastic capacity pool cost-optimized for infrequently accessed data. Until now, you could only increase your file system’s SSD capacity as your workload’s active working set grew. Starting today, you can decrease your file system’s SSD capacity in-place with just a few clicks in the Amazon FSx console, allowing you to deliver optimal performance during peak usage for workloads such as Electronic Design Automation and media processing, then scale down SSD capacity once data processing is complete. You can also accelerate data migrations by temporarily increasing SSD capacity to enable faster data ingestion, then right-sizing SSD capacity after data has been tiered to the capacity pool. You can decrease SSD storage capacity on all FSx for ONTAP second-generation file systems in all AWS Regions where FSx for ONTAP second-generation file systems are available. For more information, see the FSx for ONTAP user guide.