AWS Weekly Digest
Week of 26 October–1 November 2026
A quiet week for EC2 itself, but one Auto Scaling default worth flipping today, plus sharper tools for resilience testing, egress control and identity automation.
Do this week
- Turn on Launch Before Terminate at account level, after checking quotas and IP headroom for groups where MaxSize equals DesiredCapacity.
- Run Resilience Hub's AZ recovery test against one production-like EC2 workload, with stop conditions set.
- Put Network Firewall's Resolved IP Validation in Alert mode on one egress VPC and review DnsUnresolvedFlows after 24 hours.
- Find your biggest log buckets with no lifecycle rule and start Storage Class Analysis on them.
Showing 8 of 13 changes tagged Operational Excellence
Showing 5 of 13 changes tagged Security
Showing 5 of 13 changes tagged Reliability
Showing 3 of 13 changes tagged Performance Efficiency
Showing 2 of 13 changes tagged Cost Optimization
Showing 1 of 13 changes tagged Sustainability
Primary lens — EC2 & IaaS compute
01EC2 Auto Scaling: Launch Before Terminate as an account-wide default
Better: Turn on Launch Before Terminate at account level, then make sure your health checks are real (ELB health checks plus a meaningful grace period) so the new instance is truly ready before the…
You set it once with the new PutAccountSetting API (read it back with DescribeAccountSettings), and from then on every group in the account launches the replacement, waits for it to pass health checks, and only then terminates the old instance. That covers instance refreshes, AZ rebalancing, unhealthy-instance replacement and max-instance-lifetime recycling. It's available in all Regions at no extra cost.
This matters most for small groups. In a two- or three-instance group, terminate-first replacement briefly cuts serving capacity by a third or a half, exactly when you're already dealing with an unhealthy node or a rollout. Launch-first keeps capacity whole.
Anti-pattern: Relying on per-group settings (or the old terminate-first default) for small production groups, so a routine instance refresh quietly drops you below the capacity your SLO assumes.
Better: Turn on Launch Before Terminate at account level, then make sure your health checks are real (ELB health checks plus a meaningful grace period) so the new instance is truly ready before the old one leaves.
Tradeoff: You briefly run one extra instance per replacement, so check vCPU/On-Demand quotas, subnet IP headroom and any group where MaxSize equals DesiredCapacity. Licence-bound or stateful singletons may still need terminate-first.
Observability & operations
02Full-stack observability for AWS Outposts with Systems Manager, CloudWatch and EventBridge
Better: Alarm on ConnectedStatus and CapacityExceptions, route AWS Health events to OpsCenter, and schedule patching for windows when the link is healthy.
The useful part for EC2 teams is the metric checklist: service-link health (ConnectedStatus, VifBgpSessionState, VifConnectionStatus), CapacityExceptions for instance capacity, EBS and S3 on Outposts free-space metrics, and an EventBridge rule on aws.health events for the OUTPOSTS service that opens an OpsCenter OpsItem automatically.
Two caveats from the post deserve a place in your runbook: Patch Manager fails when the service link is degraded, and on-rack EBS capacity is finite, so capacity alarms aren't optional.
Anti-pattern: Treating Outposts (or any on-prem extension) like a Region and running it with no alarms on the service link or local capacity.
Better: Alarm on ConnectedStatus and CapacityExceptions, route AWS Health events to OpsCenter, and schedule patching for windows when the link is healthy.
03Amazon Managed Grafana 13.2 adds PromQL queries over CloudWatch metrics
Action: Upgrade a non-production Grafana workspace to 13.2 and check that existing CloudWatch dashboards and alert rules still render before upgrading production.
If your EC2 fleet already ships metrics to CloudWatch via OTLP, this lets teams that think in PromQL build dashboards without standing up a separate Prometheus store. The in-place upgrade avoids rebuilding workspaces, though dashboards and plugins should still be tested in a non-production workspace first.
Action: Upgrade a non-production Grafana workspace to 13.2 and check that existing CloudWatch dashboards and alert rules still render before upgrading production.
Tradeoff: Two query languages over the same metrics can split team conventions. Pick one per dashboard family and document it.
04Resilience Hub adds FIS-powered recommended resilience tests
Better: Run the AZ recovery test on a schedule with stop-condition alarms, and treat a failed result as a release blocker.
For EC2 workloads, the dependency validation test uses aws:ssm:send-command to inject faults on instances, so the SSM Agent and an IAM service role are prerequisites. Tests run from 1 minute to 12 hours (30 minutes by default) against up to 10 dependencies, and each run produces a report.
The value is turning 'we think we're multi-AZ' into a repeatable, evidence-backed result. Success and stop-condition alarms are capped at five each per configuration, so choose them carefully.
Anti-pattern: Calling a deployment 'production' because it's in two AZs, without ever proving it survives losing one.
Better: Run the AZ recovery test on a schedule with stop-condition alarms, and treat a failed result as a release blocker.
Tradeoff: Fault injection in shared accounts has real blast radius. Start in non-production, scope targets with tags, and always set stop conditions. Log ingestion and storage charges apply.
05AWS Backup: restore testing for Redshift and cross-account backup in the European Sovereign Cloud
Better: Add restore testing plans for EC2 and EBS recovery points (by tag), with validation, and track restore duration against each workload's RTO.
Neither launch is about EC2 directly, but both extend the same pattern you should already use for EC2 and EBS: scheduled restore tests that measure restore time against RTO, and organisation-wide backup policies managed from a delegated admin account rather than per-account plans. If your EC2 tier depends on a Redshift warehouse, you can now prove the whole stack restores, not just the instances.
The sovereign-cloud update follows on from the cross-account ESC announcement (29 Oct) and brings that Region in line with commercial Regions.
Anti-pattern: Backups that have never been restored, so the first real restore test happens during an incident.
Better: Add restore testing plans for EC2 and EBS recovery points (by tag), with validation, and track restore duration against each workload's RTO.
Networking & egress security
06Route 53 Resolved IP Validation for AWS Network Firewall
Better: Enable Resolved IP Validation in Alert mode for a day, review DnsUnresolvedFlows, then switch to Drop and block non-Resolver DNS from your workload subnets.
The feature launched on 21 October; this week's deep-dive post is the practical guide. It needs DNS through Route 53 Resolver, a DNS Firewall rule group associated with the VPCs, and the policy setting enabled before you add aws_route_53_resolved_domain rules. The feature itself is free; standard DNS Firewall rule charges apply.
Watch the edge cases: hardcoded-IP destinations need bypass ranges, alternative resolvers (DoH, DoT, direct port 53) must be blocked or they defeat the check, and traffic routed to a firewall endpoint in a different AZ fails validation. The DnsUnresolvedFlows metric shows what's failing. GovCloud and China Regions aren't supported.
Anti-pattern: Egress control that only filters HTTP/HTTPS by SNI, leaving SSH and SFTP open to any IP, or that trusts SNI headers a compromised instance can forge.
Better: Enable Resolved IP Validation in Alert mode for a day, review DnsUnresolvedFlows, then switch to Drop and block non-Resolver DNS from your workload subnets.
Tradeoff: Tight coupling to Route 53 Resolver and AZ-symmetric firewall routing. Asymmetric inspection designs need reworking first.
Identity & access
07IAM Identity Center's Identity Store now emits change events to EventBridge
Action: Create an EventBridge rule for membership changes on groups mapped to privileged EC2 or network permission sets, and send them to your security alerting channel.
This replaces polling scripts for joiner-mover-leaver automation. Typical uses: a Lambda that revokes Session Manager access or tags owned resources when someone leaves a group, SIEM alerts on admin-group changes, and an audit trail of who was added to the groups that hold EC2 permission sets.
Action: Create an EventBridge rule for membership changes on groups mapped to privileged EC2 or network permission sets, and send them to your security alerting channel.
08IAM Identity Center supports cross-Region trusted identity propagation
Better: Where the services support trusted identity propagation, use it, and keep role-based access for machine identities such as EC2 instance profiles.
Previously, multi-Region designs often fell back on broad shared IAM roles once a request crossed Regions, which loses the per-user trail. This keeps individual identity in the logs across Regions at no extra cost. It's most relevant to data and analytics access, but it removes a common excuse for coarse roles in multi-Region setups.
Anti-pattern: Shared, broadly scoped IAM roles used purely because a service lives in another Region, leaving CloudTrail unable to say which person did what.
Better: Where the services support trusted identity propagation, use it, and keep role-based access for machine identities such as EC2 instance profiles.
Storage & cost
09Evidence-based S3 lifecycle rules at petabyte scale
Better: Prove access patterns with Storage Class Analysis, then add transition and expiration rules, plus request-metric alarms to catch unexpected retrieval spikes.
This matters to EC2 teams because instance and application logs, AMI-adjacent artefacts and backups often land in S3 buckets nobody lifecycles. The approach: use Storage Lens groups to find large buckets with no lifecycle rule, confirm cold access with 30+ days of Storage Class Analysis, then transition objects over 128 KB at a proven age (90 days in the example).
Know the traps: Glacier Instant Retrieval has a 90-day minimum storage charge and a 128 KB minimum billable size, and retrieval fees can wipe out savings on data that turns out not to be cold. The 70% figure is specific to that workload.
Anti-pattern: Log buckets fed by EC2 fleets that grow forever in S3 Standard, with no lifecycle or expiration rule.
Better: Prove access patterns with Storage Class Analysis, then add transition and expiration rules, plus request-metric alarms to catch unexpected retrieval spikes.
10DataSync Enhanced mode supports FSx for Windows File Server and FSx for NetApp ONTAP
Better: Use DataSync tasks with verification enabled, then decommission the helper instance.
For Windows-on-EC2 estates, this is a cleaner path for moving file shares into FSx (or between FSx file systems) than robocopy jobs running on a helper instance. You get managed scheduling, verification and CloudWatch reporting instead of scripts on a box someone has to remember to patch.
Anti-pattern: A long-lived 'migration' EC2 instance running hand-built copy scripts with no monitoring, left running after the move.
Better: Use DataSync tasks with verification enabled, then decommission the helper instance.
Agentic AI ops
11AWS DevOps Agent: tracing failures across Terraform state boundaries, plus Nubank's DR automation
Action: Make sure CloudTrail and alarm coverage are good enough for an agent to reason over (cross-stack ownership tags help), and keep human approval on any agent-proposed infrastructure change.
In the Terraform walkthrough, a security group egress change in a networking stack breaks an application path in another stack. The agent correlates the alarms, maps the dependency, finds the change in CloudTrail and drafts a fix that an engineer reviews with terraform plan before applying. The sample code is explicitly not production-ready.
In the Nubank case study (28 Oct), FIS injects the faults and the agent writes the report from metrics, logs and alerts. The figures are Nubank's own. What's automated here is investigation and reporting; the change itself still goes through human review.
Action: Make sure CloudTrail and alarm coverage are good enough for an agent to reason over (cross-stack ownership tags help), and keep human approval on any agent-proposed infrastructure change.
Tradeoff: Autonomy versus blast radius: read-only investigation is low risk, but an agent role with write access across stacks is a high-value target. Scope its IAM role to read-only and note that CloudTrail records the automation role, not the engineer behind it.
Tertiary — Lambda & orchestration
12Lambda Managed Instances gets SOCI lazy loading for container images
Better: Benchmark the job on Lambda Managed Instances with a SOCI index, and keep EC2 only where you need OS-level control or sustained full utilisation.
Why it matters to an EC2-centric architect: Lambda Managed Instances runs functions on EC2 capacity in your account, which makes it a real alternative to a small always-on fleet for steady but spiky workloads. Large container images were a weak spot; SOCI narrows the startup gap. Push a SOCI index to ECR with a tag like my-function:v1-soci, point the function at it and publish a version.
'Up to 70%' is a ceiling, and it applies only to container images on Managed Instances, not standard Lambda.
Anti-pattern: Always-on EC2 instances running a large containerised job that only does real work a few times an hour.
Better: Benchmark the job on Lambda Managed Instances with a SOCI index, and keep EC2 only where you need OS-level control or sustained full utilisation.
Tradeoff: Versus plain EC2: less patching and scaling work, but less control over the OS and runtime, Lambda-specific limits and deployment model, and some lock-in. At sustained high utilisation, Savings Plan-covered EC2 is usually still cheaper.
13Step Functions workflows can now be used as tools by AI agents
Better: Expose bounded Step Functions runbooks as the agent's tools, each with least-privilege permissions and a human approval step for destructive actions.
Why it matters: this is the safer way to let an agent operate EC2. Instead of giving an agent broad EC2 and SSM permissions, wrap approved runbooks (stop or resize an instance, run a Patch Manager baseline, rotate an AMI) in Step Functions with their own narrowly scoped role, validation steps and approval gates, and expose only those workflows.
Anti-pattern: Giving an agent or Lambda execution role ec2:* and ssm:* so it can 'fix things' directly.
Better: Expose bounded Step Functions runbooks as the agent's tools, each with least-privilege permissions and a human approval step for destructive actions.
Tradeoff: Versus scripts on an EC2 ops box: more moving parts and per-transition cost on Standard workflows, but far better audit, retries and guardrails.