Amazon EC2 Hpc8a in Singapore: What AWS Announced and What Remains Unverified

AWS says Amazon EC2 Hpc8a instances are available in its Asia Pacific (Singapore) Region.

The change is regional availability, not a demonstrated performance or cost result for a particular workload. Here is who might consider the option and how to read AWS’s comparisons with Hpc7a.

Data Center News & Trends

What changed in Singapore?

AWS announced Hpc8a availability in the Asia Pacific (Singapore) Region. The announcement’s source feed is dated October 5, 2026. Its phrase “starting today” does not independently establish the exact time the instances became usable.

AWS describes Hpc8a as using 5th Gen AMD EPYC processors and sixth-generation AWS Nitro Cards. It cites a maximum processor frequency of 4.5 GHz—not a sustained clock rate for an application.

AWS positions the instances for compute-intensive, latency-sensitive, tightly coupled work, including computational fluid dynamics, weather forecasting, explicit finite element analysis and multiphysics simulations. The announcement does not provide measured inter-node latency for those workloads.

AWS — Amazon EC2 Hpc8a instances are now available in Asia Pacific (Singapore)

What do AWS’s Hpc7a comparisons say?

AWS makes three separate “up to” claims for Hpc8a compared with Hpc7a:

• Performance: up to 40% higher. This does not establish how much faster a particular simulation will run.
• Price performance: up to 25% better. This is not a Singapore price or a predicted reduction in a particular job’s bill.
• Memory bandwidth: up to 42% higher. Memory bandwidth is not network bandwidth or an overall application speedup.

These are AWS’s comparisons, not independently verified results for every workload.

What would a deployment decision still need?

The announcement does not give Singapore pricing, instance-size configurations, a benchmark method or measured runtime and cost for a reader’s application. That does not mean those details cannot be found elsewhere; it means the announced percentages alone cannot settle a workload-specific decision.

For a team planning HPC work in Singapore, Hpc8a is now another announced option to examine. The useful next step is to check the offered configuration and regional price, then evaluate representative application runs and their cost. Availability is the confirmed change; any time or cost benefit remains a question for the intended workload.

Sources

• AWS — Amazon EC2 Hpc8a instances are now available in Asia Pacific (Singapore)

Amazon EC2 Shared AMI Tags: What Recipients Can See and What Remains Unproven

AWS says AMI owners can make selected tags visible to accounts that receive an Amazon Machine Image.

The distinction is between owner-controlled shared tags and recipients’ own tags—and between the announced feature and any operational savings a team might achieve.

Data Center News & Trends

What did AWS announce?

An Amazon EC2 Amazon Machine Image (AMI) owner can make selected tags visible to accounts with which the AMI is shared. AWS says a shared tag accompanies an AMI shared with an individual account, across an organization, or publicly.

The AWS notice’s feed was published on October 5, 2026. A separate feature launch date has not been established.

AWS — Amazon EC2 introduces shared tags for Amazon Machine Images

Who controls a shared tag?

According to AWS, the owner marks a tag for sharing by adding `ec2:SharedTag/` to its key. Accounts receiving the AMI can see the shared tag, but it is read-only for them: only the owner can create, change, or delete it.

Shared AMI tag

Who manages it?

The owner creates, changes, and deletes it; recipients can read it

How do shared tags affect tag limits?

It counts only against the owner’s 50-tags-per-resource quota

Recipient’s private tag

Who manages it?

A recipient can add its own tag

How do shared tags affect tag limits?

Shared tags do not count against the recipient’s tag limit

That distinction matters if a recipient needs to manage its own metadata. An owner-controlled shared tag conveys information with the AMI; it is not an editable tag handed over to each receiving account.

What has been established about availability and operational benefit?

AWS says the feature is available in all AWS Regions at no additional cost. That statement concerns AMI tag sharing, not the total cost of using EC2.

AWS also says shared tags eliminate the need to build and maintain custom workflows for replicating tags into accounts after an AMI is shared. Its announcement does not report measured time savings or results from a particular organization. Whether that benefit applies to a team depends on what its existing workflow needs to do.

What should a team check before using shared tags?

A team can first decide which tag keys should be visible to AMI recipients, including when an AMI is made public. It can then check visibility in its own AMI-sharing workflow and keep owner-managed shared tags distinct from tags recipients add for themselves.

The practical takeaway is a boundary, not a promised efficiency gain: use shared tags for information the owner intends to convey with the AMI, and assess any reduction in tag-management work against the team’s actual procedures.

Sources

• AWS — Amazon EC2 introduces shared tags for Amazon Machine Images

AWS Identity Store Network Access Controls: Which API Requests Can Be Restricted?

AWS announced network access controls for IAM Identity Center’s Identity Store.

The available restrictions differ between the Identity Store API and the SCIM API; this article separates those options from the defaults, exemptions and deployment results the announcement does not verify.

Data Center News & Trends

What did AWS announce?

AWS says IAM Identity Center now supports network access controls for Identity Store, which stores users and groups. The announcement feed lists October 5, 2026, as its publication date; it does not establish a separate rollout date.

The controls concern where requests to two interfaces originate. AWS describes custom applications and user-provisioning workflows using the Identity Store API to manage or look up users and groups, while external identity providers use the SCIM API to synchronize them.

AWS — AWS IAM Identity Center now supports network access controls for Identity Store

Which restrictions apply to each API?

The VPC-based options AWS describes are for the Identity Store API. IP-range restrictions can be applied to either API, and the two APIs can have different restrictions in the same configuration.

Identity Store API

Network-origin restrictions AWS describes

Require requests through allowed VPC endpoints in the account or organization, or from specified source VPCs; allow requests only from specified IP ranges

SCIM API

Network-origin restrictions AWS describes

Allow requests only from specified IP ranges

For example, AWS describes restricting Identity Store API requests to VPC endpoints while allowing SCIM requests from an external identity provider’s published IP ranges. That illustrates a possible configuration, not a required one. The announcement does not describe the VPC endpoint or source-VPC options as SCIM API restrictions.

Are the controls already on for every request?

No. AWS says the controls are optional and off by default. Requests that AWS services make on a user’s behalf are exempt, so the announced restrictions should not be read as applying to every request associated with an Identity Store workflow.

AWS says the controls are configured through the Identity Store API using AWS SDKs or the AWS CLI and are available in AWS Regions where IAM Identity Center is offered. Availability does not establish that a particular account has enabled them.

What should a team check before drawing a deployment conclusion?

The announcement establishes configuration options, not a tested outcome for a particular deployment. It does not verify that every unwanted request would be blocked or that existing applications and synchronization workflows would continue without disruption.

The useful next question is where each request actually originates and how it reaches its API. Consider Identity Store API applications and provisioning separately from SCIM synchronization, then compare each path with the restriction selected for that API.

Include whether the control is enabled and whether an AWS service is making a request on the user’s behalf. Only that environment-specific assessment can support a conclusion about which requests the configuration would restrict and which workflows might be affected.

Sources

• AWS — AWS IAM Identity Center now supports network access controls for Identity Store

AWS MCP Server Adds Six Regions: Server Location vs. Service Reach

AWS announced six additional Regions for AWS MCP Server.

The expansion gives teams using AI coding agents more endpoint choices, but the server’s location does not establish where the AWS services it calls run—or prove a latency or data-residency outcome.

Data Center News & Trends

What did AWS add?

AWS announced that AWS MCP Server is available in six additional Regions: Singapore, Sydney, Tokyo, Ireland, London and Oregon. The announcement’s feed was published on October 2, 2026; it does not establish a separate rollout date for each Region. AWS’s full availability list also includes Northern Virginia and Frankfurt, for eight listed server-hosting Regions.

AWS describes the managed Model Context Protocol server, part of its Agent Toolkit, as a single interface through which AI coding agents can discover and call AWS services without a separate integration for each service. The expansion changes where teams can choose to run that server.

AWS — The AWS MCP Server is now available in six additional AWS Regions

London is AWS's example. Hosting the server there does not by itself verify the Region of a called service, end-to-end data residency or a latency improvement.

Does a local server endpoint mean local service calls?

Not necessarily. AWS illustrates the new choice with a London development team pointing its coding agents at a London endpoint to provision infrastructure, inspect workloads and debug failures. That is an example of endpoint selection, not a verified account of every subsequent service call.

AWS says the MCP Server runs in its listed hosting Regions but can access services in all commercial AWS Regions. The server’s Region and the Region of a service reached through it are therefore separate questions. Selecting London for the server does not, by itself, establish that a called service is in London.

What should a team verify before relying on the claimed benefits?

AWS says a server closer to developers can reduce latency and keep request data within its Region for residency requirements. The announcement provides no latency measurements or verification of end-to-end residency for a particular workflow, so those potential benefits should not be treated as demonstrated results for every team.

For a planned workflow, distinguish the chosen MCP Server Region from the Regions of the AWS services the agent will call. Then assess the actual API paths against the team’s request-data residency requirements and evaluate latency on that path. The new endpoints create a choice; whether that choice meets a specific requirement depends on the calls the team makes.

Sources

• AWS — The AWS MCP Server is now available in six additional AWS Regions

Amazon EMR Serverless: What the Announced 1 TB Shuffle Support Means

AWS says Amazon EMR Serverless now supports shuffle operations of up to 1 TB, compared with what it describes as a previous 200 GB per-job limit.

The change may matter to Spark teams constrained by shuffle storage, but the announcement does not establish how any particular job will perform. Here is what changed, where AWS says it is available, and what remains to be checked.

Data Center News & Trends

What changed—and are the two figures directly comparable?

In an announcement published October 1, 2026, AWS said Serverless Storage on Amazon EMR Serverless supports shuffle operations of up to 1 TB. It described the previous limit as 200 GB per job. The announcement does not explicitly say that the new 1 TB figure is also a per-job limit, so the figures should not be presented as a like-for-like per-job comparison.

AWS — Serverless Storage on Amazon EMR Serverless now supports terabyte-scale shuffle

Which Spark workloads might care?

Spark can produce substantial shuffle data when it rearranges data for joins, aggregations and sorting. AWS highlights large-table joins and high-cardinality aggregations as examples. A team whose jobs encountered the previous shuffle-storage limit has a reason to examine the new support. AWS also says it added spill support, which offloads data to disk when needed during memory-intensive operations.

Dataset size is not the shuffle allowance. AWS mentions joins across multi-terabyte datasets, but that example does not mean multi-terabyte shuffle operations are supported; the announced shuffle figure is up to 1 TB.

Where is it available, and what has not been demonstrated?

AWS lists Amazon emr-7.14, emr-spark-8.1 and later, across 18 AWS Regions where EMR Serverless is available. It directs readers to its documentation for the supported Regions and their applicable limits; the announcement does not list each regional limit.

AWS describes improved reliability and job success rates as benefits of spill support. The announcement, however, provides no measured results for a particular job’s success rate, runtime or cost. Availability of the feature is not evidence that a given job will finish faster or cost less.

What should a team take away?

Treat the announcement as a reason to reassess jobs that may have been constrained by shuffle storage, not as a performance result. Check the job’s EMR version, Region and applicable limit against its shuffle demand. Then assess completion, runtime and cost on the job itself. That separates a newly stated storage capability from operational improvements that still need to be established.

Sources

• AWS — Serverless Storage on Amazon EMR Serverless now supports terabyte-scale shuffle

Sonnet Solo10G T5 Launch: What the Report Confirms—and What It Doesn’t

Impress PC Watch reported the launch of a bus-powered adapter that adds a 10GbE-capable RJ45 port to specified hosts.

