#refarch (2023-06)

must be in a public subnet as well

for RDS, it’s three things that need to be addressed to access it from the internet:

1. Network level - must be in a public subnet or accessible via internet in any other way. Also check if in the subnet where the RDS is deployed assigning public IPs at launch is enabled

1. Security group level - check if the SG allows the access

1. DNS level - publicly_accesible set to true (which creates a public DNS endpoint for the RDS instance), which you did

i guess you are missing #1 (or related to it)

i’ll double check everything

it looks like it’s associated to the private subnets in the code. is that intentional? https://github.com/cloudposse/terraform-aws-components/blob/main/modules/aurora-postgres/cluster-regional.tf#L24

the component is opinionated, it’s intentional since it’s best practice to deploy it into private subnets (and (almost) never in public)

the module supports both private and public

the component can def be updated to support both using a flag

i’m still struggling getting pubic access. i updated that line to concat the public and private subnets

subnets = concat(local.private_subnet_ids, local.public_subnet_ids)

and the SG is allowing inbound and outbound traffic from/to 0.0.0.0/0

does this network acl (for public subnet) look normal?

after concating, is the instance in a public subnet?

under rds > subnet groups > xxx-ue1-dev-xxx-db-shared? yes, i see the public subnets

public and private

strange. i destroyed and recreated it, and it seems to work now

Looks like the tfstate-backend root module in the cloudposse/terraform-aws-components repo still points to an old version of cloudposse/tfstate-backend/aws in the terraform registry. Hmm.

I guess this means I just have to write my own root module to use the newer version of the tfstate-backend?

You could always vendor the tfstate-backend and then bump the version of the downstreamed module to the latest version. The components are a reusable base and are owned by the consumer. The modules are re-usable and unchange-able except by PR. This gives you freedom in the components (root tf module/dir) to modify as desired.

https://github.com/cloudposse/terraform-aws-components/blob/83f0021cd63c9148b76135fc24ce769d852b39ec/modules/tfstate-backend/main.tf#L7

https://github.com/cloudposse/terraform-aws-tfstate-backend/releases

@Jeremy G (Cloud Posse) @Max Lobur (Cloud Posse)

Correct, I’m about to release that fix for V5, expect today

The workaround would be to pin aws provider to “<5” if it doesn’t brake you anything else

https://github.com/cloudposse/terraform-aws-components/pull/716/files

@Dan Miller (Cloud Posse) @Max Lobur (Cloud Posse) I uploaded the latest changes.

@Nat Williams before we can answer in the best way, can you instead lead by what you want to accomplish (want to avoid xyproblem.info)

in general, a Spacelift stack name is calculated from the context + the Atmis component name.

The context is: namespace, tenant, environment, stage

let’s say you have:

the Spacelift stack names for these two Atmos components will be:

although:

