SW BBANG K

브라우저 주소창에 '주의 요함' 또는 'Not Secure' 경고가 뜨는 순간, 사용자 이탈은 시작된다. EC2 위에서 Nginx로 서비스를 운영 중인데 아직 HTTP만 열려 있다면, Let's Encrypt의 무료 SSL 인증서와 Certbot을 이용해 30분 안에 HTTPS를 완성할 수 있다. 이 글은 실제 운영 환경에서 겪는 함정 — 보안 그룹 누락, 도메인 검증 실패, 자동 갱신 설정 오류 — 까지 포함해 처음부터 끝까지 다룬다. TL;DR — EC2 HTTPS 설정 핵심 요약 단계 작업 주요 확인 포인트 1 보안 그룹에서 443 포트 개방 인바운드 규칙 HTTPS(443) 추가 2 도메인 A 레코드를 EC2 퍼블릭 IP로 연결 DNS 전파 확인 필수 3 Nginx 설치 및 서버 블록 구성 server_name에 실제 도메인 입력 4 Certbot 설치 및 인증서 발급 --nginx 플러그인 사용 5 자동 갱신 크론 또는 systemd 타이머 확인 certbot renew --dry-run 통과 여부 HTTPS 인증서 발급이 작동하는 방식 Let's Encrypt는 ACME(Automated Certificate Management Environment) 프로토콜로 도메인 소유권을 검증한다. Certbot의 --nginx 플러그인은 HTTP-01 챌린지를 사용하는데, 이 과정에서 Let's Encrypt 서버가 외부에서 http://<your-domain>/.well-known/acme-challenge/ 경로에 접근할 수 있어야 한다. 즉, EC2 보안 그룹의 80번 포트가 열려 있지 않으면 챌린지 자체가 실패한다 — 이게 가장 흔한 첫 번째 함정이다. sequenceDiagram participant CB a...

EC2 인스턴스를 며칠에 걸쳐 완벽하게 세팅했다. 패키지 설치, 환경 변수 설정, 애플리케이션 배포까지 끝냈는데, 이걸 그대로 복제하거나 Auto Scaling에 쓰려면 어떻게 해야 할까? Amazon Machine Image(AMI) 생성이 그 답이다. 이 글은 AMI의 동작 원리부터 실제 생성 절차, 운영 중 자주 마주치는 함정까지 다룬다. TL;DR — AMI 생성 핵심 요약 단계 핵심 내용 1. AMI 개념 이해 EBS 스냅샷 + 루트 디바이스 매핑 + 메타데이터의 조합 2. 인스턴스 준비 임시 파일 정리, 민감 정보 제거, 로그 초기화 3. AMI 생성 콘솔 또는 CLI로 create-image 실행 4. 상태 확인 describe-images 로 available 상태 대기 5. 검증 및 활용 테스트 인스턴스 실행 후 Launch Template 또는 Auto Scaling에 연결 AMI가 실제로 무엇인지 — 동작 원리 AMI를 '인스턴스 복사본'이라고 단순하게 생각하면 나중에 반드시 문제가 생긴다. 정확히는 EBS 스냅샷 집합 + 블록 디바이스 매핑 + 부팅 권한 메타데이터 로 구성된 리소스다. 인스턴스 자체를 저장하는 게 아니라, 그 인스턴스를 재현하는 데 필요한 청사진을 저장한다. EBS 기반 인스턴스(현재 대부분의 인스턴스 유형)에서 AMI를 생성하면 다음이 일어난다: 루트 볼륨과 추가 EBS 볼륨 각각에 대해 EBS 스냅샷이 생성된다. AMI는 이 스냅샷들을 참조하는 블록 디바이스 매핑을 포함한다. AMI를 이용해 새 인스턴스를 시작하면, 해당 스냅샷에서 새 EBS 볼륨이 생성되어 인스턴스에 연결된다. AMI를 삭제(deregister)해도 연결된 EBS 스냅샷은 자동으로 삭제되지 않는다. 스냅샷은 별도로 수동 삭제해야 한다. 이걸 모...

EC2 인스턴스를 새로 띄우고 나서 S3에 올려둔 설정 파일을 내려받으려는 순간, Unable to locate credentials 오류나 Access Denied 가 뜨면서 막히는 경험은 누구나 한 번쯤 겪는다. S3에서 EC2로 파일 복사 하는 작업은 명령어 자체는 단순하지만, IAM 인스턴스 프로파일이 제대로 붙어 있지 않으면 자격 증명 문제로 첫 단계부터 실패한다. TL;DR — 핵심 요약 항목 내용 복사 명령어 aws s3 cp s3://버킷명/경로/파일명 /로컬/경로/ 필수 IAM 액션 s3:GetObject (단일 파일), s3:ListBucket (경로 확인 시) 자격 증명 방식 EC2 인스턴스 프로파일 (IAM Role) — 권장 자격 증명 확인 aws sts get-caller-identity 가장 흔한 실패 원인 인스턴스 프로파일 미연결 또는 버킷 정책의 명시적 Deny 동작 원리: S3 파일 복사 흐름 aws s3 cp 는 내부적으로 S3 REST API의 GetObject 를 호출한다. EC2에서 이 호출이 성공하려면 두 가지 레이어가 모두 허용 상태여야 한다. 첫째는 IAM — 인스턴스에 연결된 Role이 해당 S3 액션을 허용해야 한다. 둘째는 S3 리소스 정책(버킷 정책) — 버킷 정책에 명시적 Deny가 있으면 IAM Allow를 덮어쓴다. sequenceDiagram participant CLI as AWS CLI (EC2 내부) participant IMDS as IMDS (169.254.169.254) participant STS as AWS STS participant S3 as Amazon S3 CLI->>IMDS: 임시 자격 증명 요청 IMDS->>STS: Role 기반 토큰 발...

