ALBでHTTPS通信を実現するためにACM証明書とRoute53の設定について調べてみた
製造ビジネステクノロジー部の小林です。
最近、久しぶりに ALB（Application Load Balancer）に触れる機会がありました。Web アプリケーションを公開する際、HTTPS 通信は今や必須要件です。しかし初めて AWS で HTTPS 化に取り組むと、「SSL 証明書ってどうやって取得するの？」「Route 53 は必要なの？」「ALB の設定はどうすればいいの？」といった疑問に直面することが多いのではないでしょうか。
今回は、Route 53 でドメインを取得し、ACM で証明書を自動発行し、ALB で HTTPS 通信を実現する一連の流れを実践してみました
前提条件
AWS CDK（TypeScript）
なぜ HTTPS 通信が必要なのか？
ALB で外部と通信する場合、HTTP（ポート 80）を利用すると以下のようなリスクがあります。
- パスワードや個人情報が平文で流れるため、Wi-Fi 盗聴などで簡単に漏洩する
- 通信途中でマルウェアを埋め込まれたり、偽の情報に書き換えられるおそれがある
- アクセスしているサーバーが本物かどうか確認する手段がない
HTTPS が標準である理由
HTTPS はこれらの問題を解決します。Google Chrome などの主要ブラウザは、HTTP サイトに対して「保護されていない通信」という警告を出し、SEO 順位も低下させます。
| 特徴 | HTTP | HTTPS |
|---|---|---|
| 暗号化 | なし（平文） | SSL/TLS で暗号化 |
| 信頼性 | 保証なし | 証明書でサーバーを認証 |
| 改ざん検知 | 不可 | 検知可能 |
| ブラウザ表示 | ⚠ 警告あり | 鍵マーク表示 |
HTTPS 化の必須要件：SSL/TLS 証明書
ALB を HTTPS 化するには、SSL/TLS 証明書が必要です。 証明書は「このサーバーは正規のものです」と証明するデジタル身分証明書です。
証明書に含まれる重要な情報
- ドメイン名
- どのドメインで使えるか（例: example.com）
- 証明書は特定のドメインに対して発行される
- どのドメインで使えるか（例: example.com）
- 発行者（認証局）
- どの認証局によって発行されたか
- 信頼できる認証局かどうかをブラウザが検証
- 有効期限
- いつまで有効か
- 期限切れの証明書は使えない
- 公開鍵
- 暗号化に使用する鍵
- 秘密鍵とペアで使用
以上のように証明書がなければ、ALB で HTTPS 通信はできません。
証明書取得の方法と ACM の優位性
証明書を取得する方法はいくつかありますが、AWS で ALB を使う場合は ACM (AWS Certificate Manager) が推奨されています。
| 比較項目 | 商用証明書 (DigiCert 等) | Let's Encrypt | AWS ACM |
|---|---|---|---|
| コスト | 年間 数千円〜 | 無料 | 無料 |
| 有効期限 | 1 年 | 90 日 | 13 ヶ月 |
| 更新作業 | 手動で定期的な更新が必要 | 90 日毎にスクリプト実行 | 自動 |
| ALB 連携 | 手動アップロード | 複雑な設定が必要 | CDK で数行書くだけ |
ACM に必要なドメイン名
ACM で証明書を取得するには、自分が所有するドメイン名が必要です。
ドメイン名の例
- example.com
- myapp.jp
- my-service.net
ACM にはなぜ「ドメイン名」が必要なのか？
SSL/TLS 証明書は「IP アドレス」ではなく「ドメイン」を証明するものだからです。ACM の仕様上、パブリックな証明書の発行にはドメイン名が必須となります。
| アクセス方法 | URL の例 | 証明書 | ブラウザの反応 |
|---|---|---|---|
| IP アドレス | http://54.123.45.67 |
発行不可 | ⚠️「保護されていない通信」 |
| ドメイン名 | https://example.com |
発行可能 | 🔒 鍵マーク（安全） |
ドメイン取得には Route 53 がおすすめ
ドメインは「お名前.com」や「Google Domains」など外部のレジストラでも取得できます。しかし、AWS CDK を使ってインフラを構築する場合は、Route 53 が推奨されます。その理由は、「DNS 検証（ドメイン所有確認）の完全自動化」ができるからです。
外部レジストラを使うと、「AWS」と「外部サイト」を行き来する手動オペレーションが発生します。一方、Route 53 ならすべてがコードで完結します。
外部レジストラの場合
- 外部レジストラでドメインを取得
↓ - Route 53 でホストゾーンを作成
↓ - 外部レジストラでネームサーバーを Route 53 に変更 ← 手動
↓ - DNS 伝播を待つ（最大 48 時間）
↓ - ACM で証明書をリクエスト
↓ - DNS 検証レコードを手動で Route 53 に追加 ← 手動
↓ - 証明書が発行される
Route53 の場合
- Route 53 でドメインを取得
↓（ホストゾーンも自動作成） - ACM で証明書をリクエスト
↓（CDK が自動で DNS 検証レコードを追加） - 証明書が自動発行
↓ - 完了！
Route 53 を使うことで、以下のコードのみで「証明書のリクエスト」から「検証完了」までがバックグラウンドで自動処理できます。
// 1. Route 53の情報を参照
const hostedZone = route53.HostedZone.fromLookup(this, "Zone", {
domainName: "example.com", // 取得したドメイン名
});
// 2. ACM証明書の作成
const certificate = new acm.Certificate(this, "Cert", {
domainName: "example.com",
// ↓ この1行だけで、Route 53への検証レコード追加→検証→発行まで自動化される
validation: acm.CertificateValidation.fromDns(hostedZone),
});
ドメイン代(.com で年間$15 程度)は外部レジストラと同等か若干高い場合がありますが、Route 53 を使うことで「DNS 検証の自動化」「手動オペレーションの削減」「設定ミスのリスク低減」が実現できます。これらの運用効率を重視する場合、Route 53 の選択が有効です。
やってみた
Route53 でドメインを取得し、CDK で ACM と ALB を構築します。
Route53 のコンソールから「ドメインの登録」を選択します。
希望するドメイン名で登録を進めます。
料金は $15/年 でした。😊
ドメインの登録が正常に完了しました。
ホストゾーンも自動的に作成されていることが確認できます。
これで Route53 でのドメイン登録作業は完了です。
ACM 作成
取得したドメインを使って、SSL/TLS 証明書を自動発行するコードを記述します。
/**
* ドメイン設定
* AWSコンソール(Route 53)で取得済みのドメイン名をここに指定します
*/
const DOMAIN_NAME = 'ドメイン名';
/**
* Route 53 ホストゾーンの参照
* 作成されたホストゾーン情報をAWSアカウントから読み込みます
*/
const hostedZone = route53.HostedZone.fromLookup(this, 'HostedZone', {
domainName: DOMAIN_NAME,
/**
* ACM証明書の作成
*/
const certificate = new acm.Certificate(this, 'Certificate', {
domainName: DOMAIN_NAME,
// サブドメイン（例: www.example.com）もカバーできるようにワイルドカードを含める
subjectAlternativeNames: [`*.${DOMAIN_NAME}`],
/**
* DNS検証をRoute 53と連携して全自動で行う設定
* これにより、CNAMEレコードの手動登録が不要になります
*/
validation: acm.CertificateValidation.fromDns(hostedZone),
})
これだけで、「証明書のリクエスト」「DNS 検証レコードの追加」「検証待機」 がすべて自動で行われます。
ALB 作成
続いて、証明書を使った ALB を定義します。 HTTP（ポート 80）へのアクセスを HTTPS（ポート 443）に強制リダイレクトさせるリスナールールも作成しました。
/**
* VPCの作成
* ALBを配置するためのネットワーク環境を作成
*/
const vpc = new ec2.Vpc(this, 'Vpc', {});
/**
* ALB の作成
*/
const alb = new elbv2.ApplicationLoadBalancer(this, 'ALB', {
vpc,
internetFacing: true, // インターネットからのアクセスを許可
})
/**
* リスナー設定 A: HTTP (ポート80)
* HTTP通信は、強制的にHTTPSへリダイレクト
*/
alb.addListener('HttpListener', {
port: 80,
defaultAction: elbv2.ListenerAction.redirect({
protocol: 'HTTPS',
port: '443',
permanent: true, // 301リダイレクト
}),
/**
* リスナー設定 B: HTTPS (ポート443)
* ここで証明書を紐づける
*/
alb.addListener('HttpsListener', {
port: 443,
certificates: [certificate], // 作成した証明書をセット
defaultAction: elbv2.ListenerAction.fixedResponse(200, {
contentType: 'text/plain',
messageBody: 'Hello, CDK!',
}),
});
Route53 A レコードの作成
最後に、ドメイン名で ALB にアクセスできるように、Route 53 の A レコード（エイリアスレコード）を作成します。 これを作成することで、ドメイン名へのアクセスが自動的に ALB へルーティングされるようになります。
/**
* Route53 ホストゾーンに ALB のエイリアスを登録
* ユーザーが https://m2m-endpoint.com にアクセスしたときALBに繋がるようにする
*/
new route53.ARecord(this, "AliasRecord", {
zone: hostedZone,
target: route53.RecordTarget.fromAlias(
new route53_targets.LoadBalancerTarget(alb)
),
});
デプロイ
実装が完了したので、デプロイして動作を確認します。
動作確認
デプロイが完了したら、AWS マネジメントコンソールと実際のブラウザアクセスの両面から確認を行います。
Route 53 の確認
ドメインと ALB を紐づける DNS レコードが作成されているか確認します。
AWS コンソールで Route 53 を開き、「ホストゾーン」から対象のドメインを選択します。A レコードが作成されていることを確認できました。
これが作成されていることで、「ドメインへのアクセス → ALB へ転送」という経路が確立されます。
CNAME レコードの確認
レコード名が _ から始まる CNAME レコード が作成されていることも確認できました。これは ACM が証明書を発行・維持するための「ドメイン持ち主確認用」レコードです。
ACM の確認（証明書ステータス）
次に、SSL/TLS 証明書が正しく発行されているか確認します。
AWS コンソールで Certificate Manager (ACM) を開き、対象ドメインの証明書をクリックします。
ステータスが 「発行済み」かつ「成功」 になっていることが確認できました。
ブラウザでの接続確認
最後に、実際にブラウザからアクセスして挙動を確認します。
HTTPS での接続（成功パターン）
ブラウザのアドレスバーに https://<ドメイン名> を入力してアクセスします。
画面に "Hello, CDK!" と表示されれば OK です。 HTTPS 通信が正常に確立されていることが確認できました。
HTTP リダイレクトの確認（転送パターン）
続いて、自動転送（リダイレクト）の設定を確認します。 あえて http:// を明示して、http://<ドメイン名> にアクセスしてみます。
自動的に https://〜 へ切り替わり、先ほどと同じ画面が表示されました。 これで、HTTP から HTTPS へのリダイレクトも正常に機能していることが確認できました。
おわりに
今回は、Route 53 でドメインを取得し、ACM と ALB を使って HTTPS 通信を実現する手順を試してみました。手動で構築する場合、証明書のリクエスト、DNS レコードの追加、検証の待機...と多くの手順が必要ですが、Route 53 と ACM を CDK で組み合わせることで、これらがすべてバックグラウンドで自動完結することの快適さを実感できました。
この記事が皆様の参考になれば幸いです。
