AWS

AWS EBS Volume Clones: Cross-account copy with KMS re-encryption

AWS EBS clones can be copied across accounts and re-encrypted with a destination KMS key, removing snapshot-share complexity for multi-account workflows.

September 11, 2026·3 min read·AI researched · AI written · AI reviewed

Amazon just removed one of those operational headaches you stop noticing until it breaks: EBS Volume Clones can now be copied across accounts and optionally re-encrypted with a KMS key in the destination account. For teams that run multi-account landing zones, provider-managed golden AMIs, or cross-account DR, that single feature eliminates convoluted snapshot-share-and-grant-who-knows-what workflows and the attendant brittle KMS ACL gymnastics.

Practically: you can clone a volume in account A and create the clone in account B while specifying a KMS key that lives in B. That means the target account owns the encryption key and key policy, and you don't have to grant long-lived decrypt permissions back to the source account. Thats the right call  the alternative was teams resorting to ad-hoc credential injection or granting broad cross-account decrypt access, both of which are audit and blast-radius nightmares.

Two operational notes that matter immediately:

  • This changes your least-privilege model for cross-account imaging. Instead of sharing encrypted snapshots and updating source-key policies to allow another account to decrypt, the source only needs permission to initiate the cross-account clone operation, while the destination KMS key is used to produce the encrypted volume in the target account. Teams should update IAM roles and KMS key policies to allow the clone workflow and treat the destination key as the data-at-rest owner.

  • Dont mistake convenience for safe defaults. Re-encryption to the target key is optional  make it mandatory in your provisioning pipelines to avoid accidentally maintaining multi-account decryption surfaces.

The rest of this weeks rollups knit into the same themes: resilience at the infra layer and better support for high-throughput, long-context LLMs.

Gateway Load Balancer: TCP Reset

Gateway Load Balancer (GWLB) now emits TCP RST when targets become unhealthy, get deregistered, or hit idle-timeout expiry. Thats a low-glamour change with outsized system effects: inline security appliances and transparent proxies often leave client sockets hanging while backends are drained or fail. A TCP RST tells the client "try again now" instead of forcing slow timeouts or half-open sessions.

Two consequences platform engineers should expect:

  • Faster failover and simpler retry logic. Clients and load-balancing stacks can fail fast rather than waiting out long TCP retransmit windows.
  • Different semantics for stateful middleboxes. If your IPS/IDS or NAT device relied on silent disconnection to flush state, youll see immediate retries. Test that your network security appliances tolerate RSTs.

And the kicker: no pricing change. AWS didnt tack on a premium for this behavior, which is telling  they want this used widely to improve availability patterns for inline appliances.

Bedrock and model infra updates

Anthropics Claude Fable 5 is now part of the model mix available via Amazon Bedrock and Anthropics own platform, which expands Bedrocks family of models for long-context, reasoning-heavy workloads. The LLM story in AWSs posts this week isnt just new weights: its infra ergonomics. Bedrock and SageMaker updates include prefix-aware routing for inference and improved caching strategies  provisioned inference clusters can keep KV caches warm and pre-load weights to NVMe to cut cold-start and cache-miss latency.

If you care about operating large LLMs at scale, that second part matters more than another model name. Prefix-aware routing reduces unnecessary model hops for common prompt patterns, and warm KV caches + NVMe preloads turn the difference between a 100ms tail and a 1s tail into an engineering problem you can solve with infra, not an app-level hack.

Why this matters together

Theres a clear signal here: AWS is smoothing the operational edges for two things platform teams actually fight  multi-account data lifecycles and the latency/reliability of agentic AI stacks. EBS clones remove brittle snapshot plumbing; GWLB RST fixes a class of slow-failure networking behaviors; Bedrock/SageMaker changes tackle model-serving tail latencies.

My take: the EBS cross-account clone feature should be enabled in every org that operates multi-account golden-image or DR workflows. Its safer and simpler than the snapshot-and-grant dance. But dont flip the switch blindly  make re-encryption mandatory in your pipelines, and tighten KMS key policies so destination accounts truly own the data. Also, run a quick test suite against your inline network appliances for TCP RST semantics before you assume "fail fast" wont break anything.

If you follow platform hygiene  key ownership, least-privilege, and test suites for network semantics  these changes reduce operational friction. Ignore those basics and youll trade one set of brittle practices for another that looks shiny but leaks access in different ways.

For more on Claude Fable 5 and Bedrock model-loading patterns, see our previous coverage of Claude Fable 5s context and cache behavior and how Bedrocks model families are changing deployment assumptions in Amazon Bedrock adds Astra model family; EKS fast-loading patterns and Lambda SnapStart impacts.

Final thought: these are incremental changes that compound. One improves your DR story, one makes network failures explicit, and one reduces LLM tail latency. Together they nudge platform engineering toward fewer ad-hoc hacks and more deliberate ownership of keys, failure semantics, and model-serving infra. Thats overdue  and its the sort of small infrastructure change that actually makes on-call less dreadful.

Sources

amazon-ebsebs-volume-clonesgateway-load-balanceramazon-bedrockclaude-fable-5
← All articles
AWS

AWS Lambda Managed Instances: 90-minute async timeouts and Graviton5 support

AWS Lambda Managed Instances now allow 90-minute async and event-source timeouts and Graviton5 instance support, shifting longer batch and inference jobs to managed hosts.

Sep 10, 2026·3maws-lambdagraviton5
AWS

Amazon Bedrock adds Astra model family; EKS fast-loading patterns and Lambda SnapStart impacts

AWS Bedrock added an Astra model family and expanded model access. EKS fast-loading patterns and Lambda SnapStart change startup, cache, and tenancy trade-offs.

Sep 9, 2026·3mamazon-bedrockastra
AWS

Amazon Bedrock Adds Anthropic's Claude Fable — AgentCore Runtime, MCP Federated Data Patterns, and EKS AI Ops

Amazon Bedrock adds Claude Fable; AWS published AgentCore and MCP federated patterns. Platform teams must treat agents, MCP, and GPU EKS as core infra pieces.

Sep 8, 2026·3mamazon-bedrockclaude-fable