SW BBANG K

처음 IAM 정책 JSON을 열어봤을 때, 왜 이 권한이 작동하는지 혹은 왜 막히는지 파악하지 못해서 한참을 헤맨 경험이 있을 것이다. IAM 정책 구조 의 네 가지 핵심 요소 — Effect , Action , Resource , Condition — 를 정확히 이해하지 못하면, 권한 오류는 항상 예상치 못한 곳에서 터진다. TL;DR — IAM 정책 핵심 요소 비교 요소 역할 필수 여부 핵심 주의사항 Effect Allow 또는 Deny 결정 필수 Explicit Deny는 모든 Allow를 재정의 Action 허용/거부할 API 작업 지정 필수 서비스 네임스페이스:작업명 형식 필수 Resource 정책이 적용될 AWS 리소스 범위 필수 일부 작업은 * 만 허용 Condition 정책 적용 조건 (선택적 필터) 선택 조건 키는 서비스별로 지원 범위가 다름 IAM 정책이 평가되는 방식 IAM 정책은 단순한 허용 목록이 아니다. AWS는 요청이 들어올 때마다 해당 요청에 적용되는 모든 정책을 수집하고, 정해진 평가 로직에 따라 최종 Allow/Deny를 결정한다. 이 평가 순서를 모르면 왜 권한이 막히는지 절대 파악할 수 없다. graph TD A["API 요청 수신"] --> B{"Explicit Deny 존재 여부"} B -- "Yes" --> C["즉시 거부 (Deny)"] B -- "No...

SQS 큐에서 메시지가 두 개의 컨슈머에 의해 동시에 처리되는 현상을 프로덕션에서 처음 마주치면, 대부분 애플리케이션 코드나 멱등성 로직을 먼저 의심한다. 하지만 실제 원인은 대부분 더 단순한 곳에 있다 — Visibility Timeout 이 처리 시간보다 짧게 설정되어 있는 것이다. 이 설정 하나가 SQS 중복 처리 문제의 가장 흔한 원인이다. TL;DR — SQS Visibility Timeout 핵심 요약 항목 내용 Visibility Timeout 역할 메시지를 수신한 후 다른 컨슈머에게 보이지 않도록 숨기는 시간 기본값 30초 설정 범위 0초 ~ 12시간 중복 처리 발생 조건 처리 시간 > Visibility Timeout 권장 설정 최대 처리 시간의 6배 이상 (AWS 권장) 런타임 연장 방법 ChangeMessageVisibility API 호출 삭제 타이밍 처리 완료 후 반드시 DeleteMessage 호출 SQS Visibility Timeout 동작 원리 SQS는 메시지 브로커가 아니라 분산 큐다. 컨슈머가 메시지를 ReceiveMessage 로 가져가도 메시지는 큐에서 즉시 삭제되지 않는다. 대신 Visibility Timeout 동안 다른 컨슈머에게 보이지 않는 상태(invisible)로 전환된다. 컨슈머가 처리를 완료하고 DeleteMessage 를 호출해야 비로소 큐에서 제거된다. Visibility Timeout이 만료되기 전에 DeleteMessage 가 호출되지 않으면, SQS는 해당 메시지를 다시 visible 상태로 되돌린다. 이 순간 다른 컨슈머(또는 동일 컨슈머의 다른 인스턴스)가 동일 메시지를 다시 수신할 수 있게 된다. 이것이 중복 처리의 정확한 메커니즘이다. sequenceDiagram participant Q a...