Reference Architecture account names

[zackproser]

A customer asked:

I'd like to understand the constraints and options for giving the AWS accounts I want to use in my Reference Architecture unique names.

---

Tracked in ticket #108766

[zackproser]

Gruntwork's Reference Architecture does support custom AWS Account names.

N.B. that, although we provide you with the option of giving your AWS accounts custom names, the names you supply must be compliant with the AWS API endpoint for creating accounts. See the AWS API reference for CreateAccount and ensure your custom name complies with the validation rules specified there.

When you purchase a Reference Architecture from Gruntwork, you'll receive a gruntwork-clients/infrastructure-live repository that is specific and private to your organization.

In that repository, you will find a reference-architecture-form.yml file. If you look at this YAML file, you'll notice there is a map named AWSAccounts Please see the expanded comments in the example form below to understand how each account role can be configured, and which aspects cannot be changed:

AWSAccounts:
  # Although the attribute is a list, this is only for type checking purposes. Do not add more entries to this list as
  # Gruntwork only supports one logs account.
  # <-- The next line, "logs" cannot be changed. It is an expected key in the AWSAccounts map. It signifies to 
  #     our backend deployment infrastructure that this account's "Role" is to be the Logs account. You can only
  #     have one logs account by design. In essence, you cannot change this outer logs key if you want your 
  #     deployment to commence. --> 
  logs:
    # This must be "logs" - you cannot change it or your deployment will error out. Note that the actual account
    # name in AWS does NOT have to be logs. This is only used for cross references and folder names in the
    # reference architecture.
    - Name: "logs"
      ID: "111111111111"

  # Although the attribute is a list, this is only for type checking purposes. Do not add more entries to this list as
  # Gruntwork only supports one security account.
  # <-- The next line, "security" cannot be changed. It is an expected key in the AWSAccounts map. It signifies to 
  #     our backend deployment infrastructure that this account's "Role" is to be the security account. You can only
  #     have one logs account by design. In essence, you cannot change this outer logs key if you want your 
  #     deployment to commence. --> 
  security:
    # This must be "security" - you cannot change it or your deployment will error out. Note that the actual account
    # name in AWS does NOT have to be logs. This is only used for cross references and folder names in the
    # reference architecture. 
    - Name: "security"
      ID: "111111111111"

  # Although the attribute is a list, this is only for type checking purposes. Do not add more entries to this list as
  # Gruntwork only supports one shared account.
  # <-- The next line, "shared" cannot be changed. It is an expected key in the AWSAccounts map. It signifies to 
  #     our backend deployment infrastructure that this account's "Role" is to be the shared account. You can only
  #     have one logs account by design. In essence, you cannot change this outer logs key if you want your 
  #     deployment to commence. --> 
  shared:
    # This must be "shared" - you cannot change it or your deployment will error out. Note that the actual account
    # name in AWS does NOT have to be logs. This is only used for cross references and folder names in the
    # reference architecture. 
    - Name: "shared"
      ID: "111111111111"
    
  # Unlike the logs, shared and security accounts, you may select custom names for the app accounts (dev, stage, prod): 

  # The following account roles support more than one entry. They can also be omitted if you have no need for the role
  # (e.g., if you only want stage and prod). In other words, these "App Accounts" as we call them, have more flexibility than logs, shared and security, which all must be singletons
  # That said, you still must preserve this outer "dev:" key. If you want no dev environment, just leave the dev: map empty. If you want multiple "dev" accounts, define them within the "dev:" map below:
  dev:
    - Name: "qa-sandbox"
      ID: "111111111111"
      DomainName: "qa-sandbox.my-company.com"
    - Name: "special-test-wasteland"
      ID: "222222222222"
    - Name: "partner-quality-assurance"
      ID: "333333333333"
    
  stage:
    - Name: "staging1"
      ID: "777777777777"
      DomainName: "staging1.my-company.com"
    - Name: "staging2"
      ID: "888888888888"
      DomainName: "staging2.my-company.com"


  # The same rules apply for prod. You can have 0 or more prod accounts, but you must leave this "prod:" outer key unchanged.
  prod: