Amazon Web Services ブログ
新機能 – CloudFormation スタックへの既存リソースのインポート
AWS CloudFormation を使うと、インフラストラクチャ全体を、テキストによりモデリングできます。この方法により、インフラストラクチャをコードのように扱うことが可能になり、ソフトウェアのバージョン管理やアーキテクチャ上の変更をデプロイ前にチームでレビューするなど、ソフトウェア開発のベストプラクティスを適用できるようになります。
初期段階でコンソールや AWS Command Line Interface (CLI) から作成された AWS リソースは、CloudFormation での管理が必要となる場合があります。たとえば、お客様 (あるいは他のチーム) で、 IAM ロール、仮想プライベートクラウド、または RDS データベースなどを移行の初期段階で作成し、その後、それらを同じスタックに組み入れ最終的なアプリケーションの形に仕上げるための作業時間を割いているとします。こういった場合、CloudFormation を使いリソースをゼロから再作成して、オリジナルのリソースから設定やデータを移行することも多くなります。
お客様によるこれらの手順を簡単にするため、 今回、CloudFormation スタックに既存のリソースをインポートすることが可能になりました。
リソース自体を削除せずに、スタックから除外することは、これまでも DeletionPolicy
を Retain
に設定することで可能でした。ここに、新なインポート機能も加わることで、利用範囲がさらに広がります。例として、現状では次のことが可能です。
- 既存リソースをインポートしながら新規のスタックを作成する。
- すでに作成済みのスタックに既存リソースをインポートする。
- スタック間でリソースの移行をする。
- 検出されたドリフトを修復する。
- 親スタックから子スタックを削除した後、別の親からインポートし直すことで、 ネストされたスタックのリファクタリングを行う。
CloudFormation スタックに既存リソースをインポートするには、以下のことが必要です。
- インポートするリソースと (既存の) スタックに既に組み込まれているリソースを含む、スタック全体を記述したテンプレート。
- インポートする各リソースのテンプレートには、
DeletionPolicy
属性が必要です。これにより、オペレーションの巻き戻しが安全かつ簡単に行えるようになります。 - 各ターゲットリソース固有の識別子。例としては、インポートをしたい Amazon DynamoDB テーブル、もしくは Amazon Simple Storage Service (S3) バケットの名前などが挙げられます。
リソースのインポート処理中、CloudFormation では次のことをチェックします。
- インポートされるリソースが、同じリージョンにある別のスタックに属していないか (IAM ロールなどグローバルなリソースの場合ご注意ください) 。
- ターゲットリソースが存在しており、ご自身にインポートに必要なアクセス権限があること。
- 必要かつ受け入れ可能なプロパティ、あるいはサポートされた値などを定義しているリソースタイプのスキーマに対応して、プロパティと設定値が有効となります。
リソースインポートの処理では、テンプレート上の定義と実際の定義が同じであるかはチェックされません。インポート処理 では、ドリフト検出と同じリソースタイプをサポートしているので、スタックにリソースをインポートした後は、ドリフト検知を実行することをお勧めします。
新しいスタックに既存リソースをインポートする
AWS アカウントに、ある程度のデータを保存した S3 バケットと DynamoDB テーブルがあり、 CloudFormation を使ってこれらを管理したい場合を考えます。 このとき、CloudFormation コンソールでは、次のような 2 つのオプションが用意されています。
- 既存のリソースをインポートしながらスタックを新しく作成する。
- 既存のスタックにリソースをインポートする。
今回のケースでは、ゼロから開始したいのでスタックを新しく作成します。 次に、インポートするリソースを記述したテンプレートを用意します。
ここでは、インポートする 2 つのリソースとして、DynamoDB テーブルと S3 バケットを含んだテンプレートをアップロードします。
AWSTemplateFormatVersion: "2010-09-09"
Description: Import test
Resources:
ImportedTable:
Type: AWS::DynamoDB::Table
DeletionPolicy: Retain
Properties:
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
AttributeName: id
AttributeType: S
KeySchema:
AttributeName: id
KeyType: HASH
ImportedBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain
このテンプレートでは、両方のリソースに対して DeletionPolicy
を Retain
に設定しています。こうしておくことで、仮にスタックから除外した場合でも、これらのリソースが削除されることはありません。リソースの中に、手違いで失いたくないデータや、将来において別のスタックに移動したいデータがある場合に、このオプションは有用です。 インポートされたリソースには、オペレーションの巻き戻しを安全で簡単に行えるよう、削除ポリシーは必須です。これは、他の人がインポートしたリソースを間違って削除してしまうことも防ぎます。
次に、既存リソースを記述したテンプレートで論理 ID をマッピングするための識別子を記述する必要があります。今回は、DynamoDB テーブルと S3 バケットの名前を使用します。他のリソースタイプについては複数の方法で識別子を指定できます。また、使用するプロパティはドロップダウンメニューから選択することが可能です。
適用前に作業を総括するため、変更点を見直します。 正しいリソースを正しい識別子で指定しているかをチェックします。 リソースのインポート中に実際に実行されるのは、CloudFormation Change Set です。
既存スタックにリソースをインポートする際は、スタックにある既存リソースに変更を加えることはできません。インポートのオペレーションは、インポートの Change Set アクションのみを許容します。 パラメータの変更は、それが既存リソースのパラメータにおいて解決済みになった値を変更しない限り許可されます。テンプレートを既存リソース用に修正することで、Ref
を使いハードコードされる値も、インポートするリソースに置換することができます。 たとえば、スタックに EC2 インスタンスがあり、それが、コンソールを使い作成された既存の IAM ロールを使用しているとします。このときは、IAM ロールをスタックにインポートすると、テンプレートで EC2 インスタンスが Ref
により使用しているハードコード値がこのロールに置換されます。
さて、話を進めます。各リソースには、それぞれに対応した CloudFormation コンソールでのイベントがあります。
インポートが完了して [Resources] タブを見ると、S3 バケットと DynamoDB テーブルがスタックに組み込まれていることが確認できます。
インポート済みのリソースがスタックのテンプレートと同期しているか確認するため、ドリフト検出を実行します。
自動的に作成されたものも含め、すべての stack-level タグが CloudFormation でサポートされるリソースに反映されます。たとえば、スタックにインポートした直後の S3 バケットに関連するタグセットを、AWS CLI を使って取得できます。これらのタグからは CloudFormation スタックの名前や ID、あるいはスタックテンプレートにあるリソースの論理 ID などがわかります。
$ aws s3api get-bucket-tagging --bucket danilop-toimport
{
"TagSet": [
{
"Key": "aws:cloudformation:stack-name",
"Value": "imported-stack"
},
{
"Key": "aws:cloudformation:stack-id",
"Value": "arn:aws:cloudformation:eu-west-1:123412341234:stack/imported-stack/..."
},
{
"Key": "aws:cloudformation:logical-id",
"Value": "ImportedBucket"
}
]
}
今すぐご利用いただけます
コンソールや AWS Command Line Interface (CLI)、 あるいはAWS SDK から使える、この CloudFormation の新しい インポート機能iは、米国東部 (オハイオ) 、米国東部 (バージニア北部)、米国西部 (北カリフォルニア) 、米国西部 (オレゴン) 、カナダ (中部) 、アジアパシフィック (ムンバイ) 、アジアパシフィック (ソウル) 、アジアパシフィック (シンガポール) 、アジアパシフィック (シドニー) 、アジアパシフィック (東京) 、欧州 (フランクフルト) 、欧州 (アイルランド) 、欧州 (ロンドン) 、欧州 (パリ) 、南米 (サンパウロ) の各リージョンでご利用になれます。
これからは、インフラストラクチャの管理がコーディングの要領でシンプルに行えるようになります。詳細については「bringing existing resources into CloudFormation management in the documentation」をご参照ください。
— Danilo