AWS Trusted Advisor が提供するベストプラクティス (チェック) は、コスト最適化セキュリティ耐障害性パフォーマンス、およびサービスの制限の 5 つのカテゴリに分類されます。チェックの状態は、ダッシュボードページに色分けして表示されます。

  • 赤: アクションを推奨
  • 黄: 調査を推奨
  • 緑: 問題は検出されませんでした

各チェックでは、推奨するベストプラクティスの詳細な説明、アラートの基準、アクションのガイドライン、トピックに関する有益なリソースを確認できます。

AWS のすべてのお客様は、7 つの Trusted Advisor チェックを利用してセキュリティとパフォーマンスの向上を図ることができます。7 つのチェックには、サービスの制限、S3 バケットのアクセス許可、セキュリティグループ – 制限されない特定のポート、IAM Use、ルートアカウントでの MFA、EBS パブリックスナップショット、および RDS パブリックスナップショットがあります。

Console2

未使用のリソースやアイドル状態のリソースの除外、リザーブドキャパシティの契約など、コストを節約する方法が表示されます。

Amazon Elastic Compute Cloud (Amazon EC2) のコンピューティング使用量の履歴をチェックし、一部前払いリザーブドインスタンスの最適な数を計算します。ここで推奨される数は、一括請求 (コンソリデーティッドビリング) アカウントすべての、直前の暦月の時間単位の使用量に基づいています。推奨される数の計算方法に関する詳細は、Trusted Advisor に関するよくある質問の、「リザーブドインスタンス最適化チェックに関する質問」 をご覧ください。

リザーブドインスタンスを使用すれば、低額の 1 回限りの予約金を支払うことによって、そのインスタンスの一時間当たりの使用料金が大幅に割り引かれます。コストを最小化するため、まず請求システムによりリザーブドインスタンス使用料が自動的に適用されます。

直近 14 日間のいずれかの時間に実行した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをチェックし、1 日あたりの CPU 使用率が 10% 以下、およびネットワーク I/O が 5 MB 以下の日が 4 日以上あった場合は警告します。インスタンスを実行すると、一時間当たりの使用料が発生します。一部のシナリオでは低稼働率になるよう設計されている場合がありますが、多くの場合、インスタンスの数と規模を管理することによりコストを削減できます。

オンデマンドインスタンスの現在の使用料と、インスタンスの稼働率が低いと予想される日数を使用して、月々の削減額を見積もることができます。リザーブドインスタンスやスポットインスタンスを使用した場合や、インスタンスが 1 日中実行されているわけではない場合、実際の削減額は異なります。毎日の稼働率データを入手するには、このチェックのレポートをダウンロードしてください。

Elastic Load Balancing の設定をチェックし、アクティブに使用されていないロードバランサーがないか確認します。設定されているすべてのロードバランサーには使用料金が発生します。ロードバランサーに関連するバックエンドインスタンスがない場合、またはネットワークトラフィックが著しく制限されている場合、ロードバランサーは効果的に使用されていません。

Amazon Elastic Block Store (Amazon EBS) ボリュームの設定を確認し、ボリュームが過少利用と思われる場合は警告します。ボリュームが作成されると課金が開始されます。ボリュームがアタッチされていない状態で残っている場合や、一定期間に行われた書き込み操作が非常に少ない場合 (ブートボリュームを除く)、そのボリュームは使用されていない可能性があります。

実行中の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに関連付けられていない Elastic IP アドレス (EIP) がないかチェックします。EIP は、動的クラウドコンピューティングのために考案された、静的 IP アドレスです。従来の静的 IP アドレスとは異なり、EIP はパブリック IP アドレスをアカウント内の別のインスタンスに再マッピングすることにより、インスタンスやアベイラビリティーゾーンの障害をマスクできます。実行中のインスタンスに関連付けられていない EIP には、わずかな使用料しか課金されません。

Amazon Relational Database Service (Amazon RDS) の設定をチェックし、アイドル状態だと思われる DB インスタンスがないか確認します。DB インスタンスへの接続が長期間にわたって行われていない場合は、コストを削減するためにインスタンスを削除できます。そのインスタンスのデータに関して永続的ストレージが必要な場合は、DB スナップショットを作成して保管するなど、より低コストの方法を使用できます。手動で作成された DB スナップショットは、削除するまで維持されます。

