耐障害性

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

c1dfprch08

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

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

ロードバランサーが、少なくとも 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 設定を変更して、すべてがパブリックまたはプライベートになるようにします。詳細については、「Modifying a DB Instance Running the MySQL Database Engine」(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 のポイントインタイムリカバリ」を参照してください。

c18d2gz138

AWS Config Managed Rule: dynamodb-pitr-enabled

黄: ポイントインタイムリカバリが Amazon DynamoDB テーブルに対して有効になっていません。

Amazon DynamoDB でポイントインタイムリカバリを有効にすると、テーブルデータを継続的にバックアップできます。

詳細については、「ポイントインタイムリカバリ: 仕組み」を参照してください。

DynamoDB のポイントインタイムリカバリ

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

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

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

c18d2gz107

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

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

Amazon DynamoDB テーブルが AWS Backup プランの一部であることを確認してください。

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

What is AWS Backup?

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

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

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 コンソールを使用したバックアッププランの作成

What is AWS Backup?

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

Amazon EBS ボリュームのスナップショットが作成されてからの経過時間をチェックします。Amazon EBS ボリュームがレプリケートされていても、障害が発生する可能性があります。スナップショットは、耐久性のあるストレージとポイントインタイムリカバリのために Amazon 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 インスタンスを定期的に監視して異常のあるインスタンスを検出して終了し、新しいインスタンスを起動します。

詳細については、「Attach an Elastic Load Balancing load balancer to your Auto Scaling group」を参照してください。

c18d2gz104

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

黄: Amazon EC2 Auto Scaling グループにアタッチされた Classic Load Balancer は 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 グループに設定された複数の AZ がないか、指定されている AZ の最小数を満たしていません。

Amazon EC2 Auto Scaling グループが複数の AZ で構成されていることを確認してください。高可用性を確保するために、複数のアベイラビリティーゾーンに 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 グループの負荷分散) を参照してください。

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

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 EC2 メトリクスデータが Amazon CloudWatch に公開される頻度を増やします (5 分間隔から 1 分間隔に)。

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

このチェックでは、アカウントレベルのドライバー設定は考慮されません。

c1dvkm4z6b

黄: awslogs ドライバーのログ記録設定のパラメータモードがブロッキングに設定されています。

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

可用性を損なうリスクを軽減するには、タスク定義の AWS ログドライバーの設定をブロッキングからノンブロッキングに変更することを検討してください。ノンブロッキングモードでは、max-buffer-size パラメータの値を設定する必要があります。詳細については、「Preventing log loss with non-blocking mode in the AWSLogs container log driver」を参照してください。

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

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

AWSLogs コンテナのログドライバーのノンブロッキングモードによってログ損失を防止する

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

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

c1z7dfpz01

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

Amazon ECS のキャパシティとアベイラビリティ

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

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

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

c1z7dfpz02

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

Amazon ECS タスク配置戦略

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

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

c1dfprch01

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

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

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

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) にデプロイされた ElastiCache クラスターをチェックします。このチェックでは、クラスター内でマルチ AZ が非アクティブである場合に警告が表示されます。

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

ECHdfsQ402

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

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

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

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

詳細については、「Snapshot and restore」を参照してください。

c18d2gz178

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

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

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

詳細については、「Snapshot and restore」を参照してください。

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

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

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

MDBdfsQ401

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

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

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

Cmsvnj8vf1

MSK の推奨ベストプラクティスに従って MSK クラスターを拡張するか、未使用のパーティションをすべて削除してください。

Amazon MSK プロビジョニング済みクラスターのアベイラビリティーゾーン (AZ) の数をチェックします。Amazon MSK クラスターは、連携してデータと負荷を分散する複数のブローカーで構成されています。メンテナンス中、または 2 つの AZ を持つクラスターでブローカーの問題が発生している間、本稼働が中断される可能性があります。

90046ff5b5

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

Build highly available clusters

Migrate Kafka workloads to an Amazon MSK cluster

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

詳細については、「Increase availability for Amazon OpenSearch Service by deploying in three Availability Zones」を参照してください。

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

デフォルトでは、バックアップは 1 日の保持期間で有効になっています。バックアップは、予期しないデータ損失のリスクを軽減し、ポイントインタイムリカバリを可能にします。

opQPADkZvH

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

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

Amazon RDS の開始方法

Amazon RDS インスタンスで Amazon RDS を使用した自動バックアップまたは AWS Backup の継続的バックアップが有効になっているかどうかを確認します。継続的バックアップにより、予期しないデータ損失のリスクが軽減され、ポイントインタイムリカバリが可能になります。

