Amazonがクラウドに関する「都市伝説」に反論、「AWSの真実」とは?

Amazonによると「クラウドより既存のデータセンターやプライベートLANの方が安全である」「高信頼度・耐障害性ということを考えるとクラウドは使えない」「クラウドに基幹の業務システムは乗せられない」という言説は「都市伝説」だと考えているとのこと。つまり、正しくない、と。
これは「次世代ディザスタリカバリを成功させるアマゾンクラウド活用法」ということで、東京国際フォーラムで開催された「Cloud Computing World Tokyo 2011」&「Next Generation Data Center 2011」において講演されたもので、Amazon EC2をはじめとするAWSについてのプロモーションも兼ねており、非常に参考となる内容になっています。
以下がその講演を再現したものです。
人だらけ

ぞろぞろ

あのAmazonの講演なので出席率がこれまた異様に高い


アナウンス「『次世代ディザスタリカバリを成功させるアマゾンクラウド活用法』と題しまして、アマゾンデータサービスジャパン株式会社のエバンジェリスト/技術推進部長の玉川 憲氏に来て頂きました」

皆様こんにちは

今日は台風が向かっている中、雨が降るかもしれないという中でこれほど多くの人に集まって頂き本当にありがとうございました。

本日の話の内容ですが、『次世代ディザスタリカバリを成功させるアマゾンクラウド活用法』ということで、震災以降注目されているITサービス計画として、ディザスタリカバリをクラウドを用いてどのように実現していくかという事を話していきたいと思います。
これまでにも、ディザスタリカバリは行われてきたのですが、ディザスタリカバリを行うための巨額のインフラへの投資や固定資産を持たなければいけないといったことや、震災などが起こるかどうかわからないにもかかわらず、前もって投資を行わなければいけない、さらに調達を行うにもデータセンターやサーバの調達に数ヶ月もしくは半年、長ければ1年2年とかかっていた状態で、また、中核の業務以外の人員も割かなければならない、そういった観点では、マネージメントの観点から検討すると現時点でのディザスタリカバリソリューションというのは非常に柔軟性がなく、コスト効果に疑問があるといったことをよく私の方にお話しされる事があります。

まず、ディザスタリカバリを行うにあたって確認しなければいけない事として「ゴール」を決めるというのがあるのですが、「ゴール」と言うのを何を指し示すかというと、「目標復旧時間」であり、事象が起きてからどれほどの時間で復旧できるかということと、失っても良い時間幅ですね。例えば、データ復旧まで5分ならば許せるのか?それとも2時間ならば許せるのか?といった目標にあわせて最適なコストがあるので、非常に高い要求をするならば、高いコストがかかっても仕方が無いわけです。若干許容できるならば、コストを抑えて実現したいと考えているわけです。

ただ、現状そのような要求を満たすソリューションというのは非常に限られているわけです。そういう中で中小企業にとっては、「あまりお金をかけたくないのに、そこまでの金額がかかるならやらなくても良い」となり、大企業などは巨大な費用を投資してディザスタリカバリを実現するというのが現実だと思います。
そんな中で、クラウドが今非常に注目されています。クラウドの持つ柔軟性もさることながら、クラウドベンダーが集中的に投資したデータセンターの堅固性や、何かしらの事象で交通網が遮断されてもリモートから操作でき、節電や停電対策もできるということからクラウドがディザスタリカバリに非常に使えるといった期待感と共に我々は多くの案件を頂いております。

しかし、日本市場の中では様々な懐疑的な意見も存在しており、我々はそれを「都市伝説」と呼んでいますが、例えば、「クラウドより既存のデータセンターやプライベートLANの方が安全である」また「高信頼度・耐障害性ということを考えるとクラウドは使えない」、「クラウドに基幹の業務システムは乗せられない」これを我々は都市伝説だと考えております。

まず、アマゾンウェブサービスとは何なのかを5分ほどまだご存じのない方に説明をしまして、Amazonのクラウドを用いたディザスタリカバリシステムの構成にはどのようなやり方があるのかという事をご説明します。そして最後に「都市伝説」と「都市伝説」にまつわる真実をお話ししたいと思います。

