承諾保留中のピアリング接続をCFnスタックにインポートする

先日の記事でCloudFormationテンプレートでVPCピアリングを生成する場合は、
PeerRoleArnを指定し承諾まで一括で済ませる必要があることを紹介させていただきました。

クロスアカウントVPCピアリング作成時の挙動

作成の場合承諾まで一気に済ませる必要があることは分かりましたが、
保留状態でCloudFormationテンプレートに取り込んだ場合どのような挙動となるのでしょうか。

今回はそれを確認してみます。

承諾保留中のリソースを取り込んでみる

事前に手動で承諾の保留中のピアリング接続を作成しておきます。
今回はpeering-import-testという名称で作成しています。

普段テスト用に利用しているリソースを定義しているスタックがありますので、
そこに追加する形で「スタックへのリソースのインポート」を実行します。

AWSTemplateFormatVersion: 2010-09-09
...
Resources:
  ....
  Peering:
    Type: AWS::EC2::VPCPeeringConnection
    DeletionPolicy: Retain
    Properties: 
      PeerOwnerId: xxxxx
      PeerRegion: ap-northeast-1
      PeerVpcId: vpc-xxxxxx
      VpcId: vpc-xxxx

取り込み時には保留中となっているピアリング接続を選択します。

インポートが完了するとそのリソースにCloudFormationで付与されるタグが付与されます。
実際に確認しに行くとそれらのタグがついており保留中を維持しております。

これにより接続先の環境での承諾を待つ必要なくルートの設定等ピアリング接続のIDをFn::Ref等で取得するような設定が可能となります。

スタックの更新で追加で承諾は取れない

注意すべき点としてこの方法で取り込んだ後、
スタック更新として承諾を取ることができないという点です。

PeerRoleArnパラメータを追加してみる

承認時に使うロールのPeerRoleArnを変更し承認が取れるのかを見てみます。

AWSTemplateFormatVersion: 2010-09-09
...
Resources:
  ....
  Peering:
    Type: AWS::EC2::VPCPeeringConnection
    DeletionPolicy: Retain
    Properties: 
      PeerOwnerId: xxxxx
      PeerRegion: ap-northeast-1
      PeerVpcId: vpc-xxxxxx
      VpcId: vpc-xxxx
      PeerRoleArn: arn:aws:iam::xxxxxx:role/peering-test-role #追加

この場合は置換が発生するため追加で諸諾を取りに行くわけではなく、
別の接続を作成し諸諾を取りに行く挙動をしそうです。

ただ実際に確認してみるとエラーとなり生成に失敗します。

置換は生成後削除のような挙動をするので既にピアリング接続があるから重複エラーかと思っていましたが、
どうもピアリング接続IDの重複が原因となるみたいです。

条件同じだと同じピアリング接続IDになるのかと一瞬不安になりましたが、
リソースを手動削除した上で作成すると別のIDになることと、
CloudTrailのイベントを見ると作成系のイベントは発生せずDescribeVpcPeeringConnectionsのみが確認できるため内部的には事前チェックを行いそこでエラーを発生させていそうです。

保留中のままタグを追加する

では置換が入らないタグを追加する変更をするとどのような挙動をするのでしょうか。
タグを追加して確認してみます。

AWSTemplateFormatVersion: 2010-09-09
...
Resources:
  ....
  Peering:
    Type: AWS::EC2::VPCPeeringConnection
    DeletionPolicy: Retain
    Properties: 
      PeerOwnerId: xxxxx
      PeerRegion: ap-northeast-1
      PeerVpcId: vpc-xxxxxx
      VpcId: vpc-xxxx
      Tags:           #追加
        - Key: foo
          Value: bar

こちらを追加しスタックを更新すると成功となりました。
追加したタグ部分のみの変更が行われてることが確認できます。

終わりに

今回の検証によりピアリング接続の承諾が必須となるのははリソース生成時のみとなり、 既に存在しているリソースに対しては追加で承認を取りに行くことがないことがわかりました。

逆にいえば動作を確認してる限り追加で承認を取る方法は見当たらないため、
手動の承認作業は諸々都合でダメになってロール作るから承諾までやってくれ！ となるような場合は一度リソースを削除した上で再度追加する形での生成が必要となりそうです。
（まずないようなケースな気はしますが...)

既に組込み済みでFn::Ref等の依存がある場合削除が大きくなることがありますので、
可能性がある場合はConditionで生成自体の制御を切り替えられるような作りも選択肢としてみてください。