非効率な設定が行われている Amazon Route 53 レイテンシーレコードセットがないかチェックします。ネットワークレイテンシーが最も低いリージョンに Amazon Route 53 がクエリをルーティングするよう許可するには、異なるリージョンの特定のドメイン名 (example.com など) に対するレイテンシーリソースレコードセットを作成する必要があります。あるドメイン名に対してレイテンシーリソースレコードセットを 1 つしか作成しない場合、すべてのクエリは 1 つのリージョンにルーティングされ、メリットがなくてもレイテンシーベースのルーティングのための追加料金を支払うことになります。 

今後 30 日以内に失効する予定の、または過去 30 日間に失効した Amazon EC2 リザーブドインスタンスがないかチェックします。リザーブドインスタンスは自動的に更新されません。予約でカバーされている EC2 インスタンスを引き続き中断なく使用できますが、オンデマンド料金が適用されます。新しいリザーブドインスタンスには期限切れのインスタンスと同じパラメータを使用できます。あるいは、異なるパラメータのリザーブドインスタンスを購入することもできます。
同じインスタンスタイプの場合、オンデマンドとリザーブドインスタンスの料金の差が、1 か月に削減できる額の見積もりとして表示されます。

使用率が低いように見えるクラスターがないか、Amazon Redshift の設定をチェックします。Amazon Redshift クラスターへの接続が長期にわたって行われていない場合や、CPU 使用率が低い場合は、クラスターのダウンサイジングやシャットダウン、最終スナップショットの作成など、さらに低価格のオプションを利用できます。最終のスナップショットは、クラスターを削除した後でも残ります。

足りない点を補い、各種の AWS セキュリティ機能を有効化し、アクセス許可を確認して、アプリケーションのセキュリティを向上させます。

セキュリティグループをチェックし、特定のポートに無制限アクセスを許可するルール (0.0.0.0/0) がないか確認します。無制限アクセスは、悪意あるアクティビティ (ハッキング、サービス拒否攻撃、データの損失) の可能性を高めます。リスクが最も高いポートには赤いフラグ、それよりもリスクが低いポートには黄色いフラグが付けられます。緑のフラグが付けられたポートは、HTTP や SMTP など無制限アクセスが必要なアプリケーションによって通常使用されるポートです。
無制限アクセスを許可するようセキュリティグループを意図的に設定している場合は、インフラストラクチャを守るために、追加のセキュリティ対策 (IP テーブルなど) を使用することをお勧めします。

セキュリティグループをチェックし、リソースへの無制限アクセスを許可するルールがないか確認します。無制限アクセスは、悪意あるアクティビティ (ハッキング、サービス拒否攻撃、データの損失) の可能性を高めます。

AWS Identity and Access Management (IAM) の使用状況をチェックします。IAM を使用して AWS のユーザー、グループ、役割を作成したり、AWS リソースへのコントロールアクセス許可を使用したりすることができます。

Amazon Simple Storage Service (Amazon S3) にオープンアクセス許可を持つバケットがないかチェックします。「リスト」 アクセスを全員に許可するようにバケットのアクセス許可が設定されていると、予想より多くの料金が発生することがあります。具体的には、意図しないユーザーがバケット内のオブジェクトのリストを取得する頻度が高い場合です。「アップロード/削除」 アクセスを全員に許可するようにバケットのアクセス許可が設定されていると、セキュリティ脆弱性の原因となることがあります。だれでもバケット内のアイテムの追加、変更、削除ができるからです。このチェックで、明示的なバケットアクセス許可、およびバケットアクセス許可に優先する可能性がある関連のバケットポリシーを調べます。

ルートアカウントをチェックし、Multi-Factor Authentication (MFA) が有効になっていない場合は警告します。セキュリティを強化するため、MFA を使用してアカウントを保護することをお勧めします。MFA を使用すると、AWS コンソールや関連するウェブサイトとやりとりする際に、ユーザーが MFA ハードウェアや仮想デバイスから一意の認証コードを入力することが必要になります。

アカウントのパスワードポリシーをチェックし、パスワードポリシーが有効でない場合や、パスワードコンテンツ要件が有効にされていない場合は警告します。パスワードコンテンツ要件では、強制的に強力なユーザーパスワードを作成させることにより、AWS 環境の全体的なセキュリティを強化します。パスワードポリシーを作成または変更すると、その変更内容は新しいユーザーに即時に適用されますが、既存のユーザーはパスワード変更を要求されません。

Amazon Relational Database Service (Amazon RDS) のセキュリティグループ設定をチェックし、セキュリティグループのルールがデータベースに過剰なアクセス権を与えている可能性がある場合に警告します。セキュリティグループのルールの設定で、特定の Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループまたは IP アドレスからのアクセスを許可するよう設定することをお勧めします。

AWS CloudTrail の使用状況をチェックします。CloudTrail は、アカウントで実行される AWS API コールに関する情報を記録することにより、AWS アカウントのアクティビティの可視性を高めます。このログを使用すると、例えば、特定のユーザーがある一定の期間に実行したアクションや、ある一定の期間に特定のリソースについてアクションを実行したユーザーなどを特定できます。CloudTrail はログファイルを Amazon Simple Storage Service (Amazon S3) バケットに配信するため、CloudTrail にはバケットへの書き込み許可が必要です。

各 MX リソースレコードセットについて SPF リソースレコードセットをチェックします。SPF (Sender Policy Framework) レコードは、お使いのドメインへの E メール送信を許可されたサーバーの一覧を発行します。これにより E メールアドレスのスプーフィングが検出されるため、スパムを減らすのに役立ちます。

暗号化通信に推奨のセキュリティ設定を使用しないリスナーを用いて、ロードバランサーをチェックします。AWS では、セキュアなプロトコル (HTTPS または SSL)、最新のセキュリティポリシー、セキュアな暗号化およびプロトコルの使用を推奨しています。フロントエンド接続 (クライアントからロードバランサー) にセキュアなプロトコルを使用すると、クライアントとロードバランサーの間でリクエストが暗号化され、セキュリティが強化されます。Elastic Load Balancing で提供される事前定義されたセキュリティポリシーでは、AWS セキュリティのベストプラクティスに準拠する暗号化およびプロトコルを使用できます。事前定義されたポリシーの新しいバージョンは、新しい設定が利用可能になると同時にリリースされます。

ロードバランサーに設定されているセキュリティグループがあるか、またはセキュリティグループがロードバランサーに設定されていないポートへのアクセスを許可しているかどうかをチェックします。ロードバランサーに関連付けられたセキュリティグループが削除されると、そのロードバランサーは正常に動作しなくなります。セキュリティグループがアクセスを許可したポートにロードバランサーが設定されていない場合、データの損失または悪意のある攻撃のリスクが高まります。

IAM 証明書ストア内にある CloudFront 代替ドメイン名の SSL 証明書をチェックします。証明書の有効期限が切れた、有効期限が間もなく切れる、古い暗号化を使用している、またはディストリビューション用に正しく設定されていない場合に、アラートを通知します。代替ドメイン名のカスタム証明書が期限切れになると、CloudFront のコンテンツを表示するブラウザに、ウェブサイトのセキュリティに関する警告メッセージが出力される可能性があります。SHA-1 ハッシュアルゴリズムを使用して暗号化される証明書は、Chrome や Firefox などのウェブブラウザで非推奨になっています。証明書内のすべてのドメイン名が、オリジンドメイン名にも、ビューワーのリクエストのホストヘッダーにあるドメイン名にも一致しない場合、CloudFront は HTTP ステータスコード 502 (不正なゲートウェイ) をユーザーに返します。

有効期限が切れた、有効期限が間もなく切れる、または古い暗号化を使用している SSL 証明書がないか、オリジンサーバーをチェックします。証明書の期限が切れると、CloudFront はコンテンツのリクエストに HTTP ステータスコード 502 (不正なゲートウェイ) で応答します。SHA-1 ハッシュアルゴリズムを使用して暗号化された証明書は、Chrome や Firefox などのウェブブラウザで非推奨になっています。

