AWS SAA 준비하면서 공부한 내용들

Snowmobile

- 초대용량 데이터를 AWS로 이전하는 데 사용하는 엑사바이트 규모의 데이터 전송 서비스

- 최대 100PB

 

Snowball

- 데이터 마이그레이션 및 엣지 컴퓨팅 디바이스

- S3와 호환되는 객체 스토리지 제공

- Snowball Edge Storage Optimized: TB~PB사이즈의 데이터를 AWS로 빠르고 안전하게 전송해야할 때 사용

- Snowball Edge -> S3 -> Glacier(수명주기 정책) 패턴으로 많이 사용

 

S3 스토리지 클래스

아래와 같이 스토리지 클래스를 전환할 수 있다(폭포수 모델)

Standard IA: 수명이 길지만 자주 엑세스하지 않는 데이터, 즉시 접근 가능해야할 때

Intelligent Tiering: 데이터 엑세스 패턴이 변경될 때 스토리지 비용을 자동으로 최적화해준다. Frequent Access, Infrequent Access 두 엑세스 티어간에 데이터를 이동시켜 자동으로 절약시켜줌

One Zone IA: 단일 AZ에 데이터 저장, 저렴하지만 AZ 파괴 시 데이터 손실

Glacier: 장기적으로 보관할 데이터, 즉시 접근 가능할 필요 없을 때, Standard IA보다 비용 절감

Glacier Deep Archive: 1년에 한 두 번정도만 엑세스하는 데이터 장기 보관

 

S3 Multipart Upload

- 대형 객체를 여러 개로 나누어서 업로드

- 기존 객체의 복사본 생성

 

S3 Transfer Acceleration

- 클라이언트와 S3 버킷 간에 파일을 빠르고 쉽고 안전하게 장거리 전송

- 전 세계 각지에서 중앙의 버킷으로 업로드

- 전 세계에 정기적으로 수 기가바이트에서 수 테라바이트의 데이터를 전송

 

S3 Cross Region Replication(CRR)

- 서로 다른 AWS 리전의 S3 버킷에서 객체 복사하는데 사용

- 고객이 두 군데의 지리적 위치를 갖는 경우 사용자와 지리적으로 더 가까운 AWS 리전에 객체 복사본을 유지하여 객체 액세스 지연 시간을 최소화

 

S3 Global Accelerator

- 고정 IP 주소를 통해 애플리케이션에 고정된 진입점을 제공

- DNS 구성을 업데이트하거나 클라이언트 애플리케이션을 변경하지 않고도 가용 영역 또는 AWS 리전 간에 엔드포인트를 손쉽게 이동

 

S3 Simple Region Replication(SRR)

- 동일한 리전의 S3 버킷에서 객체 복사하는데 사용

- 여러 버킷에 또는 여러 계정 간에 로그를 저장하는 경우, 리전 내 단일 버킷으로 로그를 손쉽게 복제

 

S3 LifeCycle

만료 작업: 일정 기간(한 주 or 한 달 ...)동안만 보관한 후 삭제해야할 때

전환 작업: 다른 스토리지 클래스로 전환해야할 때(30일 후 Standard IA로 전환, 1년 후 Glacier로 전환 등)

 

S3 데이터 보호

SSE-KMS: KMS를 사용해 암호화 키 관리, 객체 접근하려면 별도 권한 필요, 감사 추적 기능, 추가 비용 발생

**KMS 키 삭제 시: 7일안에 복구 가능, 7일이 지난 후에는 모든 메타 데이터를 삭제하며 되돌릴 수 없음**

SSE-S3: 각 객체는 고유한 키로 암호화되며 주기적으로 바뀌는 마스터 키를 사용하여 키 자체 암호화

SSE-C: 사용자가 직접 암호화 키 관리, 암호화 라이브러리 구현하고싶지않을 때 사용

 

RDS

다중 AZ 배포

- 자동으로 기본 DB인스턴스 1개 생성

- 동시(synchronously)에 다른 AZ에 예비 인스턴스 데이터 복제

- 장애 발생 시 예비 인스턴스로 자동 장애 조치 수행하여 완료 후 작업 재개 가능

- Failover 기술 사용하는 DB들: MariaDB, MySQL, Oracle, PostgreSQL

 

재해 복구 유형(primary DB -> standby DB 변환 기준)

- AZ 사용 불가

- 기본 DB 인스턴스 fail시

- DB 인스턴스의 서버 타입 변경되었을 때

- DB 인스턴스의 OS 소프트웨어 패치 시

 

OpsWork for Puppet Enterprise

 

Redshift

- 클라우드 데이터 웨어하우스로 데이터를 빠르게 쿼리

- 페타바이트급의 데이터

 

Kinesis Data Stream

- 실시간 데이터 스트리밍 서비스

- 로그, 이벤트 수집

 

Kinesis Data Analytics

- SQL, Flink로 데이터 스트림 분석

 

Kinesis Data Firehose

- 데이터 스트림을 캡쳐한 후 AWS 데이터 스토어로 로드

- S3, Redshift, Elasticsearch Service, Splunk와 같은 서비스 공급자로 전송

- input데이터 -> Kinesis Data Firehose를 사용하여 원하는 서비스에 데이터 실시간 로드 -> Lambda로 output 내보내기전에 필터링 후 전송 -> output

 

VPC

Security Group(Statefull) - 허용 규칙만 지원, 인스턴스 레벨

Network ACL (Stateless) - 허용/거부 규칙 모두 지원, 서브넷 레벨

기본 네트워크 ACL

- 규칙 번호가 *인 규칙들이 있다. 번호가 매겨진 다른 어떤 규칙과도 일치하지 않을 경우 거부된다.

- 위 규칙은 수정하거나 제거할 수 없다.

기본 NACL의 규칙은 모든 트래픽 in/out 허용하며 이 규칙을 수정할 순 없다. 다른 규칙들을 추가하거나 삭제할 수 있다.

 

VPC 서브넷에 있는 인스턴스에 대해 인터넷 엑세스할 수 있도록 설정하는 방법

1. VPC에 internet gateway를 추가한다.

2. 서브넷의 route table에 route를 추가한다.

3. 서브넷의 인스턴스가 고유한 IP주소가 있어야한다. (Elastic IP, IPv4, IPv6)

4. NACL과 Security Group에서 허용 규칙을 추가한다.

 

WebServer와 DB를 배포하려고한다. Web Server는 고객들이 인터넷으로 접근할 수 있어야한다. WebServer 혹은 ELB는 public subnet에 DB는 private subnet에 설치해야한다.

 

EndPoint

Gateway: S3, DynamoDB 지원

Interface: AWS PrivateLink 지원, 프라이빗 IP 주소를 사용하여 비공개 엑세스

 

EC2

Cold Attach: 시작중 상태

Warm Attach:  중지 상태

Hot Attach: 실행중 상태

 

EC2 인스턴스 저장소의 데이터가 손실되는 경우

- The underlying disk drive fails

- The instance stops

- The instance hibernates

- The instance terminates

 

EC2 Auto Scaling 인스턴스 제어

종료할 두 가지 유형(스팟 or 온디맨드) 식별

각 가용 영역에 종료 정책을 개별 적용(가장 오래된 시작 템플릿/구성을 사용하는 인스턴스부터 종료)

- scheduled action: 정해진 시간에 스케일링 작업을 진행함

- lifecycle hooks: 인스턴스 시작 혹은 종료될 때 커스텀 작업을 진행함

- target tracking: 목표를 설정한 후, cloudwatch 경보를 통해 확인

- step scailing: 지정된 평가 기간동안 임계값이 위반될 때 확장 가능한 대상을 스케일링, cloudwatch 경보를 통해 확인

 

EC2 스토리지

1. EBS(Elastic Block Storage): 인스턴스 수명과 무관하게 유지, 단일 AZ에 저장, 하나의 AZ에 속한 하나의 EC2 인스턴스

2. EFS(Elastic File System): 여러 AZ에 중복 저장, 수 천개의 EC2 인스턴스 동시 접근

3. Instance Store: 인스턴스가 활성화되어있는 동안에만 유지, EBS보다 저렴

 

만약 AZ가 unbalance해졌다면?

- 예전 것을 종료하기전에 새로운 인스턴스를 시작하여 재분배한다. 

- 정상적이지 못한 인스턴스를 종료시키는 scaling activity를 생성한다. 종료되고 나면, scaling activity가 새로운 인스턴스를 실행시킨다.

 

공유 책임 모델

사용자: 클라우드에서의 보안(방화벽, 네트워크, 데이터, 암호화 등, 운영체제 업데이트, 보안 패치)

AWS: 클라우드의 보안(SW, HW)

 

세션 상태 데이터 처리하기에 좋은 AWS 서비스: DynamoDB, ElastiCache 

 

ElastiCache

- 완전관리형 in-memory 데이터 스토어

- Memcached와 Redis와 호환됨

- Redis: 복제(replication), 아카이브 스냅샷 지원(snapshot)

 

DynamoDB Accelerator(DAX)

- DyDB 응답시간을 밀리초~마이크로초단위로 줄여주는 고가용성의 in-memory 캐시이다.

 

IAM Group은 IAM User의 집합, 여러 사용자에게 규칙을 명시한다.

- 유저마다 계정을 생성하고, 각 부서별로 그룹을 만든다. 각 그룹마다 필요한 정책을 연결한다. 만약 새로운 멤버가 합류하게 될 경우, 멤버별로 계쩡을 생성하고 해당하는 그룹에 추가한다. 만약 멤버가 부서를 옮기게 될경우, 새로운 IAM Group으로 유저를 옮긴다.

- permission boundary를 사용하여 IAM에 부여할 수 있는 최대 권한 제어

 

 

CloudTrail: 사용자 관찰

CloudWatch: AWS 서비스 관찰

 

CloudWatch Alarm 사용도

EC2인스턴스의 평균 CPU 사용률이 특정 범위보다 낮아질 때(혹은 높아졌을 때) 알람을 보내주도록 설정하여 인스턴스를 관리할 수 있다.

 

EC2 인스턴스 구입 옵션

Ondemand: 초 단위로 지불

Reserved: 1년 혹은 3년 기간동안 인스턴스 유형 또는 지역을 포함해 일관된 인스턴스 구성을 약정하여 지불

Scheduled Reserved: 1년단위로 인스턴스 구입

Spot: 미사용 EC2 인스턴스 요청

Dedicated Host: 인스턴스 실행을 전담하는 실제 호스트 비용 지불

 

- 시작 템플릿을 사용하여 EC2 인스턴스에 대해 구성할 수 있다. EC2 Dedicated Host를 사용하려면 '시작 템플릿'을 꼭 사용해야한다.

- 시작 템플릿 실행 -> 시작 구성을 시작 템플릿으로 교체

 

DynamoDB 사용 방식

- key value 데이터 구조

- S3 객체들의 메타데이터 저장

- 웹 세션 데이터 관리

 

DynamoDB Auto Scaling

- 실제 트래픽 패턴에 따라 사용자 대신 동적으로 조정

- 트래픽이 갑자기 증가된 경우에도 조절하지않고 처리

 

Read Replica(읽기 복제본)의 기능

- asynchronosuly update

- AZ, cross-AZ, cross-Region

- 재해 복구 단계

1. 재해를 일으킨 변경사항이 읽기전용 복제본으로 전송되기전에 복제 중지

2. 복제 시작 후 로그파일위치에서 복제가 자동으로 중지되도록 지정

3. 읽기 전용 복제본을 새 원본 DB인스턴스로 승격(자동으로 승격되는 것이 아니라 지침에 따라서 승격됨)

 

재해복구(DR)계획

RTO: 복구 시간 목표, RPO: 복구 시점 목표

1. 백업 및 복구(시간 단위 RPO, 24시간 이하의 RTO): 가장 비용 저렴, 가장 느림

2. Pilot Light(분 단위 RPO, 시간 단위 RTO): 가장 중요한 핵심 요소를 항상 실행하는 최소 버전의 환경을 DR리전에 유지

3. Warm Standby(초 단위 RPO, 분 단위 RTO): 항상 실행되는 모든 기능을 갖춘 환경의 축소된 버전을 DR리전에 유지

4. Active - Active(초 단위 RPO 또는 RTO 없음, 초 단위 RTO): 여러 리전에 배포되고 능동적으로 트래픽 처리

 

Database Migragion Service(DMS): 최소한의 가동 중단으로 데이터베이스를 AWS로 마이그레이션

 

Athena

SQL을 사용해 S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스

 

Classic Load Balancer -> Application Load Balancer의 이점

- path-based routing

- host-based routing, HTTP 헤더의 host필드 기반으로 요청을 전달하는 리스너에 대한 규칙 구성할 수 있음, 따라서 단일 로드 밸런서를 사용하여 여러 개의 도메인에 요청을 라우팅할 수 있음

- 로드밸런서 성능 개선

- 컨테이너화된 애플리케이션 지원

- ALB는 정상인스턴스에게만 요청을 보낸다

 

Classic Load Balancer -> Network Load Balancer의 이점

- 일시적으로 워크로드를 처리하고 초당 수백만개의 요청으로 확장할 수 있음

- Static IP address 지원

 

Cross-zone load balancing: 각 로드 밸런서 노드가 활성화된 모든 가용 영역에 있는 등록된 대상 간에 트래픽을 분산

- Application Load Balancer: 항상 활성화

- Network Load Balancer: 기본적으로는 비활성화

- Classic Load Balancer: 생성 방법에 따라 다름

 

Instance Store의 데이터가 유실되는 경우

- 기본 디스크 드라이브 오류

- 인스턴스 중지, 종료

- 인스턴스 최대 절전모드로 전환

 

Placement Group(배치 그룹)

Spread: 각각 고유한 랙에 배치된 인스턴스 그룹, 랙마다 자체 네트워크 및 전원 있음, 그룹당 최대 7개의 실행중인 인스턴스 가질 수 있음

Cluster: 가용 영역안에 서로 근접하게 패킹, 낮은 지연 시간의 네트워크 성능, HPC 애플리케이션 

Partition: 한 파티션안에 있는 인스턴스 그룹이 다른 파티션의 인스턴스 그룹과 하드웨어를 공유하지 않도록 함

 

Elastic Fabric Adapter(EFA)

EC2를 위한 네트워크 인터페이스, HPC 애플리케이션 

 

EBS: EC2에 사용할 수 있는 블록 스토리지 서비스, 단일 인스턴스에서 가장 짧은 지연시간으로 데이터를 엑세스해야할 때 사용

EFS: EC2에 사용할 수 있는 파일 스토리지 서비스, 최대 수 천개의 EC2 인스턴스를 위한 파일 시스템 인터페이스, 동시 엑세스 가능한 스토리지, 온프레미스 -> AWS 연결 방법: inter region vpc peering connection

S3: 객체 스토리지 서비스, 어디서나 엑세스할 수 있는 인터넷 API를 통해 데이터를 사용할 수 있음

 

SNS: 게시자가 구독자에게 메세지를 전송(push)하는 관리형 서비스, '주제'에 메세지를 발행하고 수많은 구독자들에게 전달한다(fanout)

SQS: 사용자가 메세지를 가져온다(pull). 여러 서비스로 분리(decouple)하여 병렬식 비동기 처리

- FIFO: 한 번에 처리, 순서보장, 초 당 최대 300개의 메세지 지원, 

- Standard: 최소한 한 번 전달, 순서 보장하지 않음, 무제한 처리량

 

API Gateway

- HTTP 기반

- 상태 저장(WebSocket), 상태 비저장(HTTP, RESTAPI)

- HTTP Method 지원

 

CloudFront

1. 사용자가 하나 이상의 파일 요청

2. DNS가 Edge Location로 요청을 라우팅함(지연 시간과 관련해 가장 가까운 곳)

3. 해당 캐시에 요청 파일이 있는지 확인, 있으면 사용자에게 반환 없으면 4번으로 이동

4. (a) 요청 파일 형식으로 사용자의 오리진 서버에 전달

4. (b) 오리진 서버는 해당 파일을 Edge Location으로 전송

4. (c) CF는 사용자에게 파일 전달, 다음에 사용자가 요청할 경우 Edge Location의 캐시에 파일 추가

 

FSx for Lustre

- 비용 효율적

- 확장 가능한 고성능 스토리지 제공

- 고성능 파일 시스템과 S3 API 모두에서 동시에 데이터를 액세스하고 처리할 수 있음

 

Site-to-Site VPN

- 온프레미스 네트워크와 Amazon VPC를 안전하게 연결