AWS Weekly Digest
Week of 28 Sep–4 Oct 2026
A quiet week for new EC2 silicon. The action is in guardrails, agentic remediation and closing visibility gaps.
Do this week
- Check that EC2 Runtime Monitoring covers every Auto Scaling and Spot replacement, now that its cost sits inside Security Hub.
- Replace any detect-and-re-enable Lambda guardrails with a root-level GuardDuty declarative policy.
- Enable a secondary IAM Identity Center Region that matches your DR Region, and test sign-in from it.
- Look for budget email subscribers created since 30 Sep that haven't been verified, or move alerts to SNS.
Showing 8 of 12 changes tagged Operational Excellence
Showing 8 of 12 changes tagged Security
Showing 4 of 12 changes tagged Reliability
Showing 3 of 12 changes tagged Performance Efficiency
Showing 4 of 12 changes tagged Cost Optimization
Primary lens — EC2 & IaaS compute
01GuardDuty Runtime Monitoring for EC2 now billed inside Security Hub Threat Analytics
Better: Enable it at the org level with automated agent management so every launched instance — including ASG and Spot replacements — is covered.
Runtime Monitoring (EC2, EKS, ECS on Fargate) is now folded into the Security Hub Threat Analytics plan. If Security Hub is enabled in an account/Region, you stop seeing separate GuardDuty Runtime Monitoring line items; detection coverage, finding types and the GuardDuty security agent on your instances are unchanged and need no reconfiguration.
For EC2 fleets this mostly removes a reason teams gave for leaving runtime monitoring off on non-prod or bursty Auto Scaling groups: the cost is now a single Security Hub usage type that is easier to forecast and allocate.
Anti-pattern: Runtime monitoring enabled only on a hand-picked set of "important" instances, so ASG replacements launch unmonitored.
Better: Enable it at the org level with automated agent management so every launched instance — including ASG and Spot replacements — is covered.
Tradeoff: Billing consolidation is not a price cut. Check Cost Explorer for a full month before claiming savings, and note there is no new free trial for Runtime Monitoring.
Agentic AI ops — acting on EC2, VPC, IAM and cost
02AWS Well-Architected Agent enters preview
Action: Point it at one EC2-heavy workload's IaC repo and treat its output as PR suggestions, not runbooks to execute directly.
An AI agent that correlates metrics and application topology against Well-Architected best practices and returns recommendations ranked by impact and effort. It analyzes Terraform, CDK and CloudFormation and proposes IaC diffs, and it ships fixes as SSM runbooks, CLI scripts or guided console walkthroughs.
What's automated: discovery, multi-pillar tradeoff analysis and generating the fix. What isn't: execution. A human still approves and runs the change. The agent runs in us-east-1, us-east-2 and us-west-2, workloads can be onboarded from any commercial Region, and it requires an AWS Support plan. Pricing hasn't been published.
Action: Point it at one EC2-heavy workload's IaC repo and treat its output as PR suggestions, not runbooks to execute directly.
Tradeoff: Blast radius: the SSM runbooks it generates run with whatever role you give Automation. Scope that role to the workload, and require change-calendar plus approval steps. Otherwise a "right-size" recommendation can turn into a fleet-wide stop/start.
03Security Hub remediation plans group exposures by root cause
Action: Wire remediation plans into your ticketing flow first; only let an agent auto-apply fixes for low-risk, reversible classes (e.g. tagging, flow-log enablement).
Security Hub now groups related exposure findings that share a root cause, such as one overly permissive policy or one misconfigured setting, into a single plan. Each plan carries a priority, an impact assessment and fix steps in CLI, Terraform, CloudFormation, Python or CDK. It's included in the Essentials plan at no extra cost, in all Security Hub Regions.
AWS explicitly positions the API for AI agents to consume plans and automate fixes. That's the agentic angle: fewer findings to triage, and a machine-readable fix that a DevOps or Security Agent can apply.
Action: Wire remediation plans into your ticketing flow first; only let an agent auto-apply fixes for low-risk, reversible classes (e.g. tagging, flow-log enablement).
Tradeoff: Fixing one shared root cause, like a security group or an IAM policy used by many instances, has a wide blast radius. Auto-remediating an SG rule can cut off production traffic, so stage it behind canary accounts.
04Amazon DevOps Guru enters sunset (end of support 30 Sep 2027)
Better: Run CloudWatch anomaly-detection alarms alongside it now, and retire DevOps Guru once the alarms have proved themselves on real incidents.
AWS's quarterly availability update puts DevOps Guru into sunset with end of support on 30 September 2027. Also in the update: Infrastructure Composer's standalone console ends on 7 December 2026, and Managed Blockchain and Backint Agent for SAP ASE are sunsetting. Nothing in the core EC2, VPC, ELB, EBS or IAM services is affected.
If you use DevOps Guru for EC2/ASG anomaly detection, the obvious successors are CloudWatch anomaly detection and alarms, and AWS DevOps Agent (GA earlier this year) for incident investigation.
Anti-pattern: Treating a sunset notice as a 2027 problem and leaving DevOps Guru as the only anomaly signal on production fleets.
Better: Run CloudWatch anomaly-detection alarms alongside it now, and retire DevOps Guru once the alarms have proved themselves on real incidents.
Tradeoff: DevOps Agent investigates incidents, but it doesn't do continuous baselining the way DevOps Guru did. You still need explicit alarms to page someone.
Security, IAM & governance
05GuardDuty enablement enforced through Organizations declarative policies
Better: Use a declarative policy at the root, with OU overrides only where there is a documented reason.
GuardDuty can now be enabled through AWS Organizations declarative policies applied at the root, an OU or an individual account, with Region-specific overrides. Once a policy sets enablement, the console and API can't override it, so a member-account admin can no longer turn GuardDuty off. It's available in all commercial and GovCloud (US) Regions.
Anti-pattern: A security baseline that relies on a Lambda function re-enabling GuardDuty after someone disables it.
Better: Use a declarative policy at the root, with OU overrides only where there is a documented reason.
Tradeoff: Declarative enforcement also blocks legitimate break-glass changes. Document how the delegated admin changes policy during an incident.
06IAM Identity Center multi-Region support expands to opt-in Regions
Better: Enable a second Identity Center Region aligned with your DR Region, and test console/CLI access from it during game days.
Identity Center replicates identities, entitlements and configuration from the primary Region to additional Regions. If the primary Region goes down, users keep access to their AWS accounts through the permissions already provisioned. Support now extends to opt-in Regions and within GovCloud (US) and China. It requires a multi-Region customer-managed KMS key.
Anti-pattern: A multi-Region EC2 DR design whose operators can only sign in through an Identity Center instance in the Region that just failed.
Better: Enable a second Identity Center Region aligned with your DR Region, and test console/CLI access from it during game days.
Tradeoff: It adds a multi-Region KMS key to manage and audit. Entitlement changes made during a primary-Region outage may be limited, so keep IAM break-glass users or roles too.
07Secrets Manager console surfaces posture recommendations
Better: Retrieve secrets at boot through the instance role, with rotation on and a customer-managed KMS key, and use these recommendations to find the stragglers.
The console now flags secrets with no rotation configured and secrets encrypted with the default service key instead of a customer-managed KMS key, along with other configuration improvements. It's free, in all commercial Regions.
Anti-pattern: Database credentials baked into AMIs, user data or .env files on EC2 instances.
Better: Retrieve secrets at boot through the instance role, with rotation on and a customer-managed KMS key, and use these recommendations to find the stragglers.
Tradeoff: A customer-managed key gives you control and auditability, but it adds KMS request cost and key-policy complexity. Rotation needs app-side support for credential refresh.
08CloudTrail Event Coverage shows data-plane logging gaps
Action: Use it to confirm data events are on for the S3 buckets your EC2 apps read from and write to, then lock in the settings with an org trail and advanced event selectors.
A new console view shows, per account and across the organization, which services and resource types have data-event logging on and which have it off, for example S3 GetObject and PutObject. It's available in all commercial Regions. AWS hasn't published the full list of supported data-event sources.
Action: Use it to confirm data events are on for the S3 buckets your EC2 apps read from and write to, then lock in the settings with an org trail and advanced event selectors.
Tradeoff: Data events are billed per event, so enable them selectively with advanced event selectors rather than turning on everything.
Networking & cost
09DNS analytics and insights for Route 53 Global Resolver and DNS Firewall
Action: Add a per-VPC alarm on DNS Firewall blocks. A sudden spike from an EC2 subnet is one of the cheapest early signals of a compromised instance trying to reach C2 domains.
A new Analytics tab adds CloudWatch metrics, Contributor Insights, metric filters and alarms for DNS query patterns and DNS Firewall rule hits. AWS's example: alarm when blocked queries for a VPC exceed 10 per hour. Standard CloudWatch pricing applies.
Action: Add a per-VPC alarm on DNS Firewall blocks. A sudden spike from an EC2 subnet is one of the cheapest early signals of a compromised instance trying to reach C2 domains.
Tradeoff: Contributor Insights and high-cardinality metrics can get expensive on busy resolvers, so start with block counts per VPC.
10AWS Budgets requires email verification for new subscribers
Action: If your IaC creates budgets with team distribution lists, have someone confirm the verification email after each deploy. Otherwise new budget alerts for EC2 spend silently go nowhere.
Email addresses added to budget notifications from 30 September 2026 onward only start receiving alerts after the recipient clicks a verification link. Existing subscribers are unaffected. The console shows verification status and has a resend option. It isn't available in GovCloud or China.
Action: If your IaC creates budgets with team distribution lists, have someone confirm the verification email after each deploy. Otherwise new budget alerts for EC2 spend silently go nowhere.
Tradeoff: The verification link opens the AWS console, so shared mailboxes need a member with console access. SNS-based subscribers avoid this.
Supporting services (tertiary)
11Aurora and RDS add AMD-based R8a (and RDS M8a) instances
Action: Benchmark a read replica on R8a against your current class before switching the writer over. One vCPU per core means you may be able to drop a size.
R8a database instances map each vCPU to a physical core, with up to 75 Gbps network and 60 Gbps EBS bandwidth. They support Aurora PostgreSQL/MySQL and RDS for PostgreSQL, MySQL and MariaDB in 9 Regions. RDS also gets M8a.
Why it matters for EC2-centric stacks: if your app tier already runs on the 8th-gen AMD family, the database tier can now match it. You get one performance baseline and one Savings Plans/RI strategy across tiers.
Action: Benchmark a read replica on R8a against your current class before switching the writer over. One vCPU per core means you may be able to drop a size.
Tradeoff: Regional availability is narrower than R7g/R8g, and Reserved Instances don't move between instance families.
12AWS Health version catalog for software lifecycle
Action: If you have the right support plan, feed the version catalog API into your upgrade backlog for RDS engines and EKS versions.
The catalog is a central place to see supported versions and end-of-life timelines, starting with RDS, EKS and Lambda. It's in the Health Dashboard for everyone. API access requires Business Support+, Enterprise or Unified Operations. It doesn't cover EC2 AMIs or operating systems yet.
It's relevant here because the managed databases and runtimes around your EC2 tier are where surprise forced upgrades come from. Pull the API into your upgrade planning instead of waiting for per-account emails.
Action: If you have the right support plan, feed the version catalog API into your upgrade backlog for RDS engines and EKS versions.
Tradeoff: API access is gated on the support tier, and AMI and OS lifecycle tracking still needs your own pipeline (e.g. EC2 Image Builder plus SSM inventory).