ALB에 HTTP(80)를 설정하지 않으면 어떻게 되는지 확인해 봤습니다.
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 ALB에 HTTP(80)를 설정하지 않으면 어떻게 되는지 확인해 봤습니다.
사전 준비
먼저 보안 그룹은 다음과 같이 생성했습니다.
2개의 보안 그룹만 생성했으며 ALB 보안 그룹에는 HTTPS만 허용하고 있습니다.
- 보안 그룹 이름 : test-alb-sg
| Name | 보안 그룹 규칙 ID | IP 버전 | 유형 | 프로토콜 | 포트 범위 | 소스 | 설명 |
|---|---|---|---|---|---|---|---|
| – | sgr-xxxxxxxxx | IPv4 | HTTPS | TCP | 443 | 0.0.0.0/0 | – |
- 보안 그룹 이름 : test-ec2-sg
| Name | 보안 그룹 규칙 ID | IP 버전 | 유형 | 프로토콜 | 포트 범위 | 소스 | 설명 |
|---|---|---|---|---|---|---|---|
| – | sgr-xxxxxxxxx | – | HTTP | TCP | 80 | sg-xxxxxxxxx / test-alb-sg | – |
그리고 Amazon Linux 2023 OS를 사용하는 EC2에는 다음 명령어로 아파치를 설치했습니다.
# 패키지 업데이트
sudo dnf update -y
# Apache 설치
sudo dnf install -y httpd
# Apache 시작
sudo systemctl start httpd
# 부팅 시 자동 시작 설정
sudo systemctl enable httpd
# Apache 상태 확인
sudo systemctl status httpd
웹 사이트를 보여줄 html 파일은 다음 코드를 사용했습니다.
<!DOCTYPE html>
<html lang="ko">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Welcome</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
min-height: 100vh;
display: flex;
align-items: center;
justify-content: center;
}
.container {
background: white;
border-radius: 20px;
padding: 60px 80px;
text-align: center;
box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3);
max-width: 600px;
width: 90%;
}
.icon {
font-size: 80px;
margin-bottom: 20px;
}
h1 {
font-size: 2.5rem;
color: #333;
margin-bottom: 15px;
}
p {
font-size: 1.1rem;
color: #666;
line-height: 1.8;
margin-bottom: 30px;
}
.badge {
display: inline-block;
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
color: white;
padding: 10px 25px;
border-radius: 50px;
font-size: 0.9rem;
font-weight: bold;
letter-spacing: 1px;
}
.footer {
margin-top: 40px;
font-size: 0.8rem;
color: #aaa;
}
</style>
</head>
<body>
<div class="container">
<div class="icon">🚀</div>
<h1>환영합니다!</h1>
<p>서버가 정상적으로 작동하고 있습니다.<br>Apache on Amazon Linux 2023</p>
<div class="badge">✅ 서버 정상 작동 중</div>
<div class="footer">
<p>Powered by Apache / AWS EC2</p>
</div>
</div>
</body>
</html>
테스트
먼저 https:// 로 접속해 보면 문제 없이 웹 사이트가 표시되는 것을 확인할 수 있습니다.
이어서 https:// 없이 도메인만 입력해서 접속해 보면 HTTPS로 자동 접속되는 것을 확인할 수 있습니다.
다만, 이는 ALB가 HTTP(80) 요청을 HTTPS(443)로 리다이렉트한 것이 아닙니다. 현재 ALB에는 80 포트 리스너가 존재하지 않기 때문에 HTTP 요청 자체를 처리할 수 없습니다.
따라서 브라우저의 HSTS 캐시 또는 최신 브라우저의 HTTPS-First 정책에 의해 자동적으로 HTTPS로 재시도된 것으로 볼 수 있습니다.
실제로 HTTP(80) 연결이 가능한지 확인하기 위해 curl로 테스트해 보겠습니다.
다음과 같이 http:// 로 직접 요청하면 80 포트 연결이 응답하지 않는 것을 확인할 수 있습니다.
curl -v http://xxxx.xxxx.xxxx
* Host xxxx.xxxx.xxxx.info:80 was resolved.
* IPv6: (none)
* IPv4: xx.xx.xxx.xxx, xx.xxx.xx.xxx
* Trying xx.xx.xxx.xxx:xx...
telnet으로 시도해 봐도 동일하게 응답하지 않는 것을 확인할 수 있습니다.
telnet xxxx.xxxx.xxxx.xxxx 80
Trying xx.xx.xxx.xxx...
telnet: connect to address xx.xx.xxx.xxx: Connection timed out
Trying xx.xxx.xx.xx...
왜 브라우저에서는 정상 접속되는가?
ALB에는 HTTPS(443)만 설정했기 때문에, 일반적으로 생각하면 http:// 접속은 실패해야 합니다.
하지만 실제로는 브라우저 주소창에 도메인만 입력해도 정상적으로 HTTPS 사이트가 표시되는 경우가 많습니다.
이는 ALB가 HTTP(80) 요청을 HTTPS(443)로 리다이렉트했기 때문이 아닙니다.
최근 브라우저(Chrome, Edge, Safari 등)는 보안을 위해 HTTPS를 우선적으로 시도하는 동작(HTTPS-First)을 수행하거나, 기존 접속 이력을 기반으로 HSTS 정책을 적용하기 때문입니다.
따라서 사용자가 단순히 도메인만 입력한 경우에는 브라우저가 자동으로 HTTPS 연결을 시도하여 정상적으로 접속되는 것처럼 보일 수 있습니다.
다만, 아래와 같은 경우에는 여전히 HTTP(80) 연결이 시도될 수 있습니다.
- 사용자가 직접
http://를 입력한 경우 - 오래된 북마크 또는 외부 링크가
http://인 경우 - HSTS 이력이 없는 최초 접속
- curl, telnet 등 브라우저 외부 도구를 사용하는 경우
- 일부 시스템 연동 또는 레거시 환경
이러한 상황에서는 HTTP(80) 연결이 실제로 필요할 수 있으며, 현재 구성처럼 ALB에 80 리스너가 없고 보안 그룹에서도 80 포트를 허용하지 않은 경우에는 연결이 실패하게 됩니다.
즉, 브라우저에서는 정상 동작하는 것처럼 보여도, 실제 HTTP 연결 자체는 처리되지 않고 있다는 점을 확인할 수 있습니다.
마지막
이번 테스트에서는 ALB(Application Load Balancer)에 HTTPS(443)만 설정하고 HTTP(80)를 구성하지 않았을 때 어떤 동작이 발생하는지 확인해 봤습니다.
실제로 테스트해 보면 https:// 로 접속하는 경우에는 문제 없이 정상 동작하며, 브라우저 주소창에 도메인만 입력해도 자동으로 HTTPS로 접속되는 것을 확인할 수 있었습니다.
하지만 이는 ALB가 HTTP 요청을 HTTPS로 리다이렉트했기 때문이 아니라, 최신 브라우저의 HTTPS 우선 정책(HTTPS-First) 또는 HSTS 동작에 의해 HTTPS 연결이 자동으로 시도되었기 때문입니다.
실제로 curl이나 telnet을 사용해 HTTP(80) 연결을 직접 시도해 보면 연결이 타임아웃되며, HTTP 요청 자체는 처리되지 않는 것을 확인할 수 있었습니다.
즉, 브라우저에서는 정상 접속되는 것처럼 보이더라도, 실제 HTTP 연결이 가능한 상태는 아니라는 점이 이번 테스트의 핵심이라고 볼 수 있습니다.
또한, 이번 테스트를 통해 “브라우저에서 접속이 된다”와 “HTTP 연결이 정상적으로 구성되어 있다”는 서로 다른 이야기라는 점도 확인할 수 있었습니다.
특히 최근 브라우저들은 HTTPS 사용을 적극적으로 유도하고 있기 때문에, 사용자는 HTTP가 비활성화되어 있다는 사실을 인지하지 못한 채 서비스를 이용하는 경우도 많습니다.
다만, 아래와 같은 환경에서는 여전히 HTTP 연결이 필요할 수 있습니다.
- 사용자가 직접
http://로 접속하는 경우 - 오래된 외부 링크 또는 북마크를 사용하는 경우
- 레거시 시스템 또는 일부 외부 연동 환경
- curl, telnet 등 테스트 도구를 사용하는 경우
- HSTS 이력이 없는 최초 접속 환경
따라서 운영 환경에서는 단순히 “브라우저에서 잘 열린다”만 확인하는 것이 아니라, 실제 HTTP 요청이 어떻게 처리되는지도 함께 확인하는 것이 중요합니다.
만약 HTTP 요청을 HTTPS로 안전하게 유도하고 싶다면, 일반적으로는 다음과 같은 구성을 많이 사용합니다.
- ALB에 HTTP(80) 리스너 추가
- Redirect 액션으로 HTTPS(443) 리다이렉트 설정
- 최종적으로 HTTPS만 사용하도록 유도
반대로, 내부 서비스 전용 환경이거나 HTTPS만 사용하는 것이 명확한 환경이라면 이번 테스트처럼 HTTP(80)를 완전히 비활성화하는 구성도 충분히 선택 가능한 방법이라고 생각합니다.
이번 테스트가 ALB의 HTTPS 전용 구성과 브라우저의 HTTPS 동작을 이해하는 데 도움이 되었으면 합니다.
