The week of 10 August was about AWS taking over decisions that platform teams used to make by hand, and two of them deserve a second look before you accept the default. EC2 application status checks let EC2 itself probe an HTTP endpoint on your instance and feed the result to Auto Scaling, and IAM role manager went GA, creating the IAM roles a service needs while you click through its console. Also this week: ACM put dates on the end of email validation, and MSK learned to migrate a cluster from ZooKeeper to KRaft in place. No AWS Transform launch landed this week; the modernization items were the MSK one and a quieter Elastic Disaster Recovery fix.

EC2 application status checks: health without a load balancer

Until now EC2 had two status checks: system (the host) and instance (the guest OS). The new application status check adds a third layer. You define a protocol, port and path plus the response codes that count as healthy, associate the check with instances by ID or by tag, and EC2 sends an HTTP or HTTPS request every 60 seconds and reports the result next to the other two. Auto Scaling groups can replace instances that fail it. All commercial Regions and GovCloud (US).

The obvious question is why you would want this when the ALB target group already health-checks the same path. The answer is every instance that is not behind a load balancer: workers pulling from SQS, schedulers, a Docker host whose daemon died while the instance kept answering ICMP. Those boxes today are "healthy" by every signal EC2 has, and the on-call learns otherwise from a customer. The failure mode to design for is the opposite one: a health endpoint that depends on a downstream (a database, a cache) will take the whole fleet out when the downstream blips, because the ASG will replace instances that were fine. Keep the probed path shallow, and tag-based association means a tag typo can silently leave half the fleet unchecked, so audit with aws ec2 describe-instance-status after rollout.

IAM role manager: convenient, and the Lambda default is broad

Role manager watches what you set up in a supported console (six at launch, Lambda and EventBridge among them) and either creates a default role or reuses an existing one in the account that already fits, through the new AcquireRole API matched against AWS managed role templates. The roles are ordinary IAM roles you fully control, it is one account-level setting in the IAM console, and it is enabled by default in accounts created with the new AWS experience. Not available in GovCloud (US) or China.

The detail that should drive your decision is in the security blog post: because a Lambda function's permissions cannot be known before the code exists, the role it gets carries PowerUserAccess, which excludes IAM, Organizations and account settings but includes everything else. AWS's answer is to run IAM Access Analyzer later and narrow it. That is a reasonable developer-sandbox story and a bad production one, because "later" is the step that never ships. If your accounts already provision roles through Terraform or CDK, turn it off, and use an SCP to keep member accounts from turning it back on; the post confirms SCPs can gate it. If you want it on for sandboxes, pair it with the same week's account access manager, which assigns IAM roles in an account to Identity Center users and groups, so at least the humans holding those broad roles are federated.

ACM email validation ends in 2027, and the dates are staggered

Following the CA/Browser Forum's November 2025 decision, ACM will stop supporting email-validated public certificates in three steps: no email validation in new Regions after 1 January 2027, no new email-validated requests anywhere after 31 March 2027, and no renewals of existing email-validated certificates after 30 September 2027. Certificates issued before the industry deadline stay valid until expiry, so nothing breaks on the day; what breaks is the renewal a year later, on a certificate nobody remembers requesting.

The migration is cheap if you do it now. Filter the ACM console by validation method Email and type Amazon Issued, or script it, then switch each certificate in place with aws acm update-certificate-options, which keeps the ARN so no listener or distribution needs editing. Add the CNAME within the 72-hour window and ACM renews on the new method. HTTP validation exists too, but only for CloudFront. Treat this as a Q3 ticket, not a 2027 one.

MSK: ZooKeeper to KRaft without a new cluster

Kafka 3.9.x is the last line that supports ZooKeeper and Kafka 4.x is KRaft only, so every provisioned MSK cluster still on ZooKeeper has a migration ahead of it. MSK now does it in place: no new infrastructure, no data copy, no client reconfiguration, and the cluster stays available throughout according to AWS. You must be on 3.9.x first. Available everywhere provisioned MSK runs except the European Sovereign Cloud. This is the kind of modernization that never gets prioritised because it has no feature attached, which is exactly why a one-button path matters: it turns a quarter-long project into a change window.

Also this week

The throughline

Application status checks and role manager are the same move in two directions. One lets EC2 observe your application so it can act for you; the other lets IAM act for you before you have observed anything. The first is a good trade because the blast radius of a bad health check is one fleet and it is loud. The second is a worse trade because the blast radius of a broad role is the account and it is silent. The ACM deadline and the MSK migration are reminders that the unglamorous half of platform work, renewals and version floors, is where the real outages live. Put the three dated items on the calendar this week and argue about role manager at your leisure.

Read this next

For the AI and agent reading of the same week, the field notes live at ercan.ai. Consulting on AWS, cloud, CI/CD pipelines, Linux, GitHub/GitLab and more runs through ercanermis.com.

References