いわさです。
AWS Trusted Advisor はアップデートによって定期的にサポートされるサービスや機能が追加されています。
先日もアップデートによって耐障害性チェックに関していくつかのサービスがカバーされるようになりました。
上記アップデートのうち、NAT Gateway の別 AZ 依存のチェックは少し前に「あれ？検知されてるな、なんだこれ？」と思った記憶があったのですが、2023 年 5 月ごろから使えるようになった機能だったようです。
様々な理由から、NAT Gateway をシングル AZ で運用する場合があります。
この構成は NAT Gateway のプロビジョニングのコストを削減出来る反面、AZ で障害が発生した場合にせっかくマルチ AZ で構築したにも関わらず別 AZ のリソースに影響が出てしまう可能性があります。
次のように Health Dashboard でも「NAT ゲートウェイ冗長性に関する通知」という形で通知を受信する場合があります。
今回のアップデートで、Trusted Advisor でも同様に検出が出来るようになっています。
今回は実際にシングル AZ とマルチ AZ の NAT Gateway 構成を作成し、どういう時に検知されるのか実際に試してみたので紹介します。
NAT ゲートウェイ AZ インディペンデンス
次のように AWS Trusted Advisor の耐障害性カテゴリに「NAT ゲートウェイ AZ インディペンデンス」というチェックが追加されています。
なお、AWS Trusted Advisor は AWS Support の加入中のプランによって利用可能な機能の範囲が異なっています。
今回の耐障害性カテゴリは Trusted Advisor のフルセットのチェックが必要になるので、サポートプランのグレードはビジネスあるいはエンタープライズである必要があります。
今回はビジネスプランに加入してみました。
AWS サポートへ加入するのは何気に初めてなので今度記事にしてみたいと思います。
なお、クラスメソッドメンバーズに加入している場合はエンタープライズサポート相当の機能が利用出来ます。AWS Trusted Advisor もフルセットのチェックが利用可能になっています。
サポートプランがビジネス以上であるか確認出来たら、ネットワークリソースをデプロイしてチェック項目にどのように表示されるのかを検証してみたいと思います。
リソースをデプロイして観察してみる
次の 2 セットのリソース構成をデプロイしました。
前者は NAT Gateway もマルチ AZ で構築しており、後者は NAT Gateway をシングル AZ で配置して、アウトバウンド時に別の AZ を経由して通信する構成になっています。
マルチ AZ の NAT Gateway
シングル AZ の NAT Gateway
チェック頻度は長めで、強制更新は不可
今回の検証を通して何度か確認してわかったことがあるのですが、このチェックはリソースをデプロイしてから 24 時間くらい経過してようやくチェック結果が確認出来る状態でした。
暫くはマネジメントコンソールでも AWS CLI でもチェック結果がなかなか表示されませんでした。
},
{
"id": "c1dfptbg10",
"name": "NAT ゲートウェイ AZ インディペンデンス",
"description": "NAT ゲートウェイがアベイラビリティーゾーン (AZ) インディペンデンスに設定されているかどうかをチェックします。<br>\nNAT ゲートウェイを使用すると、プライベートサブネット内のリソースを、NAT ゲートウェイの<br>\nIP アドレスを使用してサブネット外のサービスに安全に接続することができ、未承諾のインバウンドトラフィックをすべてドロップします。各 NAT ゲートウェイは指定された<br>\nアベイラビリティーゾーン (AZ) 内で動作し、その AZ にのみ冗長性を持たせる形で構築されます。そのため、特定の AZ のリソースは同じ AZ 内の<br>\nNAT ゲートウェイを使用する必要があります。それにより、NAT ゲートウェイまたはその AZ が停止した場合、<br>\n別の AZ のリソースに影響が及ぶのを防ぎます。<br>\n<br>\n<b>アラート基準</b><br>\n赤色: ある AZ 内のサブネットからのトラフィックが、別の AZ 内の NATGW を経由してルーティングされています<br>\n緑色: ある AZ 内のサブネットからのトラフィックが、同じ AZ 内の NATGW を経由してルーティングされています<br>\n<br>\n<b>推奨されるアクション</b><br>\nサブネットの AZ を確認して、同じ AZ の NAT ゲートウェイを経由してトラフィックをルーティングしてください。<br>\nAZ に NATGW がない場合は、NATGW を作成してから、それを経由してサブネットトラフィックをルーティングします。<br>\n異なる AZ のサブネットに同じルートテーブルが関連付けられている場合は、このルートテーブルを NAT ゲートウェイと同じ AZ <br>\nにあるサブネットに関連付けたままにします。他の AZ のサブネットについては、この AZ の NAT ゲートウェイへのルートに<br>\n別個のルートテーブルを関連付けてください。<br>\nAmazon VPC のアーキテクチャを変更する場合は、メンテナンスウィンドウを選択することをお勧めします。<br>\n<br>\n<b></b><b>その他のリソース</b><br>\n<br>以下の AWS 公開ドキュメントを参照してください。<ul><li><a href=\"https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-working-with\" target=\"_blank\">NAT ゲートウェイの作成</a></li><li><a href=\"https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html\" target=\"_blank\">ハブの概念を使用し、NAT ゲートウェイのさまざまなユースケースに応じてルートを設定する方法</a></li><li><a href=\"https://aws.amazon.com/support\" target=\"_blank\">AWS サポートに問い合わせて追加のサポートを得る</a></li></ul>",
"category": "fault_tolerance",
"metadata": [
"ステータス",
"リージョン",
"NAT アベイラビリティーゾーン",
"NAT ID",
"サブネットアベイラビリティーゾーン",
"サブネット ID",
"ルートテーブル ID",
"NAT ARN",
"最終更新時刻"
]
},
{% aws support describe-trusted-advisor-check-result --check-id c1dfptbg10
{
"result": {
"checkId": "c1dfptbg10",
"timestamp": "2023-06-20T21:17:52Z",
"status": "ok",
"resourcesSummary": {
"resourcesProcessed": 0,
"resourcesFlagged": 0,
"resourcesIgnored": 0,
"resourcesSuppressed": 0
},
"categorySpecificSummary": {},
"flaggedResources": []
}
}また、このチェックは手動で強制更新が出来ないチェック項目になっていました。
% aws support refresh-trusted-advisor-check --check-id c1dfptbg10
An error occurred (InvalidParameterValueException) when calling the RefreshTrustedAdvisorCheck operation: [UNREFRESHABLE_CHECK_ID_ERROR] Check c1dfptbg10 is not refreshable.
% aws support describe-trusted-advisor-check-refresh-statuses --check-ids c1dfptbg10
{
"statuses": [
{
"checkId": "c1dfptbg10",
"status": "none",
"millisUntilNextRefreshable": 0
}
]
}使われていない Elastic IP なんかだと、上記手順で強制的にステータスチェックを実行することが出来たりしますが、NAT Gateway については無理なようです。気長に待つしかありませんね。
24 時間くらいすると確認出来るようになった
次の日の朝方確認してみると、次のようにチェック項目にリソースやステータスが表示されました。
何度かデプロイしつつ、数日間観察した感じからすると、24 時間くらいかかるかな？という印象です。もしかするともう少し（12 時間とか）短い場合もあるかもしれない。
予想どおりですが、列挙されるのは NAT Gateway リソースですね。
NAT Gateway がどの AZ でデプロイされているのか、とかそれに対して関連付けられているルートテーブルやサブネットはどれかというのがわかるようになっています。
なお、ここで表示されるサブネットはルートテーブルが使われているサブネットであって、NAT Gateway がデプロイされているサブネットではありません。
今回 3 つの NAT Gateway をデプロイしたのですが、期待に反して 3 つともグリーンでした。
これもしかして、1 つの NAT Gateway に複数の AZ サブネットが関連づいていると認識されない可能性があるかもしれないです。
検知されるパターン
ブログの都合上どうにか検知させたいところなので、次のように無理やり AZ 跨ぎの構成にしてみました。
この構成に変更して 24 時間ほど待ってみると次のように、警告ステータスで検出されるようになりました。
項目上、NAT Gateway の AZ とサブネットの AZ が違っている状態ですね。
期待どおりの結果ではあるのですが、NAT Gateway に複数 AZ のサブネットで使われるルートテーブルで検出されるかどうかはもう少し検証が必要そうです。
さいごに
本日は AWS Trusted Advisor の耐障害性チェックでトラフィックが別 AZ の NAT Gateway に依存しているかチェックしてくれるようになったので試してみました。
まず、反映まで時間がかかるタイプのチェックなので、即時性を求めた利用方法とならないように注意してください。
また、今回私の検証方法が悪かったのか、期待どおり検出されないケースがいくつかありました。今後も少し構成を変更しつつ経過を観察してみますので、アップデートがあれば追記したいと思います。
3
