EC2インスタンス 料金表

超絶見やすい料金表をまとめて頂いている方を見つけたのでメモ。

Under the MOON: Amazon EC2料金早見表

料金は$1 = 100円換算で計算してある、とか注意点はあるみたいですが、とても見やすくインスタンスタイプを俯瞰してどれを使うのが自分に取って最適かを考えるにはとても役立ちそうです。

Consolidated Billing - AWS の複数アカウントの支払いを管理する

AWS で複数のアカウントをプロジェクトごとなどに作っていくと管理が大変になって行くことが予想されますが、そのためにアカウントごとの支払いを一つの親アカウントにまとめる昨日として、Consolidated Billing というものがあります。
試しに今回登録してみたところ、サインアップ時にAWS Consolidated Billing Guide というドキュメント（なぜかドキュメントの一覧ページにはリンクが見つからないけど・・）があると書いてあったので読んでみました。
いくつか注意点もあるので詳細はドキュメントを確認したほうが良いと思いますが、個人的に気になった点をいくつか羅列。

1. Consolidated Billing によってボリュームディスカウントが効く。
   統合した全てのアカウントで計算してボリュームディスカウントを適用するようなので単純に規模の経済、が成り立つということになるようです。
   たくさん利用している人に取っては積極的にConsolidated Billing の利用を検討する理由になり得ますね。
2. リザーブドインスタンスのシェアが可能
   統合した全てのアカウントでのリザーブドインスタンスが使い回せるのでコスト削減効果が見込めます。ただし同じアベイラビリティゾーンに限るという条件があるようなので詳細はドキュメントを参照の事。
3. Premium Support は個別にも使えるし全体で契約する事もおそらく可能？（一括契約が可能かどうかは不明。）
4. DevPay 絡みは対象外
   DevPay利用者にとってはConsolidated Billing でlinked account になっても自分のアカウント（で登録してある支払い方法）で払わなくては行けない部分が出てくるので注意が必要。

ボリュームディスカウントが効くほど人気のサービスを作って左うちわで暮らしたいものですね。

EC2 上でのディスク復旧手順（EBS-Backed 限定）

仮想サーバーを使い始める前に思いつく疑問として、ディスク（仮想サーバーの場合ディスクイメージですが）が壊れてしまった場合、どうやって復旧するのか、というものがあると思います。

VMWare や他の仮想化システムに慣れ親しんだ人からすれば、ディスクイメージさえ取れればなんとか復旧できる、というのは自明かもしれませんが、EC2 上で実際にどういう手順で復旧が行われうるのか、というのをAlestic がFixing Files on the Root EBS Volume of an EC2 Instance - Alestic.com にて書いていたので、簡単にまとめてみました。

先に簡単に流れを説明すると、

1. 問題のインスタンスID を確認
2. 問題のボリュームIDを確認
3. 復旧作業用の別インスタンスを起動
4. 問題のインスタンスを停止
5. 問題のEBS ボリュームをデタッチ
6. 問題のEBS ボリュームを別インスタンスにアタッチ
7. 復旧作業を行う
8. 元のインスタンスにアタッチして起動を試す

という流れになります。注意点等も多いので下記の詳細を読んで理解した上で進めてください。

どういうときに使えるか。

1. ssh key を無くした、ログインパスワードを忘れた、等
2. /etc/sudoers を編集ミスしてroot になれなくなった
3. 長時間走らせて来たインスタンスがハングして繋がらなくなった。ブートもうまく行かない。
4. ファイルシステムが壊れ、復旧もうまく行かない。別マシンでfsck 等したい。

注意点

1. ルートボリューム（起動ディスク）がEBS でないと適用できない。
   EC2 特有ですが、S3-Backed（S3 に置いてあるAMI をベースにしたインスタンス起動。インスタンスストアとも呼ばれる。）とEBS-Backed（文字通りEBS からの起動）の特性から、EBS-Backed でないと他のインスタンスにそのディスクイメージをアタッチしたりできないのでS3-Backed で起動しているインスタンスの場合はここで諦める事になります。
2. バックアップがあってそちらを復旧してしまったほうが早ければそのほうが良いかもしれません。（これは物理サーバーでも言える事ですが。）このへんの見極めは慎重に。

手順
※ 元記事から若干、手順を書き換えています。Alestic.com の記事と合わせて比較してお読みください。

1. 問題のインスタンスID を確認
   壊れたEBS ボリュームを起動ボリュームにしているインスタンスのインスタンスID を確認します。ここでは、仮にこれをi-BROKEN とします。
