AWS-SAA 정리 (1)

CloudFront 배포를 추가하는 경우

• 정적 웹사이트의 콘텐츠를 캐싱하여 대기 시간 줄임
• 콘텐츠에 접근하는 사용자의 데이터 전송 및 요청만 비용 청구 → 비용 효율적

RDS 읽기 전용 복제본

• 읽기 쿼리 오프로드  →  AP 성능과 가용성 향상

Active-Standby

• 정상일 때, 기본 리소스로 트래픽 라우팅
• 비정상일 때, 보조 리소스로 트래픽 라우팅

S3(Simple Storage Service): 파일 서버의 역할을 하는 서비스

 

S3 종류

 

1. S3 Standard
   ◼️  가장 보편적
   
   
2. S3 - IA(infrequent Access / 스탠다드 IA)
   ◼️  자주 접근 X, 빠른 접근, 비용 저렴
   ◼️  30일 이상 접근 없을 시, Standard에서 IA로 자동 전환
   
   
3. S3 - One Zone IA(단일영역 IA)
   ◼️  2와 비슷, 2보다 저렴
   ◼️  하나의 AZ에만 데이터 저장(가용성 X)
   
   
4. S3 - Intelligent Tiering(지능형 계층화)
   ◼️  머신러닝으로 파일의 티어(클래스)를 자동 변경
   ◼️  퍼포먼스 손해 오버헤드 X, 관리비 적음
   
   
5. S3 - Glacier
   ◼️  쓸모없지만 보관은 해야하는 데이터 저장
   ◼️  분~시간단위로 시간 소요
   ◼️  다른 스토리지 클레스 차이: 제한 O, 암호화 필수, ID 형식의 아카이브 이름
       1) S3 Glacier Instant Retrieval
           - 밀리초 단위의 검색시간, 분기당 한 번 엑세스에 적합
           - 성능에 민감한 사용 사례에서 설계
       2) S3 Glacier Flexible Retrieval
           - 수 분~몇 시간(최대 12시간)의 검색 시간, 연간 1~2회 액세스에 적합
           - 백업, 재해복구 같이 대규모 데이터 집합이나 유연성 필요할 때 사용
       3) S3 Glacier Deep Archive
           - 12~48시간의 검색 시간, 연 1회 미만 액세스에 적합, 가장 저렴
           - 데이터를 7~10년 이상 엄청 오래 보관하는 금융, 의료, 미디어, 공공 etc.

비용 최적화 관련 문제

• ECS, API Gateway > Lightsail > EC2

Kinesis: 실시간으로 데이터 스트림을 수집, 처리, 분석해주는 서비스

1. Data Streams
   ◼️  데이터 스트림 수집 및 저장
   ◼️ 샤드의 수를 조절하여 스트림을 얼마나 받을지 조절
   
   
2. Data Firehose
   ◼️  미리 정의된 목적지에 데이터를 안전하게 전달하며, 람다를 이용해 가공하는 작업도 가능
       1) Data Analytics
           - 스트리밍 데이터 분석
           - 실시간 분석 생성: 지표를 계산 alc Amazon S3 or Amazon Redshift로 전송
           - 실시간 대시보드 제공: 집계, 처리된 스트리밍 데이터 결과 전송 및 실시간 대시보드 구성
           - 실시간 지표 생성: 실시간 모니터링, 알림, 경보에 사용할 사용자 지정 지표와 트리거 생성
       2) Video Streams
           - 재생 및 분석을 위해 미디어 스트림을 캡처, 저장 및 처리

NAT(Network Address Translation): 네트워크 주소 변환

1. NAT 인스턴스
   ◼️  EC2 인스턴스를 NAT용으로 바꿔 사용하는 것
   ◼️  특별한 AMI(Amazon Machine Image)를 설치한 EC2, 꺼지면 죽음
   ◼️  IGW(Internet GateWay)나 서브넷(망) 내의 VM instance끼리 통신 가능
   
   
2. NAT 게이트웨이
   ◼️  고가용성(꺼져도 죽지 않음)
   ◼️  보안그룹 영향 X
   ※ NAT 인스턴스 가격 < NGW 가격

DynamoDB

1. 특징
   1) NoSQL 데이터베이스
       -  JOIN 개념 없음 => 정규화 불가능, 보통 반정규화 함
       - RDBMS(관계형 데이터베이스)와 달리 종류, 특성에 관계없이 하나의 테이블에 표현
   2) HTTP로 통신
       - 타 DB 리소스는 TCP connection 기반, DynamoDB는 Connectionless
   3) Serverless 기반
       - DynamoDB를 위한 별도 서버 X => 요청한 만큼만 비용 지불(고성능, 저비용, 유연)
       - Lambda와 같은 타 서버리스 기반 서비스와 좋은 시너지
   4) Key-Value 데이터베이스
       - Key를 제외한 테이블의 속성을 정의할 필요 X
       - 데이터에 대해 스키마가 미리 설계해야하는 RDBMS와 달리 유연하게 데이터 처리 가능
2. 해설에 나온 항목
   - EC2 인스턴스를 NAT용으로 바꿔 사용하는 것
   - 특별한 AMI(Amazon Machine Image)를 설치한 EC2, 꺼지면 죽음
   - IGW(Internet GateWay)나 서브넷(망) 내의 VM instance끼리 통신 가능
   

Lake Formation

• 데이터레이크의 구축, 보안 설정, 관리를 손쉽게 만들어주는 서비스
• 데이터 레이크가 존재할 S3의 버킷과 path 등록
• Raw 데이터를 수집, 정제, 가공, 정리하는 데이터 플로우의 관리
• 데이터 레이크의 데이터와 소스에 대한 메타 데이터를 가진 data catalog의 생성 및 관리
• 메타데이터와 데이터에 대한 접근 정책의 관리 및 적용
  (+) 필요 서비스
    1. S3: 데이터 저장
    2. Glue Data Catalog: 테이블에 대한 메타 데이터 저장
    3. Athena: 데이터 쿼리

WAF

• Layer7의 보안 위협 (DDoS 공격 또는 Web AP 공격)에 대응하기 위한 보안 서비스
  (+) 배포할 수 있는 리소스
      ◼️  CloudFront
      ◼️  Application Load Balancer(ALB)
      ◼️  API Gateway 또는 AWS AppSync

CloudFront

• AWS에서 제공하는 CDN(Content Delivery Network) 서비스
• Edge Server(Location)을 두고 캐싱을 통해 Latency 최소화하여 빠른 전송 속도 제공
  1. 데이터 전송 과정
      ◼️  클라이언트로부터 Edge Server로의 요청 발생
      ◼️  Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부 확인
      ◼️  사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터 응답
      ◼️  사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Origin Server로 요청이 포워딩
      ◼️  요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 발생
  2. 구성
      ◼️  Origin Server: 원본 데이터 가진 서버(S3, EC2 instance)
      ◼️  Edge Server: 전 세계에 퍼져있는 캐싱 기능 제공용 서버

RDS

1. 관계형 데이터베이스를 제공하는 AWS의 서비스
   ◼️  Relational Database Service: 관계형 데이터베이스
   ◼️  NoSQL(DynamoDB, DocumentDB, ElasticCache) 차이점: 관계형 데이터베이스는 데이터베이스 안의 내용 정형화 & 테이블 간 관계를 중심적으로 봄
   
   
2. VM 위에서 동작
   ◼️  단, 시스템에 직접 로그인 불가능 => RDS는 Serverless 서비스가 아님
   ◼️  단, Aurora Serverless는 말 그대로 Serverless 서비스
   
   
3. CloudWatch와 연동
   ◼️  DB 인스턴스의 모니터링(EC2와 동일 ex: 디테일 모니터링, CPU, Storage 사용량)
   ◼️  DB에서 발생하는 여러 로그(Error Log, General Log 등)을 확인 가능
   
   
4. 내부에서는 EC2 활용
   ◼️  VPC 안에서 동작: Public IP 부여하지 않으면 외부 접근 불가
   ◼️  서브넷과 보안그룹지정 필요 => 방화벽 역할 수행
   ◼️  EC2 타입의 지정 필요
   ◼️  Storage는 EBS로 용량 지정해서 활용(Aurora의 경우, 용량 지정X)
   
   
5. RDS에서 제공하는 DB 엔진
   ◼️  라이선스 비용 발생: MSSQL Server, Oracle OLAP
   ◼️  라이선스 비용 X: My SQL Server, PostgreSQL, MariaDB
   ◼️  그 외: Amazon Aurora
   
   
6. Performance Insight
   ◼️   AWS RDS 를 모니터링할 수 있는 새로운 기능