SW BBANG K

EC2 인스턴스를 중지(Stop)했는데 다음 날 청구서를 확인하니 Elastic IP 요금이 그대로 붙어 있다. 인스턴스를 껐으니 당연히 IP도 멈출 거라 생각했지만, AWS는 그렇게 동작하지 않는다. Elastic IP 요금 청구 구조를 정확히 이해하지 못하면 아무것도 실행되지 않는 인스턴스에 매달 예상치 못한 비용이 쌓인다. TL;DR — Elastic IP 요금 청구 핵심 정리 상태 요금 발생 여부 이유 실행 중 인스턴스에 연결됨 ❌ 무료 정상 사용 중 중지된 인스턴스에 연결됨 ✅ 요금 발생 IP가 유휴 상태로 낭비됨 어떤 인스턴스에도 연결 안 됨 (미연결) ✅ 요금 발생 IP가 유휴 상태로 낭비됨 연결 해제(Disassociate) 후 릴리스(Release) 완료 ❌ 무료 IP가 AWS 풀로 반환됨 결론: 요금을 완전히 멈추려면 Disassociate(연결 해제) 와 Release(릴리스) 를 모두 수행해야 한다. Disassociate만 하면 IP가 계정에 남아 있어 여전히 과금된다. Elastic IP 요금 구조가 작동하는 방식 AWS가 Elastic IP에 요금을 부과하는 핵심 원칙은 단순하다. 퍼블릭 IPv4 주소는 희소 자원 이며, AWS는 계정이 해당 IP를 실제로 사용하지 않으면서 점유하고 있을 때 요금을 청구한다. '사용 중'의 정의는 실행 상태(running)의 인스턴스 또는 NAT 게이트웨이에 연결되어 있을 때 다. 인스턴스를 중지하면 그 인스턴스에 연결된 Elastic IP는 즉시 '유휴(idle)' 상태가 된다. AWS 입장에서는 이 IP를 다른 고객에게 할당할 수 없는데 계정이 붙잡고 있는 것이므로, 시간당 요금이 발생한다. 요금과 정확한 조건은 변동될 수 있으므로 항상 공식 AWS EC2 요금 페이지 에서 확인해야 한다. stateD...

EC2 인스턴스를 운영하다 보면 CloudWatch 콘솔에서 CPU는 보이는데 메모리가 없다는 걸 처음 마주치는 순간이 있다. 알람을 걸려고 했더니 지표 자체가 없고, 인스턴스가 OOM으로 죽었는데 CloudWatch에는 아무 흔적이 없다. EC2 메모리 사용률 은 기본 CloudWatch 지표에 포함되지 않으며, 이를 수집하려면 CloudWatch Agent를 직접 설치해야 한다. TL;DR — EC2 메모리 모니터링 핵심 요약 항목 기본 CloudWatch CloudWatch Agent 설치 후 CPU 사용률 ✅ 자동 수집 ✅ 자동 수집 네트워크 I/O ✅ 자동 수집 ✅ 자동 수집 디스크 I/O (EBS 바이트) ✅ 자동 수집 ✅ 자동 수집 메모리 사용률 (RAM) ❌ 수집 불가 ✅ 수집 가능 디스크 공간 사용률 (파일시스템) ❌ 수집 불가 ✅ 수집 가능 프로세스별 메모리 ❌ 수집 불가 ✅ 수집 가능 (procstat 플러그인) 왜 EC2 메모리 사용률은 기본으로 보이지 않는가 CloudWatch가 기본으로 수집하는 지표는 AWS 하이퍼바이저 계층에서 관측 가능한 것들이다. CPU 사이클, 네트워크 패킷, EBS I/O 바이트 — 이것들은 인스턴스 외부에서 측정할 수 있다. 반면 OS 내부의 메모리 할당 상태, 파일시스템 사용량, 프로세스 목록은 게스트 OS 안에서만 볼 수 있다. AWS는 EC2 인스턴스 내부 OS에 직접 접근하지 않는다. 이건 보안 모델의 일부이기도 하고, 공유 책임 모델(Shared Responsibility Model)의 경계이기도 하다. 게스트 OS 레이어는 고객 책임 영역이고, AWS는 그 안을 들여다보지 않는다. 결과적으로 메모리 사용률을 수집하려면 인스턴스 안에서 직접 데이터를 밀어내는 에이전트가 필요하다. EBS 디스크 I/O 바이트는 하이퍼바이...

