先に要点
- AWSでのHTTPS化の基本形は、ACMで無料の証明書を発行し、CloudFrontやALB(ロードバランサー)でTLSを終端すること。証明書の運用は自動更新に乗せます。
- TLSはEC2の中ではなく「入口」(CloudFront / ALB)で終端するのが定石。サーバー側の証明書管理をなくし、更新忘れの事故を防げます。
- HTTPは必ずHTTPSへリダイレクトし、古いTLS(1.0/1.1)はセキュリティポリシーで切り、HSTSヘッダで常時HTTPSを強制します。
- つまずきやすいのは、CloudFront用の証明書はバージニア北部(us-east-1)で発行が必須という点と、混在コンテンツ(mixed content)と証明書の更新忘れ。ここを押さえれば事故はほぼ防げます。
AWSで動かしているサイトをHTTPSにしたいが、証明書をどこに置けばいいのか、何をどう設定すれば「正しい」HTTPS化なのか分かりにくい ── HTTPS化はやることが複数の場所に散らばるため、つまずきやすいテーマです。
この記事では、AWSでサイトやWebアプリを 常時HTTPS(全ページHTTPS) にするためのベストプラクティスを、証明書の発行から、TLSをどこで終端するか、リダイレクト、TLSポリシー、HSTS、Route 53、そして実際に踏みやすい落とし穴まで、実務目線で順番に整理します。AWSのマネジメントコンソールは画面名が頻繁に変わるので、本記事では細かいクリック手順より 「何を・どこで・なぜ設定するか」 を主役にします。
HTTPS化の全体像 — どこで暗号化を「終端」するか
最初に全体像です。HTTPS化で一番大事な判断は、TLS(暗号化)をどこで終端するかです。終端とは「暗号化された通信をほどいて中身のHTTPに戻す場所」のことです(TLS終端)。
AWSでは、利用者にいちばん近い 入口(CloudFront や ALB)でTLSを終端し、そこから内側(オリジンのEC2やコンテナ)へ流すのが基本です。
入口で終端すると、証明書の管理を1か所(しかもマネージド)に集約でき、サーバー側で証明書を更新する手間と事故がなくなります。以下、この形を作るためのベストプラクティスを順に見ていきます。
① 証明書は ACM で無料・自動更新にする
AWSでHTTPS化するなら、証明書は AWS Certificate Manager(ACM) で発行するのが基本です。理由はシンプルで、ACMのパブリック証明書は無料で、しかも 自動更新に対応しているからです。SSL証明書の更新忘れは実際に多いトラブルですが、ACMはここを仕組みで解決します。
CloudFrontに紐づける証明書は、必ずバージニア北部(us-east-1)リージョンのACMで発行しなければ選択肢に出てきません。東京リージョン(ap-northeast-1)で作った証明書はCloudFrontから選べず、「証明書が出てこない」とハマる定番ポイントです。一方、ALBやAPI Gatewayに紐づける証明書は、そのリソースと同じリージョンで発行します。
発行時のポイントは次の通りです。
- 検証方法はDNS検証を選ぶ ── ACMが指定するCNAMEレコードをドメインに追加すると所有確認が済みます。Route 53を使っていれば1クリックでレコードを入れられます。DNS検証なら、検証レコードを消さない限りACMが自動で更新してくれます(メール検証は自動更新の扱いが弱いので避けます)。
- ワイルドカードかSANか ──
*.example.comのワイルドカード証明書にすると、サブドメインを増やしても証明書を取り直さずに済みます。複数の異なるドメインをまとめたいときは、SAN(複数ドメインを1枚に入れる)で発行します。 - 証明書はオリジンにも置ける ── 入口〜オリジン間も暗号化したい(エンドツーエンド)場合、オリジン側にも証明書を置きます。社内向けや要件が厳しい場合はここまでやりますが、まずは入口終端から始めて問題ありません。
② TLSは「入口」で終端する(EC2で抱えない)
証明書をEC2の中(NginxやApache)に置いて自前で終端することもできますが、基本は避けます。更新の自動化を自分で組む必要があり、更新忘れやリロード忘れで止まる事故の温床になるからです。
CloudFrontとALBは併用もできます。CloudFront(エッジで終端・キャッシュ・WAF)→ ALB(TLS終端・振り分け)→ EC2/ECS という多段構成は、規模が出てきたWebアプリの定番です(構成の段階はALB vs API Gateway vs CloudFrontも参考に)。
③ HTTPは必ずHTTPSへリダイレクトする
HTTPS証明書を付けても、http:// でアクセスできるままだと「常時HTTPS」になりません。80番(HTTP)へ来たアクセスは443番(HTTPS)へ恒久リダイレクトします。
- CloudFrontの場合 ── ビヘイビアの
Viewer Protocol Policyを Redirect HTTP to HTTPS に設定します。これだけでHTTPアクセスがHTTPSへ振り替わります。 - ALBの場合 ── 80番のリスナーに「443へリダイレクト(HTTPS、ステータス301)」のルールを追加します。アプリ側でリダイレクトを書く必要はありません。
入口でリダイレクトを完結させるのがポイントです。アプリのコードでリダイレクトを書くと、ヘルスチェックやリダイレクトループの調整が面倒になります。
④ 古いTLSを切る(セキュリティポリシー)
HTTPSにしても、TLS 1.0 / 1.1のような古いプロトコルを許したままでは安全とは言えません。CloudFrontもALBも セキュリティポリシー(SSL/TLSポリシー) で、受け付ける最小TLSバージョンと暗号スイートを選べます。
- 最小TLS 1.2以上を基本にします。要件が許せばTLS 1.3に対応したポリシーを選びます。
- CloudFrontでは独自ドメイン利用時に
TLSv1.2_2021系などの新しいポリシーを選びます。ALBでも新しいELBSecurityPolicy系を選びます。 - 古い端末対応で1.0を残す要件がない限り、1.2未満は切るのが現在の標準です。
⑤ HSTSで常時HTTPSを強制する
リダイレクトを入れても、利用者が最初に http:// でアクセスした一瞬は平文です。これを塞ぐのが HSTS(HTTP Strict Transport Security) です。Strict-Transport-Security レスポンスヘッダを返すと、ブラウザは以後そのドメインへ 最初から必ずHTTPSで 接続するようになります。
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload- 付与する場所 ── CloudFrontなら レスポンスヘッダーポリシーでHSTSを付けられます(アプリを触らずに設定可能)。ALB配下ならアプリやNginxで付与します。
- max-age ── 秒数。1年(31536000)が一般的。まずは短め(数時間〜1日)で様子を見て、問題なければ延ばすと安全です。
- includeSubDomains / preload は慎重に ──
includeSubDomainsは全サブドメインがHTTPS必須になります。HTTPでしか動かないサブドメインがあると到達不能になるため、棚卸ししてから付けます。preloadはブラウザ組み込みリストへの登録で、解除に時間がかかるので、全サブドメインのHTTPS化が完了してから最後に付けます。
⑥ Route 53でaliasを入口に向ける
独自ドメインを使うなら、DNSの向き先も整えます。Route 53のエイリアス(alias)レコードで、ドメインをCloudFrontディストリビューションやALBに向けます。aliasはAWSリソースを直接指せて、ゾーンApex(example.com そのもの)にも使えるのが利点です。詳しくはRoute 53とはで解説しています。
DNSを切り替える本番作業では、切り替え後の確認も忘れずに(DNS切り替え後のチェックリスト)。
⑦ 混在コンテンツ(mixed content)を残さない
HTTPS化でいちばん多い「鍵マークが付かない」原因が 混在コンテンツ(mixed content) です。ページ本体はHTTPSなのに、中で読み込む画像・CSS・JS・APIのURLが http:// のままだと、ブラウザが警告を出したり読み込みをブロックしたりします。
- ソース内の
http://example.com/...のようなハードコードをhttps://かプロトコル相対(//)、できれば相対パスに直します。 - 外部から読むスクリプトやフォントもHTTPSのURLにします。
- 自前のリダイレクトとCloudFront/ALBのリダイレクトが二重になって リダイレクトループにならないか確認します(アプリ側の「HTTPならHTTPSへ」を入口と二重に持たない)。
ブラウザの開発者ツールのコンソールに Mixed Content 警告が出ていないかを必ず確認します。
⑧ 証明書の更新を「忘れない」仕組みにする
最後に運用です。ACMのDNS検証証明書は自動更新されますが、前提として「検証用のCNAMEレコードを消さないこと」が必要です。これを消すと自動更新が止まります。
- ACMの証明書は Certificate Managerの画面で「更新状況」を確認できます。
- 何らかの事情で EC2に自前証明書を置いている場合は、ACMの自動更新は効きません。期限監視と更新の自動化を別途用意します(SSL証明書の更新忘れと自動化)。
- 証明書の中身や期限は
openssl s_client -connect example.com:443などでも確認できます(デジタル証明書とは)。
ベストプラクティス チェックリスト
この順で整えると、AWS上で「全ページHTTPS・古い暗号は切る・更新は自動」という、現在の標準的なHTTPS構成になります。さらに前段にWAFを足すならAWS WAF入門も組み合わせます。
AWSでHTTPS化するときのよくある質問
Q. AWSのHTTPS証明書は無料ですか？
A. AWS Certificate Manager(ACM)で発行するパブリック証明書は無料です。発行・更新ともに費用はかかりません。ACMの証明書はCloudFront、ALB、API Gatewayなどに紐づけて使います。無料なのは証明書自体で、CloudFrontやALBの利用料・転送量は別途かかります。
Q. 証明書はどこのリージョンで作ればいいですか？
A. CloudFrontに紐づける証明書は、必ずバージニア北部(us-east-1)で発行します。ほかのリージョンで作るとCloudFrontの設定画面で選択肢に出てきません。ALBやAPI Gatewayに紐づける場合は、そのリソースと同じリージョンで発行します。「証明書が選べない」ときはまずリージョンを疑ってください。
Q. TLSはEC2で終端してはいけないのですか？
A. 禁止ではありませんが、基本は避けます。EC2で自前終端すると証明書の発行・更新・リロードを自分で運用することになり、更新忘れで全停止する事故が起きやすいためです。CloudFrontやALBで終端すれば、ACMの無料証明書と自動更新に乗せられ、運用が大きく楽になります。特殊要件がない限り入口終端を推奨します。
Q. HTTPからHTTPSへのリダイレクトはどう設定しますか？
A. CloudFrontならビヘイビアのViewer Protocol Policyを「Redirect HTTP to HTTPS」にします。ALBなら80番リスナーに「443へ301リダイレクト」のルールを追加します。どちらも入口側で完結するので、アプリのコードにリダイレクト処理を書く必要はありません。
Q. HSTSは付けたほうがいいですか？注意点は？
A. 常時HTTPSを徹底するなら付けたほうが安全です。ただしincludeSubDomainsを付けると全サブドメインがHTTPS必須になり、HTTPでしか動かないサブドメインがあると到達できなくなります。preloadは解除に時間がかかるため、すべてのサブドメインのHTTPS化が完了してから最後に付けます。max-ageは短めから始めて、問題がなければ延ばすのが安全です。
Q. HTTPS化したのに鍵マークが付かないのはなぜですか？
A. 多くは混在コンテンツ(mixed content)が原因です。ページはHTTPSでも、中で読み込む画像・CSS・JS・APIのURLがhttp://のままだと、ブラウザが安全でないと判断します。開発者ツールのコンソールに出るMixed Content警告を手がかりに、該当URLをhttps://か相対パスに直します。
Q. ACMの証明書は本当に放っておいても更新されますか？
A. DNS検証で発行した証明書は、検証用のCNAMEレコードをドメインに残しておけば自動更新されます。逆に、この検証レコードを削除すると自動更新が止まります。メール検証の場合は自動更新の扱いが弱いため、DNS検証を選ぶのが安全です。EC2に置いた自前証明書はACMの自動更新の対象外なので、別途期限監視が必要です。