Ian's Archive 🏃🏻

AWS CertifiedDeveloper - Associate 대비 정리 2

Cloud

2023.08.10.

7. VPC

VPC : 리소스(지역 리소스)를 배포하기 위한 사설 네트워크

EC2, RDS, ELB 등을 탑재하고 ENI(Elastic Network Interface)에 사설 IP혹은 공인 IP를 부여해 사용
서브넷 사용 시 VPC내에서 네트워크 분할 가능
라우팅 테이블 설정 추가해 공용 서브넷 인터넷 접근 o, 사설 서브넷 인터넷 접근x
NAT Gateways를 사용하면 프라이빗 서브넷의 인스턴스가 프라이빗 상태를 유지하며 인터넷 액세스 가능
-> 작동 방식 : NAT Instance를 공용 서브넷에 배포하고 사설 서브넷에서 게이트 웨이로 라우팅

NACL : 공용 서브넷을 서브넷 수준에서 방어(default : All allow)
-> 그 후, 보안 그룹 적용

VPC Flow Logs

인터페이스로 들어가는 모든 IP 트래픽에 대한 정보 캡처

접근이 거부되거나 트래픽이 잠기거나 VPC 내 허용된 트래픽을 디버깅 할 때 사용
ex) Elastic Load Balancers, ElasticCache, RDS, Aurora, etc
VPC Flow Log는 S3, CloudWatch Logs 및 Kinesis Data Firehose로 이동 가능

VPC Peering

2개의 VPC를 비공개로 연결

동일한 네트워크에 있는 것처럼 작동
CIDR(IP 주소 범위)이 겹치지 않아야 한다.
통신하는 각 VPC에 설정해야 한다
연결 생성 요금 X, 연결을 통한 전송 요금 O

VPC Endpoints

VPC 내 Resource들이 VPC 외부 서비스 (S3, Dynamo DB, Cloudwatch) 등에 접근할 때 Internet Gateway, NAT Gateway 등의 외부 인터넷전송 서비스를 타지 않고 내부 네트워크를 통해 접근할 수 있도록 지원하는 서비스

즉, AWS 여러 서비스와 VPC를 연결하는 중간 매개체로 VPC 바깥으로 트래픽이 나가지 않고 AWS의 여러 서비스 사용

보안 강화, 비용 절감, 권한 제어, VPC 종속

온프레미스 데이터 센터와 AWS를 연결 할 경우

Site-to-Site VPN을 사용해 공개 인터넷으로 연결
- 링크가 즉시 설정됨
- 적은 대역폭에 추천
Direct Connect(DX)를 사용해 AWS에 비공개로 연결
- 전송 데이터양에 따라서 비용이 달라지지 않음
- 시간당 비용지불
- 웨어하우스와 동일한 AWS 리전에 설치하는게 경제적임
- 여러 DX 위치에서 DX연결 구성시 높은 복원력과 내결함성 획득

8. S3

백업이나 스토리지 용도로 사용 (파일 저장, 디스크 저장)

파일을 버킷에 저장하는데 최상위 디렉토리 개념이라고 보면 된다.
퍼블릭 액세스 차단 기능을 사용해 비공개로 만들 수 있음
x-amz-server-side-encryption 헤더를 통해 암호화 보장
실수로 인한 객체 삭제 방지를 위해 MFA Delete를 사용(루트 계정만 가능)

버킷

버킷은 계정에 생성되고 전역적으로 고유한 이름을 가진다.
리전 단위로 정의

객체

객체는 파일을 말한다.
객체에는 키 존재 -> 파일의 전체 경로 ex) s3://my-bucket/my_folder1/another_folder/my_file.txt
-> 키는 접두사(s3://my-bucket/my_folder1/another_folder/) + 개체 이름(my_file.txt)
버킷 내에는 디렉토리 개념이 없음 (슬래시가 포함된 매우 긴 이름의 키)
개체 값은 최대 5TB (5GB가 넘으면 5GB 짜리 1000개로 나눠 올려야 함)
메타 데이터를 가질 수 있는데 Key-Value 형태

정책

Bucket Policies : S3 콘솔의 버킷 전체 규칙 (교차 계정 허용)
Object Access Control List : 보다 세분화 (비활성화 가능)
Bucket Access Control List : 보다 세분화 (비활성화 가능)

정책은 json 파일로 명시

copyButtonText

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AddPerm",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": [""]
    }
  ]
}

Resource 속성 : 적용되는 버킷, 객체 정의
Effect 속성 : Allow / Deny
Action : 허용하거나 거부할 대상 API (위에선 GetObject)
Principal : 적용 할 사용자나 계정 명시

추가로 기업의 데이터 유출을 막기위해 Bucket을 공개하지 않는 설정 가능

S3를 퍼블릭으로 공개하면 정적 웹사이트를 호스팅하고 인터넷에서 액세스 가능
S3에서 파일의 버전 지정 가능 (버킷 수준에서 활성화)
- 활성화 이전엔 모든 파일의 버전 null
- 버전 관리를 중단해도 이전 버전 삭제x

Replication

원본 및 대상 버킷에서 버전 관리를 활성화 해야 한다
적절한 IAM 권한 부여해야 한다.
복제는 비동기식으로 백그라운드 에서 진행
CRR(Corss-Region Replication) : Compliance, 저 지연 엑세스, 계정간 복제
SRR(Same-Region Replication) : 로그 집계, 프로덕션과 테스트 간의 실시간 복제
기존에 있던 객체나 복제가 실패한 객체를 복제할 땐 S3 Batch Replication 기능 사용

8.1 S3 Storage Classes

객체 생성 시 객체 클래스 선택 가능

내구성 : 그냥 파일 손실이 매우매우 적다는 뜻
가용성 : 스토리지 클래스에 따라 다른데 S3 Standard경우 연간 53분 정도 사용 불가

1.Standard : 자주 엑세스 하는 데이터, 짧은 대기 시간 및 높은 처리
- ex) 빅데이터 분석, 모바일 및 게임 App
2.S3 Infrequent Access : 덜 사용 하지만 필요할 때 접근이 빠르다.
- 비용은 적지만 데이터 조회 시 비용 발생
- ex) 주로 백업 용도
3.S3 One Zone-Infrequent Access : 온프레미스 데이터나 재 생성할 수 있는 데이터의 백업
4.Glacier Storage Class : 저렴한 객체 스토리지, 아카이브나 백업
- 스토리지 당 비용 발생, 검색 건당 비용
- Glacier Instant Retrieval : 밀리 초 단위 검색, 최소 스토리지 90일, 분기당 한번 액세스
- Glacier Flexible Retrieval : 신속(1~~5분), 표준(3~~5시간), 대량(5~12시간), 무료, 최소 보관 90일
- Glacier Deep Archive : 장기 저장용, 최소 보관기간 180일
5.S3 Intelligent-Tiering : 액세스 패턴에 따라 객체를 액세스 계층 간 이동 가능
- 월별 객체 모니터링 비용과 자동 이동 비용 발생

8.2 S3 Life Cyle Rule

Transition Actions(전환 작업) : 객체가 다른 스토리지 클래스로 전환되도록 구성
Expiration Actions(만료 작업) : 일정 시간이 지나면 객체가 만료(삭제) 되도록 구성
- ex) 엑세스 로그파일 365일 이후 삭제, 파일의 이전 버전 삭제
특정 접두사에 규칙 생성

Amazon S3 Analytics 사용!

객체를 올바른 스토리지 클래스로 전환 할 시기 결정에 도움
보고서는 매일 업데이트

8.3 S3 Event alert

원하는 만큼 S3 이벤트 생성 가능
객체명 필터링 가능
SNS, SQS, Lambda Function, Amazon EventBridge으로 전송 가능

8.4 S3 성능

S3는 기본적으로 높은 성능, 대기 시간은 100-200ms으로 자동 확장

upload 향상 방법

Multi-Part Upload : 용량이 큰 파일 저장 시 Multi-Part Upload사용, 병렬 처리 (100MB이상이면 권장, 5GB이상 필수)
S3 Transfer Acceleration : 다른 지역 S3로 데이터 전달 시 AWS 엣지 로케이션으로 파일 전송하여 전송속도 높인다.

download 향상 방법

-> S3 Byte-Range Fetches

특정 바이트 범위 요청하여 병렬화
장애 발생 시 복원력 향상
다운로드 발생 시 복원력 향상
일부 데이터만 활용해 검색하는데 사용

S3 Select

S3 Select로 CSV 형식으로 S3에 저장된 데이터셋의 일부를 검색해 필요한 부분만 추출 가능

Meta data, S3 Object Tags

객체를 만들고 업로드 할 때 메타 데이터나 태그 할당 가능
모든 메타데이터와 모든 태그를 DynamoDB에 넣으면 검색 가능
검색 결과는 Amazon S3객체로 추출

8.5 Security

4가지 방법으로 객체 암호화 가능

SSE (서버 측 암호화, defualt)
- SSE-S3 : Amazon S3 관리 키 사용
- SSE-KMS : AWS의 KMS 키사용 (KMS 서비스 API를 호출하기 때문에 부하가 추가된다.)
- SSE-C : 고객 제공 키 사용

x-zma-server-side-encryption헤더에 AES256, aws:kms 추가, SSE-C의 경우 사용자 키 추가

CSE (클라이언트 측 암호화)

S3 CORS

클라이언트가 S3버킷에서 교차 출처 요청을 하는 경우 활성화해야 한다.

8.6 S3 Access Log

S3버킷에 대한 모든 엑세스가 기록된다.
로깅 버킷을 모니터링 하면 무한루프 돌아서 기하 급수적으로 커진다. (주의)
Athena를 사용해 분석

사용자 or VPC별로 엑세스 가능한 엑세스 포인트 정의 가능
AWS Lambda 함수를 사용해 애플리케이션에서 개체를 검색하고 반환 전 람다함수 사용 가능
-> ex) XML to JSON, 이미지 크기 조정 및 워터마킹
S3 삭제 시 주의하기 위해 MFA 삭제 활성화 기능을 사용해 삭제 시 절차 추가 가능

9. AWS CLI, SDK, IAM 역할 및 정책

AWS EC2 내부에서 CLI 사용할 때 메타 데이터를 통해 IAM역할에 맞는 임시 보안 인증을 얻을 수 있다
EC2 인스턴스에서 IAM 역할 이름은 알 수 있지만 정책은 확인 불가
MFA를 CLI에서 사용하려면 임시 세션을 생성해야 하는데 STS GetSessionToken API 호출 시 생성
AWS는 AWS API를 연속으로 호출하는 횟수를 제한
-> 지수 백오프 전략 : 제한 시간을 1, 2, 4, 8초 식으로 늘려서 많은 서버 응답이 가능하게 함
- 자체 SDK 실행하는 경우
- 자체 사용자 정의 HTTP 정의 사용하는 경우
- 5xx 서버 오류 발생 시 / 4xx 클라이언트 오류 시엔 지수 백오프 전략 사용 x
AWS CREDENTIALS는 코드에 절대 위치 x
AWS API로 호출 시 Authorization 헤더에 서명 or 쿼리 스트링에 넣고 전달해야 한다.(SigV4)
- SDK, CLI로 요청할 땐 기본적으로 요청 서명해준다.

10. CloudFront

짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스, DDos공격에 대비하기 위해 Shield와 방화벽 사용

CDN이 나오면 CloudFront를 생각하자

Tip!!

추가로 Cloudflare는 제약이 크지만 무료임 + 엔터프라이즈급에서는 돈내지만 훨씬 쌈 / but 복잡해짐