アクティブな IAM アクセスキーのうち、過去 90 日間更新されていないものがないかチェックします。アクセスキーを定期的に更新することで、セキュリティを侵害されたキーが知らない間にリソースへのアクセスに使用される可能性が小さくなります。このチェックでは、アクセスキーが作成された日時または最後にアクティブになった日時が最新の更新日時となります。アクセスキーの番号と日付は、最新の IAM 認証情報レポートに含まれている access_key_1_last_rotated および access_key_2_last_rotated の情報から得られます。

一般的なコードリポジトリをチェックして、公開されているアクセスキーがないか、アクセスキーの漏洩が原因として疑われる不規則な Amazon Elastic Compute Cloud (Amazon EC2) の使用がないか確認します。アクセスキーは、アクセスキー ID とそれに対応するシークレットアクセスキーから構成されます。アクセスキーが公開されていると、お客様のアカウントおよび他のユーザーにセキュリティリスクがもたらされます。その結果、許可されていないアクティビティや不正使用により法外な料金の請求が生じたり、AWS カスタマーアグリーメントに違反したりする可能性があります。アクセスキーが公開されている場合は、アカウントを保護するためのアクションを即時に実行してください。法外な料金の請求からアカウントを保護するために、AWS は一部の AWS リソースの作成機能を一時的に制限します。この制限でアカウントのセキュリティは確保されません。請求の対象となり得る無断使用を部分的に制限するだけです。注意: このチェックによって、公開されたアクセスキーまたはセキュリティ侵害された EC2 インスタンスを確実に識別できるわけではありません。アクセスキーおよび AWS リソースの安全とセキュリティに関する最終的な責任は、お客様にあります。

Amazon Elastic Block Store (Amazon EBS) ボリュームスナップショットのアクセス許可設定をチェックし、スナップショットが公開に設定されている場合は通知します。スナップショットを公開に設定するときは、スナップショットのすべてのデータにすべての AWS アカウントとユーザーアクセスを付与します。スナップショットを特定のユーザーまたはアカウントと共有する場合は、そのスナップショットを非公開に設定し、その上でスナップショットデータを共有するユーザーまたはアカウントを指定します。

Amazon Relational Database Service (Amazon RDS) DB スナップショットのアクセス許可設定をチェックし、スナップショットが公開に設定されている場合は通知します。スナップショットを公開に設定するときは、スナップショットのすべてのデータにすべての AWS アカウントとユーザーアクセスを付与します。スナップショットを特定のユーザーまたはアカウントと共有する場合は、そのスナップショットを非公開に設定し、その上でスナップショットデータを共有するユーザーまたはアカウントを指定します。

自動スケーリング、ヘルスチェック、マルチ AZ、バックアップ機能を使用して、AWS アプリケーションのアベイラビリティーと冗長性を高めます。

Amazon Elastic Block Store (Amazon EBS) の使用可能または使用中のボリュームについて、スナップショットの使用年数をチェックします。Amazon EBS Volumes はレプリケートされますが、レプリケートが失敗することもあります。スナップショットは耐久性のあるストレージとして、またポイントインタイムリカバリを目的として、Amazon Simple Storage Service (Amazon S3) に保持されます。

あるリージョンのアベイラビリティーゾーン全体への Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのディストリビューション状況をチェックします。アベイラビリティーゾーンとは、それぞれ独立したロケーションであり、他のアベイラビリティーゾーンで発生した障害の影響を受けないように設計されています。同一リージョン内の他のアベイラビリティーゾーンへは、低コスト、低レイテンシーでネットワーク接続できるようになっています。同じリージョン内の複数のアベイラビリティーゾーンでインスタンスを起動することによって、単一障害点からアプリケーションを保護できます。

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

各 VPN についてアクティブなトンネルの数をチェックします。AWS エンドポイントでの停電や計画されたデバイスメンテナンスに備えて冗長性を確保するため、各 VPN には常に 2 つのトンネルを設定する必要があります。一部のハードウェアでは、一度に 1 つのトンネルしかアクティブにできません (Amazon Virtual Private Cloud Network Administrator Guide を参照してください)。VPN にアクティブなトンネルがない場合でも、VPN 料金が適用される場合があります。