では、早速ですが、皆さんアマゾンで本を買われたことがある方ってどれくらいおられますか?(会場内で複数人挙手)

ありがとうございます。手を上げなかった方は「楽天派」と考えても大丈夫ですかね?(笑)

アマゾンはリテールビジネスを1995年からやってきて、3つのビジネスをやってきております、もう1つのビジネスとして存在しているのが、Eコマースの売る場所をお貸しするビジネスで、これもアマゾンのサービスです。もう1つがリテールされてきたデータセンターを自主運用してきたのですが、そこで培ったノウハウを生かしてコンピュータリソースをインターネット越しに利用して頂く、しかも完全従量課金制としてまるで電気やガスや水道を利用するかのようにコンピュータリソースを使って頂くという事を行っております。

こちらが、Amazon Web Service、略してAWSとして2006年からビジネスとしてやっているものです。あまりご存じない方の為に、一番有名なサービス、Amazon Elastic Compute Cloud、略してAmazon EC2の話をしたいと思います。

まず、どのように使用するかといいますと、アマゾンで本を買うのと同様に、ウェブ上でアカウントを作成してクリックしていけばすぐにサーバが使えるようになります。具体的にはアマゾンのデータセンターの中にサーバのコピーの様な物、これを我々はマシンイメージと呼んでおりますが、そのマシンイメージがたくさん用意されており、それを選んで頂き、次にサーバのスペックを選んで頂くとすぐにWindowsであれLinuxであれ数分以内に立ち上がってすぐに使えるようになります。金額的には初期投資は必要なく、使った時間に応じて課金されるようになります。

1台でも10台でも100台でもWindowsでもLinuxでもOracleのデータベースでも、そういったものが乗ったものがすぐに利用できるわけです。そして、サーバだけではなく外付けハードディスクの様なクラウドサービスもあり、1ギガから1テラまでギガバイト単位で存在しており、こちらに書き込んだデータというのはサーバを停止しても消えないようになっております。
もう1つおもしろいのは、皆さん、サーバを起動した際に自身で様々なソフトウェアなどをインストールを行うと思いますが、そのサーバのイメージを作ることが可能で、そのサーバイメージを別のサーバにコピーして使用することも可能となっており、そのマシンイメージを使用して別のスペックのサーバにマシンイメージを入れてそのスペックで立ち上げ直すことも可能になっております。
ここで、ご存じない方のために私がこの場でサーバを調達してみたいと思います。

こちらがアマゾンのウェブ上の管理ツール、マネージメントコンソールと呼ばれている物ですが、EC2などの様々なサービスが選べるようになっております。

このEC2の中でリージョン(地域)が選べ、「西アメリカ」「東アメリカ」「ヨーロッパ」「シンガポール」「東京」が選べるようになっております。今回は「東京」を選びます。

そうしますと、私が今もっているサーバが表示され、現状4台持っているのがわかります。

稼働している物もあれば停止している物もあります。

ではここで今からマシンを調達します。ボタンを押してマシンイメージを選びます。

WindowsであれLinuxであれ、時間課金の中にライセンスが含まれています。次に選ぶのはマシンスペックです。ハードディスクも2ギガ・4ギガ・8ギガ・20ギガとなっており、メモリもこのように選べます。

ちなみに、1台のサーバの一番低いスペックの物を選んだ際にかかる時間課金は1.6円となっております。その金額で自由に使うことが可能になっております。次にサーバの台数を選びます。今回はデモのため2台を選びます。

そして、詳細な設定として、秘密鍵の設定や、ファイアーウォールの設定を行い、最後に「launch」ボタンを押します。そうすると今からサーバの課金が始まりサーバが使えるようになります。

実際に今確認すると、2台がPendingの状態になっておりますが、今サーバが稼働しようとしているわけですね。

(次の瞬間)もうRunningになりましたね。このスピードでサーバが使えるようになります。

これまでは、サーバを発注して、納品されて、設置して、電源を確保して、インターネット回線を引いて、などの時間のかかる作業が、今この短時間で出来てしまったわけです。しかも初期投資がかからなく、使った時間だけ課金され、後で月ごとに使った分だけ請求されるという仕組みになっています。
ちなみに、こういうテクノロジーを生かした会社はこういったことをしております。アメリカの会社ですが、ウェブアプリサービスをお客様に提供しており、Facebookで公開した後ものすごい人気がでて5000台のサーバを調達して使っております。

しかも、4月18日~4月20日の3日間で5000台調達しております。これはクラウドだからこそ可能であり、お客様の増加に合わせてインフラを増加しております。どんな人気なサービスでもピークを越えると人気が低下してしまうため、すぐにやめることも可能です。

もう1つの例としてウォール街の金融系の会社ですが、こちらの場合は、夜だけですが株式市場を分析してアナリストレポートを作ります。その使用として夜だけ3000台、昼は300台として昼間にサーバを落として使用料金を落としているというわけです。こういったことが可能になってきます。

このサービスは2006年から提供しており、様々なお客様の要望を取り入れており、今やストレージサービス、コンテンツ配信サービスなどのサービスも充実させており、今や10種類以上ものサービスをお客様に提供しております。

また、アマゾンのロゴを見て頂くと、アマゾンウェブサービスは違うロゴをもっていまして、ブロックのようなロゴですが、これはお客様がビジネスとかアプリケーションを作るときに我々のサービスを適宜好きな物だけを選んでもらって素早く安くこのようなアプリケーションを構築して頂きたいと、そういった想いがこもったロゴになっております。

全世界で190カ国以上、数十万のお客様に使って頂いており、アメリカ政府だと20省庁以上で使って頂いており、メーカー系、金融系でも使って頂き、スペインのトップ銀行であるバンキンターでも使って頂いております。

もちろん中小企業からベンチャーまで広く使って頂き、日本では2011年3月3日に東京データセンターを構築しましたが、
日本市場のお客様にとっては日本の国内から高速なネットワークを使い、国内にデータを安全に管理でき、また日本語での24時間365日のサポートも始めております。

実はこの東京データセンターが出来る前から日本の多くのお客様にお使いになって頂いておりますが、現時点で既に数千のお客様に使用して頂いており、こちらはその事例の一覧となっております。代表的な例として、三井物産様がSAPの開発検証として使用。オリンパス様が写真の共有サービスとして使用、リクルート様がスーモという住宅ウェブサイトとして使用、東芝様は家電のファームウェア配布として使用しています。様々な企業様にご使用して頂いていることがわかります。また、一番下に大阪府の吹田市観光ウェブというものがありますが、官公庁のウェブサーバとしても利用して頂いているわけです。

こちらは、具体的な価格帯が出ている事例です。クロスマーケティング様の例だと80台のWindowsとLinuxのサーバを調達しようとした試算した例です。最初に自前で用意した場合、初期投資がかかるといったようになっておりますが、さらに運用コストを見てみても、実はEC2の方が安かったといった結果が出ており、電気代、ネットワーク代、さらに人件費といったもろもろを試算してもこういった数値が出てくるという結果になりました。

最後にまとめますと、メリットとしては非常にキャッシュフローに効くこと、そしてビジネスの迅速な立ち上げ、またピークが来たときも迅速に立ち上げられ、やめるときも迅速な撤退が可能という事になります。

ここから、本題であるディザスタリカバリの話をしたいと思います。

ディザスタリカバリですが、従量課金で瞬時に調達可能なサービスを組み合わせると非常に柔軟なディザスタリカバリ構成がとれます。これまではディザスタリカバリのために他のデータセンターを調達するか否かしか選択がなかったものが、いろいろな組み合わせの選択が可能になったのでお客様のゴールとかけたいコストにあわせた柔軟な選択が可能になってきます。

これを紹介する前に簡単にディザスタリカバリに重要になってくるサービスを説明いたします。

まず「S3」ですが、シンプルストレージサービスというもので、インターネットストレージと呼んでいるサービスです。どういうものかと説明しますと、EC2と同様にリージョンが東京含めて選択可能です。そしてその中にバケットと呼ばれる箱を作ることで、画像であれ、HTMLファイルであれ、どのようなファイルも保存することが可能です。ネット上へアップロード可能するだけで、もちろん暗号化などを行って保存することも可能です。

