How to introduce resiliency with AWS S3 bucket without any downtime
up vote
0
down vote
favorite
We have a S3 hosted static web application. Here are some more details about its hosting. We have hosted it on AWS. We have route53 entry pointing to cloudfront which in turn points to S3 bucket.
To make sure we are resilient, we plan to go for CRR(cross-region replication) for our S3 bucket. But that is only part of the solution to make our app resilient. We have three approaches in mind.
Approach 1
Create a health check on route53 to check s3 bucket availability in primary region. If we get a 503 error, we trigger a lambda which updates cloudfront origin to be s3 bucket from secondary region. But this approach would give us 30-40mins of downtime as cloudfront update takes that much time of propogate.
Approach 2
This approach involves route53 entry pointing to cloudfront entry and in case of failure from health check for S3 and cloudfront, have failover pointing directly to the secondary S3 bucket named. More details here: https://read.iopipe.com/multi-region-s3-failover-w-route53-64ff2357aa30
Downside of this approach is during failover, we would be over HTTP instead of HTTPS. This is again not acceptable
Approach 3
Deploy your application in two regions with two addresses. If one region goes down, you can add logic in cloudfront to redirect to second address. This again looks like a overkill but most acceptable approach till now
Can someone point out which approach should we go with. Is approach 3 our only option given the constraints. Also, if you know some other better approach, that would be awesome. I read AWS documentation about using lambda@edge but I am not sure if that would work. Suggestions?
amazon-web-services amazon-s3
asked Nov 20 at 14:45
Ravi Chaudhary
9319
add a comment |
up vote
0
down vote
favorite
We have a S3 hosted static web application. Here are some more details about its hosting. We have hosted it on AWS. We have route53 entry pointing to cloudfront which in turn points to S3 bucket.
To make sure we are resilient, we plan to go for CRR(cross-region replication) for our S3 bucket. But that is only part of the solution to make our app resilient. We have three approaches in mind.
Approach 1
Create a health check on route53 to check s3 bucket availability in primary region. If we get a 503 error, we trigger a lambda which updates cloudfront origin to be s3 bucket from secondary region. But this approach would give us 30-40mins of downtime as cloudfront update takes that much time of propogate.
Approach 2
This approach involves route53 entry pointing to cloudfront entry and in case of failure from health check for S3 and cloudfront, have failover pointing directly to the secondary S3 bucket named. More details here: https://read.iopipe.com/multi-region-s3-failover-w-route53-64ff2357aa30
Downside of this approach is during failover, we would be over HTTP instead of HTTPS. This is again not acceptable
Approach 3
Deploy your application in two regions with two addresses. If one region goes down, you can add logic in cloudfront to redirect to second address. This again looks like a overkill but most acceptable approach till now
Can someone point out which approach should we go with. Is approach 3 our only option given the constraints. Also, if you know some other better approach, that would be awesome. I read AWS documentation about using lambda@edge but I am not sure if that would work. Suggestions?
amazon-web-services amazon-s3
asked Nov 20 at 14:45
Ravi Chaudhary
9319
1
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
We have a S3 hosted static web application. Here are some more details about its hosting. We have hosted it on AWS. We have route53 entry pointing to cloudfront which in turn points to S3 bucket.
To make sure we are resilient, we plan to go for CRR(cross-region replication) for our S3 bucket. But that is only part of the solution to make our app resilient. We have three approaches in mind.
Approach 1
Create a health check on route53 to check s3 bucket availability in primary region. If we get a 503 error, we trigger a lambda which updates cloudfront origin to be s3 bucket from secondary region. But this approach would give us 30-40mins of downtime as cloudfront update takes that much time of propogate.
Approach 2
This approach involves route53 entry pointing to cloudfront entry and in case of failure from health check for S3 and cloudfront, have failover pointing directly to the secondary S3 bucket named. More details here: https://read.iopipe.com/multi-region-s3-failover-w-route53-64ff2357aa30
Downside of this approach is during failover, we would be over HTTP instead of HTTPS. This is again not acceptable
Approach 3
Deploy your application in two regions with two addresses. If one region goes down, you can add logic in cloudfront to redirect to second address. This again looks like a overkill but most acceptable approach till now
Can someone point out which approach should we go with. Is approach 3 our only option given the constraints. Also, if you know some other better approach, that would be awesome. I read AWS documentation about using lambda@edge but I am not sure if that would work. Suggestions?
amazon-web-services amazon-s3
asked Nov 20 at 14:45
Ravi Chaudhary
9319
We have a S3 hosted static web application. Here are some more details about its hosting. We have hosted it on AWS. We have route53 entry pointing to cloudfront which in turn points to S3 bucket.
To make sure we are resilient, we plan to go for CRR(cross-region replication) for our S3 bucket. But that is only part of the solution to make our app resilient. We have three approaches in mind.
Approach 1
Create a health check on route53 to check s3 bucket availability in primary region. If we get a 503 error, we trigger a lambda which updates cloudfront origin to be s3 bucket from secondary region. But this approach would give us 30-40mins of downtime as cloudfront update takes that much time of propogate.
Approach 2
This approach involves route53 entry pointing to cloudfront entry and in case of failure from health check for S3 and cloudfront, have failover pointing directly to the secondary S3 bucket named. More details here: https://read.iopipe.com/multi-region-s3-failover-w-route53-64ff2357aa30
Downside of this approach is during failover, we would be over HTTP instead of HTTPS. This is again not acceptable
Approach 3
Deploy your application in two regions with two addresses. If one region goes down, you can add logic in cloudfront to redirect to second address. This again looks like a overkill but most acceptable approach till now
Can someone point out which approach should we go with. Is approach 3 our only option given the constraints. Also, if you know some other better approach, that would be awesome. I read AWS documentation about using lambda@edge but I am not sure if that would work. Suggestions?
amazon-web-services amazon-s3
amazon-web-services amazon-s3
asked Nov 20 at 14:45
Ravi Chaudhary
9319
asked Nov 20 at 14:45
Ravi Chaudhary
9319
edited Nov 20 at 14:54
asked Nov 20 at 14:45
Ravi Chaudhary
9319
asked Nov 20 at 14:45
Ravi Chaudhary
9319
asked Nov 20 at 14:45
Ravi Chaudhary
9319
9319
1
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07
add a comment |
1
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07
1
1
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Thanks to @Krease for pointing out the perfect solution. AWS allows you to create origin groups which allows you to have you secondary or failover S3 bucket. More details can be found here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
answered Nov 21 at 6:12
Ravi Chaudhary
9319
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53395509%2fhow-to-introduce-resiliency-with-aws-s3-bucket-without-any-downtime%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Thanks to @Krease for pointing out the perfect solution. AWS allows you to create origin groups which allows you to have you secondary or failover S3 bucket. More details can be found here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
answered Nov 21 at 6:12
Ravi Chaudhary
9319
add a comment |
up vote
1
down vote
accepted
Thanks to @Krease for pointing out the perfect solution. AWS allows you to create origin groups which allows you to have you secondary or failover S3 bucket. More details can be found here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
answered Nov 21 at 6:12
Ravi Chaudhary
9319
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Thanks to @Krease for pointing out the perfect solution. AWS allows you to create origin groups which allows you to have you secondary or failover S3 bucket. More details can be found here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
answered Nov 21 at 6:12
Ravi Chaudhary
9319
Thanks to @Krease for pointing out the perfect solution. AWS allows you to create origin groups which allows you to have you secondary or failover S3 bucket. More details can be found here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
answered Nov 21 at 6:12
Ravi Chaudhary
9319
answered Nov 21 at 6:12
Ravi Chaudhary
9319
answered Nov 21 at 6:12
Ravi Chaudhary
9319
answered Nov 21 at 6:12
Ravi Chaudhary
9319
9319
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53395509%2fhow-to-introduce-resiliency-with-aws-s3-bucket-without-any-downtime%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
For approach 1 - CloudFront used to take that much time to propagate (over a year ago) - it’s much faster in general now. And for the most part, propagation to American/European regions is even faster (usually well before it’s marked “done”). Have you tried using the multiple-origin feature of CF? It can do this fallback behaviour you’re describing automatically
– Krease
Nov 20 at 16:59
Thanks @Krease. Origin group works perfectly for this use case.
– Ravi Chaudhary
Nov 21 at 6:07