Share
Embed
Slide 1
Slide 1 text
ALB
「証明書上限問題」からの脱却
Road to SRE NEXT 2026 @
京都
2026/1/16
Slide 2
Slide 2 text
自己紹介
活動名
無双（@nishi_okashi
）
住まい
兵庫県
Slide 3
Slide 3 text
前提となるお話
オンラインコミュニティサイト構築アプリ
「独自ドメイン提供」サービス
お客様の好きなドメインで運用可能
Slide 4
Slide 4 text
課題：ALB
の限界との戦い
顧客ドメインごとに SSL
証明書が必要
ここでクイズです
Q. ALB
にアタッチできる証明書の上限は？
Slide 5
Slide 5 text
A.
デフォルト 25
枚
Slide 6
Slide 6 text
泥沼の戦い
1.
緩和申請で 100
枚 まで増枠
2. 2
台目のALB
を投入
3.
そして 3
台目 の足音が…
「これ、いつまで続けるの？」
Slide 7
Slide 7 text
解決策：NLB + Caddy
NLB (Network Load Balancer)
Caddy
Go
製のWeb
サーバー
自動HTTPS
機能が強力
Slide 8
Slide 8 text
新アーキテクチャ
Slide 9
Slide 9 text
アーキテクチャのポイント
いきなりアプリに繋ぐのではなく、既存ALB
を挟む
WAF
やターゲットグループなどの既存資産を有効活用
Slide 10
Slide 10 text
移行の課題
「ダウンタイムゼロ」 で切り替えたい
手間なく証明書を発行したい
http-01
チャレンジ
移行には DNS
切り替え が必要
しかし切り替え直後は証明書がない
→ ユーザーは SSL
エラー になる
Slide 11
Slide 11 text
解決策：事前発行トリック
「既存のALB
を経由して、新環境の証明書を作
る」
旧環境が稼働したまま、特定のアクセスだけを新環境へ転送するアプ
ローチ
Slide 12
Slide 12 text
No content
Slide 13
Slide 13 text
いざ、切り替え
裏で証明書確保は完了している
あとは DNS
をNLB
へ向けるだけ
→ ダウンタイムゼロで移行完了！
Slide 14
Slide 14 text
ところでDNS
の話
2
種類の方法で運用
Slide 15
Slide 15 text
Before: CNAME
パターン
A
レコードはIP
アドレスしか設定できない
ALB
のIP
は定期的に変わる
AWS
にはエイリアスレコードというものがあり、ALB
のドメインを
登録できる
顧客全員がAWS
を利用しているわけではない
解決策として弊社側でALB
へ転送するドメインを用意し、顧客に
CNAME
登録してもらっていた
Slide 16
Slide 16 text
弊社側
domain type value
alb.example.com
A (
エイリアスレコー
ド)
ALB
のデフォルトドメイ
ン
顧客側
domain type value
community.client.com CNAME alb.example.com
これ以外にもACM
検証用のドメインを登録
Slide 17
Slide 17 text
Before: NS
パターン
CNAME
が登録できない場合（ネイキッドドメイン）
、弊社へNS
を向け
てもらい、弊社側でレコードを登録していた
Slide 18
Slide 18 text
弊社側
domain type value
client.com A (
エイリアスレコード) ALB
のデフォルトドメイン
顧客側
domain type value
client.com NS ns-xxx.awsdns-xx.com
レコード管理が弊社になるので、レコード追加する必要が出た時、弊
社が対応しないといけない
Slide 19
Slide 19 text
After:
シンプル
NLB = Elastic IP (
固定IP)
ドメインの種類に関わらず…
「A
レコードでIP
を向けるだけ」
顧客への案内フローが劇的に簡略化！
Slide 20
Slide 20 text
まとめ
課題: ALB
の証明書枚数制限、管理コスト
解決: NLB + Caddy
構成への刷新
工夫:
既存ALB
を活用した事前発行トリック
副産物:
固定IP
化で顧客のDNS
設定が単純化
インフラ改善がオンボーディング工数削減に繋
がった！
Slide 21
Slide 21 text
ご清聴ありがとうございました