耐障害性

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 My SQLクラスターのバックトラックが有効になっていません。

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

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

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

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

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

xuy7H1avtl

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

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

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

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

詳細については、「オ 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 では、テーブルの増分バックアップが維持されます。

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

c18d2gz138

AWS Config Managed Rule: dynamodb-pitr-enabled

黄： Point-in-time DynamoDB テーブルの復旧は有効になっていません。

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

詳細については、Point-in-time 「復旧: の仕組み」を参照してください。

Point-in-time DynamoDB のリカバリ

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

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

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ボリュームがレプリケートされていても、障害が発生する可能性があります。スナップショットは、耐久性のあるストレージと point-in-timeリカバリのために toAmazon 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 グループの負荷分散) を参照してください。

Amazon EC2 Auto Scaling ユーザーガイド

インスタンスの詳細 yourAmazon 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 分間隔）。

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

c1dvkm4z6b

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

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

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

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

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

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

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

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

c1z7dfpz01

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

Amazon ECSの容量と可用性

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

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

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

c1z7dfpz02

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

Amazon ECSタスク配置戦略

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

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

c1dfprch01

One Zone ストレージクラスを使用する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 Backup and Restore。 AWS Backup

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

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

ECHdfsQ402

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

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

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

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

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

c18d2gz178

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

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

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

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

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

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

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

MDBdfsQ401

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

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

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

Cmsvnj8vf1

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

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

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

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

デフォルトでは、バックアップは 1 日の保持期間で有効になっています。バックアップにより、予期しないデータ損失のリスクが軽減され、復旧が可能になります 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 クラスターは、クラスターの作成RDSAPI時に AWS Management Console、 AWS CLI、、または Amazon を使用して作成できます。また、既存の 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ストレージの自動スケーリングはダウンタイムなしでストレージ容量を自動的にスケーリングします。

c1qf5bt013

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

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

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

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

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

c1qf5bt019

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

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

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

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

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

Cmsvnj8db3

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

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

Cmsvnj8db2

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

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

c1qf5bt023

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

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

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

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

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

c1qf5bt036

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

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

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

詳細については、「MySQL ドキュメントウェブサイト」の「My 8.0.26 (2021-07-20, General Availability)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 My のパラメータを設定するためのベストプラクティスSQL、パート 1: パフォーマンスに関連するパラメータ」を参照してください。

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

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

c1qf5bt034

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

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

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

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

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

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

f2iK5R6Dep

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

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

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

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

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

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

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

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

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

DB リソースの自動バックアップは無効になっています。自動バックアップにより point-in-time、DB インスタンスのリカバリが可能になります。

c1qf5bt001

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

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

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

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

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

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

c1qf5bt031

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

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

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

詳細については、「Amazon RDS for My のパラメータを設定するベストプラクティスSQL」、パート 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 DB クラスターを作成するときに、マルチ AZ RDS DB クラスターのデプロイをオンにします。

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

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

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

Amazon RDS Multi-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 が運用上安全なレベルを超える原因はいくつかあります。例えば、最近の が原因である可能性があります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 ることがあります。チームは、どの根本原因がデータベース ReplicaLag にとって高い原因となっている可能性があるかを調査し、レプリカのデータ継続性が要件と一致するように、データベースインスタンスタイプやその他のワークロードの特性を変更する可能性があります。

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

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

c1qf5bt026

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

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

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

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

自動スナップショットが 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 のヘルスチェックとフェイルオーバー

（ time-to-liveTTL) 値が低いことがメリットとなるリソースレコードセットをチェックします。

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

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

C056F80cR3

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

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

ドメインレジストラまたは正しい Route 53 ネームサーバーを使用してDNSいない 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 削除には、バケットのバージョニングステータスが変更された場合、またはオブジェクトのバージョンが削除された場合に追加の認証が必要です。ユーザーは、承認された認証デバイスから認証情報とコードを入力する必要があります。詳細については、MFA「 の削除」を参照してください。

バケットの使用

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)

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

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

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」(起動設定の作成) を参照してください。

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

hc0dfs7601

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

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

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

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

c1dfpnchv2

赤: Direct Connect ゲートウェイまたは仮想プライベートゲートウェイは、1 つの 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 「耐障害性に関する推奨事項」を参照してください。

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 関数に、非同期呼び出し用に On Failure イベント送信先または Dead Letter Queue (DLQ) が設定されていることをチェックし、失敗した呼び出しからのレコードを宛先にルーティングして、さらなる調査または処理を行うことができます。

c1dfprch05

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

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

L4dfs2Q4C6

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

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

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

c243hjzrhn

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

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

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

RH23stmM04

赤: AppComponent 回復できません。

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

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

AWS Resilience Hub の概念

AWS 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。

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

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

c18d2gz123

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

黄: A Site-to-SiteVPNには少なくとも 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」を参照してください。

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

接続ドレインが有効になっていず、Amazon EC2インスタンスを Classic ロードバランサーから登録解除すると、Classic ロードバランサーはそのインスタンスへのトラフィックのルーティングを停止し、接続を閉じます。接続ドレイニングを有効にすると、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 ()ALB、Gateway Load Balancer () のアベイラビリティーゾーン (NLB) 間のターゲットグループのターゲット分散をチェックしますGWLB。

このチェックには、1 つの AZ で設定され、入力量が最も多い AZ と少ない AZ のターゲット数の差が 1 以下のロードバランサーは含まれません。

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 ゲートウェイがアベイラビリティーゾーン (AZ) の独立性で設定されているかどうかを確認します。

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

c1dfptbg10

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

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

異なる のサブネット間で同じルートテーブルが関連付けられている場合はAZs、このルートテーブルを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 のネットワークファイアウォールを使用し、クロス 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 - バルクヘッドアーキテクチャを使用して影響の範囲を制限する

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

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

c2vlfg0gqd

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

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は単一の 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 アーキテクチャの実装を検討してください。

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

c1dfprch10

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

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

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

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

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

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

S45wrEXrLz

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

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

c1t3k8mqv1

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

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

c1t3k8mqv2

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