AWS Weekly Digest
Week of 21–27 September 2026
No new EC2 families this week, but DR for Graviton, private STS token verification and a recommend-only DevOps Agent all deserve a slot in your next design review.
Do this week
- Re-benchmark one EC2 Auto Scaling group on C8i/M8i-flex and move it to attribute-based instance selection so it can pick up new generations automatically.
- If you run Graviton in production, put at least one stateful arm64 tier under Elastic Disaster Recovery and run a recovery drill.
- Search your AMIs, user data and SSM parameters for static third-party credentials, and replace one with STS outbound federation over a private OIDC endpoint.
- Replay two past incidents through CloudWatch Omni's DevOps Agent (recommend-only) and score its root-cause analysis against your postmortems before rolling it out further.
Showing 4 of 10 changes tagged Operational Excellence
Showing 2 of 10 changes tagged Security
Showing 7 of 10 changes tagged Reliability
Showing 3 of 10 changes tagged Performance Efficiency
Showing 6 of 10 changes tagged Cost Optimization
Showing 1 of 10 changes tagged Sustainability
Primary lens — EC2 & IaaS compute
01EC2 C8i, M8i and R8i (plus -flex) reach the AWS European Sovereign Cloud
Better: Use attribute-based instance selection or a mixed-instances policy that lists C8i/M8i/R8i-flex first, and re-benchmark with your own load profile before cutting over.
All three 8th-gen Intel families landed in the European Sovereign Cloud on the same day. AWS positions them at up to 20% faster than the 7i equivalents, with headline workload gains of up to 60% on NGINX and 30% on PostgreSQL. C8i and R8i also carry a new 96xlarge size, and R8i remains the SAP-certified pick (142,100 aSAPS).
For sovereign workloads that were stuck on older families because the region launched with a narrower catalogue, this is the moment to plan a generation bump. The -flex variants (large to 16xlarge) are the sensible default for web tiers and microservices that rarely sustain full CPU.
Also: C8i announcement, R8i announcement.
Anti-pattern: Pinning production Auto Scaling groups to a single previous-generation instance type "because it's what we benchmarked in 2023".
Better: Use attribute-based instance selection or a mixed-instances policy that lists C8i/M8i/R8i-flex first, and re-benchmark with your own load profile before cutting over.
Tradeoff: The Sovereign Cloud is a separate partition with its own IAM, billing and tooling. AMIs, Savings Plans and automation don't carry over automatically, and -flex sizes cap at 16xlarge with no bare metal.
02AWS Elastic Disaster Recovery now protects Graviton (arm64) source servers
Better: Run production across at least two AZs behind an ALB, protect stateful hosts with DRS into a second Region, and schedule a non-disruptive recovery drill each quarter.
DRS now auto-detects arm64 source servers and recovers them onto Graviton instances, with the same replication and drill workflow as x86 and no extra configuration or charge. It's available in every Region where DRS runs.
This removes one of the most common objections I hear in Graviton migration reviews: "our DR tooling doesn't support it". If you hand-built snapshot-copy or AMI-replication scripts for arm64 fleets, you can now consolidate onto DRS with continuous block-level replication and point-in-time recovery.
Anti-pattern: A single-AZ "production" Graviton fleet, with DR that consists of nightly AMI copies nobody has ever restored.
Better: Run production across at least two AZs behind an ALB, protect stateful hosts with DRS into a second Region, and schedule a non-disruptive recovery drill each quarter.
Tradeoff: DRS keeps a low-cost staging area running in the target Region, which adds cost. Also check that the Graviton instance types your launch templates reference exist in the recovery Region.
03Route 53 Resolver now runs locally on second-generation Outposts racks
Action: Before 22 Dec, check whether any rack depends on a self-managed DNS forwarder on EC2. If so, decide between retiring it (and saving that instance) or opting out through AWS Support to avoid…
EC2 instances on gen-2 Outposts racks now get managed recursive DNS on the rack itself instead of going back to the parent Region over the Service Link. Cached records keep resolving when the Service Link drops, which was a real single point of failure for "edge-resilient" designs.
The feature needs no customer compute and is on by default.
Action: Before 22 Dec, check whether any rack depends on a self-managed DNS forwarder on EC2. If so, decide between retiring it (and saving that instance) or opting out through AWS Support to avoid paying twice.
Tradeoff: After the free trial ends it costs about $474 per rack per month. For fleets with many racks, weigh that against running your own resolver and the operational work it brings.
Secondary — IAM, networking & perimeter security
04IAM outbound identity federation: OIDC discovery over interface VPC endpoints
Better: Have the instance role request a short-lived STS JWT and federate to the external service. Keep anything that still needs a static secret in Secrets Manager with rotation.
Outbound identity federation lets EC2 workloads get short-lived JWTs from STS and present them to external services. Until now, verifying those tokens meant reaching the public OIDC discovery and JWKS endpoints. That forced isolated VPCs to open a NAT path or take an egress-firewall exception.
With an interface endpoint, the whole verification path stays on PrivateLink. It's available everywhere (commercial, GovCloud and China) at standard PrivateLink pricing.
Anti-pattern: Long-lived API keys or client secrets for third-party SaaS baked into AMIs, user data or environment variables on EC2.
Better: Have the instance role request a short-lived STS JWT and federate to the external service. Keep anything that still needs a static secret in Secrets Manager with rotation.
Tradeoff: Each interface endpoint is billed per AZ-hour plus data processed. In a hub-and-spoke network, centralise it in a shared-services VPC and use Route 53 private hosted zones instead of adding it to every spoke.
05AWS Network Security Manager is generally available (us-east-1)
Better: Define the baseline centrally and roll it out by OU with a canary account first. Document a break-glass exception process so incident responders aren't fighting the remediator.
NSM moves out of preview. It targets internet-facing ALBs and CloudFront distributions in front of EC2 fleets, pushes consistent WAF and Shield Advanced policy across accounts, and automatically remediates drift. It's GA in N. Virginia only for now, and Network Firewall support is "coming soon".
This is automation that makes changes in place, so treat it like an agent with write access to your edge. A bad central rule gets enforced everywhere, and auto-remediation will overwrite well-intentioned local hotfixes during an incident.
Anti-pattern: Hand-managed, per-account WAF rules on public ALBs, where half the accounts quietly drifted to "count" mode years ago.
Better: Define the baseline centrally and roll it out by OU with a canary account first. Document a break-glass exception process so incident responders aren't fighting the remediator.
Tradeoff: You trade local flexibility and a larger blast radius for consistency. With one Region at launch, check how it fits multi-Region control planes before standardising on it.
Secondary — agentic ops & FinOps tooling
06Amazon CloudWatch Omni brings the AWS DevOps Agent into incident investigation
Action: Pilot Omni on one EC2-backed service with good tagging and a known incident history. Replay two past incidents and score the agent's root-cause analysis against your postmortems before…
Omni discovers services, maps dependencies and surfaces golden metrics across accounts, Regions and even Azure. Engineers sign in through IAM Identity Center and don't need console access. The AWS DevOps Agent joins investigation sessions, correlates signals along the dependency graph and suggests next steps.
The design choice that matters is that the agent recommends and doesn't act. For EC2-heavy estates that keeps the blast radius at zero while you judge the quality of its root-cause analysis. It launched in three Regions: N. Virginia, Oregon and Ireland.
Action: Pilot Omni on one EC2-backed service with good tagging and a known incident history. Replay two past incidents and score the agent's root-cause analysis against your postmortems before letting it into the on-call rotation.
Tradeoff: Per-use pricing wasn't in the launch post, so model the cost before you enable it org-wide. Topology discovery is only as good as your tagging and tracing, and untagged Auto Scaling groups will show up as orphans.
07Billing and Cost Management adds a billing-context API built for agents
Action: Wire ListBillingViewSegments into your FinOps or rightsizing automation as a precondition check before it recommends Savings Plans or Reserved Instances. Grant it through a read-only role…
The new ListBillingViewSegments API tells you who pays and at what rates over a time window. It covers management vs member account, billing-group membership and Billing Conductor rate settings, split into effective-dated segments. It deliberately returns no cost or usage data.
This matters for any FinOps agent or chargeback pipeline that rightsizes EC2 or attributes Savings Plan coverage. Without billing context, an agent can recommend a commitment purchase in an account whose rates are overridden by Billing Conductor. It's a read-only API, so the risk of giving it to an agent is low.
Action: Wire ListBillingViewSegments into your FinOps or rightsizing automation as a precondition check before it recommends Savings Plans or Reserved Instances. Grant it through a read-only role scoped to the Billing API.
Tradeoff: It currently supports primary billing views only, so custom billing views still need your own mapping.
Tertiary — supporting services for EC2-centric designs
08EventBridge relaunches custom event buses: org-wide sharing, ordering and one-year replay
Action: For EC2 lifecycle automation that currently chains cross-account rules, prototype a single shared bus with ordering on. Use its replay to re-drive missed Spot-interruption or lifecycle-hook…
Why it's relevant to EC2: fleet lifecycle events (Auto Scaling lifecycle hooks, instance state changes, Spot interruption notices) are usually fanned out through per-account buses and fragile cross-account rules. A single shared bus with ordering and replay makes a central fleet-ops or DR controller much simpler to build.
The new bus supports RAM sharing, a Subscriber resource for filtering and routing, strict ordering, deduplication and up to a year of retention. It's in 14 Regions, and the existing product is now "Custom event bus – classic".
Action: For EC2 lifecycle automation that currently chains cross-account rules, prototype a single shared bus with ordering on. Use its replay to re-drive missed Spot-interruption or lifecycle-hook handlers.
Tradeoff: The pricing model is new (per data transferred, not per event), so re-model costs for chatty, small-payload fleets. It's also not in every Region yet, which matters if your DR Region isn't one of the 14.
09DynamoDB multi-Region strong consistency expands to 15 Regions and cross-continent setups
Better: Externalise that state to an MRSC global table and keep the EC2 tier stateless and immutable, so a Regional evacuation is a DNS or Global Accelerator change.
Why it's relevant to EC2: the hard part of an active-active EC2 application tier across Regions is the state, not the instances. MRSC gives you a zero-RPO session, entitlement or order store, so stateless EC2 fleets in each Region can take writes during a Regional failure.
The five new Regions bring the total to 15, and any three-Region combination is allowed (three replicas, or two replicas plus a witness), including across continents.
Anti-pattern: Session state or "sticky" data held on EC2 instance store or a single-Region RDS, behind a design that is labelled "multi-Region active-active".
Better: Externalise that state to an MRSC global table and keep the EC2 tier stateless and immutable, so a Regional evacuation is a DNS or Global Accelerator change.
Tradeoff: Strongly consistent writes wait on a cross-Region quorum. A cross-continent configuration adds noticeable write latency, so keep it for data that truly needs RPO 0.
10RDS for SQL Server: Multi-AZ now supported on Developer Edition
Better: Run a Multi-AZ Developer Edition instance in staging and trigger a failover (reboot with failover) as part of every release that touches data-access code.
Why it's relevant to EC2: many Windows/.NET estates run their app tier on EC2 against SQL Server. Until now, testing AG failover in non-production meant paying for Enterprise licensing or skipping the test. Developer Edition now supports Multi-AZ with Always On AGs for 2019, 2022 and 2025 Enterprise Developer, but not 2025 Standard Developer.
That means you can check whether your EC2 app tier's connection strings, retry logic and connection pools actually survive a failover before you find out in production.
Anti-pattern: Non-production databases that are single-AZ, so application failover handling is only ever exercised in production.
Better: Run a Multi-AZ Developer Edition instance in staging and trigger a failover (reboot with failover) as part of every release that touches data-access code.
Tradeoff: Developer Edition is licensed for development and test only, never production. A Multi-AZ standby also roughly doubles the instance cost, so turn it on for the environments where you run failover tests.