SW BBANG K

간단한 HTML/CSS 포트폴리오나 랜딩 페이지를 만들었는데, 서버 없이 배포할 방법을 찾고 있다면 S3 정적 웹사이트 호스팅이 가장 현실적인 선택이다. EC2 인스턴스를 띄울 필요도 없고, Nginx 설정을 건드릴 필요도 없다. S3 버킷 하나로 수백만 요청을 처리할 수 있다. TL;DR — S3 정적 웹사이트 호스팅 핵심 요약 단계 작업 주의사항 1 S3 버킷 생성 (퍼블릭 액세스 차단 해제) 버킷 이름은 변경 불가 2 정적 웹사이트 호스팅 활성화 인덱스/에러 문서 지정 필수 3 버킷 정책으로 퍼블릭 읽기 허용 ACL 방식은 권장하지 않음 4 파일 업로드 Content-Type 자동 감지 확인 5 S3 웹사이트 엔드포인트로 접근 HTTPS는 CloudFront 필요 S3 정적 웹사이트 호스팅의 동작 원리 S3에는 두 가지 엔드포인트가 존재한다. 하나는 REST API 엔드포인트( s3.amazonaws.com ), 다른 하나는 웹사이트 엔드포인트( s3-website-{region}.amazonaws.com )다. 정적 웹사이트 호스팅을 활성화하면 웹사이트 엔드포인트가 활성화되고, 이 엔드포인트는 HTTP GET 요청에 대해 인덱스 문서를 반환하거나 404 시 커스텀 에러 페이지를 반환하는 웹 서버처럼 동작한다. REST 엔드포인트와 웹사이트 엔드포인트의 결정적 차이는 루트 경로 처리 방식이다. REST 엔드포인트에서 / 를 요청하면 버킷 목록 XML이 반환되거나 403이 뜬다. 웹사이트 엔드포인트는 설정된 인덱스 문서( index.html )를 자동으로 반환한다. 중요한 제약이 하나 있다. S3 웹사이트 엔드포인트는 HTTP만 지원한다. HTTPS가 필요하다면 CloudFront를 앞단에 배치해야 한다. 이 포스트에서는 S3 단독 설정에 집중하고, CloudFront 연동은 별도로 다룬...

EC2 인스턴스를 중지했는데 재시작하니 데이터가 사라졌다는 제보가 팀 슬랙에 올라오는 순간, 모두가 멈춘다. 실제로 EC2 인스턴스 중지와 종료의 차이 를 정확히 이해하지 못한 채 비용 절감을 위해 인스턴스를 껐다가 데이터를 잃는 사고는 생각보다 자주 발생한다. Stop과 Terminate는 콘솔에서 불과 몇 픽셀 차이지만, 결과는 완전히 다르다. TL;DR — EC2 중지 vs 종료 핵심 비교 항목 Stop (중지) Terminate (종료) 인스턴스 상태 stopped → 재시작 가능 shutting-down → terminated (영구) 루트 EBS 볼륨 기본 유지 기본 삭제 (DeleteOnTermination=true) 추가 EBS 볼륨 유지 기본 유지 (DeleteOnTermination=false) 인스턴스 스토어 데이터 소멸 데이터 소멸 퍼블릭 IP (동적) 중지 시 반환, 재시작 시 새 IP 할당 즉시 반환 Elastic IP 유지 (연결 상태 유지) 연결 해제 (IP 자체는 계정에 남음) 과금 인스턴스 요금 없음, EBS 요금 발생 인스턴스 요금 없음, 잔존 EBS 요금 발생 복구 가능성 가능 불가능 EC2 인스턴스 중지와 종료의 동작 원리 Stop과 Terminate를 단순히 '켜고 끄는 것'으로 이해하면 반드시 사고가 난...

신규 개발자가 입사할 때마다 S3, CodeCommit, CloudWatch 정책을 한 명씩 붙이다 보면, 어느 순간 누군가의 계정에만 정책이 빠져 있거나 퇴사자 계정에 권한이 남아 있는 상황을 마주하게 된다. IAM 그룹은 이 문제를 구조적으로 해결하는 가장 기본적인 수단이다. TL;DR: IAM 그룹 vs 사용자 직접 연결 기준 사용자 직접 연결 IAM 그룹 연결 신규 사용자 온보딩 정책을 매번 수동 연결 그룹 추가만으로 완료 권한 변경 사용자 수만큼 반복 작업 그룹 정책 1회 수정으로 전파 퇴사자 처리 각 정책을 개별 분리 그룹 멤버십 제거로 권한 회수 감사(Audit) 사용자별 정책 목록 확인 필요 그룹 단위로 권한 범위 파악 가능 실수 가능성 높음 (누락, 중복 발생) 낮음 (그룹 정책이 단일 진실 공급원) IAM 그룹이 작동하는 방식 IAM 그룹은 사용자의 컨테이너다. 그룹 자체는 자격 증명이 아니므로 로그인하거나 임시 자격 증명을 발급받을 수 없다. 그룹에 연결된 정책은 그룹의 모든 멤버에게 적용된다. 사용자가 여러 그룹에 속하면 각 그룹의 정책이 합산되어 평가된다. 한 사용자에게 직접 연결된 정책과 그룹을 통해 상속된 정책은 IAM 평가 엔진에서 동일하게 처리된다. 단, Explicit Deny는 어떤 경로로 Allow가 부여되었든 항상 우선한다. graph LR G["Developers 그룹 정책 연결 지점"] --> P1["AmazonS3ReadOnlyAccess"] G --> P2["CloudWatchReadOnlyAccess"] U1["alice"] --> G U2["bob"] --> G U3["신규 사용자 추가 ...

SES로 내 계정 이메일로는 잘 보내지는데, 실제 고객 이메일 주소로는 전송이 안 된다. 처음 SES를 설정할 때 가장 많이 마주치는 상황이다. 원인은 단순하다 — AWS SES는 모든 신규 계정을 기본적으로 샌드박스(Sandbox) 모드 로 시작하며, 이 상태에서는 발신과 수신 모두 사전 검증된 이메일 주소로만 제한된다. TL;DR — SES 샌드박스 모드 핵심 요약 항목 샌드박스 모드 프로덕션 모드 수신자 제한 검증된 이메일/도메인만 가능 임의의 수신자 가능 일일 발송 한도 200건/일, 1건/초 요청에 따라 증가 가능 발신자 주소 검증된 이메일/도메인만 가능 검증된 이메일/도메인만 가능 바운스/컴플레인 처리 시뮬레이터로 테스트 가능 실제 피드백 루프 필요 전환 방법 — AWS Support 케이스 제출 정확한 한도 수치는 AWS 공식 문서에서 확인하라. 리전별, 계정별로 다를 수 있다. SES 샌드박스 모드가 작동하는 방식 AWS가 샌드박스를 두는 이유는 명확하다. 이메일 인프라는 스팸 발송자들이 가장 먼저 노리는 대상이고, 새로 생성된 AWS 계정에서 대량 스팸이 발송되면 SES 전체의 IP 평판이 훼손된다. 샌드박스는 그 방어선이다. 샌드박스 상태에서 SES가 이메일을 수락하는 조건은 두 가지다. 발신자 주소(From)가 SES에 검증된 이메일 또는 도메인이어야 하고, 수신자 주소(To) 역시 검증된 이메일 또는 도메인에 속해야 한다. 두 조건 중 하나라도 어긋나면 SES는 메시지 전송을 거부한다. graph TD A["이메일 발송 요청"] --> B{"발신자 주소 검증 여부"} B -- "미검증" --> C["SES 거부 (발신자 오류)"] B -- "검증됨...

처음 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...