目次
はじめに
第1章 Amazon EC2
第2章 AWS Lambda
第3章 コンテナーサービス
第4章 Amazon EBS/EFS
第5章 ネットワーク
第6章 Amazon S3
第7章 AWS Pricing Calculator
第8章 AWS Cost Explorer
第9章 AWS Cost and Usage Report
第10章 AWS Budgets
第11章 コスト配分タグ
第12章 AWS Cost Category
第13章 AWS Trusted Advisor
第14章 AWS Compute Optimizer
第15章 AWS Well-Architectedフレームワーク「コスト最適化」
第16章 事例の紹介
付録A Redashのインストール・設定
はじめに
ここ数年でAmazon Web Services（AWS）、Google Cloud Platform、Microsoft Azureのようなパブリッククラウドの存在が身近になってきました。2019年8月にAWSで大規模な障害が発生したときには、多くのシステムやサービスが影響を受けたことは、記憶に新しいと思います。障害によって、IT系に勤めていない人達もAWSという用語を口にするようになったぐらいですから、エンジニア以外の層にも浸透してきていると感じています。
パブリッククラウドの利点は、コンピューティングリソースの確保が簡単になったこと、使った分だけ請求されることです。従来のインフラストラクチャーは、データセンターでサーバーやネットワーク機器を購入して設置・構築する必要がありました。それが、パブリッククラウドの登場で、すばやくそしてリーズナブルにコンピュートリソースを手に入れることができるようになりました。
従量課金、つまり使った分だけというのは、使ってないときはお金がかからないメリットがあります。反面、利用料金の見通しが難しくなる問題を新たに生み出しました。従来のインフラストラクチャーは、サーバー・ネットワーク機器の購入金額とネットワーク回線料金といった予測が比較的しやすく、将来的な見通しが立てやすいです。ですが、パブリッククラウドはその手軽さゆえ、見通しを立てることが難しいのです。1台～10台程度なら管理は容易ですが、百〜千台の単位になると、全体管理もさることながら、請求された金額をひとつずつ紐解いていくのは困難を極めます。パブリッククラウドよって手に入れた利便性と引き換えに、リソースとコストの管理に時間を費やされることになりました。
コスト削減は会社の規模に限らず、どこにでもある課題です。安くなるからとオンプレミスからAWSに移行したのに、なぜかコストが下がらない、といった話は耳にしたことがある方もいるでしょう1。あるいは、最初はスモールスタートでコストを抑えながら利用していたけれど、気がついたらコストが増えていた、ということが起こりえます。
AWSのコスト削減というと、使っていないEC2インスタンスの停止や、リザーブドインスタンスの購入、といった方法をよく聞きます。間違いではありませんが、止めるべきEC2インスタンスを特定したり、適切なインスタンスタイプを選択するには、常日頃からEC2インスタンスの使用状況を把握しておかなければなりません。リザーブドインスタンスを購入するにしても、RIの知識が足りないと、コスト効果が不十分になる可能性があります。ベストプラクティスとして挙げられているコスト最適化の手法を、そのまま私たちのシステムに適用できるとは限りません。
コスト最適化は旅である
「Cloud cost optimization is a journey.」2という言葉があります。コスト最適化は一度やれば終わりではなく、継続的にリソースやビリングの状況を監視、追跡を行い、最適化をしていくプロセスです。AWSコストを最適化するためには「AWSサービスおよび料金への知識」「自分たちのシステムに関する理解」そして「継続的に監視・最適化するための運用」が必要です。これらのひとつでも欠けてはなりません。ひとつ目はいわずもがなですね。ふたつ目は、コスト知識だけがあっても、自分たちのシステムに落とし込んでいかないと意味がなかったり、費用対効果が薄くなるということです。コスト知識と自分たちのシステムにマッチしたコスト最適化の施策を打ち出し、継続的に取り組んでいくことが肝要です。アプリケーションエンジニアやサーバーサイドエンジニア、SRE・インフラエンジニア、セキュリティーエンジニアなどと同様に、クラウドコストを最適化するにも、専門の知識とスキルが必要なのです。
本書の構成
AWSの料金やコスト最適化に悩む人のお役に立てたら、という思いから本書を執筆しました。本書は3部構成です。
第1章～第7章は、AWSサービスについての概要と料金体系について学びます。取り上げているAWSサービスは、次のとおりです。サービスそのものについての説明はあまりしていないため、さらに知りたい人は、ドキュメントか他書と照らし合わせてください。
・Amazon EC2、リザーブドインスタンス、Savings Plans
・AWS Lambda
・AWS ECS、EKS
・Amzon EBS、EFS
・Amazon VPC、ネットワーク
・Amazon S3
料金を構成する要素と、コスト最適化するためのポイントを知ることで、正しくAWSサービスを使うことができます。また、AWS Pricing Calculatorを用いて、AWSの利用料金を見積もる方法も学びます。見積もることで、あとから高額な料金を請求されずに済みます。
第8章～第12章は、AWS Cost Explorer、AWS Cost and Usage Reportを用いて、AWSの利用料金の可視化と分析する方法について学びます。また、AWS Budgets、コスト配分タグを活用したリソースや予算管理についても知ることができます。コスト最適化のための策を講じたり、最適化の効果を確認するためには、コストの可視化と分析が必要不可欠です。タグでコストを分類したり、予算を定めて想定以上の出費に気づくといった、日常的な運用をするために必要なことを学べます。
第13章～第16章は、AWS Trusted Advisor、AWS Compute Optimizerを活用したコスト最適化方法について学びます。また、AWS Well-Architectedフレームワークの柱のひとつである「コスト最適化」で、ベストプラクティスについて触れます。
対象読者
・EC2やS3を使っているけど、料金体系についてよくわかっていない人
・オンプレミスからAWSに移行したいけど、どのぐらいのコストなのかわからない人
・AWSを使いたいけど、クラウド破産が怖い人
・AWSのコスト削減に悩んでいる人
逆に、次のような人には向かないかもしれません。
・AWSの無料枠を使い倒したい人
・AWS上級者
免責事項
本書で載せている料金は特に断りがない限り、2020年6月時点の東京リージョンの料金です。料金は今後変更になる可能性があるため、AWS公式の料金表をご確認ください。また、「$」は米ドル（USD）です。
本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。
第1章 Amazon EC2
本章は、Amazon EC2（以下、EC2）の料金体系について説明します。EC2では、オンデマンドインスタンス、リザーブドインスタンス、Savings Plans、スポットインスタンスの4種類の料金オプションが提供されています。
1.1 オンデマンドインスタンス
オンデマンドインスタンスは、デフォルトの料金オプションです。リザーブドインスタンスの購入やスポットインスタンスの指定をしなければ、自動的にオンデマンドインスタンスとなります。オンデマンドインスタンスの利用料金は、次の要素で決定されます。前払いはありません。
・実行時間
・インスタンスタイプ
・OS
・リージョン
1.1.1 実行時間
EC2インスタンスが起動（マネージメントコンソールでrunning）状態になると、料金が発生します。インスタンス直後はOSがブートされ、接続できなくても料金が発生しています。ライセンス費が発生しないLinuxなどの無償OSは秒単位（最低60秒）、Windows Server、Red Hat Enterprise Linux、SUSE Linux Enterprise Serverなどの有償OSは時間単位で請求されます。もし1時間5秒起動した場合、LinuxとWindowsで請求時間は表1.1になります。
| OS | 請求時間 |
| Linux | 65秒分 |
| Windows | 2時間分 |
EC2インスタンスが停止（stopping、stopped）もしくは削除（shutting-down、terminated）になると、課金は停止されます。停止から起動に状態が変わると、再度料金が発生します。起動と停止を繰り返すとその都度、最低時間分の料金が発生するので、注意してください。インスタンスの再起動であれば最低時間分の料金は発生しないので、OSのリブートをしたい場合は、再起動をするようにしましょう。
AWS Marketplaceで提供されているAMIからEC2インスタンスを起動する場合、EC2の料金に加えて、ライセンス費用が別途かかる場合があります。例として、オープンソースで提供されているNginxの機能拡張版であるNGINX Plus1のAWS Marketplaceページ2を見てみます。「Pricing Information」の料金詳細を見ると、「Software/hr」という項目があります図1.1。これがNGINX Plusのソフトウェアライセンス費用となり、EC2インスタンスの料金に上乗せされて請求されます。
1.1.2 インスタンスタイプ
EC2は用途に合わせて、多くの種類のインスタンス（インスタンスタイプ）が用意されています。インスタンスタイプは、「インスタンスファミリー」「インスタンス世代」「インスタンスサイズ」、そして「追加能力」の4つの要素を組み合わせたものです（図1.2）3。
インスタンスファミリー
インスタンスファミリーは汎用、コンピューティング最適化、メモリー最適化、ストレージ最適化、高速コンピューティングの5種類に分けられます（表1.2）。
| 種類 | インスタンスファミリー | ユースケース |
| 汎用 | A1、T3、M5、M6g | Webサーバーなど |
| コンピューティング最適化 | C5、C6g | 高性能Webサーバー、バッチ処理など |
| メモリー最適化 | R5、R6g、X1、Z1d | データベースなどメモリーを大量に使用する処理 |
| ストレージ最適化 | I3、H1、D2 | NoSQL、インメモリーデータベースなど |
| 高速コンピューティング | G3、P3、G4dn | GPUを活用したコンピュート処理 |
インスタンスファミリーによってサーバー性能や搭載しているCPU、メモリー量が異なります。M5インスタンスを例にすると、m5.large、c5.large、r5.largeのカタログスペックは表1.3のとおりです。アプリケーションの特性や必要なリソース（CPU、メモリー）に合わせて、適切なインスタンスファミリーを選択します。
| インスタンスタイプ | vCPU | メモリー（GiB） | 料金 |
| m5.large | 2 | 8GiB | 0.124 USD/時間 |
| c5.large | 2 | 4GiB | 0.107 USD/時間 |
| r5.large | 2 | 16GiB | 0.152 USD/時間 |
インスタンス世代
インスタンス世代は、数字が大きいほうが最新です。新世代は旧世代と比べて性能が向上されているうえに、料金が安くなる傾向にあります。m3.large、m4.large、m5.largeのカタログスペックを比べると、m5.largeの時間あたりの料金が安いことがわかります（表1.4）。
| インスタンスタイプ | vCPU | ECU | メモリー（GiB） | 料金 |
| m3.large | 2 | 6.5 | 8GiB | 0.193 USD/時間 |
| m4.large | 2 | 6.5 | 8GiB | 0.129 USD/時間 |
| m5.large | 2 | 10 | 8GiB | 0.124 USD/時間 |
ECU
ECUはElastic Compute Unitsの略で、Amazon独自のCPU性能単位を表しています。EC2インスタンスの整数処理能力を、相対的に測定した指標です。ECUによって、異なるインスタンスタイプのCPU性能の比較が容易にできます。たとえば、c5.xlarge、m5.xlarge、r5.xlargeはいずれもvCPUは4ですが、c5.xlargeのECU数がもっとも高いため、CPU性能も高いことがわかります（表1.5）。先ほどの表1.4で、m5.laregeは料金が安いうえに、CPU性能がもっとも高いです。ECUはIntel X86アーキテクチャのインスタンスのみが対象です。ArmアーキテクチャベースのインスタンスタイプにECUの表記はありません。
| インスタンスタイプ | ECU |
| c5.xlarge | 20 |
| m5.xlarge | 16 |
| r5.xlarge | 19 |
Nitroシステム
Nitroシステムは、EC2インスタンスの基盤となるプラットフォームです。EC2インスタンスのホストサーバー（物理サーバー）で実行されていたネットワーク、ストレージ、セキュリティーのソフトウェアを、AWSが独自に開発したハードウェアにオフロードする（処理を任せる）ことで、パフォーマンス向上やセキュリティー強化、コスト削減が実現しました。対象となるインスタンスタイプはC5、C5d、C6g、M5、M5d、M6g、P3dn、A1、R5、R5a、R6gなどがあります。最新情報はドキュメントから確認できます4。基本的に、新世代のインスタンスタイプはNitroシステムです。
バースタブル・インスタンス
従来のEC2インスタンスタイプのパフォーマンスは一定です。いっぽう、バースタブル・インスタンスは、CPUクレジットという機能によって、ベースラインを超えてバースト（CPU性能をフルに活用）することができます。T2、T3インスタンスがバースタブル・インスタンスで、同スペックの他のインスタンスタイプと比較して、時間あたりの料金が安いです（表1.6）。
| インスタンスタイプ | vCPU | ECU | メモリー（GiB） | 料金 |
| t3.large | 2 | 変数 | 8GiB | 0.1088 USD/時間 |
| m5.large | 2 | 10 | 8GiB | 0.124 USD/時間 |
CPU性能を必要としない開発環境や、短いピーク時のみCPU性能を発揮するワークロードに向いています。常にCPU性能を必要とするワークロードでは、CPUクレジットが枯渇し性能が落ちてしまいます。そのため、M5かC5などのインスタンスタイプにするか、CloudWatchでCPUクレジットのメトリクスを監視するようにしましょう。
プロセッサアーキテクチャ
EC2を起動するためのイメージ（AMI）はプロセッサのアーキテクチャに依存されるため、インスタンスタイプに合わせたプロセッサアーキテクチャのAMIを選択する必要があります。従来はx86ベースのAMIが主流でしたが、最近登場したArmベースAMIとの互換性に注意が必要です。
Armアーキテクチャベースのインスタンスタイプ（A1、C6g、M6g、R6g）では、arm64のAMIである必要があります。たとえば、Amazon Linux 2の場合はamzn2-ami-hvm-2.0.20200520.1-arm64-gp2（ami-01e7d6c28d99b213c）とAMI名にarm64がつきます。
AMD EPYCプロセッサが搭載されたインスタンスタイプは、x86ベースのAMIで起動ができます。現時点では、T3a、M5a、R5aインスタンスがあります。
32ビットOSで起動できるインスタンスファミリー
32ビットをサポートしているインスタンスファミリーは旧世代のみで、次のとおりです。最近は32ビットOSを起動する機会は少なくなったかと思いますが、インスタンスファミリーが限定されることを頭の片隅に入れておいてください。
t2.nano、t2.micro、t2.small、t2.medium、c3.large、t1.micro、m1.small、m1.medium、c1.medium
GPUインスタンス
機械学習やディープラーニングなどに、GPUインスタンスが使用されます。GPUインスタンスはG2、G3、G4、P2、P3が提供されており、G4（g4dn）が最新です。インスタンスタイプによって、積んでいるGPU数やGPUアクセラレータが異なります。EC2インスタンスの料金表には、GPU数やアクセラレータについての比較がありません。筆者がまとめたスプレッドシート5がありますので、GPUインスタンスを使用する場合に、参考にしてください。
追加能力
c5d.xlargeの「d」は追加能力を表しています。「d」は「disk」の意味で、NVMeベースのSSDが、インスタンスストアとしてアタッチされています。他にいくつかありますので、表1.7にまとめました。r5dn.large、g4dn.xlargeのように、複数つくこともあります。
| 種類 | 例 | 説明 |
| d（disk） | c5d.large | NVMeベースのSSDの追加付与 |
| e（extended memory） | x1e.xlarge | 拡張メモリー |
| n（network） | r5n.large | 最大100Gbpsネットワーク帯域幅 |
| a（amd） | t3a.large | AMD EPYCプロセッサを搭載 |
| s（small） | g3s.xlarge | 少量のCPUとメモリー |
| g（graviton2） | m6g.large | ArmベースのGraviton2プロセッサを搭載 |
インスタンスサイズ
インスタンスサイズが大きくなるにつれて、CPUコア数、メモリー量が増えていきます。M5インスタンスを例にすると、m5.large、m5.xlarge、m5.2xlargeのカタログスペックは表1.8のとおりです。
| インスタンスタイプ | vCPU | メモリー（GiB） | 料金 |
| m5.large | 2 | 8GiB | 0.124 USD/時間 |
| m5.xlarge | 4 | 16GiB | 0.248 USD/時間 |
| m5.2xlarge | 8 | 32GiB | 0.496 USD/時間 |
さらに大きいインスタンスサイズになると、ネットワーク帯域幅が大きく活用できます（表1.9）。大容量のネットワーク性能を必要とする場合には、大きいインスタンスサイズか、大規模ネットワーク帯域幅が使えるM5dインスタンスなどを検討します。
| インスタンスタイプ | ネットワーク帯域幅 |
| m5.large〜m5.4xlarge | 最大10Gbps |
| m5.8xlarge | 10Gbps |
| m5.12xlarge | 10Gbps |
| m5.16xlarge | 20Gbps |
| m5.24xlarge | 25Gbps |
1.1.3 OS
同じインスタンスタイプでも、無償OSと有償OSで時間あたりの料金が異なります。有償OSはライセンス料金が含まれる分、無償OSより高くなります。表1.10はm5.largeインスタンスの比較ですが、有償OSが無償OSより約1.7倍高くなっています。
| OS | インスタンスタイプ | 料金 |
| Linux | m5.large | 0.124 USD/時間 |
| Windows | m5.large | 0.216 USD/時間 |
リザーブドインスタンスも同様に、無償OSより有償OSが高くなります。表1.11はm5.largeインスタンスの比較ですが、有償OSが無償OSより約2.2倍高くなっています。
| OS | インスタンスタイプ | 料金（1年、全額前払い） |
| Linux | m5.large | 639 USD/年 |
| Windows | m5.large | 1,445 USD/年 |
1.1.4 リージョン
同じインスタンスタイプ、OSでも、リージョンによって時間あたりの料金が異なります。USリージョンが安く、東京リージョンが高めです。表1.12はm5.largeインスタンスの比較ですが、東京リージョンがバージニア北部リージョンより、約1.3倍高くなっています。
| リージョン | OS | インスタンスタイプ | 料金 |
| バージニア北部（us-east-1） | Linux | m5.large | 0.096 USD/時間 |
| 東京（ap-northeast-1） | Linux | m5.large | 0.124 USD/時間 |
1.1.5 AWS Instance Scheduler
オンデマンドインスタンスは起動した時間分だけ料金が発生するため、使用しないときは停止するのが鉄則です。しかし、開発環境などチームで使うEC2インスタンスを毎日手動で起動するのは面倒ですし、停止するのを忘れるかもしれません。そこで、起動・停止をスケジューリングする「AWS Instance Scheduler」がAWSから提供されています6。AWS Instance Schedulerは単体のAWSサービスではなく、複数のAWSサービスを組み合わせたもので、CloudFormationから作成できます（図1.3）7。かかるコストはAWS Lambda、Amazon DynamoDB合わせて、10USD/月未満です。
AWS Instance Schedulerはリソース（EC2、RDS）にスケジュールと期間をタグ付けすることで、スケジューリングします。特定の時間、曜日、日、月に実行することを設定できます。AWS Instance Schedulerを構築してしばらく経つと、停止していると思っていたインスタンスが実際には年中無休で稼働している、といったことが起こり得ます。そのため、定期的に必ずスケジューラの設定を確認してください。特に次の設定には注意してください。
・retain_running：trueに設定することで、スケジューラによって起動する前に手動でインスタンスを起動した場合、期間終了時にインスタンスが停止するのを防ぐ
・override_status：runningに設定されている場合、期間開始時にインスタンスを起動するが、期間終了時にインスタンスは自動停止されない。手動でインスタンスを指定する必要がある
・begintime and endtime：begintimeだけを設定した場合、手動でインスタンスを指定する必要がある
1.1.6 オンデマンドインスタンスが向いているユースケース
後に紹介するリザーブドインスタンス、Savings Plans、スポットインスタンスは、特定の条件やユースケースにおいて効果的な割引を発揮します。それに該当しない場合は、オンデマンドインスタンスとなります。
たとえば、定期的に急増する短期的なワークロード（4か月のプロジェクトなど）、中断できない予測不可能なワークロードをもつアプリケーションなどがあります。オンデマンドインスタンスは、スポット環境のブロックよりも長く実行され、リザーブドインスタンスの適用に必要な時間よりも短いことが多い開発環境や、テスト環境などのワークロードにも適しています。