起動設定や Auto Scaling グループに関連したリソースのアベイラビリティーをチェックします。使用不可能なリソースを指す Auto Scaling グループは、新しい Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動できません。適切に設定されている場合、Auto Scaling はデマンドスパイク時に Amazon EC2 インスタンス数をシームレスに増大させ、需要が減ると自動的にインスタンス数を減少させます。使用不可能なリソースを指す Auto Scaling グループと起動設定は、意図通りに作動しません。

Amazon RDS DB インスタンスの自動バックアップをチェックします。デフォルトでは、バックアップの保持期間は 1 日に設定されています。バックアップにより、予期しないデータ損失のリスクが低下し、ポイントインタイムリカバリが可能になります。

単一アベイラビリティーゾーンにデプロイされた DB インスタンスをチェックします。マルチ AZ 配置は、異なるアベイラビリティーゾーンでのスタンバイインスタンスに同期レプリケートを行うことにより、データベースのアベイラビリティーを強化します。計画されたデータベースメンテナンスや、DB インスタンスまたはアベイラビリティーゾーンの障害が発生した場合、Amazon RDS によって自動的にスタンバイインスタンスへのフェイルオーバーが行われ、管理者の介入なしにすばやくデータベース運用を再開できます。Amazon RDS は Microsoft SQL Server 用のマルチ AZ 配置をサポートしていないため、このチェックでは SQL Server のインスタンスを調べることはできません。

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

Amazon Simple Storage Service (Amazon S3) バケットのロギング設定をチェックします。サーバーアクセスロギングが有効な場合、詳細なアクセスログが選択したバケットに毎時間配信されます。アクセスログレコードには、リクエストタイプ、リクエストで指定されたリソース、リクエストが処理された時刻や日付など、リクエストの詳細が含まれます。デフォルトでは、バケットロギングが有効ではありません。セキュリティ監査を実施する場合や、ユーザーおよび使用パターンに関する詳細を確認する場合は、ロギングを有効にする必要があります。

Amazon Route 53 ホストゾーンをチェックして、ドメインのレジストラまたは DNS が正しい Route 53 ネームサーバーを使用していないホストゾーンがないか確認します。ホストゾーンを作成すると、Route 53 によって 4 つのネームサーバーのデリゲーションセットが割り当てられます。これらのサーバーの名前は、ns-###.awsdns-##.com、.net、.org、または .co.uk で、### と ## は通常、別の数を表します。Route 53 がドメインの DNS クエリをルーティングできるようにするには、レジストラのネームサーバーの設定を更新して、レジストラによって割り当てられたネームサーバーを削除し、この Route 53 のデリゲーションセットに含まれる 4 つのネームサーバーをすべて追加する必要があります。最大限のアベイラビリティーを得るには、4 つの Route 53 ネームサーバーをすべて追加しなければなりません。

lower time-to-live (TTL) 値を小さくすることでメリットが得られるリソースレコードセットがないか、チェックします。TTL は、DNS リゾルバ内でリソースレコードセットがキャッシュされる秒数です。TTL の設定を長くすると、更新された DNS レコードを DNS リゾルバが要求するまでの時間が長くなり、トラフィックのルーティングで不要な遅延が生じる可能性があります (例えば、DNS フェイルオーバーがエンドポイントの 1 つについて障害を検出し、反応する場合)。

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

削除されたヘルスチェックに関連するリソースレコードセットがないかチェックします。Amazon Route 53 は、1 つまたはそれ以上のリソースレコードセットに関連付けられたヘルスチェックの削除を防止することはありません。関連付けられたリソースレコードセットを更新せずにヘルスチェックを削除すると、DNS フェイルオーバー設定の DNS クエリのルーティングが意図通りに作動しません。この場合、DNS フェイルオーバー設定の DNS クエリのルーティングが影響を受けます。

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

クロスゾーン負荷分散が無効になっているロードバランサーがないかチェックします。クロスゾーン負荷分散は、インスタンスが存在するアベイラビリティーゾーンに関係なく、すべてのバックエンドインスタンスに均等にリクエストを分散します。クライアントが DNS 情報を誤ってキャッシュした場合や、各アベイラビリティーゾーン内のインスタンス数に偏りがある場合 (メンテナンスのためにインスタンスをいくつか削除した場合など) は、不均等なトラフィックの分散をクロスゾーン負荷分散が抑制します。クロスゾーン負荷分散を使用すると、複数のアベイラビリティーゾーン間でのアプリケーションのデプロイや管理が容易になります。

