Defining Unique Resource Names
This tutorial references the code in the aws-connectedcar-dotnet-serverless repository. If you're new to this course, see the introduction for information about setting up your workstation and getting the sample code.
One of the things you can see demonstrated in the sample code is the capability, using the same set of templates, to deploy more than one stack for the solution at the same time, in the same region, and under the same AWS account. The trick to making this work without triggering naming collisions between stacks is to create unique resource names for each deployment.
Constructing Segmented Resource Names
From looking at the CloudFormation templates in the sample code, you’ve probably noticed that they all have two name-related input parameters: ServiceName and EnvironmentName. These two parameters are used in the templates to construct unique, user-define resource names following this general pattern:
[ServiceName]_[Descriptive Name]_[EnvironmentName]
Here are a couple of examples showing this pattern in the services.yaml template:
In the code shown above, line 44 shows the construction of the ClientName property for the Cognito User Pool Client resource. Line 66 shows the same pattern for the construction of the TableName property for the DynamoDB dealer table.
There are two things to note about these examples. First, most user-defined resource names are not global in scope. They are account- and region-specific. So, you don’t need to include the account or region parameters in these names. You could theoretically deploy stacks that use the same resource names in different accounts or regions, but you shouldn’t, to avoid confusion.
Second, the name of the property that you're constructing with these user-defined names can vary, depending on the resource type. There isn’t a universal “name” property. For example, the resource name for a Cognito User Pool is specified in the UserPoolName property. The equivalent for a DynamoDB table is the TableName property.
Lastly, you need to be aware that different resource types can have different naming constraints. Our sample code uses underscores as segment delimiters in most of the user-defined names. But IAM resources like policies and roles, for example, don’t allow underscores or hyphens in their names. So for these resources we use camel-case user-defined names instead, without underscores.
Testing Resource Names
For any reasonably complex solution, you’re quite likely to leave some hard-coded resource names unintentionally in your templates when first written. To catch these in your code you should make a point of testing your templates by deploying two stacks with different naming parameters, under the same account and in the same region. The creation of the second CloudFormation stack will fail if there are any resources with literal name values.