The CloudFormation Registry is the mechanism CloudFormation uses to extend its capabilities beyond the AWS-native resource types, allowing you to provision third-party infrastructure directly from your CloudFormation templates.
Let’s see it in action. Imagine you’re using a service like Datadog for monitoring. You want to provision a Datadog monitor as part of your infrastructure deployment.
AWSTemplateFormatVersion: '2010-09-09'
Description: Provision a Datadog monitor using the CloudFormation Registry
Resources:
MyDatadogMonitor:
Type: "Datadog::Monitors::Monitor" # This is a third-party resource type
Properties:
Name: "High CPU Usage Alert"
Type: "metric alert"
Query: "avg(last_5m) by {host} (system.cpu.user) > 90"
Message: "High CPU usage detected on host {{host.name}}. Current value: {{value}}"
Tags:
- "environment:production"
- "service:webserver"
Options:
Thresholds:
Critical: 90
NotifyNoData: true
RenotifyInterval: 60
Here, Datadog::Monitors::Monitor is not a native AWS resource. It’s a resource type provided by Datadog and published to the CloudFormation Registry. When CloudFormation processes this template, it recognizes this type and, if it’s activated, knows how to interact with the Datadog API to create, update, or delete the monitor.
The problem this solves is the fragmentation of infrastructure management. Traditionally, you’d manage AWS resources with CloudFormation and third-party resources (like SaaS monitoring tools, databases, or security appliances) through their own CLIs, APIs, or dashboards. This leads to separate workflows, inconsistent state tracking, and a higher chance of configuration drift. The Registry unifies this by bringing third-party resources into the declarative, infrastructure-as-code paradigm of CloudFormation.
Internally, when you use a third-party resource type, CloudFormation acts as an orchestrator. It doesn’t inherently know how to create a Datadog monitor. Instead, it relies on a resource provider that Datadog has developed and registered. This provider is essentially a piece of software (often a containerized application) that CloudFormation invokes. When you deploy the template:
- CloudFormation sees the
Datadog::Monitors::Monitortype. - It looks up the registered provider for this type in the CloudFormation Registry.
- It invokes the provider, passing the
Propertiesof your Datadog monitor. - The provider then translates these properties into the specific API calls required by the Datadog API to create the monitor.
- It returns the status and any relevant information (like the monitor ID) back to CloudFormation.
The exact levers you control are defined by the Properties of the third-party resource type itself. Each resource provider defines its own schema for these properties, mirroring the configuration options available in the third-party service. You interact with the registry through the AWS console (under CloudFormation -> Registry) or the AWS CLI (aws cloudformation register-type, aws cloudformation list-types, etc.). You can activate public extensions or, if you’re a vendor, publish your own.
One thing many people don’t realize is that the resource provider itself is responsible for managing the state of the resource in the third-party system. When you update a Datadog monitor in CloudFormation, CloudFormation sends the updated properties to the Datadog provider. The provider then calls the Datadog API to update the monitor. For deletion, the provider receives a delete request and calls the Datadog API to remove the monitor. This means the provider must be robust enough to handle idempotency, error conditions, and the full lifecycle of the resource.
The next step in mastering CloudFormation extensions is understanding how to develop and publish your own custom resource providers for internal tools or less common third-party services.