VPCピアリングとDXGWで関連付けされた２つのAWSアカウント間で片方のVPCだけ削除する

いわさです。

あるAWSアカウントのDirect Connect Gateway(DXGW)に別のAWSアカウントの仮想プライベートゲートウェイ(VGW)を接続している環境がありました。
また、２つのAWSアカウント間ではVPCピアリングも構成されていました。(リクエスタはアカウントB)
それぞれのVPCのルートテーブルではVGWとVPCピアリングに関するルートが静的に登録してある状態です。

以下のような構成です。

この構成を行う場合は、アカウントAとアカウントB側をいったりきたりしながらリソースの指定や関連付けの承認作業などを行うと思います。

では、構成の削除時も同じようにどちらのアカウントへもアクセスし解除のための承認などが必要なのでしょうか。
この状態の時にアカウントBのVPCを削除出来るのかアカウントAでも何か操作が必要なのか、どういう手順で何が必要なのかを確認してみました。

先にまとめ

• VPC削除前に、アカウントBでのVPCピアリングとVGWの削除(orデタッチ）が必要
• 削除のためのアカウントAで必須の作業は無い
  • アカウントBでのVPCピアリング削除時に、アカウントAでのVPCのピアリング情報も削除され、ルートテーブルにVPCピアリングルートのblackholeが残る
  • アカウントBでのVGWデタッチ時にDXGW関連付けは自動で解除される

アカウントBでの削除の流れ

まず、VGWとVPCピアリングが残っている状態だとVPC自体の削除は出来ません。

仮想プライベートゲートウェイの削除

VPCにアタッチされているVGWはVPCからデタッチしてから削除を行う必要がありますので、まずデタッチを行います。
DXGWに関連付けされたままデタッチします。

DXGWのゲートウェイ関連付けを確認してみると、アカウントBのVGWのステータスがdisassociatingに自動で変わりました。

そして、ルートテーブルではVGWへのルートステータスがblackhole(バックホール？)になっています。

VGWが完全にデタッチされると、DXGWのゲートウェイ関連付けからも削除された状態となります。

VPCピアリングの削除

次にアカウントBでVPCピアリングを削除してみます。

VGWはルートを意識せずにデタッチ出来ましたが、VPCピアリングはルートテーブルのVPCピアリングへのルート情報をどうするか選択しないと削除が出来ません。

「関連するルートテーブルエントリを削除」を選択するとVPCピアリングとあわせてルートが削除されます。
「ルートテーブルエントリを削除しない」を選択するとVPCピアリングへのルート情報はblackholeで残ります。

あるいは手動で事前にルートテーブルから不要になるルートを削除しておく方法もあります。
今回は事前に削除しておきました。

今回はリクエストからVPCピアリングの削除を行いましたが、アクセプタからの削除も同じように可能です。

VPC削除

VGWのデタッチとVPCピアリング削除が完了するとVPC自体の削除も出来るようになります。

アカウントAでは特に操作を行わずにVPCとDXGWの関連付けを解除することが出来ました。
ただし、アカウントAのルート情報にアカウントBを指定した情報（例えばVPCピアリング）が存在していた場合はblackholeとして残るので、これはアカウントA側で適宜削除してください。

さいごに

本日はAWSアカウント間でVPCピアリングやDXの共有を行った環境での関連付けの解除を行ってみました。
関連付けを行う際は承認作業が発生したりしていましたが、関連付けの解除にあたっては承認は不要で一方的に解除が可能ということがわかりました。

VGWデタッチ時に関連リソースの確認などもなくデタッチできてしまったので、誤ってDXGWに接続されたVGWをデタッチしてしまうと再びアカウント間でのゲートウェイ関連付けの承認作業が必要になるので、VPC削除に関わらずVGWのデタッチは注意が必要ですね。