AWS CDKでホストゾーン一式を管理しよう！/nw-jaws15

2025/02/21 NW-JAWS #15 ～改めて振り返るRoute 53～の登壇資料です。

Transcript

1. © 2025 Mizuho Research & Technologies, Ltd. NW-JAWS #15 ～改めて振り返るRoute 53～ AWS CDKでホストゾーン一式を管理しよう！ 2025/02/21 小坂 洋祐 0
2. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. 自己紹介 小坂 洋祐（こさか ようすけ） みずほリサーチ＆テクノロジーズ 先端技術研究部所属 業務： • 社内AWSプラットフォームの開発・運用 • クラウド研究（AWSアップデートの確認・検証・情報展開等） 登壇歴： • 2023/11/15 Security-JAWS「AWS Control Towerを2年弱運用して得たエッセンスと展望」 • 2024/09/25 CDK支部「BLEA v3.0.0の新しいベストプラクティスを取り入れた効率的なAWS CDK開発」 好きなAWSサービス： 1 AWS Control Tower AWS Cloud Development Kit (AWS CDK)
3. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. 前提 • ドメイン自体はRoute53コンソール上で取得しています。 • 取得したドメインを利用して、サブドメインのホストゾーンをCDKで管理するお話となります。 2
4. ホストゾーンの作成、どうしていますか？ 3
5. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. マネジメントコンソールでの課題 マネジメントコンソールだと・・・ 構築の手続きが煩雑 • ホストゾーンの作成→サブドメインの委任→Aレコードなど必要なレコードの作成 • 必要な情報をそれぞれ手動で取得・コピペ等する必要あり • ACM証明書の作成（＋DNS認証） • アプリケーション・インフラは別途構築が必要 環境ごとに操作が必要 • 本番環境、開発環境等用意する場合、その個数分Route 53の操作が必要。 不要時の削除が煩雑 • 手動で作ったものは手動で削除する必要あり。対象の洗い出しも必要。 • コストダウン目的での削除がしづらい。再作成も大変。 4
6. それ、AWS CDKで解決します！ 5
7. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. AWS CDKが解決できること AWS CDKを使うと・・・？ 6 マネジメントコンソール AWS CDK 構築の手続きが煩雑 少しのコードで cdk deployのコマンド一つで構築 アプリケーションも一緒に管理 環境ごとに操作が必要 環境複製が容易 不要時の削除が煩雑 cdk destroyのコマンド一つで削除 （※一部例外あり）
8. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. 構成図 今回の題材である、ECS上で稼働しているRedmineアプリケーションの構成図 AWS Account枠内のすべてをAWS CDK(TypeScript)で作成しています 7
9. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. 構成図 今回の題材である、ECS上で稼働しているRedmineアプリケーションの構成図 AWS Account枠内のすべてをAWS CDK(TypeScript)で作成しています 8 本日の主題→
10. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. CDKのスタック構成 9 app WafStack RedmineStack NetworkConstruct DataConstruct AppConstruct us-east-1↑ ap-northeast-1↓ ACM • Certificate(ACM証明書) Route 53 • PublicHostedZone(パブリックホストゾーン) • Zone Delegation Record(サブドメインの委任) Route 53 • A Record(CloudFront DistriutionのAliasレコード) VPC等を定義 Aurora等を定義 CloudFront ・Distriution(後続のALB→ECSへ接続) Redmineアプリケーションを定義(ECS, ALB, CloudFront etc..) WAF等を定義
11. © 2025 Mizuho Research & Technologies, Ltd. Strictly Confidential CDKのスタック構成 10 app WafStack RedmineStack NetworkConstruct DataConstruct AppConstruct us-east-1↑ ap-northeast-1↓ ACM • Certificate(ACM証明書) Route 53 • PublicHostedZone(パブリックホストゾーン) • Zone Delegation Record(サブドメインの委任) Route 53 • A Record(CloudFront DistriutionのAliasレコード) VPC等を定義 Aurora等を定義 CloudFront ・Distriution(後続のALB→ECSへ接続) Redmineアプリケーションを定義(ECS, ALB, CloudFront etc..) WAF等を定義
12. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. WafStack：Route53 サブドメインの補正 複数環境を作れるように、本番(prod)以外はサブドメインに環境識別子を含めるように変更。 11 Amazon Route 53 export const DOMAIN = "example.com"; export const SUB_DOMAIN = "redmine"; （中略） let subDomain = SUB_DOMAIN; //環境が本番以外の場合、環境識別子を含める if (props.systemEnv !== "prod") { subDomain = `${props.systemEnv}-${SUB_DOMAIN}`; } 例） prod → redmine.example.com dev → dev-redmine.example.com サブドメインの前に環境識別子を設定
13. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. WafStack：Route53 パブリックホストゾーンの定義 12 public readonly zone: r53.IHostedZone; （中略） this.zone = new r53.PublicHostedZone( this, "publicHostedZone", { zoneName: `${subDomain}.${DOMAIN}`, }, ); Amazon Route 53 サブドメインの委任レコード（ZoneDelegationRecord） const parent = r53.HostedZone.fromLookup( this, "hostedZone" { domainName: DOMAIN, }, ); new r53.ZoneDelegationRecord( this, "zoneDelegationRecord", { nameServers: this.zone.hostedZoneNameServers!, zone: parent, recordName: subDomain, }, ); パブリックホストゾーン及び、サブドメインの委任 fromLookupで 親ドメイン情報を取得できる クロススタック参照用
14. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. AWS Certificate Manager (ACM) WafStack：ACM サブドメインの証明書発行 13 this.certificate = new acm.Certificate( this, "certificate", { domainName: this.zone.zoneName, subjectAlternativeNames: [`*.${this.zone.zoneName}`], validation: acm.CertificateValidation.fromDns(this.zone), }, ); validationの設定も可能。 自動的にホストゾーンにCNAMEレコードを作成してくれる
15. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. WafStack：デプロイ cdk deployでWafStackをデプロイします。 デプロイが完了すると、 Route53にサブドメインのホストゾーンが作成され、ACMの検証用のCNAMEレコードが作成されています。 14 $ npx cdk deploy XXXXWafDevStack
16. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. WafStack：デプロイ 親ドメインにNSレコードが作られ、サブドメインが委任されていることが確認できます。 15
17. © 2025 Mizuho Research & Technologies, Ltd. Strictly Confidential CDKのスタック構成 16 app WafStack RedmineStack NetworkConstruct DataConstruct AppConstruct us-east-1↑ ap-northeast-1↓ Route 53 • PublicHostedZone(パブリックホストゾーン) • Zone Delegation Record() VPC等を定義 Aurora等を定義 Redmineアプリケーションを定義(ECS, ALB, CloudFront etc..) Route 53 • A Record(CloudFront DistriutionのAliasレコード) CloudFront ・Distriution(後続のALB→ECSへ接続) ACM • Certificate(ACM証明書)
18. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. RedmineStack：AppConstruct ECSやALB等を定義するAppConstructの最後で、CloudFrontとAレコードを定義する。 CloudFront 17 // CloudFront const redmineDistribution = new cloudfront.Distribution( this, "redmineDistribution", { defaultBehavior: { origin: new origins.LoadBalancerV2Origin(alb, { protocolPolicy: cloudfront.OriginProtocolPolicy.HTTPS_ONLY, }), ・・・中略・・・・ }, webAclId: props.webAcl.attrArn, certificate: props.certificate, domainNames: [props.zoneName], }, ); WafStackで作ったWAF、証明書、ホストゾーンを設定
19. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. RedmineStack：AppConstruct ECSやALB等を定義するAppConstructの最後で、CloudFrontとAレコードを定義する。 Route53 Aレコード 18 // # Configure A Record to the HostedZone new r53.ARecord(this, "ARecord", { target: r53.RecordTarget.fromAlias( new r53targets.CloudFrontTarget(redmineDistribution), ), zone: props.zone, }); ターゲットはCloudFront Distriution WafStackで作ったホストゾーンを設定
20. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. RedmineStack：デプロイ cdk deployでRedmineStackをデプロイします。 先程のCNAMEに加え、Aレコードが追加され、ルーティング先がCloudFrontになっていることが確認できます。 19 $ npx cdk deploy XXXXRedmineDevStack
21. まとめ 20
22. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. まとめ 21 マネジメントコンソール AWS CDK 構築の手続きが煩雑 少しのコードで cdk deployのコマンド一つで構築 アプリケーションも一緒に管理 環境ごとに操作が必要 環境複製が容易 不要時の削除が煩雑 cdk destroyのコマンド一つで削除 （※一部例外あり）
23. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. まとめ 少しのコードでcdk deployのコマンド一つで構築。アプリケーションも一緒に管理 22 • コードは左記の.tsファイル7点のみ。 （app:1, stack:2, constructs:3, parameter:1） • これらのファイルで、インフラ、アプリ、DNS周りを一括管理 • 今回は話の都合上2つのスタックを2回に分けてデプロイしたが、 実際にはコマンド1回でのデプロイ可能。 • デプロイ後コンソールでの操作などは一切不要で、 すぐにアプリケーションを利用できる！
24. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. まとめ 環境複製が容易 今回のコードでは、ドメインに環境識別子を活用し、複数の環境を構築可能。 parameter.ts内で配列で環境識別子を定義し、app.ts内でその環境分定義を作成できるようにしている。 cdk deploy時にスタック名を指定すれば、特定の環境のみのデプロイ可能。 23 parameter.ts export const Environments = ["prod", "dev"]; import { Environments } from "../parameter"; const app = new cdk.App(); for (const environment of Environments) { // WafStackの定義 // RedmineStackの定義 app.ts
25. Strictly Confidential © 2025 Mizuho Research & Technologies, Ltd. まとめ cdk destroyのコマンド一つで削除 cdk destroyのコマンドで、DNS含め関連リソースを一括削除可能 不要な開発環境の削除の手間を削減 ACMのCNAMEレコードは例外 ACMが作ったCNAMEレコードは、テンプレート上リソースとして現れないため自動削除されない。 スタック削除でホストゾーンを削除するとき、CNAMEレコードが残っているため削除に失敗する。 24 CNAMEレコードは事前に手動削除する必要がある。 ここだけ残念・・・ 現状、自動化にはカスタムリソース等の作成が必要。