ネット上からアップロードするだけなので、特にインフラなどを全く気にせずにアップロードする事が可能になります。ここに保存されたデータは東京ならば東京に分散配置されたデータセンターに自動コピーが行われ、99.999999999%の11桁の耐久性となっており非常に耐久性の高い物となっております。これは1万個のファイルを1千万年の間、保存しても失われないほどの耐久性となっており、実際に今まで4000億個以上のファイルを預かっていますが、未だに一度も損失したことがないという実績があります。
もう1つの特徴は非常に安価な従量課金です。例えば10テラバイトのストレージを購入してバックアップを取る場合、購入したストレージの費用がかかりますが、S3の場合は保存した容量と期間で課金されます。10テラバイトの場合、1ヶ月で10万円程度となり、半月ですと5万円程度になります。ストレージを購入した場合、最初から10テラバイトのバックアップを保存するわけではないと思いますので、非常に有効な方法だと思われます。
次にEC2ですが、EC2も仮想サーバのサービスであり、通常起動している状態の場合は起動時の課金となり、時間あたり1.6円となるので、スペックの高いサーバの場合は1時間10円となったりします。それと保存容量の課金となりますと、だいたいS3と同じ程度の料金となっており1ギガバイトあたり10円強程度になります。起動しているとその料金形態になりますが、低スペックのサーバに瞬時に切り替えることが可能なので、10円のサーバから1.6円のサーバに切り替えることも可能です。さらにサーバの停止をしておくとディスクの料金だけかかりますので、サーバを停止しておいてもすぐさま立ち上げることも可能です。




ですので、一旦停止してからディスクの使用料金だけを払うということも可能になるわけです。もう1つの方法として、サーバは完全に停止してしまうが、バックアップのイメージを作成しておき、そこから立ち上げることが出来るという事も可能であるため、こういった様々なオプションを選ぶことも出来ます。
さらにディザスタリカバリの重要なサービスがこのDNSサービスです。名前解決のシステムが停止してしまうと、切り替えようにも切り替えられない状態になってしまいます。このRoute 53サービスはアマゾンが全世界19個所に持っているキャッシュロケーションに分散した名前解決サービスです。稼動率は100%で、1ドメインあたり1ドルなので、日本円になおすと約80円程度となります。

こういった、EC2、S3、Route53サービスを組み合わせて使用して頂く事で、様々なディザスタリカバリシステムを構築することが可能です。
本日はコストやどういったゴールにあわせて、どういったシナリオがあるかを整理してみました。

まず、データをバックアップする事だけを目的とした場合。
既存のデータセンターにデータがあります。そのデータをアマゾンのS3のサーバの中にデータを保存するだけです。また、大量のデータをインターネット越しにアップロードするのが難しいのであれば、インポート/エクスポートサービスを使ってハードディスクを送ってもらえれば(Amazonの)サーバに直接接続してデータをアップロードすることも可能です。

今現在、アマゾンのAWSに向かってデータを転送する場合は数ヶ月前より無料にするといったアナウンスをさせてもらっており、バックアップをするだけの場合は無料なのです。だいたい1テラバイトのデータを1ヶ月保存すると1万円程度となり、かなりお得な状態となっております。
次に、データバックアップをしたとしてもデータセンター自体が復旧出来ない状態。つまり、データをバックアップから戻せないといった場合にEC2を使うケースの説明をします。これを行うためには、まず最初にRoute53を使ってあらかじめ名前の解決をしておきます。これはすぐさまに切り替えるために行っておきます。次にデータをS3にあらかじめ保存しておいて、EC2にマシンイメージを用意しておきます。もし何かが起きた場合、AWSからEC2を起動して、データをS3からEC2に転送を行い、名前解決を切り替えることで万が一サーバが壊れた場合でも、EC2上に復帰する事が可能になるといったようになります。しかも、普段はEC2のサーバを停止しているためほとんど料金がかからず、S3のデータ保存量金だけがかかります。実際にEC2のサーバを使ったときだけ料金がかかるといったからくりになっております。

