293-AWS SAP AWS 「理論・実践・一問道場」AZサブネットのリサイズ

type

status

date

slug

summary

理論

1. Amazon VPC (Virtual Private Cloud) とサブネット管理

Amazon VPCは、AWSのクラウド内に仮想的なネットワーク環境を構築するためのサービスです。このVPCは、インターネットと接続されたり、プライベートな内部ネットワークを構成したりできます。VPC内で使用するIPアドレスの範囲をCIDR (Classless Inter-Domain Routing) ブロックを使って定義します。

CIDRブロック: CIDRはIPアドレスの範囲を指定する方法で、通常はVPC全体のIP範囲やサブネットのIP範囲を設定するために使用されます。例えば、10.0.0.0/23というCIDRブロックは、10.0.0.0から10.0.1.255までのIPアドレス範囲を意味します。

サブネット: VPC内に配置される小さなネットワークのことです。サブネットもCIDRブロックを使用して、使用するIPアドレスの範囲を定義します。VPC内のサブネットを複数作成することで、トラフィックの隔離や冗長性を確保できます。

2. Auto Scaling とネットワークの設定

Auto Scalingは、AWS上でのインスタンスの数を自動的に調整するためのサービスです。通常、EC2インスタンスを自動的に増減させることで、トラフィックの変動に対応し、コストを最適化します。

Auto Scaling グループ: Auto Scalingグループは、指定された数のEC2インスタンスを維持するために、自動的にインスタンスを起動したり停止したりするグループです。インスタンスは、ターゲットとしているサブネットに配置され、適切なアベイラビリティゾーン(AZ)内で冗長性を持つように設定されます。

アベイラビリティゾーン: AWSは、各リージョン内に複数のアベイラビリティゾーン(AZ)を提供しており、これにより、高可用性を確保するために、リソースを複数の物理的に分離されたデータセンターに分散配置することができます。

3. サブネットサイズとCIDRの制約

サブネットのCIDRの制限: VPC内のサブネットのCIDRブロックは、一度作成すると変更できません。そのため、CIDRブロックを変更したい場合は、新しいサブネットを作成し、インスタンスを新しいサブネットに移行する必要があります。

サブネットのサイズ変更方法: サブネットのサイズを変更するには、既存のサブネットを削除して新しいCIDRブロックでサブネットを再作成する必要があります。これを行う際には、インスタンスの移行やネットワーク設定の更新が必要です。

4. ネットワーク設計のベストプラクティス

冗長性と可用性の確保: ネットワーク設計において、複数のアベイラビリティゾーン(AZ)を利用することで、高可用性を確保できます。例えば、Auto Scalingグループを複数のAZにまたがるように設定することで、あるAZで障害が発生しても他のAZでインスタンスが稼働し続けるようにできます。

IPアドレスの最適化: VPCのCIDRブロックは適切なサイズを選択することが重要です。必要以上に大きなCIDRブロックを割り当てると、IPアドレスが無駄に使われてしまい、リソースの浪費を招く可能性があります。一方で、CIDRブロックが小さすぎると、将来的な拡張に対応できなくなることがあります。

5. サブネットの設計と管理

サブネットを分割する: 必要に応じて、VPC内のIPアドレス範囲を小さなサブネットに分割することで、リソースを適切に管理できます。例えば、パブリックサブネットとプライベートサブネットに分け、インターネットアクセスが必要なリソースと内部専用のリソースを分けて管理できます。

セキュリティとアクセス制御: サブネットごとに異なるセキュリティグループやネットワークACLを適用することで、リソース間のアクセス制御を強化できます。特定のサブネットからインターネットへのアクセスを制限したり、特定のインスタンスのみがアクセスできるようにすることが可能です。

結論

AWS VPC、Auto Scaling、CIDRブロック、およびサブネットの管理は、AWS環境でスケーラブルで高可用性のアーキテクチャを設計するための基本的な要素です。サブネットのCIDR変更やネットワーク設計の最適化を理解しておくことは、安定した運用を実現するために非常に重要です。

実例

以下は、元々のVPC構成と提案された変更後のVPC構成を比較した表です。

サブネット名	元のCIDR	提案された変更後のCIDR	範囲
VPC CIDR	10.0.0.0/23	10.0.0.0/23	10.0.0.0 〜 10.0.1.255
AZ1サブネット	10.0.0.0/24	10.0.0.0/25	10.0.0.0 〜 10.0.0.127
AZ2サブネット	10.0.1.0/24	10.0.0.128/25	10.0.0.128 〜 10.0.0.255
AZ3サブネット	なし	10.0.1.0/25	10.0.1.0 〜 10.0.1.127

比較ポイント:

VPC CIDR は変更なし（10.0.0.0/23の範囲のまま）。

AZ1 サブネット と AZ2 サブネット の範囲をそれぞれ 10.0.0.0/24 から 10.0.0.0/25 と 10.0.1.0/24 から 10.0.0.128/25 に変更し、各サブネットに対して利用可能なIPアドレス範囲を半分に縮小します。

AZ3 サブネット は新規で作成され、CIDR は 10.0.1.0/25 に設定され、既存のアドレス空間から IP 範囲を割り当てています。

これにより、VPC内のサブネットの配置を3つのAZに広げ、可用性を確保しつつ、アドレス空間を有効に活用します。

実践

略

一問道場

問題 #293

