AWS上でサーバー運用

Jun 30, 2025

Gemini に AWS Beanstalk や App Runner について聞いてみました。

質問 1

AWS Elastic Beanstalk や AWS App Runner を使って、Web サーバー(nginx, php, mariadb, etc)の保守を自動化できますか？

回答

はい、AWS Elastic Beanstalk と AWS App Runner はどちらも、Web サーバー（Nginx、PHP、MariaDB など）の保守を自動化するのに役立つサービスですが、そのアプローチと適しているユースケースが異なります。

それぞれのサービスについて詳しく見ていきましょう。

AWS Elastic Beanstalk

概要: Elastic Beanstalk は、Web アプリケーションのデプロイとスケーリングを容易にするサービスです。コードをアップロードするだけで、Elastic Beanstalk が容量のプロビジョニング、ロードバランシング、自動スケーリング、アプリケーションのヘルスモニタリングといったデプロイの詳細を自動的に処理します。Nginx や PHP などの Web サーバー環境は、提供されるプラットフォームの一部として管理されます。

保守の自動化について:

OS とミドルウェアのパッチ適用: Elastic Beanstalk は、基盤となる EC2 インスタンスの OS や、選択したプラットフォーム（例: PHP with Apache/Nginx）に含まれるミドルウェアのパッチ適用を自動的に行います。これは環境の更新として提供され、適用することでセキュリティアップデートやバグ修正が適用されます。
スケーリング: トラフィックの増減に応じて、EC2 インスタンスの数を自動的に調整します（オートスケーリング）。
ヘルスモニタリングと回復: アプリケーションのヘルスを監視し、異常なインスタンスを自動的に置き換えたり、問題を特定したりするのに役立ちます。
デプロイの管理: アプリケーションの新しいバージョンをデプロイする際、ダウンタイムを最小限に抑えるローリングアップデートやイミュータブルデプロイなどのオプションを提供します。
データベースの統合: RDS（MariaDB を含む）と統合することで、データベースのプロビジョニングと管理を Elastic Beanstalk 環境の一部として行えます。RDS 自体がデータベースのバックアップ、パッチ適用、レプリケーションなどの管理機能を備えています。

Nginx, PHP, MariaDB の場合:

Elastic Beanstalk の PHP プラットフォームを選択すると、Nginx（または Apache）と PHP が設定された環境が自動的にプロビジョニングされます。
MariaDB については、Elastic Beanstalk 環境とは別に RDS インスタンスをプロビジョニングし、Elastic Beanstalk アプリケーションから接続するように設定するのが一般的です。RDS が MariaDB の保守（パッチ、バックアップなど）を自動化します。

メリット:

幅広いプログラミング言語と Web サーバーをサポート。
基盤となるインフラストラクチャへのアクセスと制御の柔軟性がある（必要に応じて EC2 インスタンスの設定をカスタマイズ可能）。
本番環境での実績が豊富。

デメリット:

App Runner と比較して、ある程度のインフラストラクチャの概念を理解する必要がある。
より複雑な構成の場合、設定ファイル（.ebextensions）の記述が必要になることがある。

AWS App Runner

概要: App Runner は、コンテナ化された Web アプリケーションと API のデプロイをさらに簡素化することに特化したフルマネージドサービスです。コードリポジトリやコンテナイメージから直接アプリケーションをデプロイでき、インフラストラクチャの管理を完全に抽象化します。

保守の自動化について:

フルマネージド: 基盤となる OS、サーバー（Nginx など）、コンテナランタイムはすべて AWS によって管理され、パッチ適用やアップデートが自動的に行われます。ユーザーがこれらのインフラストラクチャ層を管理する必要はありません。
自動スケーリング: トラフィックに基づいて、自動的にスケールアップ・ダウンします。コールドスタートなしでほぼ瞬時にスケールできます。
ビルドとデプロイの自動化: ソースコードリポジトリ（例: GitHub）と連携し、コードの変更がプッシュされるたびに自動的に新しいイメージをビルドし、デプロイできます。
ロードバランシングと SSL: ロードバランシングと SSL 証明書の管理が自動的に行われます。
ヘルスモニタリング: アプリケーションのヘルスを監視し、異常を検出します。

