こんにちは。クラウドインフラの世界へようこそ。
Infrastructure as Code (IaC) を追求していくと、必ず「壁」にぶつかります。AWS CloudFormationは強力ですが、標準のリソースタイプだけで世界を記述しきることはできません。「RDSの中にテーブルを作りたい」「外部SaaSにAPIで設定を投げたい」「動的に生成される認証情報を管理したい」。
そんな時、多くのエンジニアは「あとで手動でやればいいか」と諦めます。しかし、それは「IaCの敗北」です。
今日は、CloudFormationの限界を突破する奥義、「カスタムリソース」の深淵を案内します。これをマスターすれば、あなたのインフラは「ただの構成」から「自律的に最適化されるシステム」へと進化します。
—
1. カスタムリソースとは？：CloudFormationの「拡張機能」
カスタムリソースとは、CloudFormationが直接サポートしていないリソースや、プログラミングによる動的な処理を、スタックのライフサイクル（作成・更新・削除）に組み込むための仕組みです。
どのような時に使うのか？
- RDS/Auroraの初期スキーマ投入: テーブル作成はCloudFormationの管轄外です。
- 外部APIの操作: Auth0やDatadogの設定など、AWS外のリソースをIaCに含めたい時。
- 複雑な条件分岐: 既存の論理条件では表現しきれないリソース配置。
「標準リソースにないなら、自分で作ればいい」。これがエンジニアの矜持です。
—
2. AWS Lambdaと連携した実装の仕組み
カスタムリソースは、裏側で「AWS Lambda」を呼び出すことで動作します。
1. CloudFormationがLambdaをトリガー（`Create`, `Update`, `Delete`イベントを送信）。
2. Lambdaがやりたい処理（DB初期化など）を実行。
3. LambdaがCloudFormationに対して「成功したよ（Success）」または「失敗したよ（Failed）」というレスポンスを返す。
この「レスポンス」を返さないと、スタックは永遠に「CREATE_IN_PROGRESS」のまま動かなくなります。これがカスタムリソースで最も多い罠です。
—
3. 【実践】データベース初期化：Hello World
今回は、「CloudFormationでRDSを作った後、自動でテーブルを作成する」という、現場で最も需要の高い実装を例に挙げます。
Lambdaのコード (Python)
`cfn-response`というAWS公式モジュールを使うのが定石です。
import cfnresponse
import boto3
def handler(event, context):
# カスタムリソースのライフサイクルを確認
request_type = event[‘RequestType’]
try:
if request_type == ‘Create’ or request_type == ‘Update’:
# ここでDB接続処理やSQL実行を行う
print(“DB初期化処理を実行中…”)
# 実際にはここにSQL実行ロジックを記述
elif request_type == ‘Delete’:
# 必要であれば削除時のクリーンアップ処理
print(“クリーンアップ処理”)
# 成功をCloudFormationに通知
cfnresponse.send(event, context, cfnresponse.SUCCESS, {“Message”: “Done!”})
except Exception as e:
# 失敗時はCloudFormationに通知してスタックをロールバックさせる
cfnresponse.send(event, context, cfnresponse.FAILED, {“Error”: str(e)})
—
4. 現場で生き残るための「鉄則」
カスタムリソースを実装する際、以下の3点を必ず守ってください。これを守らないと、深夜の障害対応で泣くことになります。
① エラーハンドリングは「悲観的」に
Lambda内の処理が失敗しても、必ず`cfnresponse.FAILED`を呼んでください。そうしないと、スタックが「スタック状態の更新中」のままフリーズし、修正すらできなくなります（いわゆる「スタックの幽霊化」です）。
② タイムアウト対策
デフォルトのLambdaタイムアウトは3秒です。DB接続やAPI通信は時間がかかるため、必ず1分以上に設定してください。
③ 冪等（べきとう）性の担保
これが最重要です。
CloudFormationの「更新」時には、同じ処理がもう一度走る可能性があります。「テーブルが既に存在しているなら何もしない」といった、何度実行しても同じ結果になるロジックを必ず実装してください。
—
まとめ：インフラを「プログラム」へ昇華させる
カスタムリソースは、CloudFormationを「設定ファイル」から「プログラマブルな制御基盤」へと変貌させます。
最初は難しく感じるかもしれません。まずは簡単な「ログを出力するだけのカスタムリソース」から作成し、スタックがどう反応するかを観察してみてください。
この技術を身につければ、あなたはもう「AWSの仕様に悩まされる側」ではなく、「インフラを意のままに操る側」に回ることができます。
さあ、次はどんなリソースを自動化しましょうか？あなたの挑戦を応援しています。