HTTPS化の手順は、証明書の発行・DNS検証・ロードバランサーへのアタッチという複数ステップに分かれており、各サービスの役割を理解していないと途中で迷子になります。
この記事では、AWS Certificate Manager(ACM)とRoute 53を使った無料SSL証明書の発行から、ALBへのHTTPS(443)リスナー設定・自動更新の仕組みまで、実務で使える手順を解説します。EC2インスタンスへの直接証明書インストールではなく、ALBを介したマネージドHTTPS構成を前提としています。
この記事のポイント
・ACMはAWSが提供する無料SSL証明書マネージドサービスで、ALB・CloudFrontに適用できる
・Route 53のDNS検証でCNAMEレコードを追加すれば証明書の発行は最短数分で完了する
・ALBのHTTPS(443)リスナーにACM証明書をアタッチするだけでHTTPS化が完成する
・ACM証明書の有効期限は13ヶ月で、Route 53使用時は自動更新が有効になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ACMとは?AWS無料SSL証明書マネージドサービスの概要
AWS Certificate Manager(ACM)は、AWSが提供するSSL/TLS証明書の発行・管理サービスです。最大の特徴は、AWSリソース(ALB・CloudFront・API Gateway等)で使う限り証明書が無料であることです。従来のSSL証明書は年間数万円以上かかることが多く、更新作業も手動で行う必要がありました。ACMはこの運用コストを大幅に削減します。
ACMの主な特徴は以下のとおりです。
・無料発行:ALB・CloudFront・API Gatewayでの使用に限り、証明書の発行・更新費用は無料
・自動更新:Route 53でDNS検証を行った場合、有効期限前に自動で証明書が更新される
・マルチドメイン対応:1枚の証明書でワイルドカード(*.example.com)や複数ドメインをカバーできる
・リージョン制約:ALBで使用する場合は同じリージョンのACM証明書が必要(CloudFrontはus-east-1のみ)
なお、EC2インスタンスに直接ACM証明書をインストールすることはできません。ALBやNLB等のロードバランサーを介して使用する設計が前提です。
AWSのLinux環境構築の基礎から体系的に学びたい場合は、AWS(Amazon Linux)入門ガイドも合わせて参照してください。
ACM証明書の発行手順(Route 53でDNS検証)
ACMで証明書を発行する際、ドメインの所有権を証明するために「DNS検証」または「メール検証」を選びます。Route 53でドメインを管理している場合は、DNS検証が圧倒的におすすめです。理由は、ACMがCNAMEレコードを自動でRoute 53に追加できるため、手作業が不要になるからです。1. ACMコンソールで証明書をリクエストする
AWSマネジメントコンソールでACMを開き、「証明書のリクエスト」をクリックします。証明書タイプは「パブリック証明書のリクエスト」を選択します。ドメイン名の欄には取得したいドメイン(例:example.com)を入力します。サブドメインも含める場合は「別の名前を追加」で複数指定できます。ワイルドカード(*.example.com)を追加すると、全サブドメインをカバーできます。
2. DNS検証方式を選択してCNAMEを追加する
検証方法で「DNS検証」を選択します。Route 53でドメインを管理している場合、次の画面で「Route 53でレコードを作成」ボタンが表示されます。このボタンをクリックすると、ACMが自動的にRoute 53のホストゾーンにCNAMEレコードを追加します。手動でCNAMEを追加する場合は、ACMコンソールに表示される「名前」「値」を自分のDNS管理画面に入力してください。DNSの仕組みについては、Linux DNS設定の基本も参考になります。
3. DNS伝播を確認して証明書の発行を待つ
CNAMEレコード追加後、通常は数分でACMが検証を完了して証明書ステータスが「発行済み」に変わります。DNS伝播の確認にはdigコマンドが使えます。# acm検証用CNAMEが正しく追加されているか確認する # _xxxxxxxx.example.com はACMコンソールに表示された検証用ドメイン名に置き換える dig CNAME _xxxxxxxx.example.com # 出力例(CNAMEが正しく設定されている場合) ;; ANSWER SECTION: _xxxxxxxx.example.com. 300 IN CNAME _yyyyyyyy.acm-validations.aws.
ALBへのHTTPS(443)リスナー設定
ACM証明書が「発行済み」になったら、ALBにHTTPS(443)リスナーを追加します。ALBがHTTPS終端(SSL Termination)を担うため、バックエンドのEC2インスタンスは証明書を管理する必要がなく、運用が大幅にシンプルになります。AWS CLIで証明書のステータスを確認したい場合は以下のコマンドを使います。
# aws acm コマンドで証明書のステータスを確認する(発行済みかチェック) # 実行環境: Amazon Linux 2023 / Ubuntu 22.04 (aws cli v2) aws acm list-certificates --region ap-northeast-1 --query 'CertificateSummaryList[*].[DomainName,Status]' --output table # 出力例(発行済み証明書が一覧表示される) ------------------------------------------- | ListCertificates | +-----------------------------+-----------+ | *.example.com | ISSUED | | example.com | ISSUED | +-----------------------------+-----------+
1. ALBを作成・確認する
EC2コンソールからロードバランサーを開き、対象のALBを選択します(または新規作成)。マルチAZ構成にする場合は、2つ以上のアベイラビリティゾーンとパブリックサブネットを選択してください。ALBのセキュリティグループには、インターネットからの443(HTTPS)ポートへのインバウンドを許可するルールが必要です。ポート設定の確認には、Linux ポート確認の全コマンドも参考にしてください(EC2インスタンス側の設定確認時に使えます)。
2. HTTPSリスナーを追加してACM証明書を選択する
ALBの「リスナーとルール」タブで「リスナーを追加」をクリックします。プロトコルは「HTTPS」、ポートは「443」を選択します。「デフォルトSSL/TLS証明書」で、先ほど発行したACM証明書を選択します。「ACMから」を選ぶと、同じリージョンのACM証明書の一覧が表示されます。対象の証明書を選択して設定を保存します。
3. ターゲットグループとルールを設定する
HTTPSリスナーのデフォルトアクションで「ターゲットグループへ転送」を選択し、バックエンドEC2インスタンス群を含むターゲットグループを指定します。ターゲットグループのプロトコルはHTTP(80)のままで問題ありません。ALBとEC2間の通信はVPC内ネットワークであり、外部からの通信はALBのHTTPS終端によって保護されます。HTTP→HTTPSリダイレクト設定
HTTPS(443)リスナーを追加しただけでは、HTTPでアクセスされた場合にそのままHTTPで表示されます。HTTPアクセスを自動的にHTTPSへリダイレクトするため、HTTP(80)リスナーにリダイレクトルールを追加します。ALBの「リスナーとルール」でHTTP(80)リスナーを選択し、デフォルトアクションを「URLへリダイレクト」に変更します。設定値は以下のとおりです。
・プロトコル:HTTPS
・ポート:443
・ステータスコード:301(恒久的なリダイレクト)
この設定により、http://example.com へのアクセスが自動的に https://example.com へ301リダイレクトされます。SEO観点でも、301リダイレクトはページの評価を引き継ぐため重要です。
設定後はブラウザのシークレットモードで http:// からアクセスし、https:// へ自動転送されることを確認してください。
ACM証明書の自動更新の仕組みと注意点
ACM証明書の有効期限は13ヶ月(約400日)です。Route 53でDNS検証を行った証明書は、有効期限の60日前からACMが自動更新を試みます。Route 53のCNAMEレコードが有効な限り、手動での更新作業は一切不要です。注意が必要なのは、以下のケースです。
・Route 53以外のDNSプロバイダーを使用している場合:CNAMEレコードが削除されていると更新に失敗します。CNAMEが残っているか定期的な確認が必要です
・証明書がリソースにアタッチされていない場合:ALB等のリソースにアタッチされていない未使用証明書は自動更新が行われません
・リージョンをまたいだ移行:CloudFront向け証明書をus-east-1以外のリージョンで発行した場合は使用できません
自動更新が正常に動作しているかは、ACMコンソールの証明書詳細画面「更新の状態」で確認できます。「更新の資格がある」と表示されていれば問題ありません。CloudWatch Eventsで自動更新の失敗を検知し、SNS通知する仕組みを追加しておくと運用リスクを下げられます。
よくあるエラーと対処法
「証明書の検証保留中」が何日経っても解消されない
DNS検証のCNAMEが正しく設定されていない場合に発生します。以下を確認してください。・Route 53のホストゾーンにACMが追加したCNAMEレコードが存在するか
・ドメインのネームサーバー設定がRoute 53のNSレコードを指しているか(よくある見落とし)
・CNAMEの値に末尾のドット(.)を付け忘れていないか(一部のDNS管理画面で必要)
ネームサーバーの切り替え直後は、DNS伝播に最大48時間かかることがあります。
「ターゲットグループのヘルスチェック失敗」でHTTPS接続が返らない
ALBのターゲットグループのヘルスチェックが失敗していると、HTTPS通信が正常に返りません。確認ポイントは以下です。・EC2インスタンスのセキュリティグループが、ALBからのHTTPインバウンド(80番)を許可しているか
・EC2上のWebサーバー(Apache等)が正常に起動しているか(httpd の基本操作参照)
・ヘルスチェックパスのHTTPステータスが200を返しているか
証明書をALBに設定できない・グレーアウトしている
ACMの証明書リージョンとALBのリージョンが一致していない場合に発生します。ALBと同じリージョンでACM証明書を発行し直す必要があります。CloudFrontの場合はus-east-1(バージニア北部)でACM証明書を発行する必要があります。まとめ:AWSで安全なHTTPS環境を構築しよう
ACMとRoute 53・ALBを組み合わせたHTTPS化の手順をまとめます。| ステップ | 作業内容 | ポイント |
|---|---|---|
| 1. ACMで証明書発行 | ドメイン入力→DNS検証選択 | Route 53なら自動でCNAME追加 |
| 2. DNS検証完了確認 | ステータスが「発行済み」になるまで待つ | 通常数分~30分程度 |
| 3. ALBにHTTPS(443)リスナー追加 | ACM証明書をリスナーに紐付け | 証明書はALBと同じリージョンのものを選択 |
| 4. HTTP→HTTPSリダイレクト | HTTP(80)リスナーを301リダイレクトに変更 | ステータスコード301でSEO評価を引き継ぐ |
| 5. 動作確認 | ブラウザで鍵マーク+HTTPSアクセスを確認 | 証明書の有効期限・発行元もブラウザで確認できる |
AWS環境でのLinuxサーバー構築・運用をさらに深く学びたい方は、AWS(Amazon Linux)の基礎から実践まで解説した入門ガイドもぜひ参考にしてください。
AWSでのHTTPS設計を「実務の型」として身につけませんか?
ACMの設定方法は調べれば分かります。でも「なぜALBでSSL終端するのか」「マルチAZ構成での証明書管理はどうするのか」を説明できますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 前のページへ:AWS VPCエンドポイントでS3へプライベート接続する方法|Gateway型・Interface型の違いとNATコスト削減設計
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます