AWS Weekly Digest
Week of 3–14 September 2026
No new instance family, but a strong week for guardrails: AMI allow-lists, cross-account EBS clones, and SSM finally telling you why an instance is unmanaged.
Do this week
- Start testing Amazon Linux 2027 now, not at GA. It ships SELinux enforcing by default. Run preview instances in permissive mode, harvest AVC denials for a fortnight, and write your policy modules before the deadline exists.
- Run the SSM unmanaged-instance diagnostic across the fleet. It will now tell you why each one is unreachable. Unmanaged instances are excluded from your patch-compliance denominator, which means that number is currently fiction.
- If you adopt AMI instance-type lists, deny-list rather than allow-list. An allow-list of today’s families silently blocks the next generation, breaks ASG instance diversification and degrades Spot capacity with no alarm anywhere.
- Re-check memory-bound workloads sitting on R8g. R9g/R9gd on Graviton5 reached GA in late August, just before this window, and is the current refresh target.
Showing 8 of 11 changes tagged Operational Excellence
Showing 7 of 11 changes tagged Security
Showing 6 of 11 changes tagged Reliability
Showing 4 of 11 changes tagged Performance Efficiency
Showing 5 of 11 changes tagged Cost Optimization
Primary lens — EC2 & IaaS compute
01Second-generation single-rack Outposts, GA
Better: put the durable state and the failover target in-Region, treat the Outpost as a latency/residency edge, and rehearse the degraded mode where the rack is unreachable but the business still has…
A self-contained 42U rack — compute, storage and networking in one unit — up to 2,688 vCPU and 100 TB of EBS. Instance coverage is x86 across three shapes: M7i/M8i general purpose, C7i/C8i compute-optimised, R7i/R8i memory-optimised, plus Bmn-sf2e / Bmn-cx2 / Bmn-cx3a for accelerated networking. This is the one to reach for when latency to a factory floor or a data-residency rule is what is actually driving the architecture, not preference.
Anti-pattern: calling one rack “highly available production.” A single rack is a single fault domain — one room, one power feed, one uplink path. It has no more independence than a single AZ, and rather less.
Better: put the durable state and the failover target in-Region, treat the Outpost as a latency/residency edge, and rehearse the degraded mode where the rack is unreachable but the business still has to run.
Tradeoff: capacity is fixed at order time. Bursting is a procurement cycle, not an API call — size for peak or design the overflow path into the Region up front.
02AMIs can now declare which instance types they support
Better: express the genuine constraint — usually architecture or a driver — as a deny-list of known-incompatible families, and give the list a named owner and a review date.
AMI owners can attach a supported list, an unsupported list, or both. A launch on a non-permitted type is blocked outright rather than booting into a broken instance. All Regions, no charge, opt-in — existing AMIs stay launchable on anything. The obvious win is the x86 AMI that someone points at a Graviton ASG: you now get a clean API error instead of half an hour of debugging why the instance is unreachable.
Anti-pattern: baking an allow-list of today’s instance types into your golden AMI pipeline. Eighteen months from now that list silently blocks the next generation, your ASG’s instance-type diversification quietly stops working, and Spot capacity gets worse with no alarm anywhere.
Better: express the genuine constraint — usually architecture or a driver — as a deny-list of known-incompatible families, and give the list a named owner and a review date.
Tradeoff: this turns a runtime failure into a launch failure, which is what you want — but Auto Scaling will now surface it as capacity it cannot fulfil. Test the restriction in a canary ASG before rolling it across the fleet, and make sure the launch-failure path actually alarms.
03Amazon Linux 2027 in public preview — SELinux enforcing by default
Better: run preview instances in permissive mode now, harvest AVC denials from the audit log for a couple of weeks, write the handful of policy modules you actually need, then flip to enforcing…
Kernel 7.1+, AWS-LC for crypto, refreshed toolchains and language runtimes, preview AMIs in all commercial Regions on both x86-64 and arm64, container base images on ECR Public. The headline for anyone with a real fleet is buried in the feature list: SELinux runs in enforcing mode out of the box, a change from AL2023.
That is the migration. Expect breakage from agents writing outside their expected paths, custom systemd units with unlabelled files, third-party EDR and monitoring, and anything doing creative things with ports or shared memory. None of it shows up in a smoke test; it shows up three weeks in, on one host, at 2am.
Anti-pattern: setenforce 0 as the migration strategy, or SELINUX=disabled baked into the golden AMI. You will have paid the upgrade cost and thrown away the only thing you got for it.
Better: run preview instances in permissive mode now, harvest AVC denials from the audit log for a couple of weeks, write the handful of policy modules you actually need, then flip to enforcing before GA rather than after.
Tradeoff: preview software — no production workloads, no support commitments. The cost of starting now is a non-prod ASG and some engineer-hours; the cost of starting at GA is discovering the same problems under a deadline.
04SSM now gives a real root cause for unmanaged EC2 instances
Better: turn on Default Host Management Configuration at the account or Organization level so SSM management is a property of the account, not of whoever built the launch template.
The diagnostic Automation used to check network connectivity and shrug at everything else. It now covers six more categories — IAM permissions, SSM Agent version, instance status checks, OS configuration, Default Host Management Configuration, and hybrid activation — and returns a specific cause with remediation steps instead of “unidentified.”
Worth more than it sounds. An unmanaged instance is an instance Patch Manager cannot reach, which means it is excluded from your compliance denominator rather than counted as non-compliant. Every fleet of size has a tail of these, and the tail is where the unpatched CVEs live. This turns “we have 40 unmanaged instances and nobody knows why” into a work queue.
Anti-pattern: resolving every IAM finding by bolting AmazonSSMManagedInstanceCore onto whatever instance profile is nearest, one instance at a time. You end up with dozens of drifting profiles and no way to reason about them.
Better: turn on Default Host Management Configuration at the account or Organization level so SSM management is a property of the account, not of whoever built the launch template.
Tradeoff: standard SSM Automation charges apply, so this is not free to run fleet-wide on a tight loop. Schedule it — weekly, or on an “instance unmanaged for >24h” trigger — rather than continuously.
05C8g reaches Taipei, New Zealand and GovCloud US-East; X2idn lands in Hong Kong
Tradeoff: a new family in a new Region does not mean deep capacity on day one. For Spot-heavy or large-scale-out workloads, diversify across families for the first few months and do not pin an ASG to…
Graviton4-based C8g adds Asia Pacific (Taipei), Asia Pacific (New Zealand) and GovCloud (US-East): 12 sizes including two bare metal, up to 50 Gbps network and 40 Gbps to EBS, up to 3x the vCPU and memory of C7g. X2idn — 3rd-gen Xeon, Nitro, SAP-certified for S/4HANA, BW and NetWeaver — arrives in Asia Pacific (Hong Kong).
Region expansions are easy to skim past, but they are what erodes the standing objection to standardising on Graviton: “we can’t, Region X doesn’t have it.” That list keeps shrinking. If Graviton adoption stalled on regional parity, it is worth re-running the inventory — the answer has probably changed.
Tradeoff: a new family in a new Region does not mean deep capacity on day one. For Spot-heavy or large-scale-out workloads, diversify across families for the first few months and do not pin an ASG to a single new type.
Secondary — EBS, VPC/networking & IAM
06EBS Volume Clones across accounts, with re-encryption on the way through
Better: always re-encrypt with a target-account CMK, run masking or subsetting immediately after attach, and make the standing RAM share a scoped, time-boxed one rather than a permanent grant on the…
Share the volume via AWS RAM, then the destination account creates a copy in the same AZ, optionally re-encrypting with a KMS key it owns. Works from unencrypted or CMK-encrypted sources; available everywhere Volume Clones is, including GovCloud, China and supported Local Zones. Console, CLI and SDK.
The practical use is seeding a test account from a production volume without the snapshot → copy → share → restore dance, and — more importantly — without the dev account ever holding a grant on the production KMS key.
Anti-pattern: cloning a production volume into a lower environment and treating the job as done. You have just moved customer data into an account with looser access control and, if you skipped the re-encrypt, extended the production key’s blast radius to every engineer with dev access.
Better: always re-encrypt with a target-account CMK, run masking or subsetting immediately after attach, and make the standing RAM share a scoped, time-boxed one rather than a permanent grant on the volume.
Tradeoff: the same-AZ constraint is real — this is not a cross-AZ or cross-Region seeding tool, and it is not DR. Snapshot copy still owns that job.
07Network health indicator now covers TGW inter-Region peering
Tradeoff: two of them. Synthetic monitors are billed per monitor plus the CloudWatch metrics, so scope them to paths that carry real traffic rather than blanketing the mesh. And the indicator’s scope…
CloudWatch Network Monitoring synthetic monitors can now tell you whether a performance problem on a path crossing a TGW inter-Region peering connection is AWS’s network or yours. Previously the indicator only covered Direct Connect paths. Publishes to CloudWatch for dashboards and alarms. All Regions except GovCloud and China.
If you run a multi-Region hub-and-spoke on TGW, this ends a recurring and unproductive incident-call argument. Put the indicator metric on the same dashboard as your application latency so the two are read together, not sequentially.
Tradeoff: two of them. Synthetic monitors are billed per monitor plus the CloudWatch metrics, so scope them to paths that carry real traffic rather than blanketing the mesh. And the indicator’s scope stops at the peering connection — a green indicator does not exonerate your route tables, NACLs, security groups or the appliance you inserted past that point. It narrows the search; it does not finish it.
08IAM condition keys for task CPU and memory on RunTask / StartTask
Better: encode the ceiling as a condition key in the permission boundary or SCP, where it is testable and auditable.
ecs:task-cpu and ecs:task-memory are now evaluated on RunTask and StartTask, not just at task-definition registration. All ECS Regions, no additional cost.
Included here because on ECS-on-EC2 this is a compute guardrail, not just a container one. An oversized task placement is what evicts other tasks, strands capacity on a host, and drives an ASG scale-out you did not budget for. Enforcing the ceiling at the launch API means it holds regardless of which path — pipeline, console, someone’s script — started the task.
Anti-pattern: treating “the team agreed to cap tasks at 4 vCPU” as a control. A convention in a wiki page is not enforced by anything and degrades the moment someone is under deadline pressure.
Better: encode the ceiling as a condition key in the permission boundary or SCP, where it is testable and auditable.
Tradeoff: a hard ceiling will eventually block a legitimate emergency scale-up at exactly the wrong moment. Scope the condition by cluster or tag rather than org-wide, and keep a break-glass role that is exempt, alarmed and reviewed after use.
09FIPS 140-3 endpoints over PrivateLink for S3 File Gateway
Better: move it onto the interface endpoint, then remove the egress route and let the absence of a path — rather than a policy document — be the control.
FIPS endpoints for File Gateway used to be reachable only over the public internet — an awkward position for the regulated workloads that need FIPS in the first place. NFS and SMB shares can now reach S3 through FIPS interface VPC endpoints. Requires gateway software 2.1.10+; eight Regions, including both GovCloud Regions.
Anti-pattern this retires: the compliance-mandated workload whose storage traffic exits via NAT gateway to a public endpoint, with a security-group rule and a lot of documentation standing in for an actual network boundary.
Better: move it onto the interface endpoint, then remove the egress route and let the absence of a path — rather than a policy document — be the control.
Tradeoff: interface endpoints bill hourly per AZ plus per-GB processed. For a high-throughput gateway that usually still beats NAT gateway data processing, but run the numbers — and remember you need an endpoint per AZ to avoid a cross-AZ hop and a single-AZ dependency.
Agentic ops tooling
10DevOps Agent gains bidirectional Slack — investigate from the incident channel
Action — autonomy and blast radius: as announced this is investigate-and-recommend, not auto-remediate. The agent reads telemetry and proposes; a human executes. That is the right default for…
@mention the agent in a connected private Slack channel and ask about resources, metrics, alarm state, deployment history or incident patterns across AWS, multicloud and on-prem. The whole investigation — agent findings, human input, recommended actions — stays in one thread. All commercial Regions where DevOps Agent is supported.
Action — autonomy and blast radius: as announced this is investigate-and-recommend, not auto-remediate. The agent reads telemetry and proposes; a human executes. That is the right default for something sitting in an incident channel, and it means blast radius is bounded by the agent’s read permissions rather than by its judgement. Confirm that when you wire it up: the role should be read-mostly, and anything mutating should stay out of it.
Two things to check before rollout. First, Slack channel membership becomes an access boundary on your operational telemetry — “private channel” is a Slack construct, not an IAM one, and channel membership drifts far faster than an IAM policy does. Audit who is in the channels you connect, and re-audit. Second, an action recommended in a thread and then run by hand leaves no change-management record unless someone writes one. Make the thread link a required field on the change ticket rather than pretending the ticket will happen on its own.
Tradeoff: lowering the friction of asking also lowers the friction of acting on a plausible-sounding answer at 3am. Treat agent output as a strong hypothesis to verify in the console, not as a finding.
Adjacent — relevant to an EC2-centric design
11Lambda Managed Instances: Graviton5 support and a 90-minute async timeout
Action — watch the 90 minutes: a longer timeout is also a longer failure. A poison-pill message can now burn 90 minutes of instance time per attempt, times your retry count, before anything gives up…
Why this is in an EC2 digest: Lambda Managed Instances is EC2 capacity — C9g/C9gd/M9g/M9gd here — billed on EC2 economics, with Lambda owning instance lifecycle, OS patching, routing, load balancing and scaling. For a batch or queue-worker fleet currently running as an ASG plus SQS plus your own patching, it is a genuine alternative worth costing, not a serverless sidebar.
Two changes landed the same day. Graviton5 instance types are now selectable, AWS citing up to 25% better compute performance than the Graviton4 generation. And the timeout for asynchronous and event-source-mapping invocations goes from 15 minutes to 90 — a 6x jump that removes the step-function-shaped workaround from a lot of media transcoding and long-calculation designs. Synchronous invocations stay capped at 15 minutes.
Action — watch the 90 minutes: a longer timeout is also a longer failure. A poison-pill message can now burn 90 minutes of instance time per attempt, times your retry count, before anything gives up — a quiet and expensive way to discover you never configured a dead-letter queue. Before raising any timeout: set maximum retry attempts explicitly, wire a DLQ, and alarm on invocation duration approaching the ceiling rather than only on errors.
Tradeoff: pinning instance types in the capacity provider gives predictable performance and benchmarks that stay comparable; leaving it on default lets Lambda move you onto newer silicon automatically. Pick deliberately — the default is the better call for most fleets, but not if you have a certification or a fixed performance baseline.