44fde09ab5

Amazon RDS インスタンスの自動バックアップが設定されていることを確認するには、Amazon RDS で保持期間を 0 より長く設定するか、AWS Backup を使用して継続的なバックアッププランを作成します。

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 クラスターでは、リーダーインスタンスが同じアベイラビリティーゾーンにあります。

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

アベイラビリティーゾーンは、各 AWS 内で障害が発生した場合に分離できるよう、互いに区別された場所のことです。DB クラスターのプライマリインスタンスとリーダーインスタンスを複数の AZ に配信して、DB クラスターの可用性を改善することをお勧めします。マルチ AZ クラスターはクラスター作成時に、AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用して作成できます。また、既存の Aurora クラスターをマルチ AZ クラスターに変更するには、新しいリーダーインスタンスを追加し、別の AZ を指定します。

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

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

Amazon RDS の拡張モニタリングは、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 メトリクス

Amazon RDS DB インスタンスのストレージ自動スケーリングが有効になっていません。データベースのワークロードが増加した場合、RDSストレージの自動スケーリングにより、ダウンタイムなしでストレージ容量が自動的に拡張されます。

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 は手動操作なしで自動的にスタンバイインスタンスにフェイルオーバーします。

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

RDS インスタンスのデータベースストレージへのキューに入っている書き込みの数が、運用上の調査が必要となるレベルまで増加したことを、CloudWatch メトリクス DiskQueueDepth が示しているかどうかを確認します。

Cmsvnj8db3

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

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

Cmsvnj8db2

Amazon RDS マネジメントコンソール、Amazon RDS API、または AWS コマンドラインインターフェイスを使用して、空きストレージ容量が不足している RDS データベースインスタンスのストレージ容量をスケールアップします。

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

c1qf5bt023

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

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

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

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

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

c1qf5bt036

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

innodb_default_row_format パラメータを DYNAMIC に設定してください。

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

詳細については、MySQL ドキュメントウェブサイトの「MySQL 8.0.26 での変更点 (2021 年 7 月 20 日、一般提供開始)」を参照してください。

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 パラメータに設定されている値によって、ログがディスクに書き込まれて保存される方法の動作が異なる場合があります。

詳細については、「Best practices for configuring parameters for Amazon RDS for MySQL, part 1: Parameters related to performance」を参照してください。

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

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

c1qf5bt034

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

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

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

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

単一のアベイラビリティーゾーン (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) に設定し、クライアントからの書き込みアクティビティをすべて無効にします。マスター/ライターインスタンスの場合、TrueIReplica は値を OFF (0) に設定し、クライアントからのインスタンスへの書き込みアクティビティを有効にします。リードレプリカを書き込み可能モードで開いた場合、このインスタンスに格納されているデータがプライマリインスタンスと異なることがあり、これがレプリケーションエラーの原因となります。

詳細については、MySQL ドキュメントサイトの「Best practices for configuring parameters for Amazon RDS for MySQL, part 2: Parameters related to replication」を参照してください。

DB リソースの自動バックアップは無効になっています。自動バックアップでは、お客様の DB インスタンスのポイントインタイムリカバリが可能になります。

c1qf5bt001

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

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

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

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

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

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

c1qf5bt031

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

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

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

詳細については、「Best practices for configuring parameters for Amazon RDS for MySQL, part 2: Parameters related to replication」を参照してください。

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 インスタンスのデプロイ

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

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

Cmsvnj8db1

ReplicaLag が運用上の安全レベルを超えて増加する原因はいくつか考えられます。例えば、古いバックアップのレプリカインスタンスが最近交換または起動され、これらのレプリカがプライマリデータベースインスタンスとライブトランザクションに「追いつく」のにかなりの時間がかかることが原因である可能性があります。この ReplicaLag は、追いつきが発生するにつれて、時間の経過とともに減少する可能性があります。もう 1 つの例としては、プライマリデータベースインスタンスで達成できるトランザクション速度が、レプリケーションプロセスやレプリカインフラストラクチャで達成できる速度よりも速いことが挙げられます。この ReplicaLagは、レプリケーションがプライマリデータベースのパフォーマンスに追いついていないため、時間の経過とともに増加する可能性があります。最後に、1 日、1 か月などのさまざまな期間にわたってワークロードが集中し、その結果、ReplicaLag が遅くなることがあります。チームは、データベースの 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 フェイルオーバー

有効期限 (TTL) の値を小さくすることでメリットが生まれる可能性のあるリソースレコードセットをチェックします。

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

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 つのアベイラビリティーゾーン (AZ) で指定されている IP アドレスがあるかどうかを確認します。AZ は、他のゾーンの障害から隔離された独立した場所です。同一のリージョン内の複数のアベイラビリティーゾーンで IP アドレスを指定することにより、単一障害点からアプリケーションを保護できます。

Chrv231ch1

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

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)

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

ターゲットサブネットで十分な IP が使用可能であることを確認します。使用可能な IP が十分にあると、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 グループに関連付けます。新しい起動設定を作成する方法については、Amazon EC2 Auto Scaling ユーザーガイド」の「Create a launch configuration」を参照してください。起動テンプレートの作成方法に関する情報については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Create a launch template for an Auto Scaling group」を参照してください。

起動テンプレートに Amazon マシンイメージ (AMI) ID を含む AWS Systems Managerパラメータが含まれている場合は、起動テンプレートのパラメータが有効な AMI ID を参照していることを確認するか、AWS Systems Manager パラメータストアで適切な変更を行います。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Use AWS Systems Manager parameters instead of AMI IDs in launch templates」を参照してください。

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

hc0dfs7601

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

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

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

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

c1dfpnchv2

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

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

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

少なくとも 2 つの異なる Direct Connect ロケーションに接続するように Direct Connect ゲートウェイまたは仮想プライベートゲートウェイを設定することで、Direct Connect ロケーションの回復性を構築できます。詳細については、「‭‬Direct Connectの回復性に関する推奨事項‭‬」を参照してください。

Direct Connect の耐障害性に関するレコメンデーション

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

黄: 1 つのアベイラビリティーゾーンのサブネットに接続されている VPC 対応の Lambda 関数の $LATEST バージョン。

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

Outposts ラックのバランスを確認します。このチェックでは、お客様の Outposts インスタンスが複数の Outposts ラックにデプロイされているか、1 つの Outpost ラックにデプロイされているかを評価します。1 つの Outposts ラックにデプロイすると、1 つのラックに関連する問題 (環境に起因する障害など) に対する単一障害点が発生します。これらのシナリオは、複数のラックに Outpost をデプロイすることで軽減できます。

c243hjzrhn

AWS Outposts で本稼働ワークロードを実行している場合は、次の回復性のあるアーキテクチャを使用することをお勧めします。1 つの AWS Outposts ラックにデプロイすると、単一障害点が発生します。フェイルオーバーイベントに対応するのに十分な容量を持つ 2 つ目の AWS Outposts ラックをその場所に追加し、ラック間でワークロードを分散することを検討してください。

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

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

RH23stmM04

赤: AppComponent は回復不能です。

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

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

AWS Resilience Hub の概念

AWS Resilience Hub ユーザーガイド

ポリシーで定義されている目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たしていないアプリケーションを Resilience Hub でチェックします。このチェックでは、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 でアクティブなトンネルの数をチェックします。

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

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

c18d2gz123

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

黄: Site-to-Site VPN で少なくとも 1 つのトンネルが DOWN です。

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

詳細については、カスタマーゲートウェイデバイス、および AWS ナレッジセンターで利用できるコンテンツを参照してください。

このチェックは、AWS ワークロードが米国東部 (バージニア北部) リージョンの STS グローバルエンドポイントにクロスリージョン呼び出しを行う場合の回復性リスクを特定します。米国東部 (バージニア北部) の STS グローバルエンドポイントにクロスリージョンリクエストを行う AWS ワークロードは、米国東部 (バージニア北部) の STS エンドポイントへの接続が影響を受けた場合、悪影響を受ける可能性があります。

2025 年 4 月、AWS はグローバルエンドポイントを強化し、AWS で実行されているワークロードと同じリージョンの STS グローバルエンドポイント呼び出しを、デフォルトで有効になっているすべての AWS リージョンに対して自動的に処理するようにしました。ただし、オプトインリージョンで実行されているワークロードや Amazon DNS サーバーを使用していないワークロードなど、一部のワークロードにとっては、この機能強化の一環として提供されるレイテンシーと障害分離の削減によるメリットはありません。これらのワークロードでは、STS グローバルエンドポイントリクエストが米国東部 (バージニア北部) リージョンで処理されるため、アプリケーションに回復性のリスクが生じ、STS リクエストのレイテンシーが増加します。

c15m0mgld3

赤: ワークロードは、米国東部 (バージニア北部) リージョンの AWS STS グローバルエンドポイントに対してクロスリージョン呼び出しを行っています。

ワークロードの回復性とパフォーマンスを向上させるには、STS グローバルエンドポイントから STS リージョンエンドポイントに移行することをお勧めします。リージョンエンドポイントを使用すると、ワークロードと同じリージョンで AWS STS を使用できます。

