耐障害性

Application Load Balancer が複数のアベイラビリティーゾーン (AZ) を使用するように設定されているかどうかを確認します。AZ は、他のゾーンの障害から隔離された独立した場所です。ワークロードの可用性を向上させるために、同じリージョン内の複数の AZs でロードバランサーを設定します。

c1dfprch08

黄: ALBは単一の AZ にあります。

緑: ALB には 2 つ以上の AZs があります。

ロードバランサーが、少なくとも 2 つのアベイラビリティーゾーンで設定されているようにします。

詳細については、「Application Load Balancer のアベイラビリティーゾーン」を参照してください。

詳細については、次のドキュメントを参照してください。

Amazon Aurora MySQL クラスターでバックトラックが有効になっているかどうかを確認します。

Amazon Aurora MySQL クラスターバックトラックは、新しいクラスターを作成せずに Aurora DB クラスターを以前の時点に復元できる機能です。これにより、スナップショットから復元する必要なく、保持期間内の特定の時点までデータベースをロールバックできます。

AWS Config ルールの BacktrackWindowInHours パラメータでバックトラック時間枠 (時間) を調整できます。

詳細については、「Aurora DB クラスターのバックトラック」を参照してください。

c18d2gz131

AWS Config Managed Rule: aurora-mysql-backtracking-enabled

黄: Amazon Aurora MySQL クラスターのバックトラックが有効になっていません。

Amazon Aurora MySQL クラスターのバックトラックを有効にします。

詳細については、「Aurora DB クラスターのバックトラック」を参照してください。

Aurora DB クラスターのバックトラック

Amazon Aurora DB クラスターにプライベートインスタンスとパブリックインスタンスの両方があるケースをチェックします。

プライマリインスタンスが失敗した場合、 レプリカはプライマリ DB インスタンスに昇格できます。レプリカがプライベートである場合、パブリックアクセスのみを持つユーザーは、フェールオーバー後にデータベースに接続できなくなります。クラスター内のすべての DB インスタンスのアクセシビリティを同じにすることをお勧めします。

xuy7H1avtl

黄: Aurora DB クラスターのインスタンスは、アクセシビリティが異なります (パブリックとプライベートの混在)。

DB クラスター内のインスタンスの Publicly Accessible 設定を変更して、すべてがパブリックまたはプライベートになるようにします。詳細については、「MySQL データベースエンジンを実行する DB インスタンスの変更」の「MySQL インスタンスの手順」を参照してください。

Aurora DB クラスターの耐障害性

Amazon CloudFront に 2 つのオリジンを含むディストリビューションに対してオリジングループが設定されていることを確認します。

詳細については、 CloudFront オリジンフェイルオーバーによる高可用性の最適化」を参照してください。

c18d2gz112

AWS Config Managed Rule: cloudfront-origin-failover-enabled

黄: Amazon CloudFront オリジンフェイルオーバーが有効になっていません。

コンテンツ配信の可用性をエンドユーザーに確実に高めるには、 CloudFront ディストリビューションのオリジンフェイルオーバー機能を必ず有効にしてください。この機能を有効にすると、プライマリオリジンサーバーが使用できなくなった場合、トラフィックはバックアップオリジンサーバーに自動的にルーティングされます。これにより、潜在的なダウンタイムが最小限に抑えられ、コンテンツの継続的な可用性が確保されます。

カスタマーマネージドキーを使用して基盤となるモデルが暗号化されたエンドポイントの AWS Key Management Service （AWS KMS) キーのアクセス許可をチェックします。カスタマーマネージドキーが無効になっている場合、または、Amazon Comprehend の付与された許可を変更するようにキーポリシーが変更された場合、エンドポイントの可用性が影響を受ける可能性があります。

Cm24dfsM13

赤: カスタマーマネージドキーが無効になっているか、キーポリシーが変更されて、Amazon Comprehend アクセス用に付与されている許可が変更されました。

カスタマーマネージドキーが無効になっている場合は、有効にすることをお勧めします。詳細については、「キーの有効化」を参照してください。キーポリシーが変更され、エンドポイントを引き続き使用する場合は、 AWS KMS キーポリシーを更新することをお勧めします。詳細については、キーポリシーの変更を参照してください。

AWS KMS アクセス許可

シングル AZ として設定されている Amazon DocumentDB クラスターがあるかどうかを確認します。

きわめて重要なワークロードでは、Amazon DocumentDB ワークロードをシングル AZ アーキテクチャで実行するだけでは不十分であり、コンポーネントの障害から回復するまでに最大 10 分かかることがあります。お客様は、メンテナンス、インスタンス障害、コンポーネント障害、アベイラビリティーゾーン障害が発生した場合の可用性を確保するため、追加のアベイラビリティーゾーンにレプリカインスタンスをデプロイする必要があります。

c15vnddn2x

黄色: Amazon DocumentDB クラスターのインスタンスが 3 つ以下のアベイラビリティーゾーンにあります。

緑: Amazon DocumentDB クラスターのインスタンスが 3 つのアベイラビリティーゾーンにあります。

アプリケーションに高可用性が必要な場合は、レプリカインスタンスを使用して DB インスタンスを変更し、マルチ AZ を有効にします。「Amazon DocumentDB High Availability and Replication」を参照してください。

Understanding Amazon DocumentDB Cluster Fault Tolerance

リージョンとアベイラビリティーゾーン

ポイントインタイムリカバリが Amazon DynamoDB テーブルに対して有効になっているかどうかを確認します。

ポイントインタイムリカバリを使用することで、偶発的な書き込みや削除のオペレーションからDynamoDB テーブルを保護できます。ポイントインタイムリカバリを有効化すれば、オンデマンドバックアップの作成、維持、スケジュールを心配する必要はありません。ポイントインタイムリカバリによって、過去 35 日間の任意の時点にテーブルを復元することができます。DynamoDB では、テーブルの増分バックアップが維持されます。

詳細については、DynamoDB のPoint-in-time リカバリ」を参照してください。

c18d2gz138

AWS Config Managed Rule: dynamodb-pitr-enabled

黄: DynamoDB テーブルでは Point-in-timeリカバリが有効になっていません。

Amazon DynamoDB で point-in-time リカバリを有効にして、テーブルデータを継続的にバックアップします。

詳細については、Point-in-time recovery: How it works」を参照してください。

DynamoDB のPoint-in-time リカバリ

Amazon DynamoDB テーブルが AWS Backup プランの一部であるかどうかを確認します。

AWS Backup は、前回のバックアップ以降に行われた変更をキャプチャする DynamoDB テーブルの増分バックアップを提供します。 AWS Backup プランに DynamoDB テーブルを含めると、偶発的なデータ損失シナリオからデータを保護し、バックアッププロセスを自動化できます。これにより、DynamoDB テーブルの信頼性が高くスケーラブルなバックアップソリューションが提供され、貴重なデータを保護し、必要に応じて復旧できるようになります。

詳細については、「 を使用した DynamoDB テーブルのバックアップの作成 AWS Backup」を参照してください。

c18d2gz107

AWS Config Managed Rule: dynamodb-in-backup-plan

黄: Amazon DynamoDB テーブルは AWS Backup プランに含まれていません。

Amazon DynamoDB テーブルが AWS Backup プランの一部であることを確認します。

スケジュールバックアップ

とは AWS Backup

AWS Backup コンソールを使用したバックアッププランの作成

Amazon EBS ボリュームがバックアッププランに存在するかどうかを確認します AWS Backup。

Amazon EBS ボリュームを AWS Backup プランに含めて、それらのボリュームに保存されているデータの定期的なバックアップを自動化します。これにより、データ損失を防ぎ、データ管理が容易になり、必要に応じてデータを復元できるようになります。バックアッププランは、データの安全性を確保し、アプリケーションとサービスの復旧時間とポイント目標 (RTO/RPO) を達成できるようにするのに役立ちます。

詳細については、「バックアッププランの作成」を参照してください

c18d2gz106

AWS Config Managed Rule: ebs-in-backup-plan

黄: Amazon EBS ボリュームは AWS Backup プランに含まれていません。

Amazon EBS ボリュームが AWS Backup プランの一部であることを確認します。

AWS Backup コンソールを使用したバックアッププランの作成

とは AWS Backup

開始方法 3: スケジュールされたバックアップの作成

Amazon EBS ボリューム (使用可能または使用中) のスナップショットの経過時間を確認します。Amazon EBS ボリュームがレプリケートされた場合でも、障害が発生する可能性があります。スナップショットは永続的なストレージと toAmazon point-in-timeリカバリS3のために永続化されています。

H7IgTzjTYb

ボリュームの週次または月次のスナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。

EBS スナップショットの作成を自動化するには、 AWS Backupまたは Amazon Data Lifecycle Manager の使用を検討してください。

