요청 본문 한도 램프

Amplify Hosting compute 의 요청 본문 한도는 AWS 가 문서화하지 않는다. 두 배씩 올려 막히는 지점을 찾고 그 사이를 이분 탐색으로 좁힌다.

배포본 실측 — 2026-09-15

Content-Type	통과 최대	413 시작	이벤트에 실릴 때
`application/x-www-form-urlencoded`	4.498 MiB	4.498 MiB	5.997 MiB
`application/json`	5.997 MiB	5.997 MiB	5.997 MiB

오른쪽 열이 둘 다 6.000 MiB 바로 아래에 모인다. 진짜 한도는 Lambda 동기 호출 페이로드 6 MiB 하나이고, JSON 본문은 문자열로 그대로 실리는 반면 urlencoded 본문은 base64 로 4/3 배 부풀어 실린다. 그래서 폼 전송이 JSON 보다 1.5 MiB 손해다. 갈래 1 의 실제 연동은 새 탭을 여는 폼 전송이라 navigation 이어야 하고, navigation 은 JSON 본문을 보낼 수 없어 왼쪽 값이 상한이 된다. 초과하면 413 이 온다 — 조용히 잘리지 않아 호출부가 분기할 수 있다.

표본	행당	폼 전송 상한	4000행 여유
인사기본정보조회	518 B	9,108행	2.3배
세대차량 현황	396 B	11,914행	3.0배
민원일반	795 B	5,930행	1.5배
접수리스트	613 B	7,688행	1.9배
일별접수/처리현황	230 B	20,533행	5.1배

4000행은 다섯 표본 모두 통과한다. 가장 빡빡한 민원일반도 5,928행까지 가고 4000행 기준 1.5배 여유가 있다. 요청 본문은 갈래 1 의 병목이 아니다 — 병목은 응답 5.72MB 와 브라우저 조판 시간 쪽이다.

과녁본문만 읽고 바이트 수를 돌려준다. 응답이 작아 막히는 쪽이 요청이라고 확정된다Content-Type둘 다 재야 한다. 같은 데이터라도 urlencoded 본문이 JSON 의 두 배 가까이 되어 한도에 먼저 닿는다.

같은 오리진으로만 쏜다. 배포본을 재려면 배포된 주소의 /poc/limits 를 열거나 저장소의 scripts/probe-body-limit.sh 를 쓴다. 로컬 next start 에는 앞단이 없어 한도가 잡히지 않는다.