This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

AWS のベスト プラクティス ポリシー

この記事では、VMware Aria Cost の AWS アカウントのベスト プラクティス ポリシーについて説明します。

財務ガバナンス

問題のあるサービスの識別

1 か月あたりの各 AWS サービスのコストをベンチマーキングすると、コストをより詳細に制御できます。多くの資産を所有している場合、このタスクに大きな負担がかかることがあります。したがって、ベスト プラクティスは、例外によって管理することです。まず、20% 以上変更されたサービスを特定します。

サンプルのサービス コスト増加ポリシー:このポリシーでは、AWS 請求の [総コスト] が指定の時間間隔内に一定の割合を超えた場合、関係者にアラートを送信します。

バリアント:

  • このポリシーを特定の AWS サービス タイプ(CloudFront コストなど)に制限します。
  • パースペクティブを利用します。たとえば、本番環境の [輸送コスト] が 1 か月で 20% 増加した場合にアラートを送信し、いずれかの部門の [総コスト] が 20% 増加した場合にアラートを送信します。
  • CloudFormation コストが 1 か月で 10% 以上増加している場合は、この増加を特定して上昇傾向が続かないようにします。

問題のあるグループの識別

クラウドのコストが上昇している場合、問題のある機能ビジネス グループによるコストの差異をプロアクティブに特定することが重要です。

  • あらゆる環境で、月額コストは前月と比較して 10% 以上増加すると予測されています。
  • あらゆる環境で、実際の月額コストは前月と比較して 10% 以上増加しています。
  • あらゆる部門で、予測される月額コストは予算を 5% 以上超過します。
  • あらゆる部門で、実際の月額コストは予算を 5% 以上超過しています。

サンプルのグループ コスト増加ポリシー:このポリシーは、開発環境のコストが特定の ($) 金額を超えた場合に関係者に警告します。このポリシーを使用して、1 つのサービスまたはすべてのサービスの月額コストを制御または監視します。

予算とコストの傾向の監視

予算を設定し、その予算の参照によって毎月の支出がどのように追跡されているかを比較します。VMware Aria Cost の顧客は、ポリシーを構成して、MTD の実際のコストが予算内である場合、または MTD の予測コストが予算を超えると予想される場合を評価できます。

例:MTD コストが予算の 100% を超える場合、E メール通知を送信します。

サンプルの予算超過ポリシー:このポリシーは、1 か月の予測コストが特定のしきい値によって最初に指定された予算を超えると予想される場合に関係者に警告します。これを使用して、割り当てられた予算と比較した実際のコストを追跡します。

バリアント

  • パースペクティブを使用します。本番環境の支出で予測される MTD が 100% より大きい場合、予算の所有者に E メール通知が送信されます。
  • MTD の実際のコストと予算を比較します。

コストの傾向に関するその他のサンプル ポリシー

  • 1 週間で合計コストが 40% を超えて増加した場合は、通知を送信します。
  • S3 の総コストが 1 日で 10% を超えると、通知が送信されます。
  • AWS 資産で予測される総コストが、以前の請求期間のコストを超過した場合。
  • AWS 資産の総コストは以前の請求期間のコストを超過しています。

予期しないコスト増加

クラウド環境の全体的なコストが急増した場合、より大きな問題の指標となる可能性があります。アノマリ検知によって、コストや使用量の増加または急激な減少を把握し、適切な判断を行います。アノマリのコスト影響が指定されたしきい値を超えた場合にアラートを表示するポリシーを設定することができます。アラートを作成するには、ポリシーの作成時にリソース タイプとして AWS アノマリ を選択します。詳細については、「コスト アノマリ検知」を参照してください。

コストの最適化

リザーブド インスタンスの購入の特定

リザーブド インスタンス (RI) を購入すると、インスタンスの 1 時間あたりの価格について大幅な割引を受けることができ、選択型価格設定を最大限に活用できます。EC2 コンピューティングの使用履歴に基づいて、オンデマンドで実行されている時間が 50% を超えるインスタンスを特定し、それらのインスタンスの予約済みキャパシティの購入を検討する必要があります。当然ながら、RI を購入する前に、必ずインスタンスを適切にサイジングする必要があります。

