skip to Main Content

Given a situation where the same AWS account will host the Dev and UAT cloud deployments simultaneously, what is the best way to instantiate and segregate those 2 pseudo-environments?

I say "pseudo" because the cdk Environment only takes in an account id & region. There is no other separation mechanism.

I could hand down the prefix manually into resource names by passing variables to the Construct constructor call which is passed in by the Stack constructor

main(args) {

  app App = ...

  Stack(app, "stackid", bucketPrefix = args[0]) 

But I’m asking if there is a cdk/aws native way that enables this instead.

Thank you in advance for your consideration and response.

2

Answers


  1. While the CDK best practice is separate environments for Dev and UAT, it’s certainly possible to deploy multiple app copies in the same account/region pair*.

    1. Each app’s stacks need a different construct id – e.g. DevMyStack and UatMyStack. Child construct identifiers inherit their parent’s scope, so passing the prefixes down the construct hierarchy isn’t required. The docs have an example of duplicating stacks within an app, which has the same constraints as your case.
    2. This assumes you are following the best practice of letting CDK/CloudFormation set resource names. The Dev and UAT builds are ephemeral anyway, so this shouldn’t be a problem. If you prefer pretty names, consider setting explicit resource names only for production:
    bucketName: props.isProduction ? "my-explicit-bucket-name" : undefined
    
    1. Add tags for better operational and cost control. It’s easy to tag to all stack resources in one go:
    cdk.Tags.of(DevMyStack).add('build', 'dev');
    

    * Your apps should not contain "singleton" resources that are created once per account/region.

    Login or Signup to reply.
  2. Most constructs have a name attribute that can be assigned. CDK prefers you to leave this blank – doing so adds a random string of characters to the end of the generated name, allowing for multiple deployments in the same account-region.

    This is not very human readable or easy to tell apart. Tags can help with this (tag each set with its own tag). My preference is to go ahead and use the Name fields, but programatically add a suffix

    my-lambda and my-dynamodbTable become blue-my-lambda and blue-my-dynamodbTable vs green-my-lambda and green-my-dynamodbTable

    just a simple variable concated string in the name attribute wil handle this, and still is mostly in line with synth-time-decision-making if you pass the name in from the stack constructor at the app level. This also prevents the need for multiple apps in your repo.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search