woongs dogfoot

CloudWatch Metrics

• Metrics : AWS 서비스를 모니터링하기 위한 변수 값 (ex. CPUUtilization, Networkln...)
  
  
  

• 특징

1. 각 Metric은 각기 다른 namespace에 저장 (AWS 서비스당 namespace는 1개)
2. Dimension : 측정 기준, metric의 속성 (instance id, environment, etc...)
3. metric당 최대 측정 기준은 30개
4. metric은 timestamp가 필수
5. 많은 지표를 한번에 볼 수 있는 CloudWatch dashboard가 있음
6. Custom Metrics를 만들 수도 있음 (ex. EC2인스턴스의 Memory 사용량)
   
   
   

• CloudWatch Metric Streams : CloudWatch 외부로 스트리밍하는 기능

1. 원하는 AWS 서비스에 실시간 저지연 성능으로 Metric을 전달할 수 있음 (Kinesis Data Firehose, 타사서비스 등)
2. 모든 namespace의 metric을 전달하거나, 특정 namespace만 선택하여 metric을 전달할 수도 있음

CloudWatch Logs

• CloudWatch Logs : AWS의 app log를 저장할 수 있는 서비스

• Log groups : app log를 저장할 group, 이름은 보통 app의 이름으로 설정

• Log stream : app안의 인스턴스나 log files, containers 형태로 존재
  
  
  

• 특징

1. log 만료정책 정의 (1일~무한대)
2. 다양한 서비스로 log를 보낼 수도 있음
3. 모든 log는 암호화됨 -> KMS기반으로 암호화 설정 가능
4. CloudWatch에 Log 전송 방법
   • SDK
   • CloudWatch Logs Agent
   • CloudWatch Unified Agent
   • Elastic Beanstalk : app으로부터 직접 log를 수집하고 CloudWatch에 전송
   • ECS : Container로부터 log를 수집하여 CloudWatch에 전송
   • AWS Lambda : 해당 서비스 자체적으로 log 전송
   • VPC Flow Logs : VPC 메타데이터 트래픽 log 전송
   • API Gateway : 해당 서비스로 오는 요청에 대한 log를 모두 전송
   • CloudTail : 필터에 기반하여 직접 log 전송
   • Route53 : 모든 DNS쿼리에 대한 log 전송
5. CloudWatch Logs Insight 기능을 이용하여 log에 쿼리를 할 수 있음 -> 로그 데이터 검색 및 분석 가능 -> console상에서 샘플 쿼리 제공 -> CloudWatch 대시보드에 적용할 수도 있음 -> 다수의 log group을 쿼리할 수도 있음 -> 과거 데이터만 쿼리 가능
   
   
   

• S3 Export : Batch Export, 최대 12시간 소요, CreateExportTask API 활용

• CloudWatch Logs Subscriptions

1. log를 실시간으로 받아서 분석할 수 있음
2. Kinesis Data Streams, Kinesis Data Firehose, Lambda 등에 보낼 수 있음
3. Subscription Filter 기능을 활용하여 내보내려는 대상 log를 선별하여 보낼 수 있음
4. 원리 : Sender계정에서 Recipient계정의 서비스로 log를 보낼 때, Sender 계정에서는 Subscriptions Filter를 활용하게 되고, Recipient 계정에서는 가상의 Subscription Destination을 만들어 데이터를 받아 대상 서비스로 전달 -> Destination Access Policy를 통해 Subscriptino Filter를 허용해야 함 -> Subscription Destination에서 Kinesis 서비스로 접근하기 위한 IAM Role 생성 필요

• Aggregation Multi-Account & Multi-Region : CloudWatch Logs Subscriptions 기능 활용 -> 다양한 계정 및 다양한 region에서 온 CloudWatch Logs 데이터를 특정 계정의 하나의 Kinesis Data Streams 등에 통합할 수 있음

• LiveTail : Log Stream으로 전송된 log들을 실시간으로 console UI에서 확인할 수 있음
  
  
  

CloudWatch Agent

• 기본적으로 EC2에서는 CloudWatch로 어떤 log도 옮기지지 않음 -> EC2에 CloudWatch Agent를 실행시켜 CloudWatch로 push해야 함
• EC2 -> CloudWatch로의 IAM Role 생성 필요
• CloudWatch Agent는 온프레미스에서도 실행가능

• CloudWatch Logs Agent (older)

1. EC2나 온프레미스 서버를 위한 Agent
2. CloudWatch logs로 log만 보냄
   
   
   

• CloudWatch Unified Agent (통합 Agent, newer)

1. EC2나 온프레미스 서버를 위한 Agent
2. log만 보낼 뿐만 아니라 프로세스나 RAM과 같은 시스템 레벨의 metrics도 수집 -> CloudWatch logs에 통합 전송
3. Metric과 log 둘다 활용
4. SSM Parameter Store를 이용하여 Agent를 보다 쉽게 구성할 수 있음 -> 중앙 집중형으로 설정 가능
   
   
   

• CloudWatch Unified Agent - Metrics

1. 수집 metric
   • CPU
   • DISK
   • RAM
   • Netstat
   • Processes
   • Swap Space
2. 일반적인 EC2 모니터링 기능보다 더 많은 metric을 수집함 (좀더 세부적인 metric 수집 가능)
   
   
   

CloudWatch Alarms

• CloudWatch Alarms : Metric에서 나오는 알림을 트리거함 (샘플링, 퍼센티지, 최대, 최소 등 정의 필요)
  
  
  

• Alarm 상태

  1. OK : 알람이 트리거되지 않음
  2. INSUFFICIENT_DATA : 상태를 결정하기 위한 충분한 데이터가 없음
  3. ALARM : 기준 값을 초과하여 알림 전송

• Period : 얼마나 오랫동안 Metric을 평가할지? (10s, 30s, 60s의 배수 등)
  
  
  

• Alarm Targets

1. EC2 인스턴스에 대한 동작 (Stop, Terminate, Reboot 등)
2. Auto Scaling에 대한 동작 (Scale-out, Scale-In 등)
3. SNS에 알림 전송 (SNS를 Lambda와 연결하여 알림에 대한 동작까지 정의할 수 있음)
   
   
   

• Composite Alarms

1. 기본 CloudWatch Alarm은 싱글 metric 기반
2. 다수의 metric 기반일 경우, Composite Alarm 사용 필요 -> 다수의 다른 알람들의 상태를 모니터링하는 방식
3. 다른 알람들의 상태를 모니터링하면서 AND 또는 OR로 최종 상태 결정
4. 알람 노이즈를 줄이는 데 유용

• Use case : EC2 Instance Recovery

1. EC2 VM과 연관된 Instance status와 하드웨어와 연관된 System status 두 가지의 상태를 검사할 수 있음
2. 위 두가지 상태 검사에 대해 CloudWatch Alarms을 정의할 수 있음
3. 해당 알람이 발생하면 EC2 인스턴스 Recovery를 시작
4. 복구가 완료되면 SNS에 알림을 전송함으로써 복구완료를 알림

• Good to know

1. Metric Filter 기반의 Alarm을 생성할 수 있음 (ex. error와 같은 키워드를 많이 받은 경우에 Alarm을 발생시킴)
2. 알람 테스트를 위해 set-alarm-state라는 CLI 호출 사용 가능

EventBridge (formerly CloudWatch Events)