Amazon Elastic Block Store (Amazon EBS）

Amazon EBS スナップショット

AWS Backup

Amazon Data Lifecycle Manager

Classic Load Balancer に関連付けられている Amazon EC2 Auto Scaling グループが Elastic Load Balancing ヘルスチェックを使用しているかどうかを確認します。Auto Scaling グループのデフォルトのヘルスチェックは、Amazon EC2 ステータスチェックのみです。インスタンスがこれらのステータスチェックに合格しない場合、異常とマークされて終了します。Amazon EC2 Auto Scaling は、新しい代替インスタンスを起動します。Elastic Load Balancing ヘルスチェックでは、Amazon EC2 インスタンスを定期的にモニタリングして、異常なインスタンスを検出して終了し、新しいインスタンスを起動します。

詳細については、Elastic Load Balancing ヘルスチェックを追加する」を参照してください。

c18d2gz104

AWS Config Managed Rule: autoscaling-group-elb-healthcheck-required

黄: Classic Load Balancer にアタッチされた Amazon EC2 Auto Scaling グループが Elastic Load Balancing ヘルスチェックを有効にしていません。

Classic Load Balancer に関連付けられた Auto Scaling グループで、Elastic Load Balancing のヘルスチェックが使用されているかどうかを確認します。

Elastic Load Balancing ヘルスチェックは、ロードバランサーが正常でリクエストを処理できるかどうかをレポートします。これにより、アプリケーションの高可用性が保証されます。

詳細については、「Auto Scaling グループに Elastic Load Balancing ヘルスチェックを追加する」を参照してください

複数のインスタンスタイプを使用する Amazon EC2 Auto Scaling グループで容量の再調整が有効になっているかどうかを確認します。

容量の再調整を使用して Amazon EC2 Auto Scaling グループを設定すると、インスタンスタイプや購入オプションに関係なく、Amazon EC2 インスタンスがアベイラビリティーゾーン間で均等に分散されます。CPU 使用率やネットワークトラフィックなど、グループに関連付けられたターゲット追跡ポリシーを使用します。

詳細については、「複数のインスタンスタイプと購入オプションをもつ Auto Scaling グループ」を参照してください。

AWS Config c18d2gz103

AWS Config マネージドルール： autoscaling-capacity-rebalancing

黄: Amazon EC2 Auto Scaling グループの容量の再調整が有効になっていません。

複数のインスタンスタイプを使用する Amazon EC2 Auto Scaling グループで容量の再調整が有効になっていることを確認します。

詳細については、「キャパシティーの再調整の有効化 (コンソール)」を参照してください。

Amazon EC2 Auto Scaling グループが複数のアベイラビリティーゾーンにデプロイされているかどうか、または指定されたアベイラビリティーゾーンの最小数を確認します。Amazon EC2 インスタンスを複数のアベイラビリティーゾーンにデプロイして、高可用性を確保します。

AWS Config ルールの minAvailibilityZones パラメータを使用して、アベイラビリティーゾーンの最小数を調整できます。

詳細については、「複数のインスタンスタイプと購入オプションをもつ Auto Scaling グループ」を参照してください。

c18d2gz101

AWS Config Managed Rule: autoscaling-multiple-az

赤: Amazon EC2 Auto Scaling グループに複数のAZsが設定されていないか、指定された最小数のAZsを満たしていません。

Amazon EC2 Auto Scaling グループが複数の AZs で構成されていることを確認します。Amazon EC2 インスタンスを複数のアベイラビリティーゾーンにデプロイして、高可用性を確保します。

起動テンプレートを使用して Auto Scaling グループを作成する

起動設定を使用して Auto Scaling グループを作成する

リージョン内のアベイラビリティーゾーン間での Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのディストリビューションをチェックします。

アベイラビリティーゾーンは、他のアベイラビリティーゾーンの障害から分離された別の場所です。そのため、同じリージョン内の複数のアベイラビリティーゾーン間の安価な低レイテンシーネットワーク接続が発生することがあります。同一のリージョン内の複数のアベイラビリティーゾーンでインスタンスを起動することにより、単一障害点からアプリケーションを保護することができます。

wuy7G1zxql

Amazon EC2 インスタンスを複数のアベイラビリティーゾーン間で均等に分散させます。これを実行するには、インスタンスを手動で起動するか、Auto Scaling を使用して自動的に実行します。詳細については、「インスタンスの起動」および「Load Balance Your Auto Scaling Group」(Auto Scaling グループの負荷分散) を参照してください。

yourAmazon EC2 Wordインスタンスの詳細モニタリングが有効になっているかどうかを確認します。

Amazon EC2 の詳細モニタリングは、Amazon EC2 の基本モニタリングで使用される 5 分間隔ではなく、1 分間隔で発行される、より頻繁なメトリクスを提供します。Amazon EC2 の詳細なモニタリングを有効にすると、Amazon EC2 リソースをより適切に管理できるため、傾向を見つけて迅速にアクションを実行できます。

詳細については、「基本モニタリングと詳細モニタリング」を参照してください。

AWS Config c18d2gz144

AWS Config マネージドルール: ec2-instance-detailed-monitoring-enabled

黄: Amazon EC2 インスタンスの詳細モニタリングが有効になっていません。

Amazon EC2 インスタンスの詳細モニタリングをオンにして、Amazon Word メトリクスデータが AmazonEC2 に発行される頻度を上げます CloudWatch (5 分間隔から 1 分間隔）。

Logs ログドライバーがブロッキングモードで設定されている Amazon ECS AWSタスク定義をチェックします。ブロッキングモードでドライバーが設定されると、システムの可用性が危険にさらされます。

c1dvkm4z6b

黄色: awslogs ドライバーのログ記録設定のモードパラメータが「ブロッキング」または「ありません」に設定されています。モードパラメータがないということは、デフォルトのブロッキング設定になっているということです。

緑: Amazon ECS タスク定義で awslogs ドライバーが使用されていないか、awslogs ドライバーがノンブロッキングモードで設定されています。

可用性リスクを軽減するには、タスク定義 AWSの Logs ドライバーの設定をブロックから非ブロックに変更することを検討してください。ノンブロッキングモードでは、 max-buffer-size パラメータの値を設定する必要があります。設定パラメータの詳細およびガイダンスについては、「」を参照してください。Logs コンテナログドライバーの「ノンブロッキングモードでのログ損失の防止 AWS」を参照してください。

AWS logs ログドライバーを使用する

バックプレッシャーを回避するためのコンテナのログ記録オプションを選択する

AWS Logs コンテナログドライバーのノンブロッキングモードでのログ損失の防止

サービス設定で単一のアベイラビリティーゾーン (AZ) を使用していることをチェックします。

AZ は、他のゾーンの障害から隔離された独立した場所です。これにより、同じ の AZs 間の低コストで低レイテンシーのネットワーク接続がサポートされます AWS リージョン。同じリージョンの複数の AZs でインスタンスを起動することで、単一の障害点からアプリケーションを保護するのに役立ちます。

c1z7dfpz01

異なるアベイラビリティーゾーンでサービスに対して 1 つ以上のタスクを追加で作成します。

Amazon ECS の容量と可用性

Amazon ECS サービスがアベイラビリティーゾーン (AZ) に基づくスプレッドプレイスメント戦略を使用していることを確認します。この戦略は、同じ 内のアベイラビリティーゾーンにタスクを分散 AWS リージョン し、単一障害点からアプリケーションを保護するのに役立ちます。

Amazon ECS サービスの一部として実行されるタスクの場合、スプレッドはデフォルトのタスク配置戦略です。

このチェックでは、有効な配置戦略リストの最初の戦略または唯一の戦略がスプレッドであることも確認します。

c1z7dfpz02

分散タスク配置戦略を有効にして、複数の AZs にタスクを分散します。アベイラビリティゾーンによるスプレッドが、有効なすべてのタスク配置戦略における第一の戦略であるか、唯一の使用されている戦略であることを確認します。AZ 配置を管理する場合は、別の AZ でミラーリングサービスを使用すると、これらのリスクを軽減できます。

Amazon ECS タスク配置戦略

Amazon EFS ファイルシステムの複数のアベイラビリティーゾーンにマウントターゲットが存在するかどうかを確認します。

アベイラビリティーゾーンは、他のゾーンの障害から隔離された独立した場所です。AWS リージョン内の複数の地理的に分離されたアベイラビリティーゾーンにマウントターゲットを作成することで、Amazon EFS ファイルシステムの最高レベルの可用性と耐久性を実現できます。

c1dfprch01

1 ゾーンストレージクラスを使用する EFS ファイルシステムの場合は、新しいファイルシステムにバックアップを復元して、標準ストレージクラスを使用する新しいファイルシステムを作成することをお勧めします。次に、複数のアベイラビリティーゾーンにマウントターゲットを作成します。

標準ストレージクラスを使用する EFS ファイルシステムの場合は、複数のアベイラビリティーゾーンにマウントターゲットを作成することをお勧めします。

Amazon EFS ファイルシステムがバックアッププランに含まれているかどうかを確認します AWS Backup。

AWS Backup は、バックアップの作成、移行、復元、削除を簡素化すると同時に、レポートと監査を改善するように設計された統合バックアップサービスです。

詳細については、「Amazon EFS ファイルシステムのバックアップ」を参照してください。

c18d2gz117

AWS Config Managed Rule: EFS_IN_BACKUP_PLAN

赤: Amazon EFS は AWS Backup プランに含まれていません。

偶発的なデータ損失やデータ破損を防ぐために、Amazon EFS ファイルシステムが AWS Backup 計画に含まれていることを確認してください。

Amazon EFS ファイルシステムのバックアップ

を使用した Amazon EFS のバックアップと復元 AWS Backup。

単一のアベイラビリティーゾーン (AZ) にデプロイする for ElastiCache クラスターをチェックします。このチェックでは、クラスター内でマルチ AZ が非アクティブである場合に警告が表示されます。

異なる AZ の読み取り専用レプリカに非同期的にレプリケートすることで、複数の AZs Enhance ElastiCache クラスターの可用性を高めることができます。クラスターの計画的なメンテナンスが発生した場合、またはプライマリノードが使用できない場合、 ElastiCache は自動的にレプリカをプライマリに昇格させます。このフェイルオーバーにより、クラスターの書き込み操作を再開でき、管理者が介入する必要はありません。

ECHdfsQ402

プライマリとは異なる AZ に、シャードごとに少なくとも 1 つのレプリカを作成します。

詳細については、「マルチ AZ による in ElastiCache (Redis OSS) のダウンタイムの最小化」を参照してください。

Amazon ElastiCache (Redis OSS) クラスターで自動バックアップが有効になっているかどうか、およびスナップショットの保持期間が指定された制限または 15 日間のデフォルト制限を超えているかどうかを確認します。自動バックアップが有効になっている場合、 ElastiCache はクラスターのバックアップを毎日作成します。

AWS Config ルールの snapshotRetentionPeriod パラメータを使用して、必要なスナップショット保持制限を指定できます。

詳細については、「 for ElastiCache (Redis OSS) のバックアップと復元」を参照してください。

c18d2gz178

AWS Config Managed Rule: elasticache-redis-cluster-automatic-backup-check

赤: Amazon ElastiCache (Redis OSS) クラスターで自動バックアップが有効になっていないか、スナップショットの保持期間が制限を下回っています。

Amazon ElastiCache (Redis OSS) クラスターで自動バックアップが有効になっていることを確認し、スナップショットの保持期間が指定された制限または 15 日間のデフォルト制限を超えていることを確認してください。自動バックアップは、データ損失を防ぐのに役立ちます。障害が起こった場合、最新のバックアップからデータを復元して新しいクラスターを作成できます。

詳細については、「 for ElastiCache (Redis OSS) のバックアップと復元」を参照してください。

詳細については、「自動バックアップのスケジュール」を参照してください。

単一のアベイラビリティーゾーン (AZ) にデプロイされた MemoryDB クラスターをチェックします。このチェックでは、クラスター内でマルチ AZ が非アクティブである場合に警告が表示されます。

複数の AZs にデプロイすると、別の AZ の読み取り専用レプリカに非同期的にレプリケートすることで、MemoryDB クラスターの可用性が向上します。クラスターの計画的なメンテナンスが行われるか、プライマリノードが使用できない場合、MemoryDB はレプリカを自動的にプライマリノードに昇格します。このフェイルオーバーにより、クラスターの書き込み操作を再開でき、管理者が介入する必要はありません。

MDBdfsQ401

プライマリとは異なる AZ に、シャードごとに少なくとも 1 つのレプリカを作成します。

詳細については、「Minimizing downtime in MemoryDB with Multi-AZ」(マルチ AZ を使用した MemoryDB でのダウンタイムの最小化) を参照してください。

Managed Streaming for Kafka (MSK) クラスターのブローカーに、推奨される数のパーティションが割り当てられていないことを確認します。

Cmsvnj8vf1

MSK の推奨ベストプラクティスに従って、MSK クラスターをスケールするか、未使用のパーティションを削除します。

Amazon AZs でプロビジョニングされたクラスターのアベイラビリティーゾーン (MSK) の数を確認します。Amazon MSK クラスターは、連携してデータとロードを分散する複数のブローカーで構成されています。2-AZ クラスターのメンテナンスまたはブローカーの問題中に、本番稼働が中断される場合があります。

90046ff5b5

クラスターの可用性を高めるには、3 AZs セットアップで別のクラスターを作成します。次に、既存のクラスターを、作成した新しいクラスターに移行します。この移行には Amazon MSK レプリケーションを使用できます。

Amazon MSK の高可用性

Amazon MSK の移行

Amazon OpenSearch Service ドメインが少なくとも 3 つのデータノードで構成され、 ZoneAwarenessEnabled が true かどうかを確認します。 ZoneAwarenessEnabled を有効にすると、Amazon OpenSearch Service は、各プライマリシャードとそれに対応するレプリカが異なるアベイラビリティーゾーンに割り当てられるようにします。

詳細については、「Amazon OpenSearch Service でのマルチ AZ ドメインの設定」を参照してください。

c18d2gz183

AWS Config Managed Rule: opensearch-data-node-fault-tolerance

黄: Amazon OpenSearch Service ドメインは 3 つ未満のデータノードで設定されています。

Amazon OpenSearch Service ドメインが少なくとも 3 つのデータノードで構成されていることを確認します。ノードを割り当て、同じリージョン内の 3 つのアベイラビリティーゾーンにデータをレプリケートすることで、Amazon OpenSearch Service クラスターの可用性を高めるようにマルチ AZ ドメインを設定します。これにより、データ損失が防止され、ノードまたはデータセンター (AZ) に障害が発生した場合のダウンタイムが最小限に抑えられます。

詳細については、「3 つのアベイラビリティーゾーンにデプロイして Amazon OpenSearch Service の可用性を高める」を参照してください。

Amazon RDS DB インスタンスの自動バックアップをチェックします。

デフォルトでは、バックアップは 1 日の保持期間で有効になっています。バックアップにより、予期しないデータ損失のリスクが軽減され、 for point-in-time の復旧が可能になります。

opQPADkZvH

赤: DB インスタンスのバックアップ保持期間は 0 日に設定されています。

アプリケーションの要件に応じて、自動 DB インスタンスのバックアップの保持期間を 1～35 日に設定します。「Working With Automated Backups」(自動バックアップの使用) を参照してください。

Amazon RDS の開始方法

DB クラスターに少なくとももうひとつの DB インスタンスを追加し、可用性とパフォーマンスを向上させます。

c1qf5bt011

黄色: DB クラスターには DB インスタンスが 1 つしかありません。

リーダー DB インスタンスを DB クラスターに追加します。

現在の設定では、読み取りオペレーションと書き込みオペレーションの両方で、1 つの DB インスタンスが使用されています。別の DB インスタンスを追加して、読み取りの再配分とフェイルオーバーオプションを有効にすることができます。

アベイラビリティーゾーンの詳細については、「Amazon Aurora の高可用性」を参照してください。

DB クラスターは現在、1 つのアベイラビリティーゾーンにあります。複数のアベイラビリティーゾーンを使用してアベイラビリティーを向上させます。

c1qf5bt007

黄色: DB クラスターでは、すべてのインスタンスが同じアベイラビリティーゾーンにあります。

DB クラスター内の複数のアベイラビリティーゾーンに DB インスタンスを追加します。

DB インスタンスは、DB クラスター内の複数のアベイラビリティーゾーンに追加することをお勧めします。DB インスタンスを複数のアベイラビリティーゾーンに追加すると、DB クラスターの可用性が向上します。

アベイラビリティーゾーンの詳細については、「Amazon Aurora の高可用性」を参照してください。

DB クラスターでは、すべてのリーダーインスタンスが同じアベイラビリティーゾーンにあります。リーダーインスタンスを DB クラスタ内の複数のアベイラビリティーゾーンに分散することをお勧めします。

分散によってデータベースの可用性が向上し、クライアントとデータベース間のネットワーク遅延が減少して応答時間が改善されます。

c1qf5bt018

赤: DB クラスターでは、リーダーインスタンスが同じアベイラビリティーゾーンにあります。

リーダーインスタンスを複数のアベイラビリティーゾーンに分散します。

アベイラビリティーゾーン (AZs) は、各 AWS リージョン内で障害が発生した場合に分離できるように、互いに異なる場所です。DB クラスターのプライマリインスタンスとリーダーインスタンスを複数の AZs に分散して、DB クラスターの可用性を向上させることをお勧めします。マルチ AZ クラスターは AWS Management Console、、 AWS CLI、またはクラスターの作成時に Amazon RDS API作成できます。また、既存の Aurora クラスターをマルチ AZ クラスターに変更するには、新しいリーダーインスタンスを追加し、別の AZ を指定します。

アベイラビリティーゾーンの詳細については、「Amazon Aurora の高可用性」を参照してください。

Amazon RDS DB インスタンスで拡張モニタリングが有効になっているかどうかを確認します。

Amazon RDS Enhanced Monitoring は、DB インスタンスが実行されるオペレーティングシステム (OS) のメトリクスをリアルタイムで提供します。Amazon RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報は、Amazon RDS コンソールで表示できます。また、ダッシュボードはカスタマイズできます。拡張モニタリングを使用すると、Amazon RDS インスタンスのオペレーションステータスをほぼリアルタイムで可視化できるため、運用上の問題に迅速に対応できます。

AWS Config ルールの monitoringInterval パラメータを使用して、必要なモニタリング間隔を指定できます。

詳細については、「Enhanced Monitoring の概要」と「拡張モニタリングの OS メトリクス」を参照してください。

c18d2gz158

AWS Config Managed Rule: rds-enhanced-monitoring-enabled

黄: Amazon RDS DB インスタンスで拡張モニタリングが有効になっていないか、必要な間隔で設定されていません。

Amazon RDS DB インスタンスの拡張モニタリングを有効にして、Amazon RDS インスタンスのオペレーションステータスの可視性を向上させます。

詳細については、「拡張モニタリングを使用した OS メトリクスのモニタリング」を参照してください。

拡張モニタリングの OS メトリクス

DB インスタンスで Amazon RDS ストレージの自動スケーリングが有効になっていません。データベースワークロードが増加すると、RDS Storage の自動スケーリングはダウンタイムなしでストレージ容量を自動的にスケーリングします。

c1qf5bt013

赤: DB インスタンスのストレージの自動スケーリングが有効になっていません。

指定された最大ストレージしきい値で Amazon RDS ストレージの自動スケーリングを有効にします。

Amazon RDS ストレージの自動スケーリングは、データベースワークロードが増加すると、ダウンタイムなしでストレージ容量を自動的にスケーリングします。ストレージ自動スケーリングはストレージの使用状況をモニタリングし、使用量がプロビジョニングされたストレージ容量に近づくと自動的に容量をスケールアップします。Amazon RDS が DB インスタンスに割り当てることができるストレージの上限を指定できます。ストレージの自動スケーリングに追加料金はかかりません。DB インスタンスに割り当てられた Amazon RDS リソースに対してのみ料金が発生します。Amazon RDS ストレージの自動スケーリングを有効にすることをお勧めします。

詳細については、「Amazon RDS ストレージの自動スケーリングによる容量の自動管理」を参照してください。

マルチ AZ 配置を使用することをお勧めします。マルチ AZ 配置により、DB インスタンスの可用性と耐久性が向上します。

c1qf5bt019

黄色: DB インスタンスはマルチ AZ 配置を使用していません。

影響を受ける DB インスタンスにマルチ AZ を設定します。

Amazon RDS マルチ AZ 配置では、Amazon RDS は自動的にプライマリデータベースインスタンスを作成し、そのデータを別のアベイラビリティーゾーンのインスタンスにレプリケートします。障害が検出されると、Amazon RDS は手動操作なしでスタンバイインスタンスに自動的にフェイルオーバーします。

詳細については、「料金」を参照してください。

CloudWatch metric DiskQueueDepth が、RDS インスタンスデータベースストレージへのキューに入れられた書き込みの数が、運用上の調査を提案すべきレベルまで増加したことを示すかどうかを確認します。

Cmsvnj8db3

読み取り/書き込み特性をサポートするインスタンスとストレージボリュームへの移行を検討してください。

FreeStorageSpace データベースインスタンスの RDS CloudWatch Wordメトリクスが、運用上合理的なしきい値を下回ったかどうかを確認します。

Cmsvnj8db2

Amazon RDS マネジメントコンソール、Amazon Word、または API コマンドラインインターフェイスを使用して、空きストレージが少なくなっている AWSRDS データベースインスタンスRDSのストレージ領域をスケールアップします。

log_output が TABLE に設定されている場合、log_output が FILE に設定されている場合よりも多くのストレージが使用されます。ストレージサイズの制限に達しないように、 パラメータを FILE に設定することをお勧めします。

c1qf5bt023

黄: DB パラメータグループには log_output パラメータが TABLE に設定されています。

DB パラメータグループの log_output パラメータ値を FILE に設定します。

詳細については、「MySQL データベースログファイル」を参照してください。

DB インスタンスで既知の問題が発生しました。8.0.26 より前のバージョンの MySQL で row_format が COMPACT または REDUNDANT に設定されている場合、インデックスが 767 バイトを超えると、テーブルにアクセスできず、回復できません。

innodb_default_row_format パラメータ値を DYNAMIC に設定することをお勧めします。

c1qf5bt036

赤: DB パラメータグループの innodb_default_row_format パラメータの設定が安全ではありません。

innodb_default_row_format パラメータを DYNAMIC に設定します。

row_format を Word または COMPACT に設定して MySQL バージョン 8.0.26 より前のテーブルを作成する場合REDUNDANT、キープレフィックスが 767 バイト未満のインデックスの作成は強制されません。データベースが再起動すると、これらのテーブルにアクセスしたり、それを復元したりすることはできません。

詳細については、MySQL ドキュメントウェブサイトの「MyWord 8.0.26 (2021-07-20、一般提供)n の変更点」を参照してください。SQL

DB インスタンスの innodb_flush_log_at_trx_commit パラメータの値は安全ではありません。このパラメータは、ディスクへのコミット操作の持続性を制御します。

innodb_flush_log_at_trx_commit パラメータを 1 に設定することをお勧めします。

c1qf5bt030

黄: DB パラメータグループの innodb_flush_log_at_trx_commit が 1 以外に設定されている。

innodb_flush_log_at_trx_commit パラメータの値を 1 に設定します

ログバッファが耐久ストレージに保存されると、データベーストランザクションは耐久性を持ちます。ただし、ディスクに保存するとパフォーマンスに影響します。innodb_flush_log_at_trx_commit パラメータに設定されている値によって、ログがディスクに書き込まれて保存される方法の動作が異なる場合があります。

詳細については、「Amazon RDS for MySQL のパラメータを設定するためのベストプラクティス、パート 1: パフォーマンスに関連するパラメータ」を参照してください。

DB インスタンスは、各データベースアカウントの最大同時接続数の値が低くなっています。

max_user_connections パラメータを 5 より大きい数に設定することをお勧めします。

c1qf5bt034

黄色: DB パラメータグループの max_user_connections の設定に誤りがあります。

max_user_connections パラメータの値を 5 より大きい数にします。

max_user_connections 設定は、MySQL ユーザーアカウントで許可される同時接続の最大数を制御します。この接続制限に達すると、バックアップ、パッチ適用、パラメータの変更など、Amazon RDS インスタンスの管理オペレーションで障害が発生します。

詳細については、MySQL ドキュメントウェブサイトの「アカウントリソース制限の設定」を参照してください。

単一のアベイラビリティーゾーン (AZ) にデプロイされた DB インスタンスをチェックします。

マルチ AZ 配置は、別のアベイラビリティーゾーン内のスタンバイインスタンスに同期的にレプリケートすることによってデータベースの可用性を向上させます。計画されたデータベースメンテナンス中、または DB インスタンスまたはアベイラビリティーゾーンの障害中に、Amazon RDS は自動的にスタンバイにフェイルオーバーします。このフェイルオーバーにより、管理者の介入を必要とせずにデータベースオペレーションを迅速に再開できます。Amazon RDS は Microsoft SQL Server のマルチ AZ 配置をサポートしていないため、このチェックでは SQL Server インスタンスを調べません。

f2iK5R6Dep

黄: DB インスタンスが 1 つのアベイラビリティーゾーンにデプロイされています。

アプリケーションで高可用性が必要な場合は、DB インスタンスを変更してマルチ AZ 配置を有効にします。「高可用性 (マルチ AZ)」を参照してください。

リージョンとアベイラビリティーゾーン

Amazon RDS DB インスタンスがバックアッププランに含まれているかどうかを確認します AWS Backup。

AWS Backup はフルマネージド型のバックアップサービスで、 AWS サービス間でデータのバックアップを簡単に一元化および自動化できます。

Amazon RDS DB インスタンスをバックアッププランに含めることは、規制コンプライアンス義務、ディザスタリカバリ、データ保護のビジネスポリシー、およびビジネス継続性の目標にとって重要です。

詳細については、AWS Backup とは」を参照してください。

c18d2gz159

AWS Config Managed Rule: rds-in-backup-plan

黄: Amazon RDS DB インスタンスは、 のバックアッププランに含まれていません AWS Backup。

Amazon RDS DB インスタンスをバックアッププランに含めます AWS Backup。

詳細については、「Amazon RDS Backup and Restore Using AWS Backup」を参照してください。

バックアッププランへのリソースの割り当て

DB インスタンスには書き込み可能モードのリードレプリカがあり、クライアントからの更新が可能です。

リードレプリカが書き込み可能モードにならないように、read_only パラメータを TrueIfReplica に設定することをお勧めします。

c1qf5bt035

黄色: DB パラメータグループはリードレプリカの書き込み可能モードを有効にします。

read_only パラメータ値を TrueIfReplica に設定します。

read_only パラメータは、クライアントからデータベースインスタンスへの書き込みアクセス許可を制御します。このパラメータのデフォルト値は TrueIfReplica です。レプリカインスタンスの場合、TrueIfReplica は read_only 値を ON (1) に設定し、クライアントからの書き込みアクティビティを無効にします。マスター/ライターインスタンスの場合、TrueIfReplica は値を OFF (0) に設定し、インスタンスのクライアントからの書き込みアクティビティを有効にします。リードレプリカを書き込み可能モードで開いた場合、このインスタンスに格納されているデータがプライマリインスタンスと異なることがあり、これがレプリケーションエラーの原因となります。

詳細については、MyWord ドキュメントウェブサイトの「Amazon RDS for MySQL のパラメータを設定するためのベストプラクティス、パート 2: レプリケーションに関連するパラメータSQL」を参照してください。

DB リソースの自動バックアップは無効になっています。自動バックアップは、DB インスタンスの Enable point-in-time リカバリを有効にします。

c1qf5bt001

赤: Amazon RDS リソースで自動バックアップが有効になっていない

最大 14 日間の保存期間で自動バックアップを有効にします。

自動バックアップは、DB インスタンスの enable point-in-time リカバリを有効にします。自動バックアップをオンにすることをおすすめします。DB インスタンスの自動バックアップを有効にすると、Amazon RDS は希望するバックアップウィンドウ中に毎日データの完全なバックアップを自動的に実行します。バックアップは、DB インスタンスの更新時にトランザクションログをキャプチャします。お客様の DB インスタンスのストレージサイズまで、バックアップストレージを追加料金なしでご利用いただけます。

詳細については、以下のリソースを参照してください。

DB インスタンスでトランザクションのコミットが確認される前には、バイナリログのディスクへの同期は実行されません。

sync_binlog パラメータの値を 1 に設定することをお勧めします。

c1qf5bt031

黄色: DB パラメータグループの同期バイナリログ記録は無効になっています。

sync_binlog パラメータを 1 に設定します。

sync_binlog パラメータは、MySQL がバイナリログをディスクにプッシュする方法を制御します。このパラメータの値を 1 に設定すると、トランザクションがコミットされる前にバイナリログのディスクへの同期が有効になります。このパラメーターの値を 0 に設定すると、ディスクへのバイナリログ同期がオフになります。通常、MySQL サーバーはオペレーティングシステムに依存して、他のファイルと同様にバイナリログを定期的にディスクにプッシュします。sync_binlog パラメータ値を 0 に設定すると、パフォーマンスが向上します。ただし、停電やオペレーティングシステムのクラッシュが発生すると、サーバーはバイナリログと同期されていないコミット済みのトランザクションをすべて失います。

詳細については、「Amazon RDS for MySQL のパラメータを設定するためのベストプラクティス、パート 2: レプリケーションに関連するパラメータ」を参照してください。

Amazon RDS DB クラスターでマルチ AZ レプリケーションが有効になっているかどうかを確認します。

マルチ AZ DB クラスターには、3 つの別々のアベイラビリティーゾーンに 1 つのライター DB インスタンスと 2 つのリーダー DB インスタンスがあります。マルチ AZ DB クラスターは、マルチ AZ 配置と比較して、高可用性、読み取りワークロードの容量の増加、および低レイテンシーを提供します。

詳細については、「マルチ AZ DB クラスターの作成」を参照してください。

c18d2gz161

AWS Config Managed Rule: rds-cluster-multi-az-enabled

黄: Amazon RDS DB クラスターにマルチ AZ レプリケーションが設定されていません

Amazon RDS DB クラスターを作成するときに、マルチ AZ DB クラスターのデプロイを有効にします。

詳細については、「マルチ AZ DB クラスターの作成」を参照してください。

マルチ AZ DB クラスターのデプロイ

Amazon RDS DB インスタンスにマルチ AZ スタンバイレプリカが設定されているかどうかを確認します。

Amazon RDS マルチ AZ は、データを別のアベイラビリティーゾーンのスタンバイレプリカにレプリケートすることで、データベースインスタンスの高可用性と耐久性を実現します。これにより、自動フェイルオーバーが可能になり、パフォーマンスが向上し、データの耐久性が向上します。マルチ AZ DB インスタンスのデプロイでは、Amazon RDS は同期スタンバイレプリカを別のアベイラビリティーゾーンに自動的にプロビジョニングして維持します。プライマリ DB インスタンスは、アベイラビリティーゾーン間でスタンバイレプリカに同期的に複製され、データの冗長性を提供し、システムバックアップ中の遅延スパイクを最小限に抑えます。高可用性を備えた DB インスタンスを実行すると、計画されたシステムメンテナンス中の可用性が向上します。また、DB インスタンスの障害とアベイラビリティーゾーンの中断からデータベースを保護することを助けることもできます。

詳細については、「マルチ AZ DB インスタンスのデプロイ」を参照してください。

c18d2gz156

AWS Config Managed Rule: rds-multi-az-support

黄: Amazon RDS DB インスタンスにマルチ AZ レプリカが設定されていません。

Amazon RDS DB インスタンスを作成するときに、マルチ AZ 配置を有効にします。

このチェックを Trusted Advisor コンソールのビューから除外することはできません。

マルチAZ DB インスタンスのデプロイ

ReplicaLag データベースインスタンスの RDS CloudWatch Wordメトリクスが、過去 1 週間に運用上合理的なしきい値を超えたかどうかを確認します。

ReplicaLag メトリクスは、リードレプリカがプライマリインスタンスの背後にある秒数を測定します。リードレプリカに加えられた非同期更新が、プライマリデータベースインスタンスで行われている更新に追いつけないと、レプリケーションラグが発生します。プライマリインスタンスに障害が発生した場合、 ReplicaLag が運用上合理的なしきい値を超えていると、リードレプリカにデータがない可能性があります。

Cmsvnj8db1

for ReplicaLag が運用上安全なレベルを超えて増加する原因はいくつか考えられます。例えば、最近の replaced/launched replica instances from older backups and these replicas requiring substantial time to “catch-up” to the primary database instance and live transactions. This ReplicaLag may dwindle over time as catch-up occurs. Another example could be that the transaction velocity able to be achieved on the primary database instance is higher than the replication process or replica infrastructure is able to match. This ReplicaLag may grow over time as replication fails to keep pace with the primary database performance. Finally, the workload may be bursty throughout different periods of the day/month/etc が原因で、時折 ReplicaLag が遅れることがあります。チームは、データベースの high ReplicaLag に寄与した可能性のある根本原因を調査し、データベースインスタンスタイプやその他のワークロードの特性を変更して、レプリカのデータ継続性が要件と一致することを確認する必要があります。

synchronous_commit パラメータを無効にすると、データベースのクラッシュでデータが失われる可能性があります。データベースの耐久性が危険にさらされます。

synchronous_commit パラメータを有効にすることをお勧めします。

c1qf5bt026

赤: DB パラメータグループでは synchronous_commit パラメータが無効になっています。

DB パラメータグループの synchronous_commit パラメータを有効にします。

synchronous_commit パラメータは、データベースサーバーがクライアントに成功通知を送信する前に、先書きログ (WAL) プロセスの完了を定義します。このコミットは非同期コミットと呼ばれます。これは、WAL がトランザクションをディスクに保存する前にクライアントがコミットを承認するためです。synchronous_commit パラメータを無効にすると、トランザクションが失われ、DB インスタンスの耐久性が損なわれ、データベースがクラッシュしたときにデータが失われる可能性があります。

詳細については、「MySQL データベースログファイル」を参照してください。

自動スナップショットが Amazon Redshift クラスターに対して有効になっていることを確認します。

Amazon Redshift は、前回のスナップショット以降にクラスターに加えられた増分変更を追跡する、増分スナップショットを自動的に作成します。自動スナップショットは、スナップショットからクラスターを復元するために必要なすべてのデータを保持します。自動スナップショットを無効にするには、保持期間を 0 に設定します。RA3 ノードタイプの自動スナップショットを無効にすることはできません。

AWS Config ルールの MinRetentionPeriod および MaxRetentionPeriod パラメータを使用して、希望する最小保持期間と最大保持期間を指定できます。

Amazon Redshift スナップショットとバックアップ

c18d2gz135

AWS Config Managed Rule: redshift-backup-enabled

赤: Amazon Redshift で、希望する保持期間内に自動スナップショットが設定されていません。

Amazon Redshift クラスターに対して自動スナップショットが有効になっていることを確認します。

詳細については、「コンソールを使用したスナップショットの管理」を参照してください。

Amazon Redshift スナップショットとバックアップ

詳細については、「バックアップの使用」を参照してください。

削除されたヘルスチェックに関連付けられているリソースレコードセットをチェックします。

リソースレコードセットに関連付けられているヘルスチェックの削除を防止する機構は Route 53 にありません。関連するリソースレコードセットを更新せずにヘルスチェックを削除した場合、DNS フェイルオーバー設定の DNS クエリのルーティングは意図したとおりに機能しません。

AWS サービスによって作成されたホストゾーンは、チェック結果に表示されません。

Cb877eB72b

黄: リソースレコードセットが削除されたヘルスチェックに関連付けられています。

新しいヘルスチェックを作成し、リソースレコードセットに関連付けます。「ヘルスチェックの作成、更新、削除」および「Adding Health Checks to Resource Record Sets」(リソースレコードセットへのヘルスチェックの追加) を参照してください。

設定ミスがある Amazon Route 53 フェイルオーバーリソースレコードセットをチェックします。

Amazon Route 53 のヘルスチェックでプライマリリソースが正常でないと判断されると、Amazon Route 53 はセカンダリのバックアップリソースレコードセットでクエリに応答します。フェイルオーバーが機能するには、正しく設定されたプライマリリソースレコードセットとセカンダリリソースレコードセットを作成する必要があります。

AWS サービスによって作成されたホストゾーンは、チェック結果に表示されません。

b73EEdD790

フェイルオーバーリソースセットがない場合は、対応するリソースレコードセットを作成します。「Creating Failover Resource Record Sets」(フェイルオーバーリソースレコードセットの作成) を参照してください。

リソースレコードセットが同じヘルスチェックに関連付けられている場合は、それぞれに個別のヘルスチェックを作成します。「ヘルスチェックの作成、更新、削除」を参照してください。

Amazon Route 53 ヘルスチェックとDNSフェイルオーバー

Word ( time-to-liveTTL) 値を小さくするとメリットが得られるリソースレコードセットをチェックします。

TTL は、リソースレコードセットが DNS リゾルバーによってキャッシュされる秒数です。長いTTLを指定すると、DNS リゾルバーが更新された DNS レコードをリクエストするまでに時間がかかり、トラフィックの再ルーティングに不要な遅延が発生する可能性があります (例えば、DNS フェイルオーバーがいずれかのエンドポイントの障害を検出して応答した場合など）。このチェックは、フェイルオーバーのポリシーを持つレコード、または関連するヘルスチェックがあるレコードのみを調べます。

AWS サービスによって作成されたホストゾーンは、チェック結果に表示されません。

C056F80cR3

リストされたリソースレコードセットに 60 秒の TTL 値を入力します。詳細については、「Working with Resource Record Sets」(リソースレコードセットの使用) を参照してください。

Amazon Route 53 ヘルスチェックとDNSフェイルオーバー

ドメインレジストラまたは DNS が正しい Route 53 ネームサーバーを使用していない Amazon Route 53 ホストゾーンをチェックします。

ホストゾーンを作成する場合、Route 53 はホストゾーンに一連の 4 つのネームサーバーの移譲セットを割り当てます。これらのサーバーの名前は ns-###.awsdns-##.com、.net、.org、.co.uk。### また、## 通常、 は異なる数値を表します。Route 53 がドメインの DNS クエリをルーティングできるようにするには、レジストラのネームサーバー設定を更新して、レジストラが割り当てたネームサーバーを削除する必要があります。次に、Route 53 委任セットに 4 つのネームサーバーをすべて追加する必要があります。可用性を最大にするには、4 つの Route 53 ネームサーバーをすべて追加する必要があります。

AWS サービスによって作成されたホストゾーンは、チェック結果に表示されません。

cF171Db240

黄: ドメインのレジストラが委任セットの 4 つすべての Route 53 ネームサーバーを使用していないホストゾーン。

レジストラまたはドメインの現在の DNS サービスでネームサーバーレコードを追加または更新して、Route 53 委任セットの 4 つのネームサーバーすべてを含めます。これらの値を見つけるには、「Getting the Name Servers for a Hosted Zone」(ホストゾーンのネームサーバーの取得) を参照してください。ネームサーバーレコードの追加または更新については、「Creating and Migrating Domains and Subdomains to Amazon Route 53」(ドメインおよびサブドメインの作成と Amazon Route 53 への移行) を参照してください。

ホストゾーンの使用

サービス設定に、冗長性のために少なくとも 2 つのアベイラビリティーゾーン (AZs) で IP アドレスが指定されているかどうかを確認します。AZ は、他のゾーンの障害から隔離された独立した場所です。同じリージョン内の複数の AZs で IP アドレスを指定することで、単一の障害点からアプリケーションを保護するのに役立ちます。

Chrv231ch1

冗長性を確保するために、少なくとも 2 つのアベイラビリティーゾーンで IP アドレスを指定します。

Amazon Simple Storage Service (Amazon S3) バケットのログ設定を確認します。

サーバーアクセスログが有効になっている場合、詳細なアクセスログは、選択したバケットに 1 時間ごとに配信されます。アクセスログには、リクエストのタイプ、リクエストで指定されたリソース、リクエストが処理された日時など、各リクエストの詳細が記録されます。デフォルトでは、バケットのログは有効になっていません。セキュリティ監査を実行する場合、またはユーザーと使用パターンについて詳しく知りたい場合は、ログを有効にする必要があります。

ログが最初に有効になっている場合、設定が自動的に検証されます。ただし、今後の変更により、ログが失敗する可能性があります。このチェックでは、明示的な Amazon S3 バケットのアクセス許可が検査されますが、バケットのアクセス許可を上書きする可能性のある関連付けられたバケットポリシーは検査されません。

BueAdJ7NrP

ほとんどのバケットでバケットログ記録を有効にします。「Enabling Logging Using the Console」(コンソールを使用してログ記録を有効にする) および「Enabling Logging Programmatically」(プログラムを使用してログ記録を有効にする) を参照してください。

ターゲットバケットのアクセス許可にルートアカウントが含まれておらず、ログ記録のステータス Trusted Advisor を確認する場合は、ルートアカウントを被付与者として追加します。「Editing Bucket Permissions」(バケット許可の編集) を参照してください。

ターゲットバケットが存在しない場合は、既存のバケットをターゲットとして選択するか、新しいバケットを作成して選択します。「Managing Bucket Logging」(バケットのログ記録の管理) を参照してください。

ターゲットとソースの所有者が異なる場合は、ターゲットバケットを、ソースバケットと同じ所有者を持つバケットに変更します。「Managing Bucket Logging」(バケットのログ記録の管理) を参照してください。

ターゲットに対する書き込み許可がログの配信者に付与されていない (書き込みが有効になっていない) 場合は、ログ配信グループにアップロード/削除許可を付与します。「Editing Bucket Permissions」(バケット許可の編集) を参照してください。

Amazon S3 バケットで、クロスリージョンレプリケーション、同一リージョンレプリケーション、またはその両方に対してレプリケーションルールが有効になっているかどうかを確認します。

レプリケーションは、同じリージョンまたは異なる AWS リージョンのバケット間でオブジェクトを自動的に非同期コピーします。レプリケーションでは、新しく作成されたオブジェクトおよびオブジェクトの更新が、レプリケート元バケットからレプリケート先バケットにコピーされます。Amazon S3 バケットレプリケーションを使用すると、アプリケーションとデータストレージの耐障害性とコンプライアンスを向上させることができます。

詳細については、「オブジェクトのレプリケーション」を参照してください。

c18d2gz119

AWS Config Managed Rule: s3-bucket-replication-enabled

黄: Amazon S3 バケットで、クロスリージョンレプリケーション、同一リージョンレプリケーション、またはその両方に対してレプリケーションルールが有効になっていません。

Amazon S3 バケットレプリケーションルールをオンにして、アプリケーションとデータストレージの耐障害性とコンプライアンスを向上させます。

詳細については、「バックアップジョブと復旧ポイントの表示」と「レプリケーションの設定」を参照してください。

チュートリアル: レプリケーションの設定例

バージョニングが有効になっていないか、バージョニングが停止している Amazon Simple Storage Service バケットをチェックします。

バージョニングが有効であれば、意図しないユーザーアクションとアプリケーション障害の両方から簡単に復旧できます。バージョニングを使用すると、 バケットに保存されたオブジェクトのすべてのバージョンを保存、取得、復元することができます。ライフサイクルルールを使用してオブジェクトを Glacier ストレージクラスに自動的にアーカイブすることで、オブジェクトのすべてのバージョンとそれに関連するコストを管理できます。ルールを設定して、指定した期間後にオブジェクトのバージョンを削除することもできます。バケットへのオブジェクトの削除や設定の変更には、多要素認証 (MFA) を要求することもできます。

バージョン管理を有効にした後は、非アクティブ化できません。ただし、一時停止して、オブジェクトの新しいバージョンが作成されないようにすることができます。バージョニングを使用すると、オブジェクトの複数のバージョンのストレージ料金が発生するため、Amazon S3 のコストが増加する可能性があります。

R365s2Qddf

誤って削除したり上書きしたりしないように、ほとんどのバケットでバケットのバージョニングを有効にします。「バージョニングの使用」および「Enabling Versioning Programmatically」(プログラムを使用してバージョニングを有効にする) を参照してください。

バケットのバージョニングが一時停止されている場合は、バージョニングを再度有効にすることを検討してください。バージョニングが停止されたバケット内のオブジェクトの操作については、「Managing Objects in a Versioning-Suspended Bucket」(バージョニングが停止されたバケット内のオブジェクトの管理) を参照してください。

バージョニングが有効または一時停止されている場合、特定のオブジェクトバージョンを期限切れとしてマークするか、不要なオブジェクトバージョンを完全に削除するライフサイクル設定ルールを定義できます。詳細については、「オブジェクトのライフサイクル管理」を参照してください。

MFA Delete では、バケットのバージョニングステータスが変更された場合や、オブジェクトのバージョンが削除された場合に追加の認証が必要です。ユーザーは、承認された認証デバイスから認証情報とコードを入力する必要があります。詳細については、MFA Delete」を参照してください。

バケットの使用

Load Balancer (Application、Network、Gateway Load Balancer) が複数のアベイラビリティーゾーンにまたがるサブネットで構成されているかどうかを確認します。

AWS Config ルールの minAvailabilityZones パラメータで、必要な最小アベイラビリティーゾーンを指定できます。

詳細については、「Application Load Balancer のアベイラビリティーゾーン」、「アベイラビリティーゾーン- Network Load Balancer」、および「ゲートウェイロードバランサーを作成」を参照してください。

c18d2gz169

AWS Config Managed Rule: elbv2-multiple-az

黄: 2 つ未満のアベイラビリティーゾーンのサブネットで構成された Application、Network、または Gateway Load Balancer。

Application、Network、Gateway Load Balancer を複数のアベイラビリティーゾーンにまたがるサブネットで構成します。

Application Load Balancer のアベイラビリティーゾーン

アベイラビリティーゾーン (Elastic Load Balancing)

ゲートウェイロードバランサーを作成

ターゲットのサブネットに十分な使用可能なIPsが残っていることを確認します。使用可能なIPsが十分あると、Auto Scaling グループが最大サイズに達し、追加のインスタンスを起動する必要がある場合に役立ちます。

Cjxm268ch1

利用可能な IP アドレスの数を増やす

Auto Scaling グループのヘルスチェック設定を調べます。

Auto Scaling グループに Elastic Load Balancing が使用されている場合は、Elastic Load Balancing ヘルスチェックを有効にすることをお勧めします。Elastic Load Balancing ヘルスチェックが使用されていない場合、Auto Scaling は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのヘルスにのみ対応できます。Auto Scaling は、インスタンスで実行されているアプリケーションに対して動作しません。

CLOG40CDO8

Auto Scaling グループにロードバランサーが関連付けられているが、Elastic Load Balancing ヘルスチェックが有効になっていない場合は、「Auto Scaling グループに Elastic Load Balancing ヘルスチェックを追加する」を参照してください。

Elastic Load Balancing ヘルスチェックが有効になっているが、Auto Scaling グループにロードバランサーが関連付けられていない場合は、「Set Up an Auto-Scaled and Load-Balanced Application」(Auto Scaling および負荷分散アプリケーションのセットアップ) を参照してください。

Amazon EC2 Auto Scaling ユーザーガイド

起動設定と Auto Scaling グループに関連付けられたリソースの可用性をチェックします。

使用できないリソースを指す Auto Scaling グループは、新しい Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動できません。適切に設定すると、Auto Scaling は需要の急増時に Amazon EC2 インスタンスの数をシームレスに増加させ、需要の急増時には自動的に減少させます。使用できないリソースをポイントする Auto Scaling グループおよび起動設定は、意図したとおりに動作しません。

8CNsSllI5v

ロードバランサーが削除されている場合は、新しいロードバランサーまたはターゲットグループを作成して Auto Scaling グループに関連付けるか、ロードバランサーなしで新しい Auto Scaling グループを作成します。新しいロードバランサーを使用して新しい Auto Scaling グループを作成する方法については、「Set Up an Auto-Scaled and Load-Balanced Application」(Auto Scaling および負荷分散アプリケーションのセットアップ) を参照してください。ロードバランサーを使用せずに新しい Auto Scaling グループを作成する方法については、「Getting Started With Auto Scaling Using the Console」(コンソールを使用した Auto Scaling の開始方法) の「Create Auto Scaling Group」(Auto Scaling グループの作成) を参照してください。

AMI が削除された場合は、有効な AMI を使用して新しい起動テンプレートまたは起動テンプレートのバージョンを作成し、Auto Scaling グループと関連付けます。「Getting Started With Auto Scaling Using the Console」(コンソールを使用した Auto Scaling の開始方法) の「Create Launch Configuration」(起動設定の作成) を参照してください。

起動テンプレートで、無効な Amazon マシンイメージ (AMI) ID を参照する AWS Systems Manager パラメータが指定されているか、無効な パラメータが含まれている場合は、起動テンプレートを確認して有効なパラメータを更新するか、 AWS Systems Manager パラメータストアで適切な変更を加えます。詳細については、IDs「Amazon AMI Auto Scaling ユーザーガイド」の「単語の代わりに AWS Systems Manager パラメータを使用する」を参照してください。 EC2 Auto Scaling

単一のアベイラビリティーゾーン (AZ) で HSM インスタンスを実行するクラスターをチェックします。このチェックは、クラスターに最新のバックアップがないリスクがある場合に警告します。

hc0dfs7601

異なるアベイラビリティーゾーンにあるクラスターのインスタンスを少なくとも 1 つ以上作成します。

のベストプラクティス AWS CloudHSM

オンプレミスを各 Direct Connect ゲートウェイまたは仮想プライベートゲートウェイに接続する AWS Direct Connect ために使用される の耐障害性をチェックします。

このチェックでは、Direct Connect ゲートウェイまたは仮想プライベートゲートウェイに、少なくとも 2 つの異なる Direct Connect ロケーションにまたがる仮想インターフェイスが設定されていない場合に警告します。ロケーションレジリエンシーがないと、メンテナンス中の予期しないダウンタイム、ファイバーの切断、デバイスの障害、または完全なロケーション障害が発生する可能性があります。

c1dfpnchv2

赤: Direct Connect ゲートウェイまたは仮想プライベートゲートウェイは、単一の Direct Connect デバイスに 1 つ以上の仮想インターフェイスで設定されています。

黄: Direct Connect ゲートウェイまたは仮想プライベートゲートウェイは、1 つの Direct Connect ロケーション内の複数の Direct Connect デバイス間の仮想インターフェイスで設定されています。

緑: Direct Connect ゲートウェイまたは仮想プライベートゲートウェイは、2 つ以上の異なる Direct Connect ロケーションにまたがる仮想インターフェイスで設定されています。

Direct Connect ロケーションレジリエンシーを構築するには、少なくとも 2 つの異なる Direct Connect ロケーションに接続するように Direct Connect ゲートウェイまたは仮想プライベートゲートウェイを設定できます。詳細については、AWS Direct Connect 「Resiliency Recommendation」を参照してください。

AWS Direct Connect 障害耐性に関する推奨事項

AWS Direct Connect フェイルオーバーテスト

AWS Lambda 関数にデッドレターキューが設定されているかどうかを確認します。

デッドレターキューは、失敗したイベントをキャプチャして分析し、それらのイベントを適切に処理 AWS Lambda する方法を提供する の機能です。コードによって例外が発生したり、タイムアウトになったり、メモリが不足したりして、Lambda 関数の非同期実行が失敗する可能性があります。デッドレターキューは、失敗した呼び出しからのメッセージを格納し、メッセージを処理して障害をトラブルシューティングする方法を提供します。

AWS Config ルールの dlqArns パラメータを使用して、チェックするデッドレターキューリソースを指定できます。

詳細については、「デッドレターキュー」を参照してください。

c18d2gz182

AWS Config Managed Rule: lambda-dlq-check

黄: AWS Lambda 関数にはデッドレターキューが設定されていません。

AWS Lambda 関数に、失敗したすべての非同期呼び出しのメッセージ処理を制御するデッドレターキューが設定されていることを確認します。

詳細については、「デッドレターキュー」を参照してください。

アカウント内の Lambda 関数に、非同期呼び出し用に障害発生時のイベント送信先またはデッドレターキュー (DLQ) が設定されていることを確認し、失敗した呼び出しからのレコードを宛先にルーティングして、さらなる調査や処理を行うことができます。

c1dfprch05

Lambda 関数が、失敗した呼び出しとその他の詳細を利用可能な送信先 DLQ サービスのいずれかに送信して、さらにデバッグまたは処理できるように、障害発生時のイベント送信先または AWS を設定してください。

1 つのアベイラビリティーゾーンでサービス中断に対して脆弱な VPC 対応 Lambda 関数の $LATEST バージョンを確認します。VPC 対応の関数は、高可用性を実現するために複数のアベイラビリティーゾーンに接続することがベストプラクティスです。

L4dfs2Q4C6

黄: Word VPC対応の Lambda 関数の $LATEST バージョンは、単一のアベイラビリティーゾーンのサブネットに接続されています。

VPC にアクセスするための関数を設定するときは、複数のアベイラビリティーゾーンのサブネットを選択して、高可用性を確保します。

Outposts ラックのバランスをチェックします。これは、お客様が Outposts インスタンスを複数の Outposts ラックにデプロイするか、単一の Outpost ラックにデプロイするかを評価します。単一の Outposts ラックは、単一のラックに関連する問題 (環境障害など) に対して単一の障害点を作成します。これらのシナリオは、アウトポストを複数のラックにデプロイすることで軽減できます。

c243hjzrhn

で本稼働ワークロードを実行している場合は AWS Outposts、次の回復力のあるアーキテクチャを使用するのがベストプラクティスです。1 つの AWS Outposts ラックで 1 つの障害点が作成されます。フェイルオーバーイベントに十分な容量がある場所に 2 台目の AWS Outposts ラックを追加し、ラック間でワークロードを分散することを検討してください。

障害モード 4: ラックまたはデータセンター

アプリケーションのアプリケーションコンポーネント (AppComponent) が回復不能かどうかを確認します。中断イベントが発生した場合に an AppComponent が回復しない場合、不明なデータ損失やシステムのダウンタイムが発生する可能性があります。

RH23stmM04

Red: AppComponent は回復できません。

your AppComponent が回復可能であることを確認するには、障害耐性に関する推奨事項を確認して実装し、新しい評価を実行します。障害耐性に関する推奨事項の確認の詳細については、「その他のリソース」を参照してください。

障害耐性に関する推奨事項の確認

AWS Resilience Hub の概念

AWS Resilience Hub ユーザーガイド

Resilience Hub で、ポリシーが定義する目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たさないアプリケーションをチェックします。このチェックでは、アプリケーションが Resilience Hub でアプリケーションに設定した RTO および RPO の目標を満たしていない場合に警告します。

RH23stmM02

Resilience Hub コンソールにサインインし、レコメンデーションを確認して、アプリケーションが RTO および RPO の目的を満たしていることを確認します。

Resilience Hub の概念

Resilience Hub でアプリケーションの評価が実行されたかどうかをチェックします。このチェックでは、耐障害性スコアが特定の値を下回っている場合に警告が表示されます。

RH23stmM01

Resilience Hub コンソールにサインインして、アプリケーションの評価を実行します。レコメンデーションを確認して耐障害性スコアを向上させてください。

Resilience Hub の概念

最後にアプリケーション評価を実行してからどれくらいの時間が経過したかを確認します。このチェックでは、指定した日数の間アプリケーション評価を実行していない場合に警告を表示します。

RH23stmM03

Resilience Hub コンソールにサインインして、アプリケーションの評価を実行します。

Resilience Hub の概念

各 でアクティブなトンネルの数を確認します AWS Site-to-Site VPN。

VPN には、常に 2 つのトンネルが設定されている必要があります。これにより、AWS エンドポイントでデバイスの停止や計画的なメンテナンスが発生した場合に冗長性が得られます。一部のハードウェアでは、一度に 1 つのトンネルだけがアクティブになります。VPN にアクティブなトンネルがない場合でも、その VPN の料金が適用される場合があります。

詳細については、AWS Site-to-Site VPN」を参照してください。

c18d2gz123

AWS Config Managed Rule: vpc-vpn-2-tunnels-up

黄: A Site-to-Site VPN には少なくとも 1 つのトンネル DOWN があります。

VPN 接続用に 2 つのトンネルが設定されていることを確認します。また、ハードウェアが対応している場合は、両方のトンネルがアクティブであることを確認してください。VPN 接続が不要になった場合は、料金が発生しないように削除してください。

詳細については、「カスタマーゲートウェイデバイス」と、AWS ナレッジセンターで利用可能なコンテンツを参照してください。

信頼性の柱でワークロードの高リスクの問題 (HRIs) をチェックします。このチェックは、AWS-Well Architected レビュー。チェック結果は、 でワークロード評価を完了したかどうかによって異なります。AWS Well-Architected.

Wxdfp4B1L4

AWS Well-Architected は、ワークロードの評価中に高リスクの問題を検出しました。これらの問題は、リスクを軽減し、費用を節約する機会を提示します。AWS Well-Architected ツールにサインインして、回答を確認し、アクティブな問題を解決するためのアクションを実行します。

Classic Load Balancer が複数のアベイラビリティーゾーン (AZs) にまたがっているかどうかを確認します。

ロードバランサーは、受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数の Amazon EC2 インスタンスに分散します。デフォルトでは、ロードバランサーは、ロードバランサーに対して有効にするアベイラビリティーゾーン間で均等にトラフィックを分散します。1 つのアベイラビリティーゾーンで停止が発生した場合、ロードバランサーノードは、1 つ以上のアベイラビリティーゾーンにある正常な登録済みのインスタンスにリクエストを自動的に転送します。

AWS Config ルールの minAvailabilityZones パラメータを使用して、アベイラビリティーゾーンの最小数を調整できます。

詳細については、「What is a Classic Load Balancer?」を参照してください。

c18d2gz154

AWS Config Managed Rule: clb-multiple-az

黄: Classic Load Balancer にマルチ AZ が設定されていないか、指定された AZs の最小数を満たしていません。

Classic Load Balancer に複数のアベイラビリティーゾーンが設定されていることを確認します。ロードバランサーを複数の AZs にまたがって、アプリケーションの高可用性を確保します。

詳細については、「Tutorial: Create a Classic Load Balancer」を参照してください。

Connection Draining が有効になっていない Classic ロードバランサーをチェックします。

Connection Draining が有効になっていず、Amazon EC2 インスタンスを Classic ロードバランサーから登録解除すると、Classic ロードバランサーはそのインスタンスへのトラフィックのルーティングを停止し、接続を閉じます。Connection Draining が有効になっている場合、 Classic ロードバランサーは登録解除されたインスタンスへの新しいリクエストの送信を停止しますが、アクティブなリクエストを処理するために接続を開いたままにします。

7qGXsKIUw

Classic ロードバランサーの接続ドレイニングを有効にします。詳細については、「Connection Draining」および「Enable or Disable Connection Draining for Your Load Balancer」(ロードバランサーの Connection Draining を有効または無効にする) を参照してください。

Elastic Load Balancing のコンセプト

Application Load Balancer (AZs）、Network Load Balancer (Word)、Gateway Load Balancer (ALB) のアベイラビリティーゾーン (GWLBNLB) 間のターゲットグループのターゲット分散をチェックします。

このチェックでは、以下は除外されます。

b92b83d667

回復力を高めるには、ターゲットグループに AZs 全体で同じ数のターゲットがあることを確認してください。

「Application Load Balancer のターゲットグループ」

Application Load Balancer ターゲットグループにターゲットを登録する

Gateway Load Balancer (GWLB) エンドポイントが、別のアベイラビリティーゾーン (AZ) からのルート送信先として設定されているかどうかを確認します。

Gateway Load Balancer エンドポイントは、検査のためにネットワークトラフィックを Gateway Load Balancer の背後にあるファイアウォールアプライアンスに転送します。各 Gateway Load Balancer エンドポイントは、指定された AZ 内で動作し、その AZ のみに冗長性を持たせて構築されます。そのため、特定の AZ のすべてのリソースは、同じ AZ の Gateway Load Balancer エンドポイントを使用する必要があります。これにより、Gateway Load Balancer エンドポイントまたはその AZ の潜在的な停止が、別の AZ のリソースに影響を与えないようにします。

528d6f5ee7

サブネットの AZ を確認し、同じ AZ の Gateway Load Balancer エンドポイントを介してトラフィックをルーティングするようにルートテーブルを設定します。

AZ に Gateway Load Balancer エンドポイントがない場合は、新しいエンドポイントを作成し、そのエンドポイントを介してサブネットトラフィックをルーティングします。

異なる AZs のサブネット間で同じルートテーブルが関連付けられている場合は、このルートテーブルを Gateway Load Balancer エンドポイントと同じ AZ に存在するサブネットに関連付けたままにします。他の AZ のサブネットの場合、別のルートテーブルをこの AZ の Gateway Load Balancer エンドポイントへのルートに関連付けることができます。

Amazon VPC のアーキテクチャ変更のメンテナンスウィンドウを選択するのがベストプラクティスです。

ロードバランサーの設定を確認します。

Elastic Load Balancing を使用する場合に Amazon Elastic Compute Cloud (Amazon EC2) の耐障害性のレベルを上げるために、リージョン内の複数のアベイラビリティーゾーンで同じ数のインスタンスを実行することをお勧めします。設定されているロードバランサーでは料金が発生するため、コスト最適化チェックとしても機能します。

iqdCTZKCUp

ロードバランサーが、少なくとも 2 つのアベイラビリティーゾーンにおいて、アクティブで正常なインスタンスをポイントしているようにします。詳細については、「Add Availability Zone」(アベイラビリティーゾーンの追加) を参照してください。

ロードバランサーが正常なインスタンスのないアベイラビリティーゾーン用に設定されている場合、またはアベイラビリティーゾーン全体でインスタンスの不均衡がある場合は、すべてのアベイラビリティーゾーンが必要かどうかを判断します。不要なアベイラビリティーゾーンを除外し、残りのアベイラビリティーゾーン全体でインスタンスが均等に分散されるようにします。詳細については、「Remove Availability Zone」(アベイラビリティーゾーンの削除) を参照してください。

NAT Gateway にアベイラビリティーゾーン (AZ) の独立性が設定されているかどうかを確認します。

NAT Gateway を使用すると、プライベートサブネット内のリソースは、NAT Gateway の IP アドレスを使用してサブネット外のサービスに安全に接続し、未承諾のインバウンドトラフィックをすべてドロップできます。各 NAT Gateway は、指定されたアベイラビリティーゾーン (AZ) 内で動作し、その AZ でのみ冗長性を持って構築されます。したがって、特定の AZ のリソースは、NAT AZ の NAT Gateway を使用して、Word Gateway またはその AZ の潜在的な停止が別の AZ のリソースに影響を与えないようにする必要があります。

c1dfptbg10

サブネットの AZ を確認し、同じ AZ の NAT Gateway を介してトラフィックをルーティングしてください。

AZ に NATGW がない場合は、その Word を作成し、サブネットトラフィックをルーティングしてください。

異なる AZs のサブネット間で同じルートテーブルが関連付けられている場合は、このルートテーブルを NAT Gateway と同じ AZ にあるサブネットに関連付け、他の AZ のサブネットには別のルートテーブルをこの他の AZ の NAT Gateway へのルートに関連付けてください。

Amazon VPC のアーキテクチャ変更には、メンテナンスウィンドウを選択することをお勧めします。

AWS Network Firewall エンドポイントが別のアベイラビリティーゾーン (AZ) からのルート送信先として設定されているかどうかを確認します。

Network Firewall エンドポイントは、検査のためにネットワークトラフィックを Network Firewall に転送します。各 Network Firewall エンドポイントは、指定された AZ 内で動作し、その AZ でのみ冗長性を持って構築されます。特定の AZ のリソースは、同じ AZ の Network Firewall エンドポイントを使用する必要があります。これにより、Network Firewall エンドポイントまたはその AZ の潜在的な停止が、別の AZ のリソースに影響を与えないようにできます。トラフィック検査のために別の AZ を起点とするネットワークトラフィックには、AZ 間のデータ転送料金が発生します。特定の AZ 内のすべてのリソースが同じ AZ の Network Firewall を使用して、AZ 間のデータ料金が発生しないようにすることがベストプラクティスです。

7040ea389a

サブネットの AZ を確認し、同じ AZ の Network Firewall エンドポイントを介してトラフィックをルーティングします。

AZ に Network Firewall エンドポイントがない場合は、新しい Network Firewall を作成し、サブネットトラフィックをルーティングします。

同じルートテーブルが異なる AZs の複数のサブネットに関連付けられている場合は、このルートテーブルを Network Firewall エンドポイントと同じ AZ に存在するサブネットに関連付けたままにします。他の AZs のサブネットの場合は、別のルートテーブルをその AZ の Network Firewall エンドポイントへのルートに関連付けます。

Amazon VPC のアーキテクチャ変更のメンテナンスウィンドウを選択するのがベストプラクティスです。

同じ 内のデータ転送 AWS リージョン

データ転送料金について

アベイラビリティーゾーンの独立性

ファイアウォールを実装するための大まかな手順

ファイアウォールの作成

AWS Well-Architected Tool - バルクヘッドアーキテクチャを使用して影響範囲を制限する

Network Firewall がファイアウォールエンドポイントに複数のアベイラビリティーゾーン (AZ) を使用するように設定されているかどうかを確認します。

AZ は、他のゾーンでの障害から隔離された個別の場所です。Network Firewall エンドポイントが 1 つの AZ にのみデプロイされている場合、単一障害点になり、トラフィック検査に Network Firewall を使用すると、他の AZs のワークロードが損なわれる可能性があります。ワークロードの可用性を向上させるために、同じリージョン内の複数の AZs に Network Firewall を設定するのがベストプラクティスです。

c2vlfg0gqd

Network Firewall が本番ワークロード用に少なくとも 2 つの AZs で構成されていることを確認します。

の VPC サブネット設定AWS Network Firewall

ファイアウォールの作成

アベイラビリティーゾーン

AWS Well-Architected Tool - ワークロードを複数の場所にデプロイする

共有サービス VPC のアプライアンス

クロスゾーンロードバランシングが Network Load Balancer に対して有効になっているかどうかを確認します。

クロスゾーンロードバランシングは、異なるアベイラビリティーゾーンのインスタンス間で受信トラフィックを均等に分散させるのに役立ちます。これにより、ロードバランサーがすべてのトラフィックを同じアベイラビリティーゾーン内のインスタンスにルーティングし、トラフィックの分散が不均一になり、過負荷になるおそれを予防できます。また、この機能は、1 つのアベイラビリティーゾーンに障害が発生した場合に、他のアベイラビリティーゾーンの正常なインスタンスにトラフィックを自動的にルーティングするので、アプリケーションの信頼性にも役立ちます。

詳細については、「クロスゾーン負荷分散」を参照してください。

c18d2gz105

AWS Config Managed Rule: nlb-cross-zone-load-balancing-enabled

クロスゾーンロードバランシングが Network Load Balancer に対して有効になっていることを確認します。

クロスゾーン負荷分散 (Network Load Balancer)

インターネット向け Network Load Balancer (NLB) にプライベートサブネットが設定されているかどうかを確認します。トラフィックを受信するには、インターネット向け Network Load Balancer (NLB) をパブリックサブネットで設定する必要があります。パブリックサブネットは、インターネットゲートウェイへの直接ルートを持つサブネットとして定義されます。サブネットがプライベートとして設定されている場合、アベイラビリティーゾーン (AZ) はトラフィックを受信しないため、可用性の問題が発生する可能性があります。

c1dfpnchv4

赤: NLB は 1 つ以上のプライベートサブネットで設定されています

緑: インターネット向け NLB 用にプライベートサブネットが設定されていません

インターネット向けロードバランサーで設定されたサブネットがパブリックであることを確認します。パブリックサブネットは、インターネットゲートウェイへの直接ルートを持つサブネットとして定義されます。次のいずれかのオプションを使用します。

Network Load Balancer が複数のアベイラビリティーゾーン (AZ) を使用するように設定されているかどうかを確認します。AZ は、他のゾーンの障害から隔離された独立した場所です。ワークロードの可用性を向上させるために、ロードバランサーを同じリージョンの複数の AZs に設定します。

c1dfprch09

黄: NLBは 1 つの AZ にあります。

緑: NLB には 2 つ以上の AZs があります。

ロードバランサーが、少なくとも 2 つのアベイラビリティーゾーンで設定されているようにします。

詳細については、次のドキュメントを参照してください。

Incident Manager レプリケーションセットの設定で、リージョンのフェイルオーバーとレスポンス AWS リージョン をサポートするために複数の が使用されていることを確認します。 CloudWatch アラームまたは EventBridge イベントによって作成されたインシデントの場合、Incident Manager はアラームまたはイベントルール AWS リージョン と同じ にインシデントを作成します。そのリージョンで Incident Manager が一時的に使用不能な場合、システムは、レプリケーションセット内にある別のリージョンにインシデントを作成しようとします。Incident Manager が使用不能で、レプリケーションセットに含まれるリージョンが 1 つだけの場合、システムはインシデントレコードの作成に失敗します。

cIdfp1js9r

レプリケーションセットに 1 つ以上のリージョンを追加します。

詳細については、「リージョン間のインシデント管理」を参照してください。

単一のアベイラビリティーゾーン (AZ) 経由でネットワークの送信トラフィックがルーティングされているかをチェックします。

AZ はロケーションとして独立しており、他のゾーンの障害からは隔離されています。サービスを複数の AZs に分散することで、AZ 障害の爆発半径を制限できます。

c1dfptbg11

アプリケーションで高い可用性が必要な場合は、可用性を高めるマルチ AZ アーキテクチャの実装を検討してください。

AWS PrivateLink VPC インターフェイスエンドポイントが複数のアベイラビリティーゾーン (AZ) を使用するように設定されているかどうかを確認します。AZ は、他のゾーンの障害から隔離された独立した場所です。これにより、同じ AWS リージョン内の AZs 間の低コストで低レイテンシーのネットワーク接続がサポートされます。インターフェイスエンドポイントを作成するときに、複数の AZs のサブネットを選択して、単一の障害点からアプリケーションを保護します。

c1dfprch10

黄: VPCエンドポイントは 1 つの AZ にあります。

緑: VPC エンドポイントは少なくとも 2 つの AZs にあります。

VPC インターフェイスエンドポイントに少なくとも 2 つのアベイラビリティーゾーンが設定されていることを確認します。

詳細については、次のドキュメントを参照してください。

Site-to-Site VPNs ごとにアクティブなトンネルの数を確認します。

VPN には、常に 2 つのトンネルが設定されている必要があります。これにより、 AWS エンドポイントでのデバイスの障害や計画的なメンテナンスの場合に冗長性が得られます。一部のハードウェアでは、一度に 1 つのトンネルだけがアクティブになります。VPN にアクティブなトンネルがない場合でも、その VPN の料金が適用される場合があります。詳細については、AWS Site-to-Site ユーザーガイドVPN」を参照してください。

S45wrEXrLz

VPN 接続用に 2 つのトンネルが設定されていること、およびハードウェアがサポートしている場合は両方がアクティブであることを確認してください。VPN 接続が不要になった場合は、料金が発生しないように削除できます。詳細については、「カスタマーゲートウェイデバイス」または Site-to-Site VPN 接続の削除」を参照してください。

Amazon MQ for ActiveMQ ブローカーが、複数のアベイラビリティーゾーンにあるアクティブ/スタンバイブローカーで高可用性を実現するように設定されていることを確認します。

c1t3k8mqv1

アクティブ/スタンバイデプロイモードで新しいブローカーを作成します。

Amazon MQ for RabbitMQ ブローカーが、複数のアベイラビリティーゾーンにあるクラスターで高可用性を実現するように設定されていることを確認します。

c1t3k8mqv2

クラスターデプロイモードで新しいブローカーを作成します。