이런 식으로 활용하면 유저의 IP는 X-Forwarded-for헤더에서 추출함
이 작업을 위해 nginx access logging 커스텀 설정 필요

CDN이란?

객체의 복사본이 전 세계 여러 위치에 보관되어 있기 때문에 향상된 안전성과 가용성을 제공

인터넷 서비스 제공자(ISP,Internet Service Provider)에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점
웹 페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱
해당 컨텐츠에 대한 요청이 들어오면 캐싱해 둔 컨텐츠를 제공
컨텐츠를 제공하는 서버와 실제 요청 지점 간의 지리적 거리가 매우 먼 경우 or 통신 환경이 안좋은 경우
-> 요청지점의 CDN을 통해 빠르게 컨텐츠 제공 가능
서버의 요청이 필요 없기 때문에 서버의 부하를 낮추는 효과
웹사이트 이미지, 비디오, 미디어 파일 또는 소프트웨어 다운로드 같은 정적 컨텐츠 배포에 적합

엣지 로케이션

컨텐츠가 캐싱되고 유저에게 제공되는 지점
AWS가 CDN 을 제공하기 위해서 만든 서비스인 CloudFront의 캐시 서버 (데이터 센터의 전 세계 네트워크)
CloudFront 서비스는 엣지 로케이션을 통해 콘텐츠를 제공
CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능이 뛰어나다.
객체의 복사본이 전 세계 여러 위치에 보관되어 있기 때문에 향상된 안전성과 가용성을 제공
콘텐츠가 이미 지연 시간이 가장 낮은 엣지 로케이션에 있는 경우 CloudFront가 콘텐츠를 즉시 제공

Cloud Front동작 방식

콘텐츠가 엣지 로케이션에 있으면 바로 전달, 없으면 최종 버전에 대한 소스로 지정된 오리진에서 검색

CloudFront는 AWS 백본 네트워크를 통해 콘텐츠를 가장 효과적으로 서비스할 수 있는 엣지로 각 사용자 요청을 라우팅하여 콘텐츠 배포 속도를 높인다.

한줄 정리하면 AWS 백본 네트워크를 사용하여 사용자의 요청이 통과해야 하는 네트워크 홉(hop) 수를 획기적으로 줄이고 성능 향상, 낮은 지연 시간 및 높은 데이터 전송 속도를 제공

tip!!

CloudFront Key Pairs는 Root계정만 생성 가능하다.

10.1 캐시 요청 정책

캐시의 각 객체는 캐시 키로 식별 - 호스트 이름 + URL 리소스 부분

캐시 기반
- CloudFront가 어떻게 캐싱할 지 설정
- 사용자, 디바이스, 언어, 사용자 위치 등을 캐시에 추가가능 HTTP 헤더, 쿠키, 쿼리 문자열
- 3가지 옵션 / Node, Whitelist, Include All-Except
- TTl 정책 설정
오리진 요청 정책
- 오리진 요청에는 포함하되, 캐시 키에는 포함x
- 캐시 정책이 아닌 자원을 요청하기 위해 필요한 부분 (HTTP 헤더, 쿠키, 쿼리 문자열)
- 사용자 지정 HTTP 헤더 또는 CloudFront HTTP 헤더를 오리진에 추가
응답 헤더 정책
- CloudFront가 응답과 함께 실어보낼 HTTP Header

10.2 캐시 무효화

CloudFront는 Backend Server의 변경사항에 대해 감지할 수 없다 -> 무효화 기능을 통해 수정된 파일이 캐시에 바로 반영되게 설정 가능

추가 비용 필요
프로젝트가 처음에 수정이 많을 경우 TTl 짧게, 안정화 되면 TTL을 늘려 캐싱을 길게 한다

10.3 캐시 동작

주어진 URL 경로에 대해 다른 설정 구성
기본 캐시 동작은 마지막에 항상 처리되며 정적 배포와 동적 배포를 분리하여 캐시 적중률을 극대화 가능
-> 정적 콘텐츠는 헤더, 세션 캐싱 규칙 없애고 - S3
-> 동적 콘텐츠는 올바른 헤더 및 쿠키 기반으로 캐시 - HTTP

10.4 Cloud Front ALB or EC2

유저 요청은 크게 2가지 방법으로 요청된다 (ALB 사용 여부)

user <-> Edge Location <- Allow public IP or Edge Locations -> EC2(public)
user <-> EDge Location <- Allow public IP or Edge Locations -> ALB <- Allow SecurityGroup of Load Balancer -> EC2(Private)

10.5 Cloud Front - Real Time Logs

실시간 로그를 활성화 한 경우 CloudFront가 수신한 모든 요청은 Kinesis 데이터 스트림에 실시간으로 전송 가능

Kinesis Data Firehose 사용해 레코드를 배치 처리해서 S3, OpenSearch등 원하는 대상으로 전송 가능
Kinesis 데이터 스트림에서 엑세스 할 필드나 캐시 동작 (경로 패턴) 지정 가능

10.6 Security

어떤 유료 공유 콘텐츠 액세스를 제공할 때 액세스 권한이 있는지 확인하려고 한다면

URL이나 Cookie에 서명하는 방법 사용

URL이나 쿠키를 생성하면 정책을 연결해서 URL이나 쿠키의 만료 시점을 지정
이 때 클라이언트 IP를 알면 활용
음악, 영화같은 콘텐츠는 몇 분 정도로 짧지만, 오래 액세스 할 콘텐츠라면 길게 유지

Signed URL

어플리케이션에서 CloudFront의 컨텐츠에 접근 할 수 있는 URL을 제공하여 컨텐츠 제공을 제어하는 방법이다.

URL에는 시작시간, 종료시간, IP, 파일명, URL의 유효기간 등의 정보를 담을 수 있음
이 URL 접근 이외의 접근을 막고 허용된 유저에게만 URL을 전달하여 컨텐츠 제공을 제어 가능
단 하나의 파일 또는 컨텐츠에 대한 허용만 가능
S3 Signed URL과 비슷한 방식

Signed Cookie

Signed URL은 하나의 컨텐츠만 제공 제어를 한다고 하면, Signed Cookie는 다수의 컨텐츠의 제공방식을 제어하고 싶을 때 사용된다.

Signed URL과 마찬가지로 여러 제약사항 설정 가능
다수의 파일 및 스트리밍 접근 허용 가능
사용사례 : 정기 구독 프리미엄 유저만 볼 수 있는 강의 동영상 등

Origin Access Identity (OAI)

S3의 컨텐츠를 CloudFront를 사용해서만 볼 수 있도록 제한하는 방법이다.

즉, S3의 정적인 컨텐츠 URL로 바로 접근하는게 아니라 CDN을 통해서 접근하는 것이다.

왜냐하면 S3로 직접 접속을 하면 캐싱을 못해 속도 측면에서 마이너스가 될수 있고, 국가별 라우팅, 인증 등이 CloudFront에 구현 되어있다면 유저가 직접 S3로 접속하면 안되기 때문이다.

S3는 CloudFront와 잘 맞는다 → 정적인 컨텐츠를 호스팅 하기 때문
CloudFront만 권한을 가지고 S3에 접근하고 나머지 접근권한은 막음
-> CloudFront는 유저와 S3사이에서 중개하는 역할
S3 Bucket Policy로 CloudFront의 접근을 허용해야 사용 가능
Cloud Front를 사용해 데이터를 S3버킷에 전송하여 파일 업로드 하는 것을 인그레스라고 한다.

Field Level Encryption

민감한 정보 보호 시,사용자와 가까운 엣지에서 암호화 (CloudFront부터 Origin 사이 통신 암호화)
클라우드 프론트로 보내는 POST요청의 경우 암호화를 원하는 필드를 최대 10개까지 지정 가능
Edge Location에서 공용키를 사용해 원하는 필드들을 암호화 하고 Web Server에서 비밀키를 활용해 해독

Tip!!

암호화 하려는 POST필드 세트 지정(최대 10개 필드)
공개 키를 지정하여 암호화

CloudFront와 S3, EC2간의 지역 단위 재해에 대한 복구가 가능한 아키텍처 구현 가능

10.6 Cloud Front Tip!!

특정 지역의 컨텐츠 접근을 제한 가능
비용 절감을 위해 엣지 위치 수를 줄일 수 있다.

11. ECS, ECR, Rargate - AWS Docker

ECS(Elastic Container Service) : 도커 관리를 위한 아마존 전용 플랫폼
EKS(Elastic Kubernetes Service) : 쿠버네티스 관리를 위한 아마존 전용 플랫폼
Fargate : 아마존 자체 컨테이너 플랫폼
ECR : 컨테이너 이미지 저장

11.1 ECS

ECS의 유형으론 크게 2가지가 있다.

첫번째론 EC2 Launch Type

ECS클러스터는 여러 요소로 이루어지는데 EC2를 시작 유형으로 사용할 땐 EC2인스턴스가 그 요소에 해당
EC2활용 시 인프라를 직접 프로비저닝 및 관리

두번쨰는 EC2 Fargate Launch Type

이 유형의 경우는 관리할 EC2 인스턴스가 없다. (서버리스)

Fargate 유형에서 ECS 클러스터를 사용하는 경우 ECS 태스크만 정의하고 나면 AWS에서 CPU와 RAM 요구사항을 토대로 ECS 태스크를 실행한다.

확장하려면 태스크 수만 늘리면 된다.

Cloud Watch로 ECS CPU사용량 확인이 가능하다
보안 그룹은 ECS에 별로 중요하지 않음, 대부분 IAM 관련

11.1.1 ECS Tasks for IAM Role

ECS 클러스터를 EC2 기반으로 생성할 땐 정확한 IAM이 설정되지 않으면 인스턴스 개수가 0
-> 임의의 호스트 포트를 활성화해 동일한 유형의 여러 건테이너를 동일한 EC2컨테이너 인스턴스에서 시작할 수 있게 설정

위의 2가지 유형으로 작업을 살펴보면

1. launch type - EC2 Instance Profile (only EC2)

json형식으로 인스턴스의 프로파일을 생성하고 ec2에 붙여야 한다.

그럼 위 그림과 같은 동작을 수행한다

Profile을 사용해 ECS 서비스에 인스턴스 복원 API 호출
CloudWatch Logs에 컨테이너 로그를 전송하는 API 호출
ECR에서 도커 이미지를 가져오는 API 호출
시크릿 매니저 또는 SSM Parameter Store에서 민감한 데이터 참조하거나 S3에서 로드

2. EC2 Task Role

태스크 별로 다른 역할을 수행하게 지정하고 필요한 권한 부여

11.1.2 Load Balancer

ECS Cluster를 접근하기 전에 ALB를 사용해 EC2 type, Fargate type으로 로드밸런싱이 가능하다
(EC2 경우 모든 포트 오픈, Fargate경우 80, 443만 오픈 - task가 해당 포트들로 열림)

ALB는 대부분의 사용 사례에서 활용하고

Network Load Balancer는 높은 성능을 요구하거나 AWS Private link를 사용할 때만 권장한다.

11.1.3 ECS Data Volumn

EFS 파일 시스템을 ECS에 마운트 (S3는 파일 시스템으로 마운트 불가)

EFS는 네트워크 파일 시스템이기 때문에 EC2와 Fargate와 모두 호환 가능하고

ECS 태스크에 파일 시스템을 바로 마운트 가능

최상의 조합은 Fargate(serverless) + EFS(serverless)

11.1.4 ECS Rolling Update

AutoScaling을 활용해 사용량에 따라 스케일 조정이 가능
ECS Rolling UPdates 방식을 사용하는데 한 번에 얼마나 많은 태스크를 시작하고 중단하는지 제어 가능

11.1.5 ECS Solution Architecture

ECS 아키텍처 3가지 확인하고 넘어가자

Event Bridge
Event Bridge Schdule
SQS Queue

11.1.6 ECS Task Definitions

EC2 태스크를 생성하면 사용 가능한 메모리와 CPU, Port를 확인할 수 있어야 한다

이를 위해 태스크 배치 전략과 테스크 제한 기능이 존재

태스크 정의 확인 -> 테스크 배치 제한 확인 -> 전략에 적합한 인스턴스 식별
-> 인스턴스 선택

배치 선택

Binpack : 가장 많이 채워져 있는 cpu혹은 메모리에 배치 시도 -> 사용 인스턴스 수 최소화 가능
Random : 그냥 랜덤 배치
Spread(분산) : 태스크 분산 해 고가용성 극대화

배치 제한

distinctInstance : 태스크가 각각 다른 컨테이너 인스턴스에 배치
-> 동일 인스턴스 상 두개 태스크 배치 불가능
memberOf : 사용자 커스텀 제한 (클러스터 쿼리 언어 사용해 정의)

Tip!

생성 관련 - EC2 Profile, 실행 관련 - EC2 Task
다양한 AWS 서비스와 상호작용 할 때 작업 역할 생성하고 ECS 작업 정의에 연결

11.2 ECR

AWS 도커 이미지 저장 및 관리

비공개 / 공개 설정 가능

11.3 AWS Copliot

컨테이너화 된 프로덕션-레디 App을 빌드 및 릴리즈하고 동작시키는데 사용하는 명령줄 인터페이스 도구

ECS, VPC, ELB, ECR 등과 같은 복잡한 인프라를 준비해준다.
CodePipeline과 통합해 명령어 하나만으로 컨테이너 자동 배포 가능
App 문제 해결, 로그 확인, 건강 상태 검사도 수행 가능
CLI나 YAML 파일을 이용해 MSA 아키텍처 형성 -> Copilot CLI를 이용해 APP 컨테이너 화 배포

11.4 EKS

ECS랑 동일한 기능 제공

Volume설정 할 떄 Container Storage Interface, CSI 호환 드라이버 활용 해야함

EFS 사용 동일

12. AWS Elastic Beanstalk

AWS 클라우드에서 애플리케이션을 신속하게 배포하고 관리

Go, Java, .NET, Node.js, PHP, Python 및 Ruby, Docker

Elastic Beanstalk의 환경 이름은 자유롭게 지정 가능
zip으로 패키징
웹 어플리케이션이나 작업자 환경의 구축에 이용됨.

12.1 Option

한번에 모두 배포 : 가장 빠르지만 잠시동안 트래픽을 처리하는데 인스턴스 사용 불가 (추가비용x)
롤링 : 한번에 몇개 인스턴스 업데이트 후 정상이면 다음 인스턴스로 이동 (적은 추가비용)
추가 배치가 있는 롤링 : 롤링과 비슷하지만 새 인스턴스 가동하여 배치 (이전 app 계속 사용 가능)
불변 : 새 인스턴스 가동하고, 이 인스턴스에 버전 배포 / 모든 것이 정상일 때 인스턴스 교체 (높은 비용) / 빠르게 롤백 가능
청록색 : 새로운 환경 만들고 준비가 되면 전환 (새 환경 테스트 -> 롤백 or 적용 - URL 스왑)
트래픽 분할 : 카나리아 테스트, 소량의 트래픽을 새 배포로 보낸다.

tip!!

EC2 burst balance가 모두 소진되는 경우
=> 불변, 트래픽 분할 (전체 변경 한꺼번에 하는 경우)

12.2 Life Cycle

최대 1000개의 App 저장 가능
이전 버전 삭제 시간이나 공간 기반으로 라이프 사이클 설정 가능
삭제 원하지 않으면 S3 저장 옵션

12.3 EB Extension

Elastic Beanstack extension을 사용해 UI에서 설정한 모든 매개변수를 파일을 사용해 코드로 구성할 수 있다.
.ebextensions/ 라는 디렉토리가 반듯이 있어야 하고 YAML, JSON 형식
-> 확장자는 반드시 .config로 끝나야 한다

12.4 EB Cloning

환경을 동일하게 복제 가능하지만 변경 할 수 있는 옵션이 제한되어 있다.
테스트 버전 배포에 유용

12.5 EB Migration 수행

LoadBalancer 변경
-> 환경 복사하고 CNAME 교체나 Route53이용 해 DNS 업데이트
Decouple RDS

[AWS SAA-C03] AWS Elastic Beanstalk 정리

참고

Tip!!

EB는 CloudFormation을 사용하는데 CloudFormation은 Elastic Cache, DynamoDB S3 버킷 배포 가능

13. AWS CI/CD

13.1 Code Commit

vs Github

default로 git사용
KMS를 통해 암호화 된다.

인증

SSH Key로 접근
표준 로그인 방식
IAM로 접근

tip!

AWS SNS / Lambda를 통합 설정을 하면 커밋마다 코드 분석을 자동으로 트리거 해

개발자가 비밀 자격 증명을 커밋하지 못하도록 한다.

13.2 Code Pipeline

Visual workflow 도구

CodeCommit(Source) -> AWS Code Build(build) -> AWS Code Deploy(Deploy)

작동이나 단계 실행 상태 변화 등 확인하기 위해선 CloudWatch Events 이용
-> 실패한 파이프라인 혹은 취소된 단계에 대한 이벤트 생성 및 메일 알림 가능
특정 작업 실행이 안되면 IAM 권한 확인
인프라에서 살펴봐야 하는 경우 AWS API 감시 서비스인 Cloud Trail 사용

webhook : 이방법 사용하면 HTTP 엔드 포인트 노출되고 해당 엔드포인트는 종류와 상관 없이 스크립트 트리거 가능
Polling : github을 주기적으로 확인
Events : 이벤트 트리거 (CodeCommit - EventBridge, Github - CodeStar Source Connection)

pipeline에서 수동 승인작업을 추가할 수 있는데 2개 권한 필요!!
-> GetPipeLine, PutApprovalResult

13.3 Code Build

AWS가 제공하는 Build Tool, 지정된 위치에서 소스코드를 가져와 Build & Test 수행

빌드 명령 파일 buildspec.yml - root에 위치해야 함

Cloud Watch Metrics는 빌드 통계 확인에 쓰임
Cloud Watch Events는 실패한 빌드 찾아 알려줌
Cloud Watch Alarams는 오류가 너무 많을 때 쓰임

AWS CodeBuild는 NAT Gateway를 사용하여 Private Subnet에서 작동하는데

vpc내부에서 실행도 가능
(통합 테스트, 데이터 쿼리, 내부 로드 밸런서와의 통신 등)

CodeBuild 컨테이너는 실행이 끝나면 삭제된다. (실행 중에도 SSH 연결 불가)

13.4 Code Deploy

EC2 인스턴스와 온프레미스 서버로 배포하기 위해선 Code Deploy Agent를 실행해야한다
appspec.yml은 Code Deploy가 App을 배포할 때 사용
시험에 나오는 배포 할 때 문제 EC2 인스턴스나 서버 시간이 잘못되서 에러가 나기도 함

과정

개발자 S3, Github에 push
Code Deploy 실행
CodeDeploy Agent가 Code Deploy polling
Download code + appspec.yml

종류

In-place : 반 배포, 반 배포 / 한번에 한번 / 한번에
blue-green deployment : 전체 복사해서 배포 후 전환

Redeploy & Rollbacks

Rollback : 이전에 배포된 애플리케이션 리비전 재배포

2가지

자동 : 배포 실패 or Cloud Watch알람이 트리거 되서 배포에 실패했다고 알려주는 경우
수동

Rollback을 하면 CodeDeploy는 마지막으로 감지한 성공한 리비전을

새로 배포하는데 이전으로 돌아가지 않는다.

새로운 배포를 할 때 가장 나중에 성공한 배포 사용 (새로운 버전)

13.5 Code Star

CI/CD관련 모든 솔루션을 통합하는 솔루션

문제 트래킹 도구가 있고, 이 도구를 문제 추적에 사용하면 JIRA 또는 Github와 통합되어 사용하기 편리
Cloud9을 사용하면 코딩을 통합할 수 있다.
통합 view는 아님

13.6 Code Artifact

종속성 관리 도구

Maven, Gradle, npm, Yarn, pip, Nuget 등과 통합되어 있음
Public Artifact Repositores에 직접 붙지 않고, Proxy처리 되어 붙는다는 의미
자체 Artifact도 가져올 수 있다.
Code Artifact는 변경사항이 있을 때 이벤트를 EventBridge로 전송 가능
Code Artifact를 액세스 하도록 권한을 부여하려면 리소스 정책을 사용해야 하는데 이 때 리포지토리 액세스 권한을 모든 패키지 권한 부여하거나, 아무 권한도 부여하지 않아야 한다.
외부 연결 된 저장소는 하나이고, 업스트림 형태, 최대 10개의 업스트림 레포지토리 가질 수 있다.

13.7 Code Curu

자동화된 코드 검토 및 App 성능 권장 사항을 위한 ML 기반 서비스

2가지 기능 제공

CodeGuru 검토자 : 정적 코드 분석을 위한 자동화 된 코드 검토
CodeGuru 프로파일러 : 런타임 동안 App 성능에 대한 가시성/권장 사항

13.8 AWS Cloud 9

클라우드 기반 IDE

14. AWS CloudFormation

CloudFormation은 AWS의 인프라 구조를 JSON와 YMSL로 작성하여 프로비저닝하기 위해 공통 언어를 제공하는 서비스 (코드형 인프라)
ex) Auto Scaling Group, Load Balancer, DB 등

생성한 모든 스택에는 식별자가 있어 손쉽게 스택 비용 추적 가능
CloudFormation 템플릿으로 리소스 비용을 추산 가능
Application 스택은 Beanstalk로 확인했는데 Beanstalk에서 CloudFormation 템플릿을 생성해 사용한 것
AWS리소스 전부 리소스가 될 수 있다. (EC2, LoadBalancer 등)
CloudFormation에서 내보낸 출력 값은 단일 지역내에서 고유한 이름을 가져야 함

배포 방법

수동 : 템플릿 수정, CloudFormation designer, console에 매개변수 입력)
자동 : YAML 파일에서 템플릿 수정 후 명령 줄 인터페이스

14.1 Template

템플릿으로부터 AWS 리소스를 자동 구축하기 위한 일련의 셋 사양
AWS 리소스를 항상 일정한 설정으로 프로비저닝
템플릿을 통해 테스트 환경 등의 환경을 만들기에 용이

Resources로는 EC2 등의 스택 리소스와 그 프로퍼티(속성)을 지정한다.
Parameters(매개변수)로는 실행시에 템플릿에 전달한 값을 지정한다.
Description 섹션에는 그 템플릿에 관련된 커맨트를 지정한다.

// JSON
{
  "AWSTemplateFormatVersion" : "version date",

  "Description" : "JSON string",

  "Metadata" : {
    template metadata
  },

  "Parameters" : {
    set of parameters
  },

  "Rules" : {
    set of rules
  },

  "Mappings" : {
    set of mappings
  },

  "Conditions" : {
    set of conditions
  },

  "Transform" : {
    set of transforms
  },

  "Resources" : {
    set of resources
  },

  "Outputs" : {
    set of outputs
  }
}

14.2 Outputs

CloudFormation 템플릿을 연결할 수 있다.
AWS 콘솔에서 출력을 볼 수도 있고, CLI를 사용해 출력값을 빠르게 검색도 가능
ex - 출력을 내보내기 해 resource에 대한 정보를 얻을 수 있고, 이를 다른 템플릿에서 재사용도 가능
(이전에 유지되던 상태로 )

14.3 Rollback

스택 생성에 실패하면, 스택을 업로드 하는데 모든 항목이 롤백 -> 모두 삭제
Rollback을 중지할 수 있음 -> 생성된 항목에 관해 좀 더 자세히 파악

14.4 Change Set, 중첩 스택, StackSet

ChangeSet

템플릿 내용 변경을 실시하는 구조
업데이트 성공 여부는 알 수 없지만 어떤 일이 생기는지는 확인 가능
change set을 사용하면 스택의 변경안이 실행중의 리소스에 미칠 가능성이 있는 영향을 확인 가능
(변경에 의해 중요한 리소스가 삭제되거나 변경되는 경우)

Cross stack

스택의 수명주기가 다른 경우 유용
내보내기 값을 여러 스택에 전달하는 경우

Stack Set

스택 셋을 이용하면 CloudFormation 템플릿 안에 있는 리소스 설정을 여러 리전이나 리소스에 적절히 사용 가능
한번 설정해두면 추가 어카운트나 리전에 대해서도 간단히 전개

Tip!!

실제 리소스와 CloudFormation 템플릿의 내용 사이에 괴리가 있는 것을 “드리프트”라고 부른다.
CloudFormation 스택 업데이트 중에 모든 리소스에서 모든 업데이트 작업이 허용
JSON 문서, 의도하지 않은 업데이트로 부터 리소스 보호
허용 할 리소스에 대해 명시적인 ALLOW 설정

15. AWS Mornitoring

15.1 AWS Cloud Watch

주요 구성 요소

메트릭 : 주요 메트릭 수집 및 추적
로그 : 로그 파일 수집, 모니터링, 분석 및 저장
이벤트 : AWS에서 특정 이벤트가 발생할 떄 알림 전송
알람 : 메트릭 / 이벤트에 실시간으로 반응

지표 수집

CloudWatch Agent를 EC2나 On-Premise에 설치하여 시스템 지표와 로그 파일을 수집 가능
(다양한 저장 장소 사용, Custom 가능)
Agent는 Windows와 Linux 지원
모니터링을 시작한 시점부터 최대 2주 동안 모든 Amazon EC2 인스턴스의 메트릭 데이터 사용
EC2 인스턴스 모니터링이 비활성화되고 2주가 경과하면 인스턴스의 메트릭 데이터를 사용 불가
2주가 경과한 후에도 메트릭 데이터를 보관하려면 명령줄에 mon-get-stats 명령을 호출한 후 결과를 Amazon S3 또는 Amazon SimpleDB에 저장
Metric은 기본 1분(1, 5, 10, 30초) 단위로 사용
푸시를 2주전으로 하던 2시간 앞으로 하던 오류 발생x -> aws시간과 ec2인스턴스 시간 잘 확인해야 함

특징

case 인스턴스가 예기치 않게 정기적으로 정지 : cloudwatch로 경보 설정 및 인스턴스 재부팅(임시방편)
클라우드워치 경보 작업으로 인스턴스를 자동 중지, 종료, 재부팅, 복구 경보 설정이 가능
인스턴스를 모니터링하고 자동으로 재부팅하는 경보설정 가능 (바로 되는데 굳이 Lambda 쓸 필요없음)
AWS 클라우드 리소스와 실행하는 어플리케이션 모니터링 경보를 사용하여 SNS를 통해 이메일 전송 가능
CloudWatch Synthetics은 API, URL, 웹사이트 등 모니터링 하는 구성 가능한 스크립트
- 고객이 영향 받기 전에 프로그래밍 방식으로 수행하는 작업 재현

15.2 EventBridge

EventBridge는 다양한 소스의 데이터와 애플리케이션을 연결하는데 사용할수있는 서버리스 이벤트버스 서비스

일정 : cron 작업
이벤트 패턴 : 서비스가 무언가를 할 떄 반응하는 이벤트 규칙
Lambda 함수 트리거, SQS/SNS 메세지 전송

특징

이벤트를 수신하고 이벤트를 대상으로 라우팅하는 규칙을 적용함
이벤트 브릿지로 람다를 호출할려면 정책추가 action에 Invokelambdafunction과 principal에 Events.amazonaws.com을 입력
리소스 기반 정책을 사용해 다른 aws 계정에서 이벤트 버스에 액세스 가능
이벤트 버스로 보낸 이벤트(전체/필터) 보관 가능 (무기한 또는 기간 설정)
보관된 이벤트 재생 가능

15.3 X-Ray

애플리케이션 성능 및 오류 문제 해결, 마이크로 서비스의 분산 추적, 실시간 오류 확인

API Gateway는 모든 API Gateway 엔드 포인트 타입(지역, 엣지 최적화, 프라이빗)의 AWS X-Ray 트레이스를 지원

15.3.1 Distro for Open Telemetry

어플리케이션에서 분산된 트레이스 및 지표 수집 방법

개별 앱에서 요청 -> 지표를 x-ray, cloudwatch 및 오픈텔레메트리에서 지원하는 모든 파트너 모니터링 솔루션으로 전송 가능

15.4 CloudTail

API 호출에 대한 내부 모니터링, 사용자의 AWS 리소스 변경 감사

로그를 Cloud Watch Logs 또는 S3에 저장 가능
이벤트는 90일 동안 저장

Cloud Watch vs X-Ray vs Cloud Tail

CloudTail : AWS API 호출 감사, 승인되지 않은 호출 또는 변경의 근번 원인 탐지에 유용

CloudWatch : 모니터링을 위한 시간 경과에 따른 지표, 로그 저장을 위한 CloudWatch Logs

X-ray : 자동 추적 분석 및 중앙 서비스 맵 시각화, 분산 시스템 오류 요청 추적

