こんにちは！SREとして日々クラウドの荒波を航海している私です。
Webアプリケーションを作って「さあ世界中に公開しよう！」となったとき、絶対に避けて通れないのがSSL/TLS（暗号化通信）の壁ですよね。URLが http:// から https:// に変わり、ブラウザに鍵マークが表示される、あれです。
インフラの世界に足を踏み入れたばかりの頃、この「暗号化とロードバランサー（ALB）の関係」で頭を悩ませた方は多いのではないでしょうか。「証明書ってどこに置くの？」「バックエンドのサーバーまでずっと暗号化しなきゃいけないの？」といった疑問です。
今回は、AWSの顔とも言える ALB（Application Load Balancer） と、無料の証明書管理サービス ACM（AWS Certificate Manager） をタッグを組ませて、この通信の仕組みをスッキリと解き明かしていきたいと思います。
難しいパケットの動きはちょっと横に置いて、まずは身近な例えから一歩ずつ理解していきましょう！
—
1. 郵便配達で例える「SSL/TLSターミネーション」
いきなり難しそうな「ターミネーション（Termination）」という言葉が出てきましたが、怖がらなくて大丈夫です。これ、日本語に訳すと「終端（おしまい）」という意味なんですね。
インターネットの世界で、ユーザー（クライアント）と私たちのWebサーバーがやり取りする通信は、そのままにしておくと中身が丸見えになってしまいます。そこで、通信をカプセルのように暗号化（SSL/TLS化）するわけですが、これをバックエンドのサーバー1台1台にやらせようとすると、サーバーのCPUが暗号化の計算でクタクタになってしまいます。
ここで登場するのが ALBによるSSL/TLSターミネーション です。
これを「厳重なセキュリティチェックを通す巨大なホテルのフロント」に例えてみましょう。
- ユーザーからの通信（HTTPS）:
外の世界から届いた手紙は、厳重に鍵のかかった封筒（暗号化）に入っています。これを直接ホテルの奥の部屋（バックエンドサーバー）まで持って行くと、開けるのが大変ですよね。
- ALBの役割（ターミネーション）:
ホテルの玄関口である ALB が、その「鍵のかかった封筒」を受け取り、フロントで一度開封（SSL/TLSの終端）します。
- バックエンドへの通信（HTTP）:
「中身は安全な手紙ですね」と確認したら、ホテルの中（プライベートなネットワーク）専用の安全なトレイに乗せて、奥の部屋（Webサーバー）へ平文（HTTP）で届けます。
このように、「外からの鍵付き通信をロードバランサーのところで安全にほどいて、中はスイスイ効率よく通信させる」 のがSSL/TLSターミネーションの正体です。サーバーの負担が劇的に軽くなる、非常に理にかなった仕組みなんですね。
—
2. めんどい証明書管理を全自動化する「ACM」の魔法
さて、このSSL/TLS通信を行うためには、サーバーの身元を証明する 「SSL/TLS証明書」 が絶対に必要です。
昔はこの証明書を手に入れるために、民間の認証局（CA）にお金を払い、有効期限が切れるたびに手動で更新し、サーバーのファイルにガチガチと設定するという、インフラエンジニア泣かせの作業が必要でした。下手をすると「証明書の有効期限切れでサイトが繋がらなくなった！」という大事故（ヒヤリハットどころの騒ぎではないですが…）の定番でした。
そこでAWSが提供しているのが ACM（AWS Certificate Manager） です。
ACMは、いわば「デジタル証明書の自動発行・更新マシーン」です。
これの何が素晴らしいかというと、以下の3点に集約されます。
1. 証明書の発行が無料（※パブリック証明書の場合）
お金がかからないので、検証環境でも本番環境でも気兼ねなく使えます。
2. 更新作業が完全に自動
「有効期限の30日前になったらどうしよう…」と怯える必要はありません。AWSが勝手に裏で更新してくれます。
3. ALBとの相性が抜群
ALBの設定画面で、ACMで作った証明書をポチッと選択するだけで、面倒な紐付けが完了します。
—
3. 実践！ALB ＋ ACM でHTTPSを受け付ける設定
理屈が分かったところで、実際にAWS上でどのように設定するのか、雰囲気を掴んでおきましょう。実務ではTerraformやAWS CDKを使うことが多いですが、ここでは全体像が一番わかりやすいAWS CLIやコンソールでの構成イメージをコードや設定例を交えて解説しますね。
ステップ1：ACMで証明書を取得する
まずは「このドメイン（例: example.com）の証明書が欲しいです」とACMにお願いします。DNS（Route 53など）を使っていれば、所有権の確認もボタン一つ（または自動）で終わります。
ステップ2：ALBのリスナーを設定する
ALBに対して、「ポート 443（HTTPS）で通信を受け付けたら、ACMの証明書を使って復号し、バックエンドのターゲットグループ（ポート 80 のHTTP）へ流してね」という設定を行います。
以下は、AWS CLIでALBのリスナー（通信の待ち受け口）を作成する際のイメージコードです。
# ALBに対してHTTPSリスナー（ポート443）を追加するコマンド例
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-alb/abcdef123456 \
--protocol HTTPS \
--port 443 \
--certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/your-cert-uuid \
--ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-target-group/abcdef123456ここで指定している --ssl-policy というパラメーターは、「どのくらい強力で安全な暗号化アルゴリズムを許可するか」 を決めるルールブックです。最近の標準である ELBSecurityPolicy-TLS13-1-2-2021-06 を選んでおけば、古くて危うい暗号化方式をバッチリ弾いてくれるので安心です。
—
4. 「再暗号化（HTTPS to HTTPS）」を選ぶべきケースとは？
ここまで「ALBで終端してバックエンドはHTTP（平文）」という構成を基本としてお話ししてきましたが、実務ではもう一つのパターン、「再暗号化（End-to-End Encryption）」 を求められる現場もあります。
これはどういうことかというと、
- ユーザー ➔ ALB間：HTTPS（暗号化）
- ALB ➔ バックエンドサーバー間：さらにHTTPS（暗号化）
とする方式です。
どんなときに「再暗号化」が必要なの？
- レギュレーション（社内規定・業界基準）の壁:
「金融や医療系など、クラウドの内部ネットワーク（VPC内）を流れるデータであっても、平文で流すことは一切禁止する（ゼロトラスト原則）」という非常に厳しいセキュリティ要件がある場合。
- 踏み台やプロキシを経由する複雑な構成:
ALBから後ろのサーバー群が、パブリックなインターネットに近い信頼性の低いゾーンを通る場合。
ただ、これを行うにはバックエンドのサーバー側にもSSL/TLS証明書（自己署名証明書や社内CAの証明書など）を配置して設定する必要があるため、構築・運用の手数が少し増えます。「まずは基本のHTTPバックエンドから始めて、必要に応じて再暗号化を検討する」というのが、初学者のステップアップとしても無理のない流れかなと思います。
—
まとめ
今回は、ALBにおけるSSL/TLSターミネーションとACM連携の仕組みについて、郵便配達の例えを交えながらお伝えしました。
- ALBのSSLターミネーションは、ホテルのフロントで鍵付きの荷物を安全に受け取り、中身を効率よくさばく賢い仕組み。
- ACMは、面倒な証明書の管理や更新をすべて裏側で自動化してくれる頼もしい相棒。
- バックエンドへの通信は基本はHTTP（平文）で十分効率的だが、セキュリティ要件に応じて「再暗号化」も選択肢に入る。
インフラの世界は、一見すると専門用語が多くて難しく感じられますが、一つひとつの部品が「現実世界のどんな役割を果たしているのか」を紐解いていくと、とてもシンプルで美しい設計になっていることが分かります。
皆さんのクラウドアーキテクチャの旅が、安全で快適なものになりますように！それではまた次回の技術解説でお会いしましょう。
コメント