This article will show you how to manage parameters across your Service Catalog Tools environment. It is a collection
of real world examples of how to use parameters for organization unit, account and region level wide configurations.
Using parameters (basic usage)
When you specify a launch you can specify parameters. Here is an example where a vpc is provisioned into the default
region of each account tagged as type:spoke:
You could have also retrieved the value from SSM:
This makes it dynamic but what happens if you want to have a different value for each region?
Using mappings for parameters
You can use a mapping to make this more configurable:
With the above configuration you are saying when provisioning vpc into us-east-1 use 10.0.0.1/24 and when
provisioning into us-west-1 use 192.168.0.1/26. This allows you to have a different parameter value for each region
but that value will be the same for every launch. To make it different per account you can use the following:
With the above configuration you are saying when provisioning vpc into account 0123456789010 use 10.0.0.1/24 and
when provisioning into account 0098765432110 use 192.168.0.1/26. This allows you to have a different parameter
value for each account but you will have to update your manifest file each time you want to add an account.
Using intrinsic functions in ssm parameter names
You can use the account id and region name within the SSM parameter name value to use account and region specific ssm
Each time vpc is provisioned into a region of an account the region name and account id will be used to substitute
values in the ssm name attribute. For example, when you provision into us-east-1 of account 012345678910 the ssm
parameter used to get the value for the cidr parameter will be the one with the name
Storing values in ssm using intrinsic functions
You can store the stack outputs for your products in SSM and use intrinsic functions to derive the name:
When you provision into us-east-1 of account 012345678910 the ssm parameter used to store the stack output will
have the name of "/vpcs/012345678910/us-east-1/id”
Customer provided parameters
If you have built a self-service / account vending mechanism you may want to allow the customers of your solution to set
some parameters to be used later on - for example whether they require a connected account or not, if they want private
subnets or public or even if they want to have networking at all or not.
If you are vending accounts by provisioning a product into your Service Catalog Tools account you have a very easy
option. Include an SSM parameter into your account creation product. The name of the parameter should be derived
from the account id of the newly created account:
Please note some of the parameters and resources have been omitted from the example above.
This will create an SSM parameter in your Service Catalog Tools account that can be used in your launches:
Within your product you can use conditions to provision the correct set of resources or you can use three launches (one
for each network type) along with a condition on whether they should do anything or not: