ALB「証明書上限問題」からの脱却

Road to SRE NEXT 2026 @京都の発表資料

Transcript

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