2. 問題のボリュームIDを確認
   問題のインスタンスにくっついている起動ボリュームを確認します。マネジメントコンソールからも確認できると思いますが、コマンドラインで以下のようにしても出来るようです。コマンドの意味が分からない人はパイプに渡さないで一つ一つ確認しましょう。
   $ ec2-describe-instances i-BROKEN | egrep '^BLOCKDEVICE./dev/sda1' | cut -f3
   ※ 上記コマンドでは/dev/sda1 を指定していますがこれはひょっとしたらOS、起動方法などによって異なるのではないかとも思います。
   ここではこのボリュームを仮にvol-DAMAGED とします。
3. 復旧作業用の別インスタンスを起動
   適当なLinux インスタンスなど自分が使いやすいものを起動します。このインスタンスのIDを仮にi-RECOVERY とします。このインスタンスに問題のEBS をアタッチするため、同じアベイラビリティゾーン内に作る必要があります。
   もちろん既に動いているインスタンス等でも構わないです。
4. 問題のインスタンスを停止
   $ ec2-stop-instances i-BROKEN
   にて、i-BROKEN を停止します。間違ってもterminate はしないようにしましょう。terminate はデフォルトではEBS-Backed のインスタンスであれ、起動に使ったルートボリュームを削除してしまいます。焦っていても落ち着いて、stop をするように注意しましょう。
   terminate とstop の違いがわかっていない方は先にそこをクリアにして置いた方が良いかもしれません。
   また、ディスクが問題を抱えているため停止までに時間がかかるかもしれません。ステータスがstopping などのままあまり長時間経過してしまうような場合には、フォーラムにインスタンスID を含め書き込んでサポートしてもらう手順もあるようです。プレミアムサポートサービスもあるのでそちら経由でサポートしてもらうことも出来ると思います。
   なお、running 以外のステータスでは課金されない（日本語訳が微妙ですが、英語ページでは、Instance-hours are billed for any time your instances are in a “running” state. となっているので間違いありません。）ので気持ちに余裕があれば1日2日（？！）じっと待ってみるのも良いかもしれません。
   --force オプションというのもあり、これも試す価値はありそうです。
   $ ec2-stop-instances i-BROKEN --force
   ※ --force オプションはWindows では推奨されないようです。というかそもそもLinux 等でも推奨されないとは思いますが。その他の注意点を含め、詳しくはec2-stop-instancesのマニュアルをご参照ください。
5. 問題のEBS ボリュームをデタッチ
   $ ec2-detach-volume vol-DAMAGED
   問題となっているEBS ボリュームをアタッチされているインスタンスから引き離します。
   こちらも--force オプションが使えるようです。注意点などについては ec2-detach-volume のマニュアルを参照。
   また、「Firefoxのadd-onであるElasticfoxをご利用いただくと、マウス操作でforce detachを行えるようです。」とのこと。
6. 問題のEBS ボリュームを別インスタンスにアタッチ
   $ ec2-attach-volume --instance i-RECOVERY --device /dev/sdj vol-DAMAGED
   ここでは/dev/sdj に割り当ててますがこの辺は任意で良いのだと思います。ただしWindows の場合はデバイス名体系が異なるかもしれません。またEC2で予約デバイスとなっているデバイス名は避けるべきだと思われます。Attaching the Volume to an Instance に予約デバイス名等が出ているので参照した方が良さそうです。
   個人的にはここでアタッチをする前に、ボリュームのスナップショットを取っておいた方が良いのではないかと思います。
7. 復旧作業を行う
   復旧用のインスタンスi-RECOVERYにssh して煮るなり焼くなりfsck するなりマウントしてファイルを書き換えるなりするというところです。
   復旧作業時の注意点として、i-BROKEN とi-RECOVERY のuid はマッチしない可能性があるのでroot 以外のユーザーでファイルを作成／コピー／編集したりする場合、それらのファイルのオーナーなどが変わってしまう可能性がある事に注意してください。（root でコピーする際などにもオーナーや実行権限が変わらないよう注意する必要があるかと思います。）
8. 元のインスタンスにアタッチして起動を試す
   復旧作業が完了したと思ったら、
   $ ec2-detach-volume vol-DAMAGED
   でi-RECOVERY からデタッチし、その後、
   $ ec2-attach-volume --instance i-BROKEN --device /dev/sda1 vol-DAMAGED
   で、元のi-BROKEN インスタンスの/dev/sda1 としてアタッチし、
   $ ec2-start-instances i-BROKEN
   にて、元のインスタンス i-BROKEN を起動して復旧が成功したか確認します。
   この際、最初に問題があったインスタンス（ここでは i-BROKEN）にElastic IP を割り当てている場合、stop したら再度立ち上げる際にもう一度立ち上げたインスタンスにそのEIP を割り当てる必要がある、ということにご注意ください。また、復旧作業用のインスタンスがテンポラリ作業用だった場合は作業終了後、terminate するのを忘れずに。

