Route 53 호스티드 존을 NFS 파일시스템으로 마운트한다는 AWS 출시 글 패러디

DNS에 환자 정보를 넣지 말라는 FAQ 답변이 제일 웃겼음. 예전에 HN에 올라온 DNS 호스팅 장난이 떠오르더라

DNS를 손으로 관리하는 사람이 정말 이렇게 많나 싶음. TXT 레코드 말고는 대부분 자동화로 리소스에 연결하지 않나

S3 객체도 사람이 관리하면서 파일시스템처럼 쓰고 싶어 하는 경우가 많음. 그 수요와 비슷한 농담 같음

대규모 조직이면 수십 년간 쌓인 프로젝트와 직원 수를 생각해야 함. 모든 DNS가 깔끔한 자동화만으로 관리되진 않음

이건 필요를 채우려는 물건이라기보다 농담에 가까움. 그래도 S3 Files 마운트를 둔 Git 저장소와 cron으로 DNS 자동화를 흉내 낼 수는 있겠네

예전 직장에서는 감사와 통제 때문에 DNS 변경을 티켓과 IaC로만 처리했음

처음엔 Corey Quinn 식의 Route 53 일반 파일시스템인 줄 알았음. 끔찍할 정도로 아름다운 아이디어라 잘 만들었네

예전 AWS 블로그 심사 담당자였는데, 작성자가 AWS 출시 글 문체를 대부분의 아마존 직원보다 잘 흉내 냈음

공식 문체 가이드가 있나? 나는 S3 Files 출시 글을 주로 따라 했고, PRFAQ에서 시작해서 고객 인용문과 FAQ를 넣었음

DNS 레코드 같은 키값 데이터를 블록 기반 read()와 write()로 다루면 사용 경험이 더 나빠질 것 같음

진지하게 Route 53 API 대안을 찾는다면 DNSControl을 추천함. Terraform 비슷하게 DNS를 관리하는 오픈소스고 v5.0이 큰 폭으로 다시 작성됐음

이 글은 계절에 맞지 않는 만우절 농담이라 진지한 대안 제안이 조금 어색하긴 함. 그래도 is-a.dev는 GitHub에서 DNSControl로 서브도메인 등록을 관리하는 영리한 사례임

Route 53은 어떤 경우에는 단순한 고가용성 키값 저장소로 쓸 만했음. GitHub Actions에서 값을 보관할 다른 수단이 마땅치 않아 써본 적 있음

Route 53은 DNSSEC 활성화도 쉬워서 DNS 데이터에 암호학적 서명을 붙일 수 있음. 공개키와 인증서를 DNS에 넣는 용도는 더 납득이 감