AWS Direct Connectリソースの削除方法（VIF・DXGW・VGWの削除）

垣見（かきみ）です。

最近、AWS Direct Connect（DX）上に複数あるリソースのうちいくつかの削除を経験する機会がありました。
こういう回線系のサービスって触って失敗したときの影響を考えると不安ですよね。それなのに、気軽な検証がしにくく一般の資料が少ない…これは困った。

そこで、今回はVIF・DXGW・VGWの削除方法をまとめました。

略称
前提条件
作業実施前の注意事項
作業手順
まとめ
参考

なお、DXって何？という方や構築の手順が知りたい！という方は、弊社の先輩がブログを書いているのでぜひご覧ください。

「DXって何？」→　AWS Direct Connectの接続をザックリ理解する
「DX構築手順」→　
【Direct ConnectでオンプレとAWS環境を繋ぐ！シリーズ】：
　【第1弾】Direct Connect Gateway (DXGW) の構築手順
　【第2弾】仮想プライベートゲートウェイ(VGW)の構築手順
　【第3弾】仮想インターフェイス（VIF）の承認作業手順

略称

使われることがある略称をまとめておきます。個人的にDXGWとVGWを混同しやすいです。

AWS Direct Connect：DX
Direct Connect ゲートウェイ：DXGW
仮想プライベートゲートウェイ：VGW
仮想インターフェイス（Vertial Interface）：VIF

前提条件

3点、前提として

Direct Connect ゲートウェイを使っている
占有型という前提
手順内でユーザー権限については扱わない

ということを、Direct Connectの簡単な解説を入れながら説明しています。詳しい方は読み飛ばしてください。

1. 削除対象と構成

今回の手順で説明する削除対象はDirect Connect ゲートウェイを使った構成です。
DX向けのルートテーブル、Direct Connect ゲートウェイ、1つのVPCと関連付いた1つの仮想プライベートゲートウェイ、2本の仮想インターフェイス（VIF）を削除します。

※Direct Connect ゲートウェイの強みは本来1:1であるVIFとVPCの数を1:多にできることですが、今回はVPCは1つです。
※今回はOrganizations環境で、Direct Connectの接続本体は別のアカウントで管理しています。DXの親玉アカウントがあって、そこで切り分けたVLANを今回の削除対象アカウントでありがたく使っている…というようなイメージです。詳しくは1つ下の「2. 占有型と共有型」をご覧ください。

2. 占有型と共有型

Direct Connectの回線形態には占有型と共有型があります。
今回は占有型という前提で手順を作成しています。

占有型：物理接続（Connection）を自分のものとして扱い、自由にVLANを切り分けて使う方法。AWSのOrganizations環境ではある専用アカウントから別アカウントに切り分けることもできます。契約した事業者から払い出されたパターンともともと物理接続を持っている場合があります。
共有型：契約した回線事業者（AWS Direct Connect デリバリーパートナー）が持つ物理接続（Connection）からVLANが払い出され、そのVIFを使用する方法。

同じ賃貸の家でもシェアハウスか一人で暮らすか、みたいな違い（先輩からきいてわかりやすかった例え）ってことですね。もちろんデータセンターを持っていたりすれば持ち家一軒家としてカスタマイズすることもできます。

占有型・共有型にはその他にも（削除にはそこまで関わってこないですが）違いがあるので、さらに興味がある方は公式資料のp47, p50あたりをご覧ください。
【AWS Black Belt Online Seminar】AWS Direct Connect（2021/2/9）

VLANやVIFについてよくわからない…という方は、以下の弊社ブログが詳しいです。ここはAWSというより一般的なネットワーク用語だそうですが、なかなか難しいですよね。
AWS Direct Connectの概念の整理...Connectionとは？VIFとは？

3. ユーザー権限

今回の削除手順ではIAMやSCPといったユーザーの権限については扱いません。適宜環境に合わせて適切な権限を使用してください。

