AWS App RunnerとECS Fargateの違い・メリットとデメリット

概要

AWS App RunnerのVPCリソースへのアクセスが可能になり、色々と検証している中で、ECS・Fargateとの違いなどを簡単にまとめてみました。


目次

目次


注意

個人的な主観レベルのものであったり、短い時間での操作によって判断したものもあるため、内容に間違い・変更がある可能性がある点はご了承下さい。

App Runnerはどんどん新機能が追加されてきていますので、新規情報があれば随時更新していきます。


アップデート情報

過去のアップデート



前提

以下のメリット・デメリットは、AWS App Runnerの特徴をベースに記述しています。


App RunnerのメリットはECS・Fargateにないもの、App RunnerのデメリットはECS・Fargateにあるもの、といったイメージです。


AWS App Runnerのメリット

  • CI/CDの簡易化
    • GitHubとの連携により、簡単にCI/CDが実行可能
      • コードのプッシュをトリガーに自動デプロイ
        • Dockerfileが必要ない
      • 対応言語(ランタイム)
        • Python 3
        • Node.js 12/14/16
        • Java(Corretto 8, Corretto 11)
        • PHP 8.1
        • Go 1.18
        • .Net 6
        • Ruby 3.1
      • モノレポ構成も可能(2023/09/27〜)
    • ECRとの連携により、簡単にCI/CDが実行可能
      • イメージのプッシュをトリガーに自動デプロイ
        • Dockerfileが必要だが、上記以外の言語でも使用可能
  • VPCやELBのリソースの隠蔽
    • VPCやELBを作成せずにアプリのプロビジョニングが可能
    • 既存VPCリソースへのアクセスも可能に(VPC Connector)
  • ロググループの自動作成
    • 以下3種類のログが自動で作成される
      • アプリケーションログ
      • デプロイログ
      • イベントログ
  • セキュリティグループの隠蔽
    • ECS, ELB用
  • AutoScalingポリシーの簡易化
    • ECS・Fargateの際のようなCloudWatch Alarmが必要ない
    • しかし別途設定がいる(ECSと少し項目が違う)
  • カスタムドメインの自前のDNSレコード作成・SSL証明書の検証などが不要(2023/10/05〜)
    • Route53での設定や管理がいらない
  • リクエスト処理をしていない(=アクティブでない)ときはvCPU料金がかからない
    • プロビジョニングされたコンテナインスタンス
      • メモリ(GB)ごとに料金が発生
    • アクティブ(リクエスト処理中)なコンテナインスタンス
      • メモリ(GB)ごと + vCPUごとに料金が発生
      • vCPU料金 = メモリ料金の9倍 (東京リージョン)
    • aws.amazon.com


AWS App Runnerのデメリット

対応済み

  • AWS WAFをアタッチできない
    • 2023/02/24 AWS WAFサポートされました!!
    • Fargateでの運用ではELBにアタッチする
  • 秘匿な環境変数が扱えない
    • 2023/01/06 AWS Secrets ManagerとAWS Systems Managerからのシークレットの取得に対応されました!!
    • ECS Fargateでは以下との統合が可能
      • Secrets Manager
      • Systems Manager Parameter Store
  • カスタムドメイン設定でALIASレコードが未対応
    • 2022/08/30 ALIASレコード対応されました!!
  • スペックの種類が少ない(以下のCPU, Memoryの組み合わせ)
    • 2023/04/05 11種類のスペックの組み合わせになりました!!
    • ECS Fargateは16v CPU, 120 GBまで可能なため、まだ小規模向けではあります。
vCPU(CPU) GB(メモリ)
0.25 vCPU 0.5 GB
0.25 vCPU 1 GB
0.5 vCPU 1 GB
1 vCPU 2 GB
1 vCPU 3 GB
1 vCPU 4 GB
2 vCPU 4 GB
2 vCPU 6 GB
4 vCPU 8 GB
4 vCPU 10 GB
4 vCPU 12 GB
  • AutoScalingConfigurationがCloudFormation未対応
    • 2023/06/22 CloudFormation対応されました!!

未対応

  • Arm(Graviton)イメージ未対応
  • App Runnerへのインバウンドを制御するセキュリティグループがつけられない
    • 現状App Runnerにアタッチするセキュリティグループはアウトバウンドに使われるものであるため
  • スケーリング基準が同時実行数のみ
    • 他のメトリクスでのスケーリングは現状できない
  • AutoScalingの最低台数を0にはできない
  • 何台立ち上げているのかわからない(わかりづらい)
    • アクセスが来ない期間は、Active Instancesメトリクスが0になるため
    • 料金の大部分(vCPU代)はActive Instancesに起因して料金発生する(0なら発生しない)ので、Fargateと比べて厳密にわからなくても良いところはある
  • ECR連携で自動デプロイをする場合、実質latestタグ固定の運用が必要
    • 自動デプロイは特定のイメージタグのプッシュをトリガーにするために、固定のタグの必要がある
    • タグをイミュータブル(上書き禁止)にできない
  • アクセスログが出せない
  • サイドカーコンテナを組み込めない
  • ECSのContainer Insightsレベルのメトリクスは取れない
  • ECS Execができない
  • カスタムドメインがCloudFormation未対応
    • CLIかカスタムリソースが必要
  • EFS未対応
  • Windowsコンテナ未対応


どちらでも変わらないこと

  • ソースコードまたはDockerfile(ECR連携の場合)の管理
  • スペック指定の必要
    • CPU
    • メモリ
  • AutoScalingのルール定義
    • 最小台数
    • 最大台数
    • スケールアウトの閾値
      • App Runnerでは同時接続数(デフォルト: 100)
  • ヘルスチェックルール定義
  • IAMロールの管理
    • App Runnerの方が少しは楽
      • CloudWatch Logsなどへのポリシーはいらないため
  • ポートや環境変数の管理
    • やらなくても良い


ロードマップ

今後のApp RunnerのロードマップをGitHubのissuesにて見ることができます。

欲しい機能などのissueがあればgoodリアクションをすると良いですね。

github.com


実際にロードマップに機能追加のリクエストを出してみました。起票の仕方なども書いてみたので、よかったらぜひご覧下さい。

go-to-k.hatenablog.com


AWS CDK・CloudFormation

App RunnerをAWS CDKやCloudFormationで作成する記事も書いているので、良かったらぜひご覧下さい。

go-to-k.hatenablog.com

go-to-k.hatenablog.com

go-to-k.hatenablog.com


最後に

App Runnerをちゃんと触ってみて、すごく便利だなと思いつつも痒いところに手が届かない点が見えてきました。


でもフルマネージドサービスってトレードオフというか、こういうことですよね。

あまり機能を詰めてもECS・Fargateと変わらなくなってしまうし・・・

ただFargateのフルマネージド感や便利さもすごかったのに、さらに便利なマネージドサービスが出てくるところが技術の進化・変化を感じますね。


今後いい塩梅に機能が追加されてくれたらもっと素晴らしいサービスになりそうで、今後に期待です。