先週AWSの世界で起こったことを振り返ってみましょう。
| 6/10 (月) |
|
| 6/11 (火) |
|
| 6/12 (水) |
|
| 6/13 (木) |
|
| 6/14 (金) |
|
それではまた来週!
P.S. このブログの最新情報はTwitterでお知らせしています。お気軽に@horiuchiをフォローください。
最近の記事
- 週刊AWS - 2013年6月10日
- 【AWS発表】 SOC3レポートが利用可能に
- 【AWS発表】 Amazon CloudFrontが独自SSL証明書とルートドメインホスティングをサポート
- 【AWS発表】 EBSスナップショットコピーがインクリメンタルコピーに対応し、より高速に!
- 【AWS発表】 AWS 無料利用枠にRed Hat Enterprise Linuxを追加
- 【AWS発表】 Amazon RDS オンデマンドとリザーブドの両方を値下げ
- 週刊AWS - 2013年6月3日
- 2013年度上半期 パートナーアワードを発表!
- 【AWS発表】 Amazon RDSのGA および SLAを発表
- 【AWS発表】 Amazon Redshiftが東京リージョンでも利用可能に!
知っていると役立つリンク
【AWS発表】 Amazon CloudFrontが独自SSL証明書とルートドメインホスティングをサポート
本日、Amazon CloudFrontに対して非常にリクエストの多かった2つの機能、独自SSL証明書とルードドメインホスティングをサポートしたことを発表できるこをうれしく思います。 これらの機能の両方をサポートすることで、CloudFrontの世界中に拡がるエッジロケーションを介して、ウェブサイトをまるごと全て配信することがより簡単になります。 これには、動的コンテンツ、静的なオブジェクト、およびウェブサイトまたはアプリケーションのセキュリティで保護された部分も含まれます。
独自SSL証明書
ユーザーがHTTPSプロトコルを使ってウェブサイトからコンテンツをリクエストした場合、ウェブサーバーはデジタル証明書を使用して、送信前にデータを暗号化します。
証明書内の情報は、コンテンツのソースを識別し、復号鍵も供給します。このような方法でコンテンツを保護することで、サイトに対するユーザーの信頼と信用を向上させることができます。
CloudFrontのディストリビューションを作成すると、例えば、d123.cloudfront.net といった一意のドメイン名を受けとります。 このドメイン名をURLとして直接使うこともできますし、CNAMEを作成し、サイトの閲覧者が慣れ親しんでいる名前を使ったり、www.mysite.comといったブランドを表す名前を使うということもできます。 しかし、各ブラウザに配布する皆様のドメインのSSL証明書を、CloudFrontのエッジサーバーは持っていませんでしたので、本日までは、HTTPS経由でコンテンツを配信する際、このCNAMEを使うことができませんでした。 しかし本日より、それが可能になりました!
特定のCloudFrontディストリビューションに対するHTTPSリクエストを処理する際に、SSL証明書をアップロードし、それを使用するCloudFrontを指定することができるようになりました。
この機能を使うには、まずAWSのWebサイトからインビテーション(招待状)をリクエストする必要があります。 リクエストが承認されるとすぐに、SSL証明書をアップロードし、AWS Management Consoleを使って、ディストリビューションと関連づけることができるようになります。手順は次のとおりです。
- 認定証明局から証明書を購入する。
証明書はX.509 PEM 形式である必要があり、証明書チェーンを含める必要があります。CloudFrontは、Domain Validation証明書、Extended Validation（EV）証明書、高保証証明書、ワイルドカード証明書（*.example.com）、およびSubject Alternative Names （SAN）証明書（example.comとexample.net）を含む、多くのタイプの証明書をサポートしています。
- AWSアカウントに証明書をアップロードする。
IAM CLIを使って、次のようなコマンドで、AWSアカウントに証明書をアップロードします。
iam-servercertupload -s www.cloudfrontdemo.com -k privatekey.txt -c certchain.txt -b publickey.txt -p/cloudfront -v
証明書がCloudFrontで使われることを示すために、-p (パス) オプションを指定する必要があることに注意していください。さらに詳しい情報については、iam-servercertupload ドキュメントをご覧ください。
- ドメイン名をディストリビューションにマッピングする。
サイトのDNSレコードセットにCNAMEレコードを作成し、ドメインもしくはサブドメインをディストリビューションのドメイン名にマッピングします。また、ディストリビューションが関連づけられたドメインをCloudFrontに教える必要もあります。
- 証明書をディストリビューションに関連づける:
これで設定は全て完了です!
閲覧者がSSL接続を介してCloudFrontからコンテンツをダウンロードする際、SSL接続はCloudFrontのエッジロケーションでターミネートされます。これにより、オリジンサーバはSSL暗号化の負担を軽減することができます。オリジンフェッチにHTTPSを使うようにCloudFrontを設定することもできます。オリジンから閲覧者までの全ての経路を暗号化したい場合に利用できます。
独自SSL証明書毎に時間単位の従量料金と月額の固定料金がかかります。SSL証明書の利用にかかる料金についての詳しい情報については、 CloudFrontの料金のページをご覧ください。
全体のプロセスに関する詳しいドキュメントとして、CloudFront Developer Guideがご利用いただけます。
ルートドメインホスティング
Route 53 (AWSのドメインネームサービス)を使って、エイリアス (A)レコードを設定できるようになりました。これは、CloudFrontディストリビューションにルートドメイン(例: "cloudfront.com")をマッピングできることを意味します。
この設定をすると、Route53はCloufFrontディストリビューションのIPアドレス(1つまたは複数)をリクエスト毎に返すようになります。 これにより、訪問者は、手動で"www"といったプレフィックスを指定しなくて済みますので、簡単かつ確実にウェブサイトにアクセスできるようになります。
設定は以下の図のとおりです。
Route53はCloudFrontディストリビューションにマッピングされたエイリアスレコードへのクエリに対して課金いたしません。 今回の発表で、CloudFrontディストリビューションを指す、全てのドメインエントリに対して、CNAMEレコードの代わりにRoute53のエイリアスレコードを使うことができるようになったことになります。 この新機能についてのさらに詳しい情報については、Route 53 Developer Guideをご覧ください。
Nihar Bihani + 堀内康弘 (Facebook, Twitter)
【AWS発表】 EBSスナップショットコピーがインクリメンタルコピーに対応し、より高速に!
EBSスナップショットコピー機能を使えば、AWSリージョン間でEBSのスナップショットをコピーすることができます。 本日お知らせする新機能は、リージョン間のインクリメンタルコピーをサポートすることで、スナップショットコピーを以前より高速に行うことができるというものです。これにより、頻繁にリージョン間のスナップショットコピーを行うことが現実的になり、可用性の高いアプリケーションを開発することがより簡単になることでしょう。
特定のリージョンに対して、EBSスナップショットのコピーをはじめて行う際には、全てのデータがコピーされます。同じリージョンへの2回目以降のコピーについては、最後のコピーから変更されたデータのみが転送されます。その結果、データの転送量が少なくなり、以前より早くスナップショットを作成できるようになります。
データの転送量が少なくなりますので、スナップショットのコピーはより早く完了できるようになります。もちろん、どれくらい早くなるかは、最後にコピーしてから変更されたデータの量に依存します。どのくらい早くなるのかを皆さんに感覚的にご理解いただだけるよう、様々なアプリケーションを実行している様々な種類のEBSボリュームを使ってリージョン間のスナップショットコピーを測定してみました。その調査結果によると、2回目以降は、約50倍のスピードアップを期待できるという結果になりました。
AWSのお客様であるAptean社は、エンタープライズのディザスタリカバリサービスの一部として、EBSスナップショットコピーを使っています。 Aptean社のバイスプレジデント Mario Baldasserini氏は次のように語っています。
Apteanは世界中のお客様に対し、イノベーティブなディザスタリカバリソリューションを提供するために、サービス開始当初からEBSのスナップショットコピーを使ってきました。今回の新機能はAWS上で世界規模の製品ソリューションを提供する際の目標回復時間をかなり削減できますので、非常にワクワクしています。
皆さんのアプリケーションで、より速くなったリージョン間のEBSスナップショットコピーを活用する方法がありましたら、是非教えてください!
今年はじめ、リージョン間でEC2 AMIをコピーできる機能を発表いたしました。この機能はEBSスナップショットコピー機能を使っていますので、今日の拡張により、EBS-backedのAMIをコピーする際は、AMIのコピーも高速になります。
この変更は透過的ですので、何か特別なことをすることなく、上記のスピードと効率性を手に入れることができます。 AWS Management Console、 ec2-copy-snapshot または ec2-copy-image コマンド、CopySnapshot または CopyImage API、どれをお使いの場合でも、今まで通りそのままお使いください!
【AWS発表】 AWS 無料利用枠にRed Hat Enterprise Linuxを追加
AWS 無料利用枠に、Red Hat Enterprise Linuxのマイクロインスタンス(t1.micro)での750時間分までの利用が含まれるようになりました!
2007年の11月からEC2上でのRHELのサポートを開始し、2010年の12月にAWS 無料利用枠を開始いたしました。 今回、この2つを組み合わせて、毎月750時間のLinuxの利用の一部として、RHELの実行ができるようになりました。
AWS Management Consoleを使って、RHELを実行するマイクロインスタンスを起動することができます。
この新しいオプションは既存の無料利用枠をお持ちのお客様および、新しくAWSアカウントをサインアップいただいたお客様全ての方がご利用いただけます。 無料利用枠の利用方法について詳しく知りたい方はAWS 無料利用枠の入門ガイドをご覧ください。また、EC2上でのRHELについて知りたい方は、Red Hat とアマゾン ウェブ サービスをご覧ください。
2013年度上半期 パートナーアワードを発表!
2013年前期のAWSパートナーアワードの発表と表彰式が 6月4日に開催されたAPNパートナー説明会で執り行われました。 各パートナー様の受賞理由発表の後にAWS代表取締役 社長の長崎より表彰の目録が手渡されました。 尚、受賞各社には記念の盾が授与されます。
アワードの受賞パートナー、案件内容は以下のとおりです。
エンタープライズ部門
受賞社名： 株式会社 ノーチラス・テクノロジーズ 様
案件名： 株式会社 西鉄ストア 様 24時間365日稼働する基幹システムの先進事例
AWSを活用し西鉄ストア殿向けの基幹システムを構築されました。総画面数が600、ジョブグループ数で200グループ、一日で処理するデータ件数は最大で一日20億件という膨大な処理が可能となり、流通業界では実現が難しかった個別原価法を実現。コストについては従来比で2倍のパフォーマンスをアップすることが可能となり、またシステムのハードウェアに対する依存をなくし低コストでの長期利用化を実現されました。AWS上でミッションクリティカルな基幹システムが24時間365日稼働する先進的な事例を高く評価し、本アワードを授与させて頂きます。
インダストリーチャレンジ：金融部門
受賞社名： クラスメソッド 株式会社 様
案件名： マネックス証券 株式会社 様 お客様向け投資信託検索サイト事例
マネックス証券様のお客さま向け投資信託の検索サイト(検索および個別商品の特長やチャートなどの紹介ページ)の基盤としてAWSを活用し構築。サービスインまでの迅速さ、キャパシティ計画の柔軟性、VPCによるセキュリティを確保し、ELBを使った負荷分散、複数AZにクラスター化されたMongoDBの活用により、高い性能と可用性を実現しました。またGlacierやCloudFormationを用いてDR(災害対策)も実施頂きました。金融市場での先進的なソリューション提供を評価し、本アワードを授与させていただきます。
WEBシステム活用部門
受賞社名：株式会社 サーバーワークス 様
案件名：株式会社 インテージ 様 トータルリサーチシステム構築事例
AWS上に展開した仮想サーバー約200台で、最大約220万人にWebアンケートを実施し、1日で回答の集計・分析ができるシステムを構築。従来に比べて総運用コストを約20〜30%削減するとこが出来ました。また短期間において大きなAWSの商談金額を達成頂きました。この貢献に関して本アワードを授与させて頂きます。
HPC部門
受賞社名： 株式会社 ヴァイナス 様
案件名： 独立行政法人 宇宙航空研究開発機構(JAXA) 様 液体ロケットエンジンターボポンプにおけるテスト解析事例
AWS EC2 HPCインスタンスを最大限に活用することで、宇宙航空研究開発機構(JAXA)殿向けに、高機能・高精度流体解析ソルバCRUNCH CFDを実装し、液体ロケットエンジンのターボポンプのテスト解析を実施されました。その結果既存システムとの対比で約2倍の高速化可能な目途が得られました。AWS EC2 HPC活用による具体的なベネフィットの例を示して頂きましたご貢献に対して本アワードを授与させて頂きます。
【AWS発表】 Amazon RDSのGA および SLAを発表
Amazon Relational Database Service (RDS)はIT活動の中で最も複雑なもののとひとつ、リレーショナルデータベースの管理、スケーリング、高速で予測可能なパフォーマンスと高可用性を提供することを、シンプルにするために設計されました。
RDSの活用事例
Amazon RDSがサービスを開始してから3年半で、非常に多くのことが起こっています。Amazon RDSは、今や、あらゆる規模の数万におよぶビジネスにおいて、ミッションクリティカルなデプロイに使われています。
これらのお客様においては、それぞれ、月間、数兆におよぶI/Oリクエストを処理しています。サムスンや、ユニリーバのようなエンタープライズ、
FlipboardやAirbnbのようなWebスケールのアプリケーション、
NASA JPLやObama for Americaのような大規模組織に積極的に採用されています。
RDSのイノベーション
RDSは3つの主要なデータベースエンジン(MySQL、Oracle、SQL Server)をサポートしており、9つ全てのAWSリージョンでご利用いただけ、要望の多かった50以上の機能を追加してきました。RDSのサービスを開始してから追加してきた機能のタイムラインは次のとおりです。
このタイムライン上の特に重要な機能について、いくつか詳しく見てみましょう。
- 複数のデータベースエンジンのサポート - MySQLに加え、Oracle Database、Microsoft SQL Serverをサポートしています。
- Multi-AZ 配備 - マスターと異なるアベイラビリティゾーンに完全同期のレプリケーションを作成する可用性の高いデータベースの配備を実現できる機能です。障害を自動で検知し、自動でフェイルオーバーします。
- リードレプリカ - 簡単に1つのデータベースの容量の制約を超えて、弾性的にスケールアウトできる、読み込みの多いデータベースワークロードのための機能です。必要であれば、リードレプリカをマスターに昇格することもできますし、AWS Management Console を介してレプリケーションのステータスを直接監視することもできます。
- プロビジョンド IOPS - Amazon RDS Provisioned IOPSは高速で予測可能、かつ一貫した I/O 性能を提供するために設計され、I/O集中型のトランザクショナル(OLTP)なデータベースワークロードに最適化されたストレージオプションです。1つのデータベースあたり、最大3TBのストレージ、30,000 IOPSまでプロブジョンすることができます。
- データベースのログへのアクセス - データベースの問題を解決するために、AWS Management Console を使って直接、様々なデータベースのログファイルを閲覧したり、ダウンロードしたりすることができます。
- EmailやSMSを介したDBの通知 - フェイルオーバー、ストレージの容量不足、レプリケーションの状態の変化などのデータベースイベントが発生したとき、EmailまたはSMS通知を受けとることができます。
冒頭で紹介したように、これらのイノベーションは数百万のユーザーに利用されている世界で最も人気のあるアプリケーションのいくつかにパワーを提供しています。
GA (General Availability) & RDS SLA
上記で紹介した非常にリクエストの多かった機能を追加した後、Amazon RDSを"一般提供開始"といたしました。
複数の市場セグメントで多くのお客様に採用いただいていること、数多くの新機能、および、AWSの豊富な運用経験により、本日、Amazon RDSのService Level Agreement (SLA)を、マンスリーベースで、Multi-AZデータベースインスタンスの場合、99.95% の可用性であると発表いたします。 このSLAはMulti-AZ 配備をサポートする、MySQL および Oracle データベースエンジンで利用可能です。 Multi-AZのデータベースインスタンスの可能性が99.95%を下回る場合(1月あたり、22分以上使用不能となった場合)、サービスクレジットを受けとる資格があります。 この新しいAmazon RDSのSLAは最も要望が多く、ミッションクリティカルなワークロードをAWSクラウドで信頼性高く実行するための追加の信用を与えるよう、設計されています。 Amazon RDSのSLAについてさらに詳しい情報については、http://aws.amazon.com/rds-slaを御参照ください。
【AWS発表】 Amazon Redshiftが東京リージョンでも利用可能に!
本日よりAmazon Redshiftが東京リージョンでもご利用いただけるようになりました! 東京リージョンをご利用のお客様は、高速でフルマネージドなペタバイト規模のデータウェアハウスを、ほとんどの従来のデータウェアハウスソリューションの10分の1の価格で、今すぐ作成することができます。
お客様からのAmazon Redshiftに対する賞賛の声
Redshiftは2013年2月にサービスを開始いたしました。その時以来、1000社以上のお客様が利用開始し、現在でも1週間に100以上のペースで増え続けています。
これらを集計すると、数百万ドルの支出(CAPEX)を節約している計算になります。
Aggregate KnowledgeのTimon Karnezos氏はRedshiftの性能とコストの特性について詳しく学ぶため、ディープダイブを行いました。Timon氏の最近のブログ記事、
AWS Redshift, How Amazon Changed the Gameにその内容が記されています。
Timon氏は、6つのRedshiftクラスターの設定(dw.hs1.xlargeノードを1から32個、および、dw.hs1.8xlargeノード2つか4つ)を用いて、4つのデータセット(20億から570億行)をテストしました。
データセットはAmazon S3に保存されており、全体のロード時間はコストとデータサイズに応じて、線形にスケールすることがわかりました。
また、レポートを作成する際によく使われるいくつかのクエリについても測定し、非常に一貫したクエリタイムであり、データセットが500億行を超えるまでに成長した時でさえも、ほぼリニアにスケールすることを確認し、性能は非常に良好であることもわかりました。
このような非常に大きなデータセットに対して、これらのクエリを高速に実行できることを言及した時、アナリスト達にちょっとした衝撃が走りました。 およそ3日間、事前に勉強し、1晩でサービスを開始できました。
お客様がAmazon Redshiftの価格、性能、使いやすさに満足いただいていると聞いて非常にうれしく思います。
いつやるの?
Amazon Redshiftは現在、米国東部(北バージニア)、米国西部(オレゴン)、EU(アイルランド)、アジアパシフィック(東京)リージョンでご利用可能で、他のリージョンにも順次追加していく予定です。
Amazon Redshiftは今すぐに東京リージョンで起動することができます。Redshift Getting Started Guideを読み、AWS Marketplaceのビジネスインテリジェンス(BI)およびデータインテグレーションソフトウェアのセクションを確認したら、すぐに自分専用のクラスターを立ちあげましょう!
【AWS発表】 AWS IAM が Amazon、Facebook、GoogleのID連携をサポート
本日はAWS Identity and Access Management (IAM) チームのプリンシパルプロダクトマネージャー、Jeff Wiererより、非常に強力な新しいフェデレーション(連携)機能をご紹介いたします。
以前、このブログで、開発者が、AWSの外で管理されているユーザーに一時発行セキュリティ証明書を付与できるようにすることで、AWS Identity and Access Management (IAM)がID連携をサポートする方法を紹介いたしました。 本日、この機能をさらに拡張し、WebのID連携をサポートするようになりました。 WebのID連携により、FacebookやGoogle、最近サービス開始したLogin with Amazonのような、パブリックなIDプロバイダを認証に利用するクラウドベースのアプリケーションの開発が非常にシンプルになります。 "Login with Amazon"をご存知ない方のために簡単に紹介いたしますと、このサービスは、数百万のAmazon.comのお客様と、皆様のウェブサイトを安全に接続するために利用できる新しいサービスです。 "Login with Amazon"について、もっと詳しく知りたい方はこちらのページをご覧ください。
WebのID連携を使えば、ユーザーが自身のAmazon.com、Facebook、GoogleのIDを使ってアプリケーションにサインインすることができ、
シームレスにAWSアカウント下で管理されているAWSリソースへのアクセスを認証できるようになります。
モバイルアプリケーションやクライアントベースのアプリケーションを構築している場合、これらの人気のIDプロバイダを統合し、サーバーサイドのコードを書くことなしに、また、アプリケーションに長期間の証明書を埋め込むことなしに、認証を行うことができるようになります。
このシナリオをサポートするために、今回のリリースでは新しいAWS Security Token Service (STS) API, AssumeRoleWithWebIdentityを導入しています。
このAPIを使用すると、Amazon.comやFacebook、またはGoogleにより認証されているアプリケーションのユーザーのための一時的なセキュリティ証明書を要求することができます。
アプリケーションはAmazon Simple Storage Service (S3) オブジェクトや、DynamoDB のテーブル、Amazon Simple Queue ServiceのキューのようなAWSのリソースへのアクセスに、この一時発行セキュリティ証明書を使うことができます。
それでは使用例を見ていきましょう。
想像してみてください。 あなたは認証に "Login with Amazon" サービスを使用するモバイルアプリケーションを開発しています。 アプリケーションの機能のひとつとして、エンドユーザーは個人のアバター用の画像ファイルをアップロードができるようになっています。 舞台裏では、S3バケットのひとつにオブジェクトとしてこれらの画像を保存したいと考えています。 これを実現するためには、アプリのユーザーにアクセスを移譲するために使われるロールを設定する必要があります。
- 役割を担うことができる信頼されたエンティティ(主体)であることを指定するトラストポリシー。このケースでは、信頼されたエンティティは認証されたAmazon.comユーザーになります。
- ユーザーが何をできるかを指定する権限を持つアクセスポリシー
"Login with Amazon"用のトラストポリシーを設定する
まず、トラストポリシーを作成します。
この例では、"Login with Amazon"に作成したアプリを登録し、アプリケーションID (app_id)として、amzn1.app.123456SAMPLEが割りあてられたと仮定しましょう。
このアプリケーションIDは"Login with Amazon"でアプリケーションを一意に識別します。
(FacebookまたはGoogleにアプリを登録した場合は、各プロバイダから別のapp IDを取得するでしょう。)
Amazon.comユーザーにアクセスを移譲するためには、ロールのトラストポリシーが新しい連携主要タイプ www.amazon.com と app_idの値を含んでいる必要があります。
次のトラストポリシーは、アプリを使って認証された任意のAmazon.comユーザーがsts:AssumeRoleWithWebIdentity APIをコールし、役割を担うことを許可しています。
{
"Version":"2012-10-17",
"Statement":[{
"Principal":{"Federated":"www.amazon.com"},
"Effect":"Allow",
"Action":"sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals":{
"www.amazon.com:app_id":"amzn1.app.123456SAMPLE"}
}
]
}
ポリシーの条件に使うことのできる、新しいタイプのキーを導入していることに注目してください。- 現在Amazon.com、Facebook、Googleのためのアイデンティティプロバイダ固有のキーをサポートしています。 このケースでは、www.amazon.com:app_id キーが、アプリの登録IDと文字列比較を行うことにより、リクエストがアプリから送られたものであることを保証します。 (Web ID連携をサポートする新しいポリシーキーについての詳しい情報については、AWS STSガイド内のCreating Temporary Security Credentials for Mobile Apps Using Public Identity Providersをご覧ください。)
次に、ロールのためのアクセスポリシーを作りましょう。
S3へのアクセスを許可するサンプルポリシー
次のアクセスポリシーはアプリケーションのエンドユーザーに、AWSアカウントで作成したmyBucketという名前のS3バケットに限定的なアクセスを許可しています。 具体的には、全てのユーザーに対して、プレフィックスがapp_idにマッチする共有フォルダーへのリードオンリーなアクセス(Get*)を許可し、 プレフィックスがAmazonによって提供されたユーザーIDにマッチするフォルダーへのリード、ライト、デリートのアクセス(GetObject, PutObject, DeleteObject)を許可しています。 前章で説明したアイデンティティプロバイダのキーは、${www.amazon.com:app_id}といったように、AWSアクセス制御ポリシー変数を使うことができることにも注目してください。 このケースでは、ユーザーのユニークなAmazon.com IDを含む ${www.amazon.com:user_id} を使っています。 (変数を使う場合、Version属性に"2012-10-17"を設定しなければならないことも覚えておいてください。)
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":["s3:Get*"],
"Resource":["arn:aws:s3:::myBucket"],
"Condition":
{"StringEquals":
{"s3:prefix":["${www.amazon.com:app_id}","${www.amazon.com:app_id}/"]}
}
},
{
"Effect":"Allow",
"Action":["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource":[
"arn:aws:s3:::myBucket/${www.amazon.com:app_id}/${www.amazon.com:user_id}",
"arn:aws:s3:::myBucket/${www.amazon.com:app_id}/${www.amazon.com:user_id}/*"
]
}
]
}
全てをまとめる
これでロールが作成されましたので、エンドユーザーに統合されたアクセスを提供するためにロールがどのように使われるか見ていきましょう。
次の図はAmazon.comユーザーを認証し、ユーザーがS3バケット内のオブジェクトにアクセスする権限与える際に発生する手順を示しています。
- まず、ユーザーが認証される必要があります。"Login with Amazon" SDKを使って、アプリはユーザーを認証し、Amazonからトークンを受けとります。
- 次に、ユーザーはあなたのAWSアカウント内のリソースにアクセスできるよう、認証される必要があります。アプリは未署名の
AssumeRoleWithWebIdentityリクエストをSTSに作り、最初のステップで取得したトークンを渡します。STSはトークンが有効であるか検証し、トークンが有効であれば、STSは一時発行セキュリティ証明書のセットをアプリに返します。デフォルトでは、証明書は1時間有効です。 - 最後に、アプリはS3バケット内のリソースにアクセスするための署名済みのリクエストを作成するために一時発行セキュリティ証明書を使います。 ロールのアクセスポリシーはアプリIDとユーザーIDを参照する変数が使われているので、一時発行セキュリティ証明書はエンドユーザーにスコープが設定され、他のユーザーが所有するオブジェクトへアクセスすることを防ぎます。
今回紹介したのは、WebのID連携の使い方のひとつの例にすぎません。 同じような手順で、FacebookやGoogleのSDKを使って、これらのサービスとID連携することが可能です。 WebのID連携と他のIDプロバイダをサポートするロールを作成する方法についての詳しい情報については、 AWS STSガイドのCreating Temporary Security Credentials for Mobile Apps Using Public Identity Providersをご参照ください。
-- Jeff Wierer
【AWS発表】 Amazon RDS - リードレプリカの状態を監視可能に
Amazon RDSのMySQLは、簡単にリードレプリカを作成することができます。 リードレプリカはマスターデータベースインスタンスのスレーブとして動作します。特定の状況下では、レプリケーションが停止してしまうことがあります。例えば、マスターで行われたアップデートと競合するようなDMLクエリをレプリカ上で実行してしまい、レプリケーションエラーが発生するといった場合です。
このような状況を検出し、対応するために、本日より、Amazon RDSにリードレプリカのレプリケーションの状況を監視する機能を追加いたしました。何かの原因でレプリケーションが停止した場合、Replication StateフィールドにErrorがセットされます。Replication State Detailsフィールドから、エラーに関する詳細な情報を確認することもできます。
ステータスはAWS Management Consoleからもご覧いただけます。
エラーを安全にスキップできると判断した場合、CALL mysql.rds_skip_repl_errorコマンドを実行し、エラーをスキップすることができます。 そうでない場合は、エラーが発生したリードレプリカを削除し、同じ識別子(DB Instance Identifier)を持った新しいリードレプリカを作成することができます。(古いリードレプリカと同じエンドポイントが維持されますので、アプリケーション側の変更は必要ありません。) レプリケーションエラーが修正されると、Replication StateがReplicatingに変更されます。
レプリケーションエラーが発生した際、自動的に通知されるように、Amazon RDS イベント通知機能を使うこともできます。 さらに、Replication Lagメトリクスを監視することもできます。レプリケーションのラグが指定した特定の閾値を超えた場合、通知を受けとるよう、CloudWatchアラームをセットアップできます。
アプリケーションに最適なインスタンスタイプを選びましょう!
Amazon EC2は2006年のサービス開始からの約7年間、非常にトラフィックの多いウェブサイトやゲノム解析プラットフォーム、SAPアプリケーションといった、あらゆる規模のお客様にご利用いただいております。 これらの多くの事例を見ているとひとつの共通点が見えてきます。最も成功したアプリケーションやサービスの開発者は、アプリケーションに適したインスタンスタイプを選択するために、厳しいパフォーマンステストや最適化プロセスを実施しているのです。
今日は、お客様のアプリケーションに最適なインスタンスタイプを見つけるお手伝いをするために、いくつかの重要なEC2の概念を確認し、それから、EC2インスタンスファミリーを構成するインスタンスの各タイプを見ていきたいと思います。
重要な概念
まずは、皆様とスタート位置を合わせるために、いくつかの概念を見ていきましょう。
Amazon Machine Image (AMI) はオペレーティングシステム(OS)を含む動作環境を定義するテンプレートです。 1つのAMIから、1つでも数千でもお好きなだけの数のインスタンスを起動することができます。
インスタンスはコンピュートパワーを提供する、基本的なビルディングブロックです。 インスタンスは特定のインスタンスタイプのAmazon Machine Image (AMI)を起動することにより生成されます。 実行するインスタンスの数をオンデマンドで増やしたり、減らしたりすることができます。手動で行うこともできますし、Auto Scalingを使って自動でスケールさせることもできます。
インスタンスタイプは、さまざまなCPU、メモリ、ストレージおよびネットワーク容量の組み合わせがあり、アプリケーションに最適なリソースの組み合わせを選択できる柔軟性を提供します。 インスタンスタイプ毎に、異なるワークロードのサイズに対応する1つ以上のサイズオプションを持っています。 アプリケーションに最も適したインスタンスタイプを選択することで、最高のエクスペリエンスを得ることができます。(インスタンスタイプは起動後いつでも簡単に変更することもできます。)
インスタンスファミリーは、共通の目標を満たすよう設計されたインスタンスタイプの集合です。 アプリケーションに最適なオプションをより簡単に選択いただけるよう、Amazon EC2インスタンスタイプは、対象となるアプリケーションのプロファイルに基づいてファミリーにグループ分けされています。
vCPUは、仮想の中央演算処理装置(CPU)です。マルチコアプロセッサは2つ以上のvCPUを持っています。
インスタンスファミリーとインスタンスタイプ
現在、Amazon EC2は6つのインスタンスファミリーに分けられた、10の異なるインスタンスタイプから選択するオプションをお客様に提供しております。
お客様はアプリケーションに最適なインスタンスタイプとサイズの組み合わせを選択できる柔軟性を持ち、ビジネスやアプリケーションの要求が変わった際に、後から、いつでもインスタンスタイプを変更することもできます。では、どのようなインタンスファミリー、インスタンスタイプがあるのでしょうか?ひとつひとつ見ていきましょう。
一般的な目的: このファミリーはM1とM3インスタンスタイプを含んでいます。どちらのタイプも多くのアプリケーションに適用できるように、バランスのとれたCPU、メモリ、ネットワークリソースを提供します。 多くのお客様にとって、1vCPU、2GiBのRAMから、8 vCPU、30GiBのRAMの範囲のサイズを持つこのファミリーは、一番最初の選択肢になりえます。 中小規模のデータベース、多くのメモリを必要とするデータ処理タスク、キャッシュサーバ群に、SAP、Microsoft SharePointといったエンタープライズアプリケーションを実行するのに最適なリソースバランスです。
M3インスタンスは一般的な目的のインスタンスの最新世代で、より高いパフォーマンスを発揮できる、より多くの仮想CPU (vCPU)を利用可能です。 M3インスタンスはCPU要件の厳しい一般的な目的のインスタンスを探している場合にオススメです。 M1インスタンスは一般的な目的のインスタンスの最初のファミリーで、より低コストでアプリケーションを実行するオプションを提供します。 M1インスタンスはそれほどCPUパフォーマンスを必要とせず、全体的なコスト下げたい場合、選択するとよいでしょう。
コンピューティングを最適化: このファミリーはC1とCC2インスタンスタイプを含んでいます。高い計算処理パワーを必要とするアプリケーションを対象としています。
コンピューティングを最適化したインスタンスは、他のファミリーと比べて、メモリに対するvCPUの比率が高くなっており、全てのAmazon EC2インスタンスタイプの中で最もvCPUあたりのコストが低くなっています。 CPUに依存してスケールアウトするアプリケーションを実行している場合、まずはこのコンピューティングを最適化したインスタンスを最初に検討すべきです。 例えば、高トラフィックのウェブサイトのためのフロントエンドのサーバ群や、オンデマンドのバッチ処理、分散された分析、ウェブサーバー、ビデオエンコーディング、ゲノム解析のような高性能な科学および工学アプリケーション、流体力学計算などです。
CC2インスタンスは、コンピューティングを最適化されたインスタンスの最新世代であり、全てのAmazon EC2 インスタンスタイプの中でCPU性能あたりのコストパフォーマンスは最高です。 さらに、CC2インスタンスはIntel Xeon E5-2670 プロセッサ、高いコア数 (32 vCPUs)、クラスタネットワーキングのサポート、といった高度な機能を提供します。これらの機能を使って、240.09テラフロップのLinpackスコアを達成した1064のCC2インスタンスで構成したクラスタを構築することもできます。このクラスタは、2011年11月のTop500スーパーコンピュータリストで42位にランクインしました。
C1インスタンスは、コンピューティングを最適化されたインスタンスの最初の世代です。CC2に比べて小規模なサイズから利用可能で、大規模なスケールで大規模にスケールアウトするアプリケーションに最適です。ビデオのトランスコートや仮想薬物設計に1000台規模のインスタンスを起動するような例もあり、このような利用にC1インスタンスは活用されています。
メモリを最適化: このファミリーはM2とCR1インスタンスタイプを含んでいます。メモリを多用するアプリケーション向けに設計されています。 このファミリーのインスタンスは全てのAmazon EC2 インスタンスタイプの中でRAM 1GiBあたりのコストが最も安価です。 アプリケーションがメモリ依存の場合、このインスタンスを使うべきです。 例えば、高性能データベースおよび分散キャッシュ、インメモリ解析、ゲノムアセンブリ、より大規模なSAP、Microsoft SharePointといったエンタープライズアプリケーションのデプロイといった用途です。一般的には、パフォーマンス重視のデータベースを実行している場合、最初に検討すべきファミリーです。
CR1インスタンスはメモリを最適化されたインスタンスの最新世代で、M2インスタンスと比べて、大量のメモリ(244GiB)、高速なCPU( Intel Xeon E5-2670)を提供します。CR1インスタンスは帯域幅を多用するアプリケーションのためのクラスタネットワーキングもサポートします。
M2インスタンスはより小規模な用途に利用可能で、多くのメモリ依存なアプリケーションに最適なオプションです。
ストレージを最適化: このファミリーは、HI1とHS1インスタンスタイプを含んでいます。特定のディスクI/Oやストレージ容量要件を持つアプリケーションのために最適化された、直接接続されたストレージオプションを提供します。現在ストレージを最適化されたインスタンスは2つのタイプがあります。
HI1インスタンスは非常に高いランダムI/O性能を持ち、IOPSあたりのコストが安くなるよう最適化されています。 このインスタンスは120,000の4kランダムリードIOPSを超える性能を提供するため、トランザクションアプリケーションに最適です。 特に、CassandraやMongoDBのような大規模NoSQLデータベースのための最高のプラットフォームとして使えるよう、このインスタンスを設計しています。
HS1インスタンスは、非常に高い記憶密度、低いストレージコスト、高いシーケンシャルI/O性能を持つよう最適化されています。 HS1インスタンスは24のハードディスクドライブにまたがる48TBのストレージ容量を提供し、2.6GBpsのスループット性能をサポートすることが可能です。 このインスタンスは大規模なデータウェアハウス、常時稼動している巨大なHadoopクラスタ、クラスタファイルシステムのために設計されています。 当社のペタバイト規模のデータウェアハウスサービス、Amazon Redshiftの基礎となるインスタンスタイプでもあります。
マイクロインスタンス: マイクロ(別名T1)インスタンスは非常に低コストなインスタンスオプションで、少量のCPUリソースを提供します。 マイクロインスタンスは追加のサイクルが利用可能である場合、日和見的に、短時間であれば、CPU容量を増大させることができます。 踏み台サーバや管理用のアプリケーション、時間により追加のコンピュートサイクルが必要なるトラフィックの少ないウェブサイトのような、スループットの低いアプリケーションに非常に適しています。
マイクロインスタンスはAWS 無料利用枠の範囲内で利用可能なので、無料でEC2の機能をお試しいただけます。 マイクロインスタンスには日和見的なスケジューリングが使われているので、持続的なCPU性能を必要とするアプリケーションには利用すべきではありません。 マイクロインスタンスの特徴および適切なワークロードの特性に関するさらに詳しい情報については、Amazon EC2 ドキュメントをご覧ください。
GPUインスタンス: このファミリーはCG1インスタンスタイプを含みます。GPGPUコンピューティングのためのCUDA または OpenCLプログラミングモデルを使ったNVidia Tesla GPUの並列性能を活用することができます。 GPUインスタンスは高度なCPU機能およびクラスターネットワーキングも提供します。 AMBERのような分子動力アプリケーションで利用すれば、CC2インスタンスと比較して4、5倍のパフォーマンス改善が期待できます。 多くの方がGPGPUから得ることができる高速化を活用するために、CG1インスタンスで計算科学、レンダリング、財務分析アプリケーションなどを実行しています。
あなたの選択
この分類が皆さんのアプリケーションに最適なインスタンスタイプを選択する手助けになることを願っています。
必要に応じてインスタンスを起動・終了できますので、簡単、安価に、様々なインスタンスタイプをそれぞれプロファイリングしたり、負荷テストできます。
長期間にわたり、特定のハードウェア設定にロックインされる伝統的な環境とは異なり、ニーズの変化に応じて簡単にインスタンスタイプを変更することもできます。
継続的インテグレーションプロセスの一部として複数のインスタンスタイプをプロファイルし、マイナーリリース毎に異なるインタンスタイプのセットを使うといったことさえ可能です。
複数インスタンスタイプの可用性、EBS最適化のよな機能との組み合わせ、およびクラスターネットワーキングにより、アプリケーションの性能を増加させたり、信頼性を改善したり、コストを抑えたりすることができます。
具体的には、アプリケーションのための最も重要なパフォーマンスメトリクスを評価する必要があります。 CPUあたりのコストを下げることにより恩恵を受けられるアプリケーションであれば、コンピューティングを最適化されたインスタンス(C1またはCC2)を最初に試してみるべきです。 メモリ1GiBあたりのコストを下げる必要があるアプリケーションであれば、メモリを最適化されたインスタンス(M2またはCR1)をオススメします。 データベースを実行する場合、EBS最適化オプションまたはクラスタネットワーキングを活用することも考えてみてください。 高いノード間ネットワークを必要とするアプリケーションでは、クラスターネットワーキングをサポートするインスタンスを選択すべきです。 Amazon EC2のインスタンスタイプに対する全ての詳細な仕様について確認したい場合は、Amazon EC2 インスタンスの詳細ページをご覧ください。詳細を一覧でご覧いただけます。
私達の目標は、あらゆるアプリケーションのニーズにお応えできるインスタンスタイプを提供し続けることです。 是非皆様のフィードバックをEC2 forumまでお寄せください。
この記事が皆さんがアプリケーションに適したインスタンスタイプを選択する手助けになれば幸いです。
【AWS発表】 AWSがFedRAMPコンプライアンスを達成
AWSがFedRAMPコンプライアンスを達成いたしました。– これにより米国連邦政府機関は、AWSの評価・検証にかかる時間、コスト、リソースを大幅に削減することができるようになりました! セキュリティ評価の一部として、数千のアーティファクトを提供することにより、数百の規制への順守を実証した後、 AWSはFedRAMP-accredited third-party assessor (3PAO)により認定され、AWSが厳しいFedRAMP要件に準拠することを実証する、ATO (Authority to Operate)を取得いたしました。
米国政府に製品やサービスを提供している、多くの米国政府機関、システムインテグレータ、その他の企業が今日、AWSを利用しています。
本日より、全ての米国政府機関は、FedRAMPリポジトリ内にあるAWSの厚生省(HHS)のATOパッケージを活用することにより、アプリケーションやワークロードのためにAWSを評価し、AWSを使うための独自認証を提供し、あるいは、ワークロードをAWS環境に移行する時間、コスト、リソースを劇的に節約することができます。
政府機関や請負業者はFedRAMPパッケージへのアクセスリクエストフォームを提出して、AWS FedRAMPパッケージへのアクセスをすぐにリクエストし、AWSを用いるATOを取得するための認証プロセスをはじめることができます。
FedRAMPとは何ですか? この答えやよくある質問を知りたい方はAWS FedRAMP FAQ サイトをご覧ください。
【AWS発表】 AWS Elastic Transcoderに多数の新機能が追加!
Amazon Elastic Transcoderがリリースされてから、多くの皆様にフィードバックをいただいて参りました。(その多くはElastic Transcoder フォーラムからです。) これらのフィードバックを元に迅速にイテレートした結果、本日いくつかの強力な拡張機能をご紹介することができることをうれしく思います。
新機能は次のとおりです。
- Apple HTTP Live Streaming (HLS) のサポート.
iOSとAndroidデバイス、セットトップボックスやWebブラウザ上で互換性のあるプレーヤーに配信するためにHLS準拠のプリセグメント化されたファイルやプレイリストを作成することができるようになりました。
入力ファイルを複数のデバイス、解像度、ビットレートを対象とするためのアダプティブビットレートのファイルセットにトランスコードするために、新しくシステム定義されたHLSのプリセットを使えるようになっています。
また、独自のプリセットを作成することもできます。
- WebM出力のサポート.
コンテンツをVP8ビデオとVorbisオーディオにトランスコードできるようになりました。
これは、ネイティブにH.264とAACをサポートしていない、Firefoxのようなブラウザで再生することができるフォーマットです。
- MPEG2-TS 出力コンテナのサポート. コンテンツをH.264ビデオとAACオーディオを含んだトランスポートストリームにトランスコードできるようになりました。 このコンテナは、放送システムで一般的に使われているものです。
- 1つのジョブで複数の出力をサポート.
1つのトランスコーディングジョブで同じ入力から複数のレンディションを生成できるようになりました。例えば、複数のプラットフォームに配信するために、1つのジョブで、H.264、HLS、WebMのビデオを作成できます。フォーマット毎にジョブを生成する必要がなくなったので、非常にシンプルになりますし、時間も節約できます。
- ビデオのビットレートの自動最適化.
ビットレートの指定をautoにすると、トランスコードされた出力の画質を最適化するためにビットレートに自動的に調整するようになりました。
Amazon Elastic Transcoderはビデオコンテンツに最適なビットレートを推測し決定します。
- アスペクト比とサイジングポリシーの拡張.
トランスコーディングのプリセットで、新しい設定が使えるようになりました。
スケーリング、トリミング、マット、ストレッチングといったオプションを指定でき、入力フォーマットに関係なく、希望の出力を手に入れられます。
- 出力ビデオのためのS3オプションの拡張.
Amazon S3のAPIやコンソールを使う必要なく、S3のAccess Control Lists (ACLs)とストレージタイプのオプションを設定できるようになりました。
この機能を使うことによって、ファイルが正しいパーミッションで作成され、すぐにエンドユーザーに配信できる状態にすることができます。
これらの新機能についての詳細については、Elastic Transcoderのドキュメントを参照ください。また無料のwebinar、What's New with Amazon Elastic Transcoder (英語)も日本時間の5/30 2:00 AM に開催されます。
いつもどおり、今日ご紹介した新機能は本日よりご利用可能となっております!
【AWS発表】 AWS OpsWorksに3つの新機能が追加。ELB、管理ビュー、マイクロインスタンスも対応!
本日は、AWS OpsWorks チームの Chris Barclay からAWS OpsWorksno3つの新機能について紹介いたします。
アプリケーション管理をより簡単にしてくれる、Elastic Load Balancingのサポート、スタックのAmazon CloudWatch メトリクスを監視するビュー、追加のAmazon EC2インスタンスタイプのサポートの3つのAWS OpsWorksの新機能を紹介できることをうれしく思います。
Elastic Load Balancing のサポート
アプリケーションのトラフィックを複数のインスタンスに自動で分散させるために、Elastic Load Balancingをご利用いただけるようになりました。OpsWorksアプリケーションとElastic Load Balancingを一緒に利用するメリットは次のようなものがあります。
- Elastic Load Balancing が自動的に、アプリケーションのトラフィックに応じて、リクエストの処理能力を調整します。
- Elastic Load Balancingを使うことで1つのDNS名で信頼性のための複数のAZにまたがる構成を簡単に構築できます。
- リクエスト数やリクエストレイテンシーのようなElastic Load Balancing メトリクス がAmazon CloudWatchによりレポートされます。
- SSL証明書がIAM証明書を使って格納されます。これにより、誰が秘密鍵を参照可能か制御することができます。
利用方法は簡単です。EC2コンソールでELBを作成し、Rails アプリのサーバーのような負荷分散したいレイヤーにELBを追加するだけです。 レイヤーは固定のインスタンスプールを持つこともできますし、負荷や時間に基づいてキャパシティを増減できるインスタンスベースのスケーリングを使うこともできます。 OpsWorksはロードバランサーと連携して自動的にレイヤーへのインスタンスの追加、削除をしてくれます。
監視ビュー
新しい監視ビューはアプリケーション上で稼動しているインスタンスの状態を見るのに便利な方法です。
OpsWorksはインスタンス毎に、CPU、メモリ、負荷といった13の1分単位のメトリクスを送ります。
メトリクスは自動的にグループ化され、スタックのレイヤーによってフィルタリングされます。
時間間隔を指定したり、閲覧したい特定のメトリクスを選択したり、詳細を見るために特定のインスタンスをドリルダウンすることもできます。
追加のインスタンスタイプのサポート
OpsWorksはEBS-backed EC2インスタンスをサポートいたしました。
開発の必要に応じてより多くのインスタンスタイプを選択いただけます。
今回の発表で、AWS無料利用枠に提供対象であるマイクロインスタンスが含まれたことになります。
すぐにはじめましょう!
本日紹介した3つの機能は全て、AWS Management Consoleから数クリックでご利用いただけます。
AWS OpsWorks Webinar (英語) (5/24 3:00 AM JST)もございますので興味がある方は是非ご覧ください。 このwebinarでは、継続的デプロイのためのキーコンセプトとデザインパターン、AWS OpsWorksやChefのようなテクノロジーを使ったインテグレーションについて学ぶことができます。
-- シニアプロダクトマネージャー Chris Barclay
【AWS発表】 AWS Management Pack for Microsoft System Center
Windowsが稼動するEC2インスタンスをより簡単に監視できる新機能が登場いたしました。 今日は、その詳細をAmazon EC2 Windows チーム ジェネラルマネージャー Tom Rizzoからお伝えいたします。
AWSをWindows自身の実行とWindowsのワークロードを行う最適な環境にするための継続的な努力により、 本日、AWS環境でより簡単にWindowsを実行、管理できる機能の発表をすることができます。 AWS Management Pack for Microsoft System Center です。
Microsoft System Centerと一緒にAWS Management Packを使うことで、ひとつのコンソールから、オンプレミスとAWSリソースの両方を閲覧、監視することができるようになります。 AWS Management Packを使って、EC2インスタンス (Windows および Linux)、Elastic Block Store (EBS) ボリューム、Elastic Load Balancing、CloudFormationのスタック、Auto Scaling グループ、Elastic Beanstalk アプリケーションを監視することができます。 あらかじめ組み込まれているCloudWatchにより、パフォーマンスの状況を確認したり、AWSリソースが設定した閾値を超えた際にアラームを取得したりすることができます。 さらに、Microsoft SQL Server、Microsoft SharePoint Server、 Microsoft Exchange ServerのようなEC2のWindowsインスタンス内で実行されているアプリケーションを確認、監視することもできます。 AWS Management PackはEC2のタグも扱えますので、複数のAWSリージョンにまたがったAWSリソースをフィルタリングしたり、検索したりすることもできます。 最後に、リソースはAWSのアベイラビリティゾーンにマッピングされ、どのリソースがどのゾーンに配置されているかがわかりますので、簡単にシステムの可用性とディザスタリカバリの状況を把握することができます。
オンプレミス、AWSクラウド、どちらのリソースも1つの画面から閲覧、監視ができるツールとして、AWS Management Packをお使いください。
皆様がすぐにお使いいただけるよう、簡単な紹介ビデオも用意いたしました。
AWS Management Pack はこちらからダウンロードいただけます。是非お試しいただき、次のようなわかりやすい画面でリソースを管理できることをご体験ください。
-- Amazon EC2 Windows チーム ジェネラルマネージャー Tom Rizzo
【AWS発表】 EBS プロビジョンドIOPSが最大4,000 IOPSまで指定可能に。AWS Marketplaceもサポート
EBS プロビジョンド IOPSボリュームが最大4,000 IOPSまで指定できるようになったことをお知らせいたします。 これは昨年のリリース当初の数値の、実に4倍になります。 プロビジョンド IOPSは現在、1ボリュームあたり、最大4,000 IOPSの性能と、1TBのストレージ容量まで設定できることになります。 今回の発表で、4,000 IOPSまでの性能であれば、(RAID0のように)複数のボリュームをストライプする必要がなくなります。 もちろん、4000IOPS以上のさらに高い性能が必要な場合は、従来通りストライプすることもできます。
また、AWS Marketplaceでもプロビジョンド IOPSのサポートを開始いたしました。 10Gen, NuoDB, Omnibondの新製品でご利用いただけます。 今回のサポートにより、ご希望の性能を指定しながら、1クリックで必要なソフトウェアを見つけて、比較し、開始することができるようになりました。 さらに詳しい情報については、新設いたしましたAWS Marketplace プロビジョンド IOPSのページをご覧ください。
今までの経緯をまとめます。 (1秒あたりのI/O性能を測定した値、IOPSという単位で)ボリュームのI/O性能をお好みの値に設定できる、プロビジョンド IOPS機能を昨年8月に発表いたしましたが、その時に、1ボリュームあたりに設定できるIOPSの最大値は、1,000 IOPSでした。 その後、よりパワーと柔軟性をご提供するために、年内に倍の2,000 IOPSまで上限値を引きあげました。 そして本日、さらに倍の4,000 IOPSにまで引きあげたことになります。
プロビジョンド IOPS ボリュームはデータベースやビジネスアプリケーション、エンタープライズアプリケーションといった、I/O集中が激しい利用のために、予測可能な高パフォーマンスを提供するよう設計されています。 必要な性能を自身で設定でき、一度設定するとEBSはボリュームが削除されるまで、一貫してその性能を提供します。
プロビジョンド IOPS ボリュームのパフォーマンスを最大限に引きだすために、 EBS 最適化 EC2インスタンスとの併用を推奨しています。 EBS 最適化オプションは、m1.large, m1.xlarge, m2.2xlarge, m2.4xlarge, m3.xlarge, m3.2xlarge, c1.xlargeのインスタンスタイプをご利用時に選択可能で、EC2インスタンスとEBSボリューム間に専用のスループットを用意するオプションです。
Amazon EBS プロビジョンド IOPS ボリューム、EBS 最適化インスタンス、AWS Marketplaceの製品はGovCloudを除く全てのAWSリージョンでご利用いただけます。
検索
このブログ内の記事を検索
Brought to You By
このブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。 @horiuchiをフォロー
2013年6 月
アーカイブ
- 2013年6 月
- 2013年5 月
- 2013年4 月
- 2013年3 月
- 2013年2 月
- 2013年1 月
- 2012年12 月
- 2012年11 月
- 2012年10 月
- 2012年9 月
- 2012年8 月
- 2012年7 月
- 2012年6 月
- 2012年5 月
- 2012年4 月
- 2012年3 月
- 2012年2 月
- 2012年1 月
- 2011年12 月
- 2011年11 月
- 2011年10 月
- 2011年9 月
- 2011年8 月
- 2011年7 月
- 2011年6 月
- 2011年5 月
- 2011年4 月
- 2011年3 月
- 2011年2 月
- 2011年1 月
- 2010年12 月
- 2010年11 月
- 2010年10 月
- 2010年9 月
