はじめに

これは、自分のチームでクラウドを対応することになった自身の経験をもとにしています。
最終的にクラウドアーキテクトチームを組織するまでの試行錯誤を共有できればと思います
自分のチーム/組織でクラウドを対応することになったリーダー、管理職の方々への参考に！
なお、本投稿ではIaaSクラウドを基本とし、AWSを前提にしています。

体制作りと漏れがちな考慮

クラウドを対応することになった場合、メンバーを集めてクラウド対応を始めるのか、それとも今いるメンバーでクラウド対応を始めるのか、これはそれぞれの事情によるところが大きいでしょう。AWS上で環境を作りには、様々なチュートリアルやハンズオン、資料が揃っています。参考情報は以前の投稿にも書きましたし、Qiitaなどでも豊富にネタが揃っています。
AWSのスキル取得は順次行っていけばよいのですが、どうしてもあらかじめ考慮しておいた方がよいスキルがあります。 ネットワーク です。

予想外に問われるネットワークスキル

クラウドになるとサーバやストレージ同様にネットワーク機器やLANケーブルなど全く見えなくなります。では、考慮しなくて良くなったのかというと全くそんなことはありません。一番悩ましいネットワークアドレス設計が残っています。ネットワークの機能自体は、他のAWSサービス同様に様々な資料が公開されています。また、レクチャー資料もAWSは非常に豊富です。

（参考）

AWS のネットワークで知っておくべき10のこと

ただ、元々ネットワークエンジニア（今でもそのつもり）をしていて、ネットワークエンジニア育成などをしていた自身の経験や、クラウドチームを作ってからの経験から、難しいのはアドレス設計だと感じています。
プライベートアドレス帯域（RFC1918）を使用するのは前提として、では10.0.0.0/8、172.16.0.0/12、192.168.0.0/16のさてどのレンジを使うのか。また、サブネット化を行う当たってどのように分割をすべきか…これは実際のネットワーク設計やその考え方を学ぶ必要があるのではないかと思っています。

あふれ出てくる/24？

多くの技術サイトやレクチャー/ハンズオンサイトでは、/24（＝254個のアドレスを利用可能）を例としていることが多いです。これが潤沢に使えるならば理想ですね。ただ、 今のご時世/24ネットワークがあふれ出してくる組織は多くはないのではないでしょうか？
ネットワークエンジニア当時、自組織やお客様組織のアドレス設計は残されたアドレス帯域の隙間を塗って行っていました。構築するAWS環境が未来永劫どこにも接続しない環境ならばどのような設計をしても問題はないのですが会社組織で構築する環境はなかなかそうもいかないのではないでしょうか。
そして、AWSはそれなりにアドレスを消費します。

AWSのネットワーク仕様

AWSのネットワーク仕様を見てみましょう

利用可能なアドレス範囲

IPv4では、サブネットのサイズは/16から/28までとなっています。/16は良いのですが、最小が/28というのはネットワークエンジニアから見ると少し広いな、という印象です。

AZ(アベイラビリティーゾーン）とネットワーク
AWS上で構築を行う際は、ベストプラクティスはマルチAZというのは様々なドキュメントや試験に登場すると思います。ただし、サブネット（VPC Subnet、ネットワークセグメント）はAZを越えられません。このため、あるEC2サーバをマルチAZ構成（全AZを利用）かつ最小アドレス帯域で配置する場合、以下のような配置となります。

EC2サーバ#1　AZ-1　192.168.1.0/28
EC2サーバ#2　AZ-2　192.168.1.16/28
EC2サーバ#3　AZ-3　192.168.1.32/28

AWS Transit Gatewayとネットワーク
さらに、これらサブネット同士をAWS Transit Gatewayで接続する場合、AWS Transit Gatewayのベストプラクティスに従うならば下記のようになります。

EC2サーバ#1セグメント AZ-1 192.168.1.0/28
EC2サーバ#2セグメント AZ-2 192.168.1.16/28
EC2サーバ#3セグメント AZ-3 192.168.1.32/28
Transit Gatewayアタッチメント#1セグメント AZ-1 192.168.1.48/28
Transit Gatewayアタッチメント#2セグメント AZ-2 192.168.1.64/28
Transit Gatewayアタッチメント#3セグメント AZ-3 192.168.1.80/28

（AWS Transit Gatewayの仕様は下記がとても参考になります）

これだけで96個分のアドレス帯域を割り当てたことになります。/24ネットワークは/28ネットワーク16個分です。
仮に、組織から利用を許容されたのが/24ネットワーク一つだけだとすると、AWSの最小ネットワーク帯域を16個作れることになります。これを多いとみるとか少ないとみるか、また、/28ネットワークでアドレスが将来的にも足りるのかどうか…このあたりの見極めができるスキルが必要です。
単に数の問題ではあるので足りる足りない自体は簡単なのですが、これでよいという判断/決断が机上学習のみではなかなか難しいのではないかと感じています。

ネットワーク相談先を持っておこう

チームにネットワークの心得があるメンバーが参加している場合は何ら問題はありません。しかし、そのようなメンバーがいない場合には相談先を持っておきましょう。社内ネットワークを構築した部門などに相談しても良いと思います。（そもそもそこからアドレスが払い出されてくる場合もあるでしょう、その場合はそのまま相談しちゃいましょう）

最後に

今回は、AWS環境を構築する際に漏れがちなネットワークスキルについて書きました。AWSサービスやサーバ技術については、技術情報としてあるべき/やるべき情報が豊富にあるのに対し、ネットワークアドレス設計は感性的な部分が含まれているためどうすべきかの情報が少ないのではなないでしょうか。意外とこの部分で頭を悩ませてしまう、手が止まってしまう話も耳にします。クラウドを対応することになったら是非チームにネットワークスキルを持つメンバーを加える、相談先を持っておくことをお勧めします。

今回はAWS内部のネットワークについて書きましたが、AWSの専用ネットワークサービスであるAWS Direct Connectなどの話になると、かなりの専門性を求められます。このあたりになってくると、AWS Direct Connectサービスに知見のあるネットワークエンジニア、システムインテグレータへの相談が必要になると思いますのでご注意ください。