はじめに
社内で、AppRunner、EC2、ECS、Fargateを比較する機会があったので、その内容をこちらでも共有させてください！
これらのサービスの大きな違いとして、「責任範囲」と「コスト」かと思います。
今回はそれらの観点に注視して比較してみました。
AWSコンピューティングサービスの歴史
以下のような遍歴でそれぞれのサービスはローンチしています。
トレンドにしたがってサービスが創られているのがわかって面白いですね。（AWSサービス年表ほしい、、）
それぞれのサービスごとの責任範囲
これらのサービスの最も大きな違いはユーザーとAWSの責任範囲です。
当然ユーザー側の責任範囲が小さいほど、運用の手間は減ります。
その代わりにそのサービス特有の制限が増えることに注意してください。
代表的なアーキテクチャの責任共有モデル
アーキテクチャの責任範囲については、こちらが非常にわかりやすいので確認してみてください。
資料の内容をまとめると以下のようになります。
構成図での比較
構成図での比較を行うとよりわかりやすいため、構成図でも比較してみます。
パブリック2層構造
パブリック3層構造
プライベート3層構造
それぞれのサービスごとのコスト
サービスごとのコストを試算して、比較してみましょう。
前提条件（デフォルト値）
- vCPU: 2vCPU
- メモリ: 4GB
- リクエスト数: 5リクエスト/s
- 通信量: 0.0003GB/s
- 接続数: 1接続/s
- ELBの適用ルール数: 60
- アクティブな時間: 8h/日
それぞれの計算式
EC2+ALB、Fargate+ALB、AppRunnerの3パターンについてそれぞれ月額を試算していきます。
"計算上の留意点"
あくまで全体の傾向を確認するための試算です。（正確な値はPriceCalculator等で計算してください）
実際にはリザーブドインスタンスやSavingsPlanを利用することでEC2の方が安くなる場合もあることに注意してください。
今回はいつアクセスされるかわからないため夜間は止めるなどの対応はできないワークロードを想定しています。
EC2+ALB
<インスタンス料金>*24*30 + (0.0243+0.0054+MAX(<接続数>/1000,<接続数>*120/3000,<通信量>*3600,(<ルール数>-10)*<リクエスト数>/1000)*0.008)*24*30
Fargate+ALB
(0.05056*<vCPU>+0.00553*<メモリ>)*<アクティブな時間>*30 + (0.0243+0.0054+MAX(<接続数>/1000,<接続数>*120/3000,<通信量>*3600,(<ルール数>-10)*<リクエスト数>/1000)*0.008)*24*30
AppRunner
(0.009*<メモリ>+0.081*<vCPU>)*<アクティブな時間>*30+1+0.005*15-(0.009*<メモリ>*<アクティブな時間>)
アクティブな時間を変数としたコスト比較
アクティブな時間を変数としてコスト比較を行うと以下のような結果となります。
| アクティブな時間 (h/日) | EC2 (t4g.medium) +ALB | Fargate+ALB | AppRunner |
|---|---|---|---|
| 1 | 58.7088 | 31.302 | 6.979 |
| 2 | 58.7088 | 34.9992 | 12.883 |
| 3 | 58.7088 | 38.6964 | 18.787 |
| 4 | 58.7088 | 42.3936 | 24.691 |
| 5 | 58.7088 | 46.0908 | 30.595 |
| 6 | 58.7088 | 49.788 | 36.499 |
| 7 | 58.7088 | 53.4852 | 42.403 |
| 8 | 58.7088 | 57.1824 | 48.307 |
| 9 | 58.7088 | 60.8796 | 54.211 |
| 10 | 58.7088 | 64.5768 | 60.115 |
| 11 | 58.7088 | 68.274 | 66.019 |
| 12 | 58.7088 | 71.9712 | 71.923 |
| 13 | 58.7088 | 75.6684 | 77.827 |
| 14 | 58.7088 | 79.3656 | 83.731 |
| 15 | 58.7088 | 83.0628 | 89.635 |
| 16 | 58.7088 | 86.76 | 95.539 |
| 17 | 58.7088 | 90.4572 | 101.443 |
| 18 | 58.7088 | 94.1544 | 107.347 |
| 19 | 58.7088 | 97.8516 | 113.251 |
| 20 | 58.7088 | 101.5488 | 119.155 |
| 21 | 58.7088 | 105.246 | 125.059 |
| 22 | 58.7088 | 108.9432 | 130.963 |
| 23 | 58.7088 | 112.6404 | 136.867 |
| 24 | 58.7088 | 116.3376 | 142.771 |
アクティブな時間が9時間程度まではAppRunnerが最安値であることがわかります。
しかし、それ以上のアクティブな時間の場合はEC2インスタンスがオンデマンドの場合も最安値です。
スペックを変数としたコスト比較
次にvCPUとメモリを変数としてコスト比較を行います。（インスタンスタイプは最もスペックが近いものを採用しています）
| vCPU | メモリ | インスタンスタイプ | キー | EC2+ALB | Fargate+ALB | AppRunner |
|---|---|---|---|---|---|---|
| 0.25 | 0.5 | t4g.nano | 0.25vCPU_0.5GB | 31.4928 | 31.302 | 6.979 |
| 0.25 | 1 | t4g.micro | 0.25vCPU_1.GB | 35.3808 | 31.9656 | 8.023 |
| 0.5 | 1 | t4g.micro | 0.5vCPU_1.GB | 35.3808 | 34.9992 | 12.883 |
| 1 | 2 | t4g.small | 1.vCPU_2.GB | 43.1568 | 42.3936 | 24.691 |
| 1 | 3 | t4g.medium | 1.vCPU_3.GB | 58.7088 | 43.7208 | 26.779 |
| 1 | 4 | t4g.medium | 1.vCPU_4.GB | 58.7088 | 45.048 | 28.867 |
| 2 | 4 | t4g.medium | 2.vCPU_4.GB | 58.7088 | 57.1824 | 48.307 |
| 2 | 6 | t4g.large | 2.vCPU_6.GB | 89.8128 | 59.8368 | 52.483 |
| 4 | 8 | c7g.xlarge | 4.vCPU_8.GB | 158.5728 | 86.76 | 95.539 |
| 4 | 10 | m5a.xlarge | 4.vCPU_10.GB | 188.8848 | 89.4144 | 99.715 |
| 4 | 12 | m5a.xlarge | 4.vCPU_12.GB | 188.8848 | 92.0688 | 103.891 |
こちらは4vCPU以上のスペックを利用する場合はFargateの方が安くなることがわかります。
AppRunnerの制限事項
AppRunnerはほとんどの運用をAWS側に任せられる半面、特有の制限事項があります。
制限事項を許容できない場合はECS、Fargate、EC2などの選択肢を検討する必要があります。
スペック上限
AppRunnerで現在選択できるスペックは以下の通りです。
これ以上のスペックを選択することはできません。
| vCPU | メモリ |
|---|---|
| 0.25 | 0.5 |
| 0.25 | 1 |
| 0.5 | 1 |
| 1 | 2 |
| 1 | 3 |
| 1 | 4 |
| 2 | 4 |
| 2 | 6 |
| 4 | 8 |
| 4 | 10 |
| 4 | 12 |
WebSocket利用不可
AppRunnerではWebSocketをサポートしていません。
したがって、Streamlitなどの利用もできません。
サイドカー利用不可
ログ出力などでもよく利用されるサイドカーが使えません。
ランタイムの制限
利用できるランタイムも限られています。
Pythonだと3.7、3.11しか使用できません。
apprunner.ymlの仕様
AppRunnerのビルド設定など、Dockerfileに似た目的で、apprunner.ymlというファイルを記述します。
AppRunner自体新しいサービスであることと制限事項から利用者が少ないため、手探りで記述しなければなりません。
（利用者が少ない＝生成AIの精度も悪い）
まとめ
EC2、ECS、Fargate、AppRunnerの比較表
| 特徴 | Amazon EC2 | Amazon ECS (EC2起動タイプ) | Amazon ECS (Fargate) | AWS App Runner |
|---|---|---|---|---|
| サービス概要 | 仮想サーバーサービス | コンテナオーケストレーションサービス | サーバーレスコンテナサービス | フルマネージドコンテナアプリケーションサービス |
| インフラ管理 | ユーザーが完全に管理 | EC2インスタンスをユーザーが管理 | AWSが完全に管理 | AWSが完全に管理 |
| スケーリング | 手動/Auto Scaling | 手動/Auto Scaling | 自動スケーリング | 自動スケーリング |
| 料金モデル | EC2インスタンス料金 | EC2インスタンス料金 | 使用したvCPUとメモリに対して課金 | 使用したvCPUとメモリに対して課金 |
| ユースケース | 常にインスタンスが稼働している必要がある場合 | Fargate/AppRunnerが利用できない、または、24/365で一定のアクセスが見込まれる場合 | 短時間で高スペックな処理を行いたい場合 | 運用管理を最小限に抑えて小規模なアプリケーションやPoCを行う場合 |
| 柔軟性 | 非常に高い | 高い | 中程度 | 低い（シンプルさ重視） |
| 運用負荷 | 高い | 中〜高 | 低い | 最も低い |
| デプロイ複雑さ | 高い | 中程度 | 低い | 最も低い |
| コントロール性 | 最も高い | 高い | 中程度 | 低い |
| 起動時間 | 数分 | 数分 | 数十秒 | 数分 |
| ネットワーク設定 | 完全なカスタマイズ可能 | 完全なカスタマイズ可能 | VPC統合可能 | VPC統合可能 |
| モニタリング | CloudWatch、カスタム | CloudWatch、カスタム | CloudWatch | CloudWatch統合済み |
| セキュリティ | セキュリティグループ、IAMなど | セキュリティグループ、IAMなど | IAM、セキュリティグループなど | IAM、セキュリティグループ（VPC内からのアクセスの場合）、WAF |
選択ワークロード
非常に簡略化した選択ワークロードですが以下のような観点で選択していくことができます。
Appendix. Lambda Web Adapter
ウェブアプリケーションをAWS上にホストする方法として、「Lambda Web Adapter」というものもあるのでご紹介します。
理論上はHTTPを話す任意のWebアプリフレームワークが利用可能とのことですが、利用している記事などが少ないことと、Lambda固有の制限があることがネックです。（15分タイムアウトなど）
しかし、これを利用すると、サーバーレスであることから最安値、最小限の運用での実装が可能になると思います。
参考資料：https://aws.amazon.com/jp/builders-flash/202301/lambda-web-adapter/
弊社では一緒に働く仲間を募集中です！
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！
募集内容等詳細は、是非採用サイトをご確認ください。
https://engineer.po-holdings.co.jp/