Amazon Web Services ブログ

同僚の Sanjay Padhi は AWS サイエンティフィックコンピューティングチームの一員です。Sanjay は、重要な科学的発見に役立つコンピューティングリソースを AWS がどのように提供したかに関するゲスト投稿を行いました。 – Jeff 質量の起源への洞察を提供する上で重要な役割を担うヒッグス粒子 (神の粒子と呼ばれることもある) は、2012 年に、スイスのジュネーブにある CERN の大型ハドロン衝突型加速器 (LHC) で、世界最大の実験装置である ATLAS および CMS により発見されました。この発見の基盤となる理論を提唱した研究者たちは、2013 年ノーベル物理学賞を受賞しています。 フランスとスイスの国境にまたがって地下深くに設置されている LHC は、世界最大 (全周 17 マイル) でこれまでにない高エネルギーの粒子加速器です。これにより、これまで探求してきたいかなる人間の発明よりも小さいスケールで自然界を探ることができます。 実験から生データへ 高エネルギー粒子の衝突により、質量はエネルギーに変換され、その後質量に再変換されて、新しい粒子が作り出されます。この粒子が CMS 検出器で観察されます。この検出器は長さ 69 フィート、幅 49 フィート、高さ 49 フィートで、フランスのセシー村近くにある地下 328 フィートのトンネルに設置されています。CMS からの生データは 1 秒あたり約 1 ペタバイトの割合で 25 ナノ秒毎に記録されます。 CERN Tier 0 データセンターで生データをオンラインおよびオフライン処理した後、そのデータセットは 48 […]

AWS CloudFormation を使用すると、AWS リソースのコレクション (「スタック」) を制御された予想可能な方法で作成、管理、および更新できます。CloudFormation を使用して、本番ワークロードを稼働するためのスタックの更新が 1 日に何十万回も実行されています。お客様は、初回のテンプレートを定義した後、要件が変わるとテンプレートを修正します。 通常「コードとしてのインフラストラクチャ」と呼ばれるこのモデルを使用すると、開発者、アーキテクト、および運用担当者の各チームが AWS リソースのプロビジョニングと構成を詳細に制御できるようになります。この制御と説明責任の詳細さは、CloudFormation を使用する際に最もはっきりとわかる利点の 1 つです。ただし、CloudFormation には、それほどはっきりとはわからないものの、同じくらい重要な利点がいくつかあります。 整合性 – CloudFormation チームは、AWS チームと連係して、リソースの作成、更新、および削除のセマンティクスについて、新しく追加されたリソースモデルでも整合性を保つようにしています。また、EBS ボリュームや RDS ボリュームの暗号化用の KMS キーなど、関連リソースの再試行、べき等性、および管理について説明できるようにしています。 安定性 – どのような配信システムでも、結果整合性に関連する問題は頻繁に発生し、必ず対処する必要があります。CloudFormation チームではこのような問題を十分認識しており、変更のプロパゲーションが必要な場合には、配信を実行する前に、自動的にそのプロパゲーションが完了するのを待つ仕組みになっています。多くの場合、CloudFormation チームはサービスチームと連係して、API と成功シグナルが CloudFormation で適切に使用できるよう調整されていることを確認します。 均一性 – CloudFormation では、スタックが更新される際に、インプレース更新とリソース置換のいずれかが選択されます。 この作業はすべて一定の時間がかかり、関連サービスが公開または更新される前にテストを完了できない場合もあります。 更新のサポートの向上 先述のように、AWS の多くのお客様が、本番スタックの更新を管理するのに CloudFormation を使用しています。お客様は、既存のテンプレートを編集 (または新しいテンプレートを作成) した後、CloudFormation の更新スタックオペレーションを実行して、変更を有効にします。 新しいテンプレートやパラメータ値に合わせてスタックが更新される際に CloudFormation が実行する変更の詳細について知りたい、というお問い合わせが、多くのお客様から寄せられています。変更のプレビューを行い、その変更が期待通りであることを確認してから、更新を実行するためです。 CloudFormation のこの重要なユースケースに対応するために、「変更セット」という概念を導入しました。変更セットを作成するための第 1 段階として、お客様は、更新対象のスタックに対する変更内容を送信します。CloudFormation では、更新対象のスタックが新しいテンプレートやパラメータ値と比較され、変更セットが作成されます。お客様は、この変更セットを確認してから、適用 […]

