# Restructuring AWS - Proper way to configure AWS Accounts, Organisations and Profiles when using Serverless **URL:** \ **Category:** Serverless Framework\ **Tags:** aws\ **Created:** [July 8, 2018, 11:54am UTC](https://forum.serverless.com/t/restructuring-aws-proper-way-to-configure-aws-accounts-organisations-and-profiles-when-using-serverless/5009 "2018-07-08T11:54:18Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![Vadorequest-SL](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.serverless.com/vadorequest-sl/32/1630_2.png) [@Vadorequest-SL](https://forum.serverless.com/u/Vadorequest-SL)\ **Post date:** [February 21, 2019, 6:49pm UTC](https://forum.serverless.com/t/restructuring-aws-proper-way-to-configure-aws-accounts-organisations-and-profiles-when-using-serverless/5009/12 "2019-02-21T18:49:25Z")
Indeed, you need to create the ACM certificate in the AWS Account you’ll use it. You cannot create it on another account, it won’t be usable. Must be within the same account. (you can create a ACM certificate with the same domain names in separated accounts though, there is no conflict about that) I am not quite sure if you fixed all your issues, but I had eventually documented the whole thing internally. Here it is, hope it helps. * * * ## Configure an application, with each stage running in a different AWS Account The AWS configuration to run an app with each stage living in a different AWS Account is a bit tedious, to say the least. ### ACM Certificate limitation For instance, it is not possible for an AWS Account to access another AWS Account’s ACM Certificates. This means that each certificate must be created in the proper AWS Account. Therefore, there is a certificate for each stage. Also, when configuring additional custom domain (like `my-budget-advisor.com`, which acts as the end-user production website for `hep.the-funding-place.org`), the certificate must contain all domain names, like `my-budget-advisor.com` and `hep.the-funding-place.org` otherwise there will be a SSL handshake failure. This implies to know the final end-user domain name when creating the production certificate, or to have to create another certificate later, and replace the certificate used by the Custom Domain once issued. ### Steps overview The domain should have been bought from the Root AWS Account. Since we don’t want to deploy anything on `the-funding-place.org` itself but only on sub-domains then we don’t have to change anything on the apex domain. Instead, we’ll create a Hosted Zone for each domain you need to create, in the appropriate AWS Account (staging, production, etc.) Then, we’ll create a “NS” Record Set for each of those domains, so that the requests going to a domain are handled by this domain. This allows each stage to handle its own DNS properly _(unlike it was done with `unly.org` and `staging.unly.org`)_ and therefore allows developers to deal with DNS of the stage they have access to, instead of configuring all DNS through the AWS Root Account. (which is neither developer-friendly, nor practical, nor a good design but rather a noobie mistake [that one’s on me!]) ### Steps to follow - Example with [demo.the-funding-place.org](http://demo.the-funding-place.org) Now that we know a bit more about the limitations we have to deal with, let’s look at the step to setup the whole thing: 1. Connect to the AWS Console with your usual AWS Account, which has cross-accounts privileges (ability to go to other AWS Accounts) 2. Switch to the production account of your application, for instance `[production] TFP` in our case (cross account) 3. Switch to the AWS Root Account (you need to leave the cross-account mode by clicking on “Back to YOUR\_EMAIL”) [Only an admin can do that because need write access to the AWS Account “Root”] 4. Nice! Now, the DNS settings defined in the `[production] TFP` AWS Account are applied to `demo.the-funding-place.org` and we can now create the ACM certificate 5. Switch to the production account of your application, for instance `[production] TFP` in our case (cross account) 6. Nice! Your production setup is ready, let’s try to see if we can generate the custom domain by running `sls create_domain`, you must configure the `NODE_ENV` and `stage` properly or it won’t work: `GROUP_NAME=demo NODE_ENV=production sls create_domain -s demo` You should get a message like 7. Now that the custom domain is being created, let’s setup the `staging` environment 8. Switch to the staging account of your application, for instance `[staging] TFP` in our case (cross account) 9. Switch to the production account of your application, for instance `[production] TFP` in our case (cross account) 10. Nice! Now, the DNS settings defined in the `[staging] TFP` AWS Account are applied to `staging.demo.the-funding-place.org` and we can now create the ACM certificate 11. Switch to the staging account of your application, for instance `[staging] TFP` in our case (cross account) 12. Nice! Your staging setup is ready, let’s try to see if we can generate the custom domain by running `sls create_domain`, you must configure the `NODE_ENV` and `stage` properly or it won’t work: `GROUP_NAME=staging.demo NODE_ENV=staging sls create_domain -s demoStaging` You should get a message like Finger in the nose, right? Yeah, that’s what documentation is for. I bet you wish you had to figure all this out by yourselves 😉 I did. 😅 --- _[View the full topic](https://forum.serverless.com/t/restructuring-aws-proper-way-to-configure-aws-accounts-organisations-and-profiles-when-using-serverless/5009)._