1. Spacelift stack name can be overridden (per Atmos component)
2. The order of the context variables can be overridden in atmos.yaml
3. Which context variables are used in the stack names is set in atmos.yaml (e.g. you might not use namespace and tenant, in which case the Spacelift stack names will be

Yeah, considering it a bit more, I guess it’s not really a Spacelift thing at all. I think ultimately I’m just surprised that vpc-1 doesn’t show up in the output of atmos terraform generate varfile

I would expect that to be in the name var

the name var - you set it as well

it’s part of the context which is used to uniquely and consistently name the AWS resources

yeah, I just didn’t want to have to do it myself

in many cases the name var can be the same as the Atmos component name

but in some cases they are different

are we supposed to create the emails ahead of time?

if youre using plus addressing, these emails will all go to the same address. And we typically will create a new Slack channel for notifications and then set up an email integration with the primary email address

Ah okay thanks!

Is the primary email the email in the management account?

it should be the base email that you used. [email protected] for example, so then each account would be [email protected], [email protected], etc

https://docs.cloudposse.com/reference-architecture/how-to-guides/implementation/enterp[…]ement-aws-cold-start/how-to-set-up-aws-email-notifications/

this page also has some of our initial set up before even the cold start https://docs.cloudposse.com/reference-architecture/quickstart/kick-off/#slack

(full disclosure, those are behind our paywall)

@Dan Miller (Cloud Posse) now knowing how this works is it possible to redeploy the component and update the emails?

I am not sure if Terraform can update account emails via the API. It’s now supported (as in AWS added support for that in the past ~6 mo), however, we’ve not tested it.

Historically, it’s a MAJOR PIA to get your account emails wrong.

crap

(it’s bitten us too)

I deployed them as

aws+%[email protected]

It should have been

devops+%[email protected]

Aha

not sure what to do

Well, the worst case is just create the [[email protected]](mailto:[email protected]) alias

on the devops group

Then it will just work as expected. You can do resets.

what do you mean by devops group?

[devops+%[email protected]](mailto:devops+%[email protected])

Our standard recommendation is to make this a group (aka distribution list, aka google group)

Not a user account.

ah ha okay

Since nothing is deployed on the member accounts could I just delete them all and just deploy again with the correct email?

@Erik Osterman (Cloud Posse) nvm got it working with the alias! Thank you so much!

you can put in an AWS service request to change that email, but it can take several days. But since you have the alias now and it’s not blocking you, you could put in that request now to eventually get those emails corrected

Awesome thanks for your help guys!

Did you get it resolved?

I sure did!

this is not directly related to Atmos. You have to first create a backend before you have a backend to store the TF state in. So you create it using the local backend (TF will store the state on your local computer), then you define (or uncomment) the S3 backend, and TF will ask you to copy the local state to the remote S3 backend

see https://github.com/cloudposse/terraform-aws-tfstate-backend

(in Atmos, you can comment out the S3 backend definition first, create the backend, then uncomment it, then run terraform plan again, and TF will ask you to copy the state from local to S3)

Thanks for the quick response.

Conceptually, this is how it works: https://github.com/cloudposse/terraform-aws-tfstate-backend/tree/main#create

In our reference architecture, here’s how we do it:

Create a workflow file like this to automate it

workflows:
  init/tfstate:
    description: Provision Terraform State Backend for initial deployment.
    steps:
      - command: terraform deploy tfstate-backend -var=access_roles_enabled=false --stack core-{{ region_0 }}-root --auto-generate-backend-file=false
      - command: until aws s3 ls {{ cookiecutter.namespace }}-core-{{ region_0 }}-root-tfstate; do sleep 5; done
        type: shell
      - command: terraform deploy tfstate-backend -var=access_roles_enabled=false --stack core-{{ region_0 }}-root --init-run-reconfigure=false

Oh, replace that {{ region_0 }} with your region.

and replace {{ cookiecutter.namespace } with your namespace

I will have a try once I am out of all the Monday meeting to see how far I get. I am sure I will have further questions.

Maybe I am missing something here. I have the following structure

I use .env in the root to define my environment variables in an .envrc

so when I cd in to the directory my environment variables get set

My atmos.yml is the default one

I create a workflow under stacks to boot strap the environment

I create a stack/component

module "terraform_state_backend" {
  source = "cloudposse/tfstate-backend/aws"
  # Cloud Posse recommends pinning every module to a specific version
   vrsion     = "1.1.1"
  namespace  = var.namespace
  stage      = var.stage
  name       = "env-init"
  attributes = ["state"]

  terraform_backend_config_file_path = "."
  terraform_backend_config_file_name = "backend.tf"
  force_destroy                      = false
}

I run

atmos workflow init/tfstate -f env-init.workflow -s ../../components/terraform/infra-init/main.tf --dry-run

get the following error

So the issue the first is this include path

included_paths: 40 - “orgs/*/” 1 # Can also be set us in atmos.yaml

If I remove it I get

It appears your workspace is misconfigured. There shouldnt be a plat-gbl-root, since root is not a platform account and is typically in core. But that’s difficult to debug without seeing code

Do you have a single account component? Where is that deployed? Could you perhaps share that catalog configuration?

In particular, I’d like to check what your organization_config looks like. It should be something like this:

      organization_config:
          root_account:
            name: core-root
            stage: root
            tenant: core
            tags:
              eks: false
          accounts: []
          organization:
            service_control_policies: []
          organizational_units:
            - name: core
              accounts:
                - name: core-auto
                  tenant: core
                  stage: auto
                  tags:
                    eks: true
                - name: core-identity
                  tenant: core
                  stage: identity
                  tags:
                    eks: false
                - name: core-network
                  tenant: core
                  stage: network
                  tags:
                    eks: false
              service_control_policies:
                - DenyLeavingOrganization
            - name: plat
              accounts:
                - name: plat-dev
                  tenant: plat
                  stage: dev
                  tags:
                    eks: true
                - name: plat-sandbox
                  tenant: plat
                  stage: sandbox
                  tags:
                    eks: true
                - name: plat-staging
                  tenant: plat
                  stage: staging
                  tags:
                    eks: true
                - name: plat-prod
                  tenant: plat
                  stage: prod
                  tags:
                    eks: true
              service_control_policies:
                - DenyLeavingOrganization

and that component (account) should only be deployed once by the core-gbl-root stack