EC2를 중지했다가 시작한 뒤 접속 주소가 달라질 수 있는 이유는 공용 IP가 인스턴스의 영구 이름표가 아니기 때문이다. 외부 사용자가 서버 IP를 직접 기억하게 하는 설계는 교체와 장애 대응을 어렵게 만든다.
주소와 서비스 이름을 분리한다
사용자에게는 DNS 이름을 제공하고, DNS가 로드 밸런서나 현재 서비스 엔드포인트를 가리키게 하면 인스턴스를 교체해도 접속 주소를 유지하기 쉽다. 여러 인스턴스로 확장하는 서비스라면 한 인스턴스의 공용 IP를 진입점으로 쓰기보다 로드 밸런서를 고려한다.
예를 들어 테스트 인스턴스를 중지했다가 다시 켠 뒤 예전 IP로 접속되지 않는다면, 먼저 인스턴스에 현재 할당된 공용 주소와 DNS 레코드가 가리키는 값을 대조한다. 브라우저 캐시나 보안 그룹을 바꾸기 전에 두 주소가 같은지 확인하면 진단 범위가 좁아진다. 공용 주소가 없는 사설 인스턴스라면 직접 인터넷 접속을 전제로 하지 않는다.
주소가 바뀌면 어느 값을 비교할까?
자동 할당된 퍼블릭 IPv4로 접속하던 인스턴스를 중지했다가 다시 시작하는 경우를 생각해 보자. 재시작 뒤 주소가 달라지면 예전 IP를 적어 둔 클라이언트는 새 서버가 정상이어도 접속하지 못한다.
| 확인 위치 | 예전 값 | 재시작 뒤 점검 |
|---|---|---|
| EC2 퍼블릭 IPv4 | 임시 주소 A | 현재 주소 B인지 확인 |
| DNS A 레코드 | 주소 A | 여전히 A를 가리키는지 확인 |
| 클라이언트 설정 | 주소 A | 고정 IP 대신 DNS 이름을 쓰는지 확인 |
이때 애플리케이션을 재시작하거나 보안 규칙을 넓히기 전에 주소와 DNS부터 비교한다. DNS가 주소 B를 가리키는데도 접속이 안 되면 그다음에 인스턴스 상태, 리스닝 포트, 보안 그룹을 확인한다. 이렇게 해야 주소 오류와 서버 오류를 혼동하지 않는다.
고정 IP가 필요하면 무엇을 함께 관리할까?
외부 시스템의 IP 허용 목록처럼 주소 자체가 계약인 연동에는 Elastic IP를 검토할 수 있다. 하지만 주소를 고정해도 인스턴스 장애 시 서비스가 자동 복구되지는 않는다. 어느 인스턴스에 연결돼 있는지, 교체 시 재연결 책임은 누구에게 있는지, 더 이상 쓰지 않을 때 어떻게 회수할지를 함께 정한다. 여러 서버로 확장하는 웹 서비스라면 로드 밸런서와 DNS가 더 적절한 진입점일 수 있다.
핵심 요약
인스턴스 공용 IP는 서비스의 영구 주소로 보기 어렵다. 사용자 접근은 DNS와 로드 밸런서 같은 안정된 진입점으로 분리하고, 고정 IP는 외부 연동처럼 필요한 경우에만 명시적으로 관리하자. 서버 교체가 주소 변경 사고로 이어지지 않는 구조가 중요하다.
