設計書のないAWS環境を高速で理解したい！〜 リバースエンジニアリングの効率化とgpt-4oの活用 〜

### はじめに

AWS (Amazon Web Services) は、その柔軟性と拡張性から多くの企業で利用されていますが、時として「設計書がない」「過去の担当者がいない」といった状況に直面することがあります。大規模なAWS環境(AWSアカウント)を引き継いだ場合、その複雑さに圧倒され、どこから手を付けて良いか途方に暮れてしまうこともあるでしょう。

今回そんな状況に陥った私が奮闘しAIを使って、ある程度効率的にAWS環境を理解できるようになった方法をご紹介します。

### まとめ
AWS CLI を活用して必要な情報を一括で収集し、GPT-4oにPythonのdiagramsライブラリを組み合わせることで、AWS環境の構成図をサッと書かせちゃいます。

### 1. 困りごと：設計書なし、担当者不在、そしてコンソールでは表示しきれない数のリソース

まず、私たちが直面する典型的な問題点を整理しましょう。

*   **設計書がない:** システム全体の構成やリソース間の関係性が不明。
*   **担当者不在:** 聞ける人がいないため、自力で解決する必要がある。
*   **リバースエンジニアリングの必要性:** 現状からシステムの全体像を把握する必要がある。
*   **コンソールで判別できる量を超えている:** 大量のリソースがあるのでAWSマネジメントコンソールでは追いつけない。情報量が多く、必要な情報を見つけ出すのが困難。



#### 2. 一括収集：AWS CLIの活用

そこで、まず最初に行うべきは、主力リソースについてAWS CLIで一括収集することです。具体的には、以下の情報を収集します。

*   **ALB (Application Load Balancer):** ロードバランサーの設定、リスナー、ターゲットグループなど。
*   **EC2 (Elastic Compute Cloud):** インスタンスの設定、セキュリティグループ、キーペアなど。
*   **RDS (Relational Database Service):** データベースの設定、セキュリティグループ、パラメータグループなど。
*   **Subnet (サブネット):** VPC (Virtual Private Cloud) のサブネット情報、CIDRブロックなど。

これらの情報は、AWS CLIを使って以下のようなコマンドで取得できます。

```bash
aws elbv2 describe-load-balancers --output json > alb.json
aws ec2 describe-instances --output json > ec2.json
aws rds describe-db-clasters --output json > rds.json
aws ec2 describe-subnets --output json > subnet.json
```

`--output json` オプションを付けることで、JSON形式で情報を出力できるため、後の処理が容易になります。これ、地味に便利です！

#### 3. 可視化への挑戦：AIとMermaid.js

収集したJSONデータを基に、AWS環境の構成図を作成します。AIを活用して、Mermaid.js形式のコードを生成してもらいました。

Mermaid.jsは、テキストベースで図を作成できる便利なツールで、以下のようなコードでVPCの構成図を記述することで、図を作成できます。

```
graph TB;
    VPC1[VPC: vpc-11111111111111111]
    VPC2[VPC: vpc-22222222222222222]

    subgraph VPC_11111111111111111
        direction TB
        Subnet1[Subnet: 10.0.8.0/24]
        Subnet2[Subnet: 10.0.6.0/24]
        Subnet3[Subnet: 10.0.3.0/24]
        Subnet4[Subnet: 10.0.4.0/24]
        Subnet5[Subnet: 10.0.2.0/24]
        Subnet6[Subnet: 10.0.7.0/24]
        Subnet7[Subnet: 10.0.1.0/24]
        Subnet8[Subnet: 10.0.5.0/24]

        Subnet1 --> ALB1[ALB: one-test-alb-web-a]
        Subnet1 --> ALB2[ALB: two-test-alb-api-a]
        Subnet2 --> NLB1[NLB: one-test-nlb-socket-a]
        Subnet3 --> RDSCluster[RDS Cluster: one-test-aurora-cluster-a]
        Subnet4 --> RDSCluster
        Subnet5 --> RDSCluster
        Subnet6 --> NLB1
        Subnet7 --> EC2Instance1[EC2: i-11111111111111111]
        Subnet7 --> EC2Instance2[EC2: i-22222222222222222]
        Subnet7 --> EC2Instance3[EC2: i-33333333333333333]
        Subnet7 --> EC2Instance4[EC2: i-44444444444444444]
        Subnet7 --> EC2Instance5[EC2: i-55555555555555555]
    end

    subgraph VPC_22222222222222222
        direction TB
        Subnet9[Subnet: 172.31.16.0/20]
        Subnet10[Subnet: 172.31.0.0/20]
        Subnet11[Subnet: 172.31.32.0/20]
    end

    VPC1 --> VPC2
```

```mermaid
graph TB;
    VPC1[VPC: vpc-11111111111111111]
    VPC2[VPC: vpc-22222222222222222]

    subgraph VPC_11111111111111111
   22222222222222222
        Subnet1[Subnet: 10.0.8.0/24]
        Subnet2[Subnet: 10.0.6.0/24]
        Subnet3[Subnet: 10.0.3.0/24]
        Subnet4[Subnet: 10.0.4.0/24]
        Subnet5[Subnet: 10.0.2.0/24]
        Subnet6[Subnet: 10.0.7.0/24]
        Subnet7[Subnet: 10.0.1.0/24]
        Subnet8[Subnet: 10.0.5.0/24]

        Subnet1 --> ALB1[ALB: one-test-alb-web-a]
        Subnet1 --> ALB2[ALB: two-test-alb-api-a]
        Subnet2 --> NLB1[NLB: one-test-nlb-socket-a]
        Subnet3 --> RDSCluster[RDS Cluster: one-test-aurora-cluster-a]
        Subnet4 --> RDSCluster
        Subnet5 --> RDSCluster
        Subnet6 --> NLB1
        Subnet7 --> EC2Instance1[EC2: i-11111111111111111]
        Subnet7 --> EC2Instance2[EC2: i-22222222222222222]
        Subnet7 --> EC2Instance3[EC2: i-33333333333333333]
        Subnet7 --> EC2Instance4[EC2: i-44444444444444444]
        Subnet7 --> EC2Instance5[EC2: i-55555555555555555]
    end

    subgraph VPC_22222222222222222
        direction TB
        Subnet9[Subnet: 172.31.16.0/20]
        Subnet10[Subnet: 172.31.0.0/20]
        Subnet11[Subnet: 172.31.32.0/20]
    end

    VPC1 --> VPC2
```


