AWS Amplify(Console、CLI)、AWS CDK、AWS CloudFormationの特徴と比較－仕様と実装から鑑みるユースケース・使い所

小西秀和です。
これまで静的ウェブサイトホスティングをテーマにAWS Amplify、AWS Cloud Development Kit(AWS CDK)、AWS CloudFormationに関する記事を書いてきました(本記事末尾参照)。

いずれも、各サービスを使用してAmazon S3＋Amazon CloudFrontの静的ウェブサイトホスティングにAWS Certificate Manager(ACM)、基本認証機能(AWS Amplify Console以外はLambda@Edgeで実現)を追加したアーキテクチャをデプロイする内容でした。
また、AWS Amplify Console以外については別リージョンのAmazon S3バケットにレプリケーション設定を加えた上でCloudFrontオリジンフェイルオーバーを設定することも試してきました。

今回は、このようにAWS Amplify Console、AWS Amplify CLI、AWS CDK、AWS CloudFormationといった4つの方法について調査し、実際に同様のアーキテクチャのデプロイを実施した記事の内容を踏まえて、各サービスの特徴と使い所のまとめと比較をしてみようと思います。
AWS Amplify Console、AWS Amplify CLIはともにAWS Amplifyに分類されますが、サービスの対象が、それぞれフルマネージドな静的ウェブサイトホスティングか、AWS CloudFormationによるカスタマイズが可能なバックエンドサービス全般か、の違いがあるため別項目として見ていきます。

ちなみにAWS Serverless Application Model(AWS SAM)についてはAmazon API Gateway、AWS Lambda、Amazon DynamoDBといった主にバックエンドのサーバーレスアプリケーションを構築するサービスのため今回は対象外にしていますが、機会があればバックエンド視点のやってみた記事や比較記事も今後書いてみようと思います。

ただし、これらの評価は本記事執筆者の個人主観によるものですので、その点をご認識の上であくまで参考資料の一つとしてご覧頂きたいと思います。

AWS Amplify Console、AWS Amplify CLI、AWS CDK、AWS CloudFormationの関係性の概念図

まず、AWS Amplify Console、AWS Amplify CLI、AWS CDK、AWS CloudFormationが相互にどのように関係しているかを概念図で示します。

AWS Amplify ConsoleはAWSマネジメントコンソールから画面操作でマネージドな静的ウェブサイトホスティング環境をデプロイします。
AWS Amplify CLIはプロジェクト作成後、カテゴリ毎に対話形式でAWSリソースを設定してデプロイすると、AWS CloudFormationテンプレートが自動生成されスタックがデプロイされます。
ただし、AWS Amplify CLIの「amplify add hosting」コマンドで「Hosting with Amplify Console」を選択した場合のみAWS Amplify Consoleを使用する画面に遷移します。
AWS CDKはプロジェクトを作成後、プログラミング言語でAWSリソースを開発してデプロイすると、AWS CloudFormationテンプレートが自動生成されスタックがデプロイされます。
AWS CloudFormationを直接使う場合は、AWSマネジメントコンソールなどからAWS CloudFormationテンプレートをアップロードし、パラメータを設定してデプロイします。

特徴の観点(比較項目)

今回は各サービスの比較ができるように、次の共通項目でそれぞれのサービスの特徴を見ていき、最終的に比較したいと思います。
分類に関しては「Architecture as Codeってなぁに？〜Infrastructure as Codeを超えて〜」の記事を参考にしました。

項目	説明
分類	Infrastructure as Code(IaC)またはArchitecture as Code(AaC)
機能概要	サービスの概要
参考資料数	学習するための情報源の概要、参考資料の多さなど
学習容易性	使い方の習得に必要な費用、時間、作業量など
要件実現可能性	幅広い要件の実現しやすさ
開発容易性	作業量の少なさ、開発しやすさ
拡張性・保守性	機能追加やメンテナンスのしやすさ
移植性・再利用性	ローカル環境の構築有無、移植と再利用のしやすさ
使い所	どのようなケースに向いているか

これらの項目は機能比較のフレームワークなどに沿ったものではなく、仕様と実装の実感を比較しやすいようにカテゴライズしてみたものです。
本記事執筆時点で他に伝わりやすい項目を思いつかなかったので、とりあえずこの内容で書いていってみます。

AWS Amplify Consoleの特徴

項目	特徴
分類	AaC
機能概要	フルマネージドな静的ウェブサイトホスティングとCI/CD。
参考資料数	AWS公式・パートナー等のドキュメントやブログなど。資料数は比較的新しいサービスの割に多い。
学習容易性	ほとんど画面操作中心なので、無料ドキュメントなどで容易に習得できる。
要件実現可能性	静的ウェブサイトホスティングに限定される。
開発容易性	AWSリソースを作成するコード開発は不要。
拡張性・保守性	機能追加は基本認証やSSL証明書など予め用意されているものに限定される。修正も画面操作から実施する。
移植性・再利用性	リポジトリやコンテンツがあればAWSマネジメントコンソールで完結するため、ローカル環境の設定は不要。移植についてはAWS Amplify Consoleアプリそのものをコピーする機能が本記事執筆時点で存在しない。ただし、操作そのものが簡易であり、リポジトリなどの連携を設定してコンテンツデプロイをするため手動による移植は容易にできる。
使い所	詳細設定を必要としない静的ウェブサイトホスティング。GitHubなどのリポジトリと連携したマネージドなCI/CDを使用したい場合。高可用・高機能のAWSリソースを使用しながら、画面操作中心で迅速にホスティング環境を作成したい場合。バックエンドのAWSリソースを追加する場合は別途AWS Amplify CLIなどで開発が必要。

AWS Amplify Consoleの参考資料

AWS Amplify CLIの特徴

項目	特徴
分類	AaC
機能概要	サーバーレスなバックエンドリソースを一般的なユースケースのアーキテクチャでデプロイする(AWS CloudFormationテンプレートが自動生成されてデプロイされる)
参考資料数	AWS公式・パートナー等のドキュメントやブログ、GitHubのコードなど。資料数は比較的新しいサービスの割に多い。
学習容易性	AWS Amplify CLIは対話的に使用するため難易度は低い。要件を満たすかを判断するために使用するカテゴリーで構築されるアーキテクチャの内容把握は必要。
要件実現可能性	要件がAWS Amplify CLIで用意されたアーキテクチャで満たせない場合はAWS CloudFormation、AWS CDKなどで拡張または別途構築する必要がある
開発容易性	主にAWS Amplify CLIで対話形式の入力とプロジェクトの構成を設定するファイルを記述することでAWSリソースが構築できる
拡張性・保守性	AWS Amplify CLIで作成されたCloudFormationテンプレートを修正すれば拡張は可能。一方で拡張部分が多い場合はAmplifyの利点がないため、AWS CDKを使用した方が良い。
移植性・再利用性	AWS Amplify CLIの実行にはコマンドを実行し、プロジェクトを作成するローカル環境が必要になる。AWS Amplify CLIでは本記事執筆時点でプロジェクトを共有する機能はあるがコピーする機能はない。移植はAWS Amplify CLIで同じ対話形式の入力でプロジェクトを作成し、拡張したコードがある場合はそれらをコピーすることで可能。
使い所	予めAWS Amplify CLIで実現できるアーキテクチャを把握しておき、要件を満たし、将来的に大きな機能拡張の可能性が低い場合に使用する。そうでない場合はAWS CDKを検討した方が良い。

AWS Amplify CLIの参考資料

AWS Cloud Development Kit(AWS CDK)の特徴

項目	特徴
分類	IaC・AaC
機能概要	TypeScript、JavaScript、Python、Java、C#といったプログラミング言語でAWSリソースのアーキテクチャを記述してデプロイする(AWS CloudFormationテンプレートが自動生成されてデプロイされる)
参考資料数	AWS公式・パートナー等のドキュメントやブログ、各言語毎のAPIリファレンス、GitHubのコードなど。APIリファレンスはしっかりしているが、歴史が浅いのでコード記述例は多くない。
学習容易性	各プログラミング言語と同様の記述ができるが、AWS CDKライブラリの使い方の学習が必要。AWS CloudFormationの記述を知っていても、抽象度の高いL2(Level 2) Constructの記述方法を学習する必要がある。一方で、抽象度の低いL1(Level 1) ConstructはAWS CloudFormationの記述と同様であるため知識が役立つ。AWS CDKではオブジェクト指向とL2 ConstructによってAWS CloudFormationよりもAWSリソースの記述が容易になっているが、都度APIリファレンスで記述方法を調べるなど学習量は多い。
要件実現可能性	対応プログラミング言語を使用して、基本的にAWS CDKのL2、L1 Constructによる実装でAWS CloudFormationと同様にAWSリソースが構築できる。マルチリージョンのリソースもAWS CDKプロジェクト内の記述で作成でき、リージョン間の値渡しもAWS CDKカスタムリソースなどで可能。ただし、L2 ConstructではAWS Secrets Managerで固定値をシークレットに登録できないなどAWS CDKの仕様による制限が一部ある。その場合、L1 ConstructやAWS CDKカスタムリソースなどを使用して対処を検討する必要がある。
開発容易性	L2 ConstructによってAWS CloudFormationよりもAWSリソースの記述が容易になっているため開発もしやすい。特に実行順序・依存関係、条件分岐、繰り返しが柔軟に記述可能。
拡張性・保守性	オブジェクト指向のプログラミング言語による記述であるため、規模が大きくなってもAWSリソースの追加や順次・選択・繰り返しといったロジック修正がしやすく、拡張性・保守性が高い。
移植性・再利用性	AWS CDKコマンドを実行してプロジェクトを作成するローカル環境が必要。本記事執筆時点でプロジェクトをコピーする機能はない。AWS CodeArtifact等を使用して共通コードをnpm、pipといったパッケージとして保存して共有する、プロジェクト初期化後に作成したコードをコピーして移植する、などの方法で再利用する。同様の複数プロジェクトを使用する場合には、同一リージョン・同一スタック名で他のプロジェクトのスタックを上書きしないように注意や工夫が必要。
使い所	AWS CDKが対応しているプログラミング言語の文法・パッケージ管理の使い方、AWS CDKのコマンド・ライブラリの使い方などを習得できる場合。学習量は多いが、習得すればAWS CloudFormationよりもコード化は容易になる。ユースケースとしては小規模から大規模まで幅広くAWSアーキテクチャのコード化に向いている。また、CDK for TerraformといったTerraform経由でマルチクラウドを構成するプロバイダ機能など新機能の追加も活発なので、今後の拡張を取り入れていく場合も使用する価値はある。

AWS Cloud Development Kit(AWS CDK)の参考資料

AWS CloudFormationの特徴

項目	特徴
分類	IaC
機能概要	JSON、YAML形式でAWSリソースの構成をCloudFormationテンプレートに記述してデプロイする
参考資料数	AWS公式・パートナー等のドキュメントやブログ、GitHubのコードなど。AWS AmplifyやAWS CDKからCloudFormationテンプレートを生成して利用される位置づけであり、歴史も長いため、リファレンスやテンプレート例なども豊富。
学習容易性	CloudFormationテンプレートの独特な記述形式、ネストやクロススタック参照などの方法を習得する必要がある。特にJSON、YAML形式の性質上、順次(依存関係の設定)・選択の記述や繰り返しの手法は独特で工夫も必要。また、AWS CloudFormationの運用にはスタックポリシー、変更セット、ドリフト検出、StackSetsなどのテンプレート以外の機能も把握しておいたほうがよい。
要件実現可能性	AWS CloudFormationでサポートしているAWSリソースはすべて作成できる。ただし、マルチリージョンのAWSリソースを作成する場合はStackSets、カスタムリソース、AWS CLIなどと組み合わせて実現することになる。
開発容易性	CloudFormationの構文や順次(依存関係の設定)・選択の記述方法を学習すれば、典型的なAWSリソースの開発は難しくない。ただし、複雑な順次(依存関係の設定)・選択処理は可視性が低くなりやすく、AWSリソースをルールに基づいて複数作成するような場合はコードレベルでJinjaなどのテンプレートエンジンでレンダリングする、カスタムリソースでAWS SDK実行やCloudFormationスタックデプロイによる繰り返し処理をする、AWS CLIでCloudFormationスタック単位で繰り返し処理をするなど別途工夫が必要。
拡張性・保守性	JSON、YAML形式の性質上、各リソースの種類と設定パラメータの可視性は高いが、順次(依存関係の設定)・選択といったロジック記述部分の可視性が低い。そのため、単純なAWSリソース追加の拡張性は高いが、依存関係や条件分岐が増えるほど、また構築する規模が大きくなるほど拡張の難易度は高くなり、保守性は低くなる。
移植性・再利用性	AWS CloudFormationはJSON、YAML形式で記述し、AWSマネジメントコンソールからデプロイできるため、ローカルに特別な環境を用意する必要がない。そのため、CloudFormationテンプレートがあれば移植は容易にでき、再利用しやすい。
使い所	AWSリソース間の依存関係や条件分岐などが複雑でなく、AWS CloudFormationの記述方法を習得できる場合、または既に習得している場合。既にAWS CloudFormationによる開発・運用ノウハウがあり、拡張性・保守性の要件が満たされていれば、既存のスタックをあえてAWS CDKに移行する必要はないと考えられる。

AWS CloudFormationの参考資料

AWS Amplify Console、AWS Amplify CLI、AWS CDK、AWS CloudFormationの比較

各サービスの特徴の比較を4段階評価で表にしてみました。
AWS Amplify Console、AWS Amplify CLIを別サービスと見るか、AWS Amplifyとして一緒に見るかで2パターンに分けています。
上記の特徴や使い所の説明よりもさらに主観的、定性的な比較となりますので、その点をご認識の上で参考としてご覧ください。

Amplify ConsoleとAmplify CLIを別に考えた場合

項目	Amplify Console	Amplify CLI	CDK	CloudFormation
分類	AaC	AaC	IaC・AaC	IaC
参考資料数	★★★★	★★★	★★★	★★★★
学習容易性	★★★★	★★★	★★	★★
要件実現可能性	★	★★★	★★★★	★★★★
開発容易性	★★★★	★★★	★★	★
拡張性・保守性	★	★★	★★★★	★★★
移植性・再利用性	★★	★★★	★★★	★★★★

Amplify ConsoleとAmplify CLIを一緒に考えた場合

項目	Amplify	CDK	CloudFormation
分類	AaC	IaC・AaC	IaC
参考資料数	★★★	★★★	★★★★
学習容易性	★★★	★★	★★
要件実現可能性	★★	★★★★	★★★★
開発容易性	★★★★	★★★	★★
拡張性・保守性	★★	★★★★	★★★
移植性・再利用性	★★★	★★★	★★★★

参考：
Tech Blog with related articles referenced

まとめ

今回は主観的ではありますが、AWS Amplify Console、AWS Amplify CLI、AWS CDK、AWS CloudFormationについて特徴と使い所を比較してみました。
簡単にまとめるとそれぞれ次のようなユースケースに向いていると考えられます。

AWS Amplify Consoleはフルマネージドな静的ウェブホスティング環境がすぐにほしい場合
AWS Amplify CLIは一般的なサーバーレスアーキテクチャを多少カスタマイズ可能なパッケージのように使用したい場合
AWS CDKは複雑なアーキテクチャをオブジェクト指向言語で柔軟に記述したい場合
AWS CloudFormationは複雑性の少ないアーキテクチャをJSON、YAML形式でライトに書きたい場合

これらの比較やユースケースから、多種多様なAWSアーキテクチャ構築の柔軟性は次のようになると考えられます。

Amplify Console ＜ Amplify CLI ＜ CloudFormation ＜ CDK

そのため、柔軟な拡張や変更ができるアーキテクチャを求める場合はAWS CDKの使用が中心となり、AWS Amplifyをメインに使うことは少なく、あったとしてもAWS CDKと組み合わせるような使い方になるでしょう。
一方で一般的なアーキテクチャで迅速にサービスを構築し、フロントエンド開発に注力する場合はAWS Amplifyが適していると言えます。

AWS CDKとAWS CloudFormationの使い所の差はオブジェクト指向言語か、JSON・YAMLかという記述形式が大きな影響を与えています。
AWS CDKはオブジェクト指向言語のカプセル化、継承、多態性の要素によって複雑な順次・選択・繰り返し処理があるスタックやConstructを整理しやすくなっています。
一方、AWS CloudFormationはJSON・YAML形式でAWSリソースの設定値を一対一で確実に表現する役割を担っている印象です。

AWS Amplify CLIやAWS CDKはAWS CloudFormationテンプレートを生成してスタックをデプロイすることから、AWS CloudFormationはこれらの骨組みとして今後も無くなることはなくAWSリソースに合わせてアップデートされていくと考えられます。
ただ、AWSアーキテクチャのコード化に関してはAWS Amplify CLIやAWS CDKといったAWS CloudFormationの使用を抽象化するサービスにシフトしてきているのが現状です。

AWS CloudFormationの学習や運用をあきらめたケースではAWSインフラコード化の再考のチャンスという捉え方もできます。
一方でAWS CloudFormationを既に使用している場合はAWS Amplify CLI、AWS CDKを実際に使ってみて特徴を知り、状況に応じた利点・欠点から導入を検討することになるでしょう。
ただ、AWS Amplify CLI、AWS CDKに限らず、コードレビュアーなど関係者含めて新しい技術を学習する習慣があれば新サービスの導入もしやすいと思います。

余談になりますが、今回の記事のために調査をしていく中で、このようにインフラストラクチャのコード化がモデル化・抽象化されていく流れが加速していくと、仮想サーバーは知ってるけど物理サーバーは知らない、サーバーレスは知ってるけど仮想サーバーは知らない、といった現象と同様に、AWS CDKは知ってるけどAWS CloudFormationは知らない、という方が出てくる時代もそう遠くないと感じました。