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를 단순히 '켜고 끄는 것'으로 이해하면 반드시 사고가 난...

프로덕션 RDS 인스턴스의 CPU가 SELECT 쿼리 때문에 80%를 넘어서는 순간, 대부분의 엔지니어는 인스턴스를 스케일업하거나 캐시 레이어를 먼저 떠올린다. 하지만 읽기 부하가 명확히 분리 가능한 구조라면, RDS 읽기 전용 복제본(Read Replica)이 가장 직접적인 해결책이다. 문제는 Read Replica와 Multi-AZ를 혼동해서 잘못된 선택을 하는 경우가 생각보다 많다는 점이다. TL;DR — Read Replica vs. Multi-AZ 핵심 비교 항목 Read Replica Multi-AZ 주목적 읽기 부하 분산 (성능) 자동 장애 조치 (가용성) 복제 방식 비동기 복제 동기 복제 엔드포인트 별도 엔드포인트 제공 단일 엔드포인트 (자동 전환) 읽기 트래픽 수신 가능 (직접 연결) 불가 (Standby는 읽기 불가) 독립 승격 가능 (독립 DB로 승격) 자동 장애 조치만 지원 리전 간 배포 가능 (Cross-Region) 단일 리전 내 다중 AZ 비용 구조 Replica 인스턴스 비용 추가 Standby 인스턴스 비용 추가 RDS 읽기 전용 복제본이 동작하는 방식 Read Replica는 소스 DB 인스턴스의 변경 사항을 비동기적으로 수신한다. MySQL과 MariaDB는 바이너리 로그(binlog) 기반 복제를 사용하고, PostgreSQL은 물리적 복제 슬롯(WAL 스트리밍)을 사용한다. 이 비동기 특성 때문에 Replica에는 항상 약간의 복제 지연(replication lag)이 존재할 수 있다 — 최신 데이터가 반드시 필요한 쿼리에는 적합하지 않다. 애플리케이션은 소스 인스턴스의 엔드포인트와 별개로 Replica 전용 엔드포인트에 직접 연결해야 한다. RDS가 자동으로 쿼리를 라우팅해주지 않는다. 읽기/쓰기 분리는 애플리케이션 레벨 또는 프록시 레...

VPC 트래픽 제어를 처음 설계할 때 가장 흔히 겪는 혼란이 있다. Security Group과 Network ACL 둘 다 '방화벽'처럼 동작하는데, 왜 인바운드 규칙만 열었는데 어떤 건 통신이 되고 어떤 건 안 되는지 — 이 차이를 모르면 프로덕션에서 반드시 한 번은 삽질한다. TL;DR — Security Group vs Network ACL 핵심 비교 항목 Security Group Network ACL (NACL) 적용 계층 인스턴스(ENI) 레벨 서브넷 레벨 상태 저장 여부 Stateful (응답 트래픽 자동 허용) Stateless (인바운드·아웃바운드 별도 규칙 필요) 규칙 평가 방식 모든 규칙을 평가 후 허용 여부 결정 번호 순서대로 평가, 첫 매칭 규칙 적용 기본 동작 모든 인바운드 거부, 모든 아웃바운드 허용 모든 인바운드·아웃바운드 허용 (기본 NACL 기준) Allow/Deny 규칙 Allow 규칙만 지원 Allow 및 Deny 규칙 모두 지원 연결 대상 ENI에 직접 연결 (인스턴스당 복수 적용 가능) 서브넷에 연결 (서브넷당 하나의 NACL) Security Group과 Network ACL의 동작 원리 두 서비스 모두 VPC 내 트래픽을 필터링하지만, 동작하는 위치와 방식이 근본적으로 다르다. Security Group은 ENI(Elastic Network Interface)에 연결되어 인스턴스 단위로 동작하고, NACL은 ...

