Operations | The AWS Blog

ACM ACME support turns certificate automation into a governance problem

Emiliano Montesdeoca — Tue, 30 Jun 2026 00:00:00 +0000

Certificate automation is becoming less optional. Validity periods are getting shorter, and manual renewal processes are exactly the kind of quiet operational risk that eventually becomes an outage.

AWS has now added ACME support for public certificates in AWS Certificate Manager. The headline is compatibility with ACMEv2 clients such as Certbot, cert-manager, and acme.sh. The bigger builder impact is that certificate issuance can become standardized without moving governance outside AWS.

What changed

ACM now provides a managed ACME server endpoint for public certificates issued by Amazon Trust Services. Teams can point existing ACME clients at ACM, request certificates through the protocol they already know, and still have ACM visibility, CloudTrail logging, CloudWatch metrics, and certificate expiry notifications.

The source article also highlights two controls that matter in real organizations:

domain scopes at the endpoint level,
External Account Binding credentials for client registration.

That means a central PKI or platform team can validate domains once, restrict what clients can request, and avoid distributing DNS credentials to every application team.

Why this matters

Most certificate incidents are not caused by cryptography being hard. They are caused by ownership being unclear.

One team owns DNS. Another owns the ingress controller. Another owns the application. Someone installed a certificate manually two years ago. Nobody remembers the renewal path until browsers start showing errors.

ACME support in ACM gives builders a cleaner operating model:

Kubernetes teams can keep using cert-manager.
VM and container teams can keep using common ACME clients.
Platform teams can centralize issuance policy and audit.
Security teams can see certificates in ACM instead of chasing external CA dashboards.

That is a good trade: keep the open protocol at the edge, centralize governance at the account or organization boundary.

The architecture trade-offs

This does not remove the need for certificate lifecycle design.

First, decide who owns ACME endpoints. If every workload account creates its own endpoint with broad wildcard permissions, you have recreated the sprawl problem. A better pattern is to define endpoints per domain boundary, environment, or platform domain, then scope allowed names carefully.

Second, treat External Account Binding credentials like bootstrap secrets. They should be short-lived where possible, stored securely, and rotated when registration flows change.

Third, think about wildcard issuance. Wildcards are convenient, but they expand blast radius. Many production environments should prefer exact domains and subdomains unless there is a strong operational reason.

Finally, price and volume behavior matter. Moving high-churn ACME issuance into ACM should be costed, especially for systems that create many short-lived certificates across tenants.

What builders should do next

If I were running a platform team, I would start with an inventory:

Which public certificates are already in ACM?
Which are issued by external ACME providers?
Which workloads use cert-manager or custom renewal scripts?
Which teams still depend on manual DNS validation?

Then I would pilot ACM ACME with one non-critical domain and one existing ACME client. The goal is not only to issue a certificate. The goal is to prove the operating model: endpoint ownership, scope policy, audit trail, renewal alarms, and incident response.

The useful part of this launch is not that Certbot can talk to AWS. It is that certificate automation can finally be treated as platform governance instead of a collection of one-off scripts.

Replicating S3 bucket configuration needs workflow discipline

Emiliano Montesdeoca — Tue, 30 Jun 2026 00:00:00 +0000

Replicating S3 data is only part of a multi-Region storage strategy. The bucket configuration around that data is often where drift hides.

The AWS Storage Blog post on replicating Amazon S3 bucket configurations across AWS Regions with AWS Step Functions shows an automation pattern for replaying bucket configuration into a target Region with an auditable workflow.

That is useful, but it also raises an important architecture question: should configuration replication be a workflow, or should it be infrastructure as code?

What changed

The source article describes a Step Functions and Lambda solution that creates a bucket in a target Region and applies configuration from a source bucket. It logs runs to DynamoDB and CloudWatch, which gives operators an audit trail.

This kind of workflow can help when teams need to replicate settings such as encryption, lifecycle, versioning, event notifications, tags, or other operational configuration across Regions.

Why builders should care

Disaster recovery plans often assume that a bucket in another Region is ready because replication is configured. But during a real failover, missing configuration can break applications or weaken controls.

Examples:

lifecycle rules are missing and costs grow,
event notifications do not trigger downstream processing,
encryption or bucket policy differs from the primary Region,
observability tags are absent,
access points or integration settings are inconsistent.

A repeatable replication workflow can turn those assumptions into something testable.

The trade-off with IaC