先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 28 日 AWS Security Blog が、AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法を掲載しました。 BotMetric が、AWS セキュリティベストプラクティスの投稿シリーズに、データセキュリティと検出サービスについての 2 つの投稿を新たに追加掲載しました。 Evident が、AWS 用のプログラムによるセキュリティの自動化についての記事を掲載しました。 Cloud Academy が、AWS DevOps Pro 試験に合格するのに役立つヒントを掲載しました。 Cloudonaut が オブジェクトストアとしての Amazon S3 の活用法を掲載しました。 Gorillastack が、より多くのコンピューティングリソースを Amazon EC2 スポットインスタンスに移行する必要がある理由を掲載しました。 The Register が、Amazon WorkSpaces のリリース後のこの 2 年間を振り返る記事を掲載しました。 火曜日 3 月 29 日 AWS CloudFormation で変更セットが利用できるようになったことを発表しました。 Amazon […]

こんにちは。プロダクトマーケティングマネージャーの石橋です。 2016年は、Amazon Web Services（以下、AWS）が2006年に事業を開始してから10年、2011年に東京リージョンを開設して5年と、節目の年を迎えました。当時はクラウドのパイオニア、今ではある意味老舗になってきたAWSです。特に、ここ数年で多くの企業においてクラウドの活用が進んでいることをニュース等で目にするようになりました。同時に、AWSも多くのお客様にご利用いただけるようになりました。なぜ、AWSは成長し続けているのでしょうか？理由を考えてみたいと思います。   ■10年前のクラウド、今のクラウド クラウドと言えば、システム構築のためのITリソースであるサーバやストレージ機器を、自社や個人で購入、所有することなくインターネット経由で提供し、必要な時に使った分だけ支払う従量課金や、ものの数分でITリソースを準備できる俊敏性が利点のビジネスモデルとして注目されました。AWS設立当時は、いかに早くビジネスを立ち上げ、その結果から次の打ち手を考えることができるかという利点が活かせる、スタートアップ企業を中心にご利用いただいていました。ここ数年は、以前とどう変化したのでしょうか？導入するお客様の業種や事業内容、企業規模は多岐に渡り、お客様の求めるサービスやセキュリティレベル、堅牢性や可用性のニーズに合わせたサービスを提供できるようになりました。AWSクラウドのセキュリティコンプライアンスへの準拠（第三者認証や監査）、専用線によるAWSクラウドへの接続、無料かつ自動更新のSSL証明書（US East（Northern Virginia）リージョンのみで提供）※など、企業においてクラウドにおけるガバナンスが効くようになり、利用している企業だけでなく、さらにその先のお客様が安心してサービスを利用できるようになりました。また、お客様と共にサービスを拡充し続けることで、多種多様な企業においてご利用いただけるようになりました。   ■クラウドによるビジネスモデル変革 導入が進むクラウドですが、AWSが最初に起こしたビジネスモデルの変革は何でしょうか？それは「ITリソースの購買体験を大きく変えたこと」です。必要な時に使った分だけ、事前の契約なしに、誰でも購入できる体験です。従来のITリソースの購買（調達）体験をシステム導入のライフサイクルから考えてみましょう。システム開発のライフサイクルには、ビジネス要件の定義、インフラ設計、システム設計（サーバサイジング設計や容量計画）、ソフトウェア設計、ソフトウェア開発、運用管理設計、システムテスト、システム運用（メンテナンス）、End of Service(EOS)と一連の流れがあります。この中で、AWSのクラウドで費用・人的労力・時間を軽減したり短くする（＝どこか別のところに任せる、考える時間を少なくする）ことができる部分はどこでしょうか？すべての開発サイクルでクラウドにワークロードを移行できます。   ■クラウドがビジネスにもたらす利点 ワークロードを移行した結果、ビジネス上の利点は何でしょうか？今までオンプレミス環境を構築している場合、ITシステム構築のワークロードは自社内にありました。これらのITワークロードをクラウド側で処理できるとすれば、システムの導入初期費用だけでなく、中長期にわたり運用する為の人的工数、ハードウェア・ソフトウェアのライセンスやメンテナンス費用まで含めたTCO削減につながります。そして重要なのは、ITワークロードをオフセットしたことによる調達や作業「時間」を、今まで手が付けられなかったことや新たな事業に投資することで、さらなる事業展開の可能性を創出できるようになることです。仕事の仕方が変わるという事なのです。   ■AWSが成長し続ける3つの理由 AWSはテクノロジーの変化に合わせて、お客様のビジネス形態も変化していることをいち早く捉え、ビジネスのパートナーとして共に成長しています。AWSの成長はお客様の変革によってもたらされています。それでは、AWSが成長し続ける理由を見てみましょう。   (1) お客様が事業に集中できる 企業や組織内の事業基盤にある技術インフラをAWSにすることで、お客様を差別化するための事業に集中できる状況を作っています。そして長期間に渡って競争力を維持し続ける為の支援を、AWSおよびパートナーエコシステムを活用し一緒にビジネスを行っています。   (2) イノベーションを起こすためのインフラ提供 すべての企業は生き残るためにビジネスや顧客体験を変えていく必要があります。コストの低減は守りの一要素ですが、その先にはビジネスの俊敏性や変革が必要です。そのためのインフラも俊敏、柔軟で革新的であるものを提供し続けています。   (3) ITに必要なモノをあらかじめそろえておく 企業内で使うITリソースは多岐にわたります。必要なモノはできるだけAWSで準備し組み合わせて使うことで、ビジネスのニーズに合わせたアウトプットを、より早く、より簡単に提供できるようになります。2015年は722ものサービスリリースや機能改善を行いました。お客様に、その継続的な進化や革新による利点をすぐに享受していただけます。     クラウドサービスの検討をはじめた方は、どこから手を付けていいかわからない方もいらっしゃると思います。弊社のホームページでセミナー情報を探していただくと、「はじめてのアマゾン ウェブ サービス」や「初級トレーニング」といった無料でAWSを知る機会がありますので、是非活用してみてくださいね。すぐにでも始めてみたい方は、AWS にサインアップした日から 12カ月間お使いいただける無料利用枠があります。ほとんどの製品をお試しいただけます。ユーザ登録は簡単ですので試してみてください。   AWSアカウントの作成手順はこちら http://aws.amazon.com/jp/register-flow/   ※サービスを提供しているリージョンは3/25現在の情報に基づいています。    

Amazon ElastiCache は、クラウド内のインメモリデータベースのデプロイ、運用、スケールの実行を簡単にするサービスです。ご存知のとおり、ElastiCache では Memcached エンジンと Redis エンジンがサポートされています。 Redis 向けの強化 本日、Redis ベースの ElastiCache クラスターがより詳細に制御できるようになる、ElastiCache の更新をローンチしました。You can now scale up to a larger node type while 保存された情報を ElastiCache に保持したまま (ベストエフォートベース)、より大きなノードタイプにスケールアップできるようになりました。ElastiCache for Redis のエンジンバージョンのアップグレードはこれまでずっと可能でしたが、保存された情報を保ったままでこれを実行できるようになりました。これらの変更は、両方とも、即時適用またはクラスターのメンテナンス期間の適用が実行できます。 ElastiCache for Redis のスケールアップとエンジンアップグレードのために、見えないところでさまざまな戦略が活用されています。スケーリングは Redis レプリケーションをベースにしています。エンジンのアップグレードでは、マルチ AZ がオフになったときにまずフォアグラウンドのスナップショットが使用され (SAVE)、マルチ AZ がオンのときにレプリケーションに続いて DNS スイッチが実行されます。 大きなノードタイプにスケールアップするには、AWS マネジメントコンソールで [Cache Cluster] を選択し、[Modify] をクリックします。新しい [Node Type] を選択し、変更を即時適用するかどうかを決定してから、[Modify] をクリックします。 […]

Airbnb は、わずか数人のすばらしい着想が業界全体を大きく変えることがあることを示す、典型的なストーリーです。2008 年にスタートして以来、これまでに 8000 万人の客が Airbnb を利用して 190 以上の国にある 200 万軒以上の家に宿泊しました。最近では、全世界からの旅行者のため、キューバに 4000 軒の家をオープンしました。同社はまた、早くから AWS を活用してきました。 ゲストによる以下の投稿の中では、Airbnb エンジニアリングマネージャーである Kevin Rice 氏が、スタートアップにおいて AWS がどれほど重要な役割を担ったか、そしてどのようにその重要な位置にとどまっているかを解説しています。 – Jeff PS – スタートアップが AWS を利用してビジネスを展開する方法の詳細についてもご覧ください。 初期 当社の創設者たちは、Airbnb を成功させるために、スピーディーかつリーンであることが必要だと認識していました。これには、インフラストラクチャに投じる時間とリソースを最小化することが不可欠です。当社のチームは、ベーシックなホスティングについての業務にではなく、ビジネスを離陸させることに集中することが必要でした。 幸いなことに、ちょうどそのとき、アマゾン ウェブ サービスにはコンピューティングとストレージにおいて非常に成熟したサービスが構築されていたため、当社のスタッフは他の人からのサポートや最小使用要件に気を使うことなく、サーバーを立ち上げることができました。同社のクラウドコンピューティング機能のほぼすべてを AWS に移行することが決定されました。スタート当初の小さな企業では、利用できるリソースを可能な限り活用する必要があります。当社の従業員たちは、ビジネスを成功させるために替えのきかないところに注意を集中したいと考えていました。 Airbnb では、Amazon EC2 や Amazon S3 といった AWS の基本サービスの多くをすばやく導入しました。当初の MySQL データベースは Amazon Relational Database Service (Amazon RDS) に移行されました。RDS […]

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。 2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポート、メジャーバージョンアップグレード、透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。 多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです！ Windows認証のサポートAWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。 SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です（新規にディレクトリを作成することもできます）： より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。 いますぐ利用可能この機能はUS East（北バージニア）、US West （オレゴン）、Europe（アイルランド）、Asia Pacific（シドニー）、Asia Pacific（東京）、そしてAsia Pacific（シンガポール）リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for […]

本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。   暗号化を行う際、開発者は次の2つの問題によく直面します: どのように正しく暗号鍵を生成し、利用するか 利用後、鍵をどのように保護するか 新しいAWS Encryption SDKによって提供されるライブラリは、ユーザーの開発環境で利用可能な暗号化プロバイダを利用し、低レベルの詳細な部分を透過的に実装することで1つ目の問題に対応します。また、どのように鍵を保護したいかを選択できる直感的なインターフェースを提供することで2つ目の問題への対応を手助けします。開発者は、暗号化の複雑性ではなく構築しようとしているアプリケーションコアにフォーカスすることが出来ます。この記事では、AWS Encryption SDKを利用してどのようにデータの暗号化プロセスを簡素化できるか、単一のリージョンあるいは鍵管理ソリューションに縛られない、アプリケーションの可用性を改善するのに役立つ方法でどのように鍵を保護できるかについてお伝えします。   エンベロープ暗号化と新しいSDK AWS Encryption SDKを利用する際に理解しておくべき重要なコンセプトは、エンベロープ暗号化(ハイブリッド暗号化としても知られています)です。アルゴリズムが違えば強度も異なり、単一のアルゴリズムで全てのユースケースにフィットするものは有りません。例えば、(RSAやAWS Key Mangement Service [KMS]などの)優れた鍵管理の特性を持つソリューションは、大容量のデータに対してはあまり有効ではありません。エンベロープ暗号化は、(AES-GCMのように)大容量データに適した単一用途のデータキーを使ってバルクデータを暗号化することでこの問題を解決します。エンベロープ暗号化ではその後、鍵管理に適したアルゴリズムや他のソリューションを使ってデータキーを暗号化します。 エンベロープ暗号化のもう一つの優位性は、複数の受信者で復号化できるようひとつのメッセージを暗号化できることです。全員で鍵を共有(これはたいていセキュアではありません)したり、全体のメッセージを複数回暗号化したり(これは現実的ではありません)するのではなく、データキーだけがそれぞれの受信者の鍵を使って暗号化されます。これによって重複した処理を顕著に削減でき、複数の鍵を利用した暗号化がより実用的になります。   エンベロープ暗号化の問題点は実装の複雑さです。全てのクライアントはデータフォーマットの生成および構文解析ができ、複数の鍵とアルゴリズムをハンドルでき、理想的には妥当な範囲で前方および後方互換性を保てる事が必須になります。   AWS Encryption SDKはどう役立つのか？ AWS Encryption SDKは、セキュアなアルゴリズムの組み合わせ(将来的に拡張可能)をサポートし、マスターキーのタイプやアルゴリズムの制限が無い、慎重にデザインされレビューされたデータフォーマットを採用しています。AWS Encryption SDK自身は、KMS、および AWS CloudHSMやその他の PKCS #11デバイスを含むJava Cryptography Architecture (JCA/JCE)を直接サポートするpoduction-readyなリファレンスJava実装です。他言語でのSDKの実装については現在開発中です。 AWS Encryption SDKの一つの利点は、低レベルの暗号処理はSDKで取り扱われるため、データの移動にフォーカスすることができることです。次に、パワフルでセキュアなマルチリージョンソリューションを構築する簡単なコードを示します。   Example 1:高可用性のためにアプリケーションの機密データを複数リージョンのKMSマスターキーで暗号化する 高可用性アプリケーションのベストプラクティスの一つは、複数のアベイラビリティゾーンだけではなく複数のリージョンでデプロイすることです。KMSはリージョンをまたがってカスタマーマスターキー(CMK)を共有できないため、データがKMSで暗号化されている場合にはこのようなデプロイメントは困難です。エンベロープ暗号化では、異なるリージョンの複数のKMS CMKを使ってデータキーを暗号化することでこの制限に対するワークアラウンドを取ることができます。各リージョンで稼働するアプリケーションは暗号文の復号化を行うために、高速で信頼性の高いアクセスのためにローカルのKMSエンドポイントを利用することができます。 このドキュメントの全ての例において、 IAM roles for EC2を設定したAmazon EC2インスタンスが稼働していることを想定しています。IAM […]

AWS Marketplace は先進の ISV (独立ソフトウェアベンダー) に大いに活用されています。 ユーザーは、ハードウェアの調達やソフトウェアのインストールを行うことなく、数分のうちに製品を見つけ、購入し、使用を開始することができます。このようなスムースな配信方法によって、ISV は新たな顧客を得ると同時に、販売サイクルを短くすることもできています。ユーザーは既存の AWS アカウントを通じ、標準の AWS 請求サイクルにしたがって製品に対する支払いを行います。 AWS Marketplace へのオンボーディングプロセスの一部として、各 ISV はソフトウェアの料金を自由に決定できます。ISV は、割引のある月間利用料金や年間利用料金の設定も選択できます。従来は時間以外に基づいてライセンスされていたソフトウェアについても、ISV は AWS Marketplace に、自分で選択したディメンションでのライセンシングオプションに対応する複数のエントリを作成できます。 このモデルはさまざまなタイプのアプリケーションで効果を上げています。しかし、通常はまだ向上の余地があります。 他の料金オプション ソフトウェアのパッケージングと料金設定については、いっそうの柔軟性を求める声が ISV から届いていました。AWS ではそれにお応えします。複数エントリを作成せずにユーザー数モデルへの拡張を希望される場合もあれば、別のディメンションでの課金を希望される場合もあります。セキュリティ製品ベンダーは、スキャン対象のホスト数に応じた課金を希望するかもしれません。分析向けの製品のベンダーであれば、処理するデータ量に応じた価格設定を望むかもしれません。 これらの選択肢を実現させるため、ISV が自社製品にとって有効なディメンション (スキャン対象ホスト数、処理データ量など) に基づいて使用量を追跡し、レポートすることが可能になりました。これらの使用量について、単位あたりの価格を設定することも可能です (1 ホストあたり 0.50 USD、1 GB あたり 0.25 USD など)。このような使用量に対する課金は、ユーザーの AWS 請求に表示されることになります。 この変更によって、AWS Marketplace の製品ラインナップがいっそう広がることになるでしょう。 新しい料金オプションの実施 自社の AWS Marketplace 製品にこの新しいモデルの料金を使用することを希望する ISV は、アプリケーションにいくらかコードを追加する必要があります。適切なディメンションにより使用量を測定し、使用量をレポートする新しい AWS API 関数を呼び出します。このデータ […]

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（1台のインスタンスから何千台のインスタンスまで）費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御、【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応。 私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが（可能な限り費用対効果を高めるよう変化）、フリート自体はその属性を保持します。 新しいスポットフリート メトリックス スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます：スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。 下記メトリックスは各スポットフリート毎に取得されます。（これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります） AvailableInstancePoolsCount BidsSubmittedForCapacity CPUUtilization DiskReadBytes DiskReadOps DiskWriteBytes DiskWriteOps EligibleInstancePoolCount FulfilledCapacity MaxPercentCapacityAllocation NetworkIn NetworkOut PendingCapacity StatusCheckFailed StatusCheckFailed_Instance StatusCheckFailed_System TargetCapacity TerminatingCapacity  メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、 AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。 BidsSubmittedForCapacity – スポットフリート キャパシティの入札数を示します。 EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか（1）スポット価格がオンデマンド価格より高い場合、または（2）入札価格がスポット価格よりも低い場合にはプールが不適用となります。 FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。 PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。 PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。 TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。 TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。 これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。 CPUUtilization DiskReadBytes […]