例:インスタンスの MTD オンデマンド時間 > 500 時間

サンプルの特定された RI 購入ポリシー:このポリシーでは、過去 1 か月間のオンデマンドの使用率を監視して、1 つ以上の EC2 インスタンスのリザーブド インスタンスを購入することによって、AWS コストを削減する機会があるかどうかを確認します。

バリアント

  • %Reserved のインスタンスの使用率が少なくとも 1 か月あたり 50% 未満であることを通知します。

リザーブド インスタンスの変更

これらのポリシーを使用して、リザーブド インスタンスのメリットを追跡および最適化できます。ポリシーは、クラウド フットプリントの増加と変化に合わせてこれらのメリットを相互に関連付け、変化するビジネス ニーズに対応するのに役立ちます。

サンプルの RI 変更ポリシー:このポリシーは、変更による節約が一定の金額 ($) を超える場合に、可能な EC2 RI の変更を実行できます。また、このポリシーは、RI の変更が実行されたときに特定のユーザーにアラートを送信します。

バリアント

  • %Reserved のインスタンスの使用率が少なくとも 1 か月あたり 50% 未満であることを通知します。

使用率の低いリザーブド インスタンスの特定

サンプルの低使用率 RI ポリシー:このポリシーは、時間単位の RI の使用率が低い場合に通知します。初回の通知には警告(つまり、RI の使用率が低い時間が MTD で 1 時間を超えている)フラグが付けられますが、2 回目の通知には重大(つまり、RI の使用率が低い時間が MTD で 5 時間を超えている)フラグが付けられます。

サンプルの RI 時間使用率ポリシー:このポリシーは、月単位の浪費コストに基づいて RI の使用率が低いと判断される場合に通知します。アクションを実行する前に、通知のフラグ レベルを高くすることができます。

運用ガバナンス

期限切れのリザーブド インスタンスの特定

次の 60 ~ 90 日以内に有効期限が切れる RI に関する通知を受け取ります。これにより、適正サイジングの分析を実施し、購入する必要がある新しい RI を決定するための十分な時間を確保できるようになります。

サンプルの期限切れ RI に関するポリシー:60 日後に期限切れとなる予約については、高レベルのアラートが発信されます。30 日後に期限切れとなる予約については、重大レベルのアラートが発信されます。

期限切れのコスト削減プランの特定

AWS コスト削減プランは、ユーザーが 1 年間または 3 年間に、一定量の AWS の利用を 1 時間ごとにコミットする割引メカニズムです。VMware Aria Cost プラットフォームを使用して、期限切れが近いコスト削減プランを追跡するアラートを作成できます。たとえば、コスト削減プランの有効期限の 60 〜 90 日前にアラートを設定できるため、現在のコスト削減プランを置き換えるかどうか、どのように置き換えるかなど、十分な情報に基づいてビジネス上の意思決定を行うことができます。

サンプルの期限切れコスト削減プランに関するポリシー:30 日後に期限切れとなるコスト削減プランについては、高レベルのアラートが発信されます。

ゾンビ インスタンスの特定と終了

これらは、アイドル状態の実行中のインスタンスであり、認識されていないことが多いのですが、コストがかかります。毎日の平均 CPU 使用率が 2 週間連続して 10% 未満で、ネットワーク I/O が 4 日以上 5 MB 未満の状態で実行されているインスタンスを特定します。より詳細なデータが必要な場合は、インスタンス タイプに基づいてインスタンスを分けてください。

例:過去 14 日間の最大 CPU 使用率が 10% 未満の C タイプのインスタンス(コンピューティングの負荷が高い)は、アイドル状態になっている可能性が高いため、終了することをお勧めします。

