Recording Configurations for Third-Party Resources - Amazon Config
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Recording Configurations for Third-Party Resources

Record configurations for third-party resources or custom resource types such as on premise servers, SAAS monitoring tools, and version control systems (like GitHub). You can publish the configuration data of third-party resources into Amazon Config and view and monitor the resource inventory and configuration history using Amazon Config console and APIs. Now, you can use Amazon Config to manage all your resources and evaluate resource configuration for compliance against best practices using Amazon Config rules. You can also create Amazon Config rules or conformance packs to evaluate these third-party resources against best practices, internal policies, and regulatory policies.


If you have configured Amazon Config to record all resource types, then third-party resources that are managed (created, updated, or deleted) through Amazon CloudFormation are automatically tracked in Amazon Config as configuration items.

Prerequisite: The third-party resources or custom resource type must be registered using Amazon CloudFormation.

Step 1: Setup Your Development Environment

Install and configure Amazon CloudFormation Amazon CLI. The Amazon CLI allows you to model and register your custom resources. For more information, see Custom Resources and What Is the CloudFormation Command Line Interface?.

Step 2: Model Your Resource

Create a resource provider schema that conforms to and validates the configuration of the resource type.

  1. Use the init command to create your resource provider project and generate the files it requires.

    $ cfn init Initializing new project
  2. The init command launches a wizard that walks you through setting up the project, including specifying the resource name. For this walkthrough, specify MyCustomNamespace::Testing::WordPress.

    Enter resource type identifier (Organization::Service::Resource): MyCustomNamespace::Testing::WordPress
  3. Enter a package name for your resource.

    Enter a package name (empty for default 'com.custom.testing.wordpress'): com.custom.testing.wordpress Initialized a new project in /workplace/user/custom-testing-wordpress

    In order to guarantee that any project dependencies are correctly resolved, you can import the generated project into your IDE with Maven support.

    For example, if you are using IntelliJ IDEA, you would need to do the following:

    • From the File menu, choose New, then choose Project From Existing Sources.

    • Navigate to the project directory

    • In the Import Project dialog box, choose Import project from external model and then choose Maven.

    • Choose Next and accept any defaults to complete importing the project.

  4. Open the mycustomnamespace-testing-wordpress.json file that contains the schema for your resource. Copy and paste the following schema into mycustomnamespace-testing-wordpress.json.

    { "typeName": "MyCustomNamespace::Testing::WordPress", "description": "An example resource that creates a website based on WordPress 5.2.2.", "properties": { "Name": { "description": "A name associated with the website.", "type": "string", "pattern": "^[a-zA-Z0-9]{1,219}\\Z", "minLength": 1, "maxLength": 219 }, "SubnetId": { "description": "A subnet in which to host the website.", "pattern": "^(subnet-[a-f0-9]{13})|(subnet-[a-f0-9]{8})\\Z", "type": "string" }, "InstanceId": { "description": "The ID of the instance that backs the WordPress site.", "type": "string" }, "PublicIp": { "description": "The public IP for the WordPress site.", "type": "string" } }, "required": [ "Name", "SubnetId" ], "primaryIdentifier": [ "/properties/PublicIp", "/properties/InstanceId" ], "readOnlyProperties": [ "/properties/PublicIp", "/properties/InstanceId" ], "additionalProperties": false }
  5. Validate the schema.

    $ cfn validate
  6. Update the auto-generated files in the resource provider package to view the resource provider schema updates. Upon initiation of the resource provider project, the Amazon CLI generates supporting files and code for the resource provider. Regenerate the code to see the updated schema.

    $ cfn generate

    When using Maven, as part of the build process the generate command is automatically run before the code is compiled. So your changes will never get out of sync with the generated code.

    Be aware the CloudFormation CLI must be in a location Maven/the system can find. For more information, see Setting up your environment for developing extensions.

For more information on the whole process, see Modeling Resource Providers for Use in Amazon CloudFormation.

Step 3: Generate Artifacts

Run the following command to generate artifacts for cfn submit.

$ mvn package

Step 4: Register Your Resource

Amazon Config does not require resource provider handlers to perform configuration tracking for your resource. Run the following command to register your resource.

$ cfn submit

For more information, see Registering Resource Providers for Use in Amazon CloudFormation Templates.

Step 5: Publish Resource Configuration

Determine the configuration for MyCustomNamespace::Testing::WordPress.

{ "Name": "MyWordPressSite", "SubnetId": "subnet-abcd0123", "InstanceId": "i-01234567", "PublicIp": "" }

Determine the schema version id from Amazon CloudFormation DescribeType.

In the Amazon Config see if this resource configuration is accepted. To evaluate compliance you can write Amazon Config rules using this resource. For additional information, see Record and Delete a Configuration State for Third-Party Resources Using Amazon CLI.

Optional: To automate recording of configuration, implement a periodic or change-based configuration collectors.