Here are the reported connection and software requirements, followed by the performance questions the launch report does not answer.

Data Center News & Trends

What was launched?

On October 1, 2026, Impress PC Watch reported that Sonnet Technologies had launched the Solo10G T5 (SOLO10G-TB5) that day, local time. The report describes it as a bus-powered Thunderbolt 5-to-10Gigabit Ethernet adapter with stated power consumption of 7.5 W. That figure describes the adapter in the report; it is not a test of a particular host’s power capacity.

Impress PC Watch — 業界初のバスパワー駆動Thunderbolt 5接続の10Gigabit Ethernetアダプタが登場

Which connections and software does the report specify?

The reported use case is adding a 10GbE-capable RJ45 port to a Mac, Windows PC, Linux PC or Apple M-series iPad Pro with a Thunderbolt 5, 4 or 3 port, or a USB4 port. Those categories are a starting point for checking a particular device, not proof that every configuration works.

On the Ethernet side, the listed connection speeds are 10, 5, 2.5 and 1 Gbps; the report identifies the lower three as NBASE-T support. These are stated port capabilities, not measured transfer speeds. The listed software requirements are macOS 15 or later, Windows 11 25H2 or later, Linux kernel 6.6 or later, and a current version of iPadOS.

No numbered minimum iPadOS version is given. The report describes Mac and Linux setup as plug-and-play, says Windows needs a driver download and installation, and makes no equivalent plug-and-play statement for iPad Pro.

What remains unverified for a planned connection?

Impress PC Watch calls the adapter an “industry first,” but its article provides no competitor comparison that independently establishes that ranking. It also provides no throughput measurement on a particular host or sustained-operation test. Neither the listed speeds nor the host categories establish how a specific setup will perform.

The useful takeaway is to separate three questions: Is the host model, port and operating system within the reported support conditions? If it runs Windows, can the required driver be installed? And, if the connection must meet a performance requirement, is there test evidence applicable to that configuration? The launch report helps with the first questions but cannot settle the last one.

Sources

• Impress PC Watch — 業界初のバスパワー駆動Thunderbolt 5接続の10Gigabit Ethernetアダプタが登場

AWS Adds Graphics G7 to WorkSpaces Core Managed Instances: What Is Confirmed?

AWS has announced Graphics G7 support for WorkSpaces Core Managed Instances.

The announcement identifies the hardware, intended workloads and four Regions, but its comparison with G6 does not establish a performance gain for a particular application.

Data Center News & Trends

What did AWS add?

AWS announced support for Graphics G7 instances in Amazon WorkSpaces Core Managed Instances in a notice published September 30, 2026. The instances use NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs and Intel Xeon 6 processors. This adds a managed-instance option for professional graphics work; it does not, by itself, demonstrate how a particular application will perform.

AWS names CAD/CAM, 3D rendering, scientific visualization, video editing and AI-assisted design as potential workloads. It specifies 32 GB of GDDR7 memory per GPU and six instance sizes spanning 1–8 GPUs, 8–192 vCPUs and 32–768 GB of system memory.

GPU memory and system memory are different quantities, and the announcement does not map those family-wide ranges to individual sizes. AWS also lists Linux and Windows support and mentions bring-your-own-license, without detailing eligibility for each operating system.

AWS — Amazon WorkSpaces Core Managed Instances adds support for NVIDIA Blackwell GPU

Where and how does AWS say G7 can be selected?

AWS lists four Regions for the offering: US East (N. Virginia), US East (Ohio), US West (Oregon) and Europe (Spain). It says more Regions will be added but gives no schedule. The list does not guarantee that G7 is currently selectable in every account or partner solution.

According to AWS, a user can specify a G7 instance type when creating a new WorkSpaces Core Managed Instance. Alternatively, a user of a WorkSpaces Core partner solution can look for G7 types when that solution makes them available. The partner route is therefore conditional, not a statement that every partner already supports G7.

What remains unverified about performance?