ソリューションアーキテクトは、Amazon EC2 インスタンスが Auto Scaling グループ内で運用されているワークロードを管理しています。VPC アーキテクチャは 2 つのアベイラビリティゾーン（AZ）にまたがっており、それぞれの AZ にサブネットがあり、Auto Scaling グループはこれらのサブネットをターゲットにしています。VPC はオンプレミス環境と接続されており、接続の中断はありません。Auto Scaling グループの最大インスタンス数は 20 です。VPC の IPv4 アドレスは次の通りです：

VPC CIDR: 10.0.0.0/23

AZ1 サブネット CIDR: 10.0.0.0/24

AZ2 サブネット CIDR: 10.0.1.0/24

展開後、リージョンに 3 番目の AZ が利用可能になりました。ソリューションアーキテクトは、追加の IPv4 アドレス空間を使わず、サービスのダウンタイムなしで新しい AZ を採用したいと考えています。この要件に最も適した解決策はどれですか？

A. Auto Scaling グループを AZ2 サブネットのみを使用するように更新します。AZ1 サブネットを削除して再作成し、元のアドレス空間の半分を使用します。Auto Scaling グループが新しい AZ1 サブネットを使用するように調整します。インスタンスが正常であれば、Auto Scaling グループを AZ1 サブネットのみを使用するように調整します。現在の AZ2 サブネットを削除し、元の AZ1 サブネットのアドレス空間の後半を使用して新しい AZ2 サブネットを作成します。元の AZ2 サブネットのアドレス空間の半分を使って新しい AZ3 サブネットを作成し、Auto Scaling グループをすべての新しいサブネットをターゲットにするように更新します。

B. AZ1 サブネット内の EC2 インスタンスを終了します。AZ1 サブネットを削除して再作成し、アドレス空間の半分を使用します。Auto Scaling グループを新しいサブネットに更新します。この操作を 2 番目の AZ に対しても繰り返します。AZ3 に新しいサブネットを作成し、Auto Scaling グループを 3 つの新しいサブネットをターゲットにするように更新します。

C. 同じ IPv4 アドレス空間を持つ新しい VPC を作成し、各 AZ に 1 つずつサブネットを定義します。既存の Auto Scaling グループを更新して、新しい VPC のサブネットをターゲットにします。

D. Auto Scaling グループを AZ2 サブネットのみを使用するように更新します。AZ1 サブネットを更新し、アドレス空間の半分を使います。Auto Scaling グループを AZ1 サブネットを使うように調整します。インスタンスが正常であれば、Auto Scaling グループを AZ1 サブネットのみを使用するように調整します。現在の AZ2 サブネットを更新し、元の AZ1 サブネットのアドレス空間の後半を割り当てます。元の AZ2 サブネットのアドレス空間の半分を使って新しい AZ3 サブネットを作成し、Auto Scaling グループをすべての新しいサブネットをターゲットにするように更新します。

解説

この問題では、既存の VPC に新しいアベイラビリティゾーン（AZ）が追加され、その AZ を追加するために必要な変更を検討しています。要求事項としては、追加のIPv4アドレス空間を使用せず、サービスのダウンタイムなしで新しい AZ を採用することです。

以下に各選択肢の解説を行います。

A の解説

選択肢 A は、既存のサブネットを変更して新しい AZ を利用する方法です。この選択肢では、以下のように進めます：

AZ2 サブネットのみを使用するように Auto Scaling グループを更新し、次に AZ1 サブネットを更新します。これにより、サービスがダウンしないように段階的に進めることができます。

元の AZ1 サブネットを削除して半分のアドレス空間を使い、新しい AZ1 サブネットを作成します。

AZ2 サブネットの後半のアドレス空間を使って新しい AZ2 サブネットを作成します。

最後に、新しい AZ3 サブネットを作成して、Auto Scaling グループがすべての新しいサブネットをターゲットにするように更新します。

これにより、新しい AZ を追加するために 既存のサブネットの変更や新しいサブネットの作成を行うことができます。重要なのは、この方法では既存のアドレス空間内で新しい AZ を追加し、サービスのダウンタイムなしで変更を進める点です。

B の解説

選択肢 B は、まず既存のインスタンスを終了して、新しいサブネットを作成し、Auto Scaling グループを更新する方法です。これにより、サービスが停止し、インスタンスの再起動が必要になります。また、手順としても非常に煩雑で、ダウンタイムが発生する可能性が高いです。従って、ダウンタイムなしという要件には適していません。

C の解説

選択肢 C は、新しい VPC を作成して、既存の Auto Scaling グループを新しい VPC に移行する方法です。この方法では、完全に新しい VPC を作成するため、既存のリソースやサブネットの設定を再構成し直さなければなりません。さらに、既存の EC2 インスタンスやネットワーク設定の移行には時間と手間がかかり、ダウンタイムが避けられないため、最も運用負荷が高い方法です。

D の解説

選択肢 D は、選択肢 A と似ていますが、Auto Scaling グループを調整する際にインスタンスを停止しないような手順となっています。ステップとしては、AZ1 サブネットとAZ2 サブネットを順番に更新し、その後 AZ3 サブネットを作成します。ただし、この方法でも、アドレス空間の管理やサブネットの変更に時間がかかり、他の選択肢と比べて最も手順が多いため、他の方法より複雑です。

結論

最も適切な解決策は A です。選択肢 A は、新しい AZ を追加するための最も効率的な方法で、既存の VPC 内で作業を行い、サービスのダウンタイムなしで新しい AZ を導入できるからです。