• 활용 유형

1. Schedule : Cron jobs

2. Event Pattern : 특정 패턴의 이벤트를 감지하여 정의된 서비스를 수행 (ex. root 계정 login 시, 이벤트를 감지하여 SNS Topic에 알림을 전송 -> 해당 알림을 받은 서비스가 이메일 발송)

3. Trigger Lambda : Lambda Function을 트리거할 수도 있음 (ex. 다수의 사용자에게 알림을 보내야 할 때, Lambda를 Trigger하여 다수 사용자가 구독 및 polling하는 SNS/SQS 알림을 발송하도록 함)
   
   
   

• EventBridge Rules

1. filter 설정 : S3 Bucket중 특정 Bucket의 이벤트만 수신
2. 여러 AWS 서비스가 source가 될 수 있음 + cron job
3. 발생된 이벤트를 EventBridge가 수신하면, JSON문서를 생성함 (JSON에는 이벤트가 발생한 인스턴스 유형과 인스턴스ID등의 정보가 담겨있음)
4. Destination 서비스에는 생성된 JSON을 전달함

• EventBridge Types

1. Default Event Bus : 위에서 살펴본 Bus
2. Partner Event Bus : 파트너사의 소프트웨어에서 발생한 이벤트도 수신 가능
3. Custom Event Bus : 자체적으로 만든 app에서 발생한 이벤트를 수신 가능
   
   
   

• 특징

1. 리소스 기반의 정책을 통해 다른 계정의 Event Bus에도 접근할 수 있음
2. 이벤트를 저장할 수도 있음 (모든/필터링된 이벤트 대상, 기간은 설정 가능) -> 저장된 이벤트를 다시 재생할 수 있음 (ex. Lambda Function의 버그를 수정하고 이벤트를 다시 발행)
   
   
   

• Schema Registry

1. 스키마 기반으로 App 코드 생성 가능
2. Event Bus의 데이터가 어떻게 정형화되는지 알 수 있음 (to JSON)
3. EventBrdige가 Event Bus로부터 어떻게 스키마를 추론하는지? 데이터는 어떻게 정형화하는지 파악 가능 -> JSON 데이터에 어떤 데이터가 어떤 데이터형식으로 구성되어 있는지 -> 해당 스키마를 통해 Java/Python 등 이벤트를 전송 받는 app 코드 생성 가능
4. 스키마 Versioning 가능 -> 스키마 반복 가능

• Resource-based Policy

1. 특정 Event Bus의 권한을 관리할 수 있음 (ex. 다른 region의 이벤트 허용/거부, 다른 계정의 이벤트 허용/거부 등)
2. Use case : AWS Organization에 Event Bus를 두고 모든 계정의 Event를 하나에 수집 -> 리소스기반 정책 추가 필요

CloudWatch Insight

• CloudWatch Container Insight
  : Container로부터 Metric과 log를 수집/집계/요약하는 서비스

• 활용 서비스

1. Amazon ECS
2. Amazon EKS
3. kubernetes platforms on EC2
4. Fargate
   
   
   

• 특징

1. Container버전의 CloudWatch Agent 활용 필요
   
   
   

• CloudWatch Lambda Insight
  : Lambda와 같은 서버리스 app을 위한 모니터링/트러블슈팅 솔루션
  
  
  

• 특징

1. 시스템 수준의 Lambda Metric을 수집/집계/요약
2. Lambda Function 옆에서 실행
   
   
   

• CloudWatch Contributor Insight
  : Contributor 데이터를 표시하는 시계열 데이터를 생성하고 log를 분석하는 서비스 (VPC log, DNS log 등)
  
  
  

• Use cases : 사용량이 가장 많은 네트워크 사용자를 찾을 수 있음, DNS log에서 오류를 가장 많이 생성하는 URL을 알 수 있음

• 특정 패턴(ex. 사용량이 많은 네트워크 사용자순)에 대해 상위 TOP N을 추출 후 분석

• CloudWatch Application Insight
  : app의 잠재적인 문제와 진행중인 문제를 분리할 수 있도록 자동화된 대시보드 제공
  
  
  

• app에 문제가 있는 경우, 대시보드를 통해 잠재적인 문제를 보여줌

• 대시보드를 보여줄 때, 내부적으로 SageMaker가 활용됨

• app 상태의 가시성을 높여줌

• 결론, 문제가 발생하면 대시보드에 표시하는 서비스

• 발견된 문제와 알림은 Amazon EventBridge와 SSM OpsCenter로 전달
  
  
  

CloudTail

• CloudTail : AWS 계정의 거버넌스, 컴플라이언스, 감사를 실현하는 방법
  
  
  

• 특징

1. 기본값으로 활성화되어 있음
2. 계정에서 일어난 이벤트와 API 호출이력, SDK, CLI 활용이력 등을 얻을 수 있음 -> 로그로서 발생
3. 발생한 log를 CloudWatch Logs나 Amazon S3에 Insert
4. 모든 region의 log를 하나의 S3에 넣고싶을 때, trail을 생성하여 하나의 region에 적용할 수 있음

• Event 유형

1. Management Events : AWS 계정 안에서 리소스에 대해 수행된 작업을 나타냄 (읽기/쓰기 이벤트 모두 나타냄)
2. Data Events
   • 기본 값은 로깅되지 않음 (고용량 작업)
   • S3 객체 조회/수정과 같은 데이터관련 작업을 나타냄
   • 읽기 이벤트/쓰기 이벤트 분리 가능
   • Lambda Function 실행 작업도 해당
3. CloudTrail Insights Events
   
   
   

• CloudTrail Insights

1. API 호출 등의 리소스 작업에 대해 정상/비정상을 확인할 수 있는 기능
2. 활성화하는 순간 비용 부과
3. log를 분석하여 정상기준을 수립한 후, 비정상적인 패턴을 탐지하는 원리
   • 부정확한 리소스 프로비저닝
   • 서비스 한도 도달
   • AWS IAM 액션의 폭증
   • 주기적 유지보수 활동 누락

• CloudTrail Events Retention

1. 기본적으로 이벤트는 CloudTrail에 90동안 보관 -> 더 오래 보관할 수도 있음 -> S3 전송 및 Athena 분석 필요 (Event 데이터 조회)

CloudTrail + EventBridge 사례

AWS Config

• AWS Config : AWS에 대한 감사와 규정준수 여부를 기록할 수 있게하는 서비스, 시간에 따른 변화를 기록 -> 문제가 있을 경우, 인프라를 빠르게 롤백하고 문제점 파악 가능
  
  
  

• 해결할 수 있는 유형

1. 보안 그룹에 제한되지 않는 SSH 접근이 있나?
2. S3 Bucket에 public access가 있나?
3. 시간이 지나며 설정이 변화한 ALB가 있나?
   
   
   

• 원리 : AWS Config에 등록된 rule에 대해 리소스의 변화가 생길 때마다 rule이 준수가 되고 있는지 확인함 -> 미준수 시, EventBridge, 자체 알림 기능 등으로 조치도 취할 수 있음
  
  
  

• 특징

1. 규정 준수 여부에 관계없이 시간에 따라 변화가 있을 경우, SNS알림 수신 가능
2. region별 구성 필요
3. 데이터 중앙화를 위해 region과 계정간 데이터 통합 가능
4. 모든 리소스의 구성을 S3에 저장하여 나중에 분석할 수도 있음
5. 규정미준수 때마다 트리거를 걸 수도 있음
6. EventBridge를 통해 트리거를 걸어 규정미준수에 대한 어떤 조치를 취할 수도 있음
   7, EventBridge를 사용하지 않고도 SNS로 알림을 직접 보낼 수도 있음
7. Custom Rule 작성 시, rule 미준수에 따른 action도 설정 가능

CloudWatch vs CloudTrail vs AWS Config

: ELB 예제

Database를 선택하는 방법

1. 읽기량/쓰기량 고려
2. 데이터 처리량 고려
3. 데이터 저장량
4. 데이터 저장 기간
5. 평균 객체 크기
6. 객체에 접근하는 방법
7. 확장이 가능한지?
8. 데이터 공급원은 어디인지?
9. 데이터 내구성이 있는지?
10. 지연시간에 관한 요구사항이 있는지?
11. 동시 사용자에 관한 요구사항이 있는지?
12. 데이터 모델이 뭔지?
13. 쿼리 방법이 뭔지?
14. 데이터 join이 많은지?
15. 정규화? 반정규화?
16. 유연성이 있는지?
17. reporting이 필요한지?
18. 관계형? NoSQL?
19. 라이선스 비용이 있는지?
    
    
    

• Database Types

1. RDBMS : RDS, Aurora
2. NoSQL : DynamoDB(JSON), ElastiCache(key-value), Neptune(Graphs), MongoDB(DocumentDB), Apache Cassandra(Keyspaces)
3. Object Store : S3, Glacier
4. Data Warehouse : Redshift(OLAP), Athena. EMR
5. Search : OpenSearch(JSON)
6. Graphs : Amazon Neptune
7. Ledger : Amazon Quantum Ledger Database
8. Time series : Amazon Timestream
   
   
   

RDS

1. PostgreSQL, MySQL, Oracle, SQL Server, MariaDB 지원
2. RDS 인스턴스 크기 및 EBS Volume Type/Size를 사전 지정해야 함
3. 스토리지에 대한 Auto-scaling 기능이 있음
4. 읽기 전용 복제본 지원
5. 고가용성 목적으로 Standby DB를 다중 AZ에 배치할 수 있음 (해당 DB엔 쿼리 실행 불가)
6. IAM을 통해 사용자 보안조치 가능 (사용자이름/비밀번호, 일부 사용자에게 IAM 인증 부여)
7. Security Groups을 통해 네트워크 보안
8. KMS를 통해 데이터 저장 보안
9. SSL을 통해 전송 데이터 보안
10. 최대 35일의 자동 백업 옵션 -> 해당 기간 내 새로운 DB로 복구 가능
11. 장기 보존 백업이 필요한 경우 DB Snapshot 이용 가능
12. 패치 작업 등을 위해 downtime이 있을 수 있음
13. RDS Proxy를 추가하여 RDS에 IAM 인증 추가
14. Secrets Manager와 통합하여 DB 자격증명 관리
15. RDS 인스턴스에 접근을 위한 사용자 지정옵션 있음 (Oracle / SQL Server)
16. 관계형 DB 및 OLTP를 저장하는데 활용
    
    
    

Aurora

1. PostgreSQL, MySQL 지원
2. 스토리지와 컴퓨팅이 구분됨
3. 기본 설정으로 3개 AZ에 6개의 인스턴스로 나누어 데이터를 저장함 -> 고가용성
4. 자동 자가복구 과정이 있음
5. 스토리지에 대한 Auto-scaling 기능이 있음 (읽기 전용 복제본도 가능)
6. DB Cluster가 구축되어 있기 때문에 어느 인스턴스에 접근하여 읽고 쓸지를 결정하기 위해 별도 endpoint가 필요 (writer endpoint, reader endpoint)
7. RDS와 동일한 Security/monitoring/maintenance 기능이 있음 -> 같은 엔진 활용
8. Aurora를 위한 백업 및 복구 기능이 있음
9. Aurora Serverless -> 예측할 수 없는 간헐적인 workload가 있을 때 용량을 별도로 계획하지 않아도 되기 때문에 유용함
10. Global DB를 위해 Aurora Global이 사용됨 -> 16개의 read전용 인스턴스가 각 region에 배포됨 -> 1초 미만의 실시간 스토리지 복제 -> 특정 region에 문제가 생겼을 때, 다른 region의 DB를 주요 region으로 승격시킬 수 있음
11. 머신러닝을 위한 Aurora Machine Learning 모듈이 있음
12. 테스트 DB 및 스테이징 DB를 위해 Aurora cloning 기능이 있음, snapshot을 복구하는 것보다 빠름 -> 새로운 cluster 구축
13. RDS보다 비용이 더 비싸지만, 더 유연성있고, 덜 관리하고, 더 좋은 성능, 더 많은 기능을 원하면 사용
    
    
    

ElastiCache

1. Redis / Memcached 두 종류
2. 캐싱작업에 활용
3. in-memory store
4. 1ms 미만의 읽기 성능을 제공
5. 캐싱을 위한 EC2 인스턴스가 프로비저닝 되어야 함
6. Redis에서는 Clustering 기능 제공 및 Multi-AZ, Sharding을 통한 읽기 전용 복제본 제공
7. IAM을 통한 접근 보안, Security Groups(네트워크 수준의 접근), KMS(데이터 저장), Redis Auth가 있음
8. RDS처럼 백업 및 Snapshot, point in time restore 기능 제공
9. app code가 ElastiCache를 사용하도록 수정 필요
10. Use Cases : key-value store, 빈번한 읽기, DB 쿼리 캐싱, 세션 데이터 저장 등
11. SQL 사용 불가
    
    
    

DynamoDB

1. ms단위의 성능을 제공하는 Serverless NoSQL DB
2. provisioned capacity mode : 지정된 용량 범위 내에서 auto scaling, 점진적인 증감이 있을 떄 활용
3. on-demand capacity mode : 용량을 프로비저닝할 필요가 없음, 예측하기 어려운 workload에 따라 자동으로 scaling, 가파른 증감이 있을 때 활용
4. key-value 저장소 -> elastiCache 대체 가능
5. 세션 데이터를 저장하기 좋음 -> TTL 기능으로 일정 시간 뒤에 세션을 만료시킴
6. 고가용성 -> Multi-AZ, 읽기/쓰기 분리
7. DynamoDB와 완벽히 호환되는 캐싱 기능인 DAX cluster 제공 (ms단위의 읽기 성능)
8. 보안/인증/인가 등의 기능이 모두 IAM을 통해 이루어짐
9. DynamoDB Streams를 활성화하여 이벤트 처리 기능도 추가할 수 있음 (DynamoDB Streams : DB에 일어나는 변경사항을 감지하여 스트리밍) -> Lambda, Kinesis Data Streams등과 결합하여 이벤트 처리)
10. Global Tables 기능 제공 -> 다수 region에 걸친 active-active 복제 가능
11. 최대 35일의 자동 백업 옵션 (point in time restore 기능 활성화 필요) -> 자동백업 옵션을 활용하여 S3로 데이터를 내보내면, RCU사용없이 PITR window로 가능, S3에서 새로운 테이블로 가져올 때에도 WCU 사용없이 가능
12. 장기 보관을 위한 On-demand 백업 옵션
13. 빠르게 스키마를 변경하거나, 유연하게 변경해야할 때 유용
    
    
    

