AWS shipped 1 of 3 promised Argo CD settings on 21 August 2026 — and ignores the rest silently

Summary. On 21 August 2026 AWS announced that the Amazon EKS Capability for Argo CD accepts a standard argocd-cm ConfigMap, and named three things you can now tune: custom health checks for Custom Resources, the Argo CD UI banner content, and how the capability watches and compares resources. The Amazon EKS User Guide page that documents the feature lists exactly one supported field, resource.customizations.health.*. The same user guide's comparison page puts "UI extensions and custom banners" in its list of features that are not available in the managed capability. AWS also states that the capability "ignores any unsupported fields and features that you set" — no error, no rejected apply, no event. At $0.03 per Argo CD Capability hour and $0.0015 per Argo CD Application hour in US East (N. Virginia) as of 22 August 2026, a 1,000-Application hub bills about $1,116.90 a month, so a ConfigMap that half-works is not a cheap thing to debug.

What actually changed on 21 August 2026

The EKS Capability for Argo CD runs Argo CD in the AWS control plane rather than on your worker nodes. Until this launch you configured it only through the capability resource's own parameters. Now you create a ConfigMap named argocd-cm in the namespace you assigned to the capability, label it app.kubernetes.io/part-of: argocd, and AWS reads supported fields out of it and applies them to the managed instance.

The AWS What's New post, posted 21 August 2026, describes the scope this way: "You can define custom health checks for your Custom Resources, customize the Argo CD UI banner content, adjust how the capability watches and compares the resources it manages, and more."

The user guide page Configure Argo CD settings carries a table headed "Supported settings". It has one row:

The banner case is not ambiguous. The user guide page Comparing EKS Capability for Argo CD to self-managed Argo CD lists, under "Unsupported features": "UI extensions and custom banners", and separately "Direct access to argocd-params and most configuration ConfigMaps (a subset of argocd-cm fields is supported)."

So the announcement names a capability the reference documentation says does not exist.

The failure mode is silence

This would be a documentation nit if a rejected key produced an error. It does not. From the Configure Argo CD settings page: "The capability ignores any unsupported fields and features that you set. Review the list of supported fields to confirm that a setting takes effect."

Kubernetes will accept the ConfigMap. kubectl apply returns success. kubectl get configmap argocd-cm -o yaml shows your keys sitting there. The managed control plane reads the one field it knows and drops the rest on the floor. A platform team that writes resource.exclusions to stop Argo CD watching a noisy CRD will see the apply succeed, see the key in the cluster, and still watch the controller churn on that CRD — with no signal anywhere that the setting never reached the instance.

The practical consequence: treat every argocd-cm key other than resource.customizations.health.* as unverified until you have observed the behaviour change. Not the ConfigMap contents. The behaviour.

The health-check gap is the part worth having

The one supported field is also the one that fixes a real production problem, and AWS describes the problem accurately. Upstream Argo CD has built-in health logic for standard Kubernetes objects such as Deployments and Services. For a Custom Resource it does not recognise, it reports no health at all, and a resource with no health is excluded from the Application's overall health.

Two things follow, both stated in the AWS documentation. An Application can report Healthy while its resources are still provisioning or have already failed. And sync waves can advance before those resources are ready, because sync ordering depends on reported health.

If you run databases, message brokers, or any operator-managed CRD through GitOps, you have probably already hit this: wave 1 creates a Database custom resource, Argo CD sees nothing to assess, wave 2 fires the migration Job against a database that does not exist yet, and the Job fails on a connection refused. The upstream Argo CD sync waves documentation notes there is a deliberate delay between waves, currently 2 seconds and configurable through the ARGOCD_SYNC_WAVE_DELAY environment variable, precisely to stop Argo CD assessing health against a stale object. Two seconds does not cover a database.

A custom health check closes it. The key format matches upstream exactly:

            apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
  labels:
    app.kubernetes.io/part-of: argocd
data:
  resource.customizations.health.example.com_Database: |
    hs = {}
    hs.status = "Progressing"
    hs.message = "Waiting for the resource to become ready"
    if obj.status ~= nil then
      if obj.status.phase == "Ready" then
        hs.status = "Healthy"
        hs.message = "Database is ready"
      end
    end
    return hs
          

The script receives the resource through the global obj variable and must return a table whose status is one of Healthy, Progressing, Degraded or Suspended, with an optional message. AWS ships built-in health checks for AWS Controllers for Kubernetes (ACK) and kro (Kube Resource Orchestrator) resources, and a custom check you define for one of those types overrides the built-in one.

Where migrated scripts break: useOpenLibs

