これ知ってた！？AWSのネットワーク管理ソリューション使ってみた

# AWSでのネットワーク管理

AWS を利用していると、多くのアカウント、リージョンが混在し、ネットワーク管理が煩雑化することが多いと思います。
そもそもネットワーク管理は運用負荷が非常に高い業務の一つです。その理由として、どうしてもレガシーな方法（Excel、Drawioなど）で管理を行うことがあげられると思います。

本来は簡単に設定変更できることがクラウドの強みであるはずなのに、TGWなどのネットワークリソースのルーティングを1つ変更すると、変更しないといけない資料が5つはある。といった形です。

こういった運用負荷を少しでも軽減できそうなソリューションを発見したので、使ってみました。
結論から言うと私が期待した機能ではなかったのですが、ご紹介させてください。
（オーケストレーションを管理と曲解してしまった、、）

# AWS のソリューション

AWS では EC2 や Lambda などの**サービス**とは別に、それらを組み合わせて提供している**ソリューション**というものがあります。
以下のようなものはソリューションとしてご存じの方も多いかと思います。

| **ソリューション名** | **概要** |
| :----------: | :------------ |
| `Instance Scheduler` | EC2インスタンスなどの起動停止をスケジューリング |
| `ワークロード検出（旧Perspective） ` | AWSの構成図を生成 |
| `生成AIアプリケーションビルダー` | 生成AIアプリケーション |

上記のようなソリューションは CloudFormation で簡単に作成が可能で、非常にユーザビリティに優れているため、運用まで考えると自作するよりも良い選択肢であることが多いです。
（自作した後に類似したソリューションを発見してしまうと悲しいので定期的に確認するのがおすすめです！）

# AWS Transit Gateway のネットワークオーケストレーション

## 概要

