[AWS]S3オブジェクトのHTTPステータスコードをカスタマイズして計画メンテナンスページを構築
計画メンテナンスでサイトを一時的に閉じる時、ブラウザでアクセスしてくる一般ユーザにはメンテナンスページを返せば十分だけれども、 検索ボットにはメンテナンスページの HTTP ステータスコードを 503:Service Unavailable で返すのが好ましい。 Official Google Webmaster Central Blog: How to deal with planned site downtime メンテナンスページは静的という前提のもと、AWS の DNS サービス route53 と CDN サービス CloudFront とストレージサービス S3 を組み合わせで実現してみる。 route53-ELB-EC2 というようなサーバ構成の場合、メンテナンスの前後で route53 の Alias Target を本番用の ELB からメンテナンスページ用の Cloud
![[AWS]S3オブジェクトのHTTPステータスコードをカスタマイズして計画メンテナンスページを構築](https://cdn-ak-scissors.b.st-hatena.com/image/square/71f62b9097bffd670134a848ff8c4b8ef71ccd3e/height=288;version=1;width=512/https%3A%2F%2Fsiguniang.files.wordpress.com%2F2015%2F01%2Froute53-cloudfront.png)
ELB用のSorryサーバをCloudFormationで構築 – Gezarで一発「ごめんなさい」 | DevelopersIO
よく訓練されたアップル信者、都元です。以前、Amazon ELBでSorryサーバへのフェイルオーバーを実現するというエントリにて、ELB配下に正常なインスタンスが1つも無くなった時にSorryページを表示する方法をご紹介しました。 その後、Route53のヘルスチェックにELBを指定できるようになったり *1、フェイルオーバーの機能は順次強化されてきています。 このRoute53のフェイルオーバー先にはS3を指定できます。S3の可用性は非常に高いため、もうWebシステムのフェイルオーバーは完璧。…かと思いきや、実はそうでもありません。 まずRoute53を使わない場合はどうしようもありません。まぁ、使えよって話ですが。 S3は「あらゆるパスへのリクエストに対して同じコンテンツを返す」ということができません。強引にやろうとするとリダイレクトをする、という解決策になってしまいます。理想として
S3+CloudFront+Route53で503なSorryページを安価に実現する - hiroohiのメモ
Amazon Route53のフェイルオーバー機能を使ってサイトのメンテナンス(Sorry)ページを表示しようとするとき、 お手軽にS3のwebホスティングでsorry画面を出してしまうと、ステータスコードが200や403になるため、検索エンジンにSorry画面が登録されてしまいます。 ちょっと恥ずかしいです。 それを防ぐために、シンガポールregion等に一番安いEC2インスタンスをたてて、sorry画面を出すwebサーバを動かしてたのですが、 S3+CloudFrontでステータスコード503を出すsorryページを運用できそうなので、やってみました。 S3に適当なbucketを作り、sorryページ用のhtmlや画像をアップする。 ※画像やcssはサイト相対パスで参照するとはがれないです。 CloudFrontディストリビューションを作る Origin Domain Nameには上で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
