Route 53 스로틀링: 초당 10회 아래인데도 DNS 배포가 막히는 이유

Route 53으로 DNS를 자동 배포하는데 요청을 초당 10회보다 적게 보냈는데도 제한에 걸린다면, 호출 횟수와 요청 안에 담은 변경량을 따로 세어 보세요. Route 53 DNS API는 계정의 요청 빈도와 DNS 데이터 변경량을 각각 제한합니다. 여러 배포가 한 계정을 쓰거나 한 번에 많은 레코드를 갱신한다면, 호출 수만 낮다고 안전한 속도라고 볼 수 없습니다.

AWS가 2026년 11월 3일 올린 운영 해설에서 이 모델과 사용 사례를 설명했습니다. 해설에 따르면 두 제한은 7월 30일부터 적용됐습니다. 11월에 처음 시작된 정책이라는 뜻은 아니에요. 아래 내용은 11월 9일 공식 해설과 개발자 문서를 대조한 결과이며, 실제 AWS 계정에서 레코드를 바꾸거나 처리 속도를 시험하지 않았습니다.

여러 배포가 같은 DNS 계정을 쓰면 생기는 일

운영팀이 오전에 호스팅 영역을 정리하고, 다른 팀은 같은 시간대에 서비스 도메인을 여러 개 배포한다고 해 볼게요. 한 팀의 배포 화면에는 호출이 많지 않은 것처럼 보입니다. 그러나 Route 53에 요청을 보내는 계정이 같다면 팀별 화면만 봐서는 전체 부하를 알 수 없습니다. 자체 스크립트뿐 아니라 인프라 도구와 자동 배포도 같은 창에 겹칠 수 있기 때문입니다.

이때 ‘초당 호출 몇 건인가’와 ‘그 호출에 담긴 변경이 얼마나 많은가’는 다른 질문입니다. 봉투에 신청서를 넣어 보낸다고 생각하면 쉽습니다. 봉투 한 개를 보내는 행위가 API 호출이고, 그 안에 들어 있는 여러 신청서가 DNS 변경입니다. 봉투를 덜 보내더라도 매번 많은 변경을 넣으면 다른 쪽 한도를 쓸 수 있어요.

AWS는 두 제한을 토큰 버킷으로 설명합니다. 토큰은 비밀 인증값이 아니라, 이 문맥에서는 작업을 얼마나 보낼 수 있는지 세는 단위입니다. 버킷에는 최대 용량과 채워지는 속도가 있습니다. 모아 둔 여유가 있으면 잠깐 많이 보낼 수 있지만, 계속 보내는 속도는 다시 채워지는 속도에 가까워야 합니다. 순간 허용량을 매초 쓸 수 있는 상시 한도로 읽으면 계산이 달라집니다.

봐야 할 제한	공식 문서의 기본값과 범위
계정 전체 API 호출	순간 최대 50, 초당 10씩 충전
특정 API 동작의 호출	동작별 추가 한도 확인
계정 전체 DNS 변경량	순간 최대 1,500, 초당 100씩 충전
다른 Route 53 제품	Resolver·Profiles·도메인 등록은 별도 기준

여기서 ‘계정 전체’는 한 팀의 배포만 뜻하지 않습니다. 예를 들어 레코드 변경 작업과 조회 작업을 동시에 돌린다면 두 작업 모두 호출 쪽의 사용량을 살펴야 합니다. 반면 DNS 데이터를 바꾸지 않는 일반적인 조회는 변경량 토큰을 쓰지 않습니다. AWS 문서에 나온 적용 범위는 Route 53 DNS API입니다. 이름이 비슷하다고 Resolver나 도메인 등록의 제한까지 이 표로 설명하면 맞지 않습니다.

기본 10이라는 숫자가 모든 API에 그대로 붙지 않습니다

공식 문서에서는 계정 전체 호출 한도 외에 개별 동작에도 제한을 둡니다. 예를 들어 호스팅 영역을 만드는 CreateHostedZone은 문서 표에서 초당 2씩 충전되고, 상태 검사를 만드는 CreateHealthCheck는 초당 0.5씩 충전됩니다. 후자의 0.5는 평균 충전 속도를 뜻해요. 하나의 요청을 반으로 보낸다는 의미는 아니고, 문서는 계정당 2초에 한 번이라는 지속 속도로 설명합니다.

운영팀이 보는 알림이 ‘API가 막혔다’ 하나뿐이라면, 먼저 어떤 동작이 많았는지 나누어 보세요. 여러 종류의 요청이 고르게 몰렸다면 계정 전체 호출량이 단서가 될 수 있습니다. 특정 동작만 반복하다 문제가 생겼다면 해당 동작에 별도 한도가 있는지도 확인해야 합니다. 한도는 기본 안내에 근거한 설명입니다. 계정의 실제 설정, 승인된 한도 변경 여부, 다른 자동화의 동시 실행은 현장에서 확인할 항목입니다.

또 레코드를 편집하는 호출 한 번은 호출 쪽과 변경량 쪽을 동시에 사용할 수 있습니다. 여러 레코드를 한 번에 넣으면 호출 횟수를 줄이는 데는 도움이 될 수 있지만, 같은 변경을 더 적은 호출에 묶었다고 변경량 자체가 사라지지는 않습니다. 배치 크기를 키우기 전에 어느 쪽이 모자란지 먼저 보는 이유입니다.

레코드 수와 변경량 토큰이 같지 않을 때

Route 53 개발자 문서에서 레코드 변경 동작은 만드는 CREATE와 지우는 DELETE가 변경 한 건당 토큰 하나, 있으면 갱신하고 없으면 만드는 UPSERT가 두 개입니다. 호스팅 영역 생성·삭제, VPC와 호스팅 영역의 연결·해제도 각각 변경량 토큰 두 개를 쓰는 동작으로 안내합니다. 전체 변경량은 계정 기준 한 버킷에서 계산합니다.

아래는 다른 작업이 없고 같은 크기의 레코드 변경을 꾸준히 제출한다고 가정한 숫자입니다. 요청 한 건에 들어갈 수 있는 세부 제한과 운영 조건은 별도로 확인해야 합니다. 이 예시는 호출과 변경량이 왜 따로 움직이는지 보여 주는 계산으로, 한도 시험이나 실제 배포 수치가 아닙니다.

가상 배포 패턴	1초 동안 쓰는 양
8회 호출, 한 번에 CREATE 10건	호출 8개, 변경량 80개
8회 호출, 한 번에 UPSERT 10건	호출 8개, 변경량 160개
4회 호출, 한 번에 UPSERT 20건	호출 4개, 변경량 160개
4회 호출, 한 번에 UPSERT 10건	호출 4개, 변경량 80개

세 번째 행은 두 번째보다 호출이 절반입니다. 그런데 변경량은 같습니다. 변경량 버킷의 여유를 잠시 사용할 수는 있어도 초당 160을 계속 쓰면 초당 100 충전으로는 따라가지 못합니다. 마지막 행처럼 제출하는 변경의 속도 자체를 낮추면 두 숫자가 함께 줄어요. 이 네 행은 현재 어떤 규칙이 반드시 발동하는지 예측하는 계산표가 아닙니다. 시작할 때 남아 있던 여유와 같은 계정의 다른 요청을 모르기 때문입니다.

레코드 세트 변경에는 별도의 배치 제약도 있습니다. 공식 할당량 페이지에서 값의 수나 요청 크기와 관련된 제한을 따로 확인하세요. 큰 요청을 만들 수 있다는 사실은 그 요청을 쉬지 않고 보낼 수 있다는 뜻이 아닙니다. 반대로 한 배치가 크다고 무조건 처리 실패로 보기도 어렵습니다. 요청의 유효성, 순간 용량, 장기 속도를 따로 봐야 합니다.

스로틀링이 보이면 기록부터 나누어 보세요

첫 번째 기록은 응답입니다. Route 53 할당량 문서는 스로틀링을 HTTP 400 응답의 Throttling 코드와 Rate exceeded 메시지로 설명합니다. 400이라는 숫자만 보고 모든 오류에 재시도를 붙이면, 잘못된 입력이나 충돌 같은 다른 문제까지 다시 보내게 됩니다. 자동화가 남기는 API 동작 이름, 오류 코드, 시각을 같은 행에 놓아야 구별이 됩니다.

두 번째는 작업 규모입니다. 호출 건수뿐 아니라 배치 안의 생성·삭제·갱신이 각각 몇 건인지 적어 보세요. 로그에 모든 레코드 값을 남길 필요는 없습니다. 업무상 공개하기 어려운 도메인이나 내부 주소 대신 계정과 작업을 구분할 수 있는 내부 별칭, 개수, 오류 코드만으로 시작할 수 있습니다. 다른 팀의 작업과 겹쳤는지 볼 때도 같은 시간 기준을 사용하는 것이 좋습니다.