Nginx, PHP, MariaDB の場合:

Nginx と PHP: これらは、アプリケーションの Dockerfile 内に記述し、コンテナイメージとしてビルドする必要があります。App Runner は、そのコンテナイメージを実行します。つまり、Nginx と PHP のインストールと設定は Dockerfile 内で管理されることになります。
MariaDB: App Runner はステートレスなサービスであるため、データベースを直接ホストすることはできません。MariaDB は、RDS のようなマネージドデータベースサービスとして別途プロビジョニングし、App Runner アプリケーションから接続する必要があります。RDS が MariaDB の保守を自動化します。

メリット:

インフラストラクチャ管理が最小限で済む（OS、サーバー、コンテナランタイムのパッチ適用などが自動）。
コンテナベースのため、環境の一貫性が高い。
CI/CD パイプラインが組み込まれており、デプロイが非常に容易。
従量課金制で、リクエストがない場合は課金されない（アイドル状態での課金はごくわずか）。

デメリット:

アプリケーションをコンテナ化する必要がある。
Elastic Beanstalk と比較して、基盤となるインフラストラクチャへの制御が非常に限定される。
特定のユースケース（例えば、特定の OS レベルのカスタマイズが必要な場合など）には不向きな場合がある。

まとめと推奨

機能	AWS Elastic Beanstalk	AWS App Runner
得意分野	伝統的な Web アプリケーション、カスタマイズ性が必要な場合	コンテナ化された Web アプリケーション、API、フルマネージドを重視する場合
インフラ管理	AWS が管理するが、ある程度の制御が可能	完全に AWS が管理
OS/ミドルウェアの保守	プラットフォームレベルで自動。ユーザーは更新を適用	完全に自動（ユーザーは気にしなくて良い）
スケーリング	自動（オートスケーリング）	自動（高速スケーリング）
Nginx/PHP	プラットフォームに含まれる、またはコンテナ化してデプロイ	アプリケーションのコンテナイメージに含める
MariaDB	RDS と連携して別途管理（推奨）	RDS と連携して別途管理（必須）
デプロイ	コードをアップロード、または CI/CD と連携	コードリポジトリまたはコンテナイメージから自動デプロイ
複雑性	中程度	低

結論として、Web サーバー（Nginx, PHP, MariaDB）の保守を自動化したい場合：

より簡単な操作性、インフラ管理の手間を極力省きたい、かつアプリケーションがコンテナ化可能であれば、「AWS App Runner」が非常に強力な選択肢です。特に新しいプロジェクトや、マイクロサービスのように独立した API をデプロイするのに適しています。Nginx や PHP はアプリケーションのコンテナイメージに含める形になります。MariaDB は RDS を利用します。
既存の PHP アプリケーションなど、もう少し柔軟性が必要な場合や、特定の OS/サーバー設定をカスタマイズする必要がある場合は、「AWS Elastic Beanstalk」が適しています。 Elastic Beanstalk の PHP プラットフォームが Nginx/Apache と PHP の基盤を管理し、MariaDB は RDS を利用します。

どちらのサービスも、MariaDB などのデータベースに関しては、AWS RDS（Relational Database Service）を利用することで、バックアップ、パッチ適用、レプリケーションなどの保守を自動化するのが一般的かつ推奨される方法です。App Runner も Elastic Beanstalk も、RDS インスタンスへの接続を容易にする機能を提供しています。

質問 2

では App Runner を前提としてリーズナブルな Web サーバーを構成する際の月額コストはどれくらいですか？構成内容と合わせて教えて欲しい。

回答

AWS App Runner を前提としたリーズナブルな Web サーバー構成と月額コストについてご説明します。

重要な注意点:

App Runner は無料利用枠の対象外です。 ただし、使用量に応じて課金されるため、トラフィックが少ない場合は非常にリーズナブルに利用できます。
MariaDB は App Runner に直接含めることはできません。 App Runner はステートレスな Web アプリケーション向けであり、データベースは別途マネージドサービス（AWS RDS）として利用するのが一般的です。RDS にも無料利用枠がありますが、それを超えると料金が発生します。
東京リージョン（ap-northeast-1）の料金で試算します。 リージョンによって料金が異なります。
想定するトラフィックとリソース: ここでは、小規模な Web サイトや開発環境を想定した「リーズナブルな」構成で試算します。

構成内容

Web アプリケーション層 (AWS App Runner)
- 役割: Nginx と PHP を実行する Web サーバー。アプリケーションコードもここにデプロイされます。
- App Runner サービス:
  - インスタンスタイプ: 最小のインスタンスタイプを選択します。
    - vCPU: 0.25 vCPU
    - メモリ: 0.5 GB
  - プロビジョニングされたインスタンス: 1 インスタンス
    - これは、トラフィックがないアイドル状態でも常に稼働しているインスタンスの数です。応答速度を重視する場合は 1 以上、完全にコストを抑えたい場合は 0 にすることも可能ですが、その場合はコールドスタート（最初のリクエストへの応答が遅くなる）が発生します。ここでは「リーズナブル」を重視しつつ、ある程度の応答性を確保するため「1」とします。
  - オートスケーリング: 最大インスタンス数は、必要に応じて増やすことができますが、ここでは「1」（トラフィックが増えてもインスタンスは増えない）と仮定します。
  - デプロイ元: ソースコード（例: GitHub）から自動デプロイ
  - Nginx と PHP: これらは Docker イメージ内に含めて App Runner にデプロイします。例：Dockerfileで Nginx を Web サーバーとして設定し、PHP-FPM と連携させます。
データベース層 (AWS RDS for MariaDB)
- 役割: MariaDB データベース。
- インスタンスタイプ: db.t3.micro (無料利用枠の範囲内、またはその次の最小構成)
  - vCPU: 2 vCPU
  - メモリ: 1 GB
- ストレージ: 20 GB (汎用 SSD - gp3)
- Multi-AZ (マルチ AZ): なし (可用性よりもコストを優先)
- バックアップ: 自動バックアップを有効 (デフォルト)
データ転送
- App Runner からのアウトバウンドデータ転送: ごく少量（例えば月間 1GB）を想定。
- RDS からのアウトバウンドデータ転送: ごく少量（例えば月間 1GB）を想定。

月額コスト試算（東京リージョン）

AWS の料金は複雑で、正確な見積もりには AWS 料金計算ツールを使用するのが最も確実ですが、以下の概算を示します。

1. AWS App Runner の費用

App Runner の料金は以下の要素で構成されます。

プロビジョニングされたインスタンス料金 (Provisioned Container Instances): アイドル状態でも割り当てられているリソースに対して発生します。
- 東京リージョン: $0.009 / GB-時間、 $0.000007 / vCPU-秒
- メモリ: 0.5 GB
- vCPU: 0.25 vCPU
- 計算:
  - メモリ: 0.5 GB _ $0.009/GB-時間 _ 24 時間/日 * 30 日/月 = $3.24/月
  - vCPU: 0.25 vCPU _ $0.000007/vCPU-秒 _ 3600 秒/時間 _ 24 時間/日 _ 30 日/月 = $4.536/月
