セミナー参加レポート: AWS Shield / Amazon CloudFront DDoS対策セミナー(2)

こんにちは。Riot.js推しのエンジニア小林です。

2017年3月23日に開催されたAWS Shield / Amazon CloudFront DDoS対策セミナーに参加してきましたのでレポートしたいと思います。

CloudFrontによるDDoS対策

発表内容レポート

  • ホットキーワード
    • Regional Edge Cache
    • エッジロケーションとオリジン間に設置する中間キャッシュサーバを追加コストなしで自動的に利用可能に
      • オリジンサーバへの負荷を軽減できる
    • Lambda@Edge
    • Lambdaベースの処理をCloudFrontのエッジロケーションで実行できる
  • CLoudFrontはWebサービス提供のベストプラクティス
    • 大量のアクセスを処理する数々の手法をフルマネージドで提供
    • Anti-DDoSも大量アクセスのひとつとして考え、CloudFrontを可能な限り使うのが基本戦略

サイトまるごとCloudFront

  • 基本的にバックエンドの改修は不要
典型的Webアプリの構成要素
Static Assets
  1. S3から配信
    • S3からCloudFrontへのデータ転送は無償
  2. Origin Access Identity(OAI)の利用
    • 特別なCloudFrontユーザーがOAIを使う
    • S3側はOAIなしには読み取り許可をしない
  3. CloudFront上のコンテンツの権限設定
    • 方法は2つ
      • Signed URLs
      • Signed Cookies
  4. ブラウザキャッシュの利用
    • max-ageをヘッダに指定
    • HTML5であれば application Cache
  5. Edge Cachingの利用
    • 中間キャッシュサーバ用のs-maxageを長くする
    • ヘッダ、クエリ文字列、クッキーの転送をしない
      • CORSをしない限り必要ない
  6. オブジェクトにバージョン付与
    • 更新とロールバックを容易にするため
      • ファイル名を変更する
      • クエリ文字列を利用する
Dynamic Content
  1. キャッシュ可能なものはキャッシュする
    • Popular Objects Reportの利用
      • アクセス上位50URLを示す
      • その中から少しでもキャッシュ可能なコンテンツを探す
  2. 複数のキャッシュ制御条件を使う
    • 必要なヘッダだけを転送
      • 例: /imagesにはクッキー転送不要
    • User-Agentヘッダは使わない
    • 全クッキーの転送は止める
      • 必要とするクッキーだけを転送する
  3. モニタ、アラーム、通知の利用
    • CloudFrontはほぼリアルタイムのモニタとアラームがCloudWatch経由で提供
  4. エラーページをカスタマイズ
    • ユーザー体験向上につながる
    • エラーページはS3を使う
    • エラーページのキャッシュTTLは短くする
      • 例: 15秒
  5. Design for Failure
    • Route 53のヘルスチェック機能の利用

感想

ここ最近で担当している案件がそこまで大規模システムでは無かったためCloudFront要る?という状況でしたが、とにかくCloudFrontは入れておいて損はない、むしろ入れろといった感じでした。想像以上に細かい指定ができ、特にOAIは知らなかったので活用していきたいと思います。ただCloudFrontはエッジロケーションにある関係で設定反映に時間がかかるので気軽にいじれないのが難点。。。