시험에 자주 나오는 유형
1. EBS vs EFS vs S3 Instance Store
(속도)
S3 < EFS < EBS
EBS vs EFS vs S3
| 특징 | EBS | EFS | S3 | Column |
|---|---|---|---|---|
| Storage Type | Block Storage | File Storage | Object Storage | |
| Pricing | Pay for provisioned capacity | Pay as you Use | Pay as you Use | |
| Storage Size | 제한됨 | 무제한 | 무제한 | |
| Scalability | 확장, 축소 가능하긴 한데 새 volume을 만들어서 이전시켜야 함. | 무제한 | 무제한 | |
| Availability | 99.99% | No SLAs | Standard 쓰면 최대 99.99% | |
| Security | Rest 지원 및 Transit 암호화 | Rest 지원 및 Transit 암호화 | Rest 지원 및 Transit 암호화 | |
| Back up and Restore | 자동화된 백업과 스냅샷 제공. | EFS 복제 | versioning과 리전 간 복제 지원 | |
| Accessibility | EC2 인스턴스에 의해서만 접근 가능 | 온 프레미스 환경과 EC2 환경에서 동시 접근 가능 | public, private | |
| Interface | file | web & file | file | |
| Use cases | Boot volumes, NoSQL DB, data warehousing ETL | Media, Bigdata ... | Media, Bigdata ... | |
| 제목 없음 |
2. SQS vs SNS vs Kinesis
- Kinesis : 데이터 스트림 단위
- Simple Queue Service: SQS Standard Queue 단위
- Simple Notification Service: Topic 단위
SQS vs SNS vs Kinesis
| d | SQS | SNS | Kinesis |
|---|---|---|---|
| 데이터 교환 시 특징 | consumer가 데이터를 당겨오고 난 후, 소비된 데이터는 consumer로부터 삭제된다. | 데이터를 push한다. publish된 데이터는 영속성을 갖고 있지 않는다. (전달 안되면 사라짐) | consumer가 데이터를 당겨온다. 각 데이터에 유효 기간을 설정할 수 있다. |
| 자원 제한 | 제한 없이 다수의 consumer를 가질 수 있다. | 구독자 수가 10,000,000로 제한된다. topic 수는 100,000까지. | consumer 수에 제한이 없다. data record가 data stream으로 보내지면, 24시간부터 최대 일주일 간 stream에 머물 수 있다. |
| 프로비저닝 | 처리량을 프로비저닝할 필요 없다. | 처리량을 프로비저닝할 필요 없다. | 반드시 처리량을 프로비저닝해야 한다. |
| 순서 보장? | FIFO Type Queue를 제외하고는 순서를 보장하지 않는다. | SQS와 함께 쓸 수 있다. (fan-in: SNS, fan-out: SQS) | 각 data stream은 하나 이상의 shard로 이루어져 있고, shard level에서 정렬된다. |
| 특징 | Queue에 publish되는 메시지의 개별 딜레이 용량을 만들 수 있다. | 생산자-소비자 모델을 따른다. | data replay가 가능하다. |
| 언제 씀? | 하나의 worker node에서만 메시지가 처리될 경우 | 여러 서비스가 같은 이벤트로부터 메시지를 받아야 할 때 | 실시간 빅데이터, 분석 및 ETL에 쓰인다. |
(정리)
SQS ⇒ Queue에 데이터 보내고, 가져올 수 있음. (publish-subscribe가 아님!!)
SNS⇒ 데이터 넣는 역할(push), publish-subscribe 메시징 시스템.
Kinesis ⇒ 실시간으로 추적할 수 있는 data stream
⇒ 데이터를 보내고 받는 기능 간 결합도를 낮출 수 있다.
3. Security Group vs NACL
Security Group
→ EC2 인스턴스의 인바운드/아웃바운드 트래픽을 제어하는 가상 방화벽
→ 즉시 적용
→ 허용하는 것만 설정하지, 차단은 못함. (Stateful 특징)
| 이름 | NACL | Security Group |
|---|---|---|
| 개요 | Network Access Control List는 aws서비스에서의 보안 레이어를 제공한다. | instance에 명시적으로 할당되는 보안 그룹이다. |
| 연결 | 하나의 NACL에 여러 subnet이 바인딩될 수 있는데, 한번에 하나의 서브넷만 하나의 NACL에 바인딩될 수 있다. | instance에 연결되며, 여러 개의 security group과 함께 연결될 수 있다. |
| 용도 | 서브넷용 방화벽 | EC2 인스턴스용 방확벽 |
| Stateless | stateless함. (변경 즉시 적용 x) | stateful함 (변경 즉시 적용 o) |
| 정책 | 차단 정책을 지원한다. | 허용하는 것만 설정 가능하다. (기본값이 모두 차단) |
| 보안 레이어 수준 | second layer of defence (VPC level) | first defence layer |
| 정책 특징 | 정책 간 우선순위가 있다. | 모든 정책이 함께 고려된다. 그래서 트래픽 생길 때마다 모든 정책을 확인해야 한다. |
| 제목 없음 |
4. CloudTrail vs CloudWatch
CloudWatch는 aws 서비스와 자원들의 활동에 집중하고, 각각의 상태나 퍼포먼스를 보여준다. (AWS는 지금 어떤지?)
→ AWS 자원, 앱 모니터링 서비스이다.
→ 자원이나 서비스를 생성할 때부터 사용된다. (무료 기본 기능 제공)
→ 수치를 추적하고, 로그 파일을 모니터링 할 수 있으며 알람 설정이 가능하다.
CloudTrail은 aws 환경 안에서 이루어지는 모든 활동의 로그이다. (AWS에서 누가 무엇을 했는지?)
→ API 활동을 기록하는 모니터링 웹 서비스이다.
→ 계정 만들 때부터 자동으로 사용된다.
→ 누가 요청했는지에 대한 내용을 로깅한다. 로깅한 내용은 S3 bucket에 저장된다.
5. Latency Routing vs Geolocation routing policy vs Geoproximity routing policy
Latency Routing vs Geolocation routing policy vs Geoproximity routing policy
| 이름 | Latency Routing | Geoproximity Routing | Geolocation Routing |
|---|---|---|---|
| 정의 | Route 53이 가장 낮은 latency를 가진 리전에서 오는 요청을 가져다 준다. | Route53 트래픽이 지역적 위치에 따라 움직일 수 있게 한다. | DNS 요청 위치에 따라 트래픽을 움직인다. |
| 하는 일 | 요청 출발지와 같은 리전에 있는 사용자에게 요청이 가는 것을 보장한다. | bias로 특정 값을 지정하여 리전에서의 트래픽의 양을 정할 수도 있다. | IP 주소와 위치를 매핑시킨다. 꼭 두 레코드가 같은 위치일 필요가 없다. |
| 특징 | 여러 리전에 있는 자원들의 latency record을 기준으로 한다. | Route 53 traffic flow를 사용해야 한다. | default record를 만들지 않으면 IP 주소로부터 오는 요청을 수행하지 않는다. (no answer 응답) |
| Use Case | 여러 aws 리전의 자원을 가장 나은 latency로 제공하고자 할 때 | 자원의 위치에 따른 트래픽 제공 | 사용자의 위치에 따른 트래픽 제공 |
| 제목 없음 |
6. Direct Connect vs Site to Site VPN
둘 다 AWS Direct Connect: 온프레미스의 네트워크와 aws 네트워크를 연결하기 위한 서비스이다.
Direct Connect: Direct Connect Location을 거쳐 연결됨.
Site to Site VPN: 네트워크와 VPC/Transit Gateway 사이의 암호화된 2개의 터널을 생성하여 사용. IPsec VPN 연결 지원. (바로 연결됨)
차이점 1. 통신 방식
→ VPN은 IPsec을 사용해 암호화된 네트워크를 형성함. Direct Connect는 프라이빗 네트워크 연결을 사용해 DirectConnect Location을 경유하여 통신함.
→ VPN은 동적/정적 라우팅을 지원하지만, Direct Connect는 BGP만 제공함.
차이점 2. 대역폭
→ VPN보다 Direct Connect가 더 다양한 대역폭을 선택할 수 있음.
→ VPN은 게이트웨이 터널을 중첩하여 대역폭을 확보하는 방식(엣지 로케이션으로 트래픽 라우팅). Direct Connect는 전용선만 사용하여 전용 연결들을 하나의 단일 연결로 처리하는 LAG을 사용함.
차이점 3. 요금
→ VPN이 더 쌈. (연결 시간 당 요금 & 데이터 전송 요금)
→ Direct Connect는 포트 시간 요금(연결 유형에 따라 상이) & 데이터 전송 요금
7. S3 + CloudFront
⇒ CDN 서비스 사용 가능함.
[작동 방식]
- S3버킷과 CloudFront를 설정
- S3 리소스 요청이 엣지 로케이션으로 라우팅됨
- 캐싱되어 있지 않으면 CloudFront가 S3 버킷 origin에서 콘텐츠를 가져옴
⇒ private network를 통해 전송되므로 public internet보다 더 빠름
8. WAF
: 웹 애플리케이션 방화벽
→ SQL Injection or XSS같은 공격 패턴을 차단하는 보안 규칙 설정 가능.
→ 검사하는 http 요청 수에 대한 요금 지불
9. FSx
: 완전 관리형 파일 시스템
→ 윈도우, 리눅스 등 각종 운영체제에서 Amazon FSx에 있는 파일에 접근할 수 있다.
→ FSx for Windows File Server: 비지니스용
→ FSx for Lustre: 컴퓨팅 집약적 워크로드용
10. RDS Multi-AZ
AWS Zone: 같은 지역에 있는 물리적으로 다른 data center의 개념.
RDS Multi Zone replication: 한 DC(zone)가 고장 나더라도 다른 DC에서 서비스가 가능한 구조.
→ 기본적으로 active-stand by 형태로 복제하다가, 장애가 나면 stand by 서버로 fail over하는 구성.
→ 백업 시 자동으로 시스템이 failover하여 멈추는 현상 없이 서비스가 가능함.
- failover(시스템 대체 작동): 서버를 이중화하여 한 시스템에 문제가 잇을 경우 다른 시스템이 대체하여 작동하는 장애 대비 기능.
[기능]
→ 다중 AZ 배포: 고가용성 목적, Aurora만 비동기식 복제 지원. 단일 리전 내에서 항상 2개 이상의 가용성 영역 확장됨.
→ 다중 리전 배포: DR, 로컬 성능 목적. 비동기식 복제. Aurora만 db 엔진 업그레이드 시 모든 인스턴스가 함께 업데이트됨.
→ 읽기 전용 복제본: 확장성 목적. 비동기식 복제. 수동 프로모션 가능함.
- RDS를 사용하면 읽기 전용 복제본을 다중 AZ로 설정할 수 있어 읽기 전용 복제본을 DR대상으로 사용할 수 있음.
11. How to enable Internet Access for the private subnet?
- Public subnet: IGW(인터넷 게이트웨이)를 가지고 있으며, public subnet의 인스턴스는 인터넷에 접속하려면 public IP 주소가 필요하다.
- Private subnet: NAT Gateway나 NAT Instance를 가지고 있으며, 각 인스턴스는 public IP 주소가 없어도 된다.
private subnet에서 인터넷 접속하려면
1) subnet을 하나 만든다.
2) NAT Gateway를 만들고, 게이트웨이를 subnet에 할당한다.
3) private subnet으로 옮길 인스턴스의 AMI를 만들고, 인스턴스를 종료한다.
4) 만든 AMI로부터 새 EC2 인스턴스를 만든다.
5) 3)에서 종료한 원래 인스턴스를 없앤다.
- AMI (아마존 머신 이미지)
EC2 인스턴스를 시작하는 데 필요한 정보를 제공한다. 스냅샷, 템플릿, 시작 권한, 블록 디바이스 매핑을 포함하고 있다.
12. S3 Storage Classes; Glacier vs Standard IA vs Glacier Deep Archive...
[S3 객체 스토리지 클래스]
- S3 Standard: 자주 액세스
- S3 Intelligent-Tiering: 액세스 패턴이 변화할 때 4개의 tier 간 객체 이동하여 비용 절감
- S3 Standard IA: 자주 액세스하지 않지만 필요 시 빠르게 액세스 해야 할 때
- S3 One Zone-IA: 단일 AZ에 데이터를 저장하여 기본 IA보다 비용 절감
- S3 Glacier: 아카이브용 클래스. 검색 시간 지정 가능
- S3 Glacier Deep Archive: 가장 저렴. 1년에 한두 번 정도 액세스 할 정도의 데이터 보관.
S3 Storage Classes
| 특징 | S3 Glacier | Standard IA | Glacier Deep Archive |
|---|---|---|---|
| 개요 | 잘 안쓰이는 데이터를 아카이브하는 서비스. | Infrequent Access로, 잘 안쓰이긴 하지만 필요할 땐 데이터를 빨리 가져다 주는 서비스 | 거~의 안쓰일 데이터를 아카이브하는 서비스 |
| 데이터 가져오는데 걸리는 시간 | few hours | milliseconds | 12 hours |
13. EC2 instance type, On-demand vs Spot vs Reserved
[EC2 인스턴스 타입]
- General Purpose: 밸런스형 컴퓨팅, 메모리, 워크로드 제공.
- Compute Optimized: 고성능 프로세서가 필요한 bound app 실행시킬 때 유용함.
- Memory Optimized: 워크로드에 대한 빠른 성능과 큰 데이터셋을 처리할 때 유용함.
- Accelerated Computing: 부동소수점 계산, 그래픽, 데이터 분석 등 무거운 프로그램 돌릴 성능 좋은 CPU가 필요할 때 유용함.
- Storage Optimized: 로컬 스토리지에서 읽기-쓰기 연산이 자주 발생할 경우 유용함.
[요금제]
- On-demand: 제일 비싸지만 끄고 킬 때 부담이 덜함.
→ 테스트용, 짧게 쓸 때
- Spot instances: 남는 EC2 용량을 갖다 쓸 수 있어 저렴함.
→ 급하게 쓸 때
- Reserved: 장기 계약하면 더 싸짐.(Saving Plans라고도 함)
→ 1, 3년 주기로 계약
- Dedicated Hosts: 아예 물리 EC2 서버 자체를 임대함.
→ On-demand나 Reserved로 임대 가능.
14. Network Load Balancer vs Application Load Balancer
https://medium.com/awesome-cloud/aws-difference-between-application-load-balancer-and-network-load-balancer-cb8b6cd296a4
ALB(Application Load Balancer): layer 7 - HTTP/HTTPS, 유연함
→ network layer에서 application layer로 가는 변수 기반해 트래픽 분배함.
→ context-aware하여 단일 변수나 여러 변수를 함께 고려할 수 있다.
→ HTTP, HTTPS 라우팅 제공
→ HTTP 상태 코드로 health check 가능함.
→ 최소 2개 이상의 Availability Zone을 사용할 수 있게 해야 됨.
NLB(Network Load Balancer): layer 4 - TLS/TCP/UDP, 고정 IP
→ network 변수(IP주소, 목적지 port)로 트래픽 분배
→ context-less하여 오직 network 관련된 정보만 본다.
→ EIPs를 사용해 고정된 endpoint를 가진다. port는 달라질 수 있다.
→ ELB는 사용가능하게 한 각 Availability Zone의 network interface를 만든다.
- 공통점: 동적 포트 제공
- 차이점 1: network layer (ALB: 7, NLB: 4)
- 차이점 2: NLB는 forwarding만 함. ALB는 HTTP 요청 내용을 검사할 수 있음.
- 차이점 3: NLB는 app의 가용 여부를 모름. ALB는 HTTP 코드로 체크 가능함.
- 차이점 4: 같은 host에 여러 app 배포할 때 NLB는 app을 구분할 수 없으나, ALB는 app을 구분할 수 있다. ALB는 application layer data를 사용할 수 있기 때문.
15. Storage Gateway File vs Tape vs Volume
https://cloud.in28minutes.com/aws-certification-aws-storage-gatewayAWS storage file gateway
- File Gateway는 온 프레미스의 VM에 띄워지고, 데이터는 S3 Bucket에 보관된다.
- S3의 장점을 가지고 있음(가용성, 저렴, cross-region 복제, Athena, EMR 연동)
- Gateway당 10 bucket까지만 공유할 수 있다.
AWS storage tape gateway
- 아카이브용. 데이터를 가상 테이프에 백업한다.
- S3의 장점을 가지고 있다.
- S3처럼, 데이터를 S3 Glacier에서 S3 Glacier Deep Archive로 옮긴다.
AWS storage volume gateway
- block 스토리지를 클라우드로 옮길 때 사용.
- iSCSI 프로토콜을 사용한다.
- 백업과 DR이 자동화되어 있다.
- AWS Backup을 사용한다. AWS에서는 volume 데이터를 S3에 저장하고, EBS 스냅샷으로 백업을 위한 기록을 보관한다.
- 볼륨 종류
- Cached Volumes: S3를 주로 사용하고, 캐시는 온프레미스에. S3의 데이터는 직접 접근이 불가능해 EBS 스냅샷은 온프레미스의 캐시에서 가져온다.
- Stored Volumes: 온프레미스를 주로 사용하고 그 복제본을 AWS에 비동기로 보관하는데, EBS 스냅샷 형태로 보관한다.
(정리)
Hybrid storage: cloud + on premise
파일 공유하면서 S3랑 통합 ⇒ AWS Storage File Service
클라우드에 자기 테이프 보관 ⇒ AWS Storage Tape Gateway
클라우드에 볼륨 보관 ⇒ AWS Storage Volume Gateway
볼륨보관할 때 고성능 ⇒ Stored
고성능 상관없으면 ⇒ Cached
*이거 쓰려면 온프레미스에 Gateway 돌릴 VM 띄워야 함.
16. Snowball, Snowmobile
AWS Snow 패밀리: 엣지 컴퓨팅 및 데이터 전송 서비스
AWS Snow Family
| 특징 | Snowcone | Snowball | Snowmobile |
|---|---|---|---|
| 개요 | 휴대용 제품으로, 엣지 로케이션에서 데이터를 안전하게 저장함. | 데이터 마이그레이션 및 엣지 컴퓨팅 디바이스로, 인터넷에 연결되지 않은 환경에서 고급 작업을 수행할 수 있게 함. | 대규모 디지털 미디어 마이그레이션 및 데이터 센터 종료할 때 사용하는 네트워크 연결 데이터 스토어. |
| 작동 방식 | 데이터를 수집, 처리하고 디바이스로 데이터를 운반하거나, AWS DataSync로 온라인으로 데이터를 올릴 수 잇음. | Compute Optimized와 Storage Optimized 옵션을 제공한다. Compute Optimized는 인터넷에 연결되지 않은 환경에서 ML 수행하는 것이고, Stored Optimized는 가끔 인터넷에 연결될 경우 인터넷이 없을 때 수집한 데이터를 보관했다가 온라인이 되면 데이터를 AWS에 보냄 | 물리적으로 Snowmobile을 AWS에 리전으로 가져가서 S3에 데이터를 로드함. |
| 데이터 규모 | 작음. | 42TB(Compute), 80TB(Storage) | 100PB |
| 제목 없음 |
17. Aurora
클라우드용으로 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스.
⇒ RDS에서 관리. (하드웨어 프로비저닝, 데이터베이스 설정, 백업 Task 자동화)
⇒ 내결함성을 갖춘 자가 복구 분산 스토리지 시스템으로, 인스턴스당 최대 128TB까지 확장됨.
⇒ S3로 지속적 백업, 3개 AZ에 복제본 저장
18. IAM
aws 리소스 접근 권한을 제어할 수 있는 서비스.
root 사용자: 완전한 액세스 권한을 가짐.
IAM 사용자: 일부 액세스 권한을 가짐.
AWS용 ABAC: 속성 기반 액세스 제어. 태그를 사용자로 연결해서 태그 기반 액세스 정책 관리가 이루어짐.
19. S3 encryption
Server Side Encryption
- SSE-S3 (AES-256) : S3의 고유한 키로 암호화를 실시하며, 암호화 주체는 S3이다.
- SSE-KMS : Key Management Service를 이용하여 객체를 암호화하는 방식. KMS 고객 마스터 키(CMK)를 활용함. 고객이 키 제어 가능
- SSE_C: 고객이 제공하는 키로 암호화 진행. 제공된 암호화키는 저장되지 않는다.
Client Side Encryption
- S3로 데이터를 보내기 전에 암호화 하는 방법
- KMS에 저장된 고객 마스터키를 사용하여 암호화 하는 방법.
- 애플리케이션 내 마스터 키를 사용해 암호화 하는 방법
20. ElastiCache Redis vs Memcached
(공통점)
- 1ms 이하의 응답대기시간
- 개발의 용이성
- 데이터 파티셔닝
- 다양한 프로그래밍 언어 지원
- 다양한 데이터 구조 지원
- 스냅샷 (디스크 저장)→복구 용이
- 복제 (Master-Slaves 구조) → 높은 가용성
- 트랜잭션(ACID) 보장
- 발행-구독(Publish-Subscribe) 모델 기반 메시지 패턴 검색 지원
- 위치기반 데이터타입 지원
ElastiCache Redis
- Redis 운영 지원 및 모니터링 제공
- 위치 정보, 채팅 메시지, 게임 리더보드 등 빠른 조회가 필요한 데이터를 구독자에게 제공한다.
ElastiCache Memcached
- 단순한 모델이 필요한 경우
- 멀티스레드 or 멀티코어가 있는 큰 노드를 실행해야 하는 경우
- 객체를 캐시에 저장해야 하는 경우