연간 감사(Audit)를 위해 딱 한 번만 꺼내볼 데이터를 S3 Standard에 그대로 두고 있다면, 매달 필요 이상의 비용을 지불하고 있는 것이다. S3 Glacier 계열 스토리지 클래스는 이런 장기 보관 시나리오를 위해 설계되었지만, 세 가지 Glacier 티어 중 어떤 것을 선택하느냐에 따라 복원 속도, 비용 구조, 운영 복잡도가 크게 달라진다. TL;DR — S3 Glacier 스토리지 클래스 비교 스토리지 클래스 최소 보관 기간 복원 소요 시간 주요 사용 사례 S3 Glacier Instant Retrieval 90일 밀리초 분기 1회 이하 접근, 즉시 복원 필요 S3 Glacier Flexible Retrieval 90일 1분~12시간 연 1~2회 접근, 수 시간 내 복원 허용 S3 Glacier Deep Archive 180일 12시간~48시간 연 1회 이하 접근, 최저 스토리지 단가 결론부터: 연 1회 감사 목적이라면 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 가 최적 후보다. 복원 시점을 며칠 전에 예측할 수 있다면 Deep Archive가 스토리지 단가 측면에서 가장 저렴하다. 당일 복원이 필요하다면 Flexible Retrieval의 Bulk 또는 Standard 검색 옵션을 사용한다. S3 Glacier가 동작하는 방식 — 복원 메커니즘 이해 Glacier 계열 클래스에 저장된 객체는 즉시 읽을 수 없다. 복원(Restore) 요청을 제출하면 AWS가 내부적으로 객체를 준비하고, 지정한 보관 기간(days) 동안 S3 Standard 계층에 임시 사본 을 생성한다. 애플리케이션은 이 임시 사본을 통해 데이터에 접근한다. 임시 사본의 보관 기간이 만료되면 자동으로 삭제되며, 원본 Glacier 객체는 그대로 유지된다. 이 구...

Lambda 함수를 매일 오전 8시에 실행해야 하는데, 처음에는 단순해 보였다. 그런데 막상 EventBridge 콘솔을 열면 Cron 문법이 일반적인 Unix Cron과 미묘하게 달라서 첫 번째 규칙을 잘못 설정하는 경우가 많다. 이 글은 EventBridge Cron 표현식으로 Lambda를 스케줄링 하는 전체 과정을 다루고, 실수하기 쉬운 타임존 문제와 권한 설정까지 정확하게 짚는다. TL;DR — EventBridge Lambda 스케줄링 핵심 요약 항목 내용 스케줄 방식 Rate 표현식 또는 Cron 표현식 매일 오전 8시 (UTC) Cron cron(0 8 * * ? *) EventBridge 기본 타임존 UTC (변경 불가, Scheduler는 타임존 지정 가능) 필수 IAM 권한 EventBridge → Lambda 호출용 리소스 기반 정책 필요 한국 시간 오전 8시 UTC 환산 전날 오후 11시 UTC → cron(0 23 * * ? *) 타임존 지정이 필요하면 EventBridge Scheduler 사용 권장 EventBridge 스케줄링이 동작하는 방식 EventBridge에는 두 가지 스케줄링 메커니즘이 있다. 하나는 EventBridge Rules (규칙 기반 스케줄) 이고, 다른 하나는 2022년 말에 출시된 EventBridge Scheduler 다. 이 둘은 같은 서비스처럼 보이지만 동작 모델이 다르다. graph LR A["EventBridge Rules (Schedule)"] -->|"직접 타겟 호출"| B["Lambda 함수"] C["EventBridge Scheduler"] -->|"실행 역할(IAM Role) 사용"| B A...

S3에 수백만 개의 로그 파일이 쌓여 있는데, 이걸 분석하려면 RDS나 Redshift에 적재해야 한다고 생각했다면 — 그 가정이 틀렸다. Amazon Athena는 S3에 저장된 파일을 그대로 두고 SQL로 직접 쿼리하는 서버리스 쿼리 엔진이다. 데이터 이동 없이, 별도 DB 프로비저닝 없이, 스캔한 데이터 양만큼만 비용을 낸다. TL;DR — S3 로그를 Athena로 쿼리하는 핵심 요약 단계 작업 핵심 포인트 1 S3 버킷 및 로그 구조 확인 파티션 키 설계가 쿼리 비용 직결 2 Glue Data Catalog에 테이블 정의 SerDe 선택이 파싱 성패를 결정 3 Athena 쿼리 결과 버킷 설정 결과 저장 위치 없으면 쿼리 실행 불가 4 파티션 등록 MSCK REPAIR 또는 파티션 프로젝션 사용 5 SQL 쿼리 실행 WHERE 절에 파티션 컬럼 반드시 포함 6 비용 최적화 Parquet 변환 + 압축으로 스캔 비용 절감 Athena가 S3 로그를 쿼리하는 방식 Athena는 Apache Hive 메타스토어 호환 카탈로그(AWS Glue Data Catalog)에 테이블 스키마와 S3 위치를 등록해 둔다. 쿼리를 실행하면 Athena가 카탈로그에서 해당 테이블의 S3 경로를 조회하고, 분산 쿼리 엔진(Presto/Trino 기반)이 S3에서 직접 파일을 읽어 처리한다. 데이터는 S3에 그대로 있고, Athena는 스캔만 한다. graph LR User["사용자 / 애플리케이션"] -->|"SQL 제출"| Athena["Amazon Athena (Presto/Trino 엔진)"] Athena -->|"스키마 및 S3 경로 조회"| Glue["Glue Data Catalog...