AWSをめぐる「驚き」と「誤解」～Amazon Web Services入門(1)

本稿のねらい

　筆者はここ数年、AWSのエンタープライズ利用について、お客さまから多種多様なご相談やお問い合わせをいただいている。その中には、残念ながら、依然として単純な誤解や思い込みに基づくものが散見され、検討を進める際の大きな壁となっているケースがある。また、AWSの特徴について、しばしば過激な表現が出回っており、これが感情的な違和感や拒否感を生み出している面もある。いずれにせよ、そのような状態ではAWS利用について前向きな結論は出てこないだろう。一方で、世間ではAWSのユーザーが急速に増大していることや、そのメリットが（ユーザーの側から）喧伝されていることは伝わっており、何が正しいのか、どう考えればよいのか、検討の現場にはある種の困惑があるのも事実のようだ。

　本章では、AWS利用の検討に際し、ありがちな「驚き」や「誤解」（思い込み）を列挙しつつ、それぞれについて簡単な解説を加えていく。見出しのキーワードは比較的筆者の耳によく飛び込んでくるものを選んだ。FAQ的な構成を企図しており、本書の他の章と重複する項目もあるが、この章では簡単な解説にとどめ、詳細は本書の別の章で詳述する。

【驚き系】
・AWSはいつでも利用規約を変更できる
・データが漏洩したらユーザーの責任
・SLAはユーザーに厳しい制約が
・契約の基本は英語、裁判所は米国
・個別契約には応じません
・30日後にサービス撤退するかも
・驚きに関するまとめの解説（なぜこれでOKなのか）

【誤解系】
・パフォーマンスが心配だ
・データセンターの場所がわからないとダメ！
・パトリオット法があるから、AWSは使えない？
・なんとなく怖い
・誤解に関するまとめの解説（誤解を解くカギ）

AWSはいつでも利用規約を変更できる

　AWSの利用を始めるに当たっては、利用者は、AWS社が提示する利用約款に合意したことになっている。実際に約款を見たか否かは無関係だ。約款はWebに掲載されているが、そこに「合意する」ボタンなどの確認手段があるわけでもない。使い始める以上、合意したということである。

　約款にはAWS社側の義務のみならず、利用者側の義務についても触れられている。あまり精読せずに使い始めたとしても、実際のところは、これは利用者とAWS社の間の契約行為となる。

　この約款を初めて通読したとき、いろいろと驚かされる事項が多かったのをよく覚えている。いまとなっては当然のこととして十分理解できているが、それでも第三者（特にお客さま）にご説明する際には誤解を招かないように相応の配慮をするようにしている。説明の順序を間違えると、感情的な反発を招きかねないからである。

　約款に関する最もベーシックな「驚き」は、その約款自体をAWS社側が任意のタイミングで変更できるという点だ。それでは契約として意味を成さないではないかという話である。そしてそのようなサービスは使えない（使いにくい）という結論になりやすい。

　しかし、AWS社自体は何万（何十万）という広範なユーザーに極めて単純なサービスを提供している。個々のユーザーと1対1の交渉でなんらかの合意を取りつけているわけではないのだ。当然、約款の変更も同様だ。約款の変更が必要になったとき、AWS社が一方的に変えられなければ、意味がないとすら言える。

　改変後の約款を受け入れられないユーザーは、利用を止めるという選択肢がある。ユーザーには利用を継続する義務はないので、これはオペレーションとしてはいつでも実行可能だ。オンプレミスとは違って、いわゆるベンダー・ロックイン問題も深刻な障壁とはならないだろう。さまざまな技術により、他のクラウドへの引っ越しも現実的な選択肢となりつつある。

　実際問題として、過去にユーザーに著しく不利となるような約款の変更は行われていない。クラウド間の競争も激しいので、トッププレーヤーたるAWS社としても顧客が離れてしまうような改定は極めて困難といえるだろう。

　約款が我々（ユーザー）の合意なしに変更されることが明記されていたとしても、それはAWS社にとって一方的に有益というわけでもなく、ユーザーにとって一方的に不利というわけでもない。約款には、ただ、そのような事態があり得ることを淡々と書いてあるだけなのだ。この項に関して大きな問題が生じることは考えにくい。

データが漏洩したらユーザーの責任

　データ漏洩の責任はユーザーにあるという記述は、最も刺激的な部分かもしれない。データが漏洩してもAWS社は責任を負わない。万が一漏洩すれば、その責任は誰にあるのか。プレーヤーは2者しかいないことは自明だ（AWS社とユーザーだ）。AWS社に責任がなければ、当然、漏洩の責任はユーザー側にあるということになる。

　ここで「なるほど、もっともだ」と思う人は（現時点では）そう多くない。「私（ユーザー）の大事なシステムをAWS社が預かっておきながら、そのデータを漏洩させてもAWS社は無責任とはどういうことだ」というのが自然な反応だ。従来の類似のビジネス（データセンター事業や、レンタルサーバー事業）では、当然のように事業者側に守秘義務があり、「だからこそ」我々は安心してシステムを預けたのではなかったか。これをAWSはどう整理しているのだろう。現実に多数いるユーザーは、どう納得しているのだろう。

　詳細は「責任分界」のところで解説するが、実はAWS社は「データを預かっている」という認識はなさそうだ。「データの置き場所を提供している」という認識はあるかもしれないし、その運用を高い水準で維持することに集中していることは間違いないが、「データ」そのものには興味がない。ユーザーが上記の「置き場」に、どのようなデータを、どのようなアクセス管理で置こうが自由自在だからである。

