AWS
S3
route53
CloudFront

Route53+CloudFront+S3の連携

背景

下記のような点を実現したかった。

  • 本番サーバが落ちる等して障害が発生した際でもメンテ画面を表示できる
    • Route53にて障害時の振り分け
  • メンテ画面を検索エンジンにインデックスさせない
    • CloudFrontで設定
  • コストは安く
    • EC2じゃなくS3で
  • 静的ファイルをS3に配置

諸々検討した結果、下記のような環境を構築することにした。
その中の未マスク部分がとりあえず出来たので、
備忘録がてら残しておく。

Screenshot from Gyazo

実現方法

S3

障害時用

  • 専用バケットを作成
  • プロパティ
    • Static website hosting
      • インデックスドキュメントに maintenance.html を指定し、配備する
    • アクセス権限
      • パブリック
      • CORSの設定
        • <AllowedHeader>*</AllowedHeader>
        • <AllowedOrigin>*</AllowedOrigin>

正常時用

  • 専用バケットを作成
  • プロパティ
    • Static website hosting
    • アクセス権限
      • パブリック

注意点

  • ホスティング用のエンドポイントと通常のエンドポイントがあり、動きがちょっと変わってくるので使用する方を注意する

Cloud Front

障害時用

  • 設定
    • Origin Domain Name:障害用s3バケットのStatic website hostingのエンドポイント
      • Screenshot from Gyazo
    • Alternate Domain Names:Route53に登録される、対象domain
    • Default Root Object:index.html
      • 存在しないURLを指定する事で404エラーを発生させ、ErrorPagesで設定したエラー時のレスポンスページを表示
  • Error Pages

静的ファイル用

  • 設定
    • Origin Domain Name:静的ファイル用s3バケットのStatic website hostingのエンドポイント
    • Alternate Domain Names:Route53に登録される、対象domain
  • Behaviors
    • Allowed HTTP Methods:GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
    • Cache Based on Selected Request Headers:All
    • Forward Cookies:All
    • Query String Forwarding and Caching:Forward all, cache based on all

注意点

  • Request内のキャッシュやCookie等諸情報をwebサーバに送るかどうかの指定をBehaviorsでしている。その辺をよく使っているアプリは設定次第で動きが変わる可能性があるので注意する。
    • デフォルトだとRequest情報をほぼほぼwebサーバに送っていない
  • Route53と連携する場合、Route53からCloudFrontへの指定と、CloudFrontからRoute53への指定の両方があり、両方指定しないとうまく動かないので注意
  • エラーページが検索エンジンにインデックスされたらかっこ悪い
  • キャッシュによってコンテンツが反映されない事がよくあるのできちんと確認する

Route53

Hosted zones

障害時用(障害発生時)

  • Name:正常時用と同一
  • Type:A
  • Alias:Yes
    • Alias Target:障害時用のCloudFrontのエンドポイント
  • Routing Policy:Failover
    • Failover Record Type:Secondary

障害時用(正常時)

  • Name:障害時用と同一
  • Type:A
  • Alias:No
    • TTL:60(すぐ切替えられるよう短め)
  • Routing Policy:Failover
    • Failover Record Type:Primary
  • Associate with Health Check:Yes
    • Health Check to Associate:対応するHealth Check

静的ファイル用

  • Name:任意
  • Type:CNAME
  • Alias:No(Yesでも良いかも?)
    • Value(Alias Target):対応するCloudFrontのエンドポイント

Health checks

  • Name:任意
  • Protocol:対応するもの
  • IP address:対応するもの
  • Host name:対応するもの
  • Port:対応するもの
  • Path:対応するもの

TODO

Refs

所感

AWS上の設定項目がバージョンアップしてるのか、記事にある設定と現在のAWSの設定とで一致しない所がたまにあり、
その際の適応が難しかった。
また、設定方法だけ書かれていたりほとんど着目されていない設定項目がどういう動きをするのか不明な所も多い。
AWSというかネットワーク周りの知識が足りてないなーと実感。
まぁ今回の調査でネットワーク周りのAWSの実現はなんとか作れるようになったかな。
あとはアプリ周りも近々やらなー。
Lambda使ってサーバレスなアプリとかも追々。。。