AWSのコスト削減について

1. AWSコスト削減アプローチ
イタンジ株式会社 藤原裕也

2. ⽤用語集
• EC2インスタンス（ElasticComputerCloud）：仮想サー
バ
• VPC（VirtualPricateCloud）：仮想プライベートクラウド
• EBS（ElasticBlockStore）：仮想HDD（SSD）
• EIP（ElasticIPAdress）：固定IPアドレス
• RDS（RelationalDatabaseService）：AWSがMySQLとか
をフルマネで提供
• AZ（AvailabilityZone）：AWSのデータセンター

3. コスト削減だからといって
やたらめったら費⽤用削減すればい
いものではない

4. これらはコスト削減ではない
• 冗⾧長構成のインスタンスを⽚片肺だけにする（※
サービスレベル次第ではｱﾘ）
• CPU/メモリが天井に張り付いてるけど、インス
タンスサイズをダウン
• RDSをシングルAZ運⽤用に切り替える（※サービ
スレベル次第ではｱﾘ）

5. 本題に⼊入る前に・・・

6. 現在のAWS使⽤用料
EC2 RDS
Data
Transfer
TOTAL
2015/5
$1,823.54
¥224,295
$744.2
¥91,512
$132.85
¥16,340
$3,292.29
¥404,951
2015/4
$1,768.41
¥217,514
$712.65
¥87,655
$113.71
¥13,986
$3,152.49
¥387,756
2015/3
$1,824.97
¥224,471
$728.95
¥89,660
$195.82
¥24,085
$3,329.17
¥409,487
2015/2
$1,661.49
¥204,363
$667.92
¥82,154
$142.88
¥17,574
$2,995.09
¥368,396
$1=¥123

7. EC2の費⽤用感
• Prime Webサーバ
m3.medium[CPU3コア相当・メモリ3.75G]
1時間起動:$0.096(¥11)
24時間起動:$2.3(¥282)
30⽇日間起動:$69.1(¥8,501)
• Connect Webサーバ
m3.large[CPU6.5コア相当・メモリ7.5G]
1時間起動:$0.193(¥23)
24時間起動:$4.6(¥569)
30⽇日間起動:$138.9(¥17,092)
※Prime/Connect共に1台分の料⾦金

8. EC2の費⽤用感
• AWSで⼀一番⾼高いインスタンス
i2.8xlarge[CPU104コア相当・メモリ244G]
1時間起動:$8.004(¥984)
24時間起動:$192(¥23,616)
30⽇日間起動:$5,762.8(¥708,834)
※インスタンス⾃自体がストレージに最適化（Linuxのカーネルレベルで
カスタマイズ）されており、6.4TB(800G*8)のSSDが付いてくる
※実はNWも他のインスタンスとは別物

9. EC2の費⽤用感
• EC2インスタンスは、リージョン（DCの地域単
位）によって価格が違う
m3.medium
東京 8501.76
USAオレゴン 5933.52
USA Government 7439.04
サンパウロ 8413.2
フランクフルト 6996.24
30⽇日間起動/$1=¥123

10. EC2にかかるコストは異常以上

11. ではありません。
残念ながら。

12. EBS（ElasticBlockStore）
• 要はストレージ（HDD⼜又はSSD）
• 選べる3つのタイプ
1.Magnetic volumes（普通のHDD）
2.General Purpose（SSD）
3.Provisioned IOPS（IOPSが調整できるSSD）

13. EBSの費⽤用感
• Prime/Connect Webサーバ
Magnetic volumes(HDD) [50GB]
1ヶ⽉月間起動:$40(¥4,920) 1Gあたり$0.08
※Prime/Connect共に1台分の料⾦金
※EBSの課⾦金単位は1ヶ⽉月

14. EBSにかかるコストは
以上

15. ではありません。
残念ながら。
2回⺫⽬目

16. EBSの費⽤用感
• General Purpose（SSD）はI/Oに対しても課⾦金
100万I/Oリクエスト毎に$0.08(¥9.84)
• EBS Provisioned IOPS (IOPSが調整できるSSD)
設定した1IOPSあたり$0.074(¥9.102)

17. コスト削減ポイント

18. 重要なコスト削減ポイント
1. 稼働していないリソースの停⽌止削除
2. 旧世代のインスタンスタイプで稼働しているイ
ンスタンスのグレードアップ
3. 開発環境/Staging環境の夜間休⽇日停⽌止検討
4. リザーブドインスタンスの購⼊入（RDS含む）
5. インスタンスタイプに⾒見合わない稼働率のイン
スタンスの⾒見直し（RDS含む）

19. コスト削減ポイント
• オーバスペックなサポートプランの解除（判断
が難しい）
• アプリケーションのIO（RDS/S3）削減
• VPC内での通信でプライベートIPの使⽤用を徹底
• S3へのAPIリクエスト（書き込み/読み込み）の
削減
• オートスケールの導⼊入

20. コスト削減ポイント
• オーバスペックなサポートプランの解除（判断
が難しい）
• Webアプリケーションの転送量削減（HTML、
画像、JSなどを圧縮）
• スポットインスタンスの導⼊入（アプリケーショ
ンによりけり）

21. 実際にやったこと

22. 今回⾏行う（⾏行った）コスト削減
• 稼働していないリソースの停⽌止削除
• 旧世代のインスタンスタイプで稼働しているインスタンスのグ
レードアップ
• 開発環境/Staging環境の夜間休⽇日停⽌止
• リザーブドインスタンスの購⼊入
• インスタンスタイプに⾒見合わない稼働率のインスタンスの⾒見直
し（RDS含む）
• オーバスペックなサポートプランの解除
• スポットインスタンスの導⼊入（Hadoopクラスタで試験導⼊入）

23. 稼働していないリソースの停⽌止削除
• 「Kibanatest」など、過去に検証/開発に使⽤用した後、放置さ
れたインスタンス
※検証/開発でインスタンスを⽴立ち上げる事は悪くない。ただ、使い終わった
ら消せ！笑
• インスタンスを停⽌止状態にしても、付随するEBSとEIPは課
⾦金される！！
• アタッチされていない謎のEBS
※⼀一時的にディタッチ状態であるEBSが存在している事は悪いことではない。
• アタッチされていないEIP
• インスタンスがぶら下がっていないELB

24. 稼働していないリソースは停⽌止/削除
仕事をサボるバイトがクビになるのと同じです。
稼働していないリソースはクビにしましょう。

25. 旧世代のインスタンスタイプで稼働している
インスタンスのグレードアップ
• インスタンスタイプには世代がある
• ⼀一番良く使われるタイプの「m4.なんちゃら」は、実は
「m1.なんちゃら」が最初期に存在していた
• mの次の数字が多いほど新しい世代のインスタンスタイ
プ。新しければ新しいほど安くて⾼高性能
• 例えば、[m1.large]は2CPU/メモリ7.5G/$0.243だが、
[m4.large]は2CPU/メモリ8G/$0.183
1ヶ⽉月(730時間)動かすと、$43.8もの違いが！！
※スペック上は余り変わってないように⾒見えるが、ハー
ドウェアが全く別物になっている

26. 開発環境/Staging環境の夜間休⽇日停⽌止
• 意外と知られていないコスト削減策
• 夜間休⽇日は使わないのに、インスタンスはせっ
せと稼働・・・。
• この策には副産物があって、夜間休⽇日に停⽌止し
ても、次の⽇日の朝に⽴立ち上げればそのまま稼働
するような構成を求められるので、本番環境で
オートスケール運⽤用する際も、同じやり⽅方で出
来る

27. リザーブドインスタンスの購⼊入
「リザーブドインスタンス」というインスタンスタイプ
が存在していると思っている⼈人？

28. Not ReservedInstance
Yes ResrvedInstanceRight

29. リザーブドインスタンスとは
• 「リザーブドインスタンス」は、正確には「リ
ザーブドインスタンスの権利」といった⽅方が正
しい
• リザーブドインスタンスというインスタンスタ
イプは存在しない
• オンデマントインスタンスとして起動したイン
スタンスの中に、購⼊入したリザーブドインスタ
ンスと同じインスタンスタイプがあれば、その
インスタンスはリザーブドインスタンスとして
みなされる

30. リザーブドインスタンス例
Prime01/t2.micro Prime02/t2.micro
t2.microのリザーブドインスタンスを2つ購⼊入
オンデマンドインスタンスとしてPrimeサーバを2つStart
2つのPrimeサーバはオンデマンドインスタンスからリザーブド
インスタンスへ⾃自動で切り替わる（正確には適⽤用される）

