There are two ways to create your CloudFormation modules: When you use a CloudFormation module, the module template is expanded into the consuming template, which makes it possible for you to access the resources inside the module using a Ref or Fn::GetAtt. Parameters that are defined in the CloudFormation module become properties when consuming the ::MODULE resource type. A module with a resource type is postfixed in the CloudFormation registry with ::MODULE so it’s easy to denote when you are using a module or a native registry resource. This means you can create a module that defines your organization’s standards for a Lambda function and then consume that Lambda module in another module that defines the patterns for your serverless Amazon API Gateway implementation.ĬloudFormation modules are available in the CloudFormation registry, so you can use them just like a native resource.
These building blocks can be nested into other modules, so you can stack your best practices into higher-level building blocks. These building blocks can be for a single resource, like best practices for defining an Amazon Elastic Compute Cloud (Amazon EC2) instance or they can be for multiple resources, to define common patterns of application architecture. Modules are building blocks that can be reused across multiple CloudFormation templates and is used just like a native CloudFormation resource. To help solve this issue, the CloudFormation team is excited to announce the release of modules. While you’re building your application, you might want to just follow the best practices for a resource and not worry about all the properties and their possible values.
As you work on your templates, you might be curious about which resource properties to configure and which values to use to follow those best practices. If you’ve used AWS CloudFormation, you’ve probably experienced times when you are trying to build applications and want to deploy resources with best practices defined.
0 kommentar(er)