こんなかんじでしょうか。
手順は概ね●nix でのものを意識して書かれていますが、Windows も・・、まあ大体同じ流れで出来るんじゃないかとは思います。

ということで、Good Luck! 焦らずじっくり復旧しましょう。

AMI への疑問

EC2 を使い始めて最初の頃、ときどき疑問に思ったのがAMI っていったいなんなのさ、ってことでした。
AMI は、、まあ仮想マシンイメージだってことはわかります。おそらくディスクイメージが含まれてて、と想像はするものの、じゃあこのAMI にはなんてユーザーでログインするのよ、とか、Debian のAMI はこの人が作ってるけど、これって信頼できるものなの？、とか、みんな疑問を抱かずに使ってるの？とか様々な疑問点が沸々とわき起こるものでした。
自分でAMI がもっと簡単に作れれば良いのですが使い始めの頃は慣れるのに精一杯でAMI をスクラッチから作るという作業にまでは手が回らないもので結局どうすれば良いの、みたいな気持ちになった気がします。最近ではCentOS ベースと思われるAmazon Linux の使用が推奨されているようなのでCentOS 使い（というかyum 使い）の人にとってはそれでいい気もしますがdebianユーザーにとっては悩ましいところでした。

さて、とにかくその辺の疑問（というかわかってる人には愚問なのかもしれませんが。）を一度書いておきたいと思います。

• AMI にはなんというユーザーでログインするのか？
  AMI を作成した人に依存。amazon がオーナーのAMI に関してはec2-user とかが使われる事が多いみたいですが以前はroot だったことも。Amazon Linux の場合は、ターミナル上でec2-user を使え、とエラーを出してくれるのでヒントにはなる。
  後述のAlestic はサイト上できちんと記載してある。
  root じゃない場合は、おそらくほとんどの場合においてそのユーザーがsudo で着るように設定してある模様。（もちろんこれもAMI による。）
• コミュニティベースのAMI って信頼できるもの？
  そこらに落ちてるフリーソフトと同等レベルと考えた方が良い。
  つまるところ、そのAMIにマルウェアが仕込まれてたとしても自己責任。
  その意味ではamazon 所有のAMI を使うのが吉なのかも。
  CentOS ならRightScale 、Debian/Ubuntu ならAlestic (Alestic ってなんだろと思っていましたがElastic のもじりですね。今気づきました。)とかを使うのがメジャーなのでしょうか。Alestic はトップページにイメージの一覧があり、ログイン可能なユーザー名も記載があるのでわかりやすいかと思います。RightScale は登録ユーザーじゃないと情報を取得できないのかも？よくわかってないです。
  RightScale 自体いろいろ高機能らしく、彼らが作成した実戦投入しやすいイメージがたくさんあり、素早くデプロイしたりと、AWS の標準機能に欠けていると思われる機能がたくさんあるようなので試してみたいところです。
  ちなみにamazon もdebian イメージがあるのですが、それはどうもhadoop 用のイメージらしく、以前試した際にはhadoop ユーザーでしかログインが出来ませんでした。
  （2011/3/19追記：Safe Use of Shared AMIsにその辺の話も書いてあった。AMI のページにもきちんとポインタが示されてました。面倒でもドキュメント読まないといけませんね。）
• スクラッチからのAMI はどうやって作るのか。公式ドキュメントのCreating Your Own AMIs というところに記載がありますが、そのなかでもFrom a Loopback というところにdd で空のディスクイメージを作成してそれをループバックマウントしてそこをルートとしてyum に --installroot というオプションを渡してrpm を入れる、という手順が示されています。おおざっぱな流れとしてこういう感じという事のようです。
  ちなみにこれはS3-Backed の手順で、EBS-Backed の場合はどうなるのかは自分もまだはっきりしていないです。まあ基本的な考え方は一緒で、という感じでEC2特有のところを気をつける必要があるという感じでしょうか。
  また、debian 系の場合はdebootstrap を使う方法がdebian 公式ドキュメントでも示されているようでこちらを使うらしいです。

サクっとVMware とかから変換できるようになると良いですね・・。

ちなみにWindows の話は今回はナシで・・、と思ったけどVMWare で思い出したので一つだけ。Windows 用のAMI はWindows のバージョンとかにもよるのだったと思うけどVMWare イメージだかから変換できるらしい。うらやましい・・。

冒頭のロゴは本文とは全く関係のないAMI プレミアムアウトレットのロゴ。

既存のssh 公開鍵をEC2 で使う