EC2 인스턴스를 시작할 때 IAM Role 연결을 빠뜨리는 건 생각보다 자주 있는 실수다. 인스턴스가 이미 프로덕션 트래픽을 받고 있는 상황에서 재시작 없이 IAM Role을 붙일 수 있는지 확인하는 것이 급선무가 된다. 다행히 AWS는 실행 중인 EC2 인스턴스에 IAM Role을 연결하거나 교체하는 기능을 지원한다. TL;DR — IAM Role을 EC2에 연결하는 핵심 요약 상황 방법 재시작 필요 여부 IAM Role이 없는 인스턴스에 최초 연결 associate-iam-instance-profile 불필요 기존 IAM Role을 다른 Role로 교체 replace-iam-instance-profile-association 불필요 연결된 IAM Role 제거 disassociate-iam-instance-profile 불필요 IAM Role이 EC2에 연결되는 구조 이해 IAM Role을 EC2에 직접 붙이는 게 아니다. 중간에 Instance Profile 이라는 컨테이너가 존재한다. IAM Role을 생성하면 AWS 콘솔에서는 자동으로 동일한 이름의 Instance Profile이 함께 생성되지만, AWS CLI나 CloudFormation으로 Role을 만들면 Instance Profile은 별도로 생성해야 한다. EC2 인스턴스에 실제로 연결되는 것은 IAM Role이 아니라 Instance Profile이다. Instance Profile은 IAM Role을 EC2 인스턴스에 전달하는 봉투라고 생각하면 된다. 봉투(Instance Profile) 없이는 Role을 인스턴스에 넣을 수 없다. 인스턴스가 Role의 임시 자격증명을 얻는 경로는 EC2 메타데이터 서비스(IMDSv2)를 통해서다. 인스턴스 내부 애플리케이션이 http://169.254.169.254/latest/meta-data/...

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

새벽 2시에 온콜 알림이 울렸다. EC2 인스턴스가 응답을 멈췄는데, DNS가 여전히 죽은 서버를 가리키고 있어서 사용자들은 그냥 타임아웃 화면만 보고 있었다. Route 53 DNS 페일오버를 미리 구성해뒀다면, 헬스 체크가 실패하는 순간 트래픽이 S3 정적 백업 사이트로 자동 전환됐을 것이다. 이 글은 그 설정을 처음부터 끝까지 다룬다. TL;DR — Route 53 DNS 페일오버 핵심 요약 단계 구성 요소 역할 1 Route 53 헬스 체크 EC2 엔드포인트 상태를 주기적으로 확인 2 Primary 레코드 (Failover) EC2를 가리키며 헬스 체크와 연결 3 Secondary 레코드 (Failover) S3 정적 웹사이트 엔드포인트를 가리킴 4 S3 버킷 정적 웹사이트 호스팅 백업 페이지 서빙 5 자동 전환 헬스 체크 실패 시 Secondary로 DNS 응답 변경 Route 53 DNS 페일오버 동작 원리 Route 53의 페일오버 라우팅 정책은 Active-Passive 구조다. Primary 레코드에 헬스 체크를 연결해두면, Route 53 헬스 체커가 전 세계 여러 위치에서 해당 엔드포인트를 주기적으로 폴링한다. 헬스 체크가 임계값 이상 실패하면 Route 53은 해당 레코드를 'Unhealthy'로 표시하고, 동일한 이름과 타입을 가진 Secondary 레코드로 DNS 응답을 전환한다. 중요한 점은 이것이 DNS 레벨의 전환이라는 것이다. 기존 TCP 연결은 끊기지 않으며, TTL이 만료된 이후 새로운 DNS 조회부터 Secondary 주소를 받게 된다. 따라서 TTL 값 설정이 실제 전환 속도에 직접적인 영향을 준다. sequenceDiagram participant Client as 클라이언트 participant R53 as Route...

5개의 EC2 인스턴스가 동일한 디렉토리를 읽고 써야 하는 상황이 생겼다. 처음엔 EBS 볼륨 하나를 여러 인스턴스에 붙이면 되지 않을까 생각했는데, 실제로 해보려고 하면 콘솔에서 막히거나 데이터가 꼬이는 경험을 하게 된다. 이 글은 여러 EC2 인스턴스 간 스토리지 공유 문제를 EBS와 EFS 관점에서 실제 운영 경험 기반으로 정리한다. TL;DR — EBS vs EFS 핵심 비교 항목 EBS (일반 볼륨) EBS Multi-Attach EFS 동시 다중 인스턴스 마운트 ❌ 불가 ⚠️ 제한적 가능 ✅ 기본 지원 파일시스템 공유 ❌ ❌ (클러스터 파일시스템 필요) ✅ NFS v4.1/4.2 AZ 제약 동일 AZ만 동일 AZ만 리전 전체 (멀티 AZ) 일반적 공유 폴더 용도 ❌ ❌ ✅ 운영 복잡도 낮음 높음 낮음 결론부터: 5개 EC2 인스턴스가 동일 폴더를 공유하려면 EFS를 사용 해야 한다. EBS는 구조적으로 단일 인스턴스 전용 블록 스토리지이며, Multi-Attach는 공유 파일시스템을 제공하지 않는다. EBS와 EFS의 동작 원리 — 왜 EBS는 공유가 안 되는가 EBS는 블록 스토리지다. 인스턴스에 마운트되면 해당 OS가 파일시스템(ext4, xfs 등)을 직접 관리한다. 두 인스턴스가 동시에 같은 EBS 볼륨을 마운트하면, 각 OS가 독립적으로 파일시스템 메타데이터를 쓰게 되어 데이터 손상이 발생한다. 이건 AWS 제약이 아니...