締切前日の夕方。最後の動作確認だけを残して、僕は余裕すら感じていました。
👨💻「ALBとECSの疎通確認、これで終わりだ…」
ところが。
👨💻「ん、何で通らない？いやな予感がする…」
ALBに紐づくAZを焦って確認すると、愕然としました。
👨💻「AZ-1aにパブリックサブネットしかない…AZ-1cにはプライベートサブネットだけ？」
そもそもパブリックサブネットとプライベートサブネットの両方が入っているAZが無かったのです。
👨💻「まずい、サブネット追加しないと…」
しかし。
「IPアドレスを使い切っているだと…？」
自己紹介
最近AWSを本格的に触り始めたnaokiです。
昨年末SESに転職し、現在はAI基盤モデル開発企業に常駐し、バックエンド開発やインフラ構築を担当しています。
今回は幸運にも自社（SES）サービスの立ち上げメンバーに選ばれ、PM兼テックリードとしてMVP開発を進めていました。
ネットワーク設計はほぼ未経験ながら勉強も兼ねてインフラを担当させてもらっていました。
気づいた時の構成
以下のような構成にしていました。
パブリックサブネットとプライベートサブネットの両方が入っているAZが無い状態でした。
なぜこんな構成で最後まで気づかなかったのか...。
なぜ問題が起きたのか
元々の設計は以下のようなものでした。
- VPC CIDR: `10.0.10.0/24`（256アドレス）
- Public Subnet: `10.0.10.0/25`
- Private Subnet: `10.0.10.128/25`
AWSで10.0.10.0/24のVPCを2つのサブネットに分割し、10.0.10.0/25をパブリックサブネット、10.0.10.128/25をプライベートサブネットとして設定しました。
これは元々256個あるIPアドレスを128個ずつ、ちょうど半分に分割した形です。
各サブネットはネットワークアドレスとブロードキャストアドレスの2つを除いた126個のIPアドレスを使用できます。
25ビット目の値（0か1か）でサブネットを区別しています。
例えば、10.0.10.0/25は25ビット目が0、10.0.10.128/25は25ビット目が1となります。
10.0.10.0/25 : 00001010.00000000.00001010.00000000
10.0.10.128/25 : 00001010.00000000.00001010.10000000
1つのAZ内で、VPC内の全てのIPアドレスを使い切る設計にしていたため、新規でサブネットを作成することが不可能だったのです。
再設計で乗り越えた危機
腹をくくり再設計し、以下のように構成を変更しました。
- AZ-1a
- Public subnet:
10.0.10.0/26 - Private subnet:
10.0.10.64/26
- Public subnet:
- AZ-1c
- Public subnet:
10.0.10.128/26 - Private subnet:
10.0.10.192/26
- Public subnet:
これで複数AZに対応でき、拡張性も持たせることができました。
終わりに
ネットワーク設計の基本を知らず、土壇場で設計を変える羽目になるという苦い経験でしたが、これをきっかけにネットワーク設計の重要性を深く理解しました。
この記事が、誰かの役に立てば幸いです。