AWS 용어
1.Region
AWS에서 사용하는 일종의 IDC의 집합으로서 거의 모든 클라우드 서비스가 탑재되는 곳으로 다수의 Availability Zone으로 구성
한 곳의 AZ가 기능마비되더라도 다른 AZ가 기능을 수행
전세계 주요 대도시에 분포
AWS 사용자는 각 Region마다 별도의 클라우드망을 구성
2.Availability Zone
가용 영역이라 불리우며 IDC, 즉 데이터센터의 역할
보통 3~4개의 AZ가 각 Region마다 존재
하나가 파괴더라도 다른 AZ가 기능을 수행
네트워크 구성에서 하나의 서브넷은 하나의 AZ를 의미
3. On-premise
클라우드 방식이 아닌 자체적으로 보유한 전산실과 같은 인프라를 의미
Edge Location
CDN 서비스인 Cloudfront가 사용하는 캐시서버
전세계에 분포되어있으며 Edge Location끼리 데이터를 공유
4. 탄력성(Elasticity)과 확장성(Scalability)
탄력성은 AWS의 상징과도 같은 서비스인 Autoscaling처럼 단시간에 갑작스러운 요구에 따라 사용량을 늘리거나 줄이는 것을 의미(Scale out)
확장성은 장기적인 관점, 즉 아키텍쳐적인 관점에서 예상치를 충분히 감당할 수 있는 리소스를 보유하는 것을 의미(Scale up)
5. Elastic Compute Cloud
가상 서버를 제공하는 서비스
실제 물리서버와 똑같은 형태의 서비스를 제공하며 Linux나 Window 같은 기본 운영체제가 설치
SSH로 원격 연결이 가능(공인 IP가 있는 경우 직접 연결 가능)
기본 동작으로는 시작, 중지,종료,재부팅이 있다.
중지가 가능한 디스크 기반 인스턴스인 EBS 기반 인스턴스와 임시 스토리지를 제공하여 중지가 불가능한 Instance Store 기반 EC2로 나누어진다.
재부팅의 경우 EBS 기반 EC2와 인스턴스 스토어 기반 EC2 모두 사용 가능하나 중지는 EBS기반 EC2만 가능(예: efs, ecs 등은 안됩니다.)
인스턴스 유형으로는 범용, 컴퓨팅 최적화, 메모리 최적화, 스토리지 최적화가 있다.
6. EC2 상태
Pending : 인스턴스가 구동하기 위해 준비중인 상태, 요금 미청구
Running : 인스턴스를 실행하고 사용할 준비가 된 상태, 요금 청구
Stopping : 인스턴스가 중지 모드로 전환되려는 상태, 요금 미청구
Shutting-down : 인스턴스가 종료할 준비중인 상태, 요금 미청구
Terminated : 인스턴스가 종료된 상태, 요금 미청구
7. EC2 구매 옵션
온디맨드(On Demand) : 필요할 때 바로 생성하여 사용하는 방식으로 1시간 단위로 과금이 이루어짐, 1분을 사용하더라도 1시간 과금을 물리는 방식
스팟(Spot) : 경매 방식의 인스턴스, 최초 생성시 기준가격이 화면에 나타나며 화면의 가격보다 높은 가격을 제시하면 계속 사용이 가능함. 그러나 다른 사람이 더 높은 가격을 입찰했다면 인스턴스가 종료됨. 불시에 중단되어도 상관없거나 각종 테스트에 적합
예약(Reserved) : 12개월 또는 36개월 단위로 예약하여 사용하는 인스턴스로 온디맨드에 비해 가격이 대폭 할인됨. 장기적으로 사용할 경우 추천, 예약 인스턴스이기 때문에 사용하지 않더라도 요금이 부과
8. AMI
Amazon Machine Image
인스턴스를 시작하는데 필요한 정보를 제공하는 소위 '이미지'
AMI를 지정하여 인스턴스를 생성할 수 있다.
EBS 지원 AMI와 인스턴스 스토어 지원 AMI로 나누어진다.
EBS 지원 AMI는 후술할 EBS 스냅샷에서 루트 디바이스 스토리지가 생성되며, 인스턴스 스토어 지원 AMI는 S3에 저장된 템플릿에서 생성된 스토어 볼륨을 사용
AMI와 연결된 스냅샷은 지울 수 없다
다른 리전으로 복사가 가능하며 권한을 준다면 다른 계정과도 공유 가능
AWS Market Place에서 다른 사람이 만들어둔 AMI를 쓰거나 공유 가능
9. Elastic IP
EC2에 설정되는 네트워크 인터페이스의 공인 IP
EC2가 기본적으로 갖는 Public IP와 Private IP 등과는 구분
Elastic IP를 사용하면 EC2로 하여금 중지되었다가 다시 시작하더라도 고정된 공인 IP를 사용
Elastic IP는 계정 내 리전당 최대 5개까지 보유 가능하며 그 이상 필요시 AWS에 요청
프리티어의 경우, 사용 중이 아닐 땐 요금이 부과됨
10. Key Pair
EC2는 SSH 접속시 key pair라고 하는 퍼블릭 키 암호화 기법을 사용하여 접속하며 로그인 정보를 암호화 및 해독함
Key Pair 분실시 접속 불가
또한 접속시 OS 별로 접속 name이 다름(Linux : EC2-USER, centos, ubuntu 등)
11. Batch Group
클러스터 : 인스턴스를 AZ 내에서 근접하게 배치함. 결합된 노드간 낮은 지연 시간의 네트워크 달성 가능
파티션 : 인스턴스가 담긴 그룹을 논리 세그먼트로 나누어 각 파티션애에 배치함. 최대 7개의 파티션을 가질 수 있으며, 각 파티션은 자체 랙 세트를 보유하고 자체 네트워크와 전원을 보유
분산 : 파티션이 논리 세그먼트로 분리된 인스턴스 그룹인 것과 달리 분산은 '인스턴스' 개체 하나가 자체 랙에 분산 배치됨. AZ당 최대 7개의 인스턴스 배치 가능
12. Elastic Block Store
EBS 지원 EC2가 갖는 블록 형태의 스토리지
애플리케이션의 기본 스토리지로 쓰거나 시스템 드라이브용으로 쓰기 적합
인스턴스 생성시 루트 디바이스 볼륨이 생성되며 사용중에는 언마운트할 수 없다
또한 인스턴스는 여러 볼륨을 마운트할 수 있고 추가볼륨에 대해서는 사용중이라도 마운트/언마운트가 가능
볼륨은 여러 인스턴스에 마운트할 수 없다
EBS를 특정 AZ에서 생성하더라도 다른 AZ의 인스턴스에 즉시 붙일 수 있다
인스턴스 스토어 볼륨과는 달리 EBS 기반 인스턴스는 중지 / 재시작이 가능
사용중인 EBS더라도 볼륨 유형과 사이즈를 변경할 수 있음(사이즈 축소는 불가)
13. EBS 볼륨 유형(중요!)
범용 SSD(gp2) : 시스템 부트 사용 가능, 대부분의 워크로드에서 사용
프로비져닝된 IOPS SSD(io1) : 지속적인 IOPS 성능이나 16,000 IOPS 이상의 볼륨당 처리량을 필요로 하는 경우 적합(DB 워크로드)
처리량 최적화된 HDD(st1) : 시스템 부트 사용 불가능, IOPS가 아닌 처리량을 기준으로 하며 자주 액세스하는 워크로드에 적합한 저비용 HDD 볼륨, 빅데이터나 데이터 웨어하우스에 사용
Cold HDD(sc1) : 시스템 부트 사용 불가능, 자주 액세스하지 않는 대용량 데이터 처리에 적합, 스토리지 비용이 최대한 낮아야 할 경우 사용
14. 스냅샷과 EBS
스냅샷을 이용하여 EBS 볼륨의 데이터를 S3에 저장할 수 있음, 증분식 백업이기 때문에 스냅샷은 하나이며 마지막 스냅샷 이후 변경된 블록만 추가적으로 저장
각 스냅샷에는 스냅샷을 만든 시점의 데이터를 새 EBS 볼륨에 복원하는 데 필요한 정보가 들어있다.
EBS의 스냅샷은 S3에 저장되며 S3에 저장된 스냅샷으로 EBS 볼륨 복구 가능
암호화된 볼륨의 스냅샷은 자동으로 암호화
암호화된 스냅샷에서 생성되는 볼륨은 자동으로 암호화
암호화되지 않은 EBS에서 암호화된 스냅샷은 생성할 수 없다.
15. EBS 암호화
EBS를 암호화함으로써 부팅 및 데이터 볼륨을 모두 암호화할 수 있다.
다음 유형의 데이터가 암호화
볼륨 내부 데이터
볼륨과 인스턴스 사이에서 이동하는 데이터
볼륨에서 생성된 모든 스냅샷
스냅샷에서 생성된 모든 볼륨(스냅샷이 암호화되면 해당 스냅샷에서 생성된 볼륨은 자동 암호화)
AES-256 알고리즘 사용
16. RAID 구성
RAID 0 : I/O 성능이 내결함성보다 더 중요한 경우
RAID 1 : 내결함성이 I/O 성능보다 더 중요한 경우
17. Simple Storage Service
웹서비스 인터페이스(HTTP)를 이용하여 웹에서 언제 어디서나 원하는 양의 데이터를 저장하고 검색할 수 있는 스토리지
버킷(Bucket)과 객체(Object)로 나뉘며, 저장하고자 하는 모든 요소는 하나의 객체로 저장되고, 오브젝트를 담는 곳이 바로 버킷
S3 자체는 글로벌 서비스이지만 버킷을 생성할 때에는 리전을 선택해야 함
객체는 객체 데이터와 메타 데이터로 나뉘며, 각자의 고유한 URL을 가지며 해당 URL로 접속 가능
18. 버킷(Bucket)의 정의와 특징
객체를 담고 있는 구성요소
크기는 무제한이며, 리전을 지정하여 버킷을 생성해야 함
버킷의 이름은 반드시 고유해야하며 중복될 수 없음
한 번 설정된 버킷의 이름은 다른 계정에서 사용할 수 없음
19. 객체(Object)의 정의와 특징
S3에 업로드되는 1개의 데이터를 객체라 함
키, 버전 ID, 값, 메타데이터 등으로 구성됨
객체 하나의 최소 크기는 1(0) byte ~ 5TB
스토리지 클래스, 암호화, 태그, 메타데이터, 객체 잠금 설정 가능
객체의 크기가 매우 클 경우 멀티파트 업로드를 통해 신속하게 업로드 가능
20. 객체의 스토리지 클래스(중요!!)
객체의 접근빈도 및 저장기간에 따라 결정되는 객체의 특성
Standard Type : 클래스를 선택하지 않을 경우 선택되는 일반적인 클래스
Standard_IA(Ifrequent Access) : 자주 액세스하지는 않지만 즉시 액세스할 수 있는 데이터여야 하는 경우 선택되는 클래스
One Zone_IA : Standard_IA와 기능은 동일하나 Standard_IA의 경우 세 곳의 AZ에 저장되는 것과 달리 한 군데의 AZ에만 저장되어 해당 AZ가 파괴될 경우 정보 손실 가능성 존재(저장요금이 적음)
Intelligent tiering : 액세스 빈도가 불규칙하여 빈도를 가늠하기 어려운 경우 선택되는 클래스
Glacier : 검색이 아닌 저장이 주용도인 스토리지로 저장요금이 위 클래스들보다 훨씬 저렴함. 다만 저장이 주용도이기 때문에 검색에 3~5시간이 걸림
Glacier Deep Archive : 10년 이상 저장할 데이터를 저장하는 스토리지 클래스
21. Multi-part Upload
오브젝트의 크기가 클 경우, 이를 조각내어 병렬적으로 처리하여 처리량을 개선하는 방법
보통 객체의 크기가 100MB 이상일 경우 사용하는 것을 권고하며 최대 가능 크기는 5TB
조각의 갯수는 최대 1만개까지 가능하며, 조각의 크기는 대개 5MB~5GM 정도임
22. Version management(중요!)
동일한 객체에 대해 여러 버전을 가질 수 있도록 하는 기능
이미 S3에 존재하는 객체에 내용을 변경하여 업데이트할 경우 기존 버전이 사라지지 않고 이전 버전으로 존재할 수 있음
최신 버전과 이전 버전 모두 확인 가능
객체를 삭제하더라도 바로 삭제되는 것이 아닌 삭제 마커를 붙여 다시 복구할 수 있는 기능 제공
23. Lifecycle management(중요!)
S3에 있는 오브젝트를 일정 시간 후에 다른 타입으로 변경하는 것을 의미
예를 들어, 자주 사용하던 Standard Type의 오브젝트를 60일 이후 더 이상 사용하지 않을 경우 Glacier Type으로 변환하여 비용을 줄일 수 있음
현재 버전과 이전 버전에 대해 설정 가능
또한 완료되지 않은 멀티파트 업로드와 버전관리가 적용된 오브젝트의 삭제 마커를 정리할 수 있음
더 이상 사용하지 않은 오브젝트에 대해 만료기간을 설정하여 정한 기간 후 삭제하도록 설정 가능(만료 기간 설정)
Standard-IA와 One Zone IA는 보관 후 30일 이후 이전 가능
24. 정적 웹 사이트 호스팅
S3로 하여금 정적 페이지를 제공할 수 있는 호스팅 기능을 제공하게 하는 것
활성화 후 특정 페이지를 지정하면 S3 접속시 해당 페이지를 띄움
굳이 서버를 이용하지 않고 S3를 이용하여 웹 호스팅을 할 수 있음
호스팅 뿐만 아니라 요청을 다른 버킷 혹은 도메인으로 리디렉션 가능
25. 기본 암호화(중요!)
암호화는 Client side와 Server side로 나뉘며 Client side는 Client에서 S3로 전송될 때의 암호화(data at transit)을, Server side는 S3에 저장될 때의 암호화(data at rest)를 의미함
Server Side Encryption
SSE-S3 : S3의 고유한 키로 암호화를 실시하며 암호화 주체가 S3가 되는 방식. 암호 알고리즘은 AES-256.
SSE-KMS : Key Management Service를 이용하여 객체를 암호화하는 방식으로 KMS 고객 마스터 키(CMK)를 활용함. SSE-S3와 달리 고객에 키를 제어할 수 있음
SSE-C : 고객(Customer)가 제공하는 키로 암호화를 진행하는 방식으로 제공된 암호화 키를 사용하여 디스크를 쓰거나 해독할 때 객체에 액세스할 때의 모든 암호화를 관리함. 제공된 암호화키는 저장되지 않음
Client Side Encryption
S3로 데이터를 보내기 전의 암호화
KMS에 저장된 고객 마스터키를 사용하여 암호화
애플리케이션 내 마스터 키를 사용하여 암호화
26. 전송 속도 향상(Transfer Acceleration)
Cloudfront의 Edge Location을 이용하여 파일 업로드를 보다 빠르게 하는 기능
S3로 직접 업로드하는 것이 아닌 가장 가까운 Edge Location으로 전송하고 아마존 백본 네트워크를 통해 S3로 도달
27. Cloudfront의 개요와 Edge Location
CDN(Content Delivery Network)
간단히 말하여 HTTP / HTTPS를 이용하여 S3 및 ELB, EC2, 외부 서버 등을 캐시하고 보다 빠른 속도로 콘텐츠를 전달하는 캐시 서버
전 세계 각지에 퍼져 있는 Edge Location의 주변 Origin Server의 콘텐츠를 Edge Location에 캐싱하고 각 Edge Location간 공유를 통해 콘텐츠를 전달
Distribution은 Edge Location의 집합을 의미
각 Edge Location간에는 아마존의 백본 네트워크를 통하기 때문에 매우 빠른 속도로 전달 가능
위에서 언급한 것처럼 S3, ELB, EC2 등의 AWS 서비스뿐만 아니라 외부의 서버도 캐싱 가능(이를 Custom Origin이라 함)
TTL을 조절하여 캐시 주기를 통제할 수 있음
28. 콘텐츠 제공 방법
사용자가 웹 사이트 혹은 앱에 액세스하고 이미지 혹은 HTML 파일을 요청함(정적 데이터)
DNS가 요청을 최적으로 서비스할 수 있는 Cloudfront Edge Location으로 요청을 라우팅함
Edge Location에서 해당 캐시에 요청된 파일이 있는지 확인하고 없으면 오리진 서버에 요청하여 확보 후 전달, 그리고 캐시 적재
29. OAI(Origin Access Identity)
S3를 오리진 서버로 사용시, Cloudfront를 제외하고 다른 경로로 S3를 접근하는 것을 막는 방법
OAI를 설정하게 되면 각각의 Distribution이 별도의 Identity를 갖게 되며, S3의 버킷 정책을 수동 혹은 자동으로 수정할 수 있음
OAI가 적용된 S3의 버킷정책은 다음과 같이 수정됨
{ "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity xxx" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::bucket-name/*" } ] }
30. Presigned URL
인증된 사용자만이 해당 Distribution를 사용할 수 있도록 제어하는 기능
만료 날짜 및 시간까지 설정 가능
Cloudfront 설정시 Presigned URL 사용과 Cloudfront Key Pair를 계정의 보안자격증명에서 생성해야 함
이를 조합하여 URL 서명을 생성하고 해당 URL을 통해 Cloudfront에 접근할 수 있음
31. Relational Database Service란?
관계형 데이터베이스를 AWS 상에서 사용할 수 있도록 지원하는 서비스, 쉽게 말해 Database 서비스
생성 후 서비스를 이용하기만 되므로 SaaS에 해당
MySQL, MariaDB, Postgre SQL, Oracle, MS SQL, Aurora 사용 가능
DB 인스턴스에 대한 Shell 지원 불가 및 OS 제어 불가능(AWS 관리)
백업, 소프트웨어 패치, 장애 감지 및 복구를 AWS가 관리함
Storage 용량에 대하여 Auto Scaling 지원
32. DB Instance
Instance : RDS 기본 구성요소로서 클라우드에서 실행하는 격리된 데이터베이스 환경을 의미함. 이 인스턴스 내에서는 여러 사용자가 만든 데이터베이스가 포함되며 액세스할 여러 도구와 앱 사용 가능.
DB 인스턴스도 EC2처럼 다양한 클래스를 가지고 있음(db.m5, db.r5 등)
앞서 말한 것처럼 RDS도 클라우드에서 실행되기 때문에 하나의 AZ에서 격리되어 인스턴스로서 실행
33. DB Instance Storage
Instance Storage : 데이터베이스 유지를 위해 EBS(Elastic Block Storage)를 사용하며 필요한 스토리지 용량에 맞춰 자동으로 데이터를 여러 EBS 볼륨에 나누어 저장
스토리지 유형
범용 SSD : 대부분의 워크로드에서 사용하는 무난한 스토리지
프로비져닝 IOPS : 빠르고 일관적인 I/O 성능이 필요하고 일관적으로 낮은 지연시간이 요구될 경우 사용하는 스토리지
I/O : Input / Output
마그네틱 : 접속 빈도가 적은 워크로드에 적합한 스토리지
34. Multi-AZ(중요!)
RDS는 Multi-AZ라는 기능을 통해 고가용성을 지원함
말그대로 다수의 AZ에 DB 인스턴스를 둠으로써 하나 혹은 그 이상의 AZ가 파괴되어 서비스가 불가능할 때를 대비함
또한 기본 인스턴스가 수행해야 할 작업(백업, 스냅샷 생성) 등을 대신하여 수행함으로서 기본 인스턴스의 부담을 줄임
기본 인스턴스에서 스냅샷을 캡쳐한 후 다른 AZ에 복원하여 '동기식' 예비 복제본을 생성함
즉, Active(AZ A)-Standby(AZ B,C) 구조를 형성한 후 지속적으로 동기화함
'예비' 복제본이기 때문에 읽기 및 쓰기 작업을 수행할 수 없음(중요!)
Multi-AZ를 사용하는 경우, 단일 AZ 배포에 비해 쓰기 및 저장 지연 시간이 길어질 수 있음(Standby에 데이터를 동기화해야 하기 때문)
Multi-AZ를 활성화한 상태에서 DB 인스턴스에 문제가 발생하면 자동으로 다른 AZ의 예비 복제본(Standby)로 전환하며 서비스를 이어나감
전환에 사용되는 시간은 약 60-120초
전환되는 상황
가용 영역(AZ) 중단
기본 DB 인스턴스 오류
DB 인스턴스 서버 유형 변경
기본 DB 인스턴스 OS에서 소프트웨어 패치 실시
장애 조치 재부팅(Failover) 실시
35. Read Replica(중요!)
읽기 전용 복제본
기본 DB 인스턴스가 읽기와 쓰기를 담당한다면 Read Replica는 읽기 작업만을 담당하여 마스터 DB 인스턴스의 부하를 줄임
우선 DB 인스턴스의 스냅샷을 캡쳐한 후, 이를 기반으로 Read Replica를 생성하며, 데이터를 '비동기' 복제 방식을 통해 업데이트함
MySQL, Oracle, PostgreSQL, Maria DB에서 사용 가능
다른 리전에도 Read Replica를 두는 것이 가능
리전당 최대 5개까지 두는 것이 가능
Read Replica 또한 독립된 인스턴스로 승격 가능
36. Automated Backup
RDS의 자동백업으로 개별 데이터베이스를 백업하는 것이 아닌 DB 인스턴스 전체를 백업하는 것
매일매일 백업이 이루어지며, 기본 보존기간은 CLI로 생성시 1일 & 콘솔로 생성시 7일이며 최저 1일부터 35일까지 가능
특정시점을 지정하여 복원가능하며 복원 기간내로부터 최근 5분까지 특정시점을 지정하여 복원 가능
사용자가 지정한 백업시간에 자동적으로 백업되며, 백업 중에는 스토리지 I/O가 일시적으로 중단될 수 있음(Multi-AZ 사용시 Standby에서 백업 실시)
37. Snapshot
DB 인스턴스의 특정시점을 스냅샷으로 생성하는 것
자동백업과 마찬가지로 스냅샷 역시 자동으로 생성가능하며, 수동으로도 생성 가능
자동백업과는 달리 스냅샷 생성시점으로만 복원가능
스냅샷으로 복원시 DB 인스턴스를 복원하는 것이 아닌 개별 DB 인스턴스가 생성됨( DB 스냅샷에서 기존 DB 인스턴스로 복원할 수 없으며, 복원하면 새 DB 인스턴스가 생성됨)
스냅샷 복사, 공유, 마이그레이션이 가능함
스냅샷 생성 중에는 스토리지 I/O가 일시적으로 중단될 수 있음(Multi-AZ 사용시 Standby에서 백업 실시)
38. Enhanced Monitoring
RDS의 지표를 실시간으로 모니터링하는 '강화된' 모니터링
모니터링 지표는 CloudWatchs Logs에 30일간 저장됨
일반 모니터링과의 차이점은 Enhanced Monitoring은 인스턴스 내 에이전트를 통해 지표를 수집하는 반면, 일반 모니터링은 하이퍼바이저에서 수집한다는 점
최대 1초단위까지 수집 가능
39. RDS vs DB in EC2
EC2 위에 데이터베이스를 직접 올리는만큼 설정을 마음대로 변경할 수 있고 커스터마이징 또한 가능
RDS와는 반대로 백업과 패치 등 관리를 직접해야 함
EC2에 설치하는 것이기에 SSH 접속 가능
40. Amazon Aurora
'클라우드에서 데이터베이스를 처음부터 설계하면 어떨까'라는 생각에서 출발한 DB 서비스
MySQL과 PostgreSQL과 호환 가능함
각 AZ마다 2개의 데이터 복사본을 자동으로 유지하며, 에러를 스스로 찾아내고 복구함
Read Replica는 다른 DB 서비스와 달리 최대 15개까지 가능하며, 백업과 스냅샷이 퍼포먼스에 영향을 주지 않음
41. VPC
AWS의 계정 전용 가상 네트워크 서비스
VPC 내에서 각종 리소스(EC2, RDS, ELB 등)을 시작할 수 있으며 다른 가상 네트워크와 논리적으로 분리되어 있음
S3, Cloudfront 등은 비VPC 서비스로 VPC 내에서 생성되지 않음
각 Region별로 별도의 VPC가 다수 존재할 수 있음
VPC는 하나의 사설 IP 대역을 보유하고, 서브넷을 생성하며 사설 IP 대역 일부를 나누어 줄 수 있음
허용된 IP 블록 크기는 /16(IP 65536개) ~ /28(IP 16개)
권고하는 VPC CIDR 블록(사설 IP 대역과 동일함)
10.0.0.0 ~ 10.255.255.255(10.0.0.0/8)
172.16.0.0 ~ 172.31.255.255(172.16.0.0/12)
192.168.0.0 ~ 192.168.255.255.(192.168.0.0/16)
42. Subnet
VPC 내 생성된 분리된 네트워크로 하나의 서브넷은 하나의 AZ(Availability Zone)에 연결됨
VPC가 가지고 있는 사설 IP 범위 내에서 '서브넷'을 쪼개어 사용가능
실질적으로 리소드들은 이 서브넷에서 생성이 되며 사설 IP를 기본적으로 할당받고 필요에 따라 공인 IP를 할당받음
하나의 서브넷은 하나의 라우팅 테이블과 하나의 NACL(Network ACL)을 가짐
서브넷에서 생성되는 리소스에 공인 IP 자동할당 여부를 설정할 수 있음
이 기능을 통해 Public Subnet과 Private Subnet을 만들어 커스터마이징 가능
서브넷 트래픽이 후술할 인터넷 게이트웨이로 라우팅 되는 경우 해당 서브넷을 Public Subnet, 그렇지 않은 서브넷의 경우 Private Subnet이라 함
각 서브넷의 CIDR 블록에서 4개의 IP 주소와 마지막 IP 주소는 예약 주소로 사용자가 사용할 수 없음, 예를 들어 서브넷 주소가 172.16.1.0/24일 경우
172.16.1.0 : 네트워크 주소(Network ID)
172.16.1.1 : VPC Router용 예약 주소(Gateway)
172.16.1.2 : DNS 서버의 IP 주소
172.16.1.3 : 향후 사용할 예약 주소
172.16.1.255 : 네트워크 브로드캐스트 주소(VPC는 브로드캐스트를 지원하지 않음)
43. ENI(Elastic Network Interface)
가상 네트워크 인터페이스
VPC 내 리소스들은 ENI와 사설 IP를 기본적으로 할당받음
선택적으로 공인 IP도 할당 가능
Public Subnet의 경우, 리소스 생성시 자동으로 공인 IP를 할당함
사설 IP 주소는 추가로 할당 가능하며 공인 IP 역시 나중에 할당 가능
44. Routing Table
서브넷 내의 트래픽이 전송되는 위치를 결정하는 라우팅의 규칙 집합
라우팅 테이블은 기본적으로 VPC의 범위에 해당하는 범위를 기본 라우팅으로 가지며(ex. 172.16.1.0/24) 이를 'Local'로 표시함
또한 Internet Gateway, NAT Gateway, VPC Endpoint, Peering 등을 설정하고 그 서비스로 트래픽을 보내도록 라우팅 설정할 수 있음
'0.0.0.0/0'은 default routing을 뜻하며 트래픽이 가고자 하는 목적지가 라우팅 테이블에 없는 경우(ex. 172.16.1.0/24 네트워크에서 외부 인터넷으로 나아가고자 할 때) 사용하는 라우팅이며 보통 Internet Gateway나 NAT Gateway로 외부 인터넷을 지정할 때 씀
하나의 서브넷은 하나의 라우팅 테이블만 가지지만, 하나의 라우팅 테이블은 다수의 서브넷을 가질 수 있음
Public Subnet의 라우팅 테이블에는 인터넷 게이트웨이로의 라우팅이 있으며, Private Subnet에서 외부 인터넷 통신이 필요할 경우 NAT Gateway로의 라우팅이 잡혀 있음
45. Internet Gateway
VPC 내 리소스가 외부 인터넷을 사용하고자 할 때 사용하는 게이트웨이
인터넷 게이트웨이가 없으면 외부 인터넷을 사용할 수 없음
인터넷 게이트웨이를 생성한 후, '0.0.0.0/0'에 대하여 라우팅 테이블을 인터넷 게이트웨이로 잡아주면 사용 가능
다만 인터넷 게이트웨이가 있다 하더라도, VPC 내 리소스가 공인 IP를 가지고 있지 않다면 인터넷 사용 불가능
또한 위의 설정을 모두 했음에도 인터넷이 제대로 되지 않는다면, 보안그룹과 Network ACL을 확인해야 함
46. NAT Gateway
외부에서의 접촉이 원천적으로 차단되어 있는 Private Subnet에서 인터넷 접속을 통해야 할 경우 사용하는 게이트웨이
VPC 내부 리소스가 NAT Gateway를 통해 인터넷을 접속할 수 있지만, 외부에서 NAT Gateway를 통해 VPC 내부로 들어올 수 없음
인터넷이 연결된 Public sunbet에 NAT Gateway(EIP를 갖고 있음)를 생성한 후, Private Subnet의 라우팅 테이블에 '0.0.0.0/0'에 대하여 라우팅을 NAT Gateway로 잡아주면 사용 가능
CloudWatch를 이용하여 모니터링 가능
47. NAT Instance
Public Subnet에 생성된 NAT Gateway 대신 EC2 인스턴스를 사용하는 방법
Public Subnet에 공인 IP를 가진 특수한 인스턴스를 게이트웨이로 삼고, Private Subnet의 라우팅 테이블에 '0.0.0.0/0'에 대하여 NAT Instance로 설정한 후, SrcDestCheck 속성을 비활성화해야 함
커뮤니티 AMI에 있는 'ami-vpc-nat'로 시작하는 인스턴스로 사용 가능
인스턴스이기 때문에 후술할 보안그룹의 설정을 적용 받으므로 트래픽을 제어할 수 있음
48. NAT Instance vs NAT Gateway
NAT Gateway는 AWS에서 관리하기 때문에 유지보수할 필요가 없으나 NAT Instance는 사용자가 직접 관리해야 함
NAT Instance는 인스턴스이기 때문에 장애가 발생할 가능성이 있어 스크립트로 인스턴스간 Failover를 신경써야 함
NAT Gateway는 대역폭을 최대 45Gbps까지 확장할 수 있지만, NAT Instance는 인스턴스 유형에 따라 다름
NAT Gateway는 보안그룹을 사용할 수 없지만, NAT Instance는 보안그룹을 사용할 수 있음
NAT Gateway와 NAT Instance 모두 NACL을 통해 트래픽 제어 가능
49. Security Group
VPC 내 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상의 방화벽
서브넷 수준이 아닌 인스턴스 수준에서 작동하기 때문에 각 인스턴스를 서로 다른 보안그룹으로 지정할 수 있음
기본적으로 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용
인스턴스당 최대 5개의 보안그룹을 설정할 수 있음
보안그룹의 가장 큰 특성은 이른바 'Stateful'로 인바운드 트래픽과 아웃바운드 트래픽에 별도의 규칙을 지정할 수 있는 것
즉 인바운드에는 HTTP(80) 포트가 허용되어 있으나, 아웃바운드에 없는 경우 HTTP 트래픽이 '외부에서 들어왔다가 나갈 때' 전혀 지장이 없음
허용 규칙만 존재하며 거부 규칙이 존재하지 않음
Source IP, Protocol, Port 등을 설정할 수 있음
설정 변경시 즉시 적용됨
50. Network ACL
서브넷 내부와 외부의 트래픽을 제어하기 위한 가상 방화벽으로 네트워크 스위치의 ACL과 역할이 같음
서브넷의 가상 방화벽이기 때문에 서브넷에 속한 모든 인스턴스가 영향을 받음
기본적으로 모든 인바운드와 아웃바운드 트래픽을 허용함
하나의 ACL은 다수의 서브넷과 연결될 수 있으며, 하나의 서브넷은 하나의 ACL만 연결됨
Network ACL의 가장 큰 특징은 'Stateless'로서 인바운드 규칙과 아웃바운드 규칙이 서로 영향을 줌
즉 인바운드에는 HTTP(80) 포트가 허용되어 있으나, 아웃바운드에 없는 경우 HTTP 트래픽이 '외부에서 들어왔다가 나갈 때' 아웃바운드 통신이 되지 않음
허용과 거부 모두 가능
Security Group과 달리 우선순위 값이 존재하며 가장 작은 값이 가장 높은 우선순위를 가지고 우선순위부터 순서대로 적용됨
변경 사항은 잠시 후 적용됨
51. Security Group vs Network ACL(중요!)
Security Group은 'Stateful', Network ACL은 'Stateless'
Security Group은 허용만 가능, Network ACL은 허용 및 거부 가능
Security Group은 규칙 리스트에 있는 것 중 적용, Network ACL은 우선순위에 따라 우선 규칙 적용
Security Group은 인스턴스의 가상 방화벽, Network ACL은 서브넷의 가상 방화벽
52. VPC Peering
두 VPC 간의 트래픽을 전송하기 위한 기능
Source VPC와 같은 / 다른 리전의 VPC를 Destination으로 선택하여 Peering 요청을 보낸 후, 수락시 Peering 가능
요청과 수락이 필요한 이유는 다른 계정의 VPC도 연결 가능하기 때문
Peering 생성 후 라우팅 테이블에 해당 peering을 집어넣으면 통신 시작
VPC Peering은 Transit Routing 불가(2개의 VPC가 하나의 VPC를 통해 통신하는 것)
53. VPC Endpoint
VPC 내 요소들과 비VPC 서비스(S3, Cloudwatch, Athena 등)을 외부인터넷을 거치지 않고 아마존 내부 백본 네트워크를 통해 연결하는 방법
그러므로 후술할 Direct Connect와 같은 전용선 서비스나 VPN, 인터넷 게이트웨이와 같은 외부 연결이 되어 있지 않는 서브넷에서 아마존의 여러 서비스를 연결할 수 있음
간단히 말하여 아마존 서비스 전용선
VPC 엔드포인트에는 Interface Endpoint, Gateway Endpoint 두 종류가 존재
Gateway Endpoint는 S3와 Dynamo DB만 가능(중요!)
54. VPN
AWS의 IPSEC VPN 서비스
이 VPN을 통해 AWS와 On-premise의 VPN을 연결하는 것이 가능
고객 측 공인 IP를 뜻하는 고객 게이트웨이와 AWS 측 게이트웨이인 Virtual Private Gateway 생성 후 터널을 생성하면 사용 가능
반드시 터널 쪽으로 라우팅을 생성해야 함
55. Direct Connect
AWS의 전용선 서비스
표준 이더넷 광섬유 케이블을 이용하여 케이블 한쪽을 사용자 내부 네트워크의 라우터에 연결하고 다른 한 쪽을 Direct Connect 라우터에 연결하여 내부 네트워크와 AWS VPC를 연결함
VPN보다 더 안전하고 빠른 속도를 보장받고 싶을 때 사용
aws region --- Direct Connect Location --- Customer
56. Route 53이란
쉽게 말해 AWS의 DNS 서비스
도메인 등록
DNS 라우팅
상태 체크(Health check)
위 3가지를 담당함
도메인 등록시 약 12,000원 정도 지불해야 하며, 최대 3일 정도 걸림
해당 도메인을 AWS 내 서비스(EC2, ELB, S3 등)와 연결할 수 있으며 AWS 외 요소들과도 연결 가능함
도메인 생성 후 레코드 세트를 생성하여 하위 도메인을 등록할 수 있음
레코드 세트 등록시에는 IP 주소, 도메인, ‘Alias’ 등을 지정하여 쿼리를 라우팅할 수 있음
57. Route 53의 라우팅 정책(중요!)
Simple : 동일 레코드 내에 다수의 IP를 지정하여 라우팅 가능, 값을 다수 지정한 경우 무작위로 반환함
Weighted : Region별 부하 분산 가능, 각 가중치를 가진 동일한 이름의 A 레코드를 만들어 IP를 다르게 줌
Latency-based : 지연시간이 가장 적은, 즉 응답시간이 가장 빠른 리전으로 쿼리를 요청함
Failover : A/S 설정에서 사용됨, Main과 DR로 나누어 Main 장애시 DR로 쿼리
Geolocation : 각 지역을 기반으로 가장 가까운 리전으로 쿼리 수행, 레코드 생성시 지역을 지정할 수 있음
Geo-proximity : Traffic flow를 이용한 사용자 정의 DNS 쿼리 생성 가능
Multi-value answer : 다수의 IP를 지정한다는 것은 simple과 비슷하지만, health check가 가능함(실패시 자동 Failover)
58. Alias(별칭)
AWS만의 기능으로 Route-53 DNS 기능에 고유한 확장명을 제공
AWS의 리소스는 도메인으로 이루어져 있는데 이 도메인을 쿼리 대상으로 지정할 수 있도록 하는 기능
Route 53에서 별칭 레코드에 대한 DNS 쿼리를 받으면 다음 리소스로 응답(즉 다음 리소스로 Alias 지정 가능)
Cloudfront Distribution
ELB
Web Site Hosting이 가능한 S3 Bucket
Elastic Beanstalk
VPC Interface Endpoint
동일한 Hosting 영역의 다른 Route 53 레코드
59. Elastic Load Balancer란?
AWS의 L4/ L7 로드밸런싱(서버 부하분산) 서비스
외부 혹은 내부에서 들어오는 클라이언트의 요청을 ELB에 연결된 가용영역에 있는 EC2로 고르게 나누어 전달하고 등록된 EC2들을 상태 검사하는 서비스
외부/내부 트래픽은 ELB의 DNS 주소를 목적지로 하여 들어오며 이 트래픽을 받은 ELB는 가용영역에 등록된 EC2로 전달
보안그룹 적용
ELB 또한 VPC 내 존재하며 공인 IP 혹은 공인/사설 IP를 모두 가질 수 있음
인터넷 연결 option : 공인/사설 IP 생성
내부 option : 사설 IP 생성
기본적으로 Port를 이용하여 로드밸런싱 (예를 들어 HTTP 요청을 로드밸런싱하는 경우, 그 ELB는 HTTP 요청만을 전달하고 다른 포트 요청은 전달하지 않음)
ELB는 '리스너'를 거느리며 리스너 하나당 요청을 받아들이는 Port 하나씩을 지정함
예를 들어, 80 Port 요청을 받아 들이는 리스너, 443 Port 요청을 받아들이는 리스너를 모두 등록할 수 있음
상태 검사에 성공한 EC2만이 요청 전달 대상이 되며 상태 검사에 실패한 EC2는 요청 전달 대상에 제외됨
SSL 인증서를 등록하여 HTTPS 암호화/복호화 통신을 대신하는 SSL Offload 가능
ELB는 세 가지 로드밸런서로 구성됨
ALB(Application Load Balancer)
NLB(Network Load Balancer)
CLB(Classic Load Balancer)
60. Target Group(대상그룹)
ELB에 등록된 EC2 인스턴스들의 그룹
대상 그룹에 등록된 EC2, EC2 상태, 상태 검사 방법 등을 정의
상태 검사 방법에는 HTTP, HTTPS, TCP 등이 있음
방법뿐만 아니라 상태 검사에 필요한 시간도 정의 가능
ALB와 NLB는 대상그룹을 지정하며, CLB는 로드밸런서에 직접 등록
61. ALB(Application Load Balancer)
L7 로드밸런서
HTTP/HTTPS Header 정보를 기반으로 요청을 전달하는 로드밸런서
즉 리스너가 HTTP/HTTPS를 전문적으로 다룸
요청에 따라 고정 페이지를 반환하거나 다른 경로로 리다이렉트
HTTP Header / HTTP 요청 메서드 / Host Header / Source IP 등을 이용하여 요청 전달 가능
예를 들어 HTTP Header 내 User-agent에는 Host의 OS 정보가 있는데 Android일 경우, ELB 리스너가 Android만 사용하는 대상 그룹으로 전달 가능
SSL 인증서를 이용하여 SSL Offload 지원
후술할 교차영역 로드밸런싱 지원
X-forwared-for를 지원하여 EC2로 하여금 클라이언트의 IP를 확인할 수 있도록 함
ALB가 소유한 공인 IP가 유동적으로 변경됨
62. NLB(Network Load Balancer)
L4 로드밸런서
TCP / UDP를 기반으로 요청을 전달하는 로드밸런서
프로토콜, 원본 IP 주소, 원본 포트, 대상 IP 주소, 대상 포트, TCP 시퀀스 번호를 이용하여 요청 전달
TCP, UDP, TCP/UDP로 리스너를 설정 가능
TCP Header를 조작하여 전달하는 것이 아닌 그저 TCP의 기본인 3-way handshake만을 대신하여 진행
Client IP를 변경하지 않고 서버에게 전달
NLB의 IP가 ALB와 달리 변경되지 않고 고정됨
교차 영역 로드밸런싱 지원
63. CLB(Classic Load Balancer)
L4/L7을 모두 지원하는 '과거의' 로드밸런서
EC2-Classic을 사용하는 경우 CLB를 사용하면 됨
TCP / HTTP / HTTPS(SSL)을 지원
X-forwared-for 지원
교차영역 로드밸런싱 지원
64. Sticky Session
세션 고정 기능
하나의 요청이 특정 EC2로 들어와 세션이 생성되었다가 종료되고, 들어왔던 요청이 다시 들어올 경우 이미 연결되었던 특정 EC2로 전달하는 기능
65. 교차영역 로드밸런싱
기본적으로 ELB는 대상그룹에 등록된 EC2별로 적절히 부하분산을 하는 것이 아닌 가용영역별로 비율을 나눔
즉 교차영역이 2개라면 각 가용영역에 50%씩 전달
이렇게 될 경우, A 가용영역에 EC2가 2개이고, B 가용영역에 EC2가 8개일 경우 A/B 가용영역에 50%씩 전달되므로 A 가용영역의 EC2의 부하가 심해짐
이를 방지하기 위해 교차영역 로드밸런싱을 활성화화면 가용영역이 아닌 EC2 갯수를 기반으로 계산하여 전달하므로 부하가 고르게 나누어짐
66. X-Forwared-for
Client의 IP를 담고 있는 HTTP Header
EC2 내 서비스가 Client의 IP를 확인할 필요가 있는 경우 ELB는 HTTP Header에 X-Forwared-for를 장착하여 전달
67. 연결 드레이닝
Autoscaling과 ELB를 함께 사용시 필요에 따라 EC2가 없어질 경우, 해당 EC2에 요청이 들어와있다면 사용중인 세션이 피해를 볼 수 있음
삭제되기 직전에 유휴 세션이 작업을 마칠 때까지 기다리는 기능
68. Cloudwatch란?
AWS 클라우드 리소스와 AWS에서 실행되는 애플리케이션을 위한 모니터링 서비스
리소스 및 애플리케이션에 대해 측정할 수 있는 변수인 '지표'를 수집하고 추적 가능
사용중인 모든 AWS 서비스에 대한 지표가 자동으로 표시되며, 사용자 지정 대시보드를 통해 사용자 지정 애플리케이션에 대한 지표를 표시하고 지정 집합 표시 가능
'지표'는 Cloudwatch에 게시된 시간 순서별 데이터 요소 세트이며, 모니터링할 변수(가령 EC2의 CPU 사용량은 EC2가 제공하는 하나의 지표)
기본 모니터링과 세부 모니터링으로 나뉘며, 각각 5분과 1분 주기로 수집함
기본 모니터링은 자동활성화이지만, 세부 모니터링은 선택사항임
기본적으로 CPU, Network, Disk, Status Check 등을 수집함
Memory 항목이 없음을 반드시 주의!!!!!!!!
지표 데이터의 보존기간은 다음과 같음(암기 미권장)
기간 60초 미만의 경우, 3시간
기간 60초의 경우, 15일
기간 300초의 경우, 63일
기간 3600초의 경우, 455일
AWS CLI 혹은 API를 이용하여, Cloudwatch에 사용자 정의 지표 게시 가능
'경보' 기능을 사용하여 어떤 지표가 일정기간동안 일정값에 도달할 경우 각 서비스가 취해야할 행동을 정의할 수 있음
즉, 모니터링하기로 선택한 측정치가 정의한 임계값을 초과할 경우 하나 이상의 자동화 작업을 수행하도록 구성
EC2의 경우, 경보에 따라 인스턴스 중지, 복구, 종료, 재부팅 가능
69. Cloudwatch Agent
EC2에 Agent를 설치하게 되면 더 많은 시스템 수준 지표를 수집할 수 있음
온프레미스 서버 또한 Cloudwatch Agent 사용 가능
여기에 Memory 항목이 포함됨!!
즉 메모리 항목은 사용자 지정 지표로 수집가능하며, 이는 Agent를 통해 수집함
Cloudwatch Agent는 로그를 수집할 수 있으며, 후술할 Cloudwatch Logs 기능 사용 가능
70. Cloudwatch Logs
EC2(Agent에서 수집된), CloudTrail, Route 53, VPC Flow log 등 기타 소스에서 발생한 로그 파일을 모니터링, 저장 및 액세스하는 기능
앞에서 언급한 것처럼 Cloudwatch Agent를 사용하여 로그를 수집함
Cloudwatch Log Insights를 사용하여 CloudWatch Logs에서 로그 데이터를 대화식으로 검색해 분석할 수 있음
Agent는 기본적으로 5초마다 로그 데이터를 전송함
71. Cloudwatch Events
AWS 각 서비스의 이벤트가 사용자가 지정한 이벤트 패턴과 일치하거나 일정이 트리거될 경우, 사용자가 원하는 기능을 발동시키도록하는 기능
이벤트 소스와 대상으로 나뉨
이벤트 소스 : AWS 환경에서 발생하는 이벤트이며, 가령 S3의 경우 오브젝트 등록, 삭제 등을 들 수 있음
대상 : 이벤트 발생시 해야 할 행동을 정의하는 것이며, SNS 전송 혹은 람다, SQS 게시 등을 설정할 수 있음
즉 이벤트 소스에 해당하는 규칙이 트리거될 경우 대상에 해당하는 서비스를 실행시킴
이벤트가 시스템에 생성해 둔 규칙과 일치하는 경우, AWS Lambda 함수를 자동으로 호출하고, 해당 이벤트를 Amazon Kinesis 스트림에 전달하고, Amazon SNS 주제를 알리는 등의 행동이 가능
72. Auto Scaling이란?
EC2 인스턴스를 자동으로 시작하거나 종료하여 애플리케이션 로드를 처리하기에 적절한 수의 EC2를 유지할 수 있도록 하는 서비스
사용자가 정의하는 조건에 따라 EC2 갯수를 자동으로 확장 또는 축소가 가능함
또한 모니터링을 통해 비정상 인스턴스를 탐지하고 교체할 수 있음
수요가 급증할 경우 EC2 수를 자동으로 늘려 성능을 유지하고 수요가 적을 경우 수를 줄여 비용을 절감
ELB의 대상그룹을 Auto Scaling Group(ASG)에 포함시켜 자동생성된 EC2로 하여금 트래픽 부하분산을 하도록 설정 가능
수요 변화가 예측 가능한 경우 '예약된 일정'을 통해 정해진 시간에 늘리거나 줄이도록 설정 가능
ASG 내 손상된 인스턴스가 발견될 경우, Auto Scaling은 이를 자동으로 종료하고 새로운 인스턴스로 교체함
ELB를 사용하는 경우, ELB가 손상된 인스턴스를 트래픽 요청 대상에서 분리시킨 후, Auto Scaling이 이를 새로운 인스턴스로 교체함
비정상 서버 탐지후 Auto Scaling이 새로운 인스턴스를 In Service 상태로 만들기까지 5분 이내 소요
73. 시작 구성(Launch Configuration)
Auto Scaling에서 새로운 인스턴스를 시작할 때 기반이 되는 구성
AMI(Amazon Machine Image), 인스턴스 유형, 보안그룹, 스토리지 등 EC2를 생성할 때와 마찬가지로 옵션을 구성할 수 있음
시작 구성은 한 번 생성시 수정이 불가하며, 복사와 삭제만 가능
시작 구성을 변경하기 위해서는 기존의 시작구성을 새로운 시작 구성을 만드는 재료로 사용해야 함
하나의 ASG는 하나의 시작구성을 반드시 가짐
74. 조정 정책(Scaling)
최소, 목표, 최대 크기를 설정할 수 있고, 별다른 정책이 없을 경우 목표 크기를 유지하려 함
또한 3가지 동적 정책 사용 가능
대상 추적 정책 : ASG의 지표 평균값을 목표로 인스턴스 수를 조절
평균 CPU 사용률, 네트워크 입/출력, 로드밸런서 요청 수
단순 조정 정책 : 지표의 임계치에 도달할 경우, 사용자가 정한 인스턴스 수를 늘리거나 감소시키는 정책
단계 조정 정책 : 단순 조정 정책과 기본은 같지만, 지표 값에 따라 증감 수를 다르게 줄 수 있음(즉 트리거가 여러 개)
75. 조정 휴지(Scaling Cooldown)
시작 구성을 이용한 ASG 생성 시점을 포함하여 인스턴스 생성 혹은 제거 후, 지표의 임계값을 넘더라도 인스턴스를 생성하지 않고 기다리는 시간
기본 300초
76. 수명주기 후크(Life Cycle Hook)
Scale In / Out : 'In'은 감소를, 'Out'은 증가를 뜻함
지표의 임계값에 의해, Scale In / Out 이 되고 난 후 'In Service' 상태에 돌입하기 전에 사용자가 정의한 작업을 수행하는 시간을 설정하는 기능
기본 3600초
즉 인스턴스 시작/종료시 사용자가 작업을 수행할 수 있음
이 시간동안 인스턴스에 설치 / 설정 등이 가능
가령, Cloudwatch를 사용하면 수명주기 작업이 발생시, Lambda 함수를 호출시키도록 설정 가능
77. IAM이란?
AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스, IAM을 사용하여 리소스를 사용하도록 인증 및 권한 부여된 대상을 제어
주요 기능
AWS 계정에 대한 공유 액세스
서비스별 세분화된 권한 제공 가능
EC2에서 실행되는 앱을 위한 AWS 리소스 액세스 권한 제공
멀티 팩터 인증(MFA)
자격 증명 연동
AWS 서비스들은 IAM Role을 할당받아 권한을 부여받을 수 있음
Access Key와 Secret Access Key를 직접 입력하지 않고 권한 부여 가능
또한 IAM 사용자 계정을 만들어 사용자에게 적절한 권한을 부여하고 사용 가능한 서비스를 제한할 수 있음
78. 정책(Policy)
User, Group, Role이 사용할 수 있는 권한의 범위를 지정한 것
S3FullAccess, Administrator Access 등 다양한 액세스 권한이 이미 정의되어 있으며 이를 'AWS 관리형 정책'이라 함
사용자 정의 정책 생성
JSON 형식 또는 직접 선택을 통해 사용자 정의 정책 선택 가능
79. 역할(Role)
특정 권한을 가진 계정에 생성할 수 있는 IAM 자격증명
역할에는 다음과 같은 주체가 있음AWS 계정의 IAM 사용자
AWS의 서비스(EC2, RDS, ELB 등)
외부 자격 증명 공급자 서비스에 의해 인증된 외부 사용자
역할 생성시 IAM 사용자, 서비스, 외부 사용자 등 주체를 정해야 함
하나의 역할에는 다수의 정책을 연결할 수 있음
생성된 역할을 서비스 혹은 IAM 사용자 등에 연결
Region에 국한되지 않고 사용 가능
신규 유저는 생성시 아무런 권한이 없으며 Access Key와 Secret Access Key가 할당됨
각 키는 최초 생성시에만 볼 수 있으며 즉시 보관해야 함
80. 그룹 & 사용자
사용자는 IAM 사용자를 의미하여 관리자 계정에 의해 부여받은 권한에 한해 제한된 서비스에 접근할 수 있는 계정을 의미함
콘솔 로그인과 프로그래밍 액세스 가능 여부를 선택하여 생성 가능
콘솔 로그인이 승인된 경우, 별도의 링크를 통해 콘솔에 로그인 할 수 있음
각 사용자마다 정책을 부여할 수 있음
사용자 모두에게 일일이 부여하기 힘들거나 그룹단위로 통제하고 싶은 경우, 'Group'을 사용할 수 있음
그룹은 이미 생성된 사용자와 권한을 설정할 수 있으며 그룹 내 모든 사용자는 그룹의 권한을 적용받음
블로그: https://aws-hyoh.tistory.com/category/AWS
aws-hyoh.tistory.com
보다 자세한 자료는 해당 블로그에서 확인해보시면 됩니다.
댓글
댓글 쓰기