Amplify-cli: How to create PROD environment from my DEV environment?

Created on 27 Jul 2020  Â·  12Comments  Â·  Source: aws-amplify/amplify-cli

@ericclemmons @RossWilliams Currently happily using aws-amplify v1.1.29, other versions have left my project shaky so i am happy in this one. I'm almost at a stage where i'm ok to have my amplify project (which i believe i set up with a DEV denomination), to a PROD one.

Could someone let me know, step by step how i can safely make a duplicate/replica PROD environment of my DEV environment?
Also, how, when i'm happy with updates in DEV, how do i safely make these changes available in the PROD environment?

p.s. i'm not using GitHub

Thanks

documentation multienv platform question

Most helpful comment

You can create many environments at practically zero cost as long as you don't use the @searchable directive. The cli command is:
amplify env add
and follow the prompts to create a new environment. Then you can push to that environment
amplify push --yes
and switch back and forth between environments
amplify env checkout DEV|PROD|TEST|NEXT

For my iOS app I switch back and forth between environments by using a ENV files that holds information about user pool ids, client ids, endpoints, etc. I then setup a schema in XCode for each environment and set the ENVFILE environment variable for the run process. I also change the bundle ID and display name for each environment so that i can have 4 versions of my app on a phone at once.

What you need to remember about deploying to production - after the initial deployment, you can't modify more than 1 GSI at a time on each DynamoDB table. You need to be aware that if you schema evolves greatly, you then need to plan out multiple deploys.

For production you need to consider a few other items. These are some random things to check that I can remember off the top of my head. You likely want to consult a more general "how to manage an AWS account" guide:

  1. Cloudwatch alarms. Do you have proper alerting setup for all of your componenents? You may want to run a filter across logs, or just use existing metrics to create alarms.
  2. Cloudtrail alarms. Very similar to cloudwatch, make sure nothing strange is going on.
  3. Guard Duty monitoring.
  4. Cognito limits - you need to request service limit increases if you are using things like SMS MFA, by default the limit is just $1.
  5. Setup an email address to send email from rather than using the Cognito default. If you do use your own domain for email sending, make sure things like SPF, DKIM, DMARC are setup.
  6. Billing alerts - consider setting up multiple alerts to keep an eye on spend.
  7. Check you Lambda memory size, the default of 128MB might not have great performance.
  8. Set an alert when production is updated to catch any production updates you aren't expecting.
  9. Lock your root account away and don't use it. Consider creating a base console login that is readonly. You don't want to be in the habit of changing resources through the console.
  10. Remember if your app is behind a login Apple will need an account to test your app.
  11. If you need to seed your database with data, you may want to create a Lambda that does this and setup a custom resource in cloudformation for it to run when you create a new environment.
  12. Update your cloudwatch log expiry time. you don't want to pay for piles of log data you don't need.

All 12 comments

Do you want prod to be in the same AWS account or a different one? Are you using a git provider like gitlab or bitbucket? Are you planning on using Route 53 for DNS? Is this a webpage or mobile app? Do you want to use Amplify to host the web page?

Tell me more about your goals and setup and I can give better advice

Hi @RossWilliams, great questions. I'd ideally like to have this in the same AWS account. I'm not using gitlab or bitbucket. No plans to use Route 53. Not using Amplify to host web pages at all.

I also have another AWS account. So if it's safer to separate the two (keep my existing the Dev, and the other the Prod) but still be able to push Dev updates to the Prod in this other AWS account, then i'm all ears. Else, let's stick with one AWS account.

I have a react native project that i've built for an iOS mobile app with an Amplify (Dev) backend. In my current dev environment, i have: Auth, Api, Storage (S3), Analytics and i've used AppSync (with GraphQL API) to interact with DynamoDB. And having users log in via Cognito.

I guess, what i'm afraid of is this Dev env is my one and only working Amplify project and i want to make sure i can make updates to this, test them here and then when ready, 'push' these changes to a Prod env that the users of the mobile app will then experience. But i need the steps/commands for the safest way to do this.

You can create many environments at practically zero cost as long as you don't use the @searchable directive. The cli command is:
amplify env add
and follow the prompts to create a new environment. Then you can push to that environment
amplify push --yes
and switch back and forth between environments
amplify env checkout DEV|PROD|TEST|NEXT

For my iOS app I switch back and forth between environments by using a ENV files that holds information about user pool ids, client ids, endpoints, etc. I then setup a schema in XCode for each environment and set the ENVFILE environment variable for the run process. I also change the bundle ID and display name for each environment so that i can have 4 versions of my app on a phone at once.

What you need to remember about deploying to production - after the initial deployment, you can't modify more than 1 GSI at a time on each DynamoDB table. You need to be aware that if you schema evolves greatly, you then need to plan out multiple deploys.

For production you need to consider a few other items. These are some random things to check that I can remember off the top of my head. You likely want to consult a more general "how to manage an AWS account" guide:

  1. Cloudwatch alarms. Do you have proper alerting setup for all of your componenents? You may want to run a filter across logs, or just use existing metrics to create alarms.
  2. Cloudtrail alarms. Very similar to cloudwatch, make sure nothing strange is going on.
  3. Guard Duty monitoring.
  4. Cognito limits - you need to request service limit increases if you are using things like SMS MFA, by default the limit is just $1.
  5. Setup an email address to send email from rather than using the Cognito default. If you do use your own domain for email sending, make sure things like SPF, DKIM, DMARC are setup.
  6. Billing alerts - consider setting up multiple alerts to keep an eye on spend.
  7. Check you Lambda memory size, the default of 128MB might not have great performance.
  8. Set an alert when production is updated to catch any production updates you aren't expecting.
  9. Lock your root account away and don't use it. Consider creating a base console login that is readonly. You don't want to be in the habit of changing resources through the console.
  10. Remember if your app is behind a login Apple will need an account to test your app.
  11. If you need to seed your database with data, you may want to create a Lambda that does this and setup a custom resource in cloudformation for it to run when you create a new environment.
  12. Update your cloudwatch log expiry time. you don't want to pay for piles of log data you don't need.

@RossWilliams Hi Ross, on the first step when doing amplify env add it asks next, would you like to use an existing environment? When i select 'yes' for my Dev environment it carries on initialising the environment. At the moment i want to replicate Dev, with everything in it (Auth, Api) and call that the new Prod environment.

So far, i haven't even been asked to name my new environment 'Prod'. You only get that when you opt NOT to use an existing environment. But if i do that, i assume this new environment will be empty (i.e. i'd have to start over again adding Auth and Api manually). Defeats the purpose of wanting to replicate the Dev to a Prod. What is the route to take to get to a Prod version of my Dev environment and its contents?

@chai86 If you create a new env from 'dev' and create the new env 'prod' - it will clone the dev infrastructure and you don't have to add auth and api manually. On an amplify push the resources will be deployed to the new environment.

@kaustavghosh06 That's good to know that i don't have to add another Auth and Api all over again. For Auth, i'm the main Cognito user so Dev or Prod would have the same config

This is where i'm at:

amplify env add
? Do you want to use an existing environment? Yes
? Choose the environment you would like to use: dev

Using default provider  awscloudformation
✔ Initialized provider successfully.
Initialized your environment successfully.

Is this right, then iamplify push ? Will this clone my 'dev' infrastructure. How do i know it's a Prod?

I haven't at any point so far mentioned that i want a 'prod' environment.

If i do this, then i can name the environment XYZ, but will it clone my 'dev' infrastructure?

amplify env add
? Do you want to use an existing environment? No
Enter a name for the environment: XYZ

Yup, it'll clone the dev env in the xyz env. Give it a shot and let me know if you have any questions.
When you run amplify status, you can see your current env.

@kaustavghosh06 Which option?

? Do you want to use an existing environment?Yes OR No?

No - if you're creating or cloning a new env.

@kaustavghosh06 Thanks! I can see when doing an amplify env checkout dev oramplify env checkout prod i'm in different environments with exactly the same Auth and Api resources names in each. Perfect

I'llamplify push these changes and see how it changes things in the cloud.

Awesome! You can find more documentation out here - https://docs.amplify.aws/cli/teams/overview

Looks like the issue here has been resolved. Closing the issue. Feel free to open a new issue if the PR doesn't fully address your concern.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MageMasher picture MageMasher  Â·  3Comments

nicksmithr picture nicksmithr  Â·  3Comments

jeanpaulcozzatti picture jeanpaulcozzatti  Â·  3Comments

adriatikgashi picture adriatikgashi  Â·  3Comments

zjullion picture zjullion  Â·  3Comments