AWS claims “up to 2.1× better performance” for graphics-intensive workloads compared with previous-generation G6 instances. That is a company claim, not a guaranteed gain across applications: the announcement supplies neither a benchmark setup nor an independently verified result for a reader’s workload.

AWS also describes G7 memory bandwidth as “2.67× faster” without explicitly identifying the comparison baseline, so that figure should not be presented as a confirmed G6 comparison.

The useful distinction is between an available option and a proven workload result. Before choosing G7, check whether it is offered in the relevant Region and access route, whether a suitable size and operating-system or licensing arrangement is available, and whether performance evidence reflects the application you intend to run.

Until then, the announced specifications and AWS’s performance claims answer different questions.

Sources

• AWS — Amazon WorkSpaces Core Managed Instances adds support for NVIDIA Blackwell GPU

Amazon RDS for SQL Server Developer Edition Adds Multi-AZ Support: What the Announcement Establishes

AWS announced Multi-AZ support using Always On Availability Groups for specified SQL Server Developer Editions.

The edition and version limits are clear, but regional availability, cost and failover results for a particular deployment need separate checks.

Data Center News & Trends

What did AWS announce?

Amazon RDS for SQL Server now supports Multi-AZ deployments using Always On Availability Groups with SQL Server Developer Edition, according to AWS. Its announcement appeared in the source feed on September 24, 2026; that publication date does not establish a separate feature-launch date.

AWS says the configuration maintains a synchronous standby replica in a different Availability Zone and provides automatic failover during infrastructure failure. That describes supported behavior, not a measured failover time or uptime result for a particular deployment.

AWS — Amazon RDS supports Multi-AZ for SQL Server Developer Edition

Which editions and versions are included?

AWS names these boundaries for Multi-AZ with Always On Availability Groups:

• SQL Server Developer Edition 2019 and 2022: supported.
• SQL Server 2025 Enterprise Developer Edition: supported.
• SQL Server 2025 Standard Developer Edition: not supported.

AWS presents the capability as a way to build and test high-availability configurations, including failover behavior, in non-production environments. It says Developer Edition includes Enterprise Edition functionality without Enterprise Edition licensing costs. That licensing statement does not mean an RDS deployment has no other costs.

What must a team verify before relying on it?

The announcement does not report a deployment-specific failover test or achieved uptime. It also directs readers elsewhere for applicable AWS Regions and RDS for SQL Server pricing rather than providing a region list or a total-cost calculation.

For a proposed non-production test, the useful distinction is between eligibility and results:

• Confirm the exact edition and major version against AWS’s supported list.
• Check availability in the intended Region and the applicable RDS pricing.
• Test the required failover behavior in the environment where the configuration will be used.

Support for a configuration makes that test possible; it does not settle whether a particular deployment meets the team’s failover requirements.

Sources

• AWS — Amazon RDS supports Multi-AZ for SQL Server Developer Edition

AWS DRS Adds Support for Graviton Source Servers: What the Announcement Establishes

AWS says Elastic Disaster Recovery now supports Graviton-based arm64 source servers.

The announcement describes the recovery path and where the capability is offered, but it does not establish a recovery result for any particular workload.

Data Center News & Trends

What changed, and what does the date mean?

AWS says Elastic Disaster Recovery (DRS) now supports disaster recovery for Graviton-based arm64 source servers. That gives teams planning recovery for Graviton workloads a support path to investigate. The distinction is between the capability AWS has announced and a recovery outcome a team has verified for its own application.

September 25, 2026 is the publication date in the AWS What's New feed. The announcement does not give a separate date when the capability became active, so the feed date should not be treated as an activation date.

AWS — AWS Elastic Disaster Recovery now supports AWS Graviton-based source servers

How does AWS describe the arm64 recovery path?

According to AWS, DRS automatically detects arm64 source servers and recovers them onto Graviton instances, preserving the workload architecture. AWS says recovery works as it does for other servers, with nothing extra to configure. That describes the announced workflow; it does not show that every application will recover successfully.

