AWS App Runnerで手軽にコンテナデプロイ - ECR連携とサービス設定の実践ガイド

はじめに

コンテナアプリケーションをAWSにデプロイする際、ECSやEKSの設定は初学者にとって敷居が高いと感じることがあります。タスク定義、サービス設定、ロードバランサー、ターゲットグループなど、多くのコンポーネントを理解し設定する必要があるためです。

AWS App Runnerは、こうした複雑さを解消するために設計されたフルマネージドサービスです。コンテナイメージまたはソースコードを指定するだけで、数分でWebアプリケーションを公開できます。本記事では、App Runnerの特徴を理解した上で、ECRに保存したコンテナイメージをApp Runnerでデプロイする手順を実践的に解説します。

この記事を読むことで、以下のことができるようになります。

• App RunnerがECSやFargateと異なる点を理解する
• マネジメントコンソールからApp Runnerサービスを作成する
• ECRリポジトリと連携したデプロイを設定する
• 自動デプロイと手動デプロイの使い分けを判断する

App Runnerの概要

App Runnerとは

AWS App Runnerは、Webアプリケーションやapi をコンテナ環境で実行するためのフルマネージドサービスです。2021年5月に一般提供が開始され、インフラストラクチャの専門知識がなくてもコンテナアプリケーションを簡単にデプロイできることを目的としています。

flowchart LR
    subgraph Source["ソース"]
        GitHub["GitHub<br/>リポジトリ"]
        ECR["Amazon ECR<br/>コンテナイメージ"]
    end
    
    subgraph AppRunner["AWS App Runner"]
        Build["自動ビルド"]
        Deploy["自動デプロイ"]
        Scale["自動スケーリング"]
        LB["ロードバランシング"]
    end
    
    subgraph Output["出力"]
        URL["HTTPS URL<br/>xxx.awsapprunner.com"]
    end
    
    GitHub --> Build
    ECR --> Deploy
    Build --> Deploy
    Deploy --> Scale
    Scale --> LB
    LB --> URL

App Runnerでは、ソースとして「コンテナイメージ」または「ソースコードリポジトリ」を選択できます。コンテナイメージを選択した場合はECR（またはECR Public）から直接プルしてデプロイします。ソースコードリポジトリを選択した場合は、GitHubと連携してApp Runnerが内部でコンテナイメージをビルドします。

ECSやFargateとの違い

App Runnerは、ECSやFargateよりも高度に抽象化されたサービスです。開発者がインフラを意識せずにアプリケーションのデプロイに集中できるよう設計されています。

App Runnerは「とにかく早くデプロイしたい」「インフラの詳細設定は不要」というユースケースに最適です。一方、細かなネットワーク設計やコンテナ配置の制御が必要な場合は、ECS on Fargateを選択してください。

App Runnerが適しているユースケース

App Runnerは以下のようなケースで特に威力を発揮します。

Webアプリケーションやapi の迅速な公開

プロトタイプや小規模なWebアプリケーションを、インフラの準備に時間をかけずに公開したい場合に最適です。HTTPS対応のURLが自動で発行されるため、すぐにアクセス可能な状態になります。

開発・テスト環境の構築

本番環境はECSで運用しつつ、開発やテスト用の環境をApp Runnerで手軽に立ち上げるパターンも有効です。環境ごとのインフラ設定を省略でき、コストも使用した分だけで済みます。

インフラ専任者がいないチーム

スタートアップやスモールチームで、インフラに詳しいメンバーがいない場合でも、開発者だけでデプロイ環境を構築できます。

App Runnerサービスの作成手順

ここからは、マネジメントコンソールを使ってApp Runnerサービスを作成する手順を解説します。

前提条件

本手順を実行するには、以下の準備が必要です。

• AWSアカウントとマネジメントコンソールへのアクセス権限
• デプロイ対象のコンテナイメージ（ECRにプッシュ済み）
• コンテナイメージがHTTPリクエストを受け付けるポートを公開していること

ECRへのイメージプッシュ手順については、AWS ECRによるコンテナイメージ管理入門を参照してください。

ステップ1: App Runnerサービスの新規作成

マネジメントコンソールにログインし、App Runnerのページに移動します。「サービスを作成」ボタンをクリックして、サービス作成ウィザードを開始します。

