Modules package resource configurations into reusable, versioned building blocks that you can include across stack templates. They encapsulate common service configurations and best practices as modular, customizable components.
Sample scenario
Modules let you incorporate best practices, expert knowledge, and accepted guidelines for security, compliance, governance, and industry regulations into your templates without deep knowledge of resource implementation.
For example, a networking expert can create a module with built-in security groups and ingress/egress rules that adhere to security guidelines. You can then include the module in your template to provision secure networking infrastructure without learning how virtual private clouds (VPCs), subnets, security groups, and gateways work. Modules also support versioning, so the module creator can publish a new version when security guidelines change.
Benefits
-
Predictability: A module must be created in Resource Orchestration Service (ROS) before you can use it. When you add a module to your template, you can identify the resources that the module resolves to.
-
Reusability: You can use the same module across multiple templates and accounts.
-
Traceability: ROS tracks the origin of resources in stacks so you can identify which resources are created from modules. You can view resource origins on the Resources, Drifts, and Change Sets tabs in the ROS console.
-
Manageability: After you create a module in ROS, you can manage it through ROS, including versioning.
Module type
-
Public module
ROS provides ready-to-use public modules. For more information, see View a public module.
-
Custom module
Custom modules are modules that you create in the ROS console. For more information, see Manage custom modules.
How a module works
When you initiate a stack operation, ROS generates a processed template that resolves all included modules into the corresponding resources. You can use change sets to preview the resources to be added or updated before executing the stack operation.
Resources (regular resources and DataSource resources) and modules follow different naming conventions. Resources use a three-part naming convention. Modules use the following four-part naming convention: MODULE::Organization::Service::Usecase.
In this example, a template containing resources and modules is used to create a stack. The template contains an individual resource named Resource1 and a module named MODULE::Org::Service::ParentModule. The MODULE::Org::Service::ParentModule module contains two resources named Resource2 and Resource3, and a nested module named MODULE::Org::Service::ChildModule. The nested module MODULE::Org::Service::ChildModule contains a resource named Resource4. ROS processes the template and resolves the modules into the corresponding resources. The resulting stack contains the following resources: Resource1, Resource2, Resource3, and Resource4.
