You need to deploy an AWS stack in a repeatable manner across multiple environments.
You have selected CloudFormation as the right tool to accomplish this.
You have found that there is a resource type you need to create and model, but it is unsupported by CloudFormation.
How should you overcome this challenge?
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - D.
Custom resources enable you to write custom provisioning logic in templates that AWS CloudFormation runs anytime you create, update (if you changed the custom resource), or delete stacks.
For example, you might want to include resources that aren't available as AWS CloudFormation resource types.
You can include those resources by using custom resources.
That way, you can still manage all your related resources in a single stack.
Use the AWS::CloudFormation::CustomResource or Custom::String resource type to define custom resources in your templates.
Custom resources require one property: the service token, which specifies where AWS CloudFormation sends requests, such as an Amazon SNS topic.
For more information on Custom Resources in Cloudformation, please visit the below URL:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.htmlWhen using AWS CloudFormation to deploy an infrastructure stack in a repeatable manner across multiple environments, it is essential to have all the resources that are required to be modeled in a CloudFormation template. However, in some cases, there may be a resource type that is not supported by CloudFormation.
In such a scenario, there are several ways to overcome this challenge, but the most appropriate one is to use a CloudFormation custom resource template. A CloudFormation custom resource template allows you to select an API call to proxy for create, update, and delete actions. CloudFormation will use the AWS SDK, CLI, or API method of your choosing as the state transition function for the resource type you are modeling.
Using a custom resource template allows you to model the unsupported resource type within your CloudFormation stack. You can use AWS Lambda to implement the custom resource provider function that interacts with the external system, such as an AWS service or a third-party system, to create, update, or delete the resource.
Another option is to create a custom resource type by implementing create, update, and delete functionality, either by subscribing a custom resource provider to an SNS topic or by implementing the logic in AWS Lambda. This approach allows you to define and model the custom resource type within your CloudFormation stack, just like any other resource type.
Submitting a ticket to the AWS Forums is not a recommended solution because the response time is not guaranteed, and there is no guarantee that the requested resource type will be added to CloudFormation. Using Chef, Puppet, or Ansible to author Heat templates is also not recommended because these tools are not directly integrated with AWS services and do not provide the same level of automation and orchestration as CloudFormation.
In conclusion, the most appropriate solution to overcome the challenge of an unsupported resource type in CloudFormation is to use a custom resource template or create a custom resource type with the help of AWS Lambda or a custom resource provider.