-
[AWS] ASG & ELB 실습 가이드aws 2025. 3. 7. 01:48
본 게시물은 AWS ASG(Auto Scaling Group)와 ELB(Elastic Load Balanacer)를 이용하여 EC2 인스턴스를 자동으로 생성하고 트래픽을 분산하는 실습 합니다.
실습의 최종 결과물은 다음과 같습니다.
1. ASG와 ELB 개요
1.1 Auto Scaling Group(ASG)이란?
ASG(Auto Scaling Group)는 EC2 인스턴스를 자동으로 확장(Scale-out) 또는 축소(Scale-in)하여 트래픽 부하에 따라 가용성을 유지하는 서비스입니다. 특정 조건을 설정하면 ASG가 자동으로 인스턴스를 추가하거나 삭제합니다.
1.2 Elastic Load Balancer(ELB)란?
ELB는 여러 개의 EC2 인스턴스에 트래픽을 균등하게 분산하는 역할을 합니다. ASG와 함께 사용하면 새롭게 생성된 EC2 인스턴스에 대해서 트래픽을 분산하고, 반대로 제거된 인스턴스로는 트래픽을 전달하지 않습니다.
1.3 실습 목표
본 실습에서는 아래와 같은 AWS 인프라를 구축하여 EC2 인스턴스를 생성하고 트래픽을 자동으로 분산하는 방법을 배워보겠습니다.
- VPC, 서브넷, 인터넷 게이트웨이(IGW), 라우팅 테이블 설정
- 보안 그룹 구성
- Auto Scaling Group 및 시작 템플릿 생성
- Application Load Balancer(ALB) 설정
- ASG를 통해 다중 AZ에 EC2 인스턴스를 배포하고, ALB를 통해 트래픽을 분산
2. AWS 인프라 구성
2.1 VPC 생성
VPC(Virtual Private Cloud)는 AWS에서 제공하는 독립적인 가상 네트워크 공간입니다. 각 VPC는 서로 격리된 환경을 제공하여 보안성을 높이고, VPC 별로 네트워크 설정을 다르게 할 수 있습니다. 또한, VPC 내에 서브넷을 생성하여 네트워크를 더욱 세분화할 수 있습니다.
왼쪽 : VPC 없음 / 오른쪽 : 2개의 VPC 존재 - VPC를 사용하지 않았을 경우 (왼쪽 사진)
- 모든 EC2 인스턴스가 하나의 네트워크에서 동작
- 모든 인스턴스가 인터넷과 연결되어 있으므로 보안에 취약
- 인스턴스 간의 불필요한 통신이 발생
- VPC를 사용할 경우 (오른쪽 사진)
- 각 인스턴스가 독립적인 네트워크 공간에서 실행됨
- 보안 그룹, 네트워크 ACL 설정을 통해 VPC 별로 접근 통제 가능
- 서로 다른 VPC에 있는 EC2 인스턴스들은 기본적으로 서로 통신할 수 없음
실제로 VPC를 생성해 보겠습니다.
- 이름: myapp-vpc
- CIDR 블록: 10.0.0.0/16
VPC 2.2 Public Subnet 생성
VPC는 AWS에서 제공하는 가상의 네트워크 공간이지만, VPC 내에서도 네트워크를 더욱 세분화하여 제어할 수 있습니다. 이때, 사용하는 것이 서브넷(Subnet)입니다. 서브넷은 VPC 내에서 생성되는 논리적인 네트워크 공간입니다. 즉, VPC 내에 생성되는 작은 네트워크 공간입니다. VPC는 반드시 하나 이상의 서브넷을 가져야 하며, VPC 생성 시 자동으로 서브넷이 생성됩니다.
서브넷은 Public과 Private Subnet으로 생성할 수 있습니다.
- Public Subnet : 인터넷과 연결되어 있는 서브넷
- 인터넷 게이트웨이(igw)를 통해 외부 네트워크와 통신 가능
- Public Subnet에 생성되는 AWS 리소스들은 외부와 통신 가능
- Private Subnet : 인터넷과 연결되지 않는 서브넷
- Private Subnet에 생성되는 AWS 리소스들은 외부와 통신 불가능
- 단, NAT 게이트웨이를 통해 서브넷 -> 외부로 트래픽 전송 가능
VPC 내에 서브넷을 다음과 같이 구성할 수 있습니다.
[VPC] (10.0.0.0/16) ├── [Public Subnet] (10.0.1.0/24) --> 인터넷 연결 가능 (IGW 사용) │ ├── EC2 (웹 서버) │ ├── ALB (로드 밸런서) │ ├── [Private Subnet] (10.0.2.0/24) --> 인터넷 연결 불가 (NAT 사용) │ ├── EC2 (애플리케이션 서버) │ ├── RDS (DB 서버)
VPC 내에 서브넷을 생성해 보겠습니다. 본 실습에서는 HTTP 요청을 통해 EC2 인스턴스에 접근할 것이므로, 인스턴스를 배포할 Public 서브넷만 생성합니다.
- myapp-public-subnet-01 (10.0.1.0/24, ap-northeast-2a)
- myapp-public-subnet-02 (10.0.2.0/24, ap-northeast-2c)
- myapp-public-subnet-03 (10.0.3.0/24, ap-northeast-2b)
- 자동 IP 할당: 활성화 (EC2 인스턴스가 퍼블릭 IP를 받도록 설정)
3개의 퍼블릭 서브넷 2.3 인터넷 게이트웨이(IGW) 생성 및 연결
인터넷 게이트웨이는 VPC와 인터넷(외부) 간에 통신이 가능하도록 합니다. VPC 내부에 있는 Public Subnet에 있는 EC2 인스턴스가 외부 인터넷과 통신할 수 있도록 연결해 주는 역할을 합니다.
인터넷 게이트웨이를 생성하고 VPC와 연결해 보겠습니다.
- 이름: myapp-igw
- VPC 연결: myapp-vpc
인터넷 게이트웨이 2.4 라우팅 테이블 생성 및 설정
라우팅 테이블은 VPC 내의 트래픽이 어디로 가야 하는지를 결정하는 설정입니다. 즉, 패킷이 어떤 대상으로 전달되어야 할지 정의하는 역할을 합니다.
라우팅 테이블의 주요 역할은 다음과 같습니다.
- 서브넷에서 발생한 트래픽을 올바른 대상으로 전달
- VPC 내부 리소스 간 통신을 자동으로 허용
- 서브넷마다 서로 다른 라우팅 규칙 적용 가능
- 인터넷과 통신 가능 (인터넷 게이트웨이 추가 시)
아래는 myapp-vpc의 CIDR 블록이 10.0.0.0/16일 때의 라우팅 테이블 예제입니다. 라우팅 테이블을 생성하면 기본적으로 VPC 내부 리소스 간 통신을 허용하는 local 경로가 자동으로 추가됩니다. (10.0.0.0/16 -> local) 추가적으로, 인터넷 연결을 위해 0.0.0.0/0 -> igw 경로를 설정할 수 있습니다.
- 10.0.0.0/16 -> local : 같은 VPC 내의 리소스 간의 통신을 허용
- 0.0.0.0/0 -> igw : Public 서브넷에서 발생한 트래픽을 외부 인터넷으로 전달 가능
- 인터넷으로 나가는 모든 트래픽을 인터넷 게이트웨이로 전달
+---------------------- 라우팅 테이블 --------------------------+ | 대상 (Destination) | 타겟 (Target) | 설명 | |------------------------|------------------|----------------| | 10.0.0.0/16 | local | 같은 VPC 내 통신 | | 0.0.0.0/0 | igw-xxxxxxxx | 인터넷 연결 | +------------------------------------------------------------+
myapp-vpc에 대한 라우팅 테이블을 생성하겠습니다. 생성된 라우팅 테이블에는 기본적으로 10.0.0.0/16 -> local 경로가 추가되어 있습니다. Public 서브넷에서 발생한 트래픽을 외부로 전달하기 위한 0.0.0.0/0 -> igw 경로도 추가해 줍니다.
- 이름: myapp-rt
- VPC 연결: myapp-vpc
- 라우팅 설정: 0.0.0.0/0 -> myapp-igw
- 3개의 Public 서브넷 명시적 연결
myapp-vpc에 존재하는 3개의 Public 서브넷에서 발생한 트래픽을 외부로 전달하기 위해 라우팅 테이블에 명시적으로 연결합니다.
2.5 보안 그룹(Security Group) 생성
보안 그룹(Security Group)이란 가상 방화벽 역할을 하는 기능으로, 보안 그룹이 허용한 트래픽에 대해서만 리소스에 접근할 수 있습니다. 허용되지 않은 모든 트래픽은 보안 그룹에 의해 차단됩니다.
보안 그룹의 특징은 다음과 같습니다.
- stateful
- 인바운드 규칙으로 허용한 트래픽은 아웃바운드 규칙으로 자동으로 허용됩니다.
- 즉, 인바운드 규칙으로 HTTP:80 포트를 허용하면 아웃바운드 규칙으로도 허용됩니다.
- 기본적으로 모든 트래픽을 차단한다.
- 보안 그룹을 생성하면 설정되어 있는 인바운드 규칙이 없으므로 모든 트래픽을 차단합니다.
- 아웃바운드 규칙으로는 모든 트래픽을 허용하도록 기본 설정되어 있습니다.
- 트래픽을 허용하는 규칙만 설정 가능
- 인바운드/아웃바운드 규칙으로 허용할 트래픽을 설정할 수 있습니다.
- 그러나 허용하지 않을 트래픽은 설정할 수 없습니다. 즉, 특정 IP나 포트를 차단하는 거부 규칙을 생성할 수 없습니다.
ASG(Auto Scaling Group)에 의해 생성될 EC2 인스턴스에 적용할 보안 그룹(Security Group)을 생성해 봅시다. 외부에서 EC2 인스턴스로 HTTP:80 접근을 허용할 것이므로, 인바운드 규칙으로 HTTP:80을 설정합니다.
- 보안 그룹 (Security Group)
- 이름: myapp-sg
- 인바운드 규칙
- HTTP (80): 모든 IP 허용 (0.0.0.0/0)
- 아웃바운드 규칙
- 모든 트래픽 허용
3. ASG(Auto Scaling Group) 및 시작 템플릿(Launch Template) 생성
3.1 시작 템플릿(Launch Template) 생성
시작 템플릿(Launch Template)은 EC2 인스턴스를 생성할 때 필요한 설정값을 미리 저장한 템플릿입니다. 특히, ASG가 시작 템플릿을 사용하여 scale-out 할 때 생성된 모든 EC2 인스턴스에 동일한 설정을 적용할 수 있습니다.
시작 템플릿의 주요 설정값은 다음과 같습니다.
- AMI (Amazon Machine Image)
- ex. Amazon Linux 2023
- 인스턴스 유형
- ex. t2.micro
- 키 페어
- ex. SSH 접속을 위한 키 페어
- 보안 그룹
- ex. EC2 인스턴스에 적용할 보안 그룹
- 스토리지
- ex. EC2 인스턴스가 사용할 EBS 볼륨
- 네트워크 (VPC, 서브넷)
- ex. EC2 인스턴스가 위치할 VPC 및 서브넷
- User Data
- ex. EC2 인스턴스가 생성될 때 실행할 스크립트
ASG가 사용할 시작 템플릿을 생성해 봅시다.
- AMI: Amazon Linux 2023
- 인스턴스 유형: t2.micro
- 보안 그룹: myapp-sg
- 사용자 데이터 (EC2 인스턴스 ID를 웹 페이지에 출력하도록 설정)
- 아래의 경우 EC2 인스턴스에 접속했을 때, 접속한 EC2 인스턴스의 ID를 출력하는 스크립트입니다. 시작 템플릿 생성 시에 사용자 데이터로 작성합니다.
#!/bin/bash sudo -s dnf install httpd -y service httpd start chkconfig httpd on TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id) echo "$INSTANCE_ID" > /var/www/html/index.html
3.2 Auto Scaling Group 생성
ASG(Auto Scaling Group)는 EC2 인스턴스를 자동으로 생성하거나 종료하여 애플리케이션 부하에 따른 인프라를 자동으로 scale-out 또는 scale-in을 수행하는 서비스입니다. 트래픽이 많아지면 시작 템플릿을 기반으로 EC2 인스턴스를 추가로 생성하고, 트래픽이 줄어들면 불필요한 인스턴스를 종료하여 비용 및 리소스를 최적화합니다.
ASG는 설정한 값을 기반으로 EC2 인스턴스 개수를 자동으로 관리합니다. EC2 인스턴스를 배포할 VPC와 서브넷을 지정하고 가용 영역 또한 지정할 수 있습니다. 따라서 ASG는 지정한 가용 영역 중에서 선택하여 EC2 인스턴스를 배포합니다.
| 값 | 설명 | |------|------| | Min Capacity (최소 개수) | EC2 인스턴스의 최소 개수 (이 값보다 줄어들지 않음) | | Max Capacity (최대 개수) | EC2 인스턴스의 최대 개수 (이 값보다 증가하지 않음) | | Desired Capacity (목표 개수) | ASG가 정상적인 상태에서 유지하려는 인스턴스 개수 |
ASG를 생성해 보겠습니다.
- VPC: myapp-vpc
- 서브넷: myapp-public-subnet-01, myapp-public-subnet-02, myapp-public-subnet-03
- Min capacity: 2
- Max capacity: 4
- Desired capacity: 2
4. Application Load Balancer(ALB) 설정
4.1 ALB(Application Load Balancer) 생성
ALB(Application Load Balancer)는 AWS에서 제공하는 로드 밸런서로, 발생한 트래픽을 여러 개의 EC2 인스턴스에 자동으로 분산하여 부하를 균형 있게 조절하는 방법입니다. 즉, 특정 인스턴스에 트래픽이 부하되지 않도록 트래픽을 고르게 분산하는 서비스입니다.
ALB는 단순히 모든 EC2 인스턴스에 트래픽을 분산하는 것이 아닌, ALB에 지정한 서브넷에 배포된 EC2 인스턴스에만 트래픽을 전달합니다.
아래는 타켓 그룹(Target Group)인데 4-2에서 설명합니다.
ALB를 생성하여 대상 그룹(Target Group)으로 지정된 EC2 인스턴스에 트래픽을 분산합니다.
- VPC: myapp-vpc
- 서브넷: myapp-vpc에 속한 3개의 Public 서브넷
- 리스너: HTTP:80 포트 설정
- 리스너란 ALB가 특정 포트에서 클라이언트 요청을 수신하는 역할을 합니다. 즉, ALB로 들어오는 트래픽을 감지하여 해당 트래픽을 대상 그룹으로 라우팅 하는 역할을 합니다.
- myapp-alb의 경우 HTTP:80 트래픽을 수신하여 myapp-vpc에 속한 3개의 Public 서브넷으로 트래픽을 분산합니다.
4.2 대상 그룹(Target Group) 설정
대상 그룹(Target Group)은 ALB에서 트래픽을 전달할 EC2 인스턴스나 서비스 그룹을 정의하는 리소스입니다. ALB는 EC2 인스턴스로 직접 트래픽을 전달하는 것이 아닌, 대상 그룹을 통해 트래픽을 분산할 대상을 결정합니다.
사용자 요청 │ ▼ [ALB: myapp-alb] ──> [대상 그룹: myapp-tg] ──> [EC2 인스턴스]
대상 그룹을 생성해 보겠습니다.
- 이름: myapp-target-group
- VPC: myapp-vpc
- 프로토콜: HTTP
- 포트: 80
4.3 ASG와 ALB 연결
ASG에서 생성된 EC2 인스턴스들이 ALB의 대상 그룹에 자동으로 등록되도록 설정합니다.
5. 테스트 및 검증
- ALB의 DNS 주소를 확인하고 브라우저에서 접속합니다.
- 페이지를 새로고침하면서 다른 인스턴스로 트래픽이 분산되는지 확인합니다.
6. 보안 고려사항
현재 설정에서는 EC2 인스턴스가 퍼블릭 서브넷에 위치하여 외부 접근이 가능합니다. 퍼블릭 서브넷에 EC2 인스턴스가 위치해 있으므로 외부에서 직접 접근이 가능하다는 보안 취약점이 존재합니다. 이를 해결하는 방법으로 Bastion Host 도는 AWS SSM을 사용할 수 있는데, 이는 다음 편에 이어서 작성하도록 하겠습니다.
- Bastion Host: SSH 접속을 위해 별도의 관리용 인스턴스를 배포
- AWS SSM(Session Manager): EC2에 직접 SSH 접속 없이 AWS 관리 콘솔을 통해 접근
본 실습을 통해 AWS Auto Scaling Group과 Elastic Load Balancer를 활용하여 트래픽을 자동으로 분산하고, 확장 가능한 인프라를 구축하는 방법을 익혔습니다. 다음 단계에서는 Bastion Host와 AWS SSM을 통해 보안 취약점을 개선하는 방법에 대해 다룰 예정입니다.