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

ALB를 새로 프로비저닝하고 도메인을 연결하려는 순간, 대부분의 엔지니어는 CNAME 레코드를 먼저 떠올린다. 그런데 example.com 자체(zone apex)를 ALB에 연결하려는 순간 CNAME은 동작하지 않는다 — DNS 표준이 이를 금지하기 때문이다. Route 53 Alias 레코드는 이 문제를 해결하기 위해 설계된 AWS 전용 확장이며, 단순한 편의 기능이 아니라 운영 비용과 장애 내성에 직접 영향을 미친다. TL;DR — Route 53 Alias vs CNAME 핵심 비교 항목 CNAME Route 53 Alias Zone Apex 사용 가능 여부 ❌ 불가 (RFC 1912) ✅ 가능 쿼리 과금 쿼리당 과금 AWS 리소스 대상 시 무료 DNS 응답 내용 CNAME 체인 반환 A/AAAA 레코드로 직접 응답 대상 리소스 상태 연동 없음 ALB 등 AWS 리소스와 연동 TTL 설정 직접 설정 Route 53이 자동 관리 사용 가능 대상 임의 호스트명 AWS 리소스 한정 DNS 동작 원리: CNAME 체인과 Alias 플래팅 CNAME 레코드는 한 호스트명을 다른 호스트명으로 위임한다. 클라이언트가 www.example.com 을 조회하면 리졸버는 CNAME 대상인 ALB의 DNS 이름을 다시 조회해야 한다. 이 추가 조회가 CNAME 체인이다. Zone apex( example.com )에 CNAME을 설정할 수 없는 이유는 RFC 1912에 명시되어 있다 — zone apex에는 SOA, NS 레코드가 반드시 공존해야 하는데, CNAME은 같은 이름에 다른 레코드가 존재하는 것을 허용하지 않는다. Route 53 Alias 레코드는 DNS 표준 레코드 타입이 아니다. Route 53 네임서버 내부에서 처리되는 확장으로, 쿼리 시점에 대상 리소스의 현재 IP 주소를 조...

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다. 요약 — 한눈에 보는 진단 단계 단계 확인할 사항 일반적인 해결 방법 1 보안 그룹(Security Group) 인바운드 규칙 사용자 IP로부터의 SSH (TCP 22) 추가 2 서브넷 라우팅 테이블(Route table) 0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인 3 네트워크 ACL(Network ACL) 규칙 인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용 4 인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP) 퍼블릭 IP가 할당되었는지 확인 5 키 페어(Key pair) 및 SSH 사용자 이름 올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용 SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유 연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다. blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서...