「検証用の EC2 を停止しておいたのに、翌月も請求が来ました。止めれば課金は止まるのではないのですか」
「Auto Scaling で台数が増えると、増えたインスタンスだけ ELB のヘルスチェックに失敗し、終了と起動を繰り返します。最初の1台は手作業で設定して、問題なく動いているのですが」
第3回では、EC2 の基盤とインスタンスタイプ、AMI と起動テンプレート、ストレージ、ログインの方法、IMDS を見ました。1台の EC2 を正しく作れるようになったら、次はお金と台数の話です。EC2 は止め方と買い方で請求が大きく変わり、台数は Auto Scaling と ELB で自動にできます。さらに、EC2 を使わずにコンテナや関数でアプリを動かす方法もあります。
後編の第4回では、ライフサイクルと課金、購入オプション、Auto Scaling と ELB、コンテナ、Lambda、使い分けと Azure との対応を扱います。
ライフサイクルと課金の関係
インスタンスの状態ごとに、何に課金が続くかが違います。
| 状態 | EC2 の課金 | EBS の課金 | パブリック IP | 備考 |
|---|---|---|---|---|
| 実行中（running） | あり（秒単位、最低 60 秒） | あり | あり（自動割り当ては停止で変わる） | ― |
| 停止（stopped） | なし | あり | 自動割り当ての IP は解放。EIP は保持（課金あり） | 再び起動すると別のホストへ移る。インスタンスストアは消える |
| 休止（hibernate） | なし | あり（RAM の内容を書き出す） | 同上 | メモリの内容を保ったまま再開 |
| 終了（terminated） | なし | ルートの EBS は既定で削除、追加の EBS は残る | 解放 | 元に戻せない。終了保護を設定できる |
| 再起動（reboot） | 継続 | 継続 | 保持 | 同じホストで OS を再起動 |
冒頭の1つ目の相談がこれです。「停止したのに請求が来る」原因は、EBS・EIP・スナップショット・ELB・NAT ゲートウェイです。停止しても EBS の課金は続きます。検証が終わったら終了まで行うか、要らなくなった付属のリソースを削除します。
購入オプション
同じインスタンスでも、買い方で料金が大きく変わります。割引率は2026年9月時点の AWS の公表値（最大）です。
| オプション | 割引率（目安） | 契約 | 中断 | 向く用途 |
|---|---|---|---|---|
| オンデマンド | 0% | なし | なし | 検証、短期、負荷が読めないもの |
| リザーブドインスタンス（RI） | 最大 72% | 1 年／3 年、全額前払い〜前払いなし | なし | タイプ・リージョンを固定できる定常の負荷 |
| Savings Plans（Compute／EC2 Instance） | 最大 66%／72% | 1 年／3 年、時間あたりの金額をコミット | なし | タイプを変えたい、Lambda・Fargate も含めたい |
| スポットインスタンス | 最大 90% | なし | あり（2 分前の通知で回収） | バッチ、CI、ステートレスな処理。DB には使わない |
| Dedicated Hosts／Instances | 割増 | ― | なし | ソケット単位のライセンス（Windows の BYOL、Oracle）、規制への対応 |
| キャパシティ予約 | 割引なし | ― | なし | 特定の AZ で確実に起動の枠を確保したい（DR 用） |
実務では「定常分を Savings Plans、変動分をオンデマンド、バッチをスポット」の組み合わせが基本です。RI・Savings Plans の割引は、アカウント単位でなく Organizations 全体で共有できます。
Auto Scaling
EC2 Auto Scaling は、起動テンプレートを元にインスタンスの台数を自動で増減させる仕組みです。「Auto Scaling グループ（ASG）」に、最小・最大・希望の台数と、配置するサブネット（複数の AZ を指定するのが基本）を設定します。
増減の判断は「スケーリングポリシー」で行います。CPU 使用率 50% を目標に台数を調整する「ターゲット追跡」、CloudWatch のアラームの段階に応じて台数を決める「ステップ」、時刻で台数を変える「スケジュール」、過去の傾向から先回りする「予測」があります。
ASG は台数の調整だけでなく、ヘルスチェックに失敗したインスタンスを終了して作り直す「自己修復」も行うため、最小＝最大＝1 で設定して「落ちたら自動で立て直す」用途にも使われます。ELB（次の節）と組み合わせると、新しいインスタンスが起動したら自動でターゲットに登録し、終了するときは接続を排出（draining）してから外します。前提として、インスタンスは起動テンプレート（前編の「起動テンプレートとユーザーデータ（cloud-init）」の節）から完全に自動で構築できなければならず、手作業で設定したサーバーはスケールできません。
- ASG：最小／最大／希望の台数、複数の AZ に配置
- ポリシー：ターゲット追跡・ステップ・スケジュール・予測
- 自己修復（落ちたら作り直す）にも使える。手作業で構築したサーバーは対象外
冒頭の2つ目の相談がこれです。最初の1台に手作業で入れたアプリや設定は、起動テンプレートの AMI にもユーザーデータにも入っていないため、ASG が増やしたインスタンスは「OS だけの状態」で起動します。アプリが応答しないので ELB のヘルスチェックに失敗し、ASG のヘルスチェックに ELB を使う設定なら、終了と作り直しを繰り返します。設定を済ませた状態からカスタム AMI を作るか、導入の手順をユーザーデータに書いて起動テンプレートの新しいバージョンにし、ASG にそのバージョンを使わせます。
ELB（Elastic Load Balancing）
AWS のロードバランサーは4種類です。
| 種類 | レイヤー | 主な機能 | 用途 |
|---|---|---|---|
| ALB（Application） | L7（HTTP／HTTPS／gRPC） | パス・ホスト・ヘッダーによる振り分け、TLS 終端、WAF との連携、認証（Cognito/OIDC）、固定 IP なし | Web アプリ、マイクロサービス |
| NLB（Network） | L4（TCP/UDP/TLS） | 超低遅延、固定 IP（EIP）、送信元 IP の保持、数百万 rps | DB 以外の TCP のサービス、ゲーム、PrivateLink の裏側 |
| GWLB（Gateway） | L3（GENEVE） | サードパーティーのファイアウォール・IDS のアプライアンスへ透過的に転送 | Palo Alto などの仮想アプライアンス群 |
| CLB（Classic） | L4/L7 | 旧世代 | 新規では使わない |
ELB 自体はマルチ AZ の冗長構成で、AWS が管理します。ELB の IP アドレスは変わるので、DNS 名（xxx.elb.amazonaws.com）を使うか、Route 53 のエイリアス（第7回）で参照します。ALB が送信元の IP を後ろのサーバーへ伝える手段は、オンプレのリバースプロキシーと同じ X-Forwarded-For です（連載「HTTP入門」第10回「X-Forwarded-For・X-Forwarded-Proto・Forwarded」で扱います）。L7 の振り分けとヘルスチェックの考え方は、同じ連載の第9回で扱います。
コンテナ：ECS・EKS・Fargate・ECR
コンテナのサービスは、イメージの置き場・オーケストレーター・実行基盤の組み合わせで考えます。
- ECR（Elastic Container Registry）：コンテナイメージを置くレジストリ（Docker Hub の自社版）。イメージスキャンの機能あり
- ECS（Elastic Container Service）：AWS 独自のオーケストレーター。タスク定義（イメージ・CPU・メモリ・環境変数）とサービス（維持する数、ELB との連携）で構成。学習のコストが低く、AWS のサービスとの統合が密
- EKS（Elastic Kubernetes Service）：マネージドの Kubernetes。コントロールプレーンを AWS が運用し、利用者はワーカーノードとマニフェストを管理する。OSS の Kubernetes の知識がそのまま使え、ほかのクラウドやオンプレとの可搬性が高い
- Fargate：ECS・EKS の実行基盤を、EC2 でなくサーバーレスにする選択肢。ホスト OS の管理（パッチ・スケール）が要らなくなる代わりに、単価は EC2 より高く、GPU や特権コンテナに制限がある
- App Runner：コンテナイメージやソースから Web サービスを直接デプロイするサービス。2026年4月30日で新しい顧客の受け付けを終えた（既存の利用者は継続できる）。これから使うなら ECS の Express Mode が案内されている
- 選び方：「Kubernetes を運用する人がいるか」で ECS／EKS を、「ホスト OS を触りたいか」で EC2／Fargate を決める
サーバーレス：AWS Lambda
Lambda は、サーバーを意識せずにコードを実行するサービスです。S3 へのアップロード、API Gateway へのリクエスト、EventBridge のスケジュール、SQS のメッセージなどをきっかけ（トリガー）に関数が起動し、処理が終われば消えます。課金は「リクエスト数＋実行時間（ミリ秒）× 割り当てたメモリ」で、待機中は無料です。対応する言語は Python、Node.js、Java、.NET、Ruby（Go・Rust などは OS 専用のランタイムで動かす）で、加えてコンテナイメージ（最大 10 GB）も実行できます。
制約として（2026年9月時点）、1 回の実行は最長 15 分、メモリは 128 MB〜10,240 MB（CPU はメモリに比例）、一時領域の /tmp は最大 10 GB、同時実行数はリージョンあたり既定で 1,000（引き上げ可）です。初回の起動時に実行環境を用意する「コールドスタート」で数百 ms〜数秒の遅延が出るため、遅延に厳しい API では Provisioned Concurrency で温めておきます。VPC の中のリソース（RDS など）に接続する場合は、関数を VPC にアタッチします。運用面では「ログは CloudWatch Logs に自動で出力」「権限は実行ロール（IAM ロール）で付与」がセットです。
- イベント駆動で起動、実行時間×メモリで課金、待機は無料
- 制約：最長 15 分、メモリ 10 GB、コールドスタート
- 権限は実行ロール、ログは CloudWatch Logs に自動で出力
EC2・コンテナ・Lambda の使い分け
3つの実行の方法を、観点ごとに比べます。
| 観点 | EC2 | ECS/EKS（Fargate） | Lambda |
|---|---|---|---|
| 管理する範囲 | OS から上すべて | コンテナイメージと定義 | コードのみ |
| 常時稼働のコスト | 台数×時間 | タスク数×時間 | ゼロ（実行時のみ） |
| 実行時間 | 無制限 | 無制限 | 最長 15 分 |
| スケール | ASG（分単位） | サービスのスケール（秒〜分） | 自動（ミリ秒〜秒） |
| 既存の資産の移行 | そのまま（Rehost） | コンテナ化が必要 | 関数の単位に分割が必要 |
| 向く処理 | 既存の AP、ライセンスの縛り、常に高負荷 | Web/API、マイクロサービス | イベント処理、バッチ、API のバックエンド |
1つのシステムの中でも、Web は ECS、夜間の集計は Lambda、レガシーな AP は EC2 のように混在させるのが普通です。「サーバーレスが最新だから全部 Lambda」は誤りです。
Azure との対応（コンピューティング）
第3回とこの回のサービスを、Azure の名前と対応させます（2026年9月時点）。
| AWS | Azure | 補足 |
|---|---|---|
| EC2 | Virtual Machines | サイズの表記は Standard_D2s_v5（D＝汎用、2＝vCPU、s＝Premium SSD 対応、v5＝世代） |
| Nitro／Graviton | （Azure Boost）／Cobalt 100（ARM） | Azure も ARM の自社の CPU を持つ |
| AMI | VM イメージ（Marketplace／Compute Gallery） | ― |
| ユーザーデータ | カスタムデータ／cloud-init（Linux）、カスタムスクリプト拡張 | ― |
| Auto Scaling グループ | 仮想マシンスケールセット（VMSS） | ― |
| ALB／NLB／GWLB | Application Gateway／Load Balancer／（Gateway LB） | Front Door はグローバルの L7（第7回） |
| ECS／EKS／Fargate | Container Apps／AKS／（AKS の Virtual Nodes、Container Instances） | ― |
| ECR | Azure Container Registry | ― |
| Lambda | Azure Functions | 従量課金プラン（Consumption）のタイムアウトは既定 5 分・最長 10 分（Flex Consumption・Premium は既定30分・上限なし） |
| Session Manager／Instance Connect | Azure Bastion | Bastion は PaaS の踏み台（時間課金） |
| スポットインスタンス | Spot VM | ― |
| RI／Savings Plans | Reserved VM Instances／Azure Savings Plan | ― |
考えてみよう
- 手元の AWS アカウント（または検証用の環境）で、停止中のインスタンスに付いている EBS、関連付けていない EIP、古いスナップショットがないか探してください。冒頭の1つ目の相談のように、止めても課金が続くものはどれですか。
- 平日の日中は 8 台、夜間と休日は 2 台で足りる Web サーバーがあります。購入オプションと Auto Scaling のスケーリングポリシーを、どう組み合わせますか。
- 夜間に 30 分かかるバッチを Lambda で動かせますか。動かせないなら、どのサービスを選びますか。
ヒント：1 は「ライフサイクルと課金の関係」、2 は「購入オプション」と「Auto Scaling」、3 は「サーバーレス：AWS Lambda」と「EC2・コンテナ・Lambda の使い分け」の節を見直してください。
まとめ
- 停止しても EBS・EIP などの課金は続く。検証の後は終了まで行う
- 定常は Savings Plans、変動はオンデマンド、バッチはスポット。スポットは 2 分前の通知で回収される
- Auto Scaling は台数の調整と自己修復を自動にする。前提は、起動テンプレートだけで完全に自動で構築できること
- ELB は L7 の ALB、L4 の NLB、アプライアンス向けの GWLB。IP は変わるので DNS 名かエイリアスで参照する
- コンテナは「Kubernetes を運用する人がいるか」で ECS／EKS を、「ホスト OS を触りたいか」で EC2／Fargate を選ぶ
- Lambda はイベント駆動・待機は無料・最長 15 分
- EC2・コンテナ・Lambda は混在させて使い分ける
次回は、S3・EBS・EFS・FSx・AWS Backup など、ストレージのサービスを扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）（この記事）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント