概要

このドキュメントでは、CloudFront、Lambda@Edge、AWS WAF などの AWS エッジサービスの設定に変更を導入するためのベストプラクティスの概要を示しています。これらの変更には、CloudFront 関数コードの更新、Lambda@Edge 関数のランタイムの変更、CloudFront での新しいキャッシュ動作の追加、WAF ルールの更新、HTTP/3 などの新しい CloudFront 機能の有効化が含まれる場合があります。比較的静的でシンプルな構成で、手動管理用の UI を好む場合は、AWS コンソールを使用できます。ただし、より複雑なセットアップの場合は、CI/CD パイプラインを活用して、設定変更とコード更新を制御された方法でデプロイすることをお勧めします。

CI/CD Pipeline

コードとしてのインフラストラクチャ (IaaC)

CI/CD パイプラインは、自動化によって開発速度を高め、コード品質を高め、ヒューマンエラーを減らすことで、ソフトウェアのリリースサイクルを強化します。CloudFront などの AWS エッジサービスとエッジ機能は、Infrastructure as Code (IaC)を使用して CI/CD パイプライン内で管理できます。エッジリソースは、API (CloudFront の API など)、 AWS CLI 、または CloudFormation 、 Terraform 、AWS Cloud Development Kit (CDK) などの高レベルの抽象化ツールを介してデプロイできます。

CDK ベースの IaC

CloudFormation をベースとする CDK は、プログラミング言語を使用して AWS リソースをデプロイできるようにすることで、最高レベルの抽象化を実現します。たとえば、次の 3 行の JavaScript コードでは、CloudFront をオリジンとして S3 バケットをデプロイできます。

const myBucket = new s3.Bucket(this, 'myBucket');
new cloudfront.Distribution(this, 'myDist', {
  defaultBehavior: { origin: new origins.S3Origin(myBucket) },
});

CDK コードに含める再利用可能なコンストラクトについては、CDK コンストラクトライブラリを確認してください。

デプロイとオーケストレーション

CI/CD パイプラインには、コード (CDK コード、エッジ関数コード)を保存するための AWS CodeCommit などのリポジトリ、インフラストラクチャをデプロイするための AWS CodeDeploy などのツール、パイプラインステップを管理するためのAWS CodePipeline などのオーケストレーションツールが必要です。このブログ記事では、AWS 開発者ツールを使用して CloudFront の CI/CD パイプラインを実装する方法を説明していますが、お好みの CI/CD ツールを使用することもできます。AWS エッジサービスの CI/CD パイプラインを構築するときは、次の制限を考慮してください：

  • CloudFront、CloudFront Functions、およびリージョンのAWS WAFウェブACLは、どの AWS リージョンからでもデプロイできます
  • CloudFront の Lambda @Edge と WAF WAF Web ACL は、バージニア州北部の米国東部 1 リージョンからのみデプロイできます。
  • ファイアウォールマネージャーポリシーは、ファイアウォールマネージャー管理者の AWS アカウントにデプロイする必要があります

テストとステージング

エッジ構成はさまざまなレベルでテストできます。まず、テストアカウントで AWS WAF WebACL を使用して CloudFront ディストリビューションなどのインフラストラクチャを複製できます。これは、開発段階で実行することも、本番環境に移行する前に自動機能テストを実行する場合にも実行できます。同じ CNAME で 2 つの CloudFront ディストリビューションを使用することはできないことに注意してください。そのため、CloudFront リソースの CNAME 設定を CI/CD フェーズに基づいて区別する必要があります。たとえば、開発フェーズには CloudFront のドメイン名 (例:xyz.cloudfront.net)、ステージングには専用の CNAME (例:staging.www.example.com)、プロダクションデプロイにはパブリック CNAME (例:www.example.comm) を使用できます。ステージングフェーズでは AWS WAF を使用して特定の IP へのアクセスを制限するなど、セキュリティコントロールをステージごとに区別することもできます。

新しい構成がテストに合格したら、CloudFront の継続的デプロイ機能を使用して canary リリースアプローチを実装し、トラフィックのごく一部で本番環境での変更をテストできます。この機能を使用すると、プロダクションディストリビューション用に別の設定を作成し、グローバルトラフィックの一部のみをそのディストリビューションに送信できます。トラフィックを新しい設定にルーティングするには 2 つの方法があります。1 つは特定のリクエストヘッダーを使用する (合成テストに便利)、もう 1 つは加重ポリシーを使用して設定可能な割合のトラフィックを新しい設定にルーティングする方法で、スティッキネスを有効にするオプションもあります。この機能の現在のバージョンでは、CloudFront 設定パラメータのサブセットの変更のみをテストできます。この機能を使用してテストできる内容をよりよく理解するには、ドキュメントをお読みください。

ダイナミックコンフィグレーション

複数のチームが CloudFront 設定に変更を加え、1 つのチームがすべてのチームの CI/CD パイプラインを管理するシナリオを考えてみましょう。たとえば、さまざまなチームが別々のマイクロサービスを管理し、そのすべてが単一の CloudFront ディストリビューションによってホストされているメインドメインに API を公開している場合があります。各チームに CloudFront ディストリビューションの全設定へのアクセスを許可すると、1 回の有害な変更の爆発範囲が広がります。逆に、CI/CD チームに CloudFront ディストリビューションの変更のみを許可すると、開発速度が低下し、リリースライフサイクルにボトルネックが生じます。代わりに、各マイクロサービスチームが所有する部分的な構成に基づいて構成を動的に生成できます。簡単な実装では、各チームは S3 バケットでホストされているテキストベースのファイルで、独自のルート (キャッシュ、エッジ機能など) の設定を管理できます。CI/CD パイプラインでは、さまざまな部分設定ファイルを使用して最終的な CloudFront 設定を動的に作成する追加ステップを導入できます。

AWS WAF と AWS Shield のデプロイ

Shield サービスと WAF サービスは、前述と同じツールを使用して CI/CD パイプラインでデプロイできます。

ただし、次の利点があるため、WAF ルールとシールド保護のデプロイには AWS Firewall Manager を使用することをおすすめします:

  • これにより、中心的なセキュリティガバナンスの実施が容易になります。(たとえば、アプリケーションチームが管理するルールを組み合わせた中央ルールのデプロイ)
  • AWS WAF を使用して重大な脆弱性にパッチを適用するために不可欠な、より迅速なデプロイが可能になります。
  • これにより、複数のアカウントや異種の CI/CD パイプライン (買収から継承されたものなど) にわたるデプロイが簡単になります。ただし、この方法では、ドリフト検出機能付きの CI/CD パイプラインを使用している場合は、ドリフトを管理する必要があります。

さらに、CI/CD パイプラインを使用して管理者アカウントのファイアウォールマネージャーポリシーを変更し、OLX で示されているように、Firewall Manager によって AWS 組織全体にデプロイできます。

WAF ルールを本番環境に安全にデプロイするには、さまざまな方法があります。カウントモードで既存の WebACL に新しいルールを追加し、それをブロックモードに変更できます。ただし、この方法では、WebACL の最大WCUに注意する必要があります。もう 1 つの方法は、ステージング WebACL に変更をデプロイし、ステージング環境で変更をテストすることです。

リソース

このページはお役に立ちましたか?

 フィードバック