DNSレコードをTerraformで管理していたドメインがありました。(Route53)
IaC(Infrastructure as Code)は当然のようになっていてこのドメインもTerraformで管理していました。

しかし運用していくにつれ今の構成に不満点も出てきてて, なんかいい感じに出来ないかな~と思っていました。

• Terraformで管理しているけど, 管理するレコード数が多くなるにつれ terraform plan や terraform apply の実行に時間がかかるようになってきた
• CircleCI使って自動化してるからデプロイ待たないで違うことしてればいいんだけど, そこまで何か違うことできるほど時間かかるわけじゃないから結局待っちゃってストレス
• そもそもコード化してるけど, このドメインに関していうとプルリク作ってレビューしてapply!みたいな慎重な手順は踏む必要がなくどちらかという柔軟にどんどん変更加えられた方がいい
• マネジメントコンソールとかaws-cliからサクッと変更しちゃいたい
• 別サービスとの連携等で自動でレコード追加とかされても気にしたくない

でもコード化していることによるメリットももちろんあります。

• ログが残る
• なのでロールバックもできる

他にもいろいろあると思いますが, このDNSレコード管理においてはログが残っていてロールバックできるようになっていれば十分だと考えました。

それを満たしつつ不満点をちょっとでも解消できないかな~と思っていろいろ考えた結果, Terraformでの管理をやめました。

Terraformはダメだという意図は全くありません！
今回のユースケースに合わなくなっただけで, 別のところではバリバリ使っています！

変更手段は自由にしたい

でもログを残したい! ということで考えたものです。

https://github.com/heptagon-inc/r53rw

処理の流れ

• マネジメントコンソール等からDNSレコードを修正する
• CloudTrailに流れてCloudWatchEventsで拾ってLambda FunctinとCodeBuildを起動する
• Lambda Functionで変更内容をSlackに通知する
• CodeBuildでRoadworkerを動かし, 対象ホストゾーンのDNSレコード情報をエクスポートし, S3にPutする
• CodeBuildのステータスがFailedになったらSlackに通知

構成について

• 全体管理はAWS CDKで
• Route53のAPIコールログ出力の設定は別管理でやってるのでAWS CDK管理外

とりあえずこんな感じで作ってみて実際運用を始めています。
もしロールバックしたいようなことがあればS3にあるRoutefileを取ってきて roadworker --apply すればいいか~って感じです。S3バケットはVersioning設定してるので古いものも取得できるしそれで十分だと思います。
(ちょっとしたした修正ならマネジメントコンソールから戻しちゃうと思うけど)

まだやり始めたばかりなのでこれから課題出そうですが, とりあえずこれでやっていこうと思います。