16. AWS Messaging

16.1 SQS

분산형 어플리케이션에 대해 사용되는 메세지큐 서비스로, 풀링 모델을 통해 메시지를 변환하고 컨포넌트의 송수신을 분리하기 위해 사용

FIFO 설정 해 순서대로 메시지 처리하도록 할 수 있다. (FIFO는 순서 보증 못함)
Push방식이 아니라 풀링 방식
병렬 처리 등의 분산 처리시 이용하는 것으로 이벤트에 연동한 메시지 통지는 SNS 이용
동적 처리 요구를 저장하고 비동기처리를 통해 확실한 처리 실행
EC2인스턴스에 분산 처리하는 것으로 복수의 워크 프로세스를 병렬 실행
메시지의 중복배제 ID를 이용하여 중복 메시지 발생을 사전에 방지
- 더 좋은 방법은 SQS 자체의 기능보다 Step Function을 작성해 메시지 중복을 예방
리소스의 수평방향의 스케일링에 도움 -> 부하 분산, 처리 프로세스 최적화
SNS로부터 메시지를 SQS에서 중단시켜 풀링 처리를 실시해도, EC2 인스턴스간에 처리 우선 순위는 변경x
SQS큐에 저장할 수 있는 메시지 수는 무제한
4일이 넘은 메시지는 자동 삭제
초당 최대 3000개 처리 가능
Auto Scaling 그룹으로 스케일링 가능
큐의 우선도에 따른 AutoScaling을 구성하는 메트릭스 설정은 존재x
메세지 손실이 없음, 알림을 보낼 수 없음
기존 sqs -> fifo sqs로 마이그레이션할때 기존꺼 삭제후 새로만들어야 함
가시성 떄문에 메시지가 2번 처리 할 떄 주의해야 함, 가시성 시간을 늘려 다른 인스턴스가 message를 더 오랫동안 가져가지못해 한번만 처리하게 가능 (완전한 솔루션은 아닌거 같긴함)
대기열 제한 시간 초과값은 초 단위이며, 기본값 30초
대기열 생성 후에는 유형 생성 후에는 변경 불가

16.2 SNS

분산 시스템 및 서버리스 어플리케이션을 분리할 수 있는(decoupling) 고사용성, 완전 관리형 pub/sub 메시지 서비스

Topic당 최대 구독자는 12,500,000명
Topic은 100,000개로 제한
이를 통해 MSA 분리 가능하게 한다
한번에 송수신 되는 대용량 메시지를 처리 불가능한 경우가 있고, 데이터 간 송수신 순서를 보장하지 못한다.
이벤트 트리거로 이용 가능

16.3 Kinesis

스트리밍 데이터를 리얼타임으로 분석

2가지 모델 존재

standard : 소비자가 pull data, 샤드 당 1초에 2MB
Enhaned-fan out : 소비자에 push, 2MB이상

특징

빅데이터에서 적극 활용
데이터 보존은 1 ~ 365일
처리량을 프로 비저닝해야함 (필요에 따라 샤드 추가, 제거)
Auto Scailing 불가

Kinesis Data Stream

일련의 데이터 레코드를 가진 샤드(Shard; 데이터 베이스 샤드는 데이터베이스나 웹 검색 엔진의 수평분할) 세트로 각 테이블 레코드에 Kinesis Data Stream을 통해 분할된 시퀀즈 번호가 있으므로, 메시지가 분실되지 않고, 중복되지 않게 도착 그리고 같은 순서대로 전송

Kinesis를 이용하면 데이터의 누락이 없으며 내구성이 있고 데이터 순으로 스트리밍
센서 데이터를 처리하기 위해 Amazon Kinesis이용 가능 (iot)
Amazon Kinesis Data Streams와 Lamabda를 연계시켜 데이터 처리를 서버리스 실현 가능
-> Amazon Kinesis Data Streams가 스트리밍 데이터 처리 -> Lambda함수가 데이터 변환처리 -> Amazon Kinesis Data Firehose가 S3에 데이터를 저장
데이터 분석과 키네시스 데이터 스트림은 모두 실시간 수집 및 분석을 위한것이다. 데이터 손실 가능

Kinesis Data Firehose

안정적으로 로드하는 방법, 데이터 처리량에 맞게 자동으로 스케일됨, 압축하여 보내서 스토리지 양을 최소화

거의 실시간으로 데이터를 처리, 또한 웨어하우스인 redshift로 데이터를 전송하여 데이터가 손실되지 않도록 함

동작 과정은

Kinesis Data Firehose를 이용해 S3에 로그를 축적 -> 변환처리(Lambda)
-> Athena를 이용하여 로그 분석 / s3 or Redshift 버킷에 저장 (ebs 로드 불가)

Kinesis Data Firehose 배달 스트림 설정 태그부터, AWS Lambda 함수를 선택

선택한 함수는 Kinesis Data Firehose에서 자동적으로 모든 입력 데이터 레코드에 적용

Amazon Athena

인터렉티브한 쿼리 서비스로, Amazon S3내의 데이터를 표준 SQL을 사용해서 간단히 분석

Amazon S3에 있는 데이터를 지정해서 스키마를 정의하고 표준적인 SQL을 사용하여 쿼리의 실행을 시작
대부분의 경우 몇 초 이내에 결과가 나온다.
case 분석이 완료되면 consumer에게 알림을 보낼 때 SNS사용하는 방법이 좋다
case 생산자 소비자간의 데이터 잔달 속도 지연 : 더 좋은 퍼포먼스는 팬아웃 사용

Reference

7. VPC
8. S3
9. AWS CLI, SDK, IAM 역할 및 정책
10. CloudFront
11. ECS, ECR, Rargate - AWS Docker
12. AWS Elastic Beanstalk
13. AWS CI/CD
14. AWS CloudFormation
15. AWS Mornitoring
16. AWS Messaging
Reference