バージョニングが有効化されていない、または一時停止している Amazon Simple Storage Service バケットがないか、チェックします。バージョニングが有効であれば、意図せぬユーザー操作からもアプリケーションの障害からも簡単に回復できます。バージョニングを使用すれば、バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを保存、取得、復元できます。ライフサイクルルールを使用して、オブジェクトを自動的にGlacier ストレージクラスにアーカイブするか、指定した期間が経過した後に削除することによって、オブジェクトのすべてのバージョン、およびオブジェクトの関連コストを管理できます。オブジェクトの削除時またはバケットの設定変更時に Multi-Factor Authentication (MFA) を必要とするよう、設定することもできます。

1 つの AWS Direct Connect 接続しか存在しないリージョンがないかチェックします。AWS リソースへの接続には、2 つの Direct Connect 接続を常に設定しておく必要があります。それによって、1 台のデバイスが利用不可になった場合に冗長性を提供します。

AWS Direct Connect 接続が 1 つ以上存在し、AWS Direct Connect ロケーションが 1 つしか存在しないリージョンがないかチェックします。AWS リソースへの接続には、異なる Direct Connect ロケーションへの Direct Connect 接続を常に設定しておく必要があります。それによって、1 つのロケーションが利用不可になった場合に冗長性を提供します。

仮想プライベートゲートウェイのうち、複数の AWS Direct Connect 接続が設定されていない AWS Direct Connect 仮想インターフェイス (VIF) を持つものがないかチェックします。仮想プライベートゲートウェイへの接続には、複数の仮想インターフェイスを複数の Direct Connect 接続とロケーションにまたがって設定しておく必要があります。それによって、1 台のデバイスまたは 1 つのロケーションが利用不可になった場合に冗長性を提供します。

Amazon Aurora DB クラスターに公開インスタンスと非公開インスタンスの両方があるケースをチェックします。プライマリインスタンスに障害が発生したときに、レプリカをプライマリインスタンスに昇格させることができます。 そのレプリカが非公開の場合、パブリックアクセスしか持たないユーザーはフェイルオーバー後にデータベースに接続できなくなります。ベストプラクティスは、クラスター内のすべての DB インスタンスに同じアクセシビリティを付与することです。

Amazon EC2 Windows インスタンスの EC2Config サービスをチェックし、EC2Config エージェントが古くなっている、あるいは正しく設定されていない場合は、アラートを表示します。最新バージョンの EC2Config を使用すれば、PV ドライバーチェックなどのエンドポイントソフトウェア管理を有効化および最適化して、最もセキュアで信頼性の高いエンドポイントソフトウェアの最新情報を常に把握できます。

注意: このチェックでは、バージニア北部 (us-east-1)、北カリフォルニア (us-west-1)、オレゴン (us-west-2)、アイルランド (eu-west-1)、サンパウロ (sa-east-1)、東京 (ap-northeast-1)、シンガポール (ap-southeast-1)、およびシドニー (ap-southeast-2) といったリージョンでの EC2 インスタンスの情報が表示されます。

Amazon EC2 Windows インスタンスの PV ドライバーのバージョンをチェックし、ドライバーが最新でない場合はアラートを表示します。最新の PV ドライバーを使用することで、ドライバーのパフォーマンスを最適化し、ランタイムの問題とセキュリティのリスクを最小限に抑えます。

注意: このチェックでは、バージニア北部 (us-east-1)、北カリフォルニア (us-west-1)、オレゴン (us-west-2)、アイルランド (eu-west-1)、サンパウロ (sa-east-1)、東京 (ap-northeast-1)、シンガポール (ap-southeast-1)、およびシドニー (ap-southeast-2) といったリージョンでの EC2 インスタンスの情報が表示されます。

サービスの制限を確認し、プロビジョンドスループットを活用し、利用率が高すぎるインスタンスをモニタリイングして、サービスのパフォーマンスを向上させます。

