-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: update note on downtime during migration #31307
Conversation
@@ -494,7 +494,8 @@ The following changes will take place: | |||
No, following the migration steps does not cause any replacement of the existing `AWS::CloudFront::Distribution`, `AWS::S3::Bucket` nor `AWS::S3::BucketPolicy` resources. It will modify the bucket policy, create a `AWS::CloudFront::OriginAccessControl` resource, and delete the existing `AWS::CloudFront::CloudFrontOriginAccessIdentity`. | |||
|
|||
**Will migrating from OAI to OAC have any availability implications for my application?** | |||
While the above steps follow the order recommended by CloudFront, updates to CloudFront distributions and S3 bucket policies can take some time to propagate globally. Bucket configuration updates are eventually consistent. As such, you should be aware there is a possibility of downtime. | |||
|
|||
Migrating from OAI to OAC following the steps above (requires a 2-step deployment) should not cause any downtime. However, if you decide to skip Step 1 and migrate to OAC in a single deployment, you should be aware there is a possibility of downtime. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Migrating from OAI to OAC following the steps above (requires a 2-step deployment) should not cause any downtime. However, if you decide to skip Step 1 and migrate to OAC in a single deployment, you should be aware there is a possibility of downtime. | |
Updates to Bucket Policies are eventually consistent, therefore, removing OAI permissions and adding OAC in the same CloudFormation stack deployment is not recommended as it may introduce downtime where CloudFront loses access to the Bucket. Following the steps above will lower this risk ask the Bucket Policy is updated to have both OAI and OAC permissions, then in a subsequent deployment, the OAI permissions are removed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the suggestion is more nuanced - updated the answer :)
Comments on closed issues and PRs are hard for our team to see. |
update note on downtime, 2-step deployment should not cause any downtime