세 번째는 결과 확인입니다. 일부 요청이 제한되었을 때, 처음부터 전체 작업을 다시 보내기 전에 어느 묶음이 받아들여졌는지 확인하는 절차를 정해 두세요. 배포 도구가 재시도했고 작업자도 같은 배포를 다시 누를 수 있다면, 각각이 보낸 묶음과 관찰한 상태를 분리합니다. 가상의 사례에서 이미 만든 레코드를 다시 만들도록 요구하면, 원래의 제한 오류와 별개로 요청 자체에 문제가 생길 수 있습니다.

AWS는 제한 응답에 지수 백오프와 지터를 안내합니다. 백오프는 다시 보내는 간격을 늘리는 방식이고, 지터는 여러 작업이 동시에 깨어나 같은 순간에 다시 몰리지 않도록 작은 무작위 차이를 두는 방식입니다. SDK의 자동 재시도와 호출 코드의 별도 재시도가 모두 있다면 둘을 합친 대기 시간과 시도 횟수도 확인하세요. 백오프는 짧은 몰림을 흡수하는 데 쓰는 방법입니다. 계속 한도를 넘는 속도로 제출한다면 입력 속도부터 조정할 문제입니다.

다음 배포에서 먼저 비교할 것

호출 쪽을 많이 쓰는 작업이라면, 읽기와 쓰기를 구분하고 불필요한 반복 조회나 겹친 작업부터 찾으세요. 변경량이 큰 작업이라면 같은 계정에서 두 배포가 동시에 밀어 넣는지, 변경을 일정 시간에 나누어 보낼 수 있는지 검토합니다. 두 상황에 모두 ‘배치를 크게 하자’라는 결론을 붙일 필요는 없습니다. 어떤 제약을 줄이려는지 이름을 붙이면 변경 뒤에 확인할 지표도 자연스럽게 정해집니다.

실제 운영에서는 기존 DNS 값과 배포 계획, 되돌릴 기준을 승인된 방식으로 보존하세요. 진행 중인 작업이 어디까지 반영됐는지 모르는 상태에서 반대 변경을 전부 넣는 것도 새 작업입니다. 복구 역시 API와 변경량을 사용하고 운영 주소에 영향을 줄 수 있습니다. 이 글에서 제안하는 첫 단계는 설정값을 즉시 수정하는 일이 아니라, 현재 작업에서 두 단위를 별도로 기록하고 병렬 실행이 있는지 확인하는 것입니다.

자주 나오는 질문

초당 10회를 넘지 않으면 제한 오류는 없어지나요? 계정 전체 호출 기본값만 만족한다는 뜻입니다. 특정 동작의 호출 제한과 변경량을 따로 보세요. 측정도 배포 도구 한 개가 아니라 같은 계정에 요청을 보내는 실제 범위를 기준으로 해야 합니다.

배치 하나가 실패하면 무조건 다시 보내면 되나요? 먼저 오류 코드와 제출 상태를 확인해야 합니다. 스로틀링과 요청 자체의 오류는 다른 대응이 필요합니다. 같은 이름의 AWS 제한이라도 서비스마다 의미가 달라요. Lambda 비동기 재시도의 오류와 스로틀링 비교는 함수 실행 큐를 다룬 글이므로 그 기본 동작을 DNS API에 그대로 적용하지 않습니다.

초당 100은 DNS 응답이나 전파가 끝나는 속도인가요? 공식 문서에서 다루는 것은 API가 제출받는 변경량 한도입니다. 레코드 조회가 언제 새 값을 보이는지, 해당 변경 작업이 언제 끝나는지는 별도의 확인 대상입니다. 배포 기록에 제출과 최종 확인을 나누어 남기세요.

확인한 공식 자료

2026년 11월 9일 11월 3일 AWS 운영 해설, Route 53 API 제한 개발자 문서, Route 53 할당량을 확인했습니다. 실제 계정의 변경량과 배포 시간, 지원 승인 여부는 이 글에서 측정하거나 보장하지 않습니다.

호출 수와 변경량을 나누고 응답과 다음 배포를 확인하는 자체 개념도입니다.