[AWS] Autoscaling : EC2 클러스터 구성 및 스케일링 정책 적용
해당 포스팅에서는 고가용성을 위한 Scale-out이 필요할 때 AWS EC2 인스턴스를 여러 AZ에 분산하여 운영하는 것을 자동화하여 지원하는 Autoscaling 기능에 대해서 살펴보려고 한다.
주요 목차
1. EC2 Autoscaling
- 직접 EC2 웹 서버의 Autoscaling 적용해보기 (시작 템플릿, Autoscaling Group)
2. Autoscaling 정책
- 동적 스케일링 정책 적용해보기
3. Autoscaling 기능 : Health Check, 축소 보호, StandBy, Instance Lifetime 관리
4. Auto Scaling Group 인스턴스 수명 주기
5. 인스턴스 유지관리 정책
6. 인스턴스 종료 정책
7. 비활성화
AWS에서 Scale out을 위한 고려할 수 있는 기술
- 인스턴스를 자동으로 프로비전 할 수 있는 방법 필요
- AWS Auto Scaling의 스케일링 정책을 설정하여 트래픽 증가 시 자동으로 EC2 인스턴스를 프로비전
- 인스턴스를 가용영역 별로 분산할 수 있는 방법 필요
- Auto Scaling Group에서 시작 템플릿(Launch Template) 을 설정하여 EC2 인스턴스를 여러 가용영역(AZ)에 분산
- Placement Group (Spread Strategy) : 단일 AZ 내에서도 인스턴스를 물리적으로 분리하여 장애 영역(Failure Domain) 간 분산
- 인스턴스 클러스터에 트래픽을 분산할 수 있는 방법 필요
- Elastic Load Balancing (ELB) : 인스턴스 클러스터에 트래픽을 자동으로 분산하여 애플리케이션의 가용성과 성능을 향상
- 인스턴스 각자가 상태를 저장하지 않고 (Stateless), 언제나 삭제되고 추가되도 무방한 방법 필요.
- 공유 저장소 활용 : S3, EFS (Elastic File System)
- 데이터베이스, 세션 관리 : RDS, Aurora, ElastiCache, DynamoDB
- ECS와 EKS : 컨테이너 기반으로 Autoscaling + ELB의 주요 목적을 구현할 수 있는 서비스.
AWS Auto Scaling
AWS Auto Scaling은 트래픽 증가나 인프라 장애 시 EC2 인스턴스를 자동으로 추가 또는 교체하여 시스템의 고가용성과 확장성을 유지하는 데 핵심적인 역할을 한다.
EC2, Aurora, DDB, ECS 등 다양한 서비스의 Scale-Out을 지원한다.
EC2 Autoscaling
EC2 인스턴스에 Auto Scaling을 적용한다는 것은 Scale-Out을 자동화한다는 것과 같은 의미다.
Auto Scaling Group은 동일한 애플리케이션을 실행하는 여러 인스턴스를 관리하며, 이를 여러 가용 영역(AZ)에 배치한다.
주요 목적 중 하나는 여러 개의 분산 인스턴스를 하나의 Auto Scaling Group으로 묶어 관리하며, 이를 여러 가용 영역(AZ)에 분배함으로써 특정 인스턴스에 장애가 발생하더라도 다른 인스턴스를 통해 서비스가 지속되도록 하는 것이다.
또한, 트래픽 및 부하 변화 등 스케일링 정책에 따라 인스턴스의 수를 자동으로 조정하여 유연한 규모 확장(Scale-Out)과 축소(Scale-In)을 지원한다.
- 특정 규모의 인스턴스를 보유하도록 보장 : 클러스터의 그룹의 최소, 최대 인스턴스 수 설정 등을 통해 엔지니어가 유지하고 싶은 규모를 설정할 수 있다.
- 스케일링 정책 적용 : CPU 부하량 등에 근거한 동적 스케일링, 스케줄 기반 스케일링 등 맞춤형 정책 적용 가능.
- 여러 AZ에 인스턴스 분배 : 특정 AZ에서의 장애 상황에서도 고가용성의 확보가 가능하다.
일반적으로 Auto Scaling Group과 함께 ELB(Elastic Load Balancer)는 거의 필수적으로 함께 아키텍쳐를 구성한다.
위의 그림은 Auto Scaling Group과 ELB의 조합을 통해 트래픽을 분산하고, 애플리케이션의 동작을 유지하는 구조를 보여준다.
Auto Scaling만 사용했을 경우의 가장 큰 문제점은, 클라이언트가 각 EC2의 Public Address에 직접 접근해야 하기 때문에 단일 진입점이 존재하지 않는다. 동적으로 새로 추가되거나 삭제된 인스턴스를 클라이언트가 인식하기 어렵기 때문에 라우팅 처리가 어렵다.
ELB는 인터넷 게이트웨이에서 들어오는 모든 트래픽을 받아 Auto Scaling Group 내의 인스턴스에 고르게 분배한다. 이 과정에서 트래픽은 각 AZ에 있는 서브넷을 통해 전달된다. 또한 비정상 인스턴스를 감지하여 해당 인스턴스로는 트래픽을 보내지 않는 등 장애에 대처할 수 있다.
Autoscaling Group의 구성 요소
시작 템플릿 (Launch Template)
Auto Scaling Group에서 EC2 인스턴스를 생성할 때 필요한 설정 정보를 정의한다. 즉 클러스터를 구성하는 EC2의 설정을 하는 것이다.
해당 템플릿을 바탕으로 Scale-Out 시 클러스터에 EC2를 추가하게 된다.
- 인스턴스 유형, AMI, 보안 그룹, 키 페어, IAM 역할 등 EC2 인스턴스를 생성할 때의 내용들과 유사하다.
Autoscaling 정책 및 모니터링
Auto Scaling Group이 언제 인스턴스를 추가하거나 제거할지 결정하기 위한 정책을 설정한다. 해당 정책을 기반으로 클러스터의 Scale-Out(추가), Scale-In(제거)를 결정한다.
- AWS CloudWatch / ELB 등과 연계하여 상태 확인을 기반으로 함.
동작 설정
관리하는 EC2 인스턴스의 수를 얼마나, 어떻게 조정할지에 대한 설정을 정의한다.
- 최소, 최대, 원하는 인스턴스 수를 설정하여 클러스터의 규모를 제어.
- ELB와 연동하여 트래픽 분배 및 상태 확인을 통해 동작 자동화.
- 종료 정책 적용 : 기본적으로 가용 영역 내에서 균형을 유지하며 인스턴스를 종료. 커스텀 설정 또는 Lambda로 동적 종료 정책 구현 가능.
직접 EC2 Autoscaling 적용해보기
1. 시작 템플릿 생성
EC2 -> 시작 템플릿 -> 시작 템플릿 생성에서 Auto Scaling Group에서 EC2 인스턴스를 생성할 때 필요한 설정 정보를 작성하자. 해당 템플릿을 기반으로 인스턴스가 추가되어야 할 때 새로운 EC2 인스턴스가 생성될 것이다.
시작 템플릿은 버전 관리가 가능하며, 기본적으로 수정 시 버전이 업데이트되도록 설정된다.
1-1. AMI 설정
Amazone Linux 이미지를 선택하였다.
1-2. 인스턴스 유형과 키 페어 설정
프리티어에서 제공하는 t2.micro 타입과, SSH 키페어를 등록해주었다.
1-3. 네트워크(VPC) : 보안 그룹 설정
일단 들어오는 모든 트래픽을 처리하도록 보안 그룹을 구성하였다.
1-4. 스토리지 설정 (EBS)
루트 디바이스 EBS만 설정해주었다.
1-5. IAM 프로파일
IAM Role을 사용할 수 있도록 프로파일을 지정해주었다. (뒤에 등장하는 유저데이터 설정에서 EC2 메타데이터를 사용하기 위한 Role)
1-6. User Data 설정
EC2 인스턴스가 신규 생성되어 초기화 될 때 자동으로 웹 애플리케이션 서버를 구성하도록 유저데이터를 설정해주었다.
아래의 내용은 기본 HTTP 서버를 구축하여, 80번 포트로 접근 시 index.html을 제공하도록 설정한 것이다.
해당 index.html에는 EC2 Meta Data를 활용하여 EC2 ID를 제공하도록 하였다. 이것은 추후 ELB까지 적용했을 때 Autoscaling된 다수의 인스턴스에 고르게 인스턴스가 분배된다는 것을 확인할 목적으로 작성되었다.
대충 Public IP 주소로 접속하면 이런 형태의 HTML이 띄워지는 HTTP 서버를 자동으로 구축하는 스크립트라고 생각하면 된다.
<함께 보기>
EC2의 주요 구성 요소
2. Autoscaling 그룹 생성
2-1. 시작 템플릿 선택
이전에 만든 시작 템플릿을 지정하여, 스케일 아웃 시 해당 템플릿을 기반으로 인스턴스를 생성하도록 한다.
앞에서 언급한 시작 템플릿의 버전을 함께 설정할 수 있다.
2-2. 인스턴스 시작 옵션 선택
VPC는 사용자 정의 내부망의 개념이었다. 즉 상호작용할 서비스들과 함께 공유할 VPC로 지정해주어 네트워킹이 가능하도록 한다.Autoscaling의 목적 중 하나는 고르게 가용 영역에 분배하는 것이었다. 따라서 분배할 가용 영역들을 지정해준다. 해당 포스팅에서는 ap-northeast-2의 모든 가용영역에 고르게 분배하도록 지정하였다.
2-3. 다른 서비스와의 통합
ELB를 비롯한 다른 서비스와 Auto Scaling을 연결시켜주는 부분이다. 현재는 ELB에 대한 포스팅이 아니므로 넘어가고, 다음 포스팅에서 Autoscaling Group과 ELB를 연동시키는 과정을 다루어보겠다.
2-4. 그룹 크기 및 크기 조정 구성
클러스터의 EC2 인스턴스의 수의 범위를 설정하는 부분이다. 해당 범위 안에서 Auto-scaling이 작동된다.
- Minimum Size : Auto Scaling Group 내에서 유지해야 할 최소 EC2 인스턴스 개수
- Maximun Size : Auto Scaling Group 내에서 유지해야 할 최대 EC2 인스턴스 개수
- Desired Capacity : 현재 상황에서 Auto Scaling Group이 실행해야 하는 EC2 인스턴스의 목표 개수, MIN-MAX 범위 안에서 설정됨.
다음과 같은 추가 선택사항들이 보이는데, 해당 기능들에 대해서는 해당 포스팅 뒤에서 정책을 다룰 때 설명하겠다.
앞에서 Autoscaling 정책은 AWS CloudWatch 지표에 기반하여 사용될 수 있다고 하였다. (그리고 가장 많이 사용되는 방식이다)
따라서 CloudWatch 내에서 그룹 지표 수집 활성화는 미리 선택해두고 넘어가도록 하자. 활성화를 해 두어야 CloudWatch에서 Auto Scaling Group을 감지하기 시작한다.
Amazone CloudWatch
애플리케이션, CPU 지표 등을 비롯한 운영 상태에 대한 모니터링 서비스. EC2를 포함한 다양한 서비스에 대한 기본적인 모니터링 지원
EC2의 지표 : 기본적으로 무료 (5분 단위), 세부 모니터링 (1분 단위) 시 비용 발생
Autoscale 지표 : 무료지만 활성화 필요
- 주요 지표 : 용량(Min/Max/Desired), 인스턴스 상태(서비스 중, 종료, 멈춤 등), 기타 관리중인 인스턴스 모두의 통합 지표 제공
- 내부적인 Autoscaling의 알람, 타겟 추적 스케일링 정책 등은 CloudWatch 기반으로 작동한다.
2-5. 기타 설정
알림 추가 : Auto Scaling 그룹에서 발생하는 이벤트(예: EC2 인스턴스 시작, 종료, 장애 등)에 대한 알림을 설정하는 과정이다. AWS에서는 Amazone SNS라는 서비스를 통해 해당 기능을 제공한다.
태그 추가 : 태그 키와 값을 입력하여 리소스를 식별할 수 있도록 한다. 만약 아래처럼 Name Key에 My-ASG라는 태그를 부여하면, 그룹에 속한 EC2 인스턴스의 접두사로 사용되어 My-ASG-xxxxyyy와 같은 인스턴스명이 부여된다.
3. 생성 결과 확인
생성된 Auto Scaling 그룹의 인스턴스 관리를 확인해보면 원하는 용량(Desired Capacity)인 3개의 인스턴스가 2~3 Min-MAX범위 안에서 생성되어 동작하는 것을 확인할 수 있다.
EC2 인스턴스 관리에서도 확인해보면 3개의 EC2가 돌아가고 있다는 것을 확인할 수 있다. 그리고 세 개의 가용 영역(AZ)에 고르게 분산되어 작동하고 있는 것 까지 확인해 볼 수 있겠다.
각각의 EC2 인스턴스의 Public IP에 들어가보면 웹 서버에 의해서 HTML에 Instance ID가 표시되는 것을 확인할 수 있다.
처음에 언급했듯이 Auto-scaling 만으로는 단일 진입점이 존재하지 않아 라우팅 처리가 어렵다는 점을 기억할 것이다. 따라서 다음 포스팅에서 로드밸런서를 연동하는 것을 다루어 볼 예정이다.
일단 자동으로 Scale-Out 되도록 구성까지는 완료했다는 것에 의의를 두자.
<함께 보기> EC2 Autoscaling + ALB (Application Load Balancer)
https://sjh9708.tistory.com/252
[AWS] ELB : 개념 및 구성 요소 (+ EC2 Autoscaling X ALB 적용)
이전 포스팅에서 Auto scaling group을 통해서 EC2 인스턴스를 자동으로 Scale-out하여 관리하는 방법에 대해서 알아보았었다.이번에는 해당 클러스터 (혹은 단일 EC2 인스턴스)를 로드밸런서에 연결해보
sjh9708.tistory.com
Autoscaling 정책 적용
Autoscaling 그룹까지 구성했다면 의문이 들 것이다. 해당 서비스는 어떤 기준으로 EC2 인스턴스를 클러스터에 추가하고 제거하는 것을 결정하는 것인가?
앞에서 잠깐 언급했지만 이것에 대한 Autoscaling 정책을 설정할 수 있다고 하였다. 해당 정책을 기반으로 클러스터의 Scale-Out(추가), Scale-In(제거)를 결정한다.
Autoscaling 정책 종류
수동 스케일 : 수동으로 직접 인스턴스 숫자 증감하는 방식. 별도 정책을 설정해두지 않았다면 수동으로 조절해야 한다.
- 주로 개발 환경 혹은 다른 정책을 적용하기 전 사전 테스트 용도 활용. 보통 다른 스케일 정책을 비활성화한 상태에서 사용한다.
스케줄기반 스케일 : 특정 시점에 인스턴스 범위 조절 → 예측 가능한 시점의 부하처리
- 어떤 시점이 될 때, 어떤 범위로 설정할 것인가에 대한 설정을 한다.
- 시점 결정 (해당 시점 OR Cron Express)
- 범위 지정 (Min, Max, Desired 셋 중 최소 한 가지)
동적 스케일 : 특정 기준치에 따라 인스턴스 숫자 증감 → CPU 사용률, 요청 수 등에 대한 유연한 대응
- 주로 CloudWatch의 지표를 활용
- Autoscale에서 지원하는 추적 조정 정책(Target Tracking Policy) 활용
- 내부적으로 CloudWatch 경보(Alarm)을 생성하여 반응
- 지표 증감에 따라 얼마나 민감하게 반응할 것인지 결정 가능
- 필요 시 특정 기준에 따라 커스텀 로직 적용 가능 (Kafka 등의 큐의 대기량에 반응하는 등)
예측기반 스케일 : 과거 기록의 패턴을 기반으로 수요량 예측
- CloudWatch 지표를 분석하여 패턴으로 생성할 수 있음.
- 유의점
- 수요량에 따라 증가만 가능. 인스턴스 숫자를 감소시키려면 동적 스케일링 정책 필요
- Autoscale Group에 다양한 인스턴스 종류가 섞여있을 경우 효율성이 떨어짐
- 다양한 스케일링 정책이 공존하면 정확성과 효율성이 떨어짐
- 충분한 데이터가 쌓일 때 까지 기다림 필요.
동적 스케일링 적용해보기
동적 스케일링은 CPU 사용률, 요청 수 등 특정 지표에 따라 인스턴스 숫자를 조절하도록 설정하는 것이라고 하였다. 주로 CloudWatch의 지표를 기반으로 한 Alerm을 발동 조건으로 사용한다.
위의 사진과 같이 평균 CPU 사용률이 50% 이상이 되면 동적으로 스케일을 높이도록 설정해보자.
동적 스케일의 발동 시점은 CloudWatch의 경보가 발생하는 시점이다.
CloudWatch에서 경보(Alarm)이란, 지정된 모니터링 지표(Metrics)가 설정한 조건을 초과하거나 미달할 때 이를 감지하여 알림 또는 동작을 트리거하는 기능이다.
동적 스케일링 설정을 통해서 CloudWatch에 두 개의 경보가 생성되었다.
- EC2 인스턴스의 CPU 사용률이 3분 동안 50%를 초과할 경우 경보가 발생 → Scale-Out 수행
- EC2 인스턴스의 CPU 사용률 15분 동안 45% 미만일 경우 경보가 발생 → Scale-In 수행
조건을 보면 눈치챌 수 있는 점 중 하나는 Scale Out에 비해서 Scale In은 보수적인 전략을 사용한다는 것을 알 수 있다. 보통 인스턴스 수를 줄인다는 것은 자원을 절약하는 대가로 가용성을 떨어뜨린다는 것이기 때문에 신중한 접근이 필요하기 때문이다.
CPU 사용률을 50% 이상으로 증가시키기
실험을 위해서 초기 인스턴스의 수를 1개로 조정해두었다. 우리는 해당 인스턴스의 CPU 사용률을 50% 이상으로 부하를 발생시켜 동적 스케일링에 의해 인스턴스가 2개로 증가하는지를 확인해 볼 것이다.
CloudWatch에서 아래와 같은 지표를 확인할 수 있다. 경보가 발생해야 하는 조건은 "3분간 CPU 사용률 50% 이상 초과" 였다.
Autoscaling의 지원 기능
Autoscaling 헬스체크
인스턴스의 상태를 체크하는 기능 → 상태 확인 시 Unhealthy 상태로 변경, 인스턴스 교체
상태 확인 소스 : EC2 (Autoscaling) vs ELB까지 적용
- EC2 : 인스턴스의 실행 여부 및 하드웨어 지표를 바탕으로 정상 여부 확인. → Application의 정상 작동 여부는 체크할 수 없다.
- ELB : 트래픽을 발생시켜 수행 여부 확인. → 즉 Application의 정상 작동 여부까지 체크할 수 있다.
Health Check Grace Period : 새 인스턴스의 초기화 시간을 고려하여 Health Check를 통과할 준비를 마칠 때까지 유예 기간을 제공하는 설정 (기본 300초)
Warm Up : 새 인스턴스의 초기화 작업에는 CPU 등의 지표가 이질적일 수 있음. 초기 작업을 마치고 안정적인 성능 지표를 제공할 때까지 기다리는 시간을 설정.
Instance Scale-In protection (축소 보호)
디버그 목적 혹은 현재 작업중인 특정 로직을 끝까지 수행할 수 있도록 인스턴스의 종료(Scale-In)을 막는 기능.
인스턴스 수명 (Lifetime) 관리
인스턴스가 최대로 실행되어 있는 기간 설정 가능 → 해당 기간 이후 자동으로 교체.
축소 보호(Scale-In Protection와과 동시에 설정되어 있을 경우 우선순위가 낮음.
StandBy
인스턴스의 Autoscale 관리 임시 해제.
- ELB의 트래픽을 받지 않고, HealthCheck도 비활성화됨.
- StandBy 된 인스턴스는 Autoscale 정책의 Capacity에서 집계에 포함되지 않음. 즉 인스턴스 범위에서 없는 취급 받게 된다.
위의 그림처럼 인스턴스 1개를 Standby 상태로 만들 시, 클러스터의 스케일을 유지하기 위해서 새로운 인스턴스가 Pending 상태로 올라가 있는 것을 확인할 수 있다. (해당 수명 주기에 대해서는 바로 뒤에서 설명하겠다.)
Auto Scaling Group 인스턴스 수명 주기 (Instance Lifecycle)
위에서 설명한 내용들의 사진들에서 클러스터에 속한 인스턴스의 "수명 주기"가 항상 함께 보였을 것이다.
Auto Scaling 그룹에서 각 인스턴스가 생성되고 종료될 때 까지의 상태를 정의한 것으로. 아래의 그림과 같이 표현한다.
1. 생성 : Pending → InService
2. 작동 중 : InService
3. 종료 : Terminating → Terminated
4. 대기 (Standby) : InService → Standby → InService
5. 분리 (인스턴스가 더 이상 Auto Scaling 그룹에서 관리되지 않음) : InService → Detaching → Detached
인스턴스 유지 관리 정책
인스턴스 유지 관리 정책은 Auto Scaling 그룹에서 비정상 인스턴스 등의 사유로 인스턴스를 교체해야 할 때의 절차와 방식을 설정할 수 있다.
예를 들어 기존 인스턴스가 Unhealthy 상태로 돌입하여 기존 인스턴스를 종료하고 신규 인스턴스를 프로비저닝 한다면 "종료를 먼저 할 것인가?" "프로비저닝 완료를 먼저 하고 종료할 것인가?" 등을 결정할 수 있다.
기본 정책
- Health-Check 실패, 인스턴스 교체, 인스턴스 LifeTime : 인스턴스 종료와 새로운 인스턴스 실행 동시에 수행
- Rebalance (재조정) : 실행 후 종료 (최대 10% 단위)
커스텀 정책
- Launch before terminating (종료 전 시작) : 프로비전 후 종료할 인스턴스 종료 (최대 프로비전 비율 설정)
- Terminate and launch (종료 및 시작) : 종료와 프로비전 동시에 수행 (최대 종료 비율 설정)
- Custom behavior (사용자 지정 동작) : 종료 이후 프로비전 시의 상세 비율 조절. (최대 종료 비율 및 최대 프로비전 비율 설정)
인스턴스 종료 정책
Auto Scaling 그룹이 인스턴스를 축소해야 할 때 어떤 인스턴스를 먼저 종료할지 우선순위를 결정하는 정책이다.
- 기본값: 기본적으로 스팟 인스턴스 먼저 종료 →가장 오래된 인스턴스 순서로 종료
- 합당 전략: AWS 상의 합당 전략 알고리즘을 사용한 최적의 인스턴스 종료
- 다음 인스턴스 시간과 가장 가까움: 다음 생성될 인스턴스와 시간이 가장 가까운 인스턴스 순서로 종료
- 최신 인스턴스: 최근에 생성된 인스턴스 순서로 종료
- 가장 오래된 인스턴스: 오래된 인스턴스 순서로 종료.
- 가장 오래된 시작 구성: 오래된 AMI 또는 설정으로 생성된 인스턴스 순서로 종료
- 가장 오래된 시작 템플릿: 오래된 시작 템플릿을 사용해 생성된 인스턴스 순서로 종료
- 사용자 지정 종료 정책: 사용자가 설정한 조건에 따라서 종료
비활성화
디버깅 등의 목적으로 임시로 Auto Scaling의 다양한 기능을 비활성화가 가능하다.
- Launch : 신규 인스턴스 시작 Scale-Out 비활성화
- Terminate : 인스턴스의 Scale-In이 필요할 때 인스턴스 중지 비활성화
- AddToLoadBalancer : ELB에 인스턴스 등록 중지
- AZRebalance : 가용영역에 고르게 인스턴스를 분배하는 기능 중지
- HealthCheck : 헬스체크 비활성화
- ReplaceUnhealthy : Health Check에 실패한 인스턴스의 중지 비활성화 (디버깅에 유용한 옵션)
References
https://docs.aws.amazon.com/
docs.aws.amazon.com
쉽게 설명하는 AWS 기초 강의 강의 | AWS 강의실 - 인프런
AWS 강의실 | AWS 여정을 시작하기 위해 가장 필요한 내용을 담았습니다., 안녕하세요. AWS 강의실입니다.AWS 공식 커뮤니티 빌더이자 2만명의 구독자를 보유한 AWS Only 강의 유튜브의 경험으로 AWS를
www.inflearn.com
'Cloud > AWS' 카테고리의 다른 글
| [AWS] ELB : 개념 및 구성 요소 (+ EC2 Autoscaling X ALB 적용) (0) | 2025.01.15 |
|---|---|
| [AWS] EC2 : ENI & Elastic IP 설정을 통한 Public IP 고정시키기 (1) | 2025.01.13 |
| [AWS] EC2 : 유저데이터와 메타데이터 (EC2 User Data & Meta Data) (0) | 2025.01.13 |
| [AWS] EC2 : 주요 구성 요소와 인스턴스 생성 및 연결 방법 (0) | 2025.01.12 |
| [AWS] IAM : 인증과 접근 방식 (장기 자격 증명 & 임시 자격 증명) (0) | 2025.01.11 |
