Amazon Web Services ブログ

使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする

業界や業種を問わず、お客様にとってコスト管理は最優先事項の1つです。 EBSボリュームのライフサイクルの可視性が十分でないと、未使用のリソースに対してコストが発生する可能性があります。 AWSはコスト管理のサービスを提供しており、コスト情報へのアクセス、コストの理解、コストの制御、およびコストの最適化を行えるようにしています。

未使用、および管理が行き届いていないAmazon EBSボリュームは、AWS のコストに影響します。 EBSボリュームのライフサイクルは、Amazon EC2 コンピューティングインスタンスから独立して管理可能です。そのため、EBS ボリュームに関連付けられている EC2インスタンスが終了しても、EC2起動時に「終了時に削除」 オプションを選択しない限り、EBS ボリュームは削除されません。 また、開発とテストのサイクルの中でEC2インスタンスの起動停止を繰り返す際、自動的にEBSボリュームを削除する処理がないと、 EBS ボリュームが残る可能性があります。 EC2にアタッチされておらず孤立したEBS ボリュームは、アタッチされていない間も料金が発生します。

この記事では、OpsCenter を活用した自動化プロセスについて説明します。OpsCenter は、AWS Systems Manager の一機能として最近発表されたもので、OpsCenterを使えば、EC2 インスタンスにアタッチされておらず、未使用なEBS ボリュームを識別および管理できるようになります。

概要

まず、Amazon CloudWatch Events を使用して AWS Lambda関数を定期的に呼び出します。 この Lambda 関数は、EBSのAWS CloudTrail イベントを解析し、EC2インスタンスに対してアタッチされておらず、利用可能な EBS ボリュームの運用作業項目（OpsItems）を作成します。

次に、EBSボリュームのスナップショットを自動的に作成する方法、および紐付け方を実演します。 この手順を実施することで未使用のボリュームが認識しやすくなり、AWS Systems Manager Automation を利用して利用されていないEBSボリュームが自動削除され、EC2 インスタンスやその他の AWS リソースの一般的なメンテナンスおよびデプロイタスクが簡素化されます。

Systems Manager によって、AWS のインフラストラクチャを可視化して制御できるため、複数の AWS サービスの運用データを一元的に把握でき、AWS リソース全体の運用タスクを自動化できます。 OpsCenter は、クラウド内でもデータセンター内でも、リソースに影響を与える問題が解決されるまでの平均修復時間 (MTTR) を削減するように設計されています。 また、運用エンジニアや IT プロフェッショナルが、リソースに関連する OpsItems を表示、調査、および解決できる一元的な場所を提供します。 どのようなプロセスが実行され、どのようなワークフローが行われるかを示した図は次のとおりです。

OpsCenterでリソースを管理するワークフローを示した図

OpsCenterでリソースを管理するワークフローを示した図

詳細

Lambda 関数を定期的に実行し、EBS ボリュームに関連するログエントリをCloudTrail で解析できるように、スケジュール化された CloudWatch イベントルールを使用します。 GitHub にホストされている スクリプトをデプロイしたLambda 関数がCloudTrail に保管されたアクションを解析することで、ユーザーが定義した期間でEBSボリュームが利用可能な状態、かつデタッチされているのかどうかが判別できます。CloudTrail ログは 90 日間保存されるため、その期間中であればCloudTrailのイベントを確認し、期間内のアクティビティに基づいて本当に必要なEBSボリュームかどうかを識別できます。

Lambda 関数がEBSボリュームを未使用として識別すると、OpsCenter の API を利用して OpsCenter に OpsItems を作成します。 OpsItems には、次のような情報が含まれます。

  • コンプライアンス違反の EC2 インスタンス
  • オペレーティングシステムのパッチレベル
  • デタッチされた EBS ボリューム

OpsItems には、最大 100 個の関連リソースをまとめて含めることができます。 たとえば、EC2にアタッチされていない EBS ボリュームが 250 個あり、Lambda 関数が OpsItem ごとに 100 個の関連リソースを含めるように設定されている場合、Lambda 関数は 3 つの OpsItems をSystems Managerに発行します。2 つは関連リソースが 100 個あり、もう 1 つは関連リソースが 50 個あります。

今回のようにEBSボリュームの数が多い場合は、関連リソースをバッチ処理するのがよいでしょう。Lambda 関数がOpsItemを発行するごとに Amazon SNS トピックをトリガーし、そのサブスクライバーへ通知されることになります。  OpsItems が発行されると、調査結果を確認できます。 OpsItem の関連リソースの一覧でフラグが付けられた特定のリソースをクリックして画面遷移し、次の画面で不要なEBSボリュームを選択してAutomation アクションを実行すれば問題を解決できます。

この記事では、デフォルトの自動化ドキュメントであるAWS-CreateSnapshotを OpsItems に関連付けて、Automationアクションを実行する機能を実演します。 独自の自動化ドキュメントを作成するか、AWS によって作成された既存のドキュメントを使用すれば、デタッチされたEBSボリュームに追加のステップ（スナップショット作成や削除など）を実行でき、デタッチされた EBS ボリュームの削除およびコスト削減ができます。

ソリューションの手順

このソリューションを設定するには、次の手順に従ってください。

Amazon SNS トピックの作成

  1. AWS Management Console で、選択したリージョンの Amazon SNS に移動し、新しいトピックを作成します。 今回は、us-west-2 を利用した手順で実演します。 名前を指定し、他はデフォルト値のまま設定します。 後続の手順で必要な、トピックの ARN に注意してください。ARNの形式は次のとおりです。

arn:aws:sns:us-west-2:123456789012:MyTopic

SNS トピックの作成の詳細については、Quick Startチュートリアルを参照してください。

  1. SNS コンソールで、手順 1 で作成した SNS トピックの E メールサブスクリプションを作成します。 詳細については、 Amazon SNS トピックにエンドポイントをサブスクライブする を参照してください。

AWS Lambda関数を作成します。

  1. IAM コンソールに移動し、指定の JSON ポリシーが付与されたLambda 関数を実行するロールを作成します。 このJSONのIAMポリシーとは、基本的な Lambda 実行権限、CloudTrail ログを読み取る権限、EBS ボリュームやSystems Managerなどの EC2 リソースにアクセスする権限であり、それらのIAMポリシーを Lambda 関数に付与することで、それぞれの機能をLambda関数から使えるようになります。 詳細については、 はじめてのカスタマー管理ポリシーの作成とアタッチ を参照してください。
  2. Lambda コンソールに移動し、次のスクリーンショットに示すように、次の基本的な詳細を含む関数を作成します。
    • 関数名 に、 opsCenterAgedEBSVolumeFinder と入力します。
    • ランタイム に、ドロップダウンリストからPython 3.6 または Python 3.7を選択します。
    • アクセス権限 で、次の操作を行います。
      • 実行ロール で、ドロップダウンリストから 既存のロールを使用するを選択します。
      • 既存のロール で、前の手順で作成したロールを Lambda 関数用に選択します。
    • 関数の作成をクリックします。

  1. 次に、新しく作成された関数の Lambda コンソールで、 環境変数 セクションまでスクロールし、次のスクリーンショットに示す 5つのkey-valueパラメータを入力します。
    • BATCH_SIZE に 20 と入力します。 このパラメーターは、Systems Manager OpsCenter に発行された 1 つの OpsItems イベントにまとめられた EBS ボリュームの数を指します。 最大バッチサイズは 100 です。
    • DETAILED_NOTIFICATIONS に True と入力すると、SNS トピックに詳細な通知が送信されます。 または、Falseを入力して簡単な通知を送信することもできます。
    • IGNORE_WINDOWに、0 から 90 までの値を入力します。 次の例では 15 を使用します。 このパラメータには、EC2からデタッチされてから孤立したと見なされるまでの期間を指定します。 CloudTrail ログは最大 90 日間保持されます。
    • SNS_ARN には、ステップ 1 で作成した SNS トピックの ARN を指定します。
    • SSM_AUTOMATION_IDに、AWS-CreateSnapshotを入力します。 Lambda 関数が OpsCenter に書き込む OpsItems に関連付ける既定のAutomationドキュメントを指定します。 この記事では、既存のAutomationドキュメントを使用して EBS ボリュームのスナップショットを作成します。 Systems Manager Automation ドキュメントのリファレンス を参照すれば、カスタムドキュメントの作成、Systems Managerへのアップロード、デフォルトのAutomationアクションとして OpsItems への関連付けができるようになります。

  1. Lambdaコンソールで、関数コード セクションまでスクロールし、次の図に示すように、ハンドラ で opsCenterAgedEBSVolumeFinder.lambda_handler に更新します。

  1. Lambda コンソールの 基本設定 で、メモリ を 256 MB に、タイムアウト を 3 に更新して保存ボタンをクリックします

  1. ラップトップまたは EC2 インスタンスの新しいディレクトリ/フォルダで、Lambda 関数のスクリプトをダウンロードします。そのLambda関数には、CloudTrail ログを解析し、未使用のEBSボリュームを特定するソースコードが実装されています。ダウンロード後、以下の手順に従ってください。
    • Python スクリプトが保存されたフォルダに移動し、次のバージョンの botocore、boto3、および awscli を持つ requirements.txt ファイルを作成して関数を実行します。

boto3==1.9.170
botocore==1.12.171
awscli==1.16.181

このファイルを Lambda 関数と同じディレクトリに保存します。 requirements.txt ファイルは、バージョンが明記された依存関係を記し、依存関係を基に1つのパッケージにまとめ、Lambdaの実行環境上で正しく動くことを保証するために必要なファイルです。boto3 と botocore のパッケージに関する概要については、「Automate your DynamoDB backups with Serverless in less than 5 minutes」を参照してください。

注記
boto3、botocore、awscliにここで指定したバージョンと同じかそれ以降のバージョンを使用すれば、Lambda関数を問題なくパッケージ化できます。

    • Lambda 関数と requirements.txt ファイルを配置したディレクトリで、次のコマンドを実行して boto3、botocore、および awscli パッケージのローカルコピーを作成します (最後に「.」を含めます)。

MacOS/Linux: pip install --upgrade -r requirements.txt -t .

Windows:pip install -r requirements.txt -t .

    • Lambda 関数のディレクトリで、再帰的に zip で圧縮してデプロイパッケージを作成します。Lambda 関数のディレクトリで次のコマンドを実行します (最後に「.」を含む) 。

MacOS/Linux:zip -r9 ../opsCenterAgedEBSVolumeFinder.zip .

Windows:7z.exe a -r c:\code\opsCenterAgedEBSVolumeFinder.zip .

    • 既存の関数を更新して、パッケージを Lambda にアップロードします (必要に応じて関数名、リージョン、および zip ファイル名を置き換えます)。

aws lambda update-function-code --region us-west-2 --function-name  opsCenterAgedEBSVolumeFinder --zip-file fileb://opsCenterAgedEBSVolumeFinder.zip

    • 注記: このコマンドは、zip ファイルが存在するディレクトリから実行されることを前提としています。ファイルへの絶対パスを指定することもできます。
  1. パッケージが正常にアップロードされたら、コンソールに移動し、Lambda 関数をテストします。
    • Lambda 関数を手動で呼び出すには、テスト を選択します。
    • 新しいテストイベントの作成を選択し、デフォルトのテンプレートはそのままにします。
    • イベント名を入力し、作成 を選択します。
    • テスト を選択して Lambda 関数を呼び出します。

OpsItems とコンプライアンスに準拠していない EBS ボリュームを確認するタスクの実行

  1. Lambda 関数を実行して、非準拠の EBS ボリュームを特定したので、結果を確認できます。 システムマネージャーコンソールに移動し、左側のパネルから OpsCenter を選択します。 ダッシュボードに複数の OpsItems が表示されるはずです。
    • OpsItem のステータス概要 (OpsItem status summary) で、未解決 対応中 (Open and In progress) の数量を示す数を選択します。

    • OpsItems バッチの一覧が表示されます。 関連するリソースを表示するには、バッチ ID を選択します。

    • 次の画面で、Lambda 関数の IGNORE_WINDOW 環境変数で指定された日数より古い、アタッチされていない EBS ボリュームのリソース ID のリストが表示されます。

  1. OpsItem ラジオボタンの関連リソースの 1 つを選択し、オートメーションを実行する を選択して、関連付けられているオートメーションドキュメント AWS-CreateSnapshotが表示されていることを確認し、選択します。

  1. VolumeId フィールドには、自動的に入力されていることが確認できます。 Description（オプション）と AutomationAssumeRole（オプション）を入力し、実行を選択してオートメーションタスクを開始します。

  1. 画面上部のステータスメッセージに、オートメーションが実行中であることが示されます。 右上のオートメーションステータスの状況を表示するを選択してステータスを確認します。

