AWSでは、さまざまなスペック、OS、ミドルウェアを持った仮想サーバのインスタンスを、ほんの数分でインターネット上に確保できる。利用申し込みなどは基本的にWebサイトで行う。設定後は特定の認証方式を用いてアクセスすれば、インターネット上にあるインスタンスを自由自在に利用できる。利用しなくなったらサーバ単位で瞬時に解約が可能で、解約したときから料金は発生しない。

　インスタンスは申し込み時のスペック、OS、ミドルウェアを備えた“素”の状態で提供される。利用に際してはユーザー自身の責任でアプリケーションなどを作り込む必要がある。

　なお、同じ設定のインスタンスを頻繁に利用したり解約したりする場合に備え、イメージをAWS上に保持しておける。

　利用できるインスタンスのスペックについて以下に簡単に紹介する。

※カリフォルニアのデータセンターを利用し、OSとしてLinux／UNIXを選択した場合

　標準的に準備されているOSとDBMSには以下のようなものがある。

　詳細はAWSのWebサイトをご参照いただきたい。

伸縮可能

　例えばトランザクションの負荷変動が激しいアプリケーションの場合、従来のオンプレミス型システム構築であれば最大ピークに耐え得るだけのサーバをあらかじめ購入して所有する必要があった。また、アプリケーションの利用が終了した後も自前の資産としてサーバを保有し続けるのが一般的であった。だがAWSを使えば、繁忙期には利用サーバ（インスタンス）を増やし、閑散期には利用サーバを減らし、サービス終了時には完全に解約してしまうという利用方法が可能である。これは次のような用途に向いている。

• キャンペーン用Webサイト

新商品の宣伝・告知など1、2カ月でピークが集中し、その後は不必要になるキャンペーン用Webサイトなど

• オンラインゲーム

平日の日中はほとんど利用されず、夜間や週末に多数のユーザーにアクセスされることが多いオンラインゲームのようなサービスなど

• 季節性サービス

年度末の1カ月だけであるとかお盆の期間だけ利用され、ほかの時期はほとんど利用されないような季節性の高いアプリケーションなど

VPC

　AWSにはVPC（Virtual Private Cloud）というサービスがあり、これを用いるとAWS上に確保したインスタンスを、あたかも自社のLANの延長線上にあるかのようにアロケートできる。これによって管理コストを削減し利便性を大幅に改善できる。多少の技術的な制約はあるためWANとして利用するには十分とはいえないが、以下のような用途には適合している。

• バックアップ用のストレージを確保するエリア
• 期末処理などのピーク対応として、一時的にハイエンドのサーバを確保するエリア

汎用性

　提供されるインスタンスのスペックなどは、一般的かつ汎用的なものであるため、現在オンプレミスで利用しているアプリケーションなどを移植するのは難しくない。新しい言語や環境に習熟する必要はほとんどなく、ほかのクラウドに見られるようなデータ容量、開発言語、トランザクション量についての制限も一切ない。いわば、「インターネット上に自前の環境をもう1つ持つ」ことが簡単に実現できるのである。この特性を生かし、次のような利用も有益と考えられる。

• 開発環境

社内システムの開発などにおいて、一時的に社内環境と同じものを用意する必要がある場合

• DRの待機系

災害などによって社内システムがまったく利用できなくなる事態に備え、同様の環境をいつでも利用可能な状態で保持しておきたい場合

ストレージ

　ストレージサービスは、容量無制限の従量課金制で提供されている。申し込めば利用可能になり、上限値については申請する必要がない。利用すれば利用するほどGバイト当たりの単価が安くなる仕組みである。保管されたファイルはすべてURLで管理され、世界中に公開したり、管理者が指定するユーザーにのみ閲覧／更新させることもできる。CDN（Content Delivery Network）のようなキャッシュサービスも利用可能であり、これを使えばアクセスが集中してもエンドユーザーにはストレスがない。これらのサービスは、例えば次のような用途に適合する。

• 拠点間で共有するファイルサーバ

社内マニュアルや共有文書などを保存しておくための「ファイルサーバ」としての利用

• マニュアルやドライバ、パッチなどのダウンロードサービス

新製品のマニュアルなど世界中に公開し、不特定多数のユーザーが一斉に参照する可能性がある電子データの置き場所としての利用

Hadoop

　AWSは、Hadoop（データ分散処理技術）との相性の良さでも知られている。実際、AWS上に仮想サーバを30～100台確保し、大規模なバッチジョブをHadoopで処理させることによって、通常では数カ月掛かるような処理を1日で終わらせたという事例が多数報告されている。同じことをオンプレミスのハイパフォーマンスコンピュータで実行しようとすると、恐らく数けた上のコストが発生するだろう。既存のプログラムをHadoopに載せ替ええることは平易ではないが、新規開発やワンショットでの大規模処理などにおいて、一定のノウハウさえあれば圧倒的なスピードとコストダウンが見込める技術である。今後の利用シーンの拡大に期待したい。

不得意分野

　サーバ（インスタンス）については「一般的かつ汎用的」な環境しか用意されないため、逆にいえば特殊な環境にあるアプリケーションを移植しようとする際には、手間取る可能性がある。例えば古いOSやDBを利用していたり、ハードウェアに特有の機能に依存したツールを多用している場合などである。特に自前で作り込んだ管理ツールなどは、存在自体が不明確だったりドキュメントが整備されていなかったりするので、注意が必要だといえる。

　ストレージについてはWeb型であるため、それ以外の、例えばWindowsファイルサーバのようなシームレスな利用をするには一工夫必要である。

　また、クラウドとはいえ、あくまでもHaaS、PaaSにすぎず、システム構築のスピードアップ／コストダウンに効いてくるのはサーバおよびストレージの調達部分と運用部分のみといえる。その上に載せるアプリケーションの開発手法には従来的な手法しかあり得ず、この部分については（例えば次回紹介するForce.comのような）大きなブレークスルーは期待できない。

　負荷状況に応じたコンピュータリソースの利用／解約について、伸縮可能という点は言及したが、実際にはユーザーが意図的にインスタンスの追加／削除を行う必要がある（注）。Google App Engineで用意されているような「負荷状況に応じて自動的に処理能力が追加される」機能は現段階では準備されていない。最近はこれらの作業を自動で行うようなツール類が充実してきており、手間自体は今後軽減される可能性は高いが、言うまでもなく（自動で）追加されたインスタンスにも課金されるので留意が必要である。

注：2010年6月22日追記。AWSにおいても、各種ツールを使うことでインスタンスの追加／削除を半自動化することが可能。ツールはサードパーティからさまざまなものが提供されている。AWS自体も「Auto Scaling Command Line Tools」を提供している。

　技術面ではないが、前述のようにAWS自体のデータセンターは世界4カ所とされており、その中に日本は（現時点では）含まれていない。「クラウドでデータを社外に置くのはOKだが、海外では困る」という場合には時期を待つ必要がありそうだ。

将来性

　AWS社は日本のエンタープライズユーザーの開拓を望んでいる。また、多くの日本企業が日本でのデータセンターに安心感を抱くことをAWS社は熟知している。同社の日本進出は時間の問題といって過言ではないだろう。

　以上、簡単ではあるがAWSの特性を概観した。クラウドを利用したシステム構築の参考になれば幸いである。次回はForce.comを取り上げる。