EC2 に SSL 証明書を入れる前に考えたい、ALB + ACM という正攻法
AWS の問題で「EC2 上の Web アプリを HTTPS 化したい」という要件が出ると、つい EC2 に証明書を入れればいい と考えがちです。
もちろん実務ではそれが絶対に不可能というわけではありません。ですが、試験文脈や AWS の王道設計 を考えると、まず疑うべきなのは Application Load Balancer（ALB）+ AWS Certificate Manager（ACM） です。
この記事では、EC2 に直接証明書を置くよりも ALB + ACM が優先されやすい理由を整理します。試験対策だけでなく、実務で HTTPS 終端をどこに置くべきか迷ったときにも使える切り分けです。
まず結論
先に結論を書くと、次のように考えるとかなり整理しやすいです。
- HTTPS 化したい
- 証明書管理を楽にしたい
- 複数 EC2 に同じ証明書を配りたくない
- 高可用性も考えたい
この条件が並んだら、まず ALB に ACM 証明書をアタッチして TLS を終端する構成 を疑うべきです。
つまり、
- EC2 に個別に証明書を置く のではなく
- ALB で HTTPS を受け、EC2 は背後で処理する
という形です。
なぜ EC2 直置きが試験で怪しく見えるのか
EC2 に直接証明書を入れる方法は、できなくはありません。ですが AWS の設計としては、運用が重くなりやすいです。
たとえば、
- 証明書更新を各インスタンスで管理する必要がある
- 台数が増えると配布作業が面倒になる
- Auto Scaling 環境では証明書配布や更新がさらに厄介になる
- TLS 終端の設計とアプリ配置が密結合しやすい
といった問題が出ます。
試験ではこの「できるかどうか」よりも、より AWS らしく、運用負荷が低く、拡張しやすい構成か が問われることが多いです。
ACM と ALB の役割
AWS Certificate Manager（ACM）
ACM は、SSL/TLS 証明書を発行・管理するためのサービスです。
AWS の対象サービスと組み合わせると、証明書の管理をかなり楽にできます。少なくとも、EC2 一台一台に証明書を配って回る発想から離れやすくなります。
Application Load Balancer（ALB）
ALB は、HTTP/HTTPS レベルでリクエストを受け、背後の EC2 へ振り分けるロードバランサーです。
ALB に ACM 証明書を設定すれば、ALB 側で HTTPS を受けて TLS を終端できます。
たとえば、
- インターネットからの HTTPS リクエストは ALB で受ける
- ALB が証明書を持つ
- 背後の EC2 はアプリ処理に集中する
という形にできます。
ALB + ACM が刺さる要件
この構成が強いのは、次のような条件が並ぶときです。
- Web アプリを HTTPS 化したい
- 証明書管理を単純化したい
- EC2 を複数台で運用したい
- Auto Scaling と相性のよい構成にしたい
- 運用負荷をなるべく減らしたい
特に 複数 EC2 に同じ証明書を配るのが面倒 という時点で、ALB + ACM の優位性はかなり大きくなります。
例えばどう考えるか
- EC2 1 台ずつに設定を抱え込む → 後でつらい
- ALB でまとめて受ける → 管理がだいぶ楽
この差は、試験でも実務でも効きます。
EC2 直置きが不利になりやすい理由
EC2 に証明書を直接置くと、構成全体の責任範囲が広がります。
たとえば、
- Nginx や Apache の証明書設定
- 更新タイミングの調整
- 台数増加時の配布
- 失効や入れ替え時の反映
を自分で考える必要があります。
もちろん、特殊要件で EC2 側終端が必要なことはあります。ですが、問題文にそこまで強い制約が書かれていないなら、わざわざ重い方を選ぶ理由は薄いです。
比較表で整理する
| 観点 | EC2 に直接証明書を置く | ALB + ACM |
|---|---|---|
| 証明書管理 | 各 EC2 で必要 | ALB 側に集約しやすい |
| 台数増加への強さ | 弱くなりやすい | 比較的強い |
| Auto Scaling との相性 | 面倒が増える | 良い |
| HTTPS 終端 | EC2 側 | ALB 側 |
| AWS 試験での王道感 | 低め | 高め |
この表で見ると、AWS がどちらを好みそうかはかなり分かりやすいです。
試験での見分け方
AWS 認定試験では、次のようなキーワードが並んだら ALB + ACM を先に疑うべきです。
- HTTPS 化したい
- 証明書管理を簡単にしたい
- 高可用性が必要
- 運用負荷を下げたい
- 複数インスタンスに配布したくない
逆に、問題文で「EC2 上の特定ソフトウェアがサーバー自身で TLS 終端しなければならない」などの制約が強く書かれているなら別です。
ですが、そうでないなら王道はかなり明確です。
実務ではどう考えるか
実務でも、外部公開する Web アプリなら、まずは次のような構成を検討することが多いです。
Internet
↓
ALB + ACM
↓
EC2
この形なら、
- 証明書管理を ALB 側に寄せられる
- EC2 の入れ替えがしやすい
- Auto Scaling と組み合わせやすい
- 運用の責任分界が整理しやすい
というメリットがあります。
まとめ
EC2 に証明書を直接置く方法は存在しますが、AWS で HTTPS 化の正攻法を問われたときに、まず考えるべきは ALB + ACM です。
- ACM で証明書を管理する
- ALB で HTTPS を受ける
- EC2 はアプリ処理に集中する
この切り分けを押さえておくと、試験でも実務でも構成判断がかなり安定します。