Amazon Web Services ブログ

Category: Compute

EC2 Image BuilderによるOSイメージビルドパイプラインの自動化

社会人になったばかりの頃、開発チーム向けのOSイメージビルドの仕事がアサインされたのを今でも思い出します。時間はかかるし、エラーはよく出るし、再作成とスナップショット再取得をなんども実行する必要がありました。さらに、ご想像のとおり、そのあとには大量の手動テストが控えていたのです。 OSを最新に保つことの重要性は現在も変わりません。場合によっては自動化スクリプトを開発してくれるチームがあるかもしれませんが、いずれにせよVMのスナップショットを手動で取得するという作業は、多くのリソースを消費し、都度エラー対処が要求される、時間のかかる作業であることに変わりはありません。今日ここで、EC2 Image Builderを発表できることを大変うれしく思います。これは、自動化されたビルドパイプラインによる、簡単、かつ高速にセキュアなWindows ServerおよびLinux OSイメージをビルドし保守していくためのツールです。EC2 Image Builderで作成されたイメージは Amazon Elastic Compute Cloud (EC2)で用いることができ、また満たすべき情報セキュリティ基準を遵守できるよう、セキュリティを強化することができます。今後AWSは規制を受ける業界向けに、はじめの一手として使える“Security Technical Implementation Guide (STIG – セキュリティ設定チェックリスト)”に準拠したセキュリティ強化ポリシーを提供していきます。 EC2 Image Builderパイプラインに含めることのできる設定項目は、OSイメージのレシピ、基盤の構成、イメージの配布先、それからテスト構成です。さらに、セキュリティパッチを含むソフトウェアアップデートに応じて、イメージビルドを自動実行する機能も含まれます。パイプラインにより新たなイメージが作成されたタイミングで、各AWSリージョンにイメージを配布する前に検証すべきテストの自動実行を設定することもできます。またEC2 Image BuilderをEC2 VM Import/Export機能と併用することで、オンプレミスに存在するVMDK, VHDX, OVFそれぞれのフォーマットからなるVMイメージと連携することができます。自動テスト機能ではAWS提供のテストとユーザー定義のテストを組み合わせることもできます。 それでは、EC2 Image Builderの開始方法を見ていきましょう。 OSイメージビルドパイプラインの作成 AWSマネジメントコンソールのサービス一覧からEC2 Image Builderを選択し、EC2 Image Builderマネジメントコンソールに進みます。ここで”Create Image Pipeline”ボタンをクリックします。今回はAmazon Linux 2イメージをカスタマイズしてビルドすることにします。はじめの一歩はソースになるOSイメージを選択し、イメージに適用するビルドコンポーネントを指定し、実行するテストを構成するレシピを定義するところからです。 OSソースイメージの選択では、EC2 Image Builderの提供するAWS管理のイメージを選択しました(“Select managed images”).  この手順では他にも、自分で作成したAMIや共有されたAMIを選択することもできます。AMI IDを直接指定することができます。 “Browse images”ボタンを押すとAWS管理のイメージを選択する画面が開きます。イメージを選択するには、OS名のボックス右上のラジオボタンをクリックします。 続いてイメージに適用するビルドコンポーネントを指定します。これはインストールすべき追加ソフトウェアを指定する手順です。ウィザードの”Create build component”をクリックすると、ユーザー定義の新しいビルドコンポーネント作成のためのオプションを指定することができます。新規にビルドコンポーネントを作成するには、ビルドコンポーネントの名前(と説明書き), OS種別、コンポーネント暗号化のためのAWS Key […]

Read More

Amazon Braket –量子コンピューティングを開始しましょう