作業実施前の注意事項

当該DX接続の提供・管理・利用に関わる関係者（死活監視やダウン時の通報といった監視・運用担当者、オンプレ側のネットワーク管理者、回線事業者など）がいる場合、AWSリソースの削除についてあらかじめ連絡・調整をする必要性の有無を確認すると良いでしょう。
削除後に改めてDirect Connectを使いたい場合、1からの再設定が必要になってしまいます。社内のネットワークに関わる重要なサービスなので、本当に消しても問題ない回線かどうか、事前確認を念入りに行いましょう。pingコマンドなどでネットワークの疎通を確認してください。
できれば1つめの手順「ルートテーブルの削除」からしばらく静観期間を取り、影響が出ないことを十分に確認してから以降の削除手順を進めることをお勧めします。
ルートテーブルの削除時、何らかの業務影響が発生してもすぐに修正できるようにするため、SCP等の権限一時変更があってもはすぐに元に戻さないようにしましょう。

作業手順

ルートテーブルの削除
DXGWからVGWの関連付けをデタッチ
VGWをVPCからデタッチして削除
VIFを削除
DXGW削除

という順で進みます。

ちなみにVPCからVGWをデタッチすることで自動的にVGWとDirect Connect ゲートウェイとの関連付けが解除されるそうなのですが、「作業の後戻りや切り戻しがしやすく1つずつ確認しながらやったほうが安全」という理由から2と3の手順を分けます。（手順書作成時に先輩に指摘された学びです。横着厳禁…！）

1. ルートテーブルの削除

DX向けのルートテーブルを削除します。

コンソールから【VPC】を検索し、移動する。
左ペインで【ルートテーブル】を選択する。
Direct Connect に関するルートテーブルを選択し、【アクション】から【ルートを編集】を押す。
削除対象の仮想プライベートゲートウェイ（vgw-XXXXXXXX）をターゲットとしたルートの【削除】ボタンを押し、【変更を保存】を押す。
全ての対象ルートテーブルに対し上記3・4を実施する。

2. DXGWからVGWの関連付けをデタッチ

コンソールから【Direct Connect】を検索し、移動する。
左ペインで【Direct Connect ゲートウェイ】を選択し、【ゲートウェイの関連付け】を選択する。
消したいVGW（vgw-XXXXXXXX）を選択し、【関連付けを解除する】を押す。
ダイアログボックスで【関連付けを解除する】を押す。
【ゲートウェイの関連付け】の状態が緑の【associated】から灰色の【disassociating】に遷移したことを確認する。
何度か更新ボタンを押し、【ゲートウェイの関連付け】から削除対象のVGWが消えたことを確認する。（※10分ほどかかる）

3. VGWをVPCからデタッチして削除

コンソールから【VPC】を検索し、移動する。
左ペインで【仮想プライベートゲートウェイ】を選択する。
消したいVGWを選択し、【アクション】-【VPCからデタッチ】を選ぶ。
作業前
ダイアログボックスで【仮想プライベートゲートウェイをデタッチ】を押す。（※前工程6のVGW関連削除が終わっていないとエラーThis call cannot be completed because there is a conflicting pending workflow for vgw-XXXXXXXXXXが発生するので注意）
何度か更新ボタンを押し、対象の仮想プライベートゲートウェイのステータスが緑色の【アタッチ済み】から灰色の【disassociating】-【detached（デタッチ済み）】に遷移するのを確認する。（※10分ほどかかる）
作業後
デタッチ済みの消したいVGWを選択し、【アクション】-【仮想プライベートゲートウェイを削除】を選択する。
ポップアップ画面で【delete】と入力し、【削除】を選択する。
対象の仮想プライベートゲートウェイの状態が、赤の【deleted（削除済み）】になるのを確認する。
削除後
※削除された仮想プライベートゲートウェイの提案は、3 日間表示されたままとなります。