AWS Weekly Digest
Week of 14–20 September 2026
Burstable gets a refresh, the network gets a new front door, and a resilience improvement quietly breaks your root-login alarm.
Do this week
- Fix root-login detection. Confirm your CloudTrail metric filter covers Ohio and Oregon, then test it with a real root sign-in. It is a silently broken security control, and the change went live on 14 September.
- Inventory SSM Agent versions. Anything below 3.3.4851.0 with remote-host port forwarding available is a credential-theft path off your instances. Patch, then automate the patching.
- Pull 30 days of T3 credit and surcharge data. Split the fleet into “genuinely bursty, move to T8i” and “lying to itself, move to M8i or Graviton.” Check Savings Plans coverage before you move anything.
- Model Direct Connect flat-rate against twelve months of actual DTO — and take the port-pair regardless. The second port is included; single-homed Direct Connect no longer has a cost excuse.
Showing 8 of 12 changes tagged Operational Excellence
Showing 6 of 12 changes tagged Security
Showing 6 of 12 changes tagged Reliability
Showing 4 of 12 changes tagged Performance Efficiency
Showing 7 of 12 changes tagged Cost Optimization
Showing 2 of 12 changes tagged Sustainability
Primary lens — EC2 & IaaS compute
01EC2 T8i is GA — the burstable floor moves
Better: pull CPU credit balance and surcharge metrics for 30 days; anything sustained above baseline moves to M8i/C8i or Graviton, anything genuinely bursty moves T3 to T8i.
T8i lands on custom Intel Xeon 6 and sixth-gen Nitro cards in nano, micro, small and medium. AWS claims up to 30% better price-performance than T3, 70% more compute, 1.25x network bandwidth and 2.4x EBS bandwidth. The CPU credit model (Standard / Unlimited) is unchanged, so this is a drop-in swap rather than a new mental model. t8i.micro and t8i.small are Free Tier eligible.
The number that matters in most fleets is the EBS bandwidth. A large share of T3 pain is not CPU credits at all — it is small instances starved on EBS throughput during backups, log rotation or a package upgrade. 2.4x on that axis changes which workloads are viable on burstable at all.
Launch Regions: US East (N. Virginia, Ohio), US West (Oregon, N. California), Europe (Frankfurt, Ireland, London, Paris), Asia Pacific (Hyderabad, Malaysia, Mumbai, Seoul, Singapore, Sydney, Tokyo) and Canada (Central). On-Demand only at launch — Spot and Savings Plans are “coming soon.”
Anti-pattern: running steady-state production on t*.unlimited and treating the surcharge as invisible. Burstable in Unlimited mode with sustained above-baseline CPU is frequently more expensive than the equivalent M-family instance, and you pay for it in a line item nobody reads.
Better: pull CPU credit balance and surcharge metrics for 30 days; anything sustained above baseline moves to M8i/C8i or Graviton, anything genuinely bursty moves T3 to T8i.
Tradeoff: no Savings Plans coverage yet. If your T3 fleet sits under a Compute Savings Plan, migrating now converts covered spend into uncovered On-Demand spend and can raise your bill despite the better unit economics. Stage the migration, or wait for Savings Plans support before moving anything material.
02Multi-modal autoscaling: stop scaling on CPU alone
Better: keep CPU at 70% as the floor/fallback, add one target-tracking policy on a metric your on-call actually pages on, and set the metric Period to match the publish interval — a 5-minute period…
Not a launch — a Compute Blog piece, and the most directly useful thing published this week. The pattern layers three target-tracking signals on one Auto Scaling group: reactive infrastructure metrics (CPU, memory, network), an application metric that reflects business state (active sessions, queue depth, in-flight orders), and predictive scaling for cyclical demand.
The mechanic that makes this safe is worth memorising: with multiple target-tracking policies attached, the group scales out if any policy demands it, but scales in only when all policies agree. That asymmetry is what stops layered policies from oscillating, and it is why adding a second policy is far lower-risk than most people assume.
AWS’s worked example is the classic failure mode: concurrent sessions climbed while arrival rate stayed flat, CPU never moved, and CPU-only scaling sat still through 7,000+ rejected checkouts. The application-metric group ran roughly 22 instances at peak against 11 for the CPU-only baseline.
Anti-pattern: a single CPU target-tracking policy at 70% as the entire scaling strategy for a stateful or session-heavy tier. CPU is a proxy for load, not load.
Better: keep CPU at 70% as the floor/fallback, add one target-tracking policy on a metric your on-call actually pages on, and set the metric Period to match the publish interval — a 5-minute period on a 1-minute metric is where most “why didn’t it scale” post-mortems end up.
Tradeoff: roughly 2x the instances at peak in AWS’s example. You are explicitly buying headroom with money. Justify it against the cost of the rejected requests, not against the steady-state bill — and note that detailed CloudWatch monitoring is effectively required for sane scale-in, which is its own small charge.
03Elastic Beanstalk Cluster Mode — pooled EKS instead of an ASG per app
Better: pool within a trust and environment tier — one cluster per environment per team — and keep tier-1 services on dedicated capacity until you have per-namespace resource limits and network…
Cluster Mode runs many applications on pooled infrastructure backed by Amazon EKS in your account, instead of Beanstalk’s traditional dedicated environment — own EC2 instances, own ASG, own load balancer — per application. It accepts source code, a Dockerfile or an ECR image, and ships with event-driven autoscaling, OpenTelemetry instrumentation, Secrets Manager integration, automatic HTTPS via ACM and a GitHub Action. No charge for Cluster Mode itself; you pay for the EKS cluster and EKS Auto Mode capacity underneath.
If you have a long tail of small Beanstalk environments — internal tools, admin apps, one-endpoint services — each burning two t3.small instances and an ALB, the arithmetic here is brutal in Cluster Mode’s favour. The per-app ALB alone is usually the largest line item on those environments.
Standard Mode is not going anywhere and still carries the .NET, Node.js and Python experience. Available in all commercial Regions where Beanstalk runs.
Anti-pattern: pooling production and non-production applications into one cluster because the cost model rewards density. You have just merged the blast radius of your staging deploys and your revenue path.
Better: pool within a trust and environment tier — one cluster per environment per team — and keep tier-1 services on dedicated capacity until you have per-namespace resource limits and network policy actually enforced.
Tradeoff: this is Beanstalk’s promise (“you don’t need to know the infrastructure”) sitting on top of EKS (“you absolutely need to know the infrastructure”). When a pod is evicted or a node scales in badly at 3am, the abstraction is thinner than it looks and your team needs Kubernetes fluency it may not have been hired for. Budget for that, or stay on Standard Mode.
04ECS on EC2: Graviton in Express Mode, and S3 Files reaches the EC2 launch type
Tradeoff: S3 Files makes S3 look like a filesystem, and it is not one. Expect different latency, different consistency behaviour under concurrent writers, and a cost profile driven by request volume…
Two ECS items that matter if you run containers on EC2 capacity rather than Fargate.
Express Mode now supports ARM64 (18 Sep). You can select Graviton for new and existing Express Mode services from the console, CLI, SDK or IaC. AWS quotes up to 40% better price-performance versus x86. All commercial Regions plus GovCloud (US). The catch is the usual one: your image must actually be ARM-native, so this is a build-pipeline change (multi-arch manifests) before it is a runtime change.
S3 Files extends to the EC2 launch type (16 Sep). Previously Fargate and ECS Managed Instances only; now consistent across all three launch types. It mounts an S3 bucket into a task as a shared file system with normal POSIX semantics, built on EFS underneath — so legacy applications that expect a directory can read and write S3 data without a code change or a second copy of the data.
Tradeoff: S3 Files makes S3 look like a filesystem, and it is not one. Expect different latency, different consistency behaviour under concurrent writers, and a cost profile driven by request volume. Excellent for “we cannot modify this binary”; a poor substitute for the S3 API where you control the code. On Graviton: mixed-architecture ECS clusters are a real operational tax — capacity providers, AMIs and image tags all have to agree — so migrate a whole service, not half of one.
Secondary — VPC & networking
05PrivateLink Tunnel Endpoints — share a CIDR, not a service
Better: a tunnel endpoint scoped to the narrowest CIDR that contains only what the vendor needs — ideally a purpose-built /28 — shared via RAM so access is revocable as a single action rather than a…
The most architecturally interesting launch of the week. A new VPC endpoint type that gives private access to an entire network segment in another VPC or account. You define a Resource Configuration representing a CIDR range, share it through AWS RAM, and the consumer creates a tunnel endpoint that reaches into that range using GENEVE encapsulation.
Before this, sharing anything non-trivial with an external party meant a Resource Configuration per asset — fine for three databases, unworkable for a subnet full of them. The alternative was VPC peering or Transit Gateway, which means route-table entanglement, CIDR overlap negotiations and a far larger reachable surface than anyone intended. Tunnel endpoints give you the one-way, CIDR-scoped, RAM-governed shape that most vendor-access designs were faking with peering.
27 Regions at launch across the US, Canada, Europe, Asia Pacific, Africa, Mexico and South America. Priced as an hourly charge per tunnel endpoint plus per-GB data processed.
Anti-pattern: reaching for VPC peering to give a SaaS vendor access to two internal services, then discovering the peering is transitive-by-routing-mistake and the vendor account can reach your entire 10.0.0.0/8.
Better: a tunnel endpoint scoped to the narrowest CIDR that contains only what the vendor needs — ideally a purpose-built /28 — shared via RAM so access is revocable as a single action rather than a route-table archaeology exercise.
Tradeoff: a CIDR range is a coarser grant than a per-resource configuration, and it stays coarse as the subnet fills up. Anything you later launch into that range is reachable by default. Treat a shared CIDR as a security boundary with its own change control, not a convenience — and watch the per-GB processing charge, which makes this expensive for bulk data movement compared with an S3 handoff.
06Direct Connect flat-rate pricing on 10/100 Gbps dedicated connections
Better: take the port-pair now that the second port is included, terminate at two locations, and actually fail over to the VPN path in a scheduled game day. Resilience you have never exercised is a…
Dedicated 10 Gbps and 100 Gbps connections can now be bought as a single fixed monthly fee based on bandwidth and geographic scope, with data transfer out eliminated within the selected tier. Five geographic tiers run from same-metro to global. The previous model — port hours plus per-GB DTO — remains for everything else, including 1 Gbps and hosted connections.
The genuinely good part is buried: a port-pair gives you two dedicated connections on different devices or locations sharing the bandwidth, with the second connection at no additional cost. AWS has effectively removed the price penalty for not running a single-homed Direct Connect, which has been one of the most common “we know, but it is expensive” risk acceptances in enterprise landing zones.
All Direct Connect locations in all commercial Regions; China excluded. The announcement does not state an effective date for existing connections — confirm with your account team before you re-baseline anything.
Anti-pattern: a single dedicated Direct Connect, at one location, on one device, carrying production hybrid traffic — with the VPN backup untested since it was built.
Better: take the port-pair now that the second port is included, terminate at two locations, and actually fail over to the VPN path in a scheduled game day. Resilience you have never exercised is a diagram, not a control.
Tradeoff: flat-rate only wins if your egress is high and reasonably predictable. A connection provisioned for a quarterly bulk transfer that idles the rest of the time will almost certainly cost more flat-rate than pay-as-you-go. Model it against twelve months of actual DTO, per tier, before switching — and re-check when your traffic geography changes, because tier selection is where this goes wrong.
07Source IP preservation for SFTP behind an NLB
Tradeoff: PPv2 prepends a header the listener must understand. Turning this on without the receiving side parsing it produces a protocol-level failure, not a graceful degradation. Enable it in a…
Transfer Family SFTP servers fronted by a Network Load Balancer now preserve the real client IP using Proxy Protocol v2, instead of presenting the NLB’s private address. The true source IP flows through authentication and logging, so IP allow-lists, custom identity providers and audit records all see the client rather than the load balancer. Enabled per server via console, CLI or API; available in all Regions where Transfer Family runs.
Small launch, disproportionate value if you have ever had to explain to an auditor why every SFTP session in your logs appears to originate from 10.0.2.47. This is the generic NLB pattern — worth remembering that PPv2 is how you solve it for your own EC2-hosted TCP services too, not just Transfer Family.
Tradeoff: PPv2 prepends a header the listener must understand. Turning this on without the receiving side parsing it produces a protocol-level failure, not a graceful degradation. Enable it in a maintenance window, on one server first, and confirm your identity provider is reading the new field before you build allow-list rules on top of it.
Secondary — IAM, identity & security
08STS unifies session token size at 4,096 bytes — and finally tells you how full it is
Action: put a CloudWatch alarm on token utilisation at around 80% for your ABAC-heavy roles — particularly any role assumed by EC2 instance profiles carrying a lot of session tags. It is a cheap…
STS replaced its separate limits on token size and passed-in parameters (inline policies, managed policy ARNs, session tags) with one 4,096-byte boundary. More usefully, AssumeRole responses now return the token size and its utilisation as a percentage of the limit, logged to CloudTrail and published to CloudWatch. There is also a new optional API parameter for testing larger tokens up to the threshold.
If you have ever debugged an intermittent PackedPolicyTooLarge that only fires for users in many groups, you know why this matters. The failure was previously invisible until it happened, and it happened to your most-privileged users first because they carry the most tags and policies. Now it is a metric you can alarm on.
Commercial Regions, GovCloud (US) and the European Sovereign Cloud Region.
Action: put a CloudWatch alarm on token utilisation at around 80% for your ABAC-heavy roles — particularly any role assumed by EC2 instance profiles carrying a lot of session tags. It is a cheap alarm that prevents a whole class of 3am incident.
09Root user sign-in goes multi-Region — and quietly breaks your CloudTrail alarm
Action: move root sign-in detection to an organization trail with all-Region coverage, or extend the metric filter to all three Regions, then verify it by deliberately signing in as root and…
Root user sign-in now distributes across US East (N. Virginia), US East (Ohio) and US West (Oregon) instead of depending primarily on us-east-1. Routing is automatic; nothing changes about how anyone signs in. Good, overdue resilience work on one of the last genuinely single-Region control-plane dependencies.
Read this carefully. ConsoleLogin events for root are recorded in the Region that processed the sign-in. If your “alert on root login” detection is a us-east-1 CloudWatch metric filter — which is how almost every landing zone and CIS benchmark implementation built it — it now silently misses root logins processed in Ohio or Oregon. This is a resilience improvement that degraded a security control as a side effect.
Action: move root sign-in detection to an organization trail with all-Region coverage, or extend the metric filter to all three Regions, then verify it by deliberately signing in as root and confirming the alarm fires.
Tradeoff: none on the resilience itself — it is strictly better. The cost is a monitoring migration you did not ask for, and the failure mode is silent. Put it on this sprint, not the backlog.
10Two advisories worth a patch cycle — SSM Agent SSRF and TEAM privilege escalation
Better: an SSM Association that auto-updates the agent on a schedule, plus a Config rule or Security Hub control alarming on instances below your minimum agent version — so the next advisory is a…
CVE-2026-89049 — SSRF in SSM Agent remote-host port forwarding (published 10 Sep). Flagged here because it sits directly on the EC2 path and did not make the previous digest. An authenticated user holding port-forwarding permission can bypass destination restrictions, reach link-local endpoints and pull the instance role’s temporary credentials — then use that role from outside the instance. Every version before 3.3.4851.0 that supports remote-host port forwarding is affected.
Interim mitigation if you cannot patch the fleet immediately: restrict ssm:StartSession and limit AWS-StartPortForwardingSessionToRemoteHost to trusted principals only. This class of credential theft is exactly what IMDSv2 with hop limit 1 is designed to blunt — if your AMIs still allow IMDSv1, this advisory is your business case.
CVE-2026-86830 — privilege escalation in TEAM for IAM Identity Center (published 14 Sep). Temporary Elevated Access Management is an AWS sample solution, so it is only your problem if you deployed it — but plenty of enterprises did, and it sits by definition on your privileged access path. Authenticated application users could obtain unintended elevated access to managed accounts. No workaround; upgrade to 1.5.1 or later, and patch any fork you made of it.
Anti-pattern: treating SSM Agent as “AWS-managed, therefore patched.” The agent version on an instance is your responsibility.
Better: an SSM Association that auto-updates the agent on a schedule, plus a Config rule or Security Hub control alarming on instances below your minimum agent version — so the next advisory is a dashboard check, not a fleet-wide inventory exercise.
Secondary — storage & agentic ops tooling
11S3 Express One Zone adds 7 Regions — and a reminder of what “One Zone” means
Better: Express One Zone for regenerable data only — caches, intermediates, checkpoints you can recompute — with the durable copy in S3 Standard or One Zone plus a replication rule. If you cannot…
Now in Asia Pacific (Singapore, Sydney, Seoul), South America (São Paulo), US West (N. California), Canada (Central) and Europe (Paris) — 15 Regions in total. Single-digit-millisecond access, up to 10x faster than S3 Standard, with request costs up to 80% lower.
Relevant to an EC2-centric stack for one reason: co-locating an Express One Zone bucket in the same AZ as your compute removes both the latency and the cross-AZ data charge. For scratch space, shuffle data or a hot cache in front of a compute fleet, that combination is hard to beat. Pair it with a single-AZ placement group and you have a legitimately fast, legitimately cheap tier.
Anti-pattern: reading “80% cheaper requests” and migrating a production bucket that holds the only copy of something into a single-AZ storage class. One Zone means one Availability Zone: an AZ loss is data loss, not a failover.
Better: Express One Zone for regenerable data only — caches, intermediates, checkpoints you can recompute — with the durable copy in S3 Standard or One Zone plus a replication rule. If you cannot answer “what do we do if this AZ is gone” in one sentence, it does not belong in this class.
Tradeoff: the cheap requests are paid for with an availability and durability profile below S3 Standard, plus storage priced higher per GB. It wins on request-heavy, small-object, short-lived data and loses on everything else. Directory buckets also behave differently enough from general-purpose buckets that tooling and IAM patterns need re-testing rather than copying.
12Agentic ops this week: all read-and-recommend, none auto-remediate
Better: scope agent roles with permission boundaries and tag conditions, keep write paths behind an explicit human approval, and require every agent-initiated change to land as a normal, auditable…
Three items, and the useful observation is what they have in common — consistent with the DevOps Agent Slack integration from the previous digest, AWS is still shipping agents that investigate and propose rather than act. Blast radius stays with the human.
AWS Continuum for penetration testing — credential testing and accessible domain suggestions (18 Sep). Continuum authenticates into your application as a real user would and captures every domain reached during login, so you can validate credentials and confirm scope before a test runs. This is scope-definition tooling: it stops you burning a test cycle discovering the agent never got past the login page. Configuration and review are required up front — it does not decide its own scope.
CloudTrail analysis in Amazon Q Console (15 Sep). Natural-language querying against your trails, associated CloudWatch log groups and event data stores. Useful for exactly the questions that are tedious in Athena: who touched this IAM role, what changed in this VPC, which IP generated these errors. On-demand and read-only — you ask, it answers from your actual account activity.
Detected Anomalies widget in Billing and Cost Management dashboards (15 Sep). Cost anomalies now surface alongside budgets and usage, with 30/60/90-day look-back, filters on severity, service, account and Region, plus scheduled email, CSV and PDF export and cross-account dashboard sharing. No additional charge, all commercial Regions. Minor, but it moves anomaly detection from a tool people forget exists into the dashboard they already open.
Anti-pattern to watch for as these mature: granting an ops agent a broad standing role so it can “fix things faster.” An agent with ec2:* and no approval gate is an unreviewed change pipeline with a natural-language interface.
Better: scope agent roles with permission boundaries and tag conditions, keep write paths behind an explicit human approval, and require every agent-initiated change to land as a normal, auditable change record. Take the recommendations; keep the hands on the wheel.
Tradeoff: read-only agents are safe but do not reduce toil much — the human still executes. Expect pressure to grant write access as these tools prove useful. The moment to define your autonomy policy is now, while the tools are still advisory, not after the first agent-initiated change you cannot explain in a post-mortem.