Record Configurations for Third-Party Resources - AWS Config

Record 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 AWS Config and view and monitor the resource inventory and configuration history using AWS Config console and APIs. Now, you can use AWS Config to manage all your resources and evaluate resource configuration for compliance against best practices using AWS Config rules. You can also create AWS Config rules or conformance packs to evaluate these third-party resources against best practices, internal policies, and regulatory policies.

Note

This feature is only available in the redesigned AWS Config console.

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

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

Step 1: Setup Your Development Environment

Install and configure AWS CloudFormation AWS CLI. The AWS 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
  4. Open the custom-testing-wordpress.json file that contains the schema for your resource. Copy and paste the following schema into custom-testing-wordpress.json.

    Note

    You can change the source URL from the default url mentioned below.

    { "typeName": "MyCustomNamespace::Testing::WordPress", "description": "An example resource that creates a website based on WordPress 5.2.2.", "sourceUrl": "https://github.com/aws-cloudformation/aws-cloudformation-rpdk.git", "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 AWS CLI generates supporting files and code for the resource provider. Regenerate the code to see the updated schema.

    $ cfn generate

For more information, see Modeling Resource Providers for Use in AWS CloudFormation.

Step 3: Generate Artifacts

Run the following command to generate artifacts for cfn submit.

$ mvn package

Step 4: Register Your Resource

AWS 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 AWS CloudFormation Templates.

Step 5: Publish Resource Configuration

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

{ "Name": "MyWordPressSite", "SubnetId": "subnet-abcd0123", "InstanceId": "i-01234567", "PublicIp": "my-wordpress-site.com" }

Determine the schema version id from AWS CloudFormation DescribeType.

In the AWS Config see if this resource configuration is accepted. To evaluate compliance you can write AWS Config rules using this resource.

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

Region Support

This feature is supported in the following regions:

Region Name Region Endpoint Protocol
Asia Pacific (Mumbai) ap-south-1 config.ap-south-1.amazonaws.com HTTPS
Asia Pacific (Seoul) ap-northeast-2 config.ap-northeast-2.amazonaws.com HTTPS
Asia Pacific (Singapore) ap-southeast-1 config.ap-southeast-1.amazonaws.com HTTPS
Asia Pacific (Sydney) ap-southeast-2 config.ap-southeast-2.amazonaws.com HTTPS
Asia Pacific (Tokyo) ap-northeast-1 config.ap-northeast-1.amazonaws.com HTTPS
Canada (Central) ca-central-1 config.ca-central-1.amazonaws.com HTTPS
Europe (Frankfurt) eu-central-1 config.eu-central-1.amazonaws.com HTTPS
Europe (Ireland) eu-west-1 config.eu-west-1.amazonaws.com HTTPS
Europe (London) eu-west-2 config.eu-west-2.amazonaws.com HTTPS
Europe (Paris) eu-west-3 config.eu-west-3.amazonaws.com HTTPS
Europe (Stockholm) eu-north-1 config.eu-north-1.amazonaws.com HTTPS
South America (São Paulo) sa-east-1 config.sa-east-1.amazonaws.com HTTPS
US East (N. Virginia) us-east-1 config.us-east-1.amazonaws.com HTTPS
US East (Ohio) us-east-2 config.us-east-2.amazonaws.com HTTPS
US West (N. California) us-west-1 config.us-west-1.amazonaws.com HTTPS
US West (Oregon) us-west-2 config.us-west-2.amazonaws.com HTTPS