ほぼ10年前、エイプリルフールの日にQuantum Compute Cloudについて書きました。未来が到来し、量子アルゴリズムを作成して実際の量子コンピューターで実行する機会が得られました。本日発表する内容は次のとおりです。 Amazon Braket –科学者、研究者、開発者が1か所で複数の量子ハードウェアプロバイダーのコンピューターで実験を開始できるようにする完全に管理されたサービスです。サービスの名称は、一般に量子力学的な状態を示すために使用されるブラケット表記にインスパイアされました。 AWS量子コンピューティングセンター – カリフォルニア工科大学(Caltech)に隣接する研究センター。世界をリードする量子コンピューティングの研究者とエンジニアを集めて、量子コンピューティングハードウェアとソフトウェアの開発を加速します。 Amazon Quantum Solutions Lab – AWSの顧客をAmazonの量子コンピューティングの専門家と非常に厳選されたコンサルティングパートナーのセットと結びつける新しいプログラムです。 量子コンピューティングとは 通常の(古典的な)コンピューターは、ビットのコレクションを使用して状態を表します。各ビットは明確に0または1であり、nビットがある場合、可能な状態の数は2 ^ nです。1ビットは2つの状態のいずれかになり、2ビットは4つの状態のいずれかになります。1 MiBのメモリを搭載したコンピューターには、CPUレジスタと外部ストレージを除く2つの状態(8 * 1048576)があります。これは大きな数ですが、有限であり、計算できます。 量子コンピューターは量子ビット(qubit)と呼ばれるより洗練されたデータ表現で状態を記述します。各量子ビットは状態1または0に存在できますが、1と0の重ね合わせにも存在できます。つまり、量子ビットは両方の状態を同時に占有します。このような状態は、1組の複素数を含む2次元ベクトルによって指定でき、無限の数の状態になります。各複素数は確率振幅であり、基本的に量子ビットがそれぞれ0または1である確率です。 古典的なコンピューターは、特定の時間にそれらの2 ^ n状態のうちの1つだけになることがありますが、量子コンピューターはそれらすべてを並行して占有できます。 長期間ITに携わっていたなら、ムーアの法則によって、私がこれを書いているように2テラバイトをサムドライブに保存するメモリチップを製造できるようになったことを知っています。これを可能にする物理的および化学的プロセスは驚くべきものであり、研究する価値があります。残念ながら、これらのプロセスは量子ビットを含むデバイスの製造には直接適用されません。私がこれを書いているとき、最大の量子コンピューターには約50量子ビットが含まれています。これらのコンピューターはいくつかの異なる技術で構築されていますが、共通する2つの属性があるようです。それらは希少であり、慎重に制御された物理環境で実行する必要があります。 動作方法 量子コンピューターは、状態ベクトルの振幅を操作することにより動作します。量子コンピューターをプログラムするには、必要な量子ビット数を把握し、それらを量子回路に配線して実行します。回路を構築するとき、正しい答えが最も可能性の高いものであり、残りのすべてが非常にありそうもないようにそれを設定します。古典コンピューターはブール論理を使用しないで使って構築され、OR、およびANDゲートに対し、量子コンピューターは、重ね合わせとの干渉を使用し、使用して構築されている量子論理ゲートを、新しいとエキゾチックな名前(X、Y、Z、CNOT、アダマール、トフォリなど)で構成します。 中期暗号化とデータ保護を検討する際には、これを念頭に置く必要があります。また、ポスト量子暗号について知る必要があります。現在、s2n(TLS / SSLプロトコルの実装)には、すでに量子耐性のある2つの異なるキー交換メカニズムが含まれています。新しい暗号化プロトコルが広く利用可能になり安全に使用できるようになるには約10年かかることを考えると、大規模な量子コンピューターが利用可能になる時期を先取りするのに早すぎるということはありません。 量子コンピューティングは今日主流ではありませんが、その時が来ています。これは、古典的に解決することが困難または不可能な特定の種類の問題を解決できる非常に強力なツールです。40年または50年以内に、量子コンピューターで実行されるサービスを使用して、多くのアプリケーションが部分的に機能するようになると思います。そのため、GPUまたは数学コプロセッサーのように考えるのが最善です。それらは単独では使用されませんが、ハイブリッド古典/量子ソリューションの重要な部分になります。 私たちの目標は、いくつかの適切なユースケースを探しているあなたに、いくつかのテストや実験を行う開始する量子コンピュータについて十分に知っているようにすることです。私たちは、現実にしっかりと根ざした強固な基盤を構築し、あなたと協力して、量子の力を活用した未来に移行したいと考えています。 Amazon Braket この新しいサービスは、量子ビットと量子回路を実際に体験できるように設計されています。シミュレーション環境で回路を構築およびテストしてから、実際の量子コンピューターで実行できます。Amazon Braketは完全に管理されたAWSサービスで、各レベルでセキュリティと暗号化が組み込まれています。 ノートブックスタイルのインターフェースを介してAmazon Braketにアクセスできます。 PythonコードはAmazon Braket SDKを利用します。1行のコードで量子回路を作成できます(これは、私の同僚によると、「量子ビット0と量子ビット1が最大にもつれた (エンタングルした) ベル状態」とのこと)。 bell = Circuit().h(0).cnot(0, 1) そして別のものでそれを実行します: print(device.run(bell, s3_folder).result().measurement_counts()) 古典計算機の力を借りたシミュレーション環境に加えて、Amazon Braketがアクセスを提供するD-Wave、IonQ、およびRigettiの量子コンピュータがあります。これらのデバイスにはいくつかの共通点があります:最先端の技術であり、構築と実行に費用がかかり、通常、電気のない状態に保つ必要がある非常に極端で特殊な環境(過冷却または真空に近い)で動作します。まとめると、ほとんどの組織が量子コンピューターを所有することは決してなく、クラウドベースのオンデマンドモデルの方が適していると考えています。プロダクション規模の量子コンピューターが最初はクラウドのみのテクノロジーである場合もあります。 実際の量子コンピューターは芸術作品であり、いくつかのクールな写真を共有できることを嬉しく思います。D-Wave 2000Qは次のとおりです。 The Rigetti 16Q Aspen-4: そして、IonQリニアイオントラップ: AWS量子コンピューティングセンター […]

Read More

Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

Read More

【開催報告】ビルシリーズ@住友不動産六本木グランドタワー 第1回

みなさんこんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第1回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは?」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは? このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです(同じビルなので移動が楽!)。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう!   著者について 木村 公哉(Kimura, Koya) 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠(Uehara, Makoto) アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

Read More

Amazon SNS, Amazon SQS, AWS Lambda のデッドレターキューによる耐久性のあるサーバーレスアプリケーション設計

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作成した、その後…

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください(なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください)。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール(ブラウザプラグインなど)を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

Read More

Amazon ECS向けAmazon CloudWatch Container Insightsについて

本記事は AWS のシニアソリューションアーキテクトの Sirirat Kongdeeによる寄稿記事です。 Amazon CloudWatch を利用することで、Amazon Elastic Container Service(Amazon ECS)のリソースを監視することができます。Amazon CloudWatchは、CPU やメモリの割り当てについてや、クラスター、サービスレベルでのリソース使用率のメトリクスを提供するサービスです。以前は、サービスとタスクについてカスタムモニタリングを有効にする必要がありましたが、CloudWatch Container Insightsを使用することで、すべての Amazon ECS リソースの監視、トラブルシューティング、アラームの設定を行うことができるようになりました。これはフルマネージド型のサービスであり、Amazon ECSのメトリクスとログを収集、集約、要約することが可能となります。

Read More

AWS ParallelCluster を使用して、インタラクティブでスケーラブルな ML 研究環境を構築する

 分散型機械学習 (ML) ワークロードの実行に関しては、AWS はマネージドサービスとセルフサービスサービスの両方を提供しています。Amazon SageMaker は、エンジニアリング、データサイエンス、および研究チームが時間を節約し、運用オーバーヘッドを削減できるマネージドサービスです。AWS ParallelCluster は、コンピューティングインフラストラクチャをより直接的に制御したいお客様向けのオープンソースのセルフサービスクラスター管理ツールです。この記事では、AWS で分散 ML を実行する方法について説明します。Amazon SageMaker を使用した分散トレーニングの詳細については、以下の「Horovod を使用した TensorFlow 分散トレーニングの起動」と「マルチリージョンサーバーレス分散トレーニング」の記事を参照してください。 AWS ParallelCluster は、AWS クラウドでのハイパフォーマンスコンピューティング (HPC) クラスターのデプロイと管理に役立つ、AWS がサポートするオープンソースのクラスター管理ツールです。AWS ParallelCluster を使用すると、データサイエンティストと研究者は、必要なコンピューティングリソースと共有ファイルシステムを自動的にセットアップすることで、伸縮自在にスケーリングされた AWS リソースで使い慣れた作業環境を再現できます。Jupyter、Conda、MXNet、PyTorch、TensorFlow などの広くサポートされているデータサイエンスおよび ML ツールにより、低オーバーヘッドのスケーリングによる柔軟でインタラクティブな開発が可能になります。これらの機能により、AWS ParallelCluster 環境は、分散モデルの開発とトレーニングをサポートする ML 研究環境に最適です。 AWS ParallelCluster は、コンピューティングリソースのオンデマンド割り当てを中心に構築されたスケーラブルな研究ワークフローを可能にします。AWS ParallelCluster は、単一のハイパワー GPU 対応ワークステーションで作業し、潜在的に十分に活用するのではなく、GPU 対応コンピューティングワーカーのオンデマンドフリートを管理します。これにより、並列トレーニング実験の簡単なスケールアップと、リソースが不要な場合の自動スケールダウンが可能になり、コストを最小限に抑え、研究者の時間を節約できます。アタッチされた Amazon FSx ファイルシステムは、開発中に従来の高性能 Lustre ファイルシステムを利用しますが、モデルとデータを低コストの Amazon S3 にアーカイブします。 次の図は、AWS ParallelCluster ベースの研究環境を示しています。自動スケーリングされた Amazon […]

Read More

Amazon ECRのネイティブなコンテナイメージスキャン機能について

本投稿は Richard Nguyen と Michael Hausenblas による寄稿を翻訳したものです。 コンテナセキュリティは、開発者、セキュリティ運用エンジニア、およびインフラ管理者を含む、さまざまなアクティビティとツールで構成されます。クラウドネイティブサプライチェーンの重要な要素の 1 つは、コンテナイメージをスキャンして脆弱性を検出し、そこから行動に移せる洞察を得ることです。 私たちはコンテナロードマップのIssue 17で、AWSネイティブソリューションを提供することがいかにお客様にとって重要であるかを学び、そして、ECRイメージスキャン機能を一般公開いたしました。この投稿では、ECR ネイティブのソリューションについて説明し、ユースケースの一つである「定期スキャン」の実装戦略を説明します。 Scanning 101 最初にコンテナスキャンに関する用語を解説し、前提知識を合わせましょう。 コンテナスキャンに精通している場合は、このセクションをスキップいただいても大丈夫です。 概念的には、コンテナセキュリティの一部としてのスキャンは次のようになります。 コンテナ化されたアプリケーションを見てみると、開発者(developer)がContinuous Integration(CI)パイプラインでコンテナイメージをbuildし、これらのアーティファクトをECRにプッシュしています。一方、セキュリティ運用エンジニア(secops)は、1つもしくは複数のECRリポジトリと、ECSやEKSなどのコンテナオーケストレーターを管理しています。この文脈でいうと、コンテナセキュリティは共同の責任であるということに着目することが重要で、developerと secops の役割は、クラウドネイティブのサプライチェーン全体のセキュリティに対処するために連携しています。たとえば、developerは、コンテナのUSER を定義し、イメージ内の不要なビルドツールを削除して攻撃対象領域を最小限に抑えるといった、セキュアなコンテナイメージをbuildするための推奨プラクティスに従います。同様に、secops も、runtimeポリシーを検証して適用するといったことを行ないます。 さらに、2種類のスキャンに分類することができます。 Static scanning (静的スキャン) :デプロイ前のフェーズで実行されるため、developers (もしくは secops) はコンテナが実行される前に脆弱性に気づくことができます。ECR イメージスキャン機能は、このカテゴリに分類され、コンテナイメージ内の OS パッケージをスキャンして、既知のセキュリティ上の脅威公開リストである共通脆弱性識別子 (CVE) を検出します。ECR イメージスキャン機能を利用すれば、独自のスキャンインフラを設定したり、サードパーティのスキャンライセンスを購入したりする必要はありません。 Dynamic scanning (動的スキャン):ランタイム環境で実行されるスキャンのことです。テスト環境、QA 環境、または本番環境で、すでに実行されているコンテナの脆弱性を特定することが可能であり、ビルド時点でインストール済みのソフトウェアに脆弱性が含まれていることが後日発覚した際や、ゼロデイの脆弱性なども検出可能です。動的(またはランタイム)コンテナセキュリティについては、CNCF Falcoなどのオープンソースソリューションから、Aqua Security、Trend Micro、Twistlock など、AWS コンテナコンピテンシーパートナーが提供するサービスまで、サードパーティ製のさまざまなオプションが利用可能です。 みなさまからお寄せいただいたフィードバックとさまざまな選択肢の評価結果に基づき、我々は人気のあるオープンソースプロジェクトであるCoreOS ClairをECRイメージスキャン機能で利用して脆弱性の静的解析を実行することに決定しました。イメージスキャン機能を備えるように ECR API、AWS CLI、SDK の拡張を行い、CI パイプラインやコマンドラインで使用しやすい形で、スケーラブルで信頼性の高いマネージドサービスを実装しました。 具体的な現実世界のユースケースから始めましょう。ECRでのコンテナイメージの定期スキャンです。 […]

Read More

使用されていない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 ボリュームを識別および管理できるようになります。

Read More