もう少し早く回復したいといったお客様の場合、データベース部分が気になることが多いと思います。常にデータベース部分については最新の状態でバックアップを行いたいといった場合ですね。まず既存のデータセンターにアプリケーションサーバやウェブサーバ、データベースサーバがあるとします。そうするとAWSの中にデータベースサーバを立てておき、アプリケーションサーバやウェブサーバは停止しておきます。データベースサーバのスペックはかなり低い物で、同期の目的のためだけに準備しておきます。

そうすることでコストを抑えておき、何か起きた場合、AWS上にアプリケーションサーバやウェブサーバを起動して、データベースサーバは本番環境にあわせてスペックの高い物に切替を行います。そして、名前解決のサーバの切替を行う事で、恐らく数分で切替が可能と考えられます。


さらに、もっと早く回復させるために、ホットスタンバイさせたいという場合があるかと思います。この場合は、アプリケーションサーバやウェブサーバを既に起動した状態、低スペックの状態で動作させておきます。また、上位でロードバランシングする事で常に使用している状態にしても良いかと思われます。このような状態で何か起きた場合、AWS上に用意したアプリケーションサーバやウェブサーバを高いスペックのサーバに切り替えることで、すぐさま対応が可能かと思われます。

また、それよりももっと復帰までを早くしたい場合。既存データセンター内と同様スペックのサーバをAWS内に用意して、ロードバランシングで「50%:50%」の使用率で常に動作させておく事で、何があってもすぐさま対応可能となります。
このようにシナリオ毎で確認していくと、コスト、復旧時間、データの復旧時間までにそれぞれ特徴が出てくるかと思います。

最初の方のシナリオだと、コストは安く復旧時間まではかかるといったこと、逆に後の方のシナリオだと復旧時間までは早いがコストはかかるといった具合になってくるわけです。大事なことは、コストとゴール、最適なトレードオフはどこか?というところになってきます。
ここでもう1つ気になるのが、既存のデータセンターをもう持たなくてもいいのではないか?という人も増えてきており、実際に本番環境とクラウドに分散してデータを持って行けるのであれば、データセンターが契約切れするタイミングで全てクラウドに移行してもいいのではないか?といった事が起きてきております。
ただし、その際に耐障害性が気になってくるのです。「もしクラウドに障害があった場合どうなるのですか?」といった疑問が出てくるのですが、そういったお客様のためにEC2の場合はリージョンの中にもゾーンというものを設けており、これは実際には地域的に離れた実物のデータセンターを指します。

つまりそのようなデータセンターが複数存在していることで、その中でサーバを分けてたてることが可能になっております。

つまり、システムを地理的に分散して動かすシステムを既に確立しております。ですので、ゾーンA、ゾーンBと分けてシステムをたてて、ロードバランサーで振り分けておき、データベースだけ同期しておく、という事が既にAWS内で出来るようになっております。

また、今まではサーバを例にして説明しましたが、個人のPC環境でも同様のサービスを行う事ができ、Windows、Linux、Debian、Ubuntuなどといった様々なディストリビューションに対応しているため、デスクトップ環境を保存しておき、何かあったときには、EC2を利用して業務を行う事も可能です。

最後にディザスタリカバリのポイントとして押さえておきたいのが、まずはシンプルに初め、徐々に最適化していくことだと思います。いきなりマルチサイトで冗長的に運用していくとなっていくと難しいかもしれませんので、まずは最初にメーターを一通りとってみて、その次にRTOを考えながら継続的に改善していくと言うことをお勧めしていきたいと思います。

後は、ディザスタリカバリの確認をしていくことが必要かと思います。訓練日みたいなものを設け、実際に切り戻してみてデータが大丈夫かなどを自分の目で確認してみるという事が重要になってくると思います。しかも、AWSの場合、立ち上げたときのみお金がかかるので、その訓練日だけの料金で済むため、非常に微々たるものになると考えております。

最後に「都市伝説」と「AWSの真実」のお話をしたいと思います。

・クラウドよりも既存のデータセンターやプライベートクラウドの方が安全である。
・高信頼度を扱うシステムにクラウドは不向きである。
・基幹の業務システムはのせられない。
この1つ1つをお話ししたいと思います。

