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

AWS ECS/Fargate/AppRunner

概要

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


目次

目次


注意

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

（2022年2月13日に執筆しました。新規情報があれば随時更新していきます。）


アップデート情報



前提

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


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


AWS App Runnerのメリット

  • CI/CDの簡易化
    • GitHubとの連携により、簡単にCI/CDが実行可能
      • コードのプッシュをトリガーに自動デプロイ
        • コンテナイメージいらず！
      • 対応言語(ランタイム)
        • Python 3
        • Node.js 12/14/16
        • Java(Corretto 8, Corretto 11)
    • ECRとの連携により、簡単にCI/CDが実行可能
      • イメージのプッシュをトリガーに自動デプロイ
  • VPCやELBのリソースの隠蔽
    • VPCやELBを作成せずにアプリのプロビジョニングが可能
    • 既存VPCリソースへのアクセスも可能に
    • go-to-k.hatenablog.com
  • ロググループの自動作成
    • 以下3種類のログが自動で作成される
      • アプリケーションログ
      • デプロイログ
      • イベントログ
  • セキュリティグループの隠蔽
    • ECS, ELB用
  • AutoScalingポリシーの簡易化
    • ECS・Fargateの際のようなCloudWatch Alarmが必要ない
    • しかし別途設定がいる(ECSと少し項目が違う)
  • SSL証明書の発行
    • ACMでの設定・管理がいらない
    • しかし同じような手順は行う必要がある


AWS App Runnerのデメリット

  • ECR連携で自動デプロイをする場合、実質latestタグ固定の運用が必要
    • 自動デプロイは特定のイメージタグのプッシュをトリガーにするために、固定のタグの必要がある
    • タグをイミュータブル(上書き禁止)にできない
  • 秘匿な環境変数が扱えない
    • ECS Fargateでは以下との統合が可能
      • Secrets Manager
      • Systems Manager Parameter Store
  • カスタムドメイン設定でALIASレコードが未対応
    • 2022/08/30 ALIASレコード対応されました!!
  • AWS WAFをアタッチできない
    • Fargateでの運用ではELBにアタッチする
  • App Runnerへのインバウンドを制御するセキュリティグループがつけられない
    • 現状App Runnerにアタッチするセキュリティグループはアウトバウンドに使われるものであるため
  • IP制限ができない
    • 上記の通り、WAFやインバウンド用セキュリティグループがつけられないため
    • CloudFrontを前段に置けば可能
  • アクセスログが出せない
  • サイドカーコンテナを組み込めない
  • ECSのContainer Insightsレベルのメトリクスは取れない
  • ECS Execができない
  • スケーリング基準が同時実行数のみ
    • 他のメトリクスでのスケーリングは現状できない
  • AutoScalingの最低台数を0にはできない
  • 何台立ち上げているのかわからない（わかりづらい）
    • アクセスが来ない期間は、Active Instancesメトリクスが0になるため
    • 料金の大部分(vCPU代)はActive Instancesに起因して料金発生する(0なら発生しない)ので、Fargateと比べて厳密にわからなくても良いところはある
  • スペックの種類が少ない(以下のCPU, Memoryの組み合わせのみ)
    • 1 vCPU, 2 GB
    • 1 vCPU, 3 GB
    • 1 vCPU, 4 GB
    • 2 vCPU, 4 GB
  • カスタムドメインやAutoScalingConfigurationがCloudFormation未対応
    • CLIかカスタムリソースが必要
  • Arm(Graviton)イメージ未対応
  • 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


最後に

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


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

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

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


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



※Twitter始めました！

良かったらぜひ。お知り合い増やせたら嬉しいです。

Twitter ID → @365_step_tech