AWSでのTLS対応

Blog

TLS対応の方法や何を検討すべきか整理します。明日の業務のために...🕊️

TLS対応（HTTPS化）をAWSで行う場合、主に次の2つの観点を考える必要があります。

  1. 証明書（ドメイン）の管理方法
  2. どのサービスでTLS配信を行うか

1. ドメインの取得と証明書の管理

ドメインの利用パターン

TLS証明書を発行するには、まず対象となるドメインを用意する必要があります。
ここでは新規に取得する場合と既存ドメインを使用する場合の違いを整理します。

1. 新規でドメインを取得する場合

  • Route 53からドメインを購入する方法
  • DNS設定（ホストゾーン）も自動的に作成される
  • ACMで証明書をリクエストすると、DNS検証のレコードも自動登録される

2. 既存ドメインを利用する場合

  • 他社レジストラ（例：お名前.com）で取得したドメインを利用する方法
  • DNS検証用のCNAMEレコードを手動で追加すれば認証が完了し、ACMで利用可能

3. サブドメインを利用する場合

  • 既存のドメインの配下にサブドメイン（例：app.example.com）を作成する方法
  • 親ドメインのDNSを管理している場所（Route 53でも他社でも）で、サブドメイン用のレコードまたは委任設定（NSレコード）を追加する

ACM

AWSでのTLS証明書管理は、基本的に ACM（AWS Certificate Manager） を利用します。
無料で証明書を発行でき、自動更新もされるため、運用コストが非常に低いです。

特徴

  • ACMで証明書を発行する際に「ドメインの所有者確認」が必要。
  • 通常はDNS 検証を用い、Route 53を使っている場合は自動でレコード登録も可能。
  • 他社ドメインでも、DNSレコードを手動で設定すれば利用可能。

リージョンとの関係と注意点

ACMは、証明書を特定のリージョン単位で管理しています。
そのため東京で作った証明書は東京のサービスでしか使えない、ということになります。

また、以下のようにサービスによって「証明書をどこのリージョンから参照できるか」が決まっています。

  • CloudFront用の証明書：us-east-1 (バージニア北部) に発行
  • ALB/NLB/EC2用の証明書：利用リージョンに発行

つまり、東京リージョンで証明書を作成した場合、CloudFrontでは選択できません。
CloudFrontとALB を両方使用するような場合は、us-east-1とALBが存在しているリージョンにそれぞれ証明書を発行する必要があります。

2. TLS終端（配信の場所 / どこで暗号を解除するか）

AWSでは「どのサービスでTLS/HTTPSを終端させるか（＝暗号化を解除し次フェーズに送るか）」によって構成が異なります。
代表的な選択肢は以下の通りです。

サービス 主な用途 特徴
CloudFront CDN配信（静的/動的両方） 高速・グローバルキャッシュ・WAFと併用可
Application Load Balancer (ALB) Webアプリ負荷分散 HTTP⇔HTTPS リダイレクト可、ターゲットにEC2/ECS
Network Load Balancer (NLB) TCPレベルの負荷分散 高スループット・低レイテンシ、TLSパススルーも可
API Gateway API公開 認証・認可、WAF連携が容易
Elastic Beanstalk / EC2 単体構成 自ら証明書を管理・インストールするため運用負荷や更新作業あり

これを基に、どのように選定すべきか複数パターンで見てみます。

パターンA：静的サイト・SPA（例：Next.js/React/Vue）

推奨構成：

  • CloudFront（CDN）＋ S3（静的ホスティング）
  • ACM（us-east-1）で証明書を発行 → CloudFrontに適用
  • Route 53で独自ドメインをCloudFrontに向ける

理由：

  • 静的コンテンツなのでキャッシュが効きやすく、世界中から高速配信できる。
  • CloudFrontによるキャッシュ化でオリジン負荷を軽減でき、コストも抑えやすい。
  • 証明書・運用の手間が少ない（静的なのでアプリケーション構成がシンプル）。
  • メンテナンス（証明書更新、サーバ設定）をほぼ意識せずに済む。

パターンB：Webアプリ（バックエンドあり/EC2・ECS 等）

推奨構成：

  • CloudFront（HTTPS終端） → ALB（HTTPS or HTTP） → ECS/EC2
  • ACMで必要な証明書を発行（CloudFront用＝us-east-1、ALB用＝対象リージョン）

理由：

  • フロントにCloudFrontを置くことでキャッシュ・グローバル配信・WAF連携が可能。
  • ALBを置くことでWebアプリの負荷分散や複数インスタンス管理、Auto Scaling等と連携しやすい。
  • オリジン（ALB～EC2）との通信もHTTPSで行えばエンドツーエンドの暗号化ができ、セキュリティ向上。
  • アプリ構成の拡張性・可用性を確保しつつ、静的配信の枠を超えた負荷や動的処理にも対応できる。

パターンC：API サーバー（REST/GraphQL等）

推奨構成：

  • API Gateway（HTTPS終端） → LambdaまたはALB/ECS
  • ACMを用いてカスタムドメインに証明書を適用

理由：

  • API公開という性質上、認証・認可・リクエスト制御（スロットリング）等が求められ、API Gatewayがこれらを持つため効率的。
  • TLS終端をAPI Gatewayに任せることで、バックエンド（Lambda/ALB）をシンプルに保てる。
  • カスタムドメイン・証明書を使って HTTPS にすることでクライアントとの通信の安全性を担保。

パターンD：リアルタイム通信・ゲームサーバーなど（TCP/UDP 通信）

推奨構成：

  • NLB（TLS終端 or パススルー） → EC2（ゲームサーバー等）
  • ACM証明書（対象リージョン）をNLBに設定

理由：

  • ゲームやリアルタイムアプリではHTTP/HTTPSに限らずTCP/UDPが使われる場合があるため、NLBを選ぶことでプロトコルを選ばず低遅延・高スループットに対応可能。
  • TLS終端をNLBに任せるか、パススルーさせるかを使い分けることで、暗号化の手前で負荷を分散しつつバックエンドはシンプルにできる。
  • 秒間多数接続・低遅延が求められる環境に適している。

この選定方法は本当に正しいのか有識者に聞いてみたいところ。

ちなみにSSLはすでに廃止され現在は後継であるTLSが使われていますが、SSLという呼び方は今も定着しているようです。