Scalability & High Availability
확장성 및 고 가용성
Scalability
확장성은 조정을 통해 더 많은 양을 처리할 수 있음을 의미
- Vertical Scalability(수직 확장성)
- EC2 인스턴스의 옵션이 기존보다 좋아지는 경우
- 데이터베이스와 같이 분산되지 않은 시스템에서 사용
- RDS, ElasticCache
- 확장할 수 있는 하드웨어의 한계가 있음
- Horizontal Scalability(수평 확장성), lasticity(탄력성)
- 동일한 옵션의 EC2 인스턴스가 여러개로 늘어나는 경우
- 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법
High availability
애플리케이션, 시스템을 둘 이상의 AWS-AZ, 데이터센터에 가동 중인 경우
어느 한쪽에서 문제가 생겨도 다른 한쪽에서 처리가 가능하여 지속적인
작동을 보장해주는 경우
스케일 아웃: 인스턴스의 수 증가
스케일 인: 인스턴스의 수 감소
다른 스케일링 그룹, 로드 밸런서에서 사용
동일 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행함을 의미
Elastic Load Balancing(ELB)
서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림으로 EC2 인스턴스
또는 서버들로 전달하는 역할을 담당
클라이언트 A, B, C / EC2 인스턴스 A, B, C
클라이언트 A ~ C의 요청을 ELB가 받으며 EC2 인스턴스 A ~ C의 상태 확인
후 서버에 요청을 전달, 서버에서 받은 응답을 다시 클라이언트에게 전달
ELB 사용 이유
결국 ELB 사용 이유는 부하를 다수의 다운스트림으로 여러 인스턴스에 분산
애플리케이션의 단일 액세스 지점(DNS)을 노출
다운스트림 인스턴스 장애 처리
로드 밸런스 상태 확인 매커니즘(인스턴스가 요청을 처리할 수 있는 상태?)
SSL을 종료하여 웹 사이트의 암호화된 HTTPS 트래픽을 가짐
SSL(Secure Socket Layer): 네트워크 위협들로 데이터를 보호
쿠키를 사용한 고정도 강화, 영역에 걸친 고가용성
클라우드내에서 개인 트래픽, 공공 트래픽 분리
Health Checks(상태 확인), ELB 보안 그룹
상태 확인은 포트와 라우트(protocol, port, endpoint)에서 이뤄짐
유저는 HTTP/HTTPS를 사용해서 어디서든 Load Balancer에 접근 가능
그러므로 Load Balancer 보안 그룹은 80, 443 포트에 대해
0.0.0.0/0 으로 어떤 유저든 접근 가능하게 설정해야 한다
그러나 EC2 인스턴스는 Load Balancer 의 트래픽에 대해 허용해야
되므로 80번 포트에 대해 IP가 아닌 Load Balancer 의 트래픽이
접근 가능한 강화된 보안 그룹 설정이 된다
CLB(Classic Load Balancer, v1)
오래되어 AWS 사용을 권장하지 않음
HTTP & HTTPS(Layer 7), TCP(Layer 4)
상태 확인은 TCP or HTTP 기반으로 이루어 짐
CLB의 고정 호스트 이름을 부여 받아 해당 이름으로 접근 가능
Client > (HTTP Listener) > (연결)CLB > (Traffic) > (전달)EC2
CLB 실습 - 하나의 EC2 인스턴스 & CLB
1.EC2 인스턴스 생성
HTTP 80(IPv4, IPv6 anywhere), SSH 22(IPv4 anywhere)
2.EC2 Dashboard -> Load Balancers -> Create Load Balancer 클릭
3.Classic Load Balancer -> create 클릭
4.값 설정 -> Next Assign Security Groups 클릭
5.값 설정(IPv6 지원 X) -> Next Configure Security Settings 클릭
6.
Response Timeout: 응답 대기 시간,
Interval: 응답 체크 주기
Unhealthy threshold: 몇 번의 무응답을 체크로 상태가 죽었는지 설정
Healthy threshold: 몇 번의 응답이 상태가 살았는지 설징
7.CLB를 적용할 인스턴스 선택 -> Next Add Tags 클릭
8.Review and Create -> Create 클릭
9.CLB 생성 확인 및 Instance Status -> InService 될 때까지 대기
10.CLB Description -> DNS name 복사 -> 브라우저 주소창에 입력
11.공용 IP 접근할 때 화면과 같은 화면 출력되는지 확인
공용 IP 접근 막고 CLB DNS name 접근 허용 방법
1.보안 그룹에 이미 적용되어 있는 HTTP 80 관련 rules 제거
2.Add rule -> HTTP, TCP, 80, Custom, "CLB 보안 그룹" 설정
3.공용 IP, DNS name 으로 브라우저에 연결 테스트
4.공용 IP에 접근이 안되는지 확인
위 순서대로 적용했는데 정상적으로 출력되지 않을 경우
1.보안 그룹이 잘못 적용 되었는지 확인
2.부트스트랩(EC2 - user data) 문구가 바르게 적용되지 않은 경우
CLB 실습 - 여러개 EC2 인스턴스 & CLB
1.동일한 설정 값의 EC2 인스턴스 2개를 더 생성
2.이미 생성한 CLB에 위에서 생성한 인스턴스 2개를 더 연결
3.InService 상태가 되었는지 확인 후 브라우저에 DNS name 입력
4.브라우저에 EC2 인스턴스 ip 가 랜덤하게 출력되는지 확인
5.위 과정을 확인하므로 CLB가 정상적으로 적용됨을 확인 가능
ALB(Application Load Balancer, v2)
HTTP, HTTPS(7 계층, HTTP 전용 로드 밸런서), WebSocket protocol
머신 간 다수 HTTP 애플리케이션 라우팅에 사용
머신들은 대상 그룹으로 묶임
HTTP/2, 리다이렉트 지원
HTTP -> HTTPS 리다이렉트는 로드 밸런서 레벨에서 가능
URL 대상 경로에 기반한 라우팅 가능(쿼리 문자열, 헤더에 기반한 라우팅)
마이크로 서비스, 컨테이너 기반 어플리케이션에 적합(Docker, ESC)
포트 매핑 기능, ECS 인스턴스의 동적 포트로 리다이렉션
쿼리 스트링으로 대상 그룹에 리다이렉트 가능
?platform=Mobile or Desktop 값으로 대상 그룹 연결
사설 IP 주소 앞에 위치할 수 있음
여러 대상 그룹으로 라우팅
대상 그룹 레벨에서 상태 확인 가능
X-Forwarded-For, Port, Proto: 클라이언트의 정보 확인
ALB 실습
1.EC2 인스턴스 3개는 CLB 실습에서 생성
2.EC2 Dashboard -> Load Balancers -> Create Load Balancer 클릭
3.Application Load Balancer -> Create 클릭
4.값, AZ Mappings 체크, 보안 그룹 설정
5.Listeners and routing Tab -> Create target group 클릭
6.값 설정 -> Next 클릭
7.EC2 인스턴스 체크 -> Include as pending below 클릭
8.Create target group 클릭 후 생성된 Target group 확인
9.다시 Listeners and routing Tab -> 새로고침 -> 대상 그룹 선택
10.Create load balancer 클릭 -> 생성된 Load Balancer 확인
11.Description Tab 클릭 -> DNS name 브라우저에서 접속
12.선택한 EC2 인스턴스들에 로드밸런싱 되는지 확인
13.Target group 클릭 -> 다른 실행중인 EC2 인스턴스의 대상 그룹 생성
14.Load balancers -> Listeners -> Rules에 View/edit rules 클릭
15.+(Add rules) 버튼 클릭 -> Insert Rule 클릭
16.IF -> + Add condition 클릭 -> path 클릭 -> /??? 입력
17.THEN -> + Add action 클릭 -> Forward 클릭 -> 대상그룹 선택
위에서 추가로
18.16번에서 특정 path에 대한 접근을 에러페이지로 리턴할 수 있음
19.여러가지 rule을 적용하고 save 클릭
20.DNS name + path 입력하여 ALB rule 적용이 됬는지 확인
NLB(Network Load Balancer, v2)
TCP, TLS(secure TCP), UDP
외부의 AZ 당 1개의 고정 IP 노출
NLB 자체의 IP 가 아닌 일래스틱 IP 할당 지원
애플리케이션 전용의 특정 IP 지정하면 NLB 가 해당 트레픽을
EC2 인스턴스로 보내는 것이며
CLB, ALB 는 고정 IP가 없고 고정 호스트 이름이 있음
GWLB(Gateway Load Balancer)
네트워크층인 3계층과 IP프로토콜에서 작동
대상 그룹
EC2 인스턴스가 대상 그룹이 될 수 있음
그룹에 의해 오토 스케일링 관리, ECS 작업, 람다 함수 사용 가능
Sticky Sessions
A ~ C 클라이언트, A ~ C 서버
A 클라이언트의 요청을 LB 를 통해서 C 서버에 전달
여러 번의 요청에도 A 클라이언트는 특정 설정 값 동안 C 서버에만 요청 한다
CLB, ALB 에서도 설정 가능
고정도(잘못된 고정도는 인스턴스 부하에 불균형을 초래할 수 있음), 만료 기간 설정 가능
쿠키 이름은 각 대상 그룹마다 지정해주어야 함
- Application-based Cookies
- Custom cookie
- 애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있음
- application cookie
- 로드 밸런서 자체에서 생성
- Custom cookie
- Duration-based cookies
- 특정 기간을 기반으로 만료되며 해당 기간이 로드밸런서 자체에서 생섬
Sticky Sessions 사용
1.EC2 Dashboard -> Load balancing -> Target groups 클릭
2.생성되어 있는 대상 그룹 클릭 -> Actions -> Edit Attributes 클릭
3.stickiness 활성화 -> 필요한 설정 값 적용
4.브라우저 LB DNS name 입력 -> 개발자 모드(network)의 쿠키 확인
Cross Zone Load balancing
예시로 2개의 AZ, 첫 번째 AZ 는 EC2 2개, 두 번째 AZ 는 EC2 8개
트래픽이 첫 번째 AZ로 가면 분산 부하를 각 50%씩 나눌 수 있고
두 번째 AZ로 가면 100 / 8 만큼 분산 부하를 크게 볼 수 있다
이러한 상황에서 교차 영역 LB는 100 / 2 + 8 만큼 분산 부하를 적용할 수 있다
CLB, ALB: 비용이 발생되지 않음, NLB: 비용 발생
SSL(Secure Socket Layer), TLS(Transport Layer Security)
SSL은 보안 소켓 계층으로 연결을 암호화 하는데 사용
TLS는 SSL의 최신 버전으로 전송 계층 보안을 의미
SSL 인증서를 사용하면 클라이언트, 로드 밸런서 사이에서 전송 중인
트래픽을 암호화할 수 있음(in-flight encryption)
발신자와 수산자만이 해독 가능
로드 밸런서 관점에서의 인증서 작동
User -> HTTPS -> (공용 인터넷을 통한 연결) Load balancer ->
(트래픽 안전성 보장을 위한 사설 네트워크 VPC 사용) HTTP ->
EC2 인스턴스(백엔드)
SNI(Server Name Indicate)
하나의 웹 서버 상에 다수의 SSL 인증서를 발급하여 단일 웹 서버가
여러 개의 웹 사이트를 제공하도록 하는 문제를 해결할 수 있음
클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 명시
즉 클라이언트가 연결하고자 하는 웹사이트의 이름을 얘기하면 서버는 해당
이름과 매칭되는 SSL 인증서를 찾을 수 있음
최신 프로토콜에만 지원
ALB, NLB 이상 로드 밸런서나 클라우드 프론트(뒷 섹션)에서 작동
CLB 지원 안함
결국 로드 밸런서에 SSL 인증서가 여러개 ? = ALB, NLB 사용 중
예시) 클라이언트, ALB, 2개의 대상그룹, 2개의 인증서
A 대상그룹: www.aws.com, B 대상그룹: www.study.com
A SSL Cert: www.study.com, B SSL Sert: www.aws.com
1.클라이언트가 ALB 에 www.study.com(SNI) 연결 요청
2.요청에 해당하는 SSL 인증서 사용, 트래픽 암호화, 규칙으로 대상 그룹 확인
3.www.aws.com 을 요청해도 1, 2번과 마찬가지로 해당 됨
서로 다른 SSL 인증서로 다른 웹사이트에 연결되는 다수의 대상그룹을 가질 수 있음
SSL 인증서 지원
- CLB (v1)
- 하나의 SSL 인증서 지원
- 다수의 SSL 인증서를 적용하고 싶으면 다수의 CLB 생성 필요
- ALB, NLB (v2)
- 다중 SSL 인증서를 가진 다수의 리스너 지원, 이 때 SNI 사용
사용 방법
1.EC2 Dashboard -> Load balancing -> 하위 탭 Listeners 클릭
2.listener 체크 및 Edit 클릭
3.listner 를 변경 하거나 추가할 때 HTTPS 프로토콜 적용
4.Secure listener settingsInfo 라는 입력 폼 생성
5.적용하고 싶은 SSL 선택하여 추가 -> Save changes 클릭
연결 드레이닝
CLB: 연결 드레이닝, ALB, NLB: 등록 취소 지연
인스턴스가 등록 취소, 비정상 상태일 때 인-플라이트, 활성 요청을
완료하도록 지원하는 기능
A, B, C 인스턴스가 있을 때 A 인스턴스가 드레이닝 상태가 된 경우
ELB(Elastic Load Balancer)는 등록 취소 중인 EC2 인스턴스에
새로운 요청을 보내지 않음
드레이닝 상태의 인스턴스에 이미 연결되어 있는 유저의 경우에는
충분한 드레이닝 시간을 얻게 되며 기존 연결 및 기존 요청을 완료하고
작업이 끝나면 모든 연결은 정지 상태가 되며
이 후의 요청에 대해서 ELB는 B, C 인스턴스에만 요청을 전달하게 됨
연결 드레이닝 파라미터
매개 변수로 표시 가능
1 ~ 3,600 초 사이의 값을 설정, default 300(5분), 0: 비활성화
빠른 처리 가능한 요청은 낮게 설정하여 드레이닝이 원활하도록 설정
업로드, 오래 지속되는 요청에만 설정 값을 높게
ASG(Auto Scaling Group)
증가한 로드: 스케일 아웃, 감소한 로드: 스케일 인
EC2 인스턴스 최대, 최소 개수 지정 가능
LB 와 페어링(ASG와 연결) 하는 경우 ASG에 의해 생성되는
EC2 인스턴스는 LB 에 모두 연결됨
특정 인스턴스가 비정상일 때 자동으로 종료하고 새 EC2 인스턴스 생성
ASG 사용 무료, EC2 인스턴스와 같은 생성된 하위 리소스만 비용
ASG 작동 방식
최소, 희망, 최대 인스턴스 개수를 설정하며 희망 개수에 맞추어 인스턴스가
스케일 아웃, 스케일 인 되는 구조
ASG 는 로드 밸런서와도 작동하는데 ASG 를 통해서 생성되는 인스턴스는
로드 밸런서와 즉시 연결되어 트래픽을 분산 받을 수 있다
ELB 에서 상태 확인을 하여 ASG 에 내용을 전달하고 ASG 는 전달 받은
내용을 토대로 인스턴스들을 관리할 수 있다
과거에는 ASG 를 사용하기 위해 Launch Template 를 사용했다고 함
현재는 Launch Template 을 설정하여 ASG 를 사용한다고 함
EC2 인스턴스를 생성할 때 했던 설정들과 매우 비슷하며 추가로 위에
스케일 사이즈, 스케일 정책을 추가하는 정도
CloudWatch
스케일링을 하기 위한 알람
간단한 예시로 인스턴스들의 CPU 사용률이 40% 보다 낮으면 스케일 인,
CPU 사용률이 70% 보다 높으면 스케일 아웃을 하도록 설정하여 실제
CloudWatch 가 ASG 에 알람을 전달하고 스케일링(인/아웃)을 진행
ASG 실습
1.EC2 Dashboard -> Auto Scaling -> Auto Scaling Groups 클릭
2.Create Auto Scaling group 클릭
3.이름 입력, Launch Template -> Create a launch template 클릭
4.EC2 인스턴스를 생성할 때 처럼 값 설정
5.Subnet 은 설정하지 않음 -> Create launch template 클릭
6.ASG 화면 -> Launch Template 새로고침 및 선택
7.설정 값 확인 -> Next -> Network VPC, AZ subnet 선택
8.Instance typpe requirements -> 템플릿이 제공
9.8번에서 템플릿을 Override 하여 인스턴스 옵션을 변경 가능
10.Next -> 로드 밸런싱(ELB에서 생성했던 ALB) 선택
11.로드 밸런싱이 없어도 되지만 거의 묶어서 사용한다고 봐야함
12.Health checks 옵션 체크
EC2: EC2 인스턴스 실패시 ASG 에서 자동으로 제거
ELB: ELB가 인스턴스를 비정상으로 간주하는 경우 ASG가 자동으로 제거
13.Next -> ASG Group size 설정, Desired(희망), Min, Max
14.Group size 를 처음에는 default(1, 1, 1)값 그대로 사용
15.scaling policies none 으로 설정(뒷 섹션에서 적용)
16.Next -> (Tag)Next -> 검토 후 Create Auto Scaling group 클릭
위 순서대로 진행하면 Group size(desired) 수 만큼 인스턴스 생성됨
해당 인스턴스는 EC2 Instance -> Instances 에서 생성 유무 확인 가능
생성한 ASG 를 클릭하고 Activity Tab -> history 를 확인
해당 영역에서 인스턴스의 상태/생성/제거 등 history 확인 가능
ASG 설정 값에서 대상 그룹에 대해 설정할 수 있는데
생성되는 인스턴스는 대상 그룹에 적용되며 선택한 로드 밸런서 까지
자동으로 연결된다
ASG 실습 - 스케일링
1.생성한 ASG 클릭 -> Details Tab -> Edit 클릭
2.위 생성할 때 Size 최소:1, 희망:1, 최대:1 -> 1,2,2 로 변경
3.다시 ASG history Tab 으로 가서 인스턴스 생성 과정 확인 가능
4.ASG 생성할 때 user data 에 스크립트를 넣어서 Httpd 서버 생성
5.1~4번 까지가 정상적으로 적용되어 있다면 DNS Name 브라우저에 입력
6.새로고침하여 출력되는 ip 가 2개 인지 확인
7.다시 Size 를 1,1,1 로 변경하여 인스턴스가 제거되는지 확인
스케일링 정책
- Dynamic Scaling Policies(동적)
- Target Tracking Scaling(대상 추적)
- 모든 인스턴스의 ASG 평균 CPU 사용률 추적으로 스케일링
- 기본 사용률의 예) 40%가 유지되도록 하여 상시 가용 가능
- Simple / Step Scaling(단순 / 단계)
- CloudWatch 경보 설정
- 예) ASG CPU 사용률 70% 초과하는 경우 2 유닛 추가
- 또는 ASG CPU 사용률 40% 이하로 떨어지면 유닛 하나 제거
- Scheduled Actions
- 사용 패턴을 바탕으로 스케일링 예상
- 예) 회사에서 5시에 이벤트를 시작하는 경우
- 이벤트로 인해 트래픽 수 증가가 예상될 때 ?개의 유닛 추가
- Target Tracking Scaling(대상 추적)
- Predictive Scaling(예측)
- AWS - ASG 활용하여 지속적으로 예측 생성 가능
- 로드(과거 사용량?)를 확인하고 다음 스케일링을 예측
- 예측된 결과에 해당하는 스케일링 진행
- 향후 많이 사용될 정책법
예측에 사용되는 로드(지표)
- CPUUtilization
- CPU 평균 사용량을 기준으로 활용
- RequestCountPerTarget
- 대상(인스턴스)별 미해결 요청의 수를 기준으로 활용
- 하나의 인스턴스는 최대 1,000개 요청까지 최적으로 작동
- Average Network In / Out
- 업/다운로드가 많아 인스턴스에 병목 현상이 발생할 것으로 판단
- 평균 네트워크 입출력량을 기반으로 임계값 도달시 스케일링 수행
- Any Custom metric
- 사용자가 애플리케이션 별로 지표를 설정하는 방법
스케일링 휴지
스케일링 작업이 끝날 때마다 5분(300초)의 휴지 기간을 갖음
휴지 기간 동안에는 ASG 가 추가 인스턴스의 실행/종료를 할 수 없음
이는 지표를 이용하여 새로운 인스턴스가 안정화될 수 있도록 하며
어떤 새로운 지표의 양상을 살펴보기 위함
Tip
즉시 사용 가능한 AMI를 이용하여 EC2 인스턴스 구성 시간을 단축
위 결과로 인스턴스 활성화 시간이 빨라지며 휴지 기간 또한 단축되므로
ASG 에서 더 많은 동적 스케일링이 가능해짐
또한 ASG가 일 분마다 지표에 접근할 수 있도록 세부 모니터링 기능을
설정하여 신속히 지표를 업데이트 해야함
스케일링 정책 실습
1.가장 먼저 아래 시작의 공통으로 ASG 리스트 중 1개 클릭
2.Automatic scaling Tab 클릭
Scheduled actions
1.Scheduled actions -> Create
2.이름, 용량 size, 주기, 시간 설정 후 Create
3.미리 예정되거나 사전에 알고 있는 이벤트에 대해서 작업 예약 진행
Predictive scaling policies
예측 스케일링 정책은 머신러닝 기반
1.Predictive scaling policies -> Create
2.이름, Metrics(지표), Target Utilization(대상 사용률) 설정
Metrics: CPU, Memories, 트래픽 등...
Target Utilization: CPU 사용량, Memories 사용량, 트래픽 수 등..
3.이 외에 추가 설정 값 적용 및 Create
4.위 설정값과 과거 데이터를 토대로 적용
Dynamic scaling policies
Policy type - Simple scaling: 하나의 CloudWatch(알람) 정책 설정
Policy type - Step scaling: 위 설정을 단계별로 여러개 등록
1.Dynamic scaling policies -> Create
2.Policy type -> Target tracking scaling 선택
3.Metric type -> Average CPU utilization 선택
4.Taget value: 평균 CPU 사용률 숫자(40) 입력 -> Create
5.생성된 정책을 확인하고 EC2 Instance 로 이동
6.EC2 Instance CLI Connect -> Stress Test 진행
7.Google 에 install stress amazon linux 2 검색
8.명령어를 CLI에 입력하여 stress 사용하기 위한 설치 작업 완료
9.CLI 에 stress - C 4 명령을 실행
10.한번에 cpu 4개를 사용하여 사용률을 100% 로 올림
11.Average cpu utilization = 40% 설정으로 인해 EC2 인스턴스가
추가 생성되는지 확인
12.스트레스 테스트를 종료하여 CPU 사용량을 원래대로 돌렸을 때
인스턴스가 줄어드는지 다시 확인
13.스케일인/아웃을 확인했으면 생성한 ASG 정책 제거
ASG 솔루션 아키텍트용
ASG 솔루션 설계자로서 알아야할 두 가지 사항
ASG 에서 인스턴스가 종료되는 방식
기본적인 ASG 기본 종료 정책, 좀 더 단순한 버전
1.가장 많은 인스턴스가 있는 AZ 찾음
2.AZ 안에 인스턴스가 여러개인 경우 가장 오래된 실행 구성, 실행 템플릿 인스턴스를 찾아서 삭제
3.기본 종료 정책을 사용하는 ASG 는 AZ 전체에 걸쳐 인스턴스 수의 균형을
맞추려고 함
수명주기 후크
ASG 에 의해서 생성되는 인스턴스는 바로 실행되나 실행되는 과정을 보면 긴 프로세스가 있음
1.인스턴스가 실행되면 Pending(보류 상태) 됨
2.Pending 상태에서 수명 주기 후크를 정의하면 Pending:Wait(보류 대기 상태) 됨
3.이 때 해당 인스턴스를 구성, 작업을 수행할 수 있는 옵션이 생김
4.위 작업을 수행후 Pending:Proceed(보류 진행 상태) 이후 서비스 시작
5.위 과정은 서비스가 실행되기 전 추가 소프트웨어를 설치할 수 있음을 의미
6.Terminating(종료 상태) 도 Pending 처럼 동일한 옵션 적용 가능
7.Terminating 에서 로그, 파일을 추출하는 용도로 사용 가능을 의미함
Launch Template vs Launch Configuration
둘 다 EC2 인스턴스의 AMI ID를 지정 가능
보안 그룹, 태그, EC2 사용자 데이터 등 원하는 파라미터 지정 가능
- Launch Configuration(Legacy)
- 단일 매개변수 변경시 다시 생성
- Launch Template(newer)
- AWS에서 사용 권장, 여러 버전을 가질 수 있음
- 파라미터 서브셋 사용하여 여러 템플릿에서 재사용 및 상속 구성 가능
- 온디맨드, 스팟 인스턴스를 사용 프로비저닝 가능
- 프로비저닝되면 비용 구조가 더 나은 스팟 플릿을 갖게 됨
