Route 53サブドメインホストゾーンを作成したら、元のホストゾーンにNSレコードを作成する自動化
ハンズオン環境でRoute 53のホストゾーンを触ってほしい際に、サブドメインを設定する場合があります。
複数アカウントでセットアップを自動化したかったので、構築しました。
目次
動作
元のドメインがexample.comだとします。
サブドメインの123はアカウントIDを想定しています。
- アカウントBでRoute 53に123.example.comホストゾーンが作成される
- EventBridgeがイベントを検知してLambda関数を実行
- Lambda関数がアカウントAのDynamoDBテーブルにレコードを追加
- DynamoDBストリームがアカウントAのLambda関数をトリガー
- アカウントAのLambda関数がexample.comのホストゾーンにNSレコード123.example.comを作成
これで、アカウントBのRoute 53で、www.123.example.comなどを作成して、レコードセット設定のハンズオンができます。
GitHub
CloudFormationテンプレートはGitHubにあります。
Lambdaのコードもテンプレートにインラインにしています。
https://github.com/yamamanx/route53-creatensrecord
EventBridgeのルール
対象アカウントが限定的なので、ホストゾーンの作成、削除はすべて対応としています。
|
1 2 3 4 5 6 7 8 9 |
{ "detail-type": ["AWS API Call via CloudTrail"], "source": ["aws.route53"], "detail": { "eventSource": ["route53.amazonaws.com"], "eventName": ["CreateHostedZone", "DeleteHostedZone"] } } |
ターゲットはLambda関数です。
Lambda関数では、クロスアカウントのDynamoDBテーブルにPutItemするので、boto3で指定しているテーブル名はARNにしています。
CreateHostedZoneの際はoperation=”create”、DeleteHostedZoneの際はoperation=”delete”でPutItemのみ許可されるようにしています。
Lambda関数はCloudFormationテンプレートにあります。
DynamoDBのリソースベースポリシー
昨年DynamoDBにリソースベースのポリシーが追加されましたので、それを利用しています。
ハンズオン用のアカウントBは元のドメインを管理しているアカウントAとは同じOrganizations組織にあります。
そこで次のようなポリシーにしました。
PutItemのみを組織内のアカウントで許可されたプリンシパルから受け付けます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "dynamodb:PutItem", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:PrincipalOrgID": "o-12345678" } } } ] } |
最後までお読みいただきましてありがとうございました!
「AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。
「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。
「AWS認定資格試験テキスト AWS認定AIプラクティショナー」という本を書きました。
「AWS教科書 AWS認定デベロッパーアソシエイト テキスト&問題集 」という本を書きました。
「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。
「AWSではじめるLinux入門ガイド」という本を書きました。
開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。
このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。
また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。
関連記事
-
-
AWS Secrets Manager交代ユーザーローテーション
AWS Secrets Managerの交代ユーザーローテーションを確認してみま …
-
-
S3バケットポリシーでクロスアカウントのPrincipalについて確認
確認したこと ドキュメントではこちらで確認しました。 AWS JSON ポリシー …
-
-
Amazon Glacierでボールトロックポリシーの作成開始をしてみました
Glacierを単体で使用することもそうそうないので、確認しました。 まずボール …
-
-
Amazon EC2のAMIイメージを自動取得して保持日数が過ぎたら削除
画像の保存をEC2に戻した事もあってEC2のバックアップの自動取得を勉強がてらや …
-
-
Amazon Linux 2023、T4Gインスタンス、PHP8にWordPressを移行しました
ブログをAmazon Linux 2からAmazon Linux 2023に移行 …
-
-
AWS Organizationsのルートユーザー管理(Root user management)でメンバーアカウントのルートユーザー認証を無効にしました
2024年11月発表のAWS Organizations を使用するお客様のため …
-
-
AWS EC2でAMI(Amazon Machine Image)を作成しておく
前回まででひとまずRedmineを構築するところまで出来たので、念のためスナップ …
-
-
CodeBuildで執筆原稿データをまとめた
今書いている原稿に対して編集者さんから、「できればで構わないのですが、章ごとにマ …
-
-
CloudWatch LogsをIPv6アドレスを使用して送信する
このブログの構成からパブリックIPv4を減らすように設計変更しています。 もとも …
-
-
Rocket.ChatにAWS Lambda(Python)から投稿する
Rocket.ChatにAPIで投稿するテスト(Postman)をやってみて、使 …