　たとえば、ユーザーはAWSを使ってオープンな情報を世界中に発信することができる。逆に非常に重要な情報をAWS上に保管して、厳密に限られた人間しかアクセスできないように防御を徹底させることもできる。無論、ここでユーザーが設定を間違えれば、その情報はインターネットに垂れ流しになる。冷徹に言えば、ユーザーには、そのような「自由度」が与えられているのだ。

　また、ユーザーが利用するサーバー（インスタンス）のルート権限はユーザーだけに与えられる。わかりやすく言えば、ルートのパスワードをユーザーが変えてしまえば、それはAWS社にはわからないし、以後、AWS社側はOSにはアクセスできなくなる。当然、OSの上のデータにもアクセスできないという理屈である。

　「データを格納しているディスクをAWS社が裏側から直接見ることはできるじゃないか」という指摘はあり得るが、現実的とは思えない。そもそもそのようなことをするメリットがAWS社側になさそうだ。よしんば、それを懸念するとしても、有効かつ平易な防御手段もある（この点は後述する）。

　ユーザーが、自由度の高い設定のミスをしたり、平易にできる防御手段を講じなかったりすれば、ユーザーは万が一の漏洩の際の責任から免れることはできない。これはこれで自然な考え方であり、合理的な考え方でもある。

SLAはユーザーに厳しい制約が

　AWSのSLAは、サービス毎に定義されている。一番利用頻度の高いEC2で言えば、（ある条件下で）「99.95％」と記載されている。1カ月で言えば、停止時間が約20分を超えれば、SLAに抵触することになる。では、この稼働率に達しなかった場合、ユーザーはどのような補償が得られるのかというと、実はほとんど得られないことがわかっている。99.95％を下回っても、99.0％以上であれば、月額利用料の10％が割り引かれるだけだ。99.0％以下でも30％である。月額利用料といってもEC2の利用料分だけと推察されるので（他にサービスの利用料を含めた総額ではないので）、額としては大した金額にはならないだろう。

　「月に20分も止まれば大損だよ」というシステムもあろう。しかし、そのような営業上の損失は一切補填されない。データセンター事業者の場合では、営業上の損失が発生した場合には、その補填含めて「真摯に交渉する」旨の契約がなされる場合もあると聞いているが、AWSについて言えば、そのような余地は一切ない。もちろん、AWSとデータセンター事業者を同列に比べることは間違っている。また、このようなSLAの特性は、他のパブリッククラウドにおいても同様であり、AWSだけの特殊事情というわけではない。

　もっと言えば、このSLAは、1ユーザーが使っている単一のEC2（仮想サーバー）に適用されるものでは「ない」。「個別のインスタンスまたはボリュームの障害の結果生じた」障害はSLAの例外事由であるとキッパリと明記されている。「私が借りているサーバーに障害が起きて、利用できなくなっても、私が補償されないとはどういうこと？」と思うだろう。確かに障害の発生はユーザー側では防ぐことはできない。サーバーが利用できなくなっても、ユーザーには瑕疵がない。それなのに補償されないとは、すぐには理解しがたいところだ。

　しかし、よく考えると、実はAWS側にも、特段の瑕疵があるわけではない。障害は偶発的に発生する。それは純粋に確率事象であって、誰にも予見はできない。防ぐ手段はなく、発生の瞬間にAWSに過失などがあるわけではないことは明らかだ。では、誰が、どのような責任で、何をすべきか。もう少し建設的に議論を進めてみよう。

　後の章で「故障を前提とした設計」を解説するが、ここでは短い説明をしておこう。上記のような偶発的な単一障害に備え、AWSは、「物理的に他のサーバーに乗り換える手段」と「他人が使っていない余剰のリソース」を準備している。直裁的に言えば、障害が発生したEC2を捨て去り、新たなEC2に乗り換える手段である。この機能の提供はAWSが自らに課した義務といえる。そしてユーザーは、適切なタイミングで上記の手段を行使することが求められる。「必要があれば行使すること」、これはユーザーの義務である。手段を行使しない（したくない）のであれば、その程度の可用性を受け入れたということなのだ。

　このように、AWSの稼働率は「ユーザーとAWSが一体となって作り上げるもの」なのである。手段はAWSが低価格で用意している。SLA＝99.95％という表現は、それ自体が一人歩きしており、見かけの数字の高低や補償の少なさが取り沙汰されることがあるが、数字にこだわることは従来的な（自由度の低い）データセンター事業が主流だった時代の発想であり、これをAWSに適用するのはほとんど意味がない。補償が足りないなら、つまり高い稼働率が必要なら、それに応じたエンジニアリングによってAWSを駆使し、耐障害性の高いシステム設計をすればよいのだ。

　従来型の（オンプレミスの）システムでも、無停止に近い状態を確実に作り出したいのであれば、それ相応のコストとエンジニアリングを必要とする。AWSでも（実現手段は違うが）基本的な考え方は同じである。きちんとエンジニアリングを行えば、SLA（99.95％）の前提条件となっている使い方を超え、さらに高い可用性が期待できる構成も組むことができる（当然、価格はやや上がる）。可用性は低くてもよいので安く使いたいユーザーもいるし、少々追加費用を払っても、高い可用性が必要なユーザーもいる。AWSは、どちらにも対応できるということだ。