Cloudformation-coverage-roadmap: AWS::AccountAlias - New Pseudo Parameter

[1davidmichael]

AWS::AccountAlias Pseudo Parameter

Scope of Interest

Currently I use AWS::AccountId for different mappings logic within CFN templates and resource naming. However, it would be nice if rather than having to maintain a list of those account IDs in every template, I could reference accounts by the account ID within templates.

Expected Behavior

I could use AWS::AccountAlias similar to how AWS::AccountId is used within templates. If the account alias is changed the already created CloudFormatiaon stack resources would maintain the previous account alias.

Suggest specific test cases

Use where naming resources is required by organizations

Example:

AWSTemplateFormatVersion: 2010-09-09
Description: Example usage of AWS::AccountAlias

Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub ${AWS::AccountAlias}-testbucket123

This would result in a bucket named example-account-alias-testbucket123

Helpful Links to speed up research and evaluation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html

https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccountAliases.html

Category

• Other - AWS CloudFormation
• Billing

[seittema]

Cool concept but I think the issue you can run into is the account alias can be changed. Doing so could cause undesirable effects on templates that are using this data if they do a stack update which could lead to loss of data (like a database changing name).
The way we get the account alias today in templates is we create an SSM parameter whenever an account is created with a value and then can use the dynamic reference to resolve it. Obviously it has the same issues of changing data but we never update this ssm value.

[1davidmichael]

Cool concept but I think the issue you can run into is the account alias can be changed. Doing so could cause undesirable effects on templates that are using this data if they do a stack update which could lead to loss of data (like a database changing name).
The way we get the account alias today in templates is we create an SSM parameter whenever an account is created with a value and then can use the dynamic reference to resolve it. Obviously it has the same issues of changing data but we never update this ssm value.

I do something similar but create a dummy CFN resource and export the alias as part of that stack. That has the benefit of being unable to be removed if its in use, but the !ImportValue function in CFN can only be used in certain locations. So it makes its inclusion in things like !Sub functions more tedious.

[joaopenteado]

I also support the inclusion of this parameter. The CloudFormation role could call iam:ListAccountAliases behind the scenes and return the value of the call as AWS::AccountAliases in order to comply with the existing AWS API. Similiar to what CloudFormation does every time you create/update a stack which references a SSM parameter.

To reference the account alias, one could simply do !Select [ 0, !Ref AWS::AccountAliases ].

Most importantly, the inclusion of this parameter could introduce a workaround to the annoying issue often found in YAML CloudFormation templates when referring an account ID that starts with one or multiple zeros.

[benbridts]

If the behaviour is going to be similar to that of SSM/Secrets Manager, it should probably be a resolve instead of pseudo-parameter, to indicate that it might change over time

[1davidmichael]

If the behaviour is going to be similar to that of SSM/Secrets Manager, it should probably be a resolve instead of pseudo-parameter, to indicate that it might change over time

I'd be fine with that instead of a pseudo parameter. Just any way to reference it more easily would be awesome.