Amplify-cli: Deployment and Downtime Clarification

Created on 15 Apr 2020 · 6Comments · Source: aws-amplify/amplify-cli

* Please describe which feature you have a question about? *
Deployments

* Provide additional details*
I have a few general question about deployments and downtime.

During the backend phase of the build when CloudFormation stacks are updating, what kind of downtime should I expect? Does it depend on the change set and services changing? Can you offer some information about how the main services are affected during deployment including AppSync, APIGW, Lambda and DynamoDb?
Similar question to 1 but with respect to the front end deployment phase. How is CloudFront and S3 affected during deployment.

pending-response question

Source

alexkates

Most helpful comment

As everyone said, and just a tip if you didn't think of it. Make sure you don't delete resources in one deployment that your current frontend code depends on / uses, then you can have zero downtime. Deprecate and remove fully in a later deployment when you are sure everyone is on the new frontend version.

houmark on 17 Apr 2020

👍2

All 6 comments

For (1) I'll need to transfer this issue over to the CLI team.

The answer to (2) is there's no downtime. We perform an atomic config change so that the latest assets are served instantly. We also continue to serve the assets for the last 6 deploys (resolving to the latest version if the name is the same but contents are not), so old assets don't suddenly disappear for users currently using the site during a deployment.

adriencg on 15 Apr 2020

Thanks for the timely and detailed response! WRT the front end deployment, this is perfect. Feel free to close/transfer me to the CLI team for the backend answer.

alexkates on 15 Apr 2020

@alexkates The CLI uses Cloudformation to deploy stacks and changes to configurations. The downtime would depend on what changes you're making to your schema or API. If you're deleting a model@ and adding a new one - which your frontend depends on, then you'll have a downtime until the old table is deleted and the new one is created as a part of the Cloudformation deployment. There wouldn't be any downtime if you're just updating an already existing resource.