CloudFormation ECS event capture for Console Event History tab

A CloudFormation custom resource that computes the deterministic EventBridge rule name the ECS console uses for a cluster's events-capture rule.

The problem

The ECS console has an Event history tab on each cluster, showing past ECS events. It only works after event capture is set up, and the console offers a button that sets it up: an EventBridge rule delivering the cluster's events to a CloudWatch Logs group.

If you build the same thing yourself with infrastructure as code, capture works, but the Event history tab shows that event capture is not configured. The console expects a specific rule name to exist, and the name it generates embeds a hash:

suffix = base58btc(sha256(JSON.stringify(clusterArn)))
name   = ("EventsToLogs-" + clusterName), truncated so that
         name + "-" + suffix lands exactly on the 64-character rule name cap

CloudFormation cannot compute a hash, so this example wraps the computation in a Lambda-backed custom resource. Give it a cluster ARN, get the rule name back, and use it as the Name of your capture rule.

This relies on undocumented console behaviour, reverse-engineered and verified in August 2026. It may break if AWS changes the console.

Contents

• template.yaml - the custom resource: Lambda function plus its role and log group. Exports the function ARN as ecs-events-rule-name.
• lambda/custom_ecs_events_rule_name.py - the function. Pure standard library, no dependencies.
• example.yaml - a working event-capture stack for an existing cluster: console-convention log group, the custom resource, and the rule named by it.

Deploy

The custom resource stack is needed once per account and region: the export is regional, so every region with clusters you want covered needs its own copy. The export name ecs-events-rule-name is fixed, so there is one such stack per account and region, and CloudFormation will not let you delete it while other stacks still import it.

The template references the Lambda source as a directory, so package it first (needs an S3 bucket for the artefact):

aws cloudformation package \
  --template-file template.yaml \
  --s3-bucket <your-templates-bucket> \
  --output-template-file packaged.yaml

aws cloudformation deploy \
  --template-file packaged.yaml \
  --stack-name ecs-events-rule-name \
  --capabilities CAPABILITY_IAM

Then use it, either via example.yaml directly:

aws cloudformation deploy \
  --template-file example.yaml \
  --stack-name my-cluster-events \
  --parameter-overrides Cluster=my-cluster

or by pasting the ClusterEventsRuleName and Name: parts of the example into your own template:

  ClusterEventsRuleName:
    Type: Custom::EcsEventsRuleName
    Properties:
      ServiceToken: !ImportValue ecs-events-rule-name
      ClusterArn: !Sub "arn:aws:ecs:${AWS::Region}:${AWS::AccountId}:cluster/${Cluster}"

  ClusterEventsRule:
    Type: AWS::Events::Rule
    Properties:
      Name: !GetAtt ClusterEventsRuleName.RuleName
      ...

Notes

• If the console button was already used on a cluster, its rule and log group exist under exactly these names. Delete them (or import them into the stack) before deploying the example, or the deploy fails on the name collision.
• Renaming an existing rule is a replacement: CloudFormation creates the new rule before deleting the old one, so events are delivered twice for a brief window. Harmless for this use.
• "ECS Deployment State Change" events carry no detail.clusterArn, so a clusterArn-matched pattern misses them. The console's own setup has the same gap.
• The custom resource manages nothing real: Create and Update just compute, Delete is a no-op. On bad input it fails the stack fast with the reason, then raises so the error also lands in the function's error metric.
• The custom resource itself costs next to nothing (one Lambda invocation per stack create or update). Event capture is not free: it is billed as EventBridge ingestion plus CloudWatch Logs storage and queries, see the Considerations section of the ECS documentation. Set a log group retention that matches how far back you actually look.

Limitations

• Not tested in AWS GovCloud (US) or China regions. The function only accepts cluster ARNs from the standard aws partition and rejects aws-us-gov and aws-cn ARNs, rather than assuming the console names the rule the same way there. If you can verify the name in those partitions, a pull request is welcome.
• The rule name is undocumented console behaviour (see above). If AWS changes how the console looks for the rule, the Event history tab may stop recognising it. Capture itself keeps working either way.

Checking a name locally

The function runs standalone:

python3 lambda/custom_ecs_events_rule_name.py \
  arn:aws:ecs:eu-west-1:123456789012:cluster/my-cluster

prints the rule name the console would use for that cluster.

Background

The full story, including how the console feature works and what the button creates, is in our blog post: Enable Amazon ECS event capture with CloudFormation.

Support

Maintained by Mysterious Code on a best-effort basis. Issues and pull requests are welcome, but there is no support guarantee.

Credits

Credit to Claude, Anthropic's AI assistant, for reverse-engineering the rule-naming convention.

License

MIT, see LICENSE.

This project is not affiliated with, endorsed by or supported by Amazon Web Services. Amazon Web Services, AWS, Amazon ECS and related marks are trademarks of Amazon.com, Inc. or its affiliates.