CloudFormationの「限界」を突破せよ：CloudFormation Registryで挑む、究極のIaC自動化
こんにちは。クラウドインフラの深淵を覗き続けてきたエンジニアです。
皆さんはAWS CloudFormationを使っていて、こんな「壁」にぶつかったことはありませんか？
「SaaSの設定や社内独自のAPIを、他のAWSリソースと一緒に宣言的に管理したいのに、CloudFormationにはリソースタイプが存在しない……」
結局、Lambdaで無理やり実装した`Custom::Resource`に泣かされ、冪等性の担保やエラーハンドリングの複雑さに頭を抱える。そんな日々とは今日で決別しましょう。
今回は、CloudFormationの真の力である「CloudFormation Registry (CloudFormation CLI)」を使い、自前のリソースプロバイダーを構築する手法を伝授します。これをマスターすれば、あなたのIaCは「AWSリソースを管理するツール」から「インフラのすべてを支配する基盤」へと進化します。
—
1. そもそも「カスタムリソース」と何が違うのか？
多くのエンジニアが通る道である `AWS::CloudFormation::CustomResource`（Lambda連携）と、今回解説する `CloudFormation Registry` による `Resource Provider`。その違いは「責務の分離」にあります。
| 比較項目 | Custom Resource (Lambda) | Resource Provider (Registry) |
| :— | :— | :— |
| 冪等性 | 実装者（あなた）がフルスクラッチで実装 | Frameworkが自動的に抽象化 |
| 状態管理 | 独自の実装が必要 | AWS側で自動追跡 |
| 可読性 | スパゲッティ化しやすい | スキーマ定義で型安全を担保 |
| 再利用性 | 低い（コピペになりがち） | 高い（プロバイダーとして配布可能） |
結論： Custom Resourceは「泥沼のパッチワーク」です。一方、Registryは「AWSネイティブなリソース」を自作する正当な設計手法です。
—
2. 開発環境のセットアップ（HelloWorldへの準備）
まずは、AWS公式の `CloudFormation CLI` をインストールします。Python環境が整っていれば一瞬です。
必要なライブラリをインストール
pip install cloudformation-cli cloudformation-cli-python-plugin
バージョンの確認
cfn –version
次に、プロバイダー開発用のプロジェクトを作成します。今回は例として `MyCompany::SaaS::Project` という架空のリソースを作ってみましょう。
プロジェクトディレクトリの作成
mkdir my-provider && cd my-provider
プロジェクトの初期化
cfn init
(対話モードで以下を選択)
1. Resource
2. MyCompany::SaaS::Project
3. python
—
3. HelloWorld：リソースを「宣言」する
プロジェクトが作成されると、`my-company-saas-project.json` というスキーマファイルが生成されます。ここでリソースの「あるべき姿」を定義します。
my-company-saas-project.json（抜粋）
{
“typeName”: “MyCompany::SaaS::Project”,
“properties”: {
“ProjectName”: { “type”: “string”, “description”: “SaaS上のプロジェクト名” },
“Owner”: { “type”: “string”, “description”: “管理者のメールアドレス” }
},
“primaryIdentifier”: [“/properties/ProjectName”]
}
この定義こそが重要です。「このリソースは、ProjectNameとOwnerという属性を持ち、ProjectNameで一意に識別される」と宣言するだけで、CloudFormationがその整合性を保証してくれます。
—
4. 現場で震えるほど役立つ「動作確認」の鉄則
コードを書く前に、必ずシミュレーションを行います。CLIには強力なテストツールが同梱されています。
生成されたコードのテストを実行
cfn test
このコマンドは、コンテナを立ち上げ、スタックの作成（Create）、更新（Update）、削除（Delete）のライフサイクルを一括で検証します。
成功のポイント：冪等性を意識する
プロバイダー内部の `create_handler` や `update_handler` を書く際は、常に「同じリクエストが2回きても、エラーにならず、かつ状態が壊れないこと」を意識してください。
もし外部API側で作成済みなら、エラーを吐くのではなく「既に存在している」ことを検知し、既存のリソースを正しくリターンさせる。これだけで、あなたのIaCの品質は上位1%に食い込めます。
—
最後に：なぜ今、これを学ぶべきなのか
SaaSや社内APIを「CloudFormationの型」に流し込むということは、「インフラの運用負荷を極限まで減らす」ということに他なりません。
コンソールポチポチや、場当たり的なLambdaのスクリプトから解放され、「`cfn deploy` を打てば、AWSもSaaSもすべてが理想の状態になる」という体験。この快感を一度知ってしまうと、もう元には戻れません。
まずは小さなリソースからで構いません。あなたの手で「AWSの世界」を広げてみてください。それが、最強のSREへの第一歩です。
何か詰まったら、いつでも聞いてください。設計思想の深いところから一緒に紐解いていきましょう。応援していますよ。