- 合計 (プロビジョニング): $3.24 + $4.536 = 約 $7.78/月
アクティブなインスタンス料金 (Active Instances): リクエスト処理中に実際に消費された CPU とメモリに対して発生します。
- 東京リージョン: $0.009 / GB-時間、 $0.000007 / vCPU-秒
- これはトラフィック量に依存します。例えば、1 日あたり平均 4 時間の処理が常に発生すると仮定した場合：
- メモリ: 0.5 GB _ $0.009/GB-時間 _ 4 時間/日 * 30 日/月 = $0.54/月
- vCPU: 0.25 vCPU _ $0.000007/vCPU-秒 _ 3600 秒/時間 _ 4 時間/日 _ 30 日/月 = $0.756/月
- 合計 (アクティブ): 約 $1.30/月 (トラフィックが非常に少ない場合はほとんどゼロに近くなります)
自動デプロイ料金 (Automated Deployments): ソースコードからのデプロイを自動化する場合、月に一度の料金が発生します。
- $0.10/月
ビルド料金 (Build Fee): ソースコードからコンテナイメージをビルドする際に発生します（ビルド時間に応じて）。
- 例えば、月に 1 回デプロイし、ビルドに 5 分かかると仮定します。
- $0.005 / ビルド分
- 5 分 * $0.005/分 = $0.025/月
データ転送アウト料金 (Data Transfer Out): App Runner からインターネットへのデータ転送量に応じて発生します。
- 最初の 1GB は無料、それ以降は$0.14/GB (東京リージョン)
- 仮に月間 1GB のデータ転送があった場合: $0 (無料枠内)

App Runner 合計概算: $7.78 (プロビジョニング) + $1.30 (アクティブ - 例) + $0.10 (自動デプロイ) + $0.025 (ビルド) + $0 (データ転送) = 約 $9.20/月

2. AWS RDS for MariaDB の費用

インスタンス料金 (db.t3.micro):
- 東京リージョン: $0.017 / 時間
- $0.017/時間 _ 24 時間/日 _ 30 日/月 = $12.24/月
- 注意: RDS の無料利用枠（db.t2.microまたはdb.t3.microで月 750 時間まで）を使い切っている場合はこの料金が発生します。新規アカウントで無料枠内であれば、この部分は無料になります。
ストレージ料金 (汎用 SSD - gp3):
- 20 GB * $0.138/GB-月 (東京リージョン) = $2.76/月
バックアップストレージ料金:
- プロビジョニングされたストレージの 100%までは無料。それを超えると課金されます。
- ここでは**$0**と仮定します。
データ転送アウト料金:
- RDS からインターネットへのデータ転送量に応じて発生します。
- 仮に月間 1GB のデータ転送があった場合: $0 (無料枠内)

RDS 合計概算: $12.24 (インスタンス) + $2.76 (ストレージ) = 約 $15.00/月

全体月額コストの概算

App Runner (Web サーバー) + RDS (データベース) = 約 $9.20 + $15.00 = 約 $24.20/月

日本円に換算すると、仮に 1 ドル 155 円とすると、 $24.20 * 155 円/ドル = 約 3,751 円/月

考慮すべきその他の要素

無料利用枠の状況: AWS の無料利用枠を最大限に活用できれば、RDS の部分が無料になり、さらにコストを抑えられます。
CloudWatch Logs: App Runner と RDS のログは CloudWatch Logs に送信され、そのストレージと取り込み量に応じて少額の料金が発生する可能性がありますが、通常は非常にリーズナブルです。
トラフィック量: App Runner のアクティブインスタンス料金やデータ転送料金は、Web サイトのトラフィック量に大きく依存します。トラフィックが増えれば増えるほど、これらの費用は増加します。
データベースの負荷: RDS インスタンスの CPU、メモリ使用量、IOPS が増加すると、料金も増加します。
開発/テスト環境: 常に稼働させておく必要がない場合、App Runner のサービスを停止（あるいは最小インスタンス数を 0 に設定）することで、プロビジョニング料金を抑えることができますが、前述の通りコールドスタートが発生します。
VPC の利用: App Runner を VPC 内にデプロイする場合、VPC コネクタの料金が別途発生する場合がありますが、パブリックアクセスで十分な場合は不要です。

この試算はあくまで「リーズナブルな」構成とトラフィックを想定した概算です。実際の利用状況によって変動しますので、AWS 料金計算ツールで詳細な見積もりを作成することを強くお勧めします。

ざっくりとまとめ

App Runner で「Web アプリケーションや API を実行するための環境（サービス）を構築する」のが良さそう。月額 4000 円程度から。