flowchart TB
    subgraph Step1["ステップ1: ソースとデプロイ"]
        Source["ソースタイプ選択"]
        Repo["リポジトリ設定"]
        DeployConfig["デプロイ設定"]
    end
    
    subgraph Step2["ステップ2: ビルド設定"]
        Runtime["ランタイム選択"]
        BuildCmd["ビルドコマンド"]
        StartCmd["起動コマンド"]
    end
    
    subgraph Step3["ステップ3: サービス設定"]
        Name["サービス名"]
        Resource["リソース設定"]
        Scaling["スケーリング設定"]
        Network["ネットワーク設定"]
    end
    
    subgraph Step4["ステップ4: 確認と作成"]
        Review["設定確認"]
        Create["サービス作成"]
    end
    
    Step1 --> Step2
    Step2 --> Step3
    Step3 --> Step4

ステップ2: ソースの設定

「ソースとデプロイ」画面では、ソースタイプとデプロイ設定を行います。

リポジトリタイプ

本記事では「コンテナレジストリ」を選択してECRからデプロイする手順を解説します。

プロバイダー

「Amazon ECR」を選択します。ECR Publicを使用する場合は「Amazon ECR Public」を選択してください。

コンテナイメージのURI

ECRリポジトリのURIを指定します。形式は以下の通りです。

{アカウントID}.dkr.ecr.{リージョン}.amazonaws.com/{リポジトリ名}:{タグ}

例:

123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-web-app:latest

ステップ3: ECRアクセスロールの設定

App RunnerがECRからイメージをプルするには、適切なIAMロールが必要です。

新しいサービスロールを作成する場合

「新しいサービスロールを作成」を選択すると、App Runnerが自動的にAppRunnerECRAccessRoleという名前のIAMロールを作成します。このロールには、ECRからイメージをプルするために必要な最小限の権限が付与されます。

既存のサービスロールを使用する場合

組織のセキュリティポリシーで事前に作成したロールを使用する必要がある場合は、以下の権限を持つIAMロールを用意してください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:DescribeImages",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "*"
    }
  ]
}

信頼ポリシーでは、App Runnerサービスプリンシパルを許可する必要があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "build.apprunner.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ステップ4: デプロイ設定

デプロイのトリガー方法を選択します。

自動デプロイを有効にすると、ECRに新しいイメージがプッシュされるたびにApp Runnerが自動的にデプロイを開始します。CI/CDパイプラインとの連携が容易になりますが、月額1 USDの追加料金が発生します。

開発環境や頻繁にデプロイしないサービスでは「手動」を選択し、本番環境のCI/CDパイプラインでは「自動」を選択するケースが一般的です。

ステップ5: サービスの設定

サービス名

サービスを識別するための名前を入力します。この名前はURLには影響しません。

CPU とメモリ

アプリケーションの要件に応じて、vCPUとメモリの組み合わせを選択します。

最小構成（0.25 vCPU / 0.5 GB）は軽量なapi や開発環境に適しています。本番環境で一定のトラフィックが見込まれる場合は、1 vCPU / 2 GB以上を推奨します。

環境変数

アプリケーションに渡す環境変数を設定できます。データベースの接続情報やAPIキーなど、設定値を外部化する際に使用します。

機密情報（データベースパスワード、APIキーなど）は、必ずSecrets ManagerまたはParameter Storeを使用してください。

ポート

コンテナがリッスンするポート番号を指定します。デフォルトは8080です。アプリケーションが異なるポートを使用している場合は、ここで変更してください。

ステップ6: 自動スケーリングの設定

App Runnerは、リクエスト数に応じてコンテナインスタンスを自動的にスケールします。

最小インスタンス数

アイドル時でも維持するプロビジョニング済みインスタンスの数です。デフォルトは1です。この値を増やすと、急なトラフィック増加時のレスポンス遅延を軽減できますが、プロビジョニング料金が増加します。

最大インスタンス数

スケールアウト時の上限です。コスト管理のために、適切な上限を設定してください。

最大同時リクエスト数

1つのインスタンスが同時に処理できるリクエスト数です。デフォルトは100です。この値を超えるとスケールアウトがトリガーされます。

flowchart LR
    subgraph Requests["リクエスト"]
        R1["リクエスト1"]
        R2["リクエスト2"]
        R3["..."]
        R100["リクエスト100"]
        R101["リクエスト101"]
    end
    
    subgraph Instance1["インスタンス1<br/>（最大同時100）"]
        P1["処理中"]
    end
    
    subgraph Instance2["インスタンス2<br/>（スケールアウト）"]
        P2["処理中"]
    end
    
    R1 --> Instance1
    R2 --> Instance1
    R100 --> Instance1
    R101 --> Instance2

ステップ7: ネットワーク設定

受信トラフィック

インターネットからアクセス可能な「パブリック」がデフォルトです。内部用途の場合は「プライベート」を選択できます。

送信トラフィック（VPCコネクタ）

App RunnerからVPC内のリソース（RDS、ElastiCacheなど）にアクセスする必要がある場合は、VPCコネクタを設定します。

flowchart LR
    subgraph Internet["インターネット"]
        User["ユーザー"]
    end
    
    subgraph AppRunner["App Runner"]
        Service["App Runner<br/>サービス"]
    end
    
    subgraph VPC["VPC"]
        Connector["VPC<br/>コネクタ"]
        RDS["Amazon RDS"]
        Cache["ElastiCache"]
    end
    
    User --> Service
    Service --> Connector
    Connector --> RDS
    Connector --> Cache

VPCコネクタを使用する場合は、事前にApp Runnerコンソールまたはaws cliで作成しておく必要があります。

ステップ8: 確認と作成

設定内容を確認し、「作成とデプロイ」をクリックします。サービスの作成とデプロイには通常2〜5分程度かかります。

デプロイが完了すると、以下の形式のURLが発行されます。

https://{ランダムID}.{リージョン}.awsapprunner.com

このURLにアクセスして、アプリケーションが正常に動作することを確認してください。

ECRとの連携方法

ECRイメージのタグ戦略

App Runnerでは、ECRイメージのタグ指定が重要です。用途に応じて適切なタグ戦略を選択してください。

latestタグを使用する場合

123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

自動デプロイを有効にしている場合、latestタグへのプッシュで自動的にデプロイが開始されます。開発環境では便利ですが、本番環境では意図しないデプロイのリスクがあります。

バージョンタグを使用する場合

123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.2.3

バージョン番号やコミットハッシュをタグに使用すると、どのバージョンがデプロイされているか明確になります。ロールバック時にも役立ちます。

イミュータブルタグの活用

ECRリポジトリでイミュータブルタグを有効にすると、一度プッシュしたタグを上書きできなくなります。これにより、v1.0.0タグが指すイメージが変わることを防止できます。

自動デプロイのフロー

ECRプッシュから自動デプロイが完了するまでのフローを示します。

sequenceDiagram
    participant Dev as 開発者
    participant CI as CI/CD
    participant ECR as Amazon ECR
    participant AR as App Runner
    
    Dev->>CI: コードをプッシュ
    CI->>CI: ビルド & テスト
    CI->>ECR: docker push
    ECR->>AR: イメージプッシュ通知
    AR->>ECR: イメージをプル
    AR->>AR: ヘルスチェック
    AR->>AR: トラフィック切り替え
    Note over AR: デプロイ完了

自動デプロイでは、新しいイメージがECRにプッシュされると、App Runnerが自動的にイメージをプルしてデプロイを開始します。ヘルスチェックに成功すると、トラフィックが新しいインスタンスに切り替わります。

クロスアカウントでのECR連携

別のAWSアカウントにあるECRリポジトリからイメージをプルする場合は、追加の設定が必要です。

ECR側（ソースアカウント）の設定

リポジトリポリシーで、App Runnerが動作するアカウントからのアクセスを許可します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountPull",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{App Runnerアカウント}:root"
      },
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ]
    }
  ]
}

App Runner側のIAMロール設定

ECRアクセスロールに、クロスアカウントでのイメージプル権限を追加します。

料金とコスト最適化

App Runnerの料金体系

App Runnerの料金は、「プロビジョニング状態」と「アクティブ状態」で異なります。

プロビジョニング状態

アプリケーションがアイドル状態（リクエストを処理していない）のとき、コンテナインスタンスはプロビジョニング状態となります。この状態ではメモリ料金のみ発生し、vCPU料金は発生しません。