The Configure Argo CD settings page says, in one paragraph: "Existing upstream scripts and community examples work with the EKS Capability for Argo CD without modification."

Four paragraphs later, under "Safety and limitations": "Standard Lua libraries are not available. The useOpenLibs option is always disabled, which is the default in upstream Argo CD. Scripts cannot access the operating system or file system. If you migrate a script from self-managed Argo CD that relies on standard Lua libraries, it might not run the same way in the capability."

Both sentences are on the same page. Only the second one is operationally true.

The word doing the work is "always". Upstream Argo CD disables standard Lua libraries by default as a security measure, but the upstream Resource Health documentation shows administrators re-enabling them per resource type with resource.customizations.useOpenLibs.<group>_<kind>: true, and gives cert-manager.io/Certificate as the worked example. On the managed capability that escape hatch is gone. Any community health check that reaches for a standard library — string formatting helpers, time parsing, table utilities — is a script you cannot fix by flipping a flag. You rewrite it or you drop it.

If you maintain health checks for cert-manager, Crossplane, or any operator whose community scripts predate this launch, audit them for standard-library calls before you cut over. AWS's own advice is to test health check scripts in a development environment first, which is the tell that "without modification" was written optimistically.

One more behaviour worth knowing: if health evaluation is temporarily unavailable, the capability reports affected Custom Resources as Progressing rather than dropping their health status. That is the safer default — a stalled Application beats a false Healthy — but it means a control-plane hiccup and a genuinely stuck resource look identical from the UI.

The migration guide is now stale against the launch

The comparison page's migration path still opens with: "Review your current Argo CD configuration for unsupported features (Notifications controller, CMPs, custom health checks, UI extensions)."

Custom health checks are the feature that shipped on 21 August 2026. As of 22 August 2026 that migration step still tells you to treat them as a blocker. Anyone who read that page and postponed a move off self-managed Argo CD was reading a document that the launch had already overtaken.

The other items on that unsupported list have not moved, and they are the ones that actually decide whether the managed capability fits:

The sync timeout being fixed at 120 seconds is the constraint most likely to bite a large monorepo. Upstream exposes timeout.reconciliation, documented at 120s by default in the upstream argocd-cm reference, among a long list of tunables. On the capability you get the default and no dial.

What it costs, and the multiplier most teams miss

EKS Capabilities bill on two components, both hourly: a base rate per enabled capability, plus a usage rate per managed unit. For Argo CD the managed unit is the Application. From the Amazon EKS pricing page, retrieved 22 August 2026:

That is on top of the EKS control plane itself, which the same page prices at $0.10 per cluster per hour on a Kubernetes version under standard support, rising to $0.60 per cluster per hour once the version enters extended support.

The multiplier is in the pricing definitions, and it is easy to read past. AWS defines an Argo CD Application hour as: "Each Application is counted per target cluster deployment - if you deploy one Application to 5 different clusters, this counts as 5 Applications. When using ApplicationSets with generators, each generated Application instance counts as one Application."

Read that against the architecture AWS recommends. The EKS Capabilities considerations page puts hub-and-spoke first among its multi-cluster patterns, with Argo CD on a management cluster deploying to workload clusters across regions and accounts. An ApplicationSet with a cluster generator fanning 200 Applications across 5 spokes is not 200 billable Applications. It is 1,000. The pattern AWS suggests and the meter AWS runs point in the same direction, and the fan-out factor is the number to model before you commit — not the base rate, which is rounding error at $21.90 a month in US East (N. Virginia).

The real cost is usually the fan-out, not the capability.

Who this affects, and how to tell if that is you

You are exposed to the silent-ignore behaviour if any of these is true:

• You planned to move argocd-cm settings across from a self-managed instance as part of a migration. Only the health-check keys will land.

• You wrote or copied Lua health checks that call standard Lua libraries. They will not error; they will behave differently.

• You use ApplicationSet generators against multiple registered clusters and sized your bill from the Application count in Git rather than the generated count per cluster.

• You depend on the Notifications controller or Config Management Plugins. Neither has shipped, and the 21 August launch did not change that.

You are not affected if you run a single cluster, deploy only standard Kubernetes objects, and authenticate through AWS Identity Center. For that shape the capability removes real work. As Jesse Butler and five co-authors at Amazon Web Services put it in the AWS Containers blog deep dive of 18 December 2025: "Running Argo CD in production means managing high availability, upgrades, Single Sign-On (SSO) configuration, and cross-cluster connectivity. This operational scope grows with each additional cluster across regions or AWS accounts."