サンプルのゾンビ インスタンス特定ポリシー:このポリシーは、潜在的なゾンビ EC2 インスタンスを特定します。これは、コンピューティングが最適化されている(C ファミリなど)、またはストレージおよび I/O が最適化されている特定のインスタンス タイプを確認します。このポリシーは、次の 2 つのルールで構成されます。

  • ルール 1:CPU の平均使用率が低い C クラスのインスタンス タイプを特定し、それらを停止して、該当するインスタンスの IAM ユーザー(所有者)に通知します。
  • ルール 2:平均読み取り/書き込み操作率が低い HS クラスのインスタンスを特定し、それらを停止して、該当するインスタンスの IAM ユーザーに通知します。

これらの 2 つのルールは別個に評価します。また、VMware Aria Cost のパースペクティブを活用することで、特定の非本番環境に対してこれらのルールを実行できます。

バリアント:ネットワーク トラフィックなどの他のパフォーマンス メトリックを取得するさまざまなルールを追加します。

ゾンビ ボリュームの特定と終了

これらは、インスタンスで起動され、インスタンスの終了後に接続解除されたままになっている EBS ボリュームであり、メモリを消費します。

例:接続されていない状態が 2 週間以上続いているボリュームを特定し、重要なデータが含まれていないことを確認した後に終了します。

サンプルのゾンビ ボリューム特定ポリシー:このポリシーは、接続されているが使用されていない可能性がある EBS ボリュームを特定して終了します。

古いスナップショットの特定と削除

これらは、一定の経過時間のしきい値を超えた古いスナップショットです。古いスナップショットは、法的責任となる可能性があります。

例:6 か月以上経過しているスナップショットを特定し、重要なデータが含まれていないことを確認した後、そのスナップショットを終了します。

サンプルの古いスナップショットを特定するポリシー:6 か月以上経過しているゾンビ EC2 スナップショットが見つかると、このポリシーによって通知が送信されます。

分離された弾性 IP アドレスの解放

Amazon が弾性 IP アドレスについて請求するのは、それらがインスタンスに関連付けられていない場合に限られます。インスタンスが終了したときに、弾性 IP アドレスが解放されず、料金が発生することがあります。

コストの発生を回避するために弾性 IP アドレスを自動的に削除するポリシーを設定する場合、EIP はインスタンスと弾性ネットワーク インターフェイス(ネットワーキングの目的でインスタンスに適用される一種の仮想アダプタ)の両方に接続されていない場合にのみ終了します。1 つのインスタンスは、それぞれが独自の IPv4 EIP アドレスとプライベート IPv4 アドレスを持つ複数の ENI(正確な数はインスタンス タイプとサイズに応じる)を持つことができます。これらの ENI は、インスタンスから自由に削除して、他のインスタンスに接続することができます。

詳細については、AWS のドキュメントの 弾性ネットワーク インターフェイス を参照してください。

ENI があるインスタンスから削除され、別のインスタンスに再割り当てされない場合、EIP は保持されます。EIP に関するレポートを作成すると、この「フローティング」EIP は未接続として表示されます。EIP が実体なしの ENI に接続されている場合、インスタンスから接続が正常に解除されている場合と同様に、コストは発生しません。ただし、レポート作成のためには、フローティング ENI や EIP を使用しないことをお勧めします。

例:実行中のインスタンスに 1 週間以上関連付けられていない EIP を特定して解放します。

サンプルの分離された弾性 IP アドレスの特定と解放ポリシー:このポリシーは、1 週間以上存在する関連付けのない EIP を特定し、通知を送信して EIP を解放します。

インスタンスのスケジューリング(ライトオン/ライトオフ)

特に、本番環境以外では、すべてのインスタンスが 24 時間年中無休で使用されているわけではありません。これらのインスタンスを定期的にシャットダウンして、コストを削減できます。

例:金曜日の午後 7 時に開発環境で EC2 インスタンスを停止し、月曜日の午前 6 時に EC2 インスタンスの展開を開始します。

サンプルのライトオン/ライトオフ ポリシー:週末を通じて開発環境をオフにします。