For stable environments, infrastructure as code should usually be the source of truth. If the bucket configuration is defined in CDK, CloudFormation, Terraform, or Pulumi, the cleanest replication path is often to deploy the same intent to another Region.

A workflow-based replication tool is valuable when:

buckets already exist and need operational synchronization,
configuration is discovered from a source environment,
teams need an emergency or transitional DR path,
there are many legacy buckets not yet under IaC,
operators need a controlled copy action with audit logs.

The risk is creating a second source of truth. If IaC says one thing and the replication workflow copies another, drift becomes harder to reason about.

What to do next

Before using this pattern, classify buckets into two groups:

IaC-owned buckets where configuration should be generated from code.
Operationally managed buckets where a replication workflow can reduce drift until IaC ownership exists.

Then run regular DR validation. Do not only check that the target bucket exists. Check whether the target bucket has the policies, notifications, lifecycle rules, encryption settings, tags, and observability hooks needed for the application to run.

The useful takeaway is that S3 resilience is not just object replication. It is configuration repeatability. Step Functions can provide a controlled workflow for that, as long as builders are clear about the source of truth.

S3 Storage Lens groups make storage cost conversations less generic

Emiliano Montesdeoca — Fri, 26 Jun 2026 00:00:00 +0000

Storage optimization advice often starts too broadly: reduce old data, review access patterns, apply lifecycle policies. That is true, but it is not specific enough for a team to act.

The AWS Storage Blog post on S3 Storage Lens groups is useful because it shows how to group storage by workload-specific criteria instead of looking only at account or bucket totals.

What changed

S3 Storage Lens groups let builders define custom groupings and analyze metrics for targeted slices of S3 data. The source article uses examples such as older application logs and aging image files across multiple buckets and accounts.

That matters because the useful unit of storage ownership is rarely just a bucket. It may be an application, dataset, tenant, media type, compliance class, or product feature.

Why builders should care

S3 cost and hygiene problems are usually ownership problems.

A central cloud team can see that storage is growing. They may not know which logs are safe to expire, which images are user-generated content, which datasets are legally retained, or which prefixes belong to an old migration. Application teams know the context, but they often lack cross-account visibility.

Storage Lens groups can bridge that gap. They help create a view that says, “this workload has 40 TB of logs older than 180 days,” not just “this account has 400 TB in S3.”

That turns a generic optimization request into a practical backlog item.

The trade-offs

Custom groups are only useful if the grouping logic reflects real ownership and lifecycle rules. If tags, prefixes, naming conventions, or account boundaries are inconsistent, the dashboard can give false confidence.

Teams should avoid building too many groups at once. Start with questions that lead to action:

Which data can move to a colder tier?
Which prefixes have no recent access?
Which workloads are growing faster than expected?
Which buckets contain small-object patterns that inflate request costs?
Which teams own the largest retained datasets?

Also remember that visibility is not enforcement. Storage Lens can show the opportunity, but lifecycle rules, retention policies, and application changes implement the fix.

What to do next

Pick one high-cost storage area and define a group around the way the business thinks about it. For example: production application logs older than 90 days, media originals by product, or export datasets by tenant.

Then review the metrics with the owning team and decide on one action: lifecycle transition, deletion after retention, object compaction, prefix redesign, or access pattern review.

The practical value of Storage Lens groups is not better charts. It is better conversations between platform, finance, security, and application teams about the specific data that is driving cost and risk.

EKS Auto Mode improvements show why managed Kubernetes is becoming operational engineering

Emiliano Montesdeoca — Tue, 23 Jun 2026 00:00:00 +0000

The latest EKS Auto Mode update is not one big feature. It is a collection of operational improvements: faster node startup, better Karpenter behavior, node-local DNS, smoother EBS migration, and more networking options.

That is exactly why it matters.

In the AWS Containers Blog post, AWS describes improvements across runtime, compute, storage, and networking. For builders, the lesson is that managed Kubernetes value increasingly comes from reducing the number of sharp edges you have to own yourself.

What changed

The source article lists several practical changes:

node ready latency reduced through faster startup detection,
Karpenter scale-out and consolidation improvements,
zram protection for transient system memory pressure,
faster image pulls for large ML and GPU images,
node-local DNS by default in Auto Mode,
support for separate pod subnets and pod security groups,
improved EBS migration and topology-aware volume scheduling.

None of these changes remove the need to understand Kubernetes. They reduce the tax of operating the infrastructure layer below your workloads.