アクティブ状態

リクエストを処理しているとき、コンテナインスタンスはアクティブ状態となります。vCPUとメモリの両方に対して課金されます。

料金試算例

例1: 軽量なapi（1日8時間アクティブ、16時間アイドル）

構成: 1 vCPU / 2 GB メモリ

アクティブ時間（8時間/日）:
  vCPU: 0.081 USD × 1 vCPU × 8h = 0.648 USD
  メモリ: 0.009 USD × 2 GB × 8h = 0.144 USD

プロビジョニング時間（16時間/日）:
  メモリ: 0.009 USD × 2 GB × 16h = 0.288 USD

1日あたり: 約1.08 USD
1ヶ月（30日）: 約32.4 USD

例2: 開発環境（1日2時間アクティブ、22時間アイドル）

構成: 0.25 vCPU / 0.5 GB メモリ

アクティブ時間（2時間/日）:
  vCPU: 0.081 USD × 0.25 vCPU × 2h = 0.041 USD
  メモリ: 0.009 USD × 0.5 GB × 2h = 0.009 USD

プロビジョニング時間（22時間/日）:
  メモリ: 0.009 USD × 0.5 GB × 22h = 0.099 USD

1日あたり: 約0.15 USD
1ヶ月（30日）: 約4.5 USD

コスト最適化のポイント

サービスの一時停止

使用していない時間帯が長い場合は、コンソールやCLIからサービスを一時停止できます。一時停止中は料金が発生しません。

1
2
3
4
5

# AWS CLIでサービスを一時停止
aws apprunner pause-service --service-arn {サービスARN}

# サービスを再開
aws apprunner resume-service --service-arn {サービスARN}

適切なリソースサイジング

アプリケーションの実際の使用量を監視し、過剰なリソース設定を避けてください。CloudWatchメトリクスでCPU使用率とメモリ使用率を確認できます。

最大インスタンス数の制限

予期しないトラフィック増加による料金増加を防ぐため、最大インスタンス数に適切な上限を設定してください。

トラブルシューティング

デプロイが失敗する場合

イメージプルエラー

ECRアクセスロールに適切な権限が付与されているか確認してください。ロールの信頼ポリシーでbuild.apprunner.amazonaws.comが許可されている必要があります。

ヘルスチェック失敗

コンテナが指定されたポートでHTTPリクエストを受け付けているか確認してください。App Runnerは/パスに対してヘルスチェックを実行します。アプリケーションの起動に時間がかかる場合は、ヘルスチェックの猶予期間を延長してください。

アプリケーションが応答しない場合

ポート設定の確認

App Runnerの設定で指定したポートと、コンテナ内でアプリケーションがリッスンしているポートが一致しているか確認してください。

ログの確認

CloudWatch Logsでアプリケーションログを確認できます。App Runnerサービスの詳細画面から「ログ」タブにアクセスしてください。

VPC内リソースに接続できない場合

VPCコネクタの設定を確認してください。

• VPCコネクタが正しいサブネットに関連付けられているか
• セキュリティグループでApp Runnerからの接続が許可されているか
• RDSなどのターゲットリソースのセキュリティグループ設定

まとめ

AWS App Runnerは、コンテナアプリケーションを最小限の設定で迅速にデプロイできるフルマネージドサービスです。本記事では以下のポイントを解説しました。

• App RunnerはECSやFargateよりも抽象化されたサービスで、ロードバランサーや自動スケーリングが組み込まれている
• ECRからのイメージデプロイには、適切なIAMロール設定が必要
• 自動デプロイを有効にすると、ECRへのプッシュで自動的にデプロイが開始される
• 料金は「プロビジョニング状態」と「アクティブ状態」で異なり、アイドル時はメモリ料金のみ

シンプルなWebアプリケーションやapiを素早く公開したい場合、App Runnerは最適な選択肢です。一方、細かなネットワーク設計やコンテナ配置の制御が必要な場合は、ECS on Fargateを検討してください。

参考リンク

• AWS App Runner 公式ページ
• AWS App Runner 料金
• AWS App Runner デベロッパーガイド
• AWS App Runner よくある質問
• Amazon ECR ユーザーガイド