AWS says the capability is available in all AWS Regions where DRS is offered, at no additional cost. This is a statement about the added capability, not a claim that DRS itself is free or available in every AWS Region.

What remains to be verified for a recovery plan?

The announcement includes no workload-specific recovery test results or measured recovery times. “Supported by DRS” is therefore different from “verified for this application”: the announcement cannot tell a team whether its workload will recover successfully or how long recovery will take.

Before relying on the capability in a plan, check the conditions that apply to the configuration in the AWS Elastic Disaster Recovery User Guide and test recovery of the workload concerned. The announced support makes that assessment relevant; the workload test is what can establish a result for the plan.

Sources

• AWS — AWS Elastic Disaster Recovery now supports AWS Graviton-based source servers

EC2 R8i and R8i-flex in Germany: What AWS Announced—and What Remains to Be Checked

AWS announced that EC2 R8i and R8i-flex are available in the AWS European Sovereign Cloud (Germany) region.

The change is regional availability, not a demonstrated performance or cost result for every deployment. Here is how the two families differ in AWS’s description, and what to verify before choosing one.

Data Center News & Trends

What changed in the announcement?

In its notice published September 25, 2026, AWS announced that Amazon EC2 R8i and R8i-flex instances are available in the AWS European Sovereign Cloud (Germany) region. The notice’s publication date is known; a separate rollout date has not been verified.

For a reader considering memory-intensive workloads in that region, the announcement puts both families on the list of options to examine. It does not establish that a needed size can be launched in a particular account, or that a workload will achieve a particular performance or cost result.

AWS — Amazon EC2 R8i and R8i-flex instances are now available in additional regions

How does AWS distinguish R8i-flex from R8i?

AWS describes the families in terms of resource use and instance size:

• R8i-flex is a memory-optimized Flex family that AWS positions for applications that do not fully use all compute resources. Its stated family size range runs from large through 16xlarge.
• R8i is positioned for memory-intensive workloads, particularly those needing the largest sizes or sustained high CPU use. AWS describes 13 family sizes, including two bare-metal sizes and 96xlarge.

These descriptions help narrow the choice, but a family’s stated size range is not confirmation that every size is launchable in the intended account in Germany.

Do AWS’s comparison figures predict a deployment’s results?

No. AWS claims that R8i and R8i-flex offer up to 15% better price-performance and 2.5 times the memory bandwidth compared with previous-generation Intel-based instances. It also claims 20% higher performance than R7i and, compared with R7i for named workloads, up to 30% faster PostgreSQL databases, 60% faster NGINX web applications and 40% faster AI deep-learning recommendation models.

Those are AWS’s comparisons, not independently verified results for a deployment in the newly announced region. In particular, an “up to” figure for a named workload should not be treated as the expected gain for a different application—or as a measured cost saving.

What should a deployment decision depend on?

AWS lists Savings Plans, On-Demand and Spot as purchase options, but that list does not give the applicable price or effective cost of a particular deployment. The useful distinction is between a family being announced for a region and the conditions under which it meets a specific deployment’s needs. Check:

• Whether the required R8i or R8i-flex sizes are available to the intended account in the Germany region.
• Which purchase terms and prices apply to the proposed deployment.
• Whether results from the actual workload meet its performance requirements.

If any of those answers is unfavorable or still unknown, the regional announcement alone is not a sufficient basis for choosing the instance family.

Sources

• AWS — Amazon EC2 R8i and R8i-flex instances are now available in additional regions

AWS’s Aurora Serverless Scaling Announcement: Up to 16 ACUs Added in a Second

AWS says Aurora Serverless can add capacity in larger steps, but the announcement does not measure the effect on a particular application.

Here is what the capacity figures mean, which platform versions AWS says are covered, and what remains to be checked.

Data Center News & Trends

What does the one-second scaling claim mean?

