前回、AWSの概要についてお話しました。そこで疑問を持った方もいらっしゃるはず。「AWSは信用できるのか、できないのか」。
このごろは、クラウドでシステムやサービスを構築している例も多く、AWSやその他のクラウド（Google Cloud、Microsoft Azure）で障害が発生すると、人々の生活に大きな影響が出て、話題になります。人命に関わる騒ぎではないものの、不便を感じますし、何やら不安になりますね。
また、最近では減りましたが、「クラウド破産」がエンジニアの間で話題に上ったこともありますし、そもそも「セキュリティは大丈夫なの？」と思う向きもあるでしょう。
第2回の今回は、「AWSは便利そう。でも、なんかクラウドって不安なんだよなー」とモヤモヤしている疑問に答えます。
サーバが事故ると、大ニュース！
AWSに限らず、サーバに大規模な障害が起こると「あのゲームがアクセスできない！」「このサービスが使えない！」と大きな話題になります。そりゃそうです。15年前に比べ、スマートフォンが全国の全年齢層に広がった今、我々の生活は、常にインターネットにつながっています。そしてネット上の何らかのサービスを使っている時間も非常に長くなりましたね。
たとえば、それ以前は、電車の中でオフラインの携帯ゲームや書籍での読書をしていた人たちも、今はオンラインでスマホを触っていることがほとんどです。待ち合わせのときも、定食屋でちょっと生姜焼き定食を待っている間にも、少しでも退屈な時間があれば、我々はスマホをいじっています。
短い時間以外にも、WordやExcelのようなOfficeツールをオンラインで使ったり、ネットで調べられなければ、仕事にならないという方もいらっしゃるでしょう。コロナ禍になってからは、オンライン会議も増えました。
常にドップリとネットに浸かる生活を送る我々は、どれか1つのサービスが使えないだけでも、大変不自由に感じます。そうすると、できる限りサーバは落としたくないわけですが、AWSも時折騒ぎになっており、「クラウドって大丈夫なの？」となるのも無理はありません。
サーバが事故るといろいろな影響がでる
リージョンとアベイラビリティゾーン（AZ）
「AWS（クラウド）って大丈夫なの？落ちないの？」という疑問に対しては「構成による」が、正直な回答です。具体的には、「落ちないサーバなんてないから、お前が冗長性を取っているかどうかだ！！」というところです。
これだけでは、いくらなんでも乱暴なので、AWSの冗長性の仕組みについて解説しておきましょう。
AWSではサーバとデータセンタを世界中の26の地域（2022年1月現在）に置いています。この地理的分類を「リージョン」と言います。我々ユーザがサービスを受けるときは地域（リージョン）を指定します。もちろん、日本にもあります。東京リージョンと大阪リージョンです。
リージョンは、サービス提供の母体のことですが、簡単に言えばデータセンタの単位でもあります。そしてこのリージョンは、さらに複数のアベイラビリティゾーン（AZ）で構成されています。AZは、ザックリと建物と考えるとわかりやすいでしょう。AZは、それぞれ電力源やネットワークなども独立した存在で、数キロメートルは離れている設計です（ただし、100km以内に集まっている）。
つまり、「東京リージョン」を選んだ場合、東京近辺にある複数のAZのどれかに自分のデータが置かれるというわけです。そして、このAZは複数選ぶことができます。そうです。冗長化です。
図 各リージョンに複数のアベイラビリティゾーンがある
AWSに障害が起こった場合、「○○リージョンのAZの1つに障害が発生」のような言い方をすることがほとんどです。これは、AZが物理的に独立しており、1つのAZの障害が他に影響しないことが多いからです。
逆を言えば、複数のAZに冗長化してあれば、1つのAZに障害が発生しても、大丈夫ということです。ですから、「お前が冗長性を取っているかどうかだ！！」なのです。
AZは、複数選ぶことができますが、義務ではないですし、顧客によっては「大丈夫！大丈夫！俺は運がいいから！」などと障害の起こりやすさを舐めているケースもあります。AZが複数で構成（マルチAZ）されているか、それとも1つだけ（シングルAZ）の冒険野郎なのか。AWSが安全かどうかは、将に設計次第なのです。
なお、東京全体に大規模な天災などがあれば、いくらAZが分かれていても、厳しいでしょう。ミッションクリティカルなサービスの場合は、リージョン（地域）を分けてしまうのが一般的です。
AWSのセキュリティってどうなの？
さて、クラウドの不安と言えば、「セキュリティが心配」というものもありますね。自社以外で管理するということに、漠然とした不安のあるケースもあるでしょう。
これも、冗長化の話と同じで、「お前がセキュアかどうかだ！！」と言ったところです。
オンプレミス（自社でサーバなどのインフラを維持・管理して運用すること）と、レンタルやクラウドを比較した場合、セキュリティ的にどちらが優れているのかは難しい問題です。なぜなら、オンプレミスの場合は、「自社の基準」であるからです。
サーバを安定して運用するには、サーバをファイアウォールで守ったり、OSやソフトウェアのアップデートをして脆弱性をふさいだりするなど、日々のセキュリティ対策が欠かせません。意識の高い管理者が運用している場合はよいのですが、ノウハウがない人が運用すると作業漏れが発生したり、長い間アップデートをせずに放置したりと、危険な状態になります。
一方、AWSのマネージドサービスでは、ソフトウェアのアップデートなどの運用作業は自動で行われるため、「一定の水準」が期待できます。
また、そもそも、プログラムはAWSではなく、自分たちが作っているのですから、そこに脆弱性があったらアウトです。ですから、「お前がセキュアかどうかだ！！」なのです。
クラウド破産と費用管理（コスト管理）
さて、クラウドと言えば、費用の話もあります。従量制とは言え、「ちょっと実験のつもりだった」を放置した結果、「大量の請求が来て、クラウド破産」という騒動が起こることもあります。
では、クラウド破産を防ぐためにどうしたら良いでしょうか。
そろそろ展開が見えてきた方もいらっしゃるかもしれませんが、「クラウド破産するしないは、お前が管理するかどうかだ！！」です。
とはいえ、AWSには、ちゃんとコスト管理するための仕組みがいくつか用意されています。
請求情報とコスト管理ダッシュボード（請求ダッシュボード）の画面からは、請求書や、支出ステータスなどが確認できますが、中でも「Cost Explorer（コストエクスプローラー）」と「Budgets（バジェッツ）」の存在を知っておくだけでも違います。
Cost Explorerは、月にどのくらいコストがかかっているのか、サービス単位で調べられるサービスです。コストは、月次だけではなく日次でも出せますし、グラフで表示されるため、金額の増減を直感的に把握できます。
Budgetsは費用が特定のしきい値を超えたときに、アラートを発行できるしくみです。また、Eメールで、予算ポートフォリオの更新を受け取ることも可能です。
ですから、これらのサービスをきちんと利用し、適切にAWSリソースを管理していれば、クラウド破産は防げますし、いくらアラートが来ていても、メールを見過ごすようでは対策になりません。「お前が管理するかどうかだ！！」なのです。
詳しくは、『図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書』第3章をご覧ください。
すべてはあなた次第なのです！
さて、今回は、AWSのモヤモヤについてお話しましたが、如何でしたでしょうか。
AWSには、色々な仕組みが備わっており、ユーザをサポートしてくれる仕組みも多いのですが、やはりサーバ管理の主体は人です。せっかくの良い仕組みがあっても、ユーザがよく理解していなければ、豚に真珠となってしまうでしょう。そこは、オンプレミスの非クラウドサーバでも、レンタルクラウドであっても変わりません。
文中の図は『図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書』より引用しております。おかげさまで発売後わずか2年ですが、10刷を迎える大ヒットとなりました。
この連載は、その10刷記念として企画されたものです。書籍のほうもよろしくお願いしますね！