EC2 を使い始めると、コマンドラインのツールを使うためのX.509証明書や、REST API 経由での利用の際に主に使われるアクセスキーなど、鍵、証明書等、どれが何に使われているのか混乱しやすいところかと思います。

その中でもEC2 のインスタンスにログインするときに使う鍵（Linux インスタンス限定のお話です。つまりssh 用の鍵の話。）に関しては、既存のものを登録する事が出来るので、これを利用しておいた方が少しでも余計なものが減るためおすすめです。

やりかたは簡単で、ec2-import-keypair コマンドを使って登録する事が出来ます。

使用例は以下の通り。

$ ec2-import-keypair MyKeyName -f .ssh/id_rsa.pub

これによりあなたが既に使っている鍵を登録する事が出来るので、余計なものを増やしたくない人にとっては抑えておきたいところです。

注意点としてはdsa 鍵は使えない、ということがあります。

また、鍵はリージョンごとに登録する必要があるため、複数のリージョンを使う場合には--region でリージョンを渡す必要があることにも注意が必要です。

Windows の鍵管理(※)は・・、諦めてManagement Console からWindows 専用のキーペアを追加しておいてそれを使うのが良い気がします。

※Windows インスタンスはログイン用パスワードの取得に秘密鍵が必要です。

CloudFront でキャッシュを消す

大きな地図で見る

AmazonCloudFront-CustomOriginを試してみた « サーバーワークス技術ブログ を読んでいたら、「edgeサーバからコンテンツを消せる」と書いてあったのでドキュメントを読んでみたところ、Object Invalidation に記載があった。

ただし、Versioning Objects で示されているような方法でバージョンコントロールをするのが通常の方法としてはベストプラクティス、とのこと。

緊急にどうしても消したい場合に使う方法、として考えておいた方が良いみたいだが、とはいえ実際にはなかなかうまくバージョンコントロール出来るとも限らないので覚えておくと役に立ちそう。

AWS のドキュメントとかAPI 等のURL に日付が含まれてるのはこのへんの考えがあってのもの、というところなのですね。

ちなみにCloudFront はCloudBerry を使って簡単に設定できるので静的コンテンツのデリバリーには手軽に使えます。

冒頭埋め込んだGoogle Maps はCDN で検索したら出て来たCentro Dramático Nacional というスペインにある国立演劇センター。バジェ－インクラン劇場 というところらしい。

リザーブドインスタンスについて

EC2の利用料金は時間単位での課金制で、US-EAST(米国バージニア)で一番小さなインスタンスであるt1.micro を借りた場合、$0.02/時、これを1年間常時起動で使った場合、$0.02 x 24 x 365 = $175.2/年 となり、月額にすると、$14.6/月 です。

さて、EC2にはリザーブドインスタンスというディスカウントされる仕組みがあります。

これはどのように利用するかというと、キャプチャ画像で示した通りなのですがマネジメントコンソールから購入する事が出来ます。

リザーブドインスタンスの利用料金はLinux 利用のマイクロインスタンスを3年間使う場合で$82です。

注意点ですが、ここで示した$82 という金額は、3年分の利用料金総額、というわけではなく、あくまでも、"ディスカウントを受けるための権利を購入する代金"である、ということがあります。

リザーブドインスタンスを購入して、Linux のマイクロインスタンスを3年間使う場合、イニシャルコストとしての$82 と、ディスカウント適用後の$0.007/時の3年分、つまり$82 + $0.007 x 24 x 365 x 3年 = $265.96 / 3年 となります。

月額にすると、およそ$7.39/月 となります。

1年のリザーブドインスタンスの場合だと、イニシャルコストが$54なので、$82 + $0.007 x 24 x 365 x 1年 = $115.32 / 1年 となります。

月額にすると、およそ$9.61/月 となります。

実際にはこれらの金額に加えて、マイクロインスタンス利用の場合には、EBS というストレージが必要となりこの料金を上記に追加した金額が最終的な利用料金となります。

EBS の利用料金は、$0.10/GB/月 および、$0.10 /100万 I/O リクエストとなっており、ボリュームサイズとIO リクエストの両方に対してかかるので見積もりが難しいのですが、

負荷の少ないサーバーであればIO リクエストに関しては無視できるレベル（月額$1に満たない、など）と思われるので、たとえば20GB のEBS を利用している小規模なサーバーであれば、$2 のEBS 料金を追加するくらいと見積もれます。

Amazon Web Services SIMPLE MONTHLY CALCULATORというコスト計算機が用意されているのでこれでいろいろ試してみるとわかりやすいかも知れません。

なお、ここで示した金額等は随時変わって行く可能性があるため、ご利用の際には、価格のページを確認することをお勧め致します。