RDS 스냅샷 복원을 처음 시도하는 엔지니어들이 가장 많이 하는 실수가 있다. '복원하면 기존 DB가 덮어써지겠지'라고 가정하고 애플리케이션 설정을 그대로 두는 것이다. 실제로는 RDS 스냅샷 복원은 항상 새로운 DB 인스턴스를 생성 하며, 엔드포인트도 완전히 달라진다. 이 동작을 모르면 복원 후 애플리케이션이 여전히 구 인스턴스(또는 없는 인스턴스)에 연결을 시도하는 상황이 발생한다. TL;DR — RDS 스냅샷 복원 핵심 요약 항목 동작 기존 인스턴스 덮어쓰기 여부 ❌ 덮어쓰지 않음. 항상 신규 인스턴스 생성 엔드포인트 변경 여부 ✅ 새 인스턴스 식별자 기반의 새 엔드포인트 생성 기존 인스턴스 상태 복원 후에도 기존 인스턴스는 그대로 유지됨 파라미터 그룹 / 보안 그룹 기본값으로 초기화됨 — 수동 재적용 필요 애플리케이션 연결 문자열 새 엔드포인트로 업데이트 필요 Multi-AZ / 스토리지 설정 스냅샷에서 복원되지 않음 — 복원 시 재지정 필요 RDS 스냅샷 복원 동작 원리 RDS 스냅샷은 특정 시점의 스토리지 볼륨 전체를 캡처한 것이다. 복원 명령을 실행하면 AWS는 해당 스냅샷 데이터를 기반으로 완전히 독립된 새 DB 인스턴스를 프로비저닝한다. 기존 인스턴스의 데이터를 교체하거나 덮어쓰는 개념이 아니다. 새 인스턴스는 복원 시 지정한 --db-instance-identifier 값을 기반으로 고유한 DNS 엔드포인트를 갖는다. 기존 인스턴스와 신규 인스턴스는 복원 직후 동시에 존재하며, 각자 독립적인 엔드포인트를 가진다. ...

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

프라이빗 S3 버킷에 저장된 파일을 외부 사용자에게 일시적으로 공개해야 할 때, 버킷 정책을 건드리거나 퍼블릭 ACL을 열지 않고도 해결하는 방법이 바로 Presigned URL이다. 실제 운영 환경에서는 '이 파일 한 번만 다운로드할 수 있게 해줘'라는 요구가 생각보다 자주 온다 — 계약서 전달, 리포트 공유, 미디어 파일 배포 등. S3 Presigned URL은 서버 측에서 서명된 임시 접근 토큰을 URL에 포함시켜, 지정된 만료 시간 내에만 해당 객체에 접근할 수 있도록 제어한다. TL;DR — S3 Presigned URL 핵심 요약 항목 내용 목적 IAM 자격증명 없이 특정 S3 객체에 임시 접근 허용 서명 방식 SigV4 (AWS Signature Version 4) 기본 만료 범위 최소 1초 ~ 최대 7일 (IAM 역할 기반 서명 시 최대 12시간) SDK 메서드 Python: generate_presigned_url / JS: getSignedUrl (v2), getSignedUrl from @aws-sdk/s3-request-presigner (v3) 주요 주의사항 서명에 사용된 자격증명이 만료되면 URL도 즉시 무효화됨 S3 Presigned URL 동작 원리 Presigned URL은 S3 서비스가 생성하는 것이 아니다. SDK를 실행하는 서버(혹은 Lambda)가 로컬에서 서명을 계산해 URL에 포함 시킨다. S3는 요청이 들어왔을 때 URL에 포함된 서명 파라미터를 검증할 뿐이다. 이 차이가 중요한 이유는 — 서명을 생성한 자격증명(IAM 사용자 또는 역할)이 비활성화되거나 만료되면, URL 자체의 만료 시간이 남아 있어도 요청이 거부된다. sequenceDiagram participant App as 애플리케이션 서버 parti...

서버 내부에서 실행 중인 스크립트가 자신이 어느 인스턴스인지 알아야 할 때가 있다. 로그에 인스턴스 ID를 찍거나, 태그를 조회하거나, Auto Scaling 그룹에서 자기 자신을 식별해야 할 때 — 이 시나리오에서 EC2 인스턴스 메타데이터 서비스(IMDS)가 유일한 현실적 선택지다. 문제는 기본 설정 그대로 두면 SSRF 취약점 하나로 IAM 자격증명까지 탈취당할 수 있다는 점이다. TL;DR — IMDSv1 vs IMDSv2 핵심 비교 항목 IMDSv1 IMDSv2 인증 방식 없음 (단순 GET) 세션 토큰 (PUT → GET) SSRF 취약점 노출 높음 낮음 (토큰 발급에 PUT 필요) TTL 제어 불가 가능 (1초 ~ 21600초) 강제 적용 방법 해당 없음 HttpTokens=required 기본 엔드포인트 http://169.254.169.254 인스턴스 메타데이터 서비스(IMDS)가 동작하는 방식 IMDS는 인스턴스 내부에서만 접근 가능한 링크-로컬 HTTP 엔드포인트( 169.254.169.254 )다. 하이퍼바이저 계층에서 라우팅을 차단하기 때문에 인스턴스 외부에서는 원칙적으로 도달할 수 없다. 인스턴스 ID, AMI ID, IAM 역할 자격증명, 네트워크 인터페이스 정보 등 부트스트랩에 필요한 거의 모든 런타임 정보를 여기서 가져온다. IMDSv1은 단순 GET 요청만으로 모든 데이터를 반환한다. 애플리케이션에 SSRF(Server-Side Request Forgery) 취약점이 있으면 공격자는 그 취약점을 통해 http://169.254.169.254/latest/meta-data/iam/security-credentials/ 까지 도달해 임시 자격증명을 탈취할 수 있다. 실제로 2019년 Capital One 침해 사고의 핵심 경로가 이 패턴이었다. IMDSv2는 세션...