Why builders should care

Most Kubernetes incidents are not about Kubernetes being unavailable. They are about the cluster being technically alive while applications wait for capacity, DNS, storage, or networking to catch up.

Faster node startup helps bursty workloads. Better consolidation helps cost. Node-local DNS reduces a common hidden bottleneck. Separate pod subnets and security groups make enterprise network patterns easier to express without abandoning Auto Mode defaults.

For platform teams, this changes the migration conversation. Auto Mode is not only about “less to manage.” It is about whether AWS-managed operational improvements arrive faster than your team could safely build and maintain them.

The trade-offs

There are still boundaries.

Auto Mode can improve node lifecycle and system components, but it cannot fix bad pod requests, missing disruption budgets, slow application startup, or chatty service dependencies. If workloads request too much CPU, do not define readiness probes, or depend on large cold images, managed infrastructure only helps so far.

Cost also needs attention. Faster scale-out is useful, but it can surface inefficient autoscaling policies. Faster consolidation is useful, but only if workloads tolerate disruption and your budgets are modeled correctly.

Networking improvements should also be treated as architecture choices. Separate pod subnets and security groups can improve segmentation, but they introduce more routes, policies, IP planning, and troubleshooting paths.

What to do next

If you run EKS Auto Mode today, measure before and after. Look at:

pending pod seconds during scale events,
node ready time,
image pull latency for large containers,
DNS latency and CoreDNS saturation,
consolidation events and interruption impact,
cross-AZ and NAT gateway traffic.

If you are migrating to Auto Mode, do it workload by workload. Start with stateless services that have clean readiness probes, pod disruption budgets, and known resource requests. Then move stateful or network-sensitive workloads after validating storage topology and security group behavior.

The best outcome is not simply fewer Kubernetes knobs. It is a platform where the knobs that remain are closer to application reliability, cost, and security decisions. That is where builders should spend their time.

Lambda runtime upgrades need campaigns, not reminders

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

Lambda runtime upgrades are easy to postpone because the function still works today. Then a deprecation date becomes a support risk, a security exception, or a rushed platform campaign.

The AWS Compute Blog post on upgrading Lambda function runtimes at scale with AWS Transform custom is useful because it treats runtime upgrades as a repeatable modernization workflow, not a calendar reminder.

What changed

AWS Transform custom can analyze codebases, identify runtime upgrade risk, apply transformations, update dependencies or configuration, and validate against exit criteria. The source article focuses on Lambda runtime upgrades, including cases where code changes are required, such as moving callback-style Node.js handlers toward async patterns.

For platform teams, the more important piece is campaign management. A large organization rarely has one repository and one owner. It has hundreds of functions across many accounts, teams, IaC stacks, and CI/CD systems.

Why builders should care

Runtime upgrades fail when ownership is unclear.

An application team may not know a function exists. A platform team may see the deprecated runtime but not understand the deployment path. Security may see the exposure but not own the code. The result is a spreadsheet-driven migration with too many manual exceptions.

A transformation tool can help, but only if it plugs into an operating model:

inventory functions and repositories,
map functions to owners,
assess code and dependency risk,
create pull requests or transformation branches,
validate with tests and alarms,
deploy with safe rollout and rollback,
track completion centrally.

That is a campaign, not a one-off task.

The trade-offs

Automated transformation is not a substitute for test coverage. It increases the value of tests because it can make changes faster than humans can manually review every edge case.

Before trusting a runtime upgrade, teams should check:

unit and integration tests for handler behavior,
dependency compatibility with the target runtime,
infrastructure definitions that set the runtime,
packaging and build pipeline changes,
observability after deployment,
alias or version-based rollback strategy.

For platform teams, the other trade-off is centralization. Pushing changes across many repositories can be efficient, but service owners still need to understand and approve behavior changes. The best model is usually centralized orchestration with distributed ownership.

What to do next

Start with inventory. Use AWS Config, Trusted Advisor, CLI scripts, tags, or deployment metadata to find functions approaching deprecation. Then group them by owner, runtime, business criticality, and test readiness.

For low-risk functions with good tests, an automated transform can move quickly. For high-risk functions with poor tests, the first transformation should probably add documentation, tests, or alarms before changing the runtime.

The lesson from this AWS post is broader than Lambda. Modernization work becomes manageable when it is continuous, visible, and validated. If runtime upgrades are still handled as emergency cleanup, the tooling can help, but the process needs upgrading too.