いわさです。
AWS Application Composer を使うと、SAM テンプレートを視覚的に構築することが可能です。
一方、AWS SAM は CloudFormation の拡張機能なので、通常は CloudFormation コンポーネントと SAM コンポーネントを組み合わせて同一テンプレート上に記述することも多いです。
本日、すべて（1000 以上）の CloudFormation リソースが Application Composer でサポートされたとアナウンスされました。
変更点をまとめてみましたので紹介します。
これまでのサポート外のコンポーネント
これまでは Application Composer では非 SAM コンポーネントである標準の CloudFormation コンポーネントのサポートがかなり限定的でした。
例えば IAM ロールが定義されている SAM テンプレートを読み込んだ場合であれば、次のように Read-only リソースとして汎用的なアイコンで表示されていましたが、キャンバスで配置したり編集したりすることは出来ませんでした。
引用元：AWS Application Composer が一般提供されました — サーバーレスアプリケーションを視覚的にすばやく構築できます | Amazon Web Services ブログ
一応何かしらのコンポーネントという形での表示のみは出来るが、Application Composer のみで開発をすることはかなり難しかったと考えて良いと思います。
アップデート後
アップデート後は Application Composer ですべての CloudFormation コンポーネントが扱えるようになっているようです。
これまでサポートされていたコンポーネントは次のように「拡張コンポーネント」として表示されています。13 個ありますね。
それ以外の CloudFormation コンポーネントは次のように「標準 IaC リソース」として表示されています。
1134 個あるようです。
標準 IaC リソースを配置してみる
上記 2 つをキャンバス上でそれぞれ操作してみます。
まず、次のように VPC を検索し、配置してみました。
設定出来るのは論理 ID のみで設定値の中身はテンプレートとして記述する形となっていますね。
他にもいくつか標準 IaC リソースを配置してみましたが、全て同じ状態でした。
プロパティ部分をテンプレートとして記述出来るようにすることで汎用的にすべてのリソースに対応させたようですね。
ちなみに標準 IaC リソースを配置すると次のように「使用量が検出されました」というメッセージが表示されました。ベータという記述があったりとメッセージが少し怪しいですが、おそらく標準 IaC が配置されたことを単純に検出したということを言いたいのかな。
配置されたリソースは当然ですが、テンプレートモードにしても次のように記述されていることが確認出来ます。
必要なリソースを検索バーで検索してポンポンと配置してスケルトンコード的なものを組み立てるのは楽そうです。
ただ、VPC と LoadBalancer(V2) はプロパティが空で配置されたのですが、LoadBlancer(V1) についてはプレースホルダ状態で自動で入力されていました。リソースによって自動入力されるものがあるのだろうか。
なお、テンプレートの一部を入力する際には入力検証がされていたり、次のように入力補完もしてくれるので汎用的なテンプレートエディターとして使えるようになっています。これは良いですね。
拡張コンポーネントを配置してみる
拡張コンポーネントの場合は従来どおりで、プロパティウィンドウ上で個別のプロパティを設定することが出来ます。
これを全リソース対応させるのは厳しいと思うのでプロパティ部分をコードで記述する今の仕様は着地点として良さそうですね。
標準 IaC リソースはキャンバスから削除できない
配置していて気がついたのですが、キャンバスに配置したコンポーネントは削除ボタンで通常削除出来るのですが、標準 IaC リソースに関してははキャンバスから削除操作が出来ないようです。
削除ボタンは非活性になっており、次のメッセージが表示されます。
上部のボタンでテンプレートモードに切り替えて直接コード上で該当コンポーネントを削除する必要があります。
標準 IaC リソースと拡張コンポーネントは重複している場合がある
拡張コンポーネントと標準 IaC リソースそれぞれで分類されていますが、その 2 つは重複していたりします。
例えば、次は SQS キューを配置しようと検索した場合なのですが、どちらにもキューが表示されることが確認出来ると思います。
これ配置したらどうなるんだろうと思って配置してみたのですが、どちらも拡張コンポーネントとしてキャンバスでサポートされているリソースとして認識されました。
次の様に標準 IaC リソースから配置したキューも DLQ など固有のプロパティがサポートされていますね。
リソースタイプでサポートされているかされていないか判定されていそう
一方で Lambda 関数を配置しようとした場合は挙動が異なっていました。
次のように標準 IaC リソースから配置した Lambda 関数は Standard Component として認識されていますね。
Standard Component として認識されたコンポーネントは先程の VPC などと同様に論理 ID 以外のプロパティをテンプレートの部分的なコードとして入力する挙動となります。
作成されたテンプレートを確認してみると、拡張コンポーネントについてはAWS::Serverless::Functionで、標準 IaC リソースはAWS::Lambda::Functionです。
一方で SQS キューについてはどちらもAWS::SQS::Queueが配置されていました。
この挙動から、リソースタイプで判定されているようです。
既存テンプレートを読み込んでみた
今回試しに既存テンプレートをいくつか読み込んで Application Composer でどのように認識されてるのかを確認してみました。
SAM CLI のクイックスタートテンプレート
SAM CLI では SAM テンプレートを生成することが出来ます。
その中からここでは標準 IaC リソースである EFS を含む次のテンプレートを生成してみました。
以前はサポート外のリソースが何なのか認識しづらかったと思いますが、アイコンやリソースタイプが全てサポートされているので、テンプレートの構造、特にコンポーネント間の依存関係を可視化しやすくなっています。
単純な CloudFormation テンプレート
私がたまに使う、シンプルな VPC - ALB - EC2 のテンプレートも読み込んでみました。
SAM 要素が一切ないやつです。
次のように可視化することが出来ました。
依存関係の方向の問題もあるので、構成図のようなものを作ることは難しいですが、テンプレート構造を可視化する際にはなかなか良いのではないでしょうか。個人的には CloudFormation のデザイナーより見やすいですが。
さいごに
本日は AWS Application Composer ですべての CloudFormation リソースがサポートされたので何が変わったのか確認してみました。
これまでの Application Composer は、正直言うと SAM 以外では全く活用の余地がなかったと思っていたのですが、今回汎用的に様々なリソースに対応出来るようになったので、より幅広いシーンで活用出来そうですね。
15
