Amplify ConsoleとCloudFront+S3のユースケースの違い

AWS S3 CloudFront Amplify

概要

最近Amplify ConsoleからCloudFront+S3へ移行する検討をしたり実際に移行したので、それぞれの違いをまとめてみました。


まとめ

  • Amplify Consoleは手軽だけどそれ以上のことはできない（しづらい）
    • 気軽にリリースしたい・開発環境で気軽に動作確認したい場合にベスト
    • Amplifyにオールインワンで作れて楽(CI/CDも含む)
      • インフラ/AWSの知識もそこまでいらない


  • CloudFront+S3は設定の手間があるがいろいろできる
    • 細かい設定ができる
      • セキュリティ要件がある場合や大規模環境・本番環境などに安心
    • コード書くことでさらになんでもできる


※以下では「Amplify Console」を略して「Amplify」と記載しています。


Amplify Consoleの特徴

特徴（メリット）

  • Amplifyにオールインワンで作れる
    • フロントエンドとバックエンドも1つで管理できる
    • ※今回バックエンド(API)の方の話はスコープ外としています


  • 手軽に作れる
    • AWS、CICD、DNS、IaC(Infrastructure as Code)の知識少なめでもデプロイや環境構築ができる
      • テスト・ビルド・デプロイ設定（CICD）
      • カスタムドメイン設定
    • amplifyで作ってもAWS内部でS3・CloudFrontが作られるが、隠蔽されてAWS上で見えない・触れないので、良くも悪くも意識しなくて済む


  • リダイレクト設定・カスタムヘッダー設定も簡単



  • Basic認証とかの機能もつけられる
    • CloudFrontだとコードで実装の必要がある
    • 一応AWS WAFだけでもBasic認証できるので、CloudFront + S3でもノンコーディングで可能ではある(あまりWAFではやらない)


補足

  • amplify CLIで作成するとS3/CloudFrontがAWS上で見える・触れるようになるので、amplifyで作成後に手を加えられるようになるが、気軽さが失われるのでそれならCloudFrontから作ればいいかと
    • そもそも「手を加えられる」＝「その知識がある」
    • AWSリソース責務がamplifyとCloudFront各々に散らばるので、そこまでするなら個人的にはamplifyやめた方がいいのではと
      • 管理が辛い
      • 用途が合ってない可能性(※それがベストな可能性もあります)


CloudFront + S3の特徴

特徴（メリット）

  • Lambda@edge、CloudFront Functionsが使える(リクエスト/レスポンス間にコードの処理を挟める)
    • いろいろできるようになる
      • リクエスト・レスポンス整形
        • セキュリティ要件などでHTTPレスポンスに動的にセキュリティ系ヘッダー入れたりしたい場合などがよくあるケース
        • ★2021年11月より、CloudFront単体でレスポンスヘッダーを設定できるようになりました
      • カスタムなロギング
      • カスタムなアクセス制限
      • Basic認証
      • etc...


  • カスタムエラーページの導入/遷移・レスポンスやステータスコードの動的変更が可能
    • Lambda@edge、CloudFront Functionsを使わなくてもできる
      • CloudFrontの機能やWAFの機能で
        • AWS WAFのカスタムエラーレスポンス機能がかなり便利
    • amplifyだとリダイレクト設定ならできるがステータスコードはリダイレクト系に限定(選択式)


  • AWS WAF（Web Application Firewall：セキュリティサービス）が挟める
    • 基本的なアプリケーションレイヤーの攻撃が防げる
      • AWSの提供するマネージドルールにより、既知の攻撃を設定のみで防げる
        • AWSが管理している世界のIPブラックリストからブロックしたり
        • レートベースでアクセスブロックも可
          • 例：5分間に同じIPからn件以上アクセス来たらブロック
          • ※DDoSはCloudFrontと連携しているAWS Shieldというサービスがブロックしてくれる
      • 「動的コンテンツ(API)じゃないのでWAFはなくてもいい」と言う意見もあるが、静的コンテンツでも一部のXSSやディレクトリトラバーサル攻撃等は可能なので、あった方が安心
    • IP制限などもWAFで簡単・動的にできる
      • アプリケーションコードにIPホワイトリストを含まなくていいので疎な管理・反映ができる
        • アプリのライフサイクルとは違うので
          • アプリの変更はないのにIP変更のためにバージョンが上がるの辛い
      • 自前コーディングがいらない
      • DBとかもいらない
      • (Systems Manager Parameter StoreなどにIPホワイトリストを格納して管理すればアプリケーションでのIP管理も可能。ロジック実装の手間はあるが)


  • S3,CloudFrontの細かいパラメータ設定が可能
    • キャッシュTTL・キャッシュポリシー
    • パスパターンなどでのマルチオリジン
      • amplifyはモノレポはできるがマルチオリジンとは違う
    • セキュリティポリシー(TLSバージョン)
    • CDN反映先の国の制限
    • バケットポリシーによるアクセス制限変更
      • あまりないが、運用バッチなどでS3直アクセスしたい場合などを想定
    • その他いろいろetc...


  • DNSレコードをCNAMEではなくAliasレコード(CNAMEを内部でAレコードに変換)で設定可
    • amplifyのカスタムドメイン設定ではCNAMEレコードになる
      • CNAMEレコード
        • Aliasレコードと比べるとDNSルックアップのパフォーマンスが落ちる
        • ネイキッド（Zone Apex）ドメインをCNAMEで設定してしまうと、他にそのドメインのサブドメインを使用したCloudFrontを何も作れなくなってしまう(=CNAME Existsエラー)


補足

  • S3のみによる「S3静的ホスティング」という方法もありますが、詳細は割愛。
    • S3静的ホスティング
      • CloudFrontがいらないので手軽
      • httpになってしまう（httpsができない）
      • S3へのパブリックアクセスを許容するので色々と面倒（詳細は割愛）
      • CDNじゃないのでキャッシュ系が不便だったり
    • 「S3静的ホスティング + CloudFront」という手法もありますが、こちらも詳細は割愛。



※Twitter始めました！

良かったらぜひ。

Twitter ID → @365_step_tech