S3

1. key-value 형태로 저장 -> 큰 객체를 저장할 때 유용, 여러 개의 작은 객체를 저장할 때는 비효율
2. Serverless
3. 객체 최대 크기 5TB
4. Versioning 기능
5. 다양한 스토리지 지원, Storage tiers : S3 Standard, S3 Infrequent Access, S3 Intelligent, S3 Glacier + tier 전환을 위한 lifecycle policy
6. Versioing, Encryption, 복제, 영구삭제를 위한 MFA, logs 등의 기능들을 제공
7. IAM을 통한 접근 보안, 버킷에 대한 접근 권한인 S3 Bucket Policy, Access Point 생성, ACL, CORS, 객체 잠금 기능 등 보안기능 제공
8. Encryption : SSE-S3 (자체키 기반), SSE-KMS (관리할 수 있는 KMS키 기반), SSE-C, client-side 인증, TLS 전송보안
9. S3 객체에 대한 대량 처리가 필요할 때 -> S3 Batch (use case : 비암호화 객체 일괄 암호화 등)
10. 성능 : Multi-part upload (파일 병렬식 upload), S3 Transfer Acceleration, S3 Select (필요한 데이터만 검색)
11. Automation : S3 Event Notifications (SNS, SQS, Lambda 등과 결합 가능)
12. Use cases : 정적 파일, key-value 형태의 대량 file 저장소, 웹사이트 호스팅 등
    
    
    

DocumentDB (mongoDB)

1. DocumentDB는 MongoDB의 Aurora 버전
2. NoSQL DB
3. mongoDB 기반
4. JSON 데이터를 저장, 쿼리, 인덱스
5. 배포개념이 Aurora와 유사 -> 완전 관리형 DB, 3 AZ에 걸친 고가용성
6. 스토리지는 자동적으로 10GB까지 확장됨
7. 초당 수백만개의 요청을 작업하기 위해 scale될 수 있음
   
   
   

Amazon Neptune

• Graph 데이터셋의 예시 : Social Network -> 과정(데이터)들이 모두 연결됨
  1. 사용자는 친구를 팔로우
  2. 댓글을 게시
  3. 다른 사용자의 댓글을 좋아요
  4. 게시글을 공유
     
     
     

1. 완전 관리형 graph DB
2. like Social Network
3. 3 AZ에 걸쳐 최대 15개의 읽기전용 복제본을 가짐 -> 가용성이 높음
4. 고도로 연결된 데이터 셋을 사용하는 app에 적합
5. DB에 수십억 개의 관계를 저장
6. 그래프를 쿼리할 때의 지연시간은 ms단위
7. 위키피디아 지식 데이터와 같이 고도로 연결되어 있는 데이터에 적합 (추천 엔진, 소셜 네트워크 등)
   
   
   

Amazon Keyspaces (Apache Cassandra)

1. Apache Cassandra를 지원
2. Apache Cassandra : 오픈 소스의 NoSQL 분산 DB
3. Serverless
4. 완전 관리형, 확장성/가용성 높음
5. app 트래픽에 따른 Auto Scaling 기능 제공
6. 테이블 데이터는 여러 AZ에 걸쳐 세 번 복제됨
7. 쿼리 수행에는 CQL(Cassandra Query Language)가 사용됨
8. 지연시간 10ms
9. 초당 수천 건의 요청 처리
10. On-demand mode과 Provisioned mode with auto-scaling 두 가지 모드 지원 (DynamoDB와 동일)
11. 암호화, 백업, 최대 35일의 PITR 기능 제공
12. Use cases : IoT 장치 정보와 시계열 데이터 저장 등
    
    
    

Amazon QLDB

1. Quantum Ledger Database
2. Ledger : 금융 트랜잭션을 기록하는 장부
3. 완전 관리형, Serverless, 고가용성 (3개 AZ에 걸쳐 복제)
4. app 데이터의 시간에 따른 변경 내역을 검토하는 데 사용 -> 장부
5. DB에 데이터를 기록하면 삭제하거나 수정할 수 없음 -> 불변 시스템
6. QLDB Journal내에서 수정할 때마다 암호화 해시가 계산되어 추가됨 -> DB에서 삭제 불가, 수정본 추가방식(?)
7. 일반 ledger blockchain framework보다 2~3배 나은 성능
8. 관리형 블록체인과의 차이점은 QLDB는 탈중앙화 개념이 없음 -> Amazon 소유의 중앙 DB에서만 데이터 작성 가능

Amazon Timestream

1. 시계열 DB
2. 완전 관리형, 빠름, scale 가능, serverless
3. 시계열(timestream) : 시간정보를 포함하는 point의 모음
4. DB의 용량을 자동으로 확장/축소 가능
5. 매일 수조 건의 이벤트를 저장/분석 가능
6. 시계열 데이터에는 관계형 DB보다 시계열 DB를 활용하는 것이 속도나 비용측면에서 훨씬 이점
7. SQL에 호환
8. 최신 데이터는 메모리에 저장
9. 과거 데이터는 비용 효율적인 스토리지 계층에 저장
10. 시계열 분석 기능이 있어서 실시간으로 분석하고 패턴을 찾을 수 있음
11. 전송중 암호화, 저장 암호화를 지원
12. Use cases : IoT apps, 실시간 분석, 운영 app 등
    
    
    

• Architecture

Serverless

• Serverless : Server가 없는 것은 아니고 관리할 필요가 없음 (서버가 보이지 않거나 provisioning 필요x)
  
  
  

• Serverless in AWS

1. AWS Lambda
2. DynamoDB
3. AWS Cognito
4. AWS API Gateway
5. Amazon S3
6. AWS SNS & SQS
7. AWS Kinesis Data Firehose
8. Aurora Serverless
9. Step Functions
10. Fargate

AWS Lambda

• AWS Lambda : 관리할 서버가 필요없는 코드실행 서비스
  
  
  

• 특징

1. 최대 15분 실행
2. 호출을 받을 때, 온디맨드로 실행
3. 실행되는 동안에만 비용 청구
4. 스케일링 자동화
   
   
   

• 장점

1. 쉬운 가격 책정 (요청 횟수 및 컴퓨팅 시간에 따라 책정 -> Lambda가 실행된 만큼)
2. Free Tier에서는 요청 백만건과 40GB/s의 컴퓨팅 시간 제공
3. 다양한 AWS 서비스와 연결 가능
4. 많은 프로그래밍 언어와 호환 -> 오픈소스 덕분
   • Node.js
   • Python
   • Java
   • C#
   • Golang
   • Ruby
   • Lambda Container Image -> Container Image 자체가 Lambda의 API가 됨 (Container 상에서 Lambda API가 있어야하기 때문) -> Image에 Lambda API가 없는 경우, ECS나 Fargate에서 Container를 실행하는 것이 더 좋음
   • etc...
5. CloudWatch와의 통합 쉬움
6. 함수당 최대 10GB의 램을 제공받을 수 있음 -> RAM을 증가시키면, CPU 및 네트워크 성능도 같이 좋아짐
   
   
   

• Lambda와의 통합 방식

1. API Gateway : Lambda를 호출하는 Rest API 생성
2. Kinesis : Lambda를 활용해 데이터 변환
3. DynamoDB : DB상에 특정 이벤트가 생기면 Lambda를 실행하도록 트리거를 생성
4. S3 : 언제든 Lambda를 실행할 수 있음
5. CloudFront : Lambda 전용 CloudFront, Lambda@Edge
6. CloudWatch / EventBridge : AWS 인프라이 어떤 일이 생기고 자동 대응을 하려고할 때 활용
7. CloudWatch Logs : log를 스트리밍할 때 활용
8. SNS : SNS로 알림을 보내고 SNS topic에 따른 처리를 진행할 때 활용
9. SQS : SQS Queue 메세지 처리할 때 활용
10. Cognito : DB를 활용하여 로그인할 때마다 응답 (인증처리)
    
    
    

• Example1 : Thumbnail creation

• Example2 : Serverless CRON Job
  : EC2 등에서 CRON을 활용할 때, 스케줄링이 안되는 시간대에는 낭비가 있어서 Lambda에 활용하는 것이 적절 -> CloudWatch에서 스케줄링 되도록 설정

• Lambda Pricing

1. 호출당 청구
   • 처음 백만건 요청은 무료
   • 이후 백만건 마다 20센트 과금
2. 기간당 청구 (1ms 단위)
   • 한달간 첫 40만GB/s(=1GB RAM을 40만초 사용) 동안은 무료
   • 이후에는 60만GB/s당 1달러 과금
     
     
     

Lambda Limits

• 실행한도

1. Memory : 128MB ~ 10GB (1MB단위로 증가, CPU성능도 같이 증가)
2. 실행시간 : 최대 900초 (15분)
3. 환경변수 : 최대 4KB
4. 임시공간 : 512MB ~ 10GB (/tmp, 파일처리 등과 같이 공간활용이 필요할 때 사용)
5. 동시실행 : 1000개 (미리 예약하고 쓰는 것 권장)
   
   
   

• 배포한도

1. 압축 시 50MB, 비압축 시 250MB -> 한도 넘는 경우, /tmp공간 활용 필요
2. 배포 후 시작할 때, 크기가 큰 파일이 있을 경우 /tmp 공간 활용 권장
3. 환경변수 : 최대 4KB
   
   
   

Lambda SnapStart

• Lambda SnapStart : Lambda SnapStart이 활성화 되어 있을 경우, Lambda Function이 미리 초기화된 상태에서 호출 -> 성능 향상

• Java11 이상에서 실행되는 Lambda Function의 성능을 추가 비용없이 10배 높여줌

• 원리 : Lambda Function이 실행되면 메모리와 초기화된 Lambda Function 디스크 상태의 SnapShot 생성됨 -> 생성된 SnapShot은 캐싱되어 다음 Lambda Function 실행 때 활용됨 -> SnapStart
  
  
  

• LifeCycle

Edge Function

• Edge Function : app에 도달하기 전, Edge에서 특정 logic을 실행하는 Function -> 지연시간 최소화

• Edge Function을 사용하면 전역으로 배포되기 때문에 서버관리가 필요하지 않음

• Use Case : CrontFront의 CDN 콘텐츠 커스터마이징
  
  
  

• CloudFront 함수의 종류

1. CloudFront Functions
2. Lambda@Edge
   
   
   

• Use Cases

1. Dynamic Web Application
2. 검색 엔진 최적화 (SEO)
3. Origin-DataCenter간 지능형 라우팅
4. 엣지에서의 실시간 이미지 변환
5. A/B Test
6. 사용자 인증 및 인가
7. 사용자 우선순위 지정
8. 사용자 추적 및 분석
9. Website Security and Privacy
   
   
   

• CloudFront Functions

1. javascript로 작성된 경량함수
2. 확장상이 높고 지연 시간에 민감한 CDN 커스터마이징에 활용
3. 최대 실행시간은 1ms 미만 (very simple code), 초당 백만 개의 요청 처리
4. 고성능/고확장성, viewer의 요청과 응답을 수정할 때에만 사용
5. 모든 코드가 CloudFront에서 직접 관리
6. Use Cases
   • 캐시 key 정규화 (요청의 attribute를 변환하여 key 변환)
   • HTTP 헤더 조작
   • URL를 다시 쓰거나 redirect
   • 요청 인증 및 인가 (ex. JWT 생성 및 검증 등)
     
     
     

• Lambda@Edge

1. Node.JS나 Python으로 작성
2. 초당 수천 개의 요청 처리
3. 모든 CloudFront 요청 및 응답을 변경할 수 있음 -> Origin 요청/응답도 수정 가능
4. us-east-1 region에만 코드 작성 가능 (CloudFront 배포를 관리하는 region과 같은 region -> 함수를 작성하면 CloudFront가 모든 location에 해당 함수 복제)
5. 최대 실행시간은 5~10초
6. Use Cases
   • 여러 라이브러리 로드
   • 타사 라이브러리 의존
   • SDK로 다른 AWS서비스에 접근
   • 네트워크를 통해 외부 서비스에서의 데이터 처리
   • 파일 시스템 및 HTTP요청 body에도 접근 가능

Lambda Network

• 기본적으로 Lambda 함수는 VPC 외부에서 시작 -> Lambda는 VPC내부에서 실행되는 AWS 서비스에 접근 불가 -> 인터넷상의 public API 접근 가능 -> VPC내 접근을 위해 VPC에서 Lambda 함수 시작 필요 -> VPC 생성 후 해당 서브넷을 Lambda에 할당하고 보안 그룹 추가 -> 서브넷에 생성된 ENI(Elastic Network Interface)를 통해 VPC 내부 서비스에 접근 가능

• RDS Proxy

1. RDS에 Lambda가 직접 접근하게되면, Lambda가 Scale-Out 되었을 때 RDS에 큰 부하를 줄 수 있음 -> RDS Proxy 활용 필요
2. DB 연결 pool을 공유함으로써 확장성 향상
3. 장애가 발생할 경우에 가용성이 향상되고 연결이 보존됨
4. RDS Proxy에서 IAM인증을 강화하여 보안을 높일 수 있고, credential을 Sercets Manager 안에서 관리할 수 있음
5. RDS Proxy를 통한 접근을 위해 Lambda는 반드시 동일 VPC내부에 있어야 함 (RDS Proxy는 public에서 접근 불가)

RDS/Aurora에서의 Lambda 호출

• RDS/Aurora에서의 Lambda 호출 : DB에서 일어나는 데이터 이벤트를 처리할 수 있음
• RDS for PostgreSQL/Aurora MySQL에서 지원
• AWS Console 설정이 아님
• RDS DB로부터 Lambda로 오는 트래픽 허용 필요 -> Lambda가 public일 경우, NAT GW/VPC Endpoint 등 사용할 수 있음
• RDS가 Lambda호출할 권한 필요 (IAM 정책 조정 필요)

• RDS Event Notifications

1. AWS 안에서 DB에 대한 정보(ex. created, stopped, start, etc...)를 알림 (메타데이터?)
2. DB안의 데이터는 포함하지 않음 (DB 컬럼정보x) -> DB 컬럼 데이터에 관한 정보는 Lambda를 통해야 함
3. 알림 전달 최대 시간 : 5분
4. SNS 또는 EventBridge에 전달 가능

DynamoDB

• 특징