直近 14 日間のいずれかの時間に実行した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをチェックし、1 日あたりの CPU 使用率が 90% を超えた日が 4 日以上あった場合は警告します。稼働率が定常的に高いということは、パフォーマンスが最適化され安定していることを示す場合もありますが、アプリケーションのリソースが十分でないことを示す場合もあります。毎日の CPU 使用率データを入手するには、このチェックのレポートをダウンロードしてください。

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされているものの、Amazon EBS 用に最適化されていないプロビジョンド IOPS (SSD) ボリュームがないかチェックします。Amazon Elastic Block Store (Amazon EBS) のプロビジョンド IOPS ボリュームは、EBS 最適化されたインスタンスにアタッチされた場合にのみ、期待通りのパフォーマンスを発揮するように設計されています。

それぞれの Amazon Elastic Compute Cloud (EC2) セキュリティグループのルール数が多過ぎないかチェックします。セキュリティグループのルール数が多いと、パフォーマンスが低下する場合があります。
詳細については、Amazon EC2 セキュリティグループを参照してください。

Amazon Elastic Compute Cloud (EC2) インスタンスのセキュリティグループのルール数が多いかチェックします。インスタンスのルールの数が多いと、パフォーマンスが低下する場合があります。

DNS クエリを AWS リソースにルーティングするリソースレコードセットがないか、チェックします。あれば、エイリアスリソースレコードセットに変更できます。エイリアスリソースレコードセットは、Amazon Route 53 の特別なレコードタイプの 1 つで、DNS クエリを AWS リソース (例: Elastic Load Balancing ロードバランサー、Amazon S3 バケット)、または別の Route 53 リソースレコードセットにルーティングします。エイリアスリソースレコードセットを使用すると、Route 53 は DNS クエリを AWS リソースに無料でルーティングします。

使用率が高過ぎる可能性のある Amazon Elastic Block Store (EBS) マグネティックボリュームをチェックします。設定を効率的にするなら、メリットがある場合があります。マグネティックボリュームは中程度から大量の I/O 要件を持つアプリケーション用に設計されているため、IOPS レートは保証されません。標準ボリュームの平均パフォーマンスは約 100 IOPS であり、ベストエフォートで数百 IOPS のバーストも可能です。定常的に高い IOPS の場合、プロビジョンド IOPS (SSD) ボリュームを使用できます。バースト性のある IOPS の場合、汎用 (SSD) ボリュームを使用できます。

AWS のグローバルコンテンツ配信サービスである Amazon CloudFront を使用して、Amazon Simple Storage Service (Amazon S3) バケットからのデータ転送を高速化できないかチェックします。コンテンツを配信するよう Amazon CloudFront を設定する際、コンテンツに関するリクエストは自動的に最も近いエッジロケーションにルーティングされ、コンテンツはそこでキャッシュ化されます。これにより、ユーザーは可能な限り最適なパフォーマンスで配信を受けられます。バケットに保存されたデータへのデータ転送率が高いということは、Amazon CloudFront を使用してデータを配信するならメリットがあるということを示しています。

CloudFront が現在クライアントから受信してオリジンサーバーに転送する HTTP リクエストヘッダーをチェックします。Date や User-Agent など、一部のヘッダーでは、キャッシュヒット率 (CloudFront エッジキャッシュから提供されるリクエストの比率) が大幅に下がります。これにより、CloudFront からオリジンに転送するリクエストの数が多くなるため、オリジンにかかる負荷が大きくなり、パフォーマンスが低下します。

Amazon EBS Volumes のうち、パフォーマンスが アタッチ先の Amazon EC2 インスタンスの最大スループット能力の影響を受ける可能性のあるものがないかチェックします。パフォーマンスを最適化するには、EC2 インスタンスの最大スループットが アタッチ済みの EBS ボリュームの最大スループットの合計よりも確実に大きくなるようにする必要があります。

DNS 設定に誤りのある代替ドメイン名がないか、CloudFront ディストリビューションをチェックします。CloudFront ディストリビューションに代替ドメイン名が含まれる場合、そのドメインの DNS 設定により、DNS クエリをディストリビューションにルーティングする必要があります。

サービスの使用量がサービスの制限の 80% を超えていないか、チェックします。この値はスナップショットに基づいているため、現時点での使用量とは異なる場合があります。上限と使用率のデータは、変化が反映されるまでに最大 24 時間かかります。チェックされるサービスの制限の詳細については、サービスの制限のチェックに関する質問を参照してください。