以下は、米国東部 (バージニア北部) リージョンの AWS STS グローバルエンドポイントに対してクロスリージョン呼び出しを行う AWS Identity and Access Management (IAM) プリンシパルのリストです。ブログ記事「How to use Regional AWS STS endpoints」の手順に従って、リージョン STS エンドポイントを使用するようにワークロードを再設定できます。

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

Wxdfp4B1L4

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

Classic Load Balancer が複数のアベイラビリティーゾーン (AZ) にまたがるかどうかをチェックします。

ロードバランサーは、受信アプリケーショントラフィックを複数のアベイラビリティーゾーンの複数の 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 が設定されていないか、指定された最小数の AZ を満たしていません。

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

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

Connection Draining が有効になっていない Classic Load Balancer をチェックします。

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

7qGXsKIUw

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

Elastic Load Balancing のコンセプト

Application Load Balancer (ALB)、Network Load Balancer (NLB)、Gateway Load Balancer (GWLB) のアベイラビリティーゾーン (AZ) 間でのターゲットグループのターゲットディストリビューションをチェックします。

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

b92b83d667

回復性を向上させるには、ターゲットグループが AZ 全体で同じ数のターゲットを持っていることを確認してください。

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 エンドポイントがない場合は、新たに作成し、そのエンドポイントを経由してサブネットトラフィックをルーティングします。

異なる AZ のサブネット間で同じルートテーブルが関連付けられている場合は、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 ゲートウェイの設定に、アベイラビリティーゾーン (AZ) インディペンデンスが使用されているかどうかを確認します。

NAT ゲートウェイを使用すると、プライベートサブネット内のリソースは、NAT ゲートウェイの IP アドレスを使用することでサブネット外のサービスに安全に接続でき、招待していないインバウンドトラフィックはすべて拒否されます。各 NAT ゲートウェイは指定されたアベイラビリティーゾーン (AZ) 内で動作し、その AZ 内のみで、冗長性を持って構築されています。そのため、特定の AZ にあるリソースは同一の AZ 内の NAT ゲートウェイを使用する必要があります。これにより、NAT ゲートウェイまたはその AZ が停止したとしても、別の AZ にあるリソースに影響が及ばないようになります。

c1dfptbg10

サブネットの AZ を確認し、同じ AZ 内の NAT ゲートウェイ経由でトラフィックをルーティングします。

AZ に NATGW がない場合は、1 つ作成し、それを介してサブネットトラフィックをルーティングします。

異なる AZ のサブネットに同じルートテーブルが関連付けられている場合は、NAT ゲートウェイと同じ AZ にあるサブネットとこのルートテーブルとの関連付けを維持しておき、別の AZ のサブネットについては、そちらの AZ にある NAT ゲートウェイにルーティングして異なるルートテーブルを関連付けてください。

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 を作成し、それを経由してサブネットのトラフィックをルーティングします。

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

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

同一の AWS リージョン リージョンでのデータ転送

データ転送料金について

Availability Zone Independence

High-level steps for implementing AWS Network Firewall

What is AWS Network Firewall?

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

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

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

c2vlfg0gqd

Network Firewall が、本稼働ワークロード用に 2 つ以上の AZ を使用するように設定されていることを確認します。

Configuring your VPC and other components for AWS Network Firewall

What is AWS Network Firewall?

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

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

Example: Appliance in a shared services 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 は、他のゾーンの障害から隔離された独立した場所です。同じリージョンの複数の AZ にロードバランサーを設定すると、ワークロードの可用性が向上します。

c1dfprch09

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

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

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

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

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

cIdfp1js9r

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

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

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

AZ はロケーションとして独立しており、他のゾーンの障害からは隔離されています。サービスを複数の AZ に分散させることで、AZ の障害が影響を及ぼす範囲を限定できます。

c1dfptbg11

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

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

c1dfprch10

黄色: 単一の AZ に VPC エンドポイントがあります。

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

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

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

各サイト間 VPN でアクティブなトンネルの数をチェックします。

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

S45wrEXrLz

VPN 接続用に 2 つのトンネルが設定されていること、およびハードウェアがサポートしている場合は両方ともアクティブであることを確認してください。VPN 接続が不要になった場合には、料金の発生を回避するために、それを削除することができます。詳細については、「AWS Site-to-Site VPN customer gateway devices」または「Delete an AWS Site-to-Site VPN connection and gateway」を参照してください。

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

c1t3k8mqv1

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

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

c1t3k8mqv2

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