0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【インフラ】サーバーレス vs VM(EC2)どっちを選ぶ?

Posted at

はじめに

この記事は筆者の個人的な見解に基づいています。プロジェクトの要件や組織の状況によって最適解は異なりますので、あくまで一つの考え方として参考にしていただければ幸いです。

結論から言います。

image.png

対象読者

  • クラウドでのインフラ選択に迷っている方
  • 「サーバーレスって結局何がいいの?」と思っている方
  • 新規プロジェクトでEC2とLambda/Fargateのどちらを選ぶか悩んでいる方

サーバーレスとVMの違いをざっくり理解

まず、両者の違いを図で整理してみましょう。

image.png

「どこまで自分で管理するか」の違いが、選択の本質です。

サーバーレス / マネージドサービスが選ばれる理由

新規事業やWebアプリケーションの開発では、サーバーレス(AWS Fargate, Lambdaなど)が第一選択肢(Serverless First)になるケースが多いと私は感じています。

1. 運用コスト(人件費)の削減

OSのアップデートやセキュリティパッチの適用をAWS側がやってくれます。

エンジニアは「コードを書くこと」に集中できる。これが私にとって最大のメリットです。

2. スケーラビリティ

アクセスが増えたら勝手に増え、減ったら勝手に消える。

「3年後のアクセス数を予測してサーバーのスペックを決める」という不毛な作業から解放されます。

3. コスト効率(従量課金)

「動いた分だけ」の課金なので、誰も使っていない夜間のサーバー代を節約できます。

それでもVM(EC2)が選ばれる理由

一方で、あえてVM(EC2)を選択、あるいは併用するケースも依然として多いと感じています。

1. 特殊な設定が必要なケース

OSのカーネルレベルでのカスタマイズや、特定の古いミドルウェアを動かす必要がある場合は、VMの自由度が必要です。

# 例:カーネルパラメータの調整(サーバーレスではできない)
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w vm.swappiness=10

2. コストの予測しやすさ

24時間365日、一定の大きな負荷がかかり続けるシステムでは、従量課金のサーバーレスよりも、定額(リザーブドインスタンス等)のVMの方が安くなることがあります。

パターン おすすめ
アクセスが不規則・少ない サーバーレス 💰
24時間フル稼働・高負荷 VM(RI/Savings Plans) 💰

3. 既存資産の移行(リフト&シフト)

社内にある古いサーバーをそのままクラウドに持っていきたい場合、まずはVMに乗せるのが一番早いです。

これは「正解」ではなく「現実的な妥協」だと私は考えています。長期的にはサーバーレスへのリファクタリングを検討すべきでしょう。

比較表:特徴を一目で理解

私の視点で整理した比較表です。

具体的な使い分け

レイヤー 私のおすすめ 理由
フロントエンド / API Lambda, Fargate 管理が楽、スケールも自動
データベース RDS, Aurora, DynamoDB 自分でVMを立てず、マネージドサービスを利用
重い処理 / AI学習 EC2(GPUインスタンス) 専用の高性能VMで一気に処理

私の考え: 「VMの管理はめんどくさいし、付加価値を生まないから、できるだけクラウド屋さんに任せよう」という思想です。

よくある質問(FAQ)

Q. 全部サーバーレスじゃダメなの?

A. 技術的には可能ですが、コストや制約の問題があります。

例えば、以下のような制約があります:

  • Lambda: 実行時間15分制限、メモリ10GB制限
  • Fargate: GPUが使えない(2026年1月時点)

また、24時間フル稼働のワークロードでは、サーバーレスの方が高くつくこともあります。

Q. 最初はEC2で始めて後からサーバーレスに移行できる?

A. 可能ですが、設計次第で難易度が大きく変わります。

私のおすすめは:

  1. コンテナ化しておく → Fargateへの移行が楽
  2. ステートレスに設計する → Lambdaへの移行が楽
  3. 環境変数で設定を外出しする → どこでも動く
app.py
import os

# ❌ ハードコード
# db_host = "10.0.1.100"

# ⭕ 環境変数で外出し
db_host = os.environ.get("DB_HOST", "localhost")
移行を見据えた設計のポイント
  1. セッション情報をサーバーに持たない(Redisや外部ストアを使う)
  2. ファイルをローカルに保存しない(S3を使う)
  3. ログは標準出力に流す(CloudWatchが自動収集)

まとめ

観点 私の意見
基本姿勢 Serverless First(まずサーバーレスを検討)
VMを選ぶとき 特殊要件・レガシー移行・コスト最適化のため
思想 「付加価値を生まないことはクラウドに任せる」

最後に繰り返しになりますが、これは私個人の意見です。プロジェクトの特性、チームのスキルセット、予算などによって最適解は変わります。この記事が皆さんの判断材料の一つになれば嬉しいです。

参考リンク

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?