Blog

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円程度から。