AWS says Aurora Serverless can add up to 16 ACUs to its current capacity within a second. The 16 ACUs are the maximum addition in that interval, not the resulting total capacity. AWS separately says capacity can continue rising to as much as 256 ACUs as workload demand grows; it does not say the service reaches 256 ACUs in one second.

The AWS feed published the notice on September 30, 2026. The announcement text does not give a separate date on which the change occurred.

AWS — Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads

Which clusters does AWS say are covered?

AWS says the enhancement is enabled by default, without configuration changes, on Aurora Serverless clusters running platform version 3 or 4. For existing clusters on versions 1 or 2, AWS describes a direct upgrade path to version 4; it does not say the enhancement is already enabled on those older versions.

To check a cluster’s platform version, AWS points to the instance configuration section of the AWS Management Console or the RDS API’s ServerlessV2PlatformVersion parameter. That version check establishes whether a cluster falls within the stated scope; it does not measure an application benefit.

What results does the announcement leave unverified?

AWS says Aurora Serverless scales down to zero when a workload finishes and describes it as suited to bursts separated by long idle periods. That description does not establish cost savings for a particular cluster. The notice also gives no application-specific before-and-after latency, throughput or cost results.

For prices and Region availability, it directs readers to Amazon Aurora Pricing rather than listing those details.

For a team running a bursty service, the useful next distinction is between eligibility and effect: check the cluster’s platform version to understand whether AWS says the change applies, then use that service’s workload and operating records to assess any effect on latency, throughput or cost. A faster capacity increase alone cannot establish those outcomes.

Sources

• AWS — Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads

ElastiCache Serverless for Valkey Public Endpoints: What Changed and What Still Needs Checking

AWS says ElastiCache Serverless for Valkey now supports public endpoints, giving applications outside an AWS VPC another way to connect.

Here is what AWS says about access, authentication, versions, availability and pricing—and what the announcement cannot establish for a particular workload.

Data Center News & Trends

What changed for applications outside a VPC?

AWS announced public-endpoint support for Amazon ElastiCache Serverless for Valkey. It says a laptop, serverless function or application running outside AWS can connect to a cache without setting up a VPN, bastion host or SSH tunnel. The announcement appeared in AWS’s feed on September 29, 2026; that publication date does not establish a separate date when the feature became available.

AWS describes the public-endpoint option as an internet-reachable cache with no VPC to configure or infrastructure to provision. That describes this access option, not the configuration of every ElastiCache deployment.

AWS — Amazon ElastiCache Serverless for Valkey now supports public endpoints

What do the cache and client need?

AWS says connections use IAM authentication over TLS 1.3. Under the method it describes, there is no separate password to store or rotate. For a client, AWS names two paths: Valkey GLIDE 2.2 or later, which has built-in IAM support, or another Valkey client paired with the Developer Toolkit for ElastiCache to generate and refresh IAM authentication tokens.

For getting started, AWS specifies a Valkey 9.0 or later serverless cache with a public endpoint, created through the AWS Management Console, AWS SDK or AWS CLI. The two version numbers refer to different things: 9.0 is the cache’s Valkey version; 2.2 is the minimum stated GLIDE client version.

The stated authentication and encryption method does not, by itself, establish that a particular deployment meets an organization’s security requirements.

What do the availability and pricing statements cover?

AWS says the public-endpoint option is available in all commercial AWS Regions and the China Regions. It also says there is no additional charge for using a public endpoint beyond standard ElastiCache Serverless pricing. Regional availability is not a test of access from a particular application, and the endpoint-pricing statement is not an estimate of that application’s total cost.

What is the practical takeaway?

For an application outside a VPC, the announcement changes the access question: a VPN or tunnel is not the only route AWS describes. The next question is whether the intended client can authenticate and connect to this public endpoint—and whether that connection meets the workload’s security, latency and cost requirements.

AWS’s announcement identifies an option and its stated conditions; it does not establish those outcomes for a specific deployment.

Sources

• AWS — Amazon ElastiCache Serverless for Valkey now supports public endpoints