次の新しいタブを開くと、自動化に対して実行したステップ、結果として生じたスナップショット ID、および開始時刻や終了時刻などの詳細を確認できます。

注記
独自のカスタムAutomationドキュメントを作成して、ボリュームのスナップショットや削除、または必要に応じてボリュームの削除を行い、Lambda 関数によって発行される OpsItems に関連付けることができます。

Lambda関数のスケジュール
CloudWatch イベントルールを使用して、Lambda 関数を任意の頻度で自動的に呼び出されるようにスケジュールできるようになりました。 schedule オプションを使用すれば、CRON 形式の式で、特定の時刻とスケジュールでLambda 関数を自動的にトリガーする設定を定義できます。

この記事では、毎日 23:00 UTC に Lambda 関数を呼び出すように CRON 式を設定します。 このスケジュールを設定するには、次の手順に従ってください。

  1. CloudWatch サービスコンソールに移動し、左側のパネルで イベント オプションの下にある ルール を選択します。 ルールの作成を選択します。 詳細については、 Creating a CloudWatch Events Rule That Triggers on a Schedule を参照してください。
  2. 次のスクリーンショットに示すように、スケジュールオプションを選択し、CRON式を指定します。 次の式を使用して、毎日 23:00 UTC にトリガーできます。
    0 23 * * ? *
  3. ターゲット セクションで、未使用の EBS ボリュームを識別するために以前に作成した Lambda 関数を選択し、設定の詳細 を選択します。

  1. ルールの定義 で、名前と説明を指定し状態 が有効になっていることを確認してから、ルールの作成 を選択します。

Lambda 関数が毎日自動的にトリガーされ、未使用の EBS ボリュームの OpsItem バッチをSystems Manager OpsCenter に発行し、通知を SNS トピックに発行できるようになりました。

結論

この記事では、Lambda 関数内で OpsCenter API を使用して、孤立した EBS ボリュームを識別する OpsItems を作成する方法をお伝えしました。また、AWS Systems Manager Automation を使用して、EBSボリュームのスナップショットを取得する方法をお伝えしました。 さらに、Systems Manager Automation を使用して EBS ボリュームのスナップショット作成後にEBSボリュームを削除して、 AWS のコストを管理することもできます。
新しい機能である Systems Manager OpsCenter を使用して、さまざまな AWS リソースを一元的に管理してみてください。

みなさんの提案やフィードバックをお待ちしています。

 

Authors

Josh Zeiser は、AWS のシニアテクニカルアカウントマネージャです。 サンフランシスコベイエリアに在住し、お客様のAWS でのアプリケーションの設計と最適化を支援しています。 余暇で、家族と一緒に料理をすることや旅行をすることを楽しんでいます。

 

 

 

Sona Rajamani は AWS のシニアソリューションアーキテクトです。 サンフランシスコベイエリアに在住し、AWS 上で動かすアプリケーションの設計と最適化の支援をしています。 余暇で、ハイキングや旅行を楽しんでいます。

 

 

 

Ballu Singh は AWS のプリンシパルソリューションアーキテクトです。 サンフランシスコベイエリアに在住し、 AWS上で動かすアプリケーションの設計と最適化を支援しています。 余暇で、家族とともに時間を過ごすことや、読書をすることを楽しんでいます。

 

 

 

 

 

翻訳: ソリューションアーキテクト 内田 大樹 @nikuyoshi

原文:  Controlling your AWS costs by deleting unused Amazon EBS volumes