古い世代のインスタンスの特定

古い世代のインスタンスを最新の世代にアップグレードすることで、コストを削減し、パフォーマンスを向上させることができます。

例:レガシーの AWS インスタンス(T1、M1、C1、CC2、M2、CR1、CG1、HI1、HS1)を特定し、所有者に通知して、アップグレードできるようにします。

古い世代のインスタンスの特定ポリシー:指定された月の実行時間が 1 時間を超える M1 および C1 インスタンス タイプを探し、JIRA 通知を送信します。

パフォーマンス管理

ボリュームの適正サイジング

例:

  • クラウド インフラストラクチャ全体で PIOPS ストレージ コストが 1 週間にわたって 15% 以上変化した場合、通知を受け取ります。
  • 開発グループまたは本番グループの PIOPS ストレージ コストが 1 週間にわたって 15% を超えた場合、重要なアラートを送信します。
  • いずれかのボリューム タイプの週間平均ディスク スループットが 20% 未満の場合、E メール通知を送信します。

サンプルのボリューム適正サイジング ポリシー:すべての EBS ボリュームで 1 週間の平均が 20% 未満の場合に通知します。

EC2 インスタンスの適正サイジング

インスタンスに対するパフォーマンスのしきい値を指定して、使用率の低いインスタンスや、使用率の過剰なインスタンスがないかを監視します。使用率の低いインスタンスはコスト効率を上げるためにダウングレードし、使用率の過剰なインスタンスはパフォーマンスの問題を避けるためにアップグレードする必要があります。

  • 使用率の低下の例:CPU の平均使用率が 20% 未満で、ディスクの平均 I/O が 35% 未満、かつ CPU の最大使用率が 35% に満たない日が 5 日を超える場合は、インスタンスの所有者に通知します。
  • 使用率の過剰の例:毎日の平均 CPU 使用率、メモリ使用率、およびディスクのスループットがいずれも 5 日以上、80% を上回る場合は、E メールで通知します。

資産と構成のガバナンス

タグ コンプライアンス

タグ付けは、適切なビジネス グループの資産を正確にグループ分けするために不可欠な方法です。通知を設定して、組織で定義されている内部タグ付け基準に準拠していない資産を特定します。

例:

  • いずれかの資産でタグ環境が欠落している場合は、通知を送信し、Lambda 関数を実行して、資産にタグを付けます。
  • いずれかの資産でタグが付いていない場合は、所有者にアラートが送られ、インスタンスが停止します

サンプルのベスト プラクティス ポリシー:このポリシーでは、タグなしでプロビジョニングされている新しい AWS 資産をレポートする E メール アラートが送信されます。

非準拠の資産

どの組織にも、推奨されていない、または完全には許可されていない資産のタイプと構成があります。インスタンス タイプ、リージョン、AMI タイプ、OS、ネットワーク タイプのいずれであっても、これらを迅速に識別して修正するための措置を講じることが重要です。

例:

  • リソースが特定の AWS 構成ルールを遵守していない場合
  • インスタンスが同じ月で 1 時間以上実行されている場合。VPC の有効化が VPC で無効の場合
  • インスタンスが同じ月で 1 時間以上実行されている場合。オペレーティング システムが Red Hat Enterprise Linux の場合

サンプルのベスト プラクティス ポリシー:このポリシーは、AWS 構成ルールに準拠していない実行中の EC2 インスタンスを特定します。

セキュリティ管理

デフォルト セキュリティ ポリシー

VMware Aria Cost でのセキュリティ管理ポリシーのベスト プラクティスには、アクセス制御ポリシー、ネットワーク セキュリティ ポリシー、アプリケーション/データ セキュリティ ポリシー、監査証跡ポリシーなどがあります。

AWS セキュリティのベストプラクティスCenter for Internet Security のベスト プラクティス のデフォルト ポリシーは、VMware Aria Cost プラットフォームで利用できます。

check-circle-line exclamation-circle-line close-line
Scroll to top icon