本記事では「[AWS Transit Gateway のネットワークオーケストレーション](https://aws.amazon.com/jp/solutions/implementations/network-orchestration-aws-transit-gateway/)」というソリューションを取り上げます。
詳しくは公式ページをご確認いただくのがいいと思いますが、大きく以下のような機能があるようです。

* マルチアカウント／リージョンでのネットワーク設定管理
* 接続リクエストの承認処理
* ウェブUI
* ネットワークの変更ガードレール

また、費用は1か月あたり **~85.22 USD** となっていますが、TGW の費用を含んでいるため、実質的な費用はかなりリーズナブルかと思います。

## 使ってみる！

[ソリューションを展開する](https://docs.aws.amazon.com/solutions/latest/network-orchestration-aws-transit-gateway/deploy-the-solution.html)手順に従って、操作を行います。
せっかくなので流れをさらっていきます。

### AWS RAM を有効化

Organizations の画面から RAM のアクセスを有効化します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/0a8b7346-bba4-4430-ae4a-a47c700b2b7f.png)

:::note warn
公式手順では`設定`から移動するようになっていますが、おそらく`サービス`です。
:::

### 組織ARNの取得

マネジメントコンソールからこちらを確認するのは面倒なので、以下のコマンドを CloudShell で実行します。

```bash
aws organizations describe-organization
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/2ecc545d-8a34-4412-ac70-3bfedd9e6475.png)

### 組織ロールスタックを起動する

実装手順にあるリンクをクリックすると CloudFormation のスタック作成画面に遷移するので、スタックの作成を行います。

1.テンプレートのURLが正しいことを確認し、`次へ`をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/4a4ffd21-c13b-40f6-94a6-77bcf8caddb3.png)

:::note warn
リンクを開いた際にリージョンが異なる場合がありますので注意してください。
:::

2.スタック名とパラメータを入力し、`次へ`をクリックします。

| パラメータ名 | 説明 | 例 |
| :------------: | :----------- | :------------: |
| HubAccount | 組織の管理アカウントID | 123456789123 |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/b1b6b32f-7ffd-48d3-b83d-1190196772ef.png)

3.IAMリソースが作成されることを承認し、`次へ`をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/c9c75cb2-cf04-4ac5-a94a-7ba06ab64ba7.png)

4.`送信`をクリックします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/86f6d28b-5570-4d19-93dc-bcd05fb91c91.png)

5.スタックの状態が`CREATE_COMPLETE`になったことを確認します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/863e98c6-50fa-411a-86ed-11ad23c52879.png)

### AWS RAMハブスタックのサービスリンクロールを起動する

こちらの手順は、AWS RAM の管理アカウントに「AWSServiceRoleForResourceAccessManager」という IAM ロールが存在しない場合に必要な手順となります。
今回はすでにあったので、実施しませんが、[組織ロールスタックを起動する](#組織ロールスタックを起動する)と同様の手順で作成可能です。

### ハブスタックを起動する

管理アカウントでスタックを起動します。（手順は[組織ロールスタックを起動する](#組織ロールスタックを起動する)を参照）

パラメータは以下の通りです。（今回はとりあえず使ってみるのが目的なので、設定値は割と適当です。）

| パラメータ名 | 説明 | 例 |
| :------------: | :----------- | :------------: |
| Principal Type | 利用するアカウントを列挙するか組織全体にするかを選択 | AWS Organization ARN |
| Account List or AWS Organizations ARN | アカウントリストか組織ARNを入力 | [組織ARNの取得](#組織ARNの取得)で取得したARN |
| Allow External Principals | 組織外のアカウントを許可するか | No | 
| (Optional) IAM Role ARN of Management Account | OrganizationsにアクセスするためのIAMロールARN | [組織ロールスタックを起動する](#組織ロールスタックを起動する)で作成したIAMロールのARN |
| Web User Interface | WebUIを利用するか | Yes |
| Allow Listed Ranges | WebUIへのアクセスを許可するリスト | 0.0.0.0/1,128.0.0.0/1 |
| Cognito Domain Prefix | Cognitoのドメインプレフィックス | 任意の文字列 |
| Console Login Information Email | Cognitoの一時パスワードを送信するメールアドレス | 有効な任意のメールアドレス |
| Admin Username | 管理者ユーザー名 | adminuser |
| Read-Only Username | 読み取り専用ユーザー名 | readonlyuser |
| Set MFA for Cognito to 'ON' or 'OPTIONAL' | MFA設定を必須とするか | OPTIONAL |
| SAML Provider Name | SAMLプロバイダー名 |  |
| SAML Provider Metadata URL | SAMLプロバイダーのメタデータURL |  |
| (Optional) Do you wish to use an existing transit gateway? If yes, you must provide the transit gateway id below. | 既存のTGWを利用する場合はTGW IDを入力 |  |
| (Optional) Do you wish to register the transit gateway with a global network?  | グローバルネットワークの登録を行うか | No  |
| (Optional) Do you wish to use an existing global network? If yes, you must provide the global network id below.  | グローバルネットワークID |  |
| Choose the type of destination for target Transit Gateway  | ルートテーブルが関連付けられたときにデフォルトで追加する送信先 | All-Trafic(0/0) |
| If selected 'Custom-Destinations', provide a comma separated list of CIDR Blocks.  | 'Custom-Destinations'を選択した場合の送信先 | 10.0.0.0/8,172.0.0.0/16 |
| If selected 'Custom-Destinations', provide a comma separated list of Customer-managed Prefix List IDs.  | 'Custom-Destinations'を選択した場合の送信先 | p-xxxxxx |
| Tag key for subnets - Adds subnet to VPC attachment and add routes to route table associated with the tagged subnet. | VPCアタッチメントとルートを追加するサブネットのタグキー | Attach-to-tgw |
| Tag key for subnets - Only adds routes to route table associated with the tagged subnet. | ルートを追加するサブネットのタグキー | Route-to-tgw |
| Tag key for TGW Route Table Association with TGW Attachment | アタッチメントと関連付けを行うTGWルートテーブルのタグキー（初期デプロイ時は変更不可） | Associate-with |
| Tag key for Route Propagation to TGW Route Table(s) | TGWルートテーブルで伝播を作成するタグキー（初期デプロイ時は変更不可） | Propagate-to |
| (Optional) Comma separated list of VPC tag keys to copy from VPC to TGW Attachments | タグキーのカンマリスト、VPCのこのタグをVPCアタッチメントにコピー | Associate-with,Propagate-to |
| Transit Gateway Peering Tag | TGW間ピアリングのアタッチメントを作成するためのタグキー名。値は<tgw-id_aws-region>の形式 | TgwPeer |
| Receive Approval Notifications | 承認メッセージを受け取るか | Yes |
| Approval Notification Email | 承認メッセージの受取先 | 任意の有効なメールアドレス |

正直タグキー関連のパラメータは今のところよくわからないですが、利用していくうちに解像度があがることを信じて進めます。

こちらはスタックの作成にそこそこ時間がかかるようです。（私の場合は10分かからずに終わりました）

:::note info
これ、CloudFrontとかWAFとかあるけどほんとにこんなコストでできるのだろうか。。ドキドキ。。。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/121b3eb8-f53b-4345-9ed9-2ae5775de70e.png)

設定したメールアドレスにCognitoの一時パスワードが届いているはずなので確認しましょう。

:::note info
件名：Network Orchestration for AWS Transit Gateway Console Credentials (ap-northeast-1)
上記のようなメールが届きます。
:::

早速 WebUI にアクセスしてみます！

### WebUIへのアクセス

作成したスタックの出力に **Console** という値があるのでそのリンクをクリックしてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/371b27c0-8a6d-45e0-ac34-98058a5eed91.png)

メールのパスワードを使用してサインインしてみましょう！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/b6342d58-457d-4486-933a-c65a4dab91d2.png)

パスワード変更が求められるので変更します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/7d7d5f7d-1060-4eb2-9924-6b309db76035.png)

WebUIが開けました！！
まだ何にもないですね、、

### スポークスタックを起動する

今度はスポークスタックを起動します。
おそらく操作を実際に行う IAM ロール等が含まれているので、StackSets を利用して展開するのがよさそうですね。
今回は一旦シンプルに CloudFormation スタックで作成します。

| パラメータ名 | 説明 | 例 |
| :------------: | :----------- | :------------: |
| Network (Hub) Account | ネットワークアカウントID（TGWがあるアカウント） | 123456789123 |

### VPCを管理

VPCを管理下に置くために、ハブスタックを作成する際に設定したタグをつける必要があります。

| タグキー | タグ値 | 備考 |
| :----------: | :------------: | :-------- |
| Associate-with | Flat/Isolated/Infrastructure/On-premises  | デフォルトのTGWルートテーブル名のいずれかかカスタムキー |
| Propagate-to | Flat/Isolated/Infrastructure/On-premises | デフォルトのTGWルートテーブル名のいずれかかカスタムキー |

今回は`Flat`をつけてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/0450ccef-3779-4ef3-9cd3-9d50edffba6f.png)

ダッシュボードを確認すると情報が追加されました！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/93784a05-a715-4fdb-b46f-496155e02f87.png)


サブネットにもタグを追加します。

| タグキー | タグ値 | 備考 |
| :----------: | :------------: | :-------- |
| Attach-to-tgw |  | 値はなし |
| Route-to-tgw |  | 値はなし |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/c0a17905-0e68-490c-878b-584f78275603.png)

Action Items を確認すると項目が追加されています！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/d35b1bca-b82b-4205-95b9-1cc2e7762387.png)

あれ？失敗してる。
メッセージの内容からルートを作成する際に、TGW IDが見つからないとされています。
おそらく、アタッチメントの作成とルートの作成は同時にできません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/ba9aea36-f242-4365-b171-9ab4198d9546.png)

なので改めて、`Attach-to-tgw`だけで作成してみます。
少し待機するとアタッチメントが作成されていました！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/44053c58-abe7-4d12-9389-008a58908f4c.png)

ルートテーブルの関連付けと伝播も追加されています！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/cfdeb919-49a5-4c05-95df-7d301313db10.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/3ea5c8de-9324-4049-a1d7-d6c21c7f9107.png)

ダッシュボードを確認するとサブネットが追加されました！

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/2c93505f-0028-4e4e-9e56-5fc102c37324.png)

では改めて、`Route-to-tgw`も追加します！

:::note info
本来はTGWアタッチメントは専用のサブネットを切ることがベストプラクティスであるため、ルートが不要であることからこのような仕様になっているのではないかと思います。
:::

ルートテーブルを更新すると、ルートが追加されています。

:::note info
`Route-to-tgw`を外すとルートも自動的に消えます。
`Attach-to-tgw`を外してもアタッチメントは消えませんでした。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4026620/a1510554-5b1e-4866-ad43-b2e70213f811.png)

ここまでが基本的な機能といった感じでした。
（ようやくタグが腹落ち。。）

# 感想・所感

全体的にかなり上級者向けなソリューションだと感じました。
タグポリシー等による制御、ServiceCatalogによりVPCなどのネットワークリソースを作成する際にタグを強制的につけるなど、すでにかなり運用の整理ができている方向けなのかなという感想です。

正直当初期待した機能とはかなり違いましたが、今後、冒頭に述べたネットワーク管理簿の代替になるような機能が追加されれば便利になりそうです。
（自動でネットワーク構成図を作成してくれて、更新してくれるなどあれば幸せですね）

また、試せていない機能もあるので、ぜひ触ってみてはいかがでしょうか？

Control Tower管理下で利用するブログもあったのでリンク貼っておきます。
https://aws.amazon.com/jp/blogs/mt/serverless-transit-network-orchestrator-stno-in-control-tower/

# 弊社では一緒に働く仲間を募集中です！
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。
https://engineer.po-holdings.co.jp/