公開先の選択で手が止まる理由
この記事は要約版です。省略した詳しい解説や手順は、ブログの完全版にまとめています: VPSとAWSどっちを選ぶ？個人開発・学習・転職の目的別に違いを比較
自作のWebアプリを初めて公開するとき、VPSを1台借りるかAWSを使うかで迷います。月数千円という予算では金額が近いのに、契約の単位、障害時に誰が何をするか、あとから規模を広げられるかが異なります。料金は改定されるため、最終的な金額は各サービスの公式料金ページとAWS Pricing Calculatorで確認してください。
技術的な土台は同じで、違うのは提供の単位
VPSもEC2も、物理サーバー上のハイパーバイザで動く仮想マシンを借りる仕組みです。利用者はゲストOS以上を自分で管理します。差が出るのは売り方です。VPSはvCPU・メモリ・ディスク・転送量をまとめたプランを月単位で契約します。AWSはコンピュート、ブロックストレージ、ロードバランサー、マネージドDB、権限管理が個別のサービスとして提供され、必要な部品を選んで組み立てます。
VPSは完成品のサーバー1台、AWSは部品のカタログです。VPSは決める項目が少ないぶん早く動き出せる反面、冗長化やスケールは自分で設計します。中間解としてAmazon Lightsailがあり、月額固定のバンドルでVPSに近い課金感覚になります。ただしLightsailだけで運用すると、VPC設計やIAM、ALB、Auto Scalingには触れないままになります。
判断基準は「予測可能性」か「冗長化と学習価値」か
常時稼働でアウトバウンド転送量が多く、構成が固定なら、VPSの月額固定が安く収まりやすいです。稼働時間が短い場合や、環境を作って消す使い方ならAWSの秒課金が有利になります。見積もりは月間の稼働時間とアウトバウンド転送量の2つから始めてください。
責任共有モデル自体は両者でほぼ同じで、ゲストOS以上は利用者の責任です。振る舞いが分かれるのはホスト側に異常が出たときです。多くのVPSでは事業者が別ホストへ移送し、利用者は再起動確認で済む場合があります。AWSはscheduled eventとして通知され、期日までに利用者が停止・起動して載せ替えます。自動復旧はCloudWatchアラームなどで自分で組む前提です。
差が最も開くのは冗長化とマネージドサービスです。RDSのPostgreSQLマルチAZ構成では、プライマリのWALを別AZのスタンバイへ同期転送し、スタンバイ側の書き込み完了を待ってコミットを返します。書き込みレイテンシはAZ間往復のぶん増えますが、プライマリが失われてもコミット済みトランザクションは残ります。フェイルオーバーはエンドポイントのDNSレコード切り替えで行われ、完了までおおむね1〜2分かかります。アプリ側にはDNS TTLを長くキャッシュしない設定と接続リトライが必要です。
一方でRDSにはOSログインがなく、権限はrds_superuser止まりです。設定はパラメータグループ経由で、pg_hba.confも編集できません。拡張機能を自由に入れたい、OSレベルで調整したいという要件があるなら、VPSやEC2上の自前構築のほうが自由度は高くなります。
VPS 1台構成で先に決めるPostgreSQL設定
Web・アプリ・DBを1台に同居させる構成で最も多いのは、メモリ不足によるOOM Killerです。work_memは1接続あたりではなく、ソートやハッシュ結合の1操作あたりに割り当てられます。並列クエリが走ると並列ワーカー数のぶん膨らむため、同居構成では控えめにし、接続数はPgBouncerで絞ると安全です。
# postgresql.conf（メモリ2〜4GBの同居構成の出発点）
shared_buffers = 512MB # 搭載メモリの25%程度から
effective_cache_size = 1500MB # OSキャッシュ込みの想定値。プランナのヒント
work_mem = 8MB # ソート/ハッシュ1回あたり。接続数×並列度で膨らむ点に注意
maintenance_work_mem = 128MB
max_connections = 50 # 多すぎるとwork_mem合計でメモリ枯渇
random_page_cost = 1.1 # SSD前提。デフォルト4.0はHDD想定で不当にSeq Scanへ寄る
落ちたときはdmesg -T | grep -i oomで確認し、swapの有無を先に見ます。
AWSで請求が読みにくくなる要因
請求を膨らませる代表はインターネットへのアウトバウンド転送、インスタンスを止めても残るEBSとスナップショットと未使用のElastic IP、そして時間課金のNAT Gatewayです。ALBは時間課金に加えてLCUで変動し、RDSマルチAZはシングルAZの約2倍が目安になります。CloudWatch Logsも取り込み量と保存量で課金されます。EC2の単価だけを見て安いと判断するのが、最も多い見積もりミスです。
検証を終えたら、時間課金のリソースが残っていないかを確認してください。
# 検証後の棚卸し：NAT GatewayとALBの残骸チェック
aws ec2 describe-nat-gateways \
--query 'NatGateways[?State==`available`].[NatGatewayId,VpcId]' --output table
aws elbv2 describe-load-balancers \
--query 'LoadBalancerName,Type,State.Code]' --output table
予算アラートはリソースを触る前に作っておくのが順序です。
VPSからAWSへ移す場合の最小手順
最初にやるのは棚卸しです。OSとミドルウェアのバージョン、cronの一覧、証明書の有効期限、外部連携先のIP制限、DNSのTTL、シークレットの置き場所を書き出します。ダウンタイムを許容できるなら、論理バックアップでの移行が最も単純です。RDSにはsuperuserがないため、所有者やACLをそのまま復元しようとすると失敗します。
# 移行元でダンプ（カスタム形式）
pg_dump -Fc -h old-vps -U app_user -d myapp -f myapp.dump
# RDSへリストア（所有者・権限はスキップし、RDS側のロールに合わせる）
pg_restore -h myapp.xxxxx.ap-northeast-1.rds.amazonaws.com -U app_user \
-d myapp --no-owner --no-acl --jobs=4 myapp.dump
ダンプとリストアの方式では統計情報が引き継がれません。リストア直後は実行計画が悪化しがちなので、ANALYZEを必ず実行します。移行後に遅くなった場合は、t系インスタンスのCPUクレジット残量、ディスクI/Oの待機イベント、統計情報と実行計画、ロック待ち、接続数とwork_memの合計を順に確認します。
詳しくは
元記事では、料金体系やスペック変更、セキュリティと権限管理、撤退コストを含む7つの軸での比較と、個人開発・資格学習・アクセス変動それぞれのケースでの選び方を扱っています。AWSを選んだ場合のアカウント安全設計からIaCまでの4ステップ、CloudWatchアラームによる自動復旧の設定、論理レプリケーションでのダウンタイム最小化、照合順序やメール送信など移行時の注意点も具体的に書いています。