1. 완전 관리형 DB
2. 다중 가용영역에 복제되므로 가용성 좋음
3. AWS 독점 NoSQL
4. 트랜잭션 지원 기능 있음
5. DB가 내부에서 분산되기 때문에 방대한 workload에 적용 가능
6. 초당 수백만 개의 요청 처리, 수조개의 rows, 수백 TB 스토리지 -> 성능 좋고, 일관성 높음
7. 보안 관련 기능은 IAM 활용
8. 비용이 적게 들고, 오토 스케일링 기능이 있음
9. 유지관리나 패치가 필요하지 않음
10. 테이블 클래스
    • Standard : 데이터가 빈번함
    • IA : 데이터가 빈번하지 않음
      
      
      

• 기초

1. Aurora나 RDS와 달리 DB를 별도 생성하지 않아도 됨 -> DynamoDB는 DB가 이미 존재함
2. 테이블로 구성된 DB
3. PK는 테이블 생성 시, 결정됨
4. 테이블마다 rows를 무한히 추가할 수 있음
5. 테이블당 attribute는 열로써 표시됨 -> null이 될 수도 있음
6. 열을 언제든 쉽게 추가할 수 있음 -> 각 row에서 attribute 형식이 달라도 됨
7. row의 최대 크기는 400KB
8. 다양한 데이터 형식 지원
   • Scalar : 문자열, 숫자, 바이너리, 불리언, null
   • Document : List, Map
   • Set : String Set, Number Set, Binary Set
     9. DynamoDB는 스키마를 빠르게 적용해야할 때 유용
     
     
     

• Read/Write Capacity Modes

1. Provisioned Mode (default)
   • 사전에 용량을 Provisioning
   • Provisioning된 RCU(Read Capacity Unit)/WCR(Write Capacity Unit)만큼의 비용 지불
   • 오토 스케일링 기능이 있어 테이블에 대한 트래픽에 따라 RCU/WCR 조절 가능
   • 스키마가 서서히 적용되고, 비용 절감이 필요할 때 활용
   • 대충 Workload의 범위 예측 가능 -> 오토 스케일링 기능으로 조절 하면됨
2. On-Demand Mode
   • 읽기/쓰기 용량이 Workload에 따라 자동 확장
   • RCU/WCR 개념이 없음 (미리 Provisioning 하지 않기 때문)
   • 사용한 만큼의 비용 지불
   • Workload를 예측할 수 없거나 급격히 증가하는 경우에 활용
   • Workload 범위도 예측이 안될 경우

• DynamoDB Accelerator (DAX)

1. 완전 관리형 seamless in-memory cache
2. 고가용성
3. 읽기 작업이 많을 때, DAX 클러스터를 생성하고 데이터를 캐싱함
4. ms단위의 저지연 시간의 읽기 성능 제공
5. 기존 DynamoDB API와 호환 -> app logic 변경이 필요하지 않음
6. TTL은 default로 5분으로 설정되어있으나 변경 가능
7. ElastiCache가 아닌 DAX를 사용하는 이유
   • 개별 객체에 대한 cache 처리에 유용 -> 집계 결과 처리에는 ElastiCache가 더 좋음
   • 쿼리 및 스캔 cache 처리에 유용 -> 대용량의 연산을 저장할 때 좋음
   • DynamoDB 앞에 배치

• DynamoDB Stream Processing

1. 테이블에 대한 수정사항을 Stream으로 생성할 수 있음 -> 변경사항에 실시간으로 반응
2. Use cases
   • 사용자 테이블에 새로운 사용자가 등록되었을 때, 환영 이메일 전송
   • 실시간 사용 분석
   • 파생 테이블 insert
   • region간 데이터 복제
   • 테이블 변경사항에 대한 Lambda 함수 실행
3. Stream 처리의 두 가지 유형
   • DynamoDB Streams : 보존기간 24시간, 소비자 수 제한, Lambda 트리거와 주로 사용, 자체적 읽기를 위해 DynamoDB Stream Kinesis 어댑터 사용
   • Kinesis Data Streams : 보존기간 1년, 더 많은 소비자 수, 데이터 처리 방법이 다양 (Lambda, Kinesis Data Analytics, Kinesis Data Firehost, Glue Streaming, etc...)

• DynamoDB Global Tables

1. 여러 region간 복제 가능 테이블
2. 여러 region중 하나의 region의 테이블에 작업을 하면, 다른 region에 복제되어 있는 테이블에도 자동 동기화
3. 다수의 region간 복제본을 통해 DynamoDB로의 저지연 접근을 가능하게 함
4. 다중 활성 복제 가능 (Active-Active)
5. 모든 region에서 테이블에 데이터를 읽고 쓸 수 있음
6. DynamoDB Stream 기능 활성화 필요

• DynamoDB Time To Live (TTL)

1. 시간이 지나면 자동으로 item(=row)를 삭제하는 기능
2. row의 attributes중 하나
3. 현재 시간이 TTL상의 시간을 초과하면, 해당 item 삭제 처리
   
   
   

• Backups for disaster recovery

1. PITR (point-int-time recovery)를 활용하여 지속적 백업 가능
   • 활성화를 선택하면 35일 동안 지속
   • 백업기간 내 언제든 복구 수행 가능
   • 복구를 진행할 경우, 새로운 테이블 생성
2. On-demand backups
   • 데이터를 직접 삭제할 때까지 보존
   • 테이블의 성능이나 지연시간에 영향을 주지 않음
   • 백업 관리 서비스로 AWS Backup이 있음 -> 해당 백업 방식에 lifecycle 홞성화 가능, region간 백업 복제 가능 -> 새로운 테이블 생성
     
     
     

• Amazon S3와의 통합

1. S3에 DynamoDB 테이블을 내보내기 위해 PITR 활성화 필수 -> 35일 내에 내보내기 가능
2. 쿼리 실행 시, AWS Athena 서비스 활용
3. 테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향이 없음
4. S3 내보내기를 통한 데이터 분석 가능
5. 감사 목적의 snapshot 확보 가능
6. S3에서 다시 DynamoDB로 가져올 때 데이터의 대규모 변경 가능
7. 내보낼 때, DynamoDB JSON이나 ION형식 이용
8. S3에서 테이블을 가져올 때에는 CSV/JSON/ION형식의 객체를 기반으로 새로운 DynamoDB 테이블을 생성하게 됨 -> 쓰기 용량을 소비하지 않고 새로운 테이블 생성
9. 가져올 때 발생한 오류는 모두 CloudWatch Logs에 기록
   
   
   

API Gateway

• Client에서도 Lambda를 호출하려면 IAM권한 필요
• ALB와 Lambda의 조합을 활용하게 되면 HTTP endpoint가 노출됨 (서버리스가 아님)

• API Gateway : Client가 Lambda를 호출할 수 있도록 REST API를 제공하는 서버리스 서비스, Lambda 함수에 요청을 Proxy함
• 사용 이유

1. 인증 기능 제공
2. 사용량 계획 기능 제공
3. 개발 환경 기능 제공
   
   
   

• 특징

1. Lambda와 결합할 경우, 완전 서버리스
2. WebSocket 프로토콜 지원 -> 두 가지 방법의 실시간 스트리밍 가능
3. API Versioning을 핸들링 함 (Version 변경이 있어도 client와의 연결이 끊기지 않음)
4. dev, test, prod 등 여러 환경 지원
5. 여러 보안 기능 제공
6. API key 생성 -> client의 요청 조절
7. Swagger나 기타 Open API의 공통 표준을 가져올 수 있음 -> 내보낼 수도 있음
8. 요청 및 응답의 유효성 검증
9. SDK/API 스펙 생성
10. API 응답 캐싱
    
    
    

• 통합

1. Lambda Function : 서버리스로 Lambda를 client에게 노출시키는 가장 일반적인 방법
2. HTTP : 클라우드 환경 및 온프레미스 환경의 백엔드를 HTTP로 노출시킬 수 있음 -> 다양한 공통 기능 추가 (ex. 인증, 캐싱 등)
3. AWS Service : 어떤 AWS API도 노출 가능, Step Function workflow 시작, SQS로 메세지 전송
   
   
   

• Use Case (Kinesis Data Streams)
  : 사용자가 Kinesis Data Streams에 데이터를 전송할 수는 있지만 AWS 자격증명은 가질 수 없도록 설정

• Endpoint Types (API Gateway 배포방법)

1. Edge-Optimized (default)
   • global client용
   • global하게 접근할 수 있음
   • 모든 요청이 CloudFront edge location을 통해 들어옴 -> 지연시간 개선
   • API Gateway는 생성된 region에 위치
2. Regional
   • CloudFront를 원하지 않을 때 활용
   • API Gateway와 동일한 region의 사용자만 접근 가능
   • 별도로 CloudFront를 배포하여 결합 가능 -> Edge-Optimized 배포와 동일한 결과이지만, CloudFront에 대한 더 많은 권한을 가질 수 있음
3. Private
   • not Public
   • 배포된 VPC내에서만 접근 가능 (ENI와 같은 VPC 인터페이스 활용)
   • API Gateway로의 접근을 정의할 때 리소스 정책 사용
     
     
     

• Security

1. IAM Role을 사용하여 사용자 식별 -> API Gateway에 접근할 때, IAM Role 사용 필요
2. 외부 사용자에 대한 보안 조치로 Amazon Cognito 사용 가능
3. 자체로직(ex. Lambda Function)을 구현할 수도 있음 -> Custom Authorizer (사용자 지정 권한 부여자) 활용
4. HTTPS의 CDN(Custom Domain Name)을 ACM(AWS Certificate Manager)와 통합 가능
   • Edge-Optimized endpoint를 사용할 경우, 인증서는 us-east-1에 있어야 함
   • region endpoint를 사용할 경우, 인증서는 API Gateway와 동일한 region에 있어야 함
5. Route 53에 CNAME이나 A-alias record를 설정하여 도메인이 API Gateway를 가리키도록 해야 함
   
   
   

Step Functions

• Step Functions : Serverless Workflow를 시각적으로 구성할 수 있는 기능, 주로 Lambda 함수를 설계할 때 활용

• Lambda 함수 뿐만 아니라 EC2 연동, ECS, 온프레미스 서버, API Gateway, SQS 등의 workflow 구조를 표현할 때에도 활용
• Workflow에 사람이 개입하여 승인해야 진행되는 단계를 설정할 수 있음
  
  
  

Amazon Cognito

• Amazon Cognito : 사용자에게 웹 및 모바일 앱과 상호작용할 수 있는 자격증명을 제공하는 서비스, 익명의 사용자에게 자격증명을 부여하여 해당 사용자를 인식(Cognito)하게 됨
  
  
  

• IAM vs Cognito : Cognito는 AWS 외부의 app 사용자를 대상으로 함 (keywords : 수백명의 사용자, 모바일 사용자, SAML 인증)
  
  
  

• Cognito User Pools (CUP)

1. 웹 및 모바일 앱을 대상으로 하는 서버리스 사용자 DB
2. 이름/이메일/비밀번호 조합으로 간단한 로그인 절차 수립 가능
3. 비밀번호 재설정 기능
4. 이메일/폰번호 유효성 검증
5. Multi-factor Authentication (MFA) 가능
6. Facebook, Google, SAML 등 통합 가능 (Federated Identities)
7. API Gateway 및 ALB와 통합 가능 -> 유효성 검증 책임을 API Gateway나 ALB에 넘김
8. app 사용자에게 가입기능 제공

• Cognito Identity Pools

1. 사용자에게 임시 AWS Identity를 부여하여 AWS 계정에 직접 접근 -> 일부 AWS 서비스에 직접 접근 (API Gateway, ALB 직접 접근x)
2. Cognito User Pools와 통합 가능
3. 타사 로그인 활용 가능 (ex. google 등)
4. API Gateway를 통해 AWS 서비스에 접근 가능
5. 자격증명에 적용되는 IAM 정책이 Cognito에 사전 정의되어 있음
6. User_id 기반으로 사용자를 정의하여 세분화된 제어 가능

• Low Level Security
  : DynamoDB Leading key와 Cognito 자격증명 user_id와 같아야 함. -> 해당 조건을 충족시킨 사용자만 DynamoDB 테이블에 접근 가능

Docker Containers Management on AWS

• Amazon Elastic Container Service (Amazon ECS) : Amazon의 container 플랫폼
• Amazon Elastic Kubernetes Service (Amazon EKS) : Amazon에서 관리되는 Kubernetes
• Amazon Fargate : Amazon의 서버리스 Container 플랫폼, ECS/EKS와 함께 동작 가능
• Amazon ECR : Container Image 저장
  
  
  

Amazon ECS

• AWS에서 docker container 실행 = ECS Cluster에서 ECS task 실행 (task = container, 생성된 task로 서비스를 배포하는 작업이 추가로 진행되어야 함 -> cluster에서 server 생성 후 맞는 type을 선택하고 Family로 사전 생성한 task를 선택하면 됨 -> 사전에 서비스 배포가 되었기 때문에 해당 task의 갯수가 늘어나면, container의 갯수도 늘어나게됨)
  
  
  

• ECS Cluster의 Launch Type (task 생성 시, 선택)

1. EC2 인스턴스
   • infra를 직접 provisioning하고 유지해야함
   • EC2 인스턴스는 각각 ECS Agent를 실행해야 함 -> ECS 클러스터 등록
   • ECS task가 실행되면 AWS가 container를 실행하거나 중단시킴 -> 새로운 Docker Container가 생성되면 임의로 ECS Cluster에 등록된 EC2 인스턴스를 선택하여 배포함

2. Fargate
   • AWS에서 docker container를 실행하는데, infra를 provisioning 하지않아서 관리할 EC2인스턴스는 없음 -> 서버리스 (서버를 관리하지 않아서)
   • ECS task 정의만 생성하면 필요한 CPU/RAM에 맞게 ECS task를 AWS가 대신 실행 (관리자는 어느 서버에서 실행되는지 모름)
   • 확장이 필요하면 ECS task만 더 생성하면 됨

• IAM Roles

1. EC2 인스턴스 profile
   • EC2 type에만 활용됨
   • ECS Agent만 EC2 인스턴스의 profile을 관리하고, 이를 활용하여 ECS API 호출 -> ECS 서비스가 CloudWatch log에 API 호출하여 Container log를 보냄 -> ECR로부터 docker image 수신
   • Secret Manager나 SSM Parameter Store에서 민감 데이터를 참고하기도 함
