説明
RDS の DB サブネットグループに含めるサブネットで、CidrBlock に 0.0.0.0/0、または Ipv6CidrBlock に ::/0 を指定すると、AWS で無効なサブネット構成になります。これらの値はアドレス空間全体を表すため、サブネットに割り当て可能な範囲を選ぶ必要があります。
サブネットのアドレス範囲とルートの宛先は、役割が異なります。インターネットゲートウェイへの直接のルートがあるサブネットは、パブリックサブネットです。10.0.0.0/24 のようなプライベートアドレス範囲を使っていても、パブリックサブネットになる場合があります。内部用データベースでは、サブネットグループ、ルーティング、PubliclyAccessible、セキュリティグループを組み合わせ、必要な接続だけを許可する必要があります。
想定される影響
- 無効なサブネット CIDR は、リソースの作成や更新の失敗につながるおそれがあります。
- アドレス範囲だけで内部用ネットワークと判断すると、意図しないインターネット接続経路を残すおそれがあります。公開アドレスとネットワークアクセスがともに許可されている場合、外部からデータベースへの接続を試みることができます。
対処方法
- VPC のアドレス範囲内で AWS がサポートするサブネット CIDR を選び、他のサブネットと重複しないようにしてください。メンテナンスやフェイルオーバーに必要な空きアドレスも確保してください。
- 内部用データベースには、インターネットゲートウェイへの直接のルートがないサブネットを使ってください。DB サブネットグループ内のすべてのサブネットとルートを確認し、
PubliclyAccessible: falseと、必要なクライアントだけを許可するセキュリティグループを構成してください。変更前にアプリケーションのプライベート接続経路を準備し、接続をテストしてください。 - デプロイ先のサブネットグループ要件を確認してください。通常のリージョン内のデプロイでは、異なる 2 つのアベイラビリティーゾーンのサブネットが必要ですが、Local Zone には別の例外があります。必須プロパティ、参照、既存のデータベースへの変更の影響を検証してください。
例
以下は、サブネット CIDR を比較する不完全なテンプレートです。変更前の mySubnet1 の定義と、両方の例の DBSubnetGroupDescription、VpcId、データベースの作成に必要なプロパティが省略されています。変更後にも、通常のリージョン内のデプロイに必要な 2 つのゾーンの構成はありません。論理 ID が異なるため、既存のスタックを更新する際は対象リソースを確認してください。
変更前
yaml
Resources:
Positive1:
Type: AWS::RDS::DBInstance
Properties:
DBSubnetGroupName:
Ref: myDBSubnetGroup
myDBSubnetGroup:
Type: "AWS::RDS::DBSubnetGroup"
Properties:
SubnetIds:
- Ref: mySubnet1
- Ref: mySubnet2
mySubnet2:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: 0.0.0.0/0
変更後
yaml
Resources:
Negative1:
Type: AWS::RDS::DBInstance
Properties:
DBSubnetGroupName:
Ref: myDBSubnetGroup0
myDBSubnetGroup0:
Type: "AWS::RDS::DBSubnetGroup"
Properties:
SubnetIds:
- Ref: mySubnet10
mySubnet10:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: 10.0.0.0/24
説明:
- 変更前:
0.0.0.0/0は有効な AWS サブネット CIDR ではありません。パブリックサブネットは、このアドレス範囲の指定ではなく、ルーティングによって構成します。 - 変更後:
10.0.0.0/24は、VPC の範囲内に収まり、他のサブネットと重複しなければ使用できるサイズの CIDR です。内部用のアクセスにするには、この例にないルート、公開アクセス設定、セキュリティグループも構成する必要があります。