Amazon SAA-C03: コンテンツ配信、エッジ、パフォーマンス最適化 — 学習ガイド

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

こちらの一部です： AWS SAA-C03 — 完全学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

Amazon CloudFrontの概要と利点

Amazon CloudFrontは、600以上のPoP (ポイントオブプレゼンス) に基づいて構築された、グローバルに分散されたコンテンツ配信ネットワークです。その役割は、最も近いエッジでビューワーのTLSを終端し、キャッシュされたレスポンスを即座に提供するか、キャッシュミスしたリクエストをAWSのプライベートバックボーン経由でオリジンにプロキシすることです。パフォーマンス上の利点は2つあります。キャッシュヒットはラウンドトリップタイムを1桁ミリ秒に短縮し、オリジンの負荷を完全にオフロードします。一方、キャッシュミスの場合でも、エッジでの最適化されたTLS/TCP終端、HTTP/2およびHTTP/3のサポート、オリジンへのkeep-alive接続の再利用、そしてノイズの多いパブリックインターネットを回避するバックボーン経由の転送によってメリットが得られます。

よくある誤解は、CloudFrontは静的アセットの高速化にしか役立たないというものです。CachingDisabledポリシーを使用してCloudFrontの背後にALBを配置すると、動的なAPIのパフォーマンスも向上します。なぜなら、ビューワーのハンドシェイクがオリジンリージョンまでインターネットを経由するのではなく、ローカルのPoPで完了するからです。これを混合ワークロード、例えばS3から提供される/static/*とALBから提供される/api/*と組み合わせることで、1つのディストリビューションで両方を処理できます。

Distribution:
  Aliases: [www.example.com]
  ViewerCertificate: ACM cert in us-east-1
  Origins:
    - Id: s3-static
      DomainName: static-assets.s3.us-east-1.amazonaws.com
      S3OriginConfig:
        OriginAccessControlId: !Ref OAC
    - Id: alb-dynamic
      DomainName: alb-1234.us-east-1.elb.amazonaws.com
      CustomOriginConfig: { OriginProtocolPolicy: https-only }
  DefaultCacheBehavior:
      TargetOriginId: alb-dynamic
      CachePolicyId: CachingDisabled
      OriginRequestPolicyId: AllViewer
  CacheBehaviors:
    - PathPattern: /static/*
      TargetOriginId: s3-static
      CachePolicyId: CachingOptimized
    - PathPattern: /api/*
      TargetOriginId: alb-dynamic
      CachePolicyId: !Ref ShortTtlPolicy

次に、Route 53のエイリアスレコードでwww.example.comをディストリビューションのd123.cloudfront.netに向けます。エイリアスレコードは無料で、CloudFrontのエニーキャストIPに直接解決されます。

証明書はus-east-1に配置する

カスタムドメインで提供されるCloudFrontディストリビューションの場合、AWS Certificate Managerのビューワー向けTLS証明書は、オリジンのバケット、ALB、またはユーザーの場所に関係なく、必ずus-east-1 (バージニア北部) で発行されている必要があります。CloudFrontはグローバルサービスであり、そのコントロールプレーンはus-east-1に固定されています。エッジロケーションはそのリージョンから証明書を取得します。S3バケットがたまたまeu-west-1にあるからという理由でACM証明書をそのリージョンでリクエストするのは誤ったパターンです。ディストリビューションはその証明書を認識できません。

aws acm request-certificate \
  --domain-name media.example.com \
  --validation-method DNS \
  --region us-east-1

CloudFrontとALBオリジンとの間で2回目のTLS終端を行う場合、そのオリジン向けの証明書はALBのリージョンに配置します。us-east-1に固定されるのは、ビューワー向けの証明書だけです。同じルールがAPI Gatewayのエッジ最適化カスタムドメイン（内部でAWSが管理するCloudFrontディストリビューションを使用）にも適用されます。証明書はus-east-1にある必要があります。対照的に、リージョンAPI Gatewayエンドポイントは、API自体のリージョンにある証明書を使用します。

S3オリジンに対するOrigin Access Control

S3バケットをパブリックにしたままCloudFrontを前面に配置すると、目的が損なわれます。ビューワーはS3のRESTエンドポイントに直接アクセスすることでCloudFrontをバイパスし、WAF、地理的制限、署名付きURL、キャッシュの利点を回避してしまい、データが漏洩する可能性があります。

現代的な解決策は**Origin Access Control (OAC)**であり、これはレガシーなOrigin Access Identity (OAI)を置き換えるものです。OACはSigV4署名を使用し、SSE-KMSをサポートし、すべてのS3リージョン（2022年以降に開設されたリージョンを含む）で機能し、動的リクエストをサポートします。パブリックアクセスブロックは有効のままにし、ACLは不要です。バケットポリシーでは、CloudFrontサービスプリンシパルにのみ読み取りアクセスを許可し、さらに特定のディストリビューションARNで制約をかけます。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowCloudFrontServicePrincipal",
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::media-example-com/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCDEF"
      }
    }
  }]
}

OAIもまだ機能しますが、レガシーと見なすべきです。新規の作業では常にOACを選択してください。

キャッシュの正確性

キャッシュの有効性は、オリジンが返すCache-ControlおよびExpiresヘッダーと、CloudFrontキャッシュポリシーの最小/デフォルト/最大TTLの組み合わせによって決まります。フィンガープリントされた不変のアセットは積極的にキャッシュすべきです。それらを参照するHTMLシェルは、デプロイが伝播するようにキャッシュ期間を短くする必要があります。認証済みJSONは、共有CDNでは一切キャッシュしてはいけません。

Cache-Control: public, max-age=31536000, immutable   # fingerprinted assets
Cache-Control: public, max-age=60, s-maxage=300      # HTML that changes
Cache-Control: private, no-store                      # authenticated JSON

対称的な2つの罠がよくあります。第一に、オリジンがキャッシュヘッダーを返さない場合、CloudFrontはディストリビューションのデフォルトTTLにフォールバックし、動的なレスポンスを何時間も暗黙的にキャッシュしてしまう可能性があります。第二に、キャッシュすべきアセットに対して一律にCache-Control: no-cacheを設定すると、すべてのリクエストがオリジンに戻ってしまい、CDNの利点が失われます。

最も危険な罠は、適切なヘッダーなしでパーソナライズされたレスポンスをキャッシュすることです。もし/account/dashboardがユーザーAに特化したHTMLを返すのに、オリジンがno-storeを省略し、キャッシュポリシーのキャッシュキーに認証ヘッダーやクッキーが含まれていない場合、エッジはユーザーAのページをユーザーBに喜んで提供してしまいます。このようなレスポンスにはprivate, no-storeを付けるか、セッション識別子をキャッシュキーに含めてヒット率の低下を受け入れるかのどちらかです。

EC2オンデマンドインスタンスのAuto Scalingグループが静的コンテンツを提供しているコスト最適化シナリオでは、アセットをS3に移動し、OACを設定したCloudFrontを前面に配置し、ASGを廃止または縮小するのが正しい再設計です。これにより、コストが時間単位のコンピューティングからリクエスト単位の配信に移行し、静的ワークロードにとっては桁違いに安価になります。

署名付きURL、署名付きCookie、および地理的制限

CloudFrontは署名付きURL（単一オブジェクトへの時間制限付き、オプションでIP制限付きのアクセス — 購入した動画のダウンロード、一度きりのPDFリンクなど）と署名付きCookie（パスパターンに一致する多数のオブジェクトへのアクセス — カタログを閲覧する認証済み加入者など）をサポートしています。どちらも、公開鍵をCloudFrontにアップロードした信頼されたキーグループを使用します。秘密鍵は、有効期限、ソースIP範囲、またはURLパターンを指定するポリシーに署名します。

https://d123.cloudfront.net/premium/movie.mp4
  ?Expires=1735689600
  &Signature=...
  &Key-Pair-Id=APKAI...

これはS3の署名付きURLとは異なります。S3の署名付きURLはCloudFrontをバイパスし、バケットへの直接アクセスを許可します。CloudFrontの署名付きURLをOACと組み合わせることで、バケットはエンドツーエンドでプライベートな状態を保ちます。

地理的制限は、リクエストがキャッシュやオリジンに到達する前に、ディストリビューションレベルで国単位の許可リストまたはブロックリストを強制します。これはCloudFrontが維持するGeoIPデータベースを使用し、ライセンスによる禁輸措置を強制するための安価でキャッシュバイパスを防ぐメカニズムです。より細かいロジック（州レベル、ヘッダーの組み合わせなど）が必要な場合はCloudFront FunctionやLambda@Edgeを、完全なルールエンジンが必要な場合はWAFを使用します。

AWS Global Accelerator

Global AcceleratorはCDNではなく、キャッシュもしません。AWSのエッジロケーションからグローバルにアドバタイズされる2つの静的なエニーキャストIPv4アドレス（またはBYOIP）をプロビジョニングします。クライアントのTCPまたはUDP接続は、最寄りのエッジでAWSバックボーンに入り、AWSのプライベートネットワークを介して、トラフィックダイヤルと重みを持つエンドポイントグループにグループ化された1つ以上のリージョン内の最も正常なエンドポイント（ALB、NLB、EC2、またはElastic IP）にルーティングされます。

静的IPには3つの具体的なメリットがあります。バックエンドが再設計されてもクライアントやファイアウォールの許可リストは変更不要であること、ヘルスチェックの変更に応じてエンドポイントグループ間でトラフィックを移動させることでリージョンフェイルオーバーが数秒で完了し、DNSのTTL伝播を完全にバイパスできること、そしてTCPハンドシェイクはエッジで終端され、長距離通信はAWSのバックボーン上で実行されることです。

Global Acceleratorを選択する場合：

• プロトコルが非HTTPである場合：ゲームやVoIP向けのUDP、MQTT、SIP、SFTP、カスタムTCP。
• エンタープライズの許可リストやアドレスをハードコードするモバイルアプリのために静的IPが必要な場合。
• ステートフルなアクティブ/アクティブ構成のために1分未満のリージョンフェイルオーバーが必要な場合。
• ワークロードが動的でキャッシュ不可能であり、CDNの価値がほとんどない場合。

CloudFrontを選択する場合：

• コンテンツがキャッシュ可能である場合（画像、動画セグメント、静的HTML、TTL付きのAPIレスポンス）。
• Lambda@EdgeまたはCloudFront Functionsによるエッジコンピューティングが必要な場合。
• エッジでのWAF、署名付きURL/Cookie、またはフィールドレベル暗号化が必要な場合。

避けるべき2つの罠があります。「ゲームサーバーをグローバルに高速化する」ためにCloudFrontを選択するのは失敗です。なぜなら、ゲームはUDPでありキャッシュ不可能だからです。Global Acceleratorが必要です。逆に、静的ウェブサイトにGlobal Acceleratorを選択すると、高価（時間単位の固定料金＋GB単位の料金）になり、キャッシュの利点を放棄することになります。CloudFrontならオリジンからのデータ転送量を劇的に削減できます。グローバルに分散しているが単一リージョンのHTTP APIで、ユーザーがレイテンシーを許容できる場合、単純なRoute 53のレイテンシーベースルーティングで十分であり、どちらよりも安価な場合があります。

グローバルトラフィックのためのRoute 53ルーティングポリシー

Route 53はクライアントが解決するエンドポイントを決定し、その後CloudFrontまたはGlobal Acceleratorが接続を処理します。グローバルアーキテクチャでは、3つのポリシーが主に使われます。

レイテンシーベースルーティングは、リゾルバーの場所から各リージョンまでの実際のネットワークレイテンシーを測定し、最も高速なものを返します。複数のリージョンに同一のスタックがあり、ユーザーをその時点で最も高速なリージョンに誘導したい場合に使用します。

地理的近接性ルーティングは、レイテンシーベースではなく座標ベースです。各エンドポイントの場所（またはAWSリージョン）を宣言すると、Route 53はユーザーを地理的に最も近い場所に送信します。その特徴は、有効なサービスエリアを拡大または縮小するバイアス値（-99から+99）です。これは、リージョンのローンチ中に徐々にトラフィックを移行したり、メンテナンスのためにリージョンからトラフィックを抜いたりするのに役立ちます。地理的近接性ルーティングにはRoute 53トラフィックフロー（トラフィックポリシー）が必要で、通常は各リージョンのリージョンNLBまたはALBと組み合わせて使用されます。

RecordSets:
  - Region: eu-west-1
    Endpoint: nlb-eu.example.internal
    Bias: +30       # expand EU service area during launch
  - Region: us-east-1
    Endpoint: nlb-us.example.internal
    Bias: 0
  - Region: ap-southeast-1
    Endpoint: nlb-ap.example.internal
    Bias: 0

フェイルオーバールーティングは、ヘルスチェックに紐付いたプライマリ/セカンダリのペアを使用します。これはDNSレベルのフェイルオーバーであり、TTLとリゾルバーのキャッシュの影響を受けるため、Global Acceleratorのデータプレーンフェイルオーバーよりも低速です。数分程度のDNS伝播が許容できる単純なアクティブ/パッシブ構成にはフェイルオーバールーティングを、数秒単位での切り替えが必要な場合はGlobal Acceleratorを選択します。

これらのポリシーは組み合わせることができます。一般的なグローバルパターンは、Route 53のレイテンシーまたは地理的近接性レコードがGlobal Accelerator（TCP/UDP用）またはCloudFront（キャッシュ可能なHTTPS用）を指し、その下にセーフティネットとしてヘルスチェック付きのフェイルオーバーレコードを配置する構成です。この階層化は意図的なものです。Route 53がリージョンを選択し、Global AcceleratorまたはCloudFrontがエッジとバックボーン経由のパスを選択し、リージョン内のロードバランサーがリージョン内のターゲットを選択します。

API Gatewayのエンドポイントタイプとカスタムドメイン

API Gatewayは、それぞれ異なるトポロジーを持つ3つのエンドポイントタイプを提供します。

エッジ最適化エンドポイントは、APIを直接設定できないAWSマネージドのCloudFrontディストリビューションでラップします。これは迅速なグローバル展開には便利ですが、独自のキャッシュビヘイビア、WAFルール、またはオリジンリクエストポリシーが必要な場合には制約となります。最大限の制御を得るための典型的なパターンは、顧客管理のCloudFrontディストリビューションを前面に配置したリージョンエンドポイントです。

証明書の配置はCloudFrontのルールに従います。エッジ最適化カスタムドメインにはus-east-1のACM証明書が必要であり、リージョンエンドポイントにはAPIと同じリージョンの証明書が必要です。HTTP APIは最低でもTLS 1.2を強制し、REST APIはTLS 1.3までのセキュリティポリシーをサポートします。

ACM証明書: 発行、検証、インポート

ACMは、パブリックTLS証明書を無料で発行し、自動更新します。CloudFront、API Gateway、ALB、NLB、その他のAWSサービスと直接統合されています。検証方法にはDNS検証（ACMが提供するCNAMEをRoute 53または任意のDNSプロバイダーに設定。レコードが存在する限り、ACMは永久に自動更新）とEメール検証（更新ごとに手動でクリックが必要で、自動化には脆弱）があります。本番環境では、DNS検証が正しいデフォルトの選択肢です。

ACMが発行した証明書はエクスポートできず、統合されたAWSサービス以外では使用できません。規制やビジネス要件により特定のサードパーティCAが必須となる場合（例えば、特定の商用発行者にチェーンし、TLS 1.3を強制する必要があるREST APIなど）、ACM発行の証明書は使用できません。その場合は、要求されたCAから証明書を取得し、ACMにインポートしてから、TLS 1.3セキュリティポリシーを持つリージョナルAPI Gatewayのカスタムドメインにアタッチします。

インポートには2つの罠があります。インポートされた証明書は自動更新されないため、有効期限が切れる前に再インポートしないとエンドポイントは完全に停止します。また、ACMはインポート時にチェーンを検証しないため、壊れた中間証明書は実際のクライアントからのハンドシェイク時に初めて問題として表面化します。展開前に、厳格なクライアントに対して完全なチェーンをテストしてください。

S3 Transfer Acceleration vs. CloudFront

CloudFrontがダウンロードを最適化するのに対し、S3 Transfer Accelerationはアップロードを最適化します。Transfer Accelerationは、同じCloudFrontエッジネットワークを逆方向に利用します。PUTリクエストは最寄りのエッジに入り、AWSバックボーンを経由して宛先バケットのリージョンに到達します。これは、世界中に分散したユーザーが、単一リージョンのバケットに大きなオブジェクトをアップロードする場合に特に効果を発揮します。例えば、世界中のフィールドエンジニアが数ギガバイトの図面をus-east-1にアップロードするようなケースです。

この2つの機能は同じバケット上で共存できます。Transfer Accelerationを有効にし、ダウンロード用にはOACを持つCloudFrontディストリビューションを公開します。オブジェクトが小さい場合や、クライアントがバケットのリージョンにすでに近い場合は、Transfer Accelerationはメリットなくコストを増加させるだけです。導入を決定する前に、S3 Transfer Accelerationの速度比較ツールで測定してください。アクセラレーションを有効にするには、クライアントはs3-accelerateエンドポイントを使用する必要があります。

レイヤー7保護のためのAWS WAF

AWS WAFは、保護対象リソースに到達する前にHTTP(S)リクエストを検査します。CloudFrontディストリビューション、ALB、API Gatewayステージ、AppSync API、Cognitoユーザープール、App Runnerサービス、Verified Accessインスタンスにアタッチできます。ウェブACLには、URI、ヘッダー、クエリ文字列、ボディ（デフォルトで最大8KB、ALB/API Gatewayでは64KBまで拡張可能）、IPセット、地理的位置情報に基づいて照合するルールが含まれます。

最も一般的な構成要素はAWSマネージドルールです。AWSManagedRulesCommonRuleSetとAWSManagedRulesKnownBadInputsRuleSetはOWASPのトップエクスプロイトをカバーし、AWSManagedRulesSQLiRuleSetとXSSマッチステートメントはインジェクションを処理します。カスタムルールでは、地理的マッチング（コンプライアンスのための国別許可/ブロックリスト）、IPセットマッチング、そしてレートベースのルールを追加できます。レートベースのルールは、送信元IPあたりのリクエスト数を5分間のローリングウィンドウでカウントし、しきい値を超えるとブロックします。これはHTTPフラッドやクレデンシャルスタッフィングに対する第一の防御線です。

{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 500,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/login",
          "FieldToMatch": {"UriPath": {}},
          "PositionalConstraint": "STARTS_WITH",
          "TextTransformations": [{"Priority":0,"Type":"NONE"}]
        }
      }
    }
  },
  "Action": {"Block": {}}
}

リージョンのルールが重要です。 CloudFront用のウェブACLはグローバルであり、us-east-1で作成する必要があります。リージョナルリソース（ALB、API Gatewayなど）用のウェブACLは、リソース自身のリージョンで作成します。

S3上の静的サイトを保護する場合、WAFをバケットにアタッチすることはできません。S3はWAFがサポートするリソースではないためです。正しいパターンは、バケットの前にCloudFront + OACを配置し、ウェブACLをそのディストリビューションにアタッチすることです。バケットがCloudFront経由でしか到達できないようにすることで、「すべてのトラフィックを検査する」という要件が真に満たされます。

複数アカウントにまたがるWAFガバナンスのためのFirewall Manager

WAFをアカウントごとに管理する方法はスケールしません。Organization全体で、あるチームが企業のベースラインをアタッチせずに新しいALBを立ち上げると、コンプライアンス体制が静かに後退してしまいます。AWS Firewall Managerは、対象範囲内のアカウントとリソースに対して組織全体のポリシーを強制することで、この問題を解決します。

前提条件は、全機能が有効化されたAWS Organizations、指定されたFirewall Manager管理者アカウント、そして各メンバーアカウントでAWS Configが有効になっていることです。ポリシータイプには、AWS WAF、AWS Shield Advanced、セキュリティグループ（監査と使用状況）、Network Firewall、Route 53 Resolver DNS Firewall、およびサードパーティ製ファイアウォールが含まれます。

WAFポリシーは、「最初」のルールグループ（アプリケーション所有のルールの前に評価）、「最後」のルールグループ（後に評価）、またはウェブACLを完全に置き換えることを強制できます。リソーススコープに一致する新しいALBやCloudFrontディストリビューションは、自動的に企業のルールセットを受け取ります。また、非準拠のリソースはフラグが立てられ、修復設定に応じて自動的に修正されます。シナリオに「複数アカウント」「一元管理」「組織全体で一貫したWAFルール」といった言葉が出てきた場合、答えはアカウントごとのWAFではなくFirewall Managerです。

Shield Standard と Shield Advanced の比較

WAFだけでDDoSを阻止できると考えるのは重大な間違いです。WAFは到達したリクエストに対して動作します。アプリケーションレイヤーのフラッド攻撃、クレデンシャルスタッフィング、既知の脆弱性利用シグネチャに対しては非常に優れていますが、レイヤー3/4での大規模なボリューム型攻撃（SYNフラッド、UDPリフレクション）はAWS Shieldによって吸収されます。

Shield Standardは、追加料金なしでデフォルトで有効になっています。一般的なL3/L4攻撃を自動的に防御し、CloudFront、Route 53、Global Acceleratorに適用されます。また、ELB、EC2、その他のリソースにも基本的な保護を提供します。攻撃固有の可視性、Shield Response Team（SRT）による対応、コスト保護は提供されません。

Shield Advanced（組織ごとに月額3,000ドル、1年間のコミットメント）では、以下が追加されます。

Shield Standardが「コスト保護と専門家による対応を備えた大規模DDoS対策」に十分であると考えるのは間違いです。なぜなら、Standardには可視性、コスト保護、SRTへのアクセスが欠けているからです。オリジンがELBの背後にあるEC2で、DNSがサードパーティ製（そのためRoute 53のエイリアスレコードは利用不可）の場合、推奨されるパターンは、ELBでShield Advancedを有効にし、アプリケーションの前面にCloudFront（同様にShield Advancedで保護）を配置することです。これにより、緩和の境界をエッジに移動させ、リージョンに到達する攻撃対象領域を縮小できます。

正しい階層型の防御態勢は次のとおりです。L3/L4のボリューム型攻撃にはShield、L7のフィルタリングにはWAF、両サービスがアタッチされるエッジのエントリポイントとしてCloudFrontまたはGlobal Accelerator、そしてすべてのアカウントにわたってポリシーを強制するためにFirewall Managerを使用します。

← ネットワーキングと接続性 · すべてのドメイン · データベースとキャッシング →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →