AWS App Runner

AWS App Runner は、コンテナ化された Web アプリケーションや API を、インフラの構築・運用を意識せずに本番環境へ公開できるフルマネージドサービスです。ソースコードまたはコンテナイメージを指定すれば、ビルド・デプロイ・スケーリング・負荷分散・HTTPS 終端までをサービス側が引き受けます。

解決する課題

Web アプリや API をクラウドで公開する際、本来やりたいのはアプリの開発であるにもかかわらず、その周辺で多くの作業が発生します。コンテナを動かすためのクラスター構築、ロードバランサーの設定、TLS 証明書の取得と更新、オートスケーリングのポリシー設計、デプロイパイプラインの整備などです。これらは専門知識を要し、運用負荷も大きくなりがちです。

App Runner は、こうした周辺作業を抽象化します。利用者はコンテナイメージかソースリポジトリを指定するだけで、あとはサービスが実行環境を用意し、外部からアクセス可能な HTTPS エンドポイントを発行します。小規模なチームや、インフラ管理に時間を割きたくない開発者が、素早くアプリを本番公開したいケースに適しています。

主要概念と用語

• サービス: App Runner における最上位のデプロイ単位。1 つの Web アプリや API に対応し、固有の HTTPS URL を持つ。
• ソース: アプリの供給元。ECR などに置いたコンテナイメージを使うソースイメージ方式と、GitHub などのリポジトリからビルドするソースコード方式の 2 種類がある。
• 自動デプロイ: ソースイメージやソースコードが更新されたことを検知し、新しいバージョンを自動でデプロイする仕組み。
• オートスケーリング設定: 同時リクエスト数に基づいてインスタンス数を増減させるためのパラメータ群。最小・最大インスタンス数や 1 インスタンスあたりの同時実行数を定義する。
• プロビジョンドインスタンス: リクエストを待ち受けるためにあらかじめ確保しておくインスタンス。コールドスタートを避けたい場合に使う。
• アクティブインスタンス: 実際にリクエストを処理しているインスタンス。リクエストがあるときだけ課金対象の CPU が割り当てられる。
• VPC コネクタ: App Runner サービスから VPC 内のリソース、たとえばデータベースなどへ接続するための仕組み。

仕様・制限・クォータ

App Runner は HTTP/HTTPS のリクエストを受け付ける Web アプリや API のための実行基盤です。コンテナはリッスンするポートを 1 つ公開し、サービスがその前段で TLS 終端と負荷分散を行います。バックグラウンド常駐処理やバッチ、長時間のジョブのような用途には向いていません。

1 サービスあたりに割り当てられる CPU とメモリの組み合わせには、あらかじめ用意された選択肢の中から選ぶ形になります。同時リクエスト数、最小・最大インスタンス数などにも上限が設けられています。具体的な数値はリージョンや時期によって変わり得るため、最新の値は AWS の公式ドキュメントで確認してください。サービス数やデプロイ頻度などのアカウント単位のクォータの一部は、申請により引き上げられる場合があります。

内部の仕組み

App Runner はソースの種類に応じて 2 つの流れを持ちます。ソースイメージ方式では、ECR にあるコンテナイメージを取得してそのまま実行します。ソースコード方式では、GitHub などの接続済みリポジトリからコードを取得し、指定したランタイムと設定に基づいてサービス側でコンテナイメージをビルドしてから実行します。

実行されたコンテナの前段には、サービス管理のロードバランサーと TLS 終端層が自動的に配置され、固有のドメインで HTTPS エンドポイントが提供されます。トラフィックが増えると、オートスケーリング設定にしたがってインスタンスが追加され、減ると縮退します。リクエストがない間はアクティブな処理用 CPU を割り当てず、待機用のメモリ確保のみとなるため、アイドル時のコストが抑えられます。デプロイはローリング方式で行われ、新しいバージョンが正常に立ち上がってからトラフィックが切り替わるため、無停止での更新がしやすくなっています。

設計パターン / ベストプラクティス

ステートレスな Web アプリや API を載せるのが基本方針です。セッションやファイルなどの状態はコンテナ内に持たず、外部のデータストアやオブジェクトストレージに委ねることで、インスタンスが増減しても一貫した挙動を保てます。

データベースなど VPC 内のプライベートなリソースへアクセスする場合は、VPC コネクタを介して接続します。ヘルスチェックのパスを適切に設定し、アプリの起動完了を正しく判定できるようにしておくと、デプロイ時の切り替えが安定します。コールドスタートによるレイテンシが許容できないワークロードでは、最小インスタンス数を 1 以上にしてプロビジョンドインスタンスを確保しておく方法が有効です。

運用・監視

App Runner はアプリケーションログとサービスのシステムログを CloudWatch Logs に出力します。アプリ側は標準出力や標準エラーへログを書き出すように作っておくと、追加設定なしで収集されます。リクエスト数、レイテンシ、アクティブインスタンス数、CPU やメモリの使用率といったメトリクスは CloudWatch メトリクスで確認でき、しきい値に基づくアラームの設定も可能です。

デプロイ履歴はサービス単位で記録され、問題が発生した場合は以前の正常なバージョンへ戻すことで影響を抑えられます。設定変更や監査の観点では、API 操作が CloudTrail に記録されます。

コスト

課金はおおむね 2 つの要素から成ります。1 つはリクエストを処理しているアクティブな間に消費される CPU の利用量、もう 1 つはインスタンスを待機させておくためのメモリの確保量です。リクエストがないアイドル時は処理用 CPU が課金されないため、トラフィックに波があるワークロードではコスト効率が高くなりやすい一方、最小インスタンス数を増やしてプロビジョンドインスタンスを常時確保すると、その分のメモリ確保コストが継続的に発生します。

ソースコード方式を使う場合のビルドにも費用が関係します。具体的な単価はリージョンや時期で変動するため、見積もりは公式の料金ページと料金計算ツールで確認してください。

セキュリティ

外部公開されるエンドポイントは HTTPS で提供され、TLS 終端はサービス側が担います。アプリが AWS の他サービスへアクセスする際は、サービスに割り当てたインスタンスロールの権限を用い、長期的なアクセスキーをコンテナに埋め込まないようにします。一方、ソースイメージの取得など App Runner 自体が AWS リソースへアクセスする操作には、アクセスロールが使われます。

データベースなどプライベートリソースへの接続は VPC コネクタ経由とし、インターネットを経由させない設計が安全です。認証や認可はアプリケーション側、あるいは前段に置いた認証の仕組みで実装します。機密情報は Secrets Manager や Systems Manager パラメータストアで管理し、環境変数として安全に参照する運用が推奨されます。

Well-Architected の観点

運用上の優秀性の観点では、インフラの構築・運用をサービスに委ねることで、開発者がアプリのコードと改善に集中できる点が大きな利点です。ビルドからデプロイ、ローリング更新、ログ・メトリクス収集までが標準化されているため、運用の属人化を避けやすくなります。

信頼性の面ではマネージドな負荷分散とオートスケーリングにより需要変動へ追従でき、ヘルスチェックと自動デプロイの仕組みが安定した更新を支えます。コスト最適化の観点では、アイドル時に処理用 CPU が課金されないモデルが、トラフィックに波のあるワークロードでの無駄を減らします。

試験で問われるポイント

関連サービス・比較

同じくコンテナを動かす Amazon ECS on Fargate と比較すると、抽象度と制御の自由度のトレードオフが明確になります。

ハンズオン / CLI例

ECR のコンテナイメージから App Runner サービスを作成する例です。ロールの ARN やイメージの URI は自分の環境の値に置き換えてください。

aws apprunner create-service \
  --service-name my-web-app \
  --source-configuration '{
    "AuthenticationConfiguration": {
      "AccessRoleArn": "arn:aws:iam::123456789012:role/AppRunnerECRAccessRole"
    },
    "ImageRepository": {
      "ImageIdentifier": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-web-app:latest",
      "ImageRepositoryType": "ECR",
      "ImageConfiguration": {
        "Port": "8080"
      }
    },
    "AutoDeploymentsEnabled": true
  }' \
  --instance-configuration '{
    "Cpu": "1 vCPU",
    "Memory": "2 GB"
  }'