gpt-4oに上記のようなMermaid.jsコードを生成してもらうことで、AWS環境の構成図を自動的に作成することを試みました。しかし、手軽な一方で、うーん、あまりきれいではありません。さらなる工夫が必要です。

#### 4. より高度な可視化：gpt-4oとPython diagrams

次に、Pythonのdiagramsライブラリで出力させる方法を試しました。
**python diagramsでVPCやSubnetをアイコンなしのグルーピングの枠として表現して。**
diagramsは、AWSやGCPなどのクラウド環境の構成図を、Pythonコードで記述できる強力なライブラリです。

```python
from diagrams import Diagram, Cluster
from diagrams.aws.network import VPC, ALB, NLB
from diagrams.aws.database import RDS
from diagrams.aws.compute import EC2

with Diagram("aws  architecture", show=False):

    with Cluster("VPC: vpc-11111111111111111"):
        with Cluster("PublicSubnet\n10.0.0.0/24, 10.0.4.0/24, 10.0.2.0/24"):
            rds = RDS("one-test-aurora-cluster-a")
        with Cluster("PrivateSubnet\n10.0.7.0/24"):
            ec2_1 = EC2("i-11111111111111111")
            ec2_2 = EC2("i-22222222222222222")
            ec2_3 = EC2("i-33333333333333333")
            ec2_4 = EC2("i-44444444444444444")
            ec2_5 = EC2("i-55555555555555555")

        with Cluster("PublicSubnet\n10.0.8.0/24"):
            alb1 = ALB("one-test-alb-web-a")
            alb2 = ALB("two-test-alb-api-a")
        with Cluster("PublicSubnet\n10.0.6.0/24, 10.0.7.0/24"):
            nlb = NLB("one-test-nlb-socket-a")

        rds - ec2_1
        alb1
        alb2
        nlb

    with Cluster("VPC: vpc-22222222222222222"):
        with Cluster("Subnet\n172.31.16.0/20"):
            pass
        with Cluster("Subnet\n172.31.0.0/20"):
            pass
        with Cluster("Subnet\n172.31.32.0/20"):
            pass
```
<!--
![aws_architecture.png](fig)

-->



gpt-4oとPython diagramsを組み合わせることで、自動的に構成図を生成する試みは、一定の成果を上げました。しかし、完全にキレイに描画することはできません。以下の点で課題が残りました。

*   **グルーピングの理解:** VPCやサブネットなどグルーピングして枠にしたいリソースも指示なしではアイコンで表現しちゃう。「VPCやSubnetをアイコンなしのグルーピングの枠として表現して。」が必要。
*   **リソース間の関係性の複雑さ:** 実際のAWS環境は、想定以上に複雑な関係性を持っている場合が多く、gpt-4oがそれを正確に理解するのはちょっと困難。
*   **命名規則の曖昧さ:** リソースの命名規則が統一されていない場合、gpt-4oがリソースの種類や役割を判断するのがけっこう難しい。

最終的には、gpt-4oが生成した構成図をベースに、手動で修正を加える必要がありました。しかし、gpt-4oを活用することで、手作業の量を大幅に削減できたことは間違いありません。


### まとめ

今回の記事では、設計書のないAWSアカウントを高速で理解するために、以下の方法をご紹介しました。

1.  **一軍のリソースを確認する:** ELB  → EC2 → RDSの関係性を把握することで、おおよそシステムの概要を理解する。
2.  **AWS CLIを使用する:** 必要な情報を一括で収集することで、コンソールのノイズを排除する。
3.  **gpt-4oに頼ってpython diagramsで描画する:** gpt-4oとPython diagramsを組み合わせることで、構成図の作成を効率化する。

これらの方法を組み合わせることで、AWSアカウントのリバースエンジニアリングを効率化し、システムの全体像を迅速に把握できます。

ただし、AIに完全に回答を求めることは難しく、最終的には手動での修正が必要になります。
ある程度把握できれば十分でしたので、途中でやめ、答え合わせをしました。
ほどほどの距離感で完璧を求めないAIの使い方がよさそうです。

### 付録

最後に、今回の記事で紹介したdiagramsのDockerfileのビルド・実行方法について説明します。

#### Dockerfileのビルド・実行

1.  Dockerfileを作成します。
    ```Dockerfile
    FROM  registry.access.redhat.com/ubi8/python-312:1-37.1736925652
    USER root
    WORKDIR /app
    #ENV https_proxy=http://proxyserver/
    RUN yum install -y graphviz.x86_64
    RUN pip3 install diagrams --progress-bar off
    ```

2.  Dockerイメージをビルドします。

    ```bash
    docker build . -t diagrams:p312
    ```
3.  Dockerコンテナを実行します。

    ```bash
    docker run -it  -v `pwd`:/app:Z  diagrams:p312   python diagram.py
    ```

これらの手順に従うことで、AWS環境の構成図を自動的に生成し、Dockerコンテナ上で実行できます。

AWS雑多なアカウントのリソースで理解に苦労している方々が他にもいれば嬉しいです！