AWSリソースを一時的に利用するために手動で作成するケースは、よくあることだと思います。そして、そのリソースが思いのほか長く使われ続け、定期的にメンテナンスが必要になる、または他のAWS環境でも必要になる、といった経験もあるのではないでしょうか。
AWSリソースがAWS CloudFormationやAWS CDKなどでテンプレート化（コード化）して管理されていれば、改修や他のAWSアカウントへの流用は容易です。しかし、手動で作成した場合は設定の齟齬がないように確認しながら1から作成することになるため、作業負荷がかかります。
そのような場合に備えて、本コラムでは、手動で作ってしまったAWSリソースをテンプレート化して管理する方法をご紹介します。
準備編では、手動で作成したAWSリソースを、AWS CloudFormationに取り込むための準備作業の手順を解説しました。今回は実践編として、AWSリソースをAWS CloudFormationに取り込み、それらのリソースを更新する手順を解説します。
AWSリソースのテンプレート化の手順
準備編に続き、AWS CloudFormationを利用してAWSリソースのテンプレート化を行う手順を解説します。
＜作業手順＞
準備編
手順1 手動でAmazon API GatewayとAWS Lambdaを作成する
手順2 AWS Lambdaのソースコードを格納するAmazon S3のパスを取得する
手順3 Amazon API Gateway とAWS LambdaのテンプレートをSAM形式で作成する
手順4 AWSリソースをAWS CloudFormationに取り込むための定義ファイルを作成する
実践編（本コラム）
手順5 Amazon API Gateway とAWS LambdaをAWS CloudFormationに取り込む
手順6 AWS CloudFormationに取り込んだAWSリソースを更新する
手順5 Amazon API Gateway とAWS LambdaをCloudFormationに取り込む
手動で作成したAWSリソースをAWS CloudFormationに取り込む準備ができましたので、AWS CloudFormationにスタックをインポートします。作成したテンプレートファイルと、作成した定義ファイルのパスを指定する必要がありますので、それらのファイルが保存されているローカル環境の階層でインポートのコマンドを実行します。
＜図1 AWS CLI 実行コマンド（ローカル環境）＞
aws cloudformation create-change-set --stack-name blog-api-stack --change-set-name blog-api-change-set --resources-to-import file://import.json --change-set-type IMPORT --template-body file://blog-api.yaml --capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_NAMED_IAM実行後、AWS CloudFormationの管理画面から作成された変更セットの内容を確認します。
＜図2 AWS CloudFormation 変更セット確認（AWSマネジメントコンソール）＞
表示されている内容に問題がなければ、右上の[変更セットを実行]ボタンをクリックし、AWS CloudFormationのスタックにAWSリソースをインポートします。変更セットの完了には数分かかります。その後、AWS CloudFormationスタックのステータスが“IMPORT_COMPLATE”と表示され、AWS CloudFormationのスタック化が完了したことを確認できます。
手順6 AWS CloudFormationに取り込んだAWSリソースを更新する
AWS CloudFormationの取り込みが完了しました。最後に、このスタックを利用して手動で作成したAWSリソースを更新できるのかを確認します。更新作業は、ローカル環境でSAMのコマンドツールを利用して行います。
手順3で作成したSAM形式のテンプレートを修正して利用します。修正箇所は、ソースファイルのパスを指定する項目（CodeUri）のみで、先ほど準備したAWS Lambdaのソースコードが配置されたファイルのパスを指定します。
＜図3 フォルダ構成＞
work-dir/
├─src/
│└─lambda_function.py
└─blog-api.yaml
＜図4 AWS Lambdaソースコード：lambda_function.py＞
import json
def lambda_handler(event, context):
# TODO implement
return {
'statusCode': 200,
'body': json.dumps('CloudFormation Update!') #更新がわかるよう修正
} ＜図5 SAMテンプレートファイル：blog-api.yaml＞
AWSTemplateFormatVersion: "2010-09-09"
…
blogapi:
Type: AWS::Serverless::Function
DeletionPolicy: Retain
Properties:
FunctionName: blog-api
CodeUri: src/
{以降割愛}以上で準備が整いましたので、ローカル環境のSAMコマンドで実行し、ビルドとデプロイを行います。
＜図6 SAMコマンド実行（ローカル環境）＞
# ビルド
C:> sam build --template blog-api.yaml
# デプロイ
C:> sam deploy --guidedコマンド実行後、コマンド結果の最後に“Successfully ~ ”のメッセージが表示されたら、AWS CloudFormationのスタック更新が完了しています。
AWSリソースが想定通りに更新されているか確認するため、Amazon API GatewayのURLをブラウザで表示して確認します。
＜図7 Amazon API GatewayのAPI実行確認（ブラウザ）＞
“CloudFormation Update!”のメッセージが表示され、手動で作成したAWSリソースをAWS CloudFormation経由で更新できていることが確認できました。
AWS CloudFormationスタックへのインポートについての補足
AWS CloudFormationスタックへのインポートについて補足します。
AWS CloudFormationスタックへのインポート作業の一部をコマンドで実行した理由について（手順5）
AWS CloudFormationスタックへのインポートは、AWSマネジメントコンソール画面からも作業が可能です。しかし、SAM形式のテンプレートを利用する場合は、AWSの制約によりAWS CLIを用いて実施しなければなりません。そのため今回は、ローカル環境からAWS CLIを利用して、変更セットの作成などを行いました。その他にも一部の条件下ではAWS CLIの利用を求められますので、AWSマネジメントコンソールで作業したい場合は、以下のAWS公式ナレッジサイトにて条件を確認してください。
https://repost.aws/ja/knowledge-center/cloudformation-template-resources-error
AWS CloudFormationにインポートできるAWSリソースについて（手順3）
AWS CloudFormationにインポートできるリソースには限りがあります。例えば、AWS LambdaではAliasが利用できないなど細かい制限があります。以下のAWS公式ドキュメントサイトにて、インポート予定のAWSリソースが問題なくインポートできるかを確認してください。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html
リソースインポート用の定義ファイル項目[ResourceIdentifier]にて指定するキー情報について（手順4、手順5）
インポート対象のAWSリソースを特定するための識別子を[ResourceIdentifier]の項目に定義する必要があります。しかし、識別子のキー情報をAWS公式ドキュメントサイトから見つけることができませんでした。
そのため、筆者は定義ファイル内の識別子のキーと値を仮で指定し、変更セット作成後に出力されるエラー画面の情報を元に定義ファイルを修正して再度実行する、という方法をとっています。少し泥臭い作業にはなってしまいますが、1度エラーを出せば必要な情報がわかりますので、キー情報がわからない場合は本手順で取得してみてください。
＜図8 AWS CloudFormation変更スタックエラー画面（AWSマネジメントコンソール）＞
＜準備編＞＜実践編＞として、AWS上に手動で作ったAmazon API GatewayとAWS Lambdaを、AWS Serverless Application Model化しAWS CloudFormationで管理する手順をご紹介しました。
少し手間ではありますが、AWS CloudFormationでテンプレート化をしておけば、将来的なメンテナンスの工数削減や他のAWS環境への横展開のしやすさなど様々なメリットがあります。手動で作成したAWSリソースがある場合は、ぜひ本コラムを参考にAWS CloudFormationを使ったテンプレート化に挑戦してみてください。
富士ソフトのAWS関連サービスについて、詳しくはこちら
アマゾンウェブサービス(AWS)