That claim holds. The managed capability does remove that scope. The question this launch raises is a narrower one: whether the documentation is precise enough for you to know which parts of your existing configuration survive the move.

What to do this week

1. If you already applied an argocd-cm with anything beyond resource.customizations.health.*, do not assume it took effect. Verify by behaviour: change a health check and confirm the Application status changes, then check whether your exclusion or compare-option keys produced any observable difference. Assume no unless proven yes.

1. Grep your health check scripts for standard Lua library calls before migrating. useOpenLibs is not available to you on the capability.

1. Recount your Applications the way the meter does: Applications multiplied by target clusters, plus every generated instance from ApplicationSet generators.

1. Confirm the ConfigMap basics, because all three are required and none of them are validated for you: name argocd-cm, the namespace you configured on the capability (default argocd), and the label app.kubernetes.io/part-of: argocd.

1. Register the local cluster explicitly if you deploy to the cluster hosting the capability. The comparison page is clear that the capability does not add kubernetes.default.svc automatically, and target clusters must be referenced by EKS cluster ARN, not by Kubernetes API server URL.

1. Do not put credentials in the ConfigMap. AWS flags this directly: a ConfigMap is not a secure store.

Teams standardising on GitOps across several EKS clusters usually find the hard part is not the Argo CD install — it is the Application topology, the tenancy model, and the bill that follows from both. That is the work our release engineering and CI/CD platform practice does, and it sits alongside the same decisions covered in our notes on EKS 1.33 standard support and the Kubernetes 1.36 upgrade breaking changes. For the cost side, see our cloud FinOps guide for Indian teams.

What is still unknown

AWS has not said whether ui.bannercontent and the watch/compare keys are shipping later, were cut before launch, or were never in scope and the announcement copy overreached. The Configure Argo CD settings page is written as an extensible list — "The managed capability supports the following argocd-cm field" — which suggests more are planned, but no roadmap or date is published. Nothing in the AWS material states a policy for surfacing ignored keys, so there is no indication that a warning event or a status condition is coming. Until one of those changes, verification by behaviour is the only method available.

India-specific considerations

Asia Pacific (Mumbai) carries the highest Argo CD rates of the three regions above: $0.032322 per Capability hour and $0.001601 per Application hour, about 7.7% above US East (N. Virginia) on the base charge and 6.7% above it on usage. For an Indian team running a hub in Mumbai with regional spokes, the fan-out multiplier lands on the higher unit price, so the gap widens with cluster count rather than staying flat. Where GitOps configuration carries personal data — repository credentials, identity mappings, anything that reaches a workload processing customer records — the Digital Personal Data Protection Act 2023 obligations follow the data, not the control plane, and AWS's own warning that a ConfigMap is not a secure store applies with full force.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5, MSME certified and ISO 27001:2022 certified engineering organisation based in Gurugram, and an AWS partner. Our senior engineering teams design GitOps topologies for multi-cluster EKS estates, including the Application fan-out modelling that drives the capability bill and the health-check work that keeps sync waves honest. If you are weighing the managed Argo CD capability against a self-managed install, or auditing an argocd-cm that may be half-applied, contact us and we will review the configuration with you.

References

1. Amazon EKS Capability for Argo CD now supports custom configuration — AWS What's New, posted 21 August 2026.

1. Configure Argo CD settings — Amazon EKS User Guide, supported fields table and safety limitations.

1. Comparing EKS Capability for Argo CD to self-managed Argo CD — Amazon EKS User Guide, unsupported features and migration path.

1. Argo CD considerations — Amazon EKS User Guide, Identity Center limits, multi-cluster registration, webhook configuration.

1. Continuous Deployment with Argo CD — Amazon EKS User Guide, capability architecture and control-plane placement.

1. EKS Capabilities considerations — Amazon EKS User Guide, hub-and-spoke and decentralised patterns.

1. Amazon EKS pricing — AWS, EKS Capabilities rates and pricing definitions, retrieved 22 August 2026.

1. Resource Health — Argo CD documentation, custom health checks and useOpenLibs.

1. argocd-cm.yaml example — Argo CD documentation, full upstream field set including ui.bannercontent, resource.exclusions and timeout.reconciliation.

1. Sync Waves — Argo CD documentation, wave ordering and ARGOCD_SYNC_WAVE_DELAY.

1. Deep dive: Streamlining GitOps with Amazon EKS capability for Argo CD — Jesse Butler, Pankaj Walke, Badrish Shanbhag, Carlos Santana, Satish Patil and Sébastien Allamand, AWS Containers blog, 18 December 2025.

Last updated: 22 August 2026.