Reference Architecture account names
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. --- <ins datetime="2022-06-14T14:03:26Z"> <p><a href="https://support.gruntwork.io/hc/requests/108766">Tracked in ticket #108766</a></p> </ins>
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`](https://docs.aws.amazon.com/organizations/latest/APIReference/API_CreateAccount.html#API_CreateAccount_RequestSyntax) 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: ```yaml 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: ```