accounts.yaml in Quickstart

[GervaisdeM-SpryPoint]

Hi Folks,

Is there a way to have an account be used for multiple stages? I'm early on in working through the reference architecture. I am now at the stage "Prepare Account Deployment" and I am taking heed of the warning, "If you aren't confident about the email configuration, account names, or anything else, now is the time to make changes or ask for help." :)

The existing account structure in the accounts.yaml will not work for us. What we want to do is create an OU for each of our customers and then have two accounts for each customer/OU. One would be for "prod" and the other account would be for all their lower environments which can include some, or all of the following: dev, test, staging.

In the reference architecture example, there is an OU for "plat" and then a separate account (with an associated stage) for each stage.

Questions:

1. Is it possible for an account to be references for multiple stages?
2. How would that be represented in the yaml?
3. Would this create other issues or require changes that we may need to consider in other places in the Quickstart?

Would something like this work to replace the plat entries in the accounts.yaml?

          organizational_units:
            - name: cust1
              accounts:
                - name: cust1-non-prod
                  tenant: cust1
                  stage:
                    - dev
                    - staging
                    - test
                    - demo
                  tags:
                    eks: false
                - name: cust1-prod
                  tenant: cust1
                  stage: prod
                  tags:
                    eks: false                    
            - name: cust1
              accounts:
                - name: cust2-non-prod
                  tenant: cust2
                  stage:
                    - staging
                  tags:
                    eks: false
                - name: cust2-prod
                  tenant: cust2
                  stage: prod
                  tags:
                    eks: false

[milldr]

No there is not a way with the Terraform variables inputs for account to define a reusable stage pattern across many OUs. Each account needs to be defined in the given OU. For example, I recently had to provision an organization with 40+ accounts and had a very long account.yaml stack configuration.

However, I consider this a benefit. When working with highly privileged components, especially the account component that has the power to destroy any AWS account, DRY-ness may not be beneficial. It's better to be clear about the account structure than save a bit of time on the initial cold start.

With that said, I think you may be missing a key piece. We try to align any single stage to a single account. A stage and an account are 1:1. So you wouldn't have a cust1-non-prod account; you would have cust2-dev, cust2-staging, cust2-test, and cust2-demo accounts. The reasoning behind that decision is in regards to account boundaries, which you can read more about here: https://docs.cloudposse.com/layers/accounts/#account-boundaries

[osterman]

@milldr I think it's possible using YAML anchors.

[milldr]

I thought that as well, but each account needs the tenant and name defined. It may be possible. But it's over-complicating a sensitive configuration, so I stick by my argument

[osterman]

Nevermind, since the account names contain the OU, there's no way to use YAML anchors.

[osterman]

Ok, so the other way may be to templatize the account config. Then pass the list of tenants in the context to the import. Then you can create a proper factory.

[osterman]

@GervaisdeM-SpryPoint here's how you can accomplish what you want to do:

Solution

1. Rename catalog/account.yaml to catalog/account.yaml.tmpl
2. Find where account is imported, and replace it with something like this:

   import:
    - path: "catalog/account.yaml.tmpl"
      context:
        tenants:
          - name: acme
          - name: foo
          - name: bar
      skip_templates_processing: false
      ignore_missing_template_values: true

3. Update your account.yaml.tmpl like this:

    components:
    terraform:
      account:
        vars:
            # ... deleted everything else to focus on solution 
            # you should keep what is there.
            organizational_units:
              # ... Other OUs define here
              {{ range .tenants }}
              - name: {{ .name }}
                accounts:
                  - name: {{ .name }}-dev
                    tenant: {{ .name }}
                    stage: dev
                    tags:
                      eks: true
                  - name: {{ .name }}-sandbox
                    tenant: {{ .name }}
                    stage: sandbox
                    tags:
                      eks: true
                  - name: {{ .name }}-staging
                    tenant: {{ .name }}
                    stage: staging
                    tags:
                      eks: true
                  - name: {{ .name }}-prod
                    tenant: {{ .name }}
                    stage: prod
                    tags:
                      eks: true
                service_control_policies:
                  - DenyLeavingOrganization
              {{ end }}
          service_control_policies_config_paths: []

Outcome

I tested this locally, and got this:

test:
    components:
        terraform:
            account:
                atmos_component: account
                atmos_manifest: deploy/test
                atmos_stack: test
                atmos_stack_file: deploy/test
                backend: {}
                backend_type: ""
                command: terraform
                component: account
                env: {}
                inheritance: []
                metadata: {}
                overrides: {}
                providers: {}
                remote_state_backend: {}
                remote_state_backend_type: ""
                settings: {}
                stack: test
                vars:
                    account_email_format: aws+cplive-%[email protected]
                    account_iam_user_access_to_billing: DENY
                    aws_service_access_principals:
                        - cloudtrail.amazonaws.com
                        - guardduty.amazonaws.com
                        - ipam.amazonaws.com
                        - ram.amazonaws.com
                        - securityhub.amazonaws.com
                        - servicequotas.amazonaws.com
                        - sso.amazonaws.com
                        - auditmanager.amazonaws.com
                        - config.amazonaws.com
                        - config-multiaccountsetup.amazonaws.com
                        - malware-protection.guardduty.amazonaws.com
                    enabled: true
                    enabled_policy_types:
                        - SERVICE_CONTROL_POLICY
                        - TAG_POLICY
                    organization_config:
                        accounts: []
                        organization:
                            service_control_policies:
                                - DenyEC2InstancesWithoutEncryptionInTransit
                        organizational_units:
                            - accounts:
                                - name: core-analytics
                                  stage: analytics
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-artifacts
                                  stage: artifacts
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-audit
                                  stage: audit
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-auto
                                  stage: auto
                                  tags:
                                    eks: true
                                  tenant: core
                                - name: core-corp
                                  stage: corp
                                  tags:
                                    eks: true
                                  tenant: core
                                - name: core-dns
                                  stage: dns
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-identity
                                  stage: identity
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-marketplace
                                  stage: marketplace
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-network
                                  stage: network
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-public
                                  stage: public
                                  tags:
                                    eks: false
                                  tenant: core
                                - name: core-security
                                  stage: security
                                  tags:
                                    eks: false
                                  tenant: core
                              name: core
                              service_control_policies:
                                - DenyLeavingOrganization
                            - accounts:
                                - name: acme-dev
                                  stage: dev
                                  tags:
                                    eks: true
                                  tenant: acme
                                - name: acme-sandbox
                                  stage: sandbox
                                  tags:
                                    eks: true
                                  tenant: acme
                                - name: acme-staging
                                  stage: staging
                                  tags:
                                    eks: true
                                  tenant: acme
                                - name: acme-prod
                                  stage: prod
                                  tags:
                                    eks: true
                                  tenant: acme
                              name: acme
                              service_control_policies:
                                - DenyLeavingOrganization
                            - accounts:
                                - name: foo-dev
                                  stage: dev
                                  tags:
                                    eks: true
                                  tenant: foo
                                - name: foo-sandbox
                                  stage: sandbox
                                  tags:
                                    eks: true
                                  tenant: foo
                                - name: foo-staging
                                  stage: staging
                                  tags:
                                    eks: true
                                  tenant: foo
                                - name: foo-prod
                                  stage: prod
                                  tags:
                                    eks: true
                                  tenant: foo
                              name: foo
                              service_control_policies:
                                - DenyLeavingOrganization
                            - accounts:
                                - name: bar-dev
                                  stage: dev
                                  tags:
                                    eks: true
                                  tenant: bar
                                - name: bar-sandbox
                                  stage: sandbox
                                  tags:
                                    eks: true
                                  tenant: bar
                                - name: bar-staging
                                  stage: staging
                                  tags:
                                    eks: true
                                  tenant: bar
                                - name: bar-prod
                                  stage: prod
                                  tags:
                                    eks: true
                                  tenant: bar
                              name: bar
                              service_control_policies:
                                - DenyLeavingOrganization
                        root_account:
                            name: core-root
                            stage: root
                            tags:
                                eks: false
                    organization_enabled: true
                    service_control_policies_config_paths: []
                    stage: test
                workspace: test

[GervaisdeM-SpryPoint]

Thanks for all the input. I love your template @osterman and I see how I might even extend it so that I can only create an account for stages that certain customers have (as not all of them have all stages).

My concern and reason for my question is with the amount of customers and stages that we have today, I will have to create hundreds of accounts. We plan to grow aggressively and will end up creating many, many more.

I was also considering some cost savings... For example, all non-prod could share a database (Aurora Serverless) or ecs (Fargate) cluster.

[osterman]

Yes, so there are tons of things that can be done to keep configurations DRY. Almost always, the concern is making them overly DRY.

As you come across other specific challenges, share them here and we can some techniques on optimizing them.

[GervaisdeM-SpryPoint]

Yes, so there are tons of things that can be done to keep configurations DRY. Almost always, the concern is making them overly DRY.

As you come across other specific challenges, share them here and we can some techniques on optimizing them.

How do you feel about my concern that I would end up creating about 400 accounts if I try to create 1 for every tenant-stage?
Perhaps this is going to have to wait until Wednesday's customer workshop 😞

[osterman]

There's no technical limitation for this. You will need to talk to AWS about increasing your limits, if you do go down this route. The real risk could be financial. Does your revenue per tenant financially support a fully dedicated account (e.g. with VPC, NAT gateways, load balancers, etc)