まず、AWSはセキュリティをトッププライオリティとして考えております。そして、グローバルなベンダーとして、多大な投資をセキュリティ向上のために投資を行っております。皆さんが安心して使って頂けるように、第三者機関から認証をできる限り多く取得出来るようにしております。SAS70 TypeII、ISO27001、最後のPCIDSSプロバイダ認証、これははクレジットカードのセキュリティ情報を扱うようなベンダーが取るべきような認証ですが、これをクラウドベンダーとして取得しているわけです。

もし仮に、「既存のデータセンターの方が安全だ」といったときに1つの評価視点として、この第三者機関認証と同じくらいの認証を取得しているデータセンターがそう言うのであれば、我々も「そうなのかもしれない」といったことになるのですが、これに相当する認証を取得しているベンダーはほとんど無いと思います。ですので、これは1つの評価の視点になるのかな、とは考えております。
もう1つはプライベートクラウドと同じで、インフラ部分はAWSが全ての努力を注ぎ込んで安全を守りますが、その上の部分である、ネットワーク部分のファイアーウォールの設定であったり、データをどのようにして暗号化しておくかというのはお客様に自由度があります。

自由度があると言うことはこれまでと同じようにしっかりと設定・運用して頂くということになります。ファイアーウォールの設定、root権限でサーバを使用しますので、逆に言うと、お客様がroot権限の秘密鍵を失うと、我々はもうそのシステムにアクセスする事は出来なくなります。ですが、それだけ安全だと取って頂ければ助かります。また、データ通信を行う際のSSLとか暗号化通信といったところはこれまでと全く同様です。つまりこれまで培ってきたセキュリティのノウハウをAWSを使って生かして頂ければと思います。

次に「耐障害性を高めるにはパブリッククラウドは不向きだ」といった「都市伝説」があります。これは「クラウド」という言葉があまりにも広範囲で使用されているため、あるメールサービスであったり、SaaSのサービスを考えると、確かにデータのコントロールが出来なかったり、停止してしまうとどうしようもなかったりと、そういうことも確かにありますが、AWSの場合は、こういった耐障害性を高めるための自由度を複数用意しております。実際に震災時に多数のサイトがAWSに移行もしくは平行運用を行う事で厳しい状況を乗り切った実績があり、AWSを利用することで、既存のデータセンターやサーバが対処できなかった急激なトラフィック増加などに対し、迅速に対応できたという実績があります。


もう少し中身を見ますと、AWSのEC2が置いてあるデータセンターはリージョンという中のくくりで捉えられます。そのリージョンの中を見てみますと、EC2のために異なるデータセンターを複数配置しているわけです。S3のためにも異なるデータセンターを複数配置しているわけです。

EC2の場合、このこのアベイラビリティゾーンを好きなように選べるので、を好きなように選べるので、冗長構成をとってシステムをより耐障害性を高めるためのソリューションというのが皆さんで構築することが可能です。そして、こういったデータセンターを複数置くためのポリシーなのですが、お互いが物理的に隔離されていて、洪水面的にみても同じ位置になく、地盤が非常に安定していること、無停止電源・バックアップ電源を備えていること、燃料の優先契約があること、そして冗長化されたTier-1ネットワークを持っていること、こういったもの全てを兼ね備えたデータセンターを用意しています。

最後にパブリッククラウドには業務システムは乗せられない、こういった話があると思いますが、実際には、主要なビジネスアプリケーションを既存ライセンスでAWSに持ち込むことは可能です。これはアマゾンがグローバルベンダーとして、様々な主要ベンダーと協業して実現しています。