2. ECS Task Role
   • ECS task는 Task Role을 가짐
   • EC2 및 Fargate type에 모두 활용됨
   • 만약 두 개의 task가 있다면, 각각에 특정 Role을 만들 수 있음
   • ECS task role은 각자 다른 ECS 서비스를 이용할 수 있음 (ex. task A는 S3 API 호출, task B는 DynamoDB에 API 호출)
   • task를 정의하여 생성할 때, Role을 정의할 수 있음

• Load Balancer Integrations

1. EC2 및 Fargate type 모두 가능
2. ECS 클러스터 내부에 많은 ECS task가 실행됨
3. 많은 ECS task는 HTTP/HTTPS endpoint로 활용되길 원함 -> ALB 활용 -> 사용자는 ALB를 경유하여 ECS task에 연결될 수 있음
4. ALB대신 NLB가 사용될 수도 있는데, 해당 경우는 처리량이 많거나 높은 성능이 요구될 때 권장 (AWS Private Link와 사용할 때 권장)

• Data Volumes (EFS)

1. EC2 task에 File System을 마운트하여 데이터 공유 원함 -> EFS 활용
2. EFS는 EC2 및 Fargate 모두에 호환됨
3. EFS를 마운트한다면, 가용영역이 달라도 데이터를 공유할 수 있음 (EFS의 특징)
4. EFS를 활용하여 다른 task와도 연결 가능
5. EFS내부의 Fargate를 쓸 때 좋음 (EFS도 서버리스이기 때문)
6. Use case : Multi-AZ에 걸쳐 배포된 Container의 영구적인 Storage
7. Amazon S3는 ECS에 의해 마운트될 수 없음

ECS Auto Scaling

• ECS Auto Scaling : ECS task의 수를 자동으로 늘려주고 줄여줌
  
  
  

• Scaled Metrics

1. ECS의 CPU 사용률
2. ECS의 RAM 사용률
3. ALB의 target당 요청 수
   
   
   

• Scaling Types

1. Target Tracking : CloudWatch의 특정 값 기준
2. Step Scaling : CloudWatch의 특정 알람 기반
3. Scheduled Scaling : 트래픽의 변화가 예측되는 정해진 시간 기준
   
   
   

• ECS Auto Scaling (task level) != EC2 Auto Scaling (EC2 Instance level) -> EC2 Auto Scaling 기능이 없다면, Fargate로 전환 후 ECS Auto Scaling을 쓰는 것이 좋음 -> 서버리스
  
  
  

• EC2 Instance Auto Scaling 방법 (launch type이 EC2일 때)

1. EC2 Auto Scaling Group
2. ECS Cluster Capacity Provider : 새 task를 실행할 용량이 부족하면, 자동으로 ASG 확장 (with ASG, ECS Cluster CPU/RAM사용량 기반)
   
   
   

• Example : ECS Cluster Capacity Provider를 활용하는 Service의 트래픽이 증가할 경우, CloudWatch가 CPU사용량 증가를 인식하고 Alarm을 발생시킴 -> CloudWatch Alarm은 scale out 요청을 하게되고, Capacity Provider는 희망용량을 증가시켜 task가 자동으로 증가됨 -> task가 증가됨에 따라 EC2인스턴스가 증가됨

• Event Bridge에 의한 ECS
  : EventBridge는 수신된 Event를 전달하는 역할 -> Event를 받으면 ECS task를 실행시키기 위한 rule이 설정되어 있을 경우, ECS task 실행에 대한 요청을 ECS Cluster에 보냄 -> ECS task Role에 따라 처리

• Event Bridge Schedule에 의한 ECS
  : 1시간마다 스케줄링되는 EventBridge에 의해 특정 ECS Task가 실행됨 -> 생성되는 task Role에 맞는 작업 진행 -> 서버리스

• SQS Queue에 의한 ECS
  : 서비스가 SQS Queue로부터 메세지를 직접 가져와 처리

• Intercept StoppedTasks using EventBridge
  : EventBridge를 통한 ECS Cluster내에서 Event를 가로채는 방식 -> ECS Cluster내에서 task에 관한 Event가 발생될 경우, EventBridge에 트리거됨 (json형태의 데이터 전송) -> 해당 트리거를 이용하여 SNS topic에 메세지를 전송하고, 관리자에게 메일을 전송하는 등의 case에 활용될 수 있음

Amazon ECR

• Amazon ECR : Elastic Container Registry, AWS에 Docker image를 저장하고 관리하는데 사용
  
  
  

• 계정에 한해 image를 비공개로 저장 -> 여러 계정으로 권한 확대할 수 있음

• public으로 image를 저장할 수도 있음

• image는 background에서 S3에 저장됨

• ECS Cluster내 EC2 IAM Role을 통해 ECR로부터 Docker image를 가져올 수 있음 (ECR에 대한 모든 접근은 IAM이 보호)

• image의 단순 저장뿐만 아니라 image 취약점 스캐닝, versioning, tag 및 life cycle 확인 지원

Amazon EKS

• Amazon EKS : Elastic Kubernetes Service, AWS에서 kubernetes를 실행할 수 있는 service
  
  
  

• Amazon ECS와 비슷하지만, 사용하는 API가 다름

• EKS Launch Modes

1. EC2 Instance : EC2에 Worker Node 배포
2. Fargate : EKS Cluster에 서버리스 Container 배포
   
   
   

• 특징

1. kuberentes는 모든 Cloud에서 지원 (Azure, Google Cloud 등) -> 클라우드간 마이그레이션에 유용
2. Use Case : 회사가 온프레미스나 클라우드에서 Kubernetes or Kuberentes API를 사용중일 때, 해당 Kubernetes를 관리하기 위해 Amazon EKS를 활용

• Node Types

1. Managed Node Groups : AWS로 노드(EC2 Instance)를 생성하고 관리
   • 노드는 EKS로 관리되는 ASG의 일부
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
2. Self-Managed Nodes : 노드를 직접 생성하고 EKS Cluster에 등록하여 Cluster내 ASG에 의해 관리
   • 사용자 지정사항 or 제어대상이 많은 경우 사용
   • 최적화된 Amazon EKS AMI를 사용하면 부팅시간을 줄일 수 있음
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
3. Fargate
   • 노드를 원하지 않는 경우 사용
   • 유지관리 필요 없음
     
     
     

• Data Volumes

1. EKS Cluster에 Storage Class manifest를 지정해야 함
2. CSI (Container Storage Interface)라는 규격의 드라이버 사용 -> Cluster 설정의 Add-ons에서 해당 드라이버 설정 필요
3. Amazon EBS, Fargate모드를 지원하는 유일한 유형인 Amazon EKS, Amazon FSx for Lustre, Amazon FSx NetAPP ONTAP 지원
   
   
   

AWS App Runner

• AWS App Runner : 인프라나 소스코드를 알 필요 없이 누구나 AWS에 배포할 수 있음

• 완전 관리형 서비스로 서비스 규모에 따라 Web Application, API 배포를 지원
  
  
  

• 배포 방법

1. Docker image or Source code를 가지고 원하는 구성 설정 -> CPU/RAM 설정, ASG여부 등
2. 설정을 기반으로 Container에 자동 배포
3. URL이 생성되면 해당 URL로 접근 가능

• 장점

1. Auto Scaling 가능
2. 고가용성
3. Load Balancing
4. 암호화 기능 지원
5. custom VPC 배포 지원
6. DB, 캐시, 메세징 서비스 등에 연결 가능
   
   
   

• Use case : 웹앱 application의 신속한 배포가 필요한 경우