31. リザーブドインスタンス例
Prime01/t2.micro Samurai01/t2.micro
Prime02が不要になったので削除した。
代わりに、不動産サムライ⽤用のWPサーバを⽴立ち上げた
Prime01とSamurai01がリザーブドインスタンスの対象に！

32. リザーブドインスタンスまとめ
• リザーブドインスタンスはインスタンスタイプ
ではない
• インスタンスIDを指定する必要なし！固有のイ
ンスタンスに紐付かない
• 指定するのは、OSとAZとインスタンスタイプと
リザーブドする期間（1年or3年）と⽀支払い⽅方法

33. インスタンスタイプに⾒見合わない稼働
率のインスタンスの⾒見直し（RDS含
む）
• サービススタート時は、どのくらいの負荷がか
かってくるかがわからないため、⼤大きめのイン
スタンスで起動しがち
• 慣れてくると、⼤大体⾒見積もれる
• 稼働率の確認は、CloudWatchで。CPUとメモリ
の稼働率を確認せよ。
• 疎かになりがちだが、EBSの使⽤用率も！

34. オーバースペックなサポートの解除
• 今までのサポートプランだと、24365で問い合わ
せから初動1時間以内で、電話・メール・チャッ
トで対応します！
AWSだけじゃなくて、インスタンス上で動く
Nginxとかミドルウェアも対応します！という神
対応プランだった
• 問い合わせ履歴０で、今後もAWSに緊急での問
い合わせが無いと判断したので、⽉月額５０００
円のプランに変更

35. AWSサポートにお世話になるには１００年早い！

36. スポットインスタンスの導⼊入
リザーブドインスタンスの次によくわからないEC2のオ
プション

37. スポットインスタンスとは

38. スポットインスタンス
マジ意味不明

39. スポットインスタンスとは
• EC2インスタンスのリソースを⼊入札制で開放し
ている（⼀一定量のリソースをスポットインスタ
ンス⽤用に確保している模様）
• まだまだ利⽤用者が少なく、⼊入札競争も激しくな
いので、同じインスタンスタイプのリザーブド
インスタンスよりも安い価格で利⽤用することが
できる
• その時の相場次第だが、オンデマンドインスタ
ンスより１桁下の価格で利⽤用可能な事が多い

40. ただし！

41. スポットインスタンスは突然落ちる
というか、消される（Terminate)

42. スポットインスタンス
• ⼊入札制のため、⾃自分が設定した最⾼高⼊入札額を超
えると⾃自動で削除される
• また、スポットインスタンス全体でリソース量
が決められているので、その上限に⾏行ったら消
される（上限不明）
• 今年の前半に、消される２分前に通知する機能
が備わった（２分前てｗｗｗ）

43. いつ消えるか分からないサーバ
何に使うんだよｗｗｗｗｗ

44. 利⽤用シーン
• ⼤大規模分散システム（数台いなくなっても問題
ない）
Hadoopとか
• アクセス量が尋常じゃないWebサービス
例：50台のWebサーバ中、30台はオンデマンド
とリザーブドで構成し、残り20台はオンデマン
ド
• 開発環境/ステージング環境/検証環境

45. 利⽤用シーン
• イタンジでは、Hadoopクラスタで利⽤用予定
• マスタを含めた3台をオンデマンド⼜又はリザーブ
ドで構成し、激安で⼊入札出来た時のみ数台をオ
ンデマンドで追加投⼊入する
• 料⾦金例：r3.large
オンデマンド リザーブド1年 スポット
$0.210 $0.157 $0.0214

46. EC2のワゴンセール！！！

47. 今回⾏行う（⾏行った）コスト削減
• 稼働していないリソースの停⽌止削除
• 旧世代のインスタンスタイプで稼働しているインスタンスのグ
レードアップ
• 開発環境/Staging環境の夜間休⽇日停⽌止
• リザーブドインスタンスの購⼊入
• インスタンスタイプに⾒見合わない稼働率のインスタンスの⾒見直
し（RDS含む）
• オーバスペックなサポートプランの解除
• スポットインスタンスの導⼊入（Hadoopクラスタで試験導⼊入）

48. 以上がイタンジで「やったorやるコスト削減」
他にもたくさんコスト削減策はありますが⼿手をつけてません
IO削減などは効果も⼤大きいが、⼿手間も⾮非常に⼤大きいため

49. 今⽇日のまとめ
「要らないものは捨てる」