例えばOracle様のOracleアプリケーション、Oracle DBはEC2の上で起動出来ますし、既存のライセンスを持ち込めます。またRDSというリレーショナルデータベースのクラウドサービスを使用されると、時間単位でOracleのデータベースを使用することが可能です。これは他のベンダーでは出来ていないことですね。検証の時だけ時間単位でOracleのデータベースを使用して、本番環境になったときは既存ライセンスを持ち込み、使用することが出来ます。
また、マイクロソフト様、こちらはライセンスモビリティという制度の中にデータベースも組み込みました。そうなると、既存のデータセンターで使用している商用サーバ、シェアポイントやエクスチェンジ、そう言ったライセンスをAWSへ持ち込むことが可能です。
SAP様からは、各種ソリューションをEC2の上で動かしてもこの稼働を保証するというリリースを出しました。これは基幹業務の代表格であるSAP様がクラウドにお墨付きを与えた、と非常に業界でも話題になっております。
もう1つ、様々なサーバイメージをVM Wareであったり、Xenサーバであったり、Hyper-Vなど、そういった形で持っていると思います。AWSはそういった場合でも最大限の活用をして頂けるように、Widnows 2003 ServerもWindows 2008 Serverも全てのフォーマットの組み合わせのサーバをEC2にインポート出来るようにしています。ですので、お客様がそういった資産を持っていれば、すかさずそれEC2の上に持っていって動かすことができる、つまり移行の手間が非常に省けるのです。もちろんエクスポートもやっております。現状ではEC2上のWindows 2008 ServerのイメージデータをVM Wareのイメージ形式でエクスポート出来るようにしておりますが、今後もインポート、エクスポートの組み合わせというのは最大限努力して増やしていきたいと考えております。

また、社内のシステムをパブリッククラウドに持って行きにくい、社内のIPアドレスが使えない、そう言ったような要望を受けたりもしますが、既に今月から東京リージョンでヴァーチャルプライベートクラウドというサービスを始めております。
これはどういうものかと説明しますと、EC2の中の一部を隔離します。そしてその中でサーバを立てられるようにします。そしてその領域に対して御社のイントラからVPS接続して頂き、御社のIPアドレスを振って頂き、御社の環境で使用して頂く事が可能というサービスです。
既存のデータセンターを拡張する際に、サーバの拡張はなく、VPN接続を用いてVPCを作成してその中にサーバを作って頂き、必要なときだけ、10台、20台と使用して頂く、といったことが可能になっています。

さらに専用線接続のサービスも始めており、御社の持っているデータセンターなどからアマゾンの持っているウェブサービスに対して専用線接続をする事が可能になっております。1Gbps、10Gbps、もしくはその複数の組み合わせで専用線接続をして頂くことで、その帯域保証をさせて頂きます。

なので、クラウドといってもまさにプライベートクラウドと同じセキュリティレベルで、コスト面で見ても初期費用がかからず必要なときだけ使用できる、といったことが実現できるようになっているわけです。専用線接続は既にアメリカではサービスが始まっておりますが、日本では今年度を目処に計画をしております。
また、これもおもしろいのですが、EC2のような仮想サーバがセキュリティ的に非常に良いものだとわかっていても、コンプライアンス的に1つの物理サーバ上に他社のサーバと混在することはできないというお客様もいます。そういったお客様のために、ハードの占有サービスとして、デディケイテッドインスタンスというのも始めました。通常のEC2インスタンスの場合、1台の物理サーバの上にハイパーバイザーが入って仮想サーバが複数立ちます。つまり、B社のサーバがA社のサーバと並ぶことがあります。

これは基本的には完全に隔離されているので問題にはならないのですが、コンプライアンス的には問題になってくるので、これを解決するため、A社様の乗っている物理サーバの上には他社のサーバを一切のせない、というサービスです。
これはある料金を払って頂くとデディケイテッドインスタンスというものをVPCの中で使って頂く事が可能です。




ここまで様々な「都市伝説」に対するAWSの真実ということでお話させて頂きました。

本日は40分という短い時間でしたがご静聴頂きありがとうございました。

・関連記事
Intel副社長がクラウドの講演「次の10年を支えるデータセンター基盤とは」 - GIGAZINE
「Amazon EC2」と「Amazon S3」を実際に使ってみたので、まずはアカウント作成まで - GIGAZINE
「Amazon EC2」と「Amazon S3」を実際に使ってみた、今度はEC2の操作環境セットアップ - GIGAZINE
「Amazon EC2」と「Amazon S3」を実際に使ってみた、最後はカスタムAMI作成・登録・削除編 - GIGAZINE
・関連コンテンツ
in 取材, ネットサービス, Posted by darkhorse
You can read the machine translated English article Amazon counterclaims "urban legend" on t….