Published 2022. 8. 3. 23:35

AWS Certificated Developer 공부

자격증

EBS

자체 암호화 가능

중지가 되어도 데이터를 유지하고 있다

한번에 하나의 인스턴트에만 마운트 할 수 있다.

네트워크 상의 usb의 역할

인스턴스와 ebs가 소통하기 위해선 네트워크 사용된다.

ebs는 특정 가용 영역에서만 사용할 수 있다.

하나의 ec2 인스턴스에 하나의 ebs가 있을 수도 있으며 하나의 ec2에 두개의 ebs도 가능 하다

ebs는 ec2와 연결되지 않고 독립적으로 on demand에 남겨 있어져도 된다.

az를 옮기고 싶다면 snapshot 을 사용하면 된다.

인스턴스가 중지되면 삭제할지 안삭제할지 선택 가능

aws ebs 지원 인스턴스 vs 인스턴스 스토어 지원 인스턴스 : ebs 지원 인스턴스를 중지하고 다시 시작할 수 있다.

성능에 영향을 주지 않고 데이터가 디스크에서 암호화 되도록 하는 방법 : 데이터 저장에 암호화된 EBS 볼륨을 사용하도록 Amazon EC2 인스턴스 집합을 구성합니다.

ebs snapshot

ebs volume을 백업

snapshot을 복사해서 새로운 az에 저장할 수 있다.

24~72시간 내에 새로운 저장소에 저장하면 된다.

휴지통에 들어갔다가 일정 기간 내에 백업이 가능하다. 그 기한이지나면 삭제

aws ami (amazon machine image)

ami EC2 인스턴스의 커스텀 software 구성 os 모니터링 가능 더 빠른 boot 구성시간이 가능하다.

ami는 구체적인 지역에서 만들어진다.

public ami, amazon linux2, launch ec2 instance ,aws marketplace

ami를 생성, 카피해서 새로운 az에 그대로 대입할 수 잇다.

ec2 instance store

인스턴스에 블록 수준의 임시 스토리지를 제공

가상 환경에서 이루어지지만 하드웨어 상에서 이루어지기 위해서 장기에는 ebs가 더 적합하긴 하다.

백업과 replication이 자신의 책임 필요하다 high performance가 필요할 때 고려

EBS VOLUME

gp2 : 비용 절감적이다. 더 오래됨 / io증가 disk size 를 상승시킨다.

gp3 (ssd) : 비용 절감적이다. 최신 ssd volume (boot volume으로 사용)

io1./io2 hisghest-performance ssd (boot volume으로 사용) 32000넘으면 필요 (io1 io 독립성을 증가시킨다.)

st1 : 저렴

sc1 : 가장저렴

ebs multi attach

하나의 ebs당 같은 az에 여러개의 ec2 사용

higher application avilability 필요, file system 필요하다

efs elastic file system

scalable expence highly avilable

동시에 하나의 네트워크 시스템으로 여러개의 가용 지역을 관리한다.

가용지역당 여러개의 ec2 인스턴스 있음

efs scale

1000개의 NFS( 컴퓨터 사용자가 원격지 컴퓨터에 있는 파일을 마치 자신의 컴퓨터에 있는 것처럼 검색하고, 마음대로 저장하거나 수정하도록 해주는 클라이언트/서버형 응용프로그램) 클라이언트

10 gb per second throughput

1. performance mode

잠복기에 민감한 경우 사용

max i/0 higher latench, throughput, highly parallel (빅데이터, 미디어 프로세싱)

2. throughput mode

bursting, provisioned

ebs 이전을 위해선

snapshot 필요, 다른 az에 저장

Scalability

어플리케이션 시스템이 적응하며 더 큰 부하를 처리할 수 있는 능력을 의미한다.

ertical scalability

자신의 인스턴스 크기를 늘린다. (성능이 더 뛰어난 것 사용한다는 의미)

RDS, ElastiCache 에서 사용한다

Horizontal scalability

인스턴스의 숫자를 늘린다. 분배된 시스템을 의미

웹이나 모던 어플리케이션에서 일반적,EC2에서 사용한다.

auto scaling group, 로드 밸런스

High Availability

horizontal scaling과 관계가 있다.

내 어플리케이션을 최소 2개 이상의 AZ(데이터센터)를 활용하여 운영하는 것을 의미

하나가 문제가 생겨도 다른 하나로 충분히 운영할 수 있음을 의미한다.

auto scaling group(multi az), 로드밸런스(multi az)

ELB

다운 스트림(서버에서 로컬 기기로 전송되는 데이터의 흐름)의 여러 서버로 트래픽을 전달하는 서버

세명의 유저가 세개의 인스턴스로 사용하면 사용자들은 어떤 인스턴스에 연결되어있는지는 모르고 그저 elb를 통해 연결이 되어있다는 것만 알 수 있다.

사용이유

여러개의 인스턴스를 사용하게 한다.

expose a single point of access(DNS) to my application

인스턴스 장애를 원활하게 처리

health check를 정기적으로 할 수 있다. (인스턴스가 요청에 응답할 수 있는지 여부를 알 수 잇도록 확인, 포트와 루트를 통해서)

원격 중지가 가능하다. 고가용성

쿠키 고정성 강요 가능

프라이빗 트래픽에서 공용 트래픽으로 분리 가능

비용이 적게 들고 사용이 어렵지 않다. 많은 aws 서비스와 연계가 가능하다.

ec2, acm, cloudwatch, route53

유저는 elb에 어디서든 접근 가능하다 하지만 loadbalancer 에서 ec2는 제한된 접근만 가능하다.

CLB

ALB

layer7, machine 간 로드밸런싱, 같은 machine의 복수의 어플리케이션 로드밸런싱 지원,http/2 웹소켓 지원

그룹라우팅, micro-balanceing, container-based application 에 적합하다 (ecs, docker에 적합함)

타겟 그룹 : ec2 인스턴스, lambda, ec2 tasks, ip 주소

NLB

layer4, tcp/udp 트래픽, 지연율이 적다, 하나의 az에 하나의 정적 ip를 가지고 있다.

not free tier (ip, ec2, alb target group 모두 가능)

세션 고정을 활성화하고 컨테이너에서 세션 데이터를 관리합니다.

Gateway load balancer

유저가 직접적으로 application에 접근하는 것이 아닌 gateway loadbalancer를거쳐 방화벽이나 방어 기제 같은 target group으로 트래픽을 먼저 전달하고 여기서 과정이 끝나면 application에 접근을 하는 구조이다.

Sticky sessions

같은 유저가 항상 같은 인스턴스로 할당되는 것이 가능하다. CLB ALB에서 가능

쿠키는 사용자가 제어하는 쿠키는 만료 날짜가 있다. 세션 데이터르르 잃고싶지 않을 때 사용한다.

1.커스텀 쿠키

target 에 의해 생성, 각 target group에 따라 쿠키 네임이 구체화된다.

2. application 쿠키

로드밸런서에 의해 생성

3. Duration-based 쿠키

로드밸런서에 의해 생성ㅇ

Cross-zone load balancing

2의 인스턴스가 있는 az와 8개의 인스턴스가 있는 az가 있다. 트래픽은 각 az로 50% 로 보내진다. 하지만 cross-zone load balancing을 통해 각 인스턴스에 10%씩 리다이렉트를 진행하여 트래픽을 조절하는 것을 의미한다.

ALB의 경우 cross-zone load balancing을 진행하며 az전환에 있어 비용을 따로 지불하지 않는다.

NLB의 경우 장애가 발생할 수 잇고 czlb를 하려면 비용이 청구된다.

CLB의 경우 czlb가 안되어 있는데 사용코자 하려면 비용이 청구되지 않는다.

SSL

SSL 인증서를 통해 클라이언트와 로드밸런스간 트래픽 전송 중 암호화가 된다.

ssl은 보안 소켓 계층을 참조, tls는 전송 계층 보안 참조, tls 를 ssl이라고 부른다

공용 ssl은 CA(인증기관)에서 발급한다

만료 날짜가 있어 갱신이 필요하다

SNI - Server name indication

다중 ssl 로드 문제를 해결한다 (하나의 웹서버에 대한 인증서, 각 웹사이트당 인증서가 하나씩)

alb & nlb에서만 사용 가능, CloudFront Clb는 사용 불가

Connection draining -clb

deregistration delay - ALB & NLB

deregistration이 이루어질 떄 인스턴스가 실행중인 요청을 완료할 수 있도록 시간이 주어진다

너의 인스턴스 요청을 완료학 멈추면 새로운 요청이 보내지지 않는다. default 5분 1시간까지 가능

Auto Scaling Group

자동으로 수요에 따라 ec2인스턴스를 늘리고 줄이고 해주는 것

asg는 무료다 ec2비용에 대해서만 지불하면 된다.

launch template

AMI+ Instance Type, EC2 User Data, EBS Volumes, securitygroups, ssh key pair, IAM roles for user, nework+subnet, load balancer information

CloudWatch Alarms

전체 ASG 인스턴스에 대해 평균 CPU와 같은 메트릭이 계산됩니다.

Dynamic Scaling Polics

간단하게 설정 가능 어느 수준에서 실행이 될지 설정, cpu수준, 요청 수준, 네트워크 경계(네트워크가 많이 소요되는 다운로드 업로드 상황)

Predictive Scaling

예측 가능

Scaling Cooldown

스케일링 후에는 5분간의 냉각 기간이 필요하다. 이때는 시작과 종료가 불가능

즉시 사용할 수 있는 AMI를 사용하여 더 빨리 냉각을 요청하는 것이 좋다.

EC2

Elastic Compute Cloud - Infrastructure as a Service

가상 컴퓨팅에서 가장 중요한 요소

aws api 를 안전하게 호출하도록 ec2 인스턴스를 구성

IAM 역할 생성.
역할을 수행할 수 있는 계정 또는 AWS 서비스를 정의합니다.
API 작업 및 리소스를 정의합니다.
인스턴스를 시작할 때 역할을 지정하거나, 기존 인스턴스에 역할을 연결합니다.
애플리케이션에서 임시 자격 증명 세트를 검색하여 사용하도록 합니다.

aws서비스에 대한 액세스 관리 : 인스턴스 프로파일 생성

퍼블릭 ipv4 주소 찾는 방법 http://169.254.169.254/latest/metadata/를 검색해 인스턴스 메타데이터를 가져온다.

CPU, RAM, 네트워크, 하드웨어 용량, public ip 주소, 보안 그룹, ec2 유저 데이터 설정(최초 1회)

ec2 user data

bootstraping 초기 단계의 단순한 요소부터 복잡한 체계를 구축하는 것, 첫 시작에 한번만 동작한다.

update,software 설치, 인터넷에서 파일 설치를 한다.

EC2 인스턴스 Metadata

IAM 규칙 사용없이 EC2 인스턴스 자신에 대해서 알아볼 수 있다. 퍼블릭 IP 프라이빗 IP 오직 EC2로만 접근이 가능

RDS

장점

자동 프로비저닝, 연속적 백업과 타임스탬프 저장, 대시보드 모니터링, multi az setup

단, ssh로 rds에 접근은 불가능하다,

rds backup

자동화 가능, full backup 가능

트랜잭션이 매 5분마다 백업이 가능하다, 어떠한 시점에서도 저장 가능

db napshot : 원하는 기간동안 보존 가능(6개월), 사용자가 사용하는 기능

auto scaling

자동으로 스토리지도 auto scaling 가능, 최소 5분 이상 저장가능

마지막 수정 후 6시간이 지남

read replicas

5개 까지 가능, 복제본이 있을 수 있지만, 읽을수만 있고 쓰는 것은 main에서만 가능하다.

다른 팀에서 db가 필요한 경우 읽기 전용으로만 사용토록 하는 것!

RDS Multi AZ

SYNC replication

AZ나 네트워크 스토리지에 문제가 생기는 경우를 대비해 예비용으로 복제를 해두는 것

스케일링이 되지는 않는다. read replica가 복구용으로 multi az로 만들어지기도 한다.

modify만 하기만 하면 복제가 된다. snapshot 이 생성된다. 동기화가 진행된다.

Encryption

0. 최초 한번. 데이터를 암호화 ssl인증서 옵션 제공

1. 암호화 되지 않은 RDS db snapshot 생성

2. 스냅샷을 암호화된 스냅샷으로 복사도 가능,

3. 응용 프로그램을 스냅샷으로부터 새 db를 생성 및 이전하고 이전 db를 삭제한다.

IAM-Security

네트워크 보안 : rds 프라이빗 서브넷 내에 구축된다.

보안 그룹으로 접근 제어

이름과 암호를 통해 db에 접근 or IAM기반 인증서로 mysql, postgre에 로그인 가능

로그인 방식이 아닌 인증 방법 : api call을 통해서 15분 짜리 인가토큰을 받는다. (ssl 사용)

사용자의 책임:
• DB의 SG에서 포트 / IP / Security Group 인바운드 규칙 확인
• 데이터베이스 내 사용자 생성 및 권한 또는 IAM을 통한 관리
• 공용 접근 권한 유무에 관계없이 데이터베이스 작성
• 매개 변수 그룹 또는 DB가 SSL 연결만 허용하도록 구성되었는지 확인

AWS 책임:
• SSH 액세스 없음
• 수동 DB 패치 적용 없음
• 수동 OS 패치 적용 없음
• 기본 인스턴스를 감사할 수 있는 방법이 없습니다.

Aurora

mysql과 호환이 된다. 10gb ~ 128tb 까지 가능

6개의 데이터 카피 3az 사용 가능, 자가복구 가능

aurora cluster

writer endpoint ( master를 가리킨다)reader endpoint( 로드 밸런싱 연결)

ElastiCache : 세션 저장

내결함성(시스템의 일부 구성요소가 작동하지 않아도 계속 작동할 수 있는 기능), 확장성, 서비스 중단의 영향x

클라우드에서 분산된 메모리 데이터 스토어 또는 캐시 환경을 손쉽게 설정, 관리 및 확장할 수 있는 웹 서비스

캐시는 높은 성능과 낮은 성능을 가진 메모리 내 데이터베이스, 데이터베이스의 로드를 줄인다.

Redis, Memcached에서 사용된다.

이를 사용하며 어플리케이션 코드가 크게 변경된다.

어플리케이션에서 EC를 쿼리한다. (cache hit)

어플리케이션에서 EC를 쿼리할 수 없는 경우(Cache miss) RDS 에서 가져오기도 한다. ( 시간이 더욱 소요)

읽기만 할때보다 쓰기를 수반하는 경우 2가지 요청 (EC, RDS요청)이 이루어지고 쓰기가 더 오래걸림

RDS 의 부하 완화, 최신 데이터만 사용하도록 무효화 전략이 있어야 한다.

로그인을 하는 경우 세션을 EC에 저장 -> 세션을 반환하면 다시는 로그인 과정이 필요하지 않다. 인증이 끝나서

Redis

multi az, read replica(고가용성) 백업,복원 가능

수직 확장. Redis 클러스터를 온디맨드 방식으로 확장하거나 축소할 수 있습니다. Amazon ElastiCache는 노드 유형을 변경하여 클러스터의 크기를 조정하는데, 이때 클러스터는 계속 온라인 상태를 유지하고 수신되는 요청을 처리합니다.

Memcached

데이터 파티셔닝을 위한 다중 노드

고가용성 없음, 백업복원 없음, 멀티 스레드 아키텍쳐(샤딩)

점검사항

캐싱이 데이터에 효과적인지, 캐싱에 적합한 디자인 패턴인지, 어떤 캐싱 설계 패턴이 가장 적합한지

Lazy caching, lazy loading

lazy population or cache-aside 캐싱 제외 캐싱 전략, 즉 lazy caching을 의미한다.

RDS에서 내가 찾고자 하는 데이터가 없을 때 시간이 오래걸린다. 기본 아이디어는 객체가 애플리케이션에 의해 실제로 요청될 때만 캐시를 채우는 것이다

Cache 삭제

의도적 / 메모리 다 차면 / 시간 (TTL)

ElastiCache 복사

Cluster Mode Disabled : 기본 노드에서 5개까지 복제 가능 복제본은 읽기만 가능, 모든 노드들은 공유 multi-az가능

Cluster Mode Enabled : 데이터들이 나누어진다. 5개노드까지, multii-az 가능

AWS Route53

CNAME

호스트 이름을 다른 호스트 이름으로 변경하는 것

루트 도메인이 아닌 것에 대해서만 적용이 가능하다.

Alias

호스트 이름을 AWS리소스 이름으로 변경하는 것

루트도메인과 루트도메인 아닌 것에 모두 작용한다. 무료, 헬스체크 기능

A/AAAA 타입에 적용 가능 (IPv4 IPv6)

EC2 DNS 에는 설정할 수 없다.

Routing Policies

Route53이 DNS 쿼리에 어떻게 응답하는 지 정의한다.

Simple

여러개의 값이 반환되는 경우에는 클라이언트에 의해 랜덤으로 ip주소를 받는다.

헬스 체크가 필요 없다.

Weighted

가중치에 따라 트래픽이 분배되고 비중을 퍼센트로 계산한다.

DNS record는 같은 이름과 유형이어야 하고, 헬스 체크를 연관 지어야 한다.

지역간 로드밸런싱, 새로운 어플리케이션 버전 테스트에서 사용된다.

트래픽 송신을 중단하려면 레코드에 가중치 0 을 할당하면 된다.

동등한 트래픽 송신은 모두 가중치 0을 부여하면 된다.

Latency-based

최소 지연율의 리소스로 리다이렉트 한다.

유저와 AWS 지역의 트래픽에 의해 정해진다.

헬스 체크와 연계

Failover(시스템 대체작동)

헬스체크를 통해서 문제를 인지하면 복구할 수 있도록 장애 복구용 EC2 인스턴스를 사용

Geolocation

Latency와 다르다. 특정 지역을 설정하지 않은 다른 지역에 있는 사람들에게 Default IP로 리다이렉트 시킨다.

그래서 Default 레코드를 생성해야만 한다.

Geoproximity Routing Policy

정의된 bias를 기반으로 더 많은 트래픽을 전환할 수 있는 능력

미 서부와 동부를 나누었을 때 보통은 서쪽에 가까운지역은 서쪽의 리전을 사용하게 되어있다.

하지만 편향이 주어지면, 주어진 쪽으로 더 많은 이용자가 해당 리전을 사용한다.

Traffic flow

복잡한 트래픽 프로세스를 그림처럼 단순화하여 보여준다.

Multi-Value

트래픽을 다양한 리소스로 라우팅할 때 사용한다.

multi-value는 ELB를 대신할 수는 없다.

Health Checks

public 리소스에서만 사용된다.

요청을 보내면 잘 응답이 오는지 확인, 30초 간격, http,https, tcp에서 사용

18%이상이면 건강하다.

Calculated Health Checks

여러 개의 헬스 체크를 결합한 결과를 내놓을 때 사용

OR, AND, NOT사용 가능 256개까지 관리 가능 어람나 통과해야 하는지 확인할 때

Private Hosted Zone

VPC(Virtual Private Cloud) 밖에 있어private endpoint에 접근할 수 없다.

cloud watch metric나 alarm을 생성할 수 있다.

VPC

(Virtual Private Cloud) 나의 리소스를 나타내는 프라이빗 네트워크다

subnet : 너의 vpc의 네트워크를 분할할 수 있도록 한다. (az와 연결되어 있음)

public subnet은 인터넷으로부터 접근할 수 있는 영역이다.

internet gateway : 인터넷 게이트웨이는 VPC가 인터넷과 연결될 수 있도록 돕는다. public subnet이 인터넷 게이트웨이와 연결되는 경로를 가지고 있다.

NAT gateway : public 서브넷에 위치하여 private subnet 이 인터넷 게이트웨이트에 접근할 수 있도록 해주는 게이트웨이이다.

NACL vs Securitygroups

network ACL (NACL) : 서브넷에서 주고받는 트래픽을 통제하는 방화벽, 허용과 금지 규칙이 가능하다(ip주소만), stateless

security groups : eni나 ec2 인스턴스에 대한 트래픽을 통제하는 방화벽이다. 허용 규칙만 가능, ip주소와 보안 그룹에 대한 규칙을 포함할 수 있다. stateful

VPC,Subnet,Internet Flow Logs : ip트래픽에 대한 정보를 확보할 수 있다. 관리, 트러블 슈팅을 도울 수 있다.

VPC Peering : 프라이빗하게 사용하는 두개의의 vpc를 연결한다. 단, IP 주소 범위(CIDR)가 오버랩 되어서는 안된다. 네트워크가 어디로 가야할 지 모르게 되기 때문. 세개면 두개씩 서로 연결

vpc Endpoint : aws 서비스에 private 네트워크로 접근할 수 있도록 해준다. 강화된 보안, 적은 지연율

Site to site VPN : 온프레미스 데이터 센터 와 VPC의 연결, 자동 암호화 (public환경을 통해서)

Direct connect (DX) : 온프레미스와 aws와의 물리적인 연결, 빠르다, 구축에 한달정도 걸린다. (private 환경으로)두 방법들은 모두 VPC Endpoint에는 접근할 수 없다. 온프레미스와 연결되어있으면 사용 불가능

Amazon VPC에 연결된 Lambda 함수에 인터넷 액세스 권한을 부여하려면

VPC에 하나의 퍼블릭 서브넷과 하나 이상의 프라이빗 서브넷을 생성

인터넷 게이트웨이를 생성하여 Amazon VPC에 연결

NAT 게이트웨이 생성

퍼블릭 서브넷과 프라이빗 서브넷용 사용자 지정 라우팅 테이블 두 개를 만듭니다.

ACL(엑세스 제어목록)이 Lambda 함수의 아웃바운드 요청과 필요에 따라 인바운드 트래픽을 허용하는지 확인합니다.

VPC에 연결하도록 람다 Lambda 함수 구성

VPC에 대한 Lambda 실행 역할 생성

S3

정적 컨텐츠를 저장한다.

성능 최적화 : Amazon S3에서 20개 이상의 접두사를 생성합니다. 접두사로 파일을 배치합니다. 접두사로 병렬로 읽습니다.

버킷은 글로벌 적으로 특별한 이름이어야 한다. 지역에 국한되지 않음

obejcts - 키를 가진다(파일 경로+파일이름)

5gb 이상 업로드 시에는 multi-part upload를 사용해야 한다.

암호화

X-AMX-SERVER-SIDE-ENCRYPTION 헤더가 포함되어야한다.

sse-s3

aws가 데이터키와 마스터 키 모두 관리

s3에 의해 관리되는 키, kineses 도 가능!

http/s+header를 통해 객체를 s3 업로드 + s3 데이터 키로 버킷에 접근한다..

sse-kms

aws 는 데이터 키 사용자는 마스터 키 관리

kms에 의해 관리되는 키, 유저의 통제가 가능하다 비용이 발생, 감사추적기능 존재

http/s+header를 통해 객체를 s3 업로드 + kms 키로로 버킷에 접근한다..

자체 마스터 키 존재

sse-c

데이터와 마스터 키 모두 관리

https가 필수적이다.

객체와 클라이언트가 가진 데이터 키와 함께 https에 실린다. 그리고 s3에 업로드 되어 버킷에 접근한다.

사용자는 암호화 키를 관리하고 s3는 암호화 및 해독 관리

클라이언트측 암호화

사용자가 전적으로 관리하는 키

s3에 전송하기 전에 데이터를 암호화한다. 데이터 업로드 직전에 데이터 키를 생성

객체를 s3암호화 sdk와 클라이언트 데이터 키로 객체를 암호화한다. 그리고 http/s를 통해 s3 버킷에 접근한다.

S3 Security

유저기반

IAM 정책 : 어떤 API 요청이 허가되는지 유저에 따라서 판단

Resource 기반

버킷 정책 : 계정 전반에 걸쳐 버킷 룰을 적용할 수 있다.json 기반

ACL (access control list) 객채 혹은 버킷

IAM정책은 s3 객체에 접근할 수 있다. (유저 IAM정책이 허락하거나 리소스 정책이 허락하는 경우에)

퍼블릭 액세스를 차단하는 설정 방법

ACL, 공용 버킷 및 객체에 대한 교차 계정 접근 차단. 기업의 데이터 유출을 막기 위해 사용되었다.

네트워킹 VPC, 로깅 Cloudtrail, 유저 보안 : MFA, 제한시간이 있는 URL

s3 CORS

Cross-origign resource Sharing

주 origin(프로토콜, 호스트, 포트)을 방문하는 동안 다른 origin에 대한 요청을 허용하는 웹 브라우저 기반 메커니즘이다.

클라이언트가 S3 버켓에 cross-origin 요청을 하면, 올바른 CORS header를 활성화해야 한다.

s3 MFA 삭제

삭제를 위해선 S3 bucket에서 버전 관리를 사용하도록 설정한다. 영구삭제, 버전 관리를 멈추기 위해선 mfa가 필요하다

현재는 CLI에서만 삭제가 가능하다.

s3 암호화 / 버킷 정책

advanced encryption standard사용

버킷 정책을 사용하면 암호화를 강제할 수 있고 어떤 API요청도 거절할 수 있다.

아니면 s3 암호화 사용

S3 접근 로그

주의 : 로깅 버킷이 모니터링되는 버킷(app bucket)이 되지 않도록 해야한다 (자기 자신을 계속 로그함)

로깅 루프를 생성해 버킷의 사이즈가 무한히 커진다.

S3 복제

반드시 버전 관리를 하게 한다.

CRR(Cross region replication) : 더 낮은 지연 접근, 계정간 복제

SRR(Same region replication) : 기록 집합, 생성과 테스트 계정 사이의 복제

대부분 새로 생성되는 객체만 복제를 한다.

다만, s3 batch replication을 통해 이미 존재하는 객체들도 복제할 수 있다.

삭제 : 삭제 마커를 복제할 수 있다.

연쇄적인 복제는 없다. (1->3, 1->2)

pre-signed URLs (사전 서명)

sdk나 CLI로 실행 가능

(고정값) 1시간 동안 유효하다. url을 부여받으면 허가를 상속받는 것임

ex) 로그인한 유저만이 s3 버킷에서 프리미엄 비디오를 다운받는 것, 일시적으로 유저가 파일을 업로드 가능

durability(내구성)

99.9999999999%내구성이 있어 천만개의 객체를 저장하면 만년에 한번 소실이 발생할 것

availability(유용성)

Credentials

EC2인스턴스에 배포된 어플리케이션이 환경 변수를 사용한다.

IAM 사용자가 아마존 s3를 호출할 수 있는 자격 크리덴셜을 제공한다. (iam 사용자에게는 s3접근 권한이 있다.)

자격 증명 체인은 여전히 환경 변수에 우선 순위를 부여하고 있습니다

AWS 자격 증명 공급자는 마지막으로 인스턴스 프로필 자격 증명을 찾습니다.

aws Credentials를 자신의 코드에저 저장하지 마라

Glacier Storage Classes

저비용 저장 객체

Instant retrieval : 밀리 초의 회수,최소 저장 기간 세달

Flexible retrieval : 무료, 최소 저장 기간 세달

deep archive : 오랜 저장, 최소저장기간 6달

티어 : frequent, infrequent(30일), archive instant(90, archive access(90~), deeparchieve(180일~)

Infrequent access

잘 접근하지 않지만 빠른 접근이 필요한 경우, 더 적은 비용으로 기능 사용가능

standard-infrequent access : 99.9% 가용성, 재앙 회복, 백업 기능

OneZone infrequent access : 99.99999999% 내구성, 하나의 az az가 문제 생기면 망가진다.

99.5% 가용성, 2차 백업, 재생성

Lifecycle Rules

transition actions : 객체가 다른 스토리지로 전환되는 시기

expiration actions : 오래된 버전 파일 삭제

Baseline Performance

s3는 자동적으로 요청율을 조정한다.

sse-kms 제한이 있는데, kms api를통해 키를 생성하고 해독하는 api가 필요 해서

Multi-part upload : 100MB 이상의 파일 추천, 5GB이상은 필수 평행하게 업로드 가능

Transfer acceleration : 전송속도를 향상시킨다 : edge-location을 활용해 public환경을 private 환경으로 전환해 전송

byte-range-fetches

오직 부분적인 데이터만 회복할 때, 다운로드 속도를 증가시킬 때 (헤더만 요청, 동시에 부분적 다운로드 등)

s3 select & glacier select

서버측은 SQL 필터링으로 으로 적은 데이터를 되찾음, cpu도 덜 사용하고, 네트워크 전송도 덜 활용

Event Notification

이미지 등록으로 썸네일을 발생 시, s3 맘대로 생성 가능

Athena

s3객체를 분석하기 위한 서버리스 쿼리 서비스 접근 권한이 없는 직원들에게 유용

s3 성능 최적화

병렬화를 사용하여

접두사 수에는 제한이 없음

Amazon S3로 캐싱하기 위해 Amazon CloudFront 또는 Amazon ElastiCache를 사용합니다. 클라이언트와 S3 버킷 간 장거리에 걸쳐 고속 데이터 전송을 원할 경우 Amazon S3 Transfer Acceleration을 사용

단일 put 업로드 제한 크기 5gb

IAM

Identity and Access Management

IAM은 루트 계정이 있고 루트 계정에서 USER 계정을 여러개 생성할 수 있습니다.

주로 프로젝트 팀장과 같이 책임자가 루트 계정을 사용하고 팀원들에게 USER 계정을 생성해 사용 권한을 부여

물론 USER 계정은 인당 1개!

USER는 그룹을 형성할 수 있는데, 그룹을 만드는 이유는 필요한 기능만 사용하도록 제한하기 위해서

USER는 하나의 그룹에 소속되어도 되고 여러개의 그룹에 소속되어도 되고 그룹에 소속되지 않아도 된다.

다만 그룹간에 소속 관계는 존재하지 않습니다.

iam : pass role : AWS 서비스에 역할을 전달하도록 하기위해 사용한다.

IAM 보안방법

1. password policy

비번 설정방법 : 일반적으로 설정하는 비밀번호 형식 (특수문자 대소문자 등을 넣어서)

USER 자신의 비밀번호를 변경할 수 있고 만료되면 비밀번호를 변경하거나 재사용할 수 있다.

2. MFA - multi factor authentication

IAM 규칙

IAM security tools

1. IAM credentials report ( account-level) IAM 자격 증명 보고서

계정의 모든 사용자와 해당 계정의 다양한 인증 정보 상태를 나열하는 보고서

감사 및 규정을 준수하는 데에 도움이 된다.

2. IAM access advisor (user-level)

액세스 관리자는 사용자에게 부여된 서비스 권한과 해당 서비스가 마지막으로 액세스된 시기를 표시합니다.

정책을 수정할 때 이 정보를 사용합니다.

유저가 aws에 접근하는 방법

AWS management console, cli,sdk

aws CLI

aws 서비스의 public api에 접근이 가능하다.

리소스 관리를 위해 스크립트를 develop할 수 있다.

aws management console을 사용하는 대안이 있다.

프로그래밍적으로 접근이 가능하다. (자바, 파이썬 , go , nodejs 등)

나의 application에 탑재가 가능하다. (안드로이드,ios, 아두이노 등)

CLI Dry Runs

우리에게 API 요청 허가가 있는지 확인하기 위해 사용하는 옵션

AWS SDK

요류 재시도 시에 사용한다.

Exponential Backoff

LimitExceed 오류 시, ProvisionedThroughputExceededException(특정 해시 키에 대한 용량을 초과)오류시

에러가 발생하면 재시도해보는 메커니즘

500 : 서버 오류를 위해 재시도만 구현해야 한다.

400번대 에러 : 클라이언트 문제이므로 구현 x

lambda 함수가 다른 aws 계정의 iam 역할을 수임하도록 구성하는 방법

Lambda 함수가 다른 AWS 계정의 IAM 역할을 수임하도록 함수의 실행 역할을 구성합니다.
Lambda 함수가 역할을 수임하도록 교차 계정 IAM 역할의 신뢰 정책을 수정합니다.
AWS Security Token Service(AWS STS) AssumeRole API 호출을 Lambda 함수의 코드에 추가합니다

CloudFront

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 신속하게 배포하는 웹 서비스입니다.

컨텐츠 전송 네트워크 (CDN)

읽기 능력을 향상하고 컨텐트는 마지막에 캐싱한다. ddos 방어, 쉴드 통합, aws 웹 어플리케이션 방화벽

s3 bucket

파일분산, 캐싱, 강화된 보안 (OAI origin access identity)

Custom Origin

ALB(무조건 퍼블릭 보안그룹은 private), EC2 사용(무조건 퍼블릭), S3웹사이트, Http 백엔드

Geo restriction : whitelilst, blacklist

cloudfront : 글로벌, 파일 캐시, 어디서든 이용 가능한 정적 내용

s3 region replication : 읽기만 가능, 몇몇 지역에 한해 동적 컨텐츠에 가능, 각 지역 당 설정

viewer protocol policy : http or https

origin protocol policy : https 만, s3 버킷 웹사이트는 https를 지원하지 않는다.

signed url : 개별 파일에 접근 가능

signed cookies : 여러개의 파일에 접근 가능

cloudfront signed url : origin에 상관없이 경로에 접근 허가, 루트 계정만 관리, 캐싱

s3 pre-signed url : iam 키 원리를 사용, 시간 제한

cached invalidation : 캐시 무효화

Caching

캐싱은 엣지 로케이션에 있음, 동적과 정적 컨텐츠를 분리하면 향상

AWS ECR(Elastic Container Registry)

private or public repository 존재, 컨테이너 이미지 저장

IAM에 의해 접근이 관리된다.

AWS EKS(쿠버네티스)

EC2 지원

파일 무효화 : 엣지 캐시에서 파일을 무효화합니다. 파일 버전 관리를 사용하여 서로 다른 이름을 가진 여러 버전의 파일을 제공합니다.

AWS ECS(Elastic Container Service)

아마존의 컨테이너 플랫폼

도커를 실행하면 인프라 구조를 공급하고 유지해야 한다.(ec2 인스턴스)

ecs 는 ecs 에이저트를 실행해야 한다.

AWS Fargate

Fargate Launch Type

서버리스 컨테이너 플랫폼 (ecs,eks로 운영)

ec2를 공급하지는 않음

IAM 역할

ec2 인스턴스를 대신해 iam 역할을 ecs에 할당해 인프라를 보호한다.

이러면 s3에서 접근하는데 특정 iam역할을 하는 작업과 dynamodb 테이블에 접근하는 iam 역할을 사용하는 작업이 하나씩 있을 수 있다.

작업 정의를 한다.

컨테이너 로그를 cloudwatch 로그에 보낸다.

ecr로부터 도커 이미지를 끌어온다.

ecs task role

각 task는 구체적으로 각각 role을 부여받는다.

Load Balancer Integrations

ALB : 대부분 상황에 사용

NLB : 오직 높은 고성능 작업에 사용된다.혹은 Private link와 연결

ELB는 잘 사용 X

Data Volumes(EFS)

fargate + efs = serverless

s3는 파일 시스템에 마운트될 수 없다.

EC2 Service Auto Scaling(테스크레벨) (!= EC2 Auto Scaling 인스턴스 레벨)

cpu, RAM, ALB

Rolling Update

버전 업그레이드시 테스크 수량 처리, 순서 min max 정할 수 있음

SQS Queue

메시지를 뽑아서 처리

Task Definitions

다른 컨테이너와 데이터 공유시 : 작업 정의는 하나만 있으면 된다. 정의에서 두 컨테이너를 모두 지정하십시오. 두 컨테이너 간에 공유 볼륨을 탑재합니다.

json , 이미지이름, 환경변수, 네트워크, IAM Role

Load Balancing

ec2 보안그룹은 ALB 보안 그룹으로부터 오는 어떠한 포트도 허용해야만한다.

load balancing fargate : 각 작업은고유의 private ip를 가져야한다. 컨테이너 포트만을 지정,

Data Volume

하나의 테스크에 하나의 규칙만 적용, 하나의 테스크의 여러개의 컨테이너(사이드 카) 적용도 가능

Task Placement

ec2 가 실행되면 어디에 할당해야 할 지 결정해야 한다. 서비스 스케일을 줄여야할 경우에도 어떤걸 줄일지 결정해야하는데 이를 도와주기 위한 기능

- binpack : 컨테이너를 묶어 최소한의 cpu와 메모리를 사용하게 해 비용절감

-random : 랜덤

- spread : 전체적으로 퍼지게 배분

이들을 섞어서 사용할 수도 있음

구분 가능한 인스턴스여야한다.

AWS Elastic Beanstalk

aws 에 어플리케이션을 배포하는 개발자 중심의 뷰

autoscaling 모드, elastic loadbalancer, rds 배포 가능

apache tomcat, .net지원

조건

무조건 zip파일, CLI, management 콘솔에서 패키징된 어플리케이션을 업로드해서 배표 (업데이트 시)
단일 ZIP 파일 또는 WAR 파일로 구성됩니다. WAR 파일 내에 여러 ZIP 파일을 포함할 수 있습니다.
512MB를 초과해서는 안 됩니다.
상위 폴더 또는 최상위 디렉터리를 포함해서는 안 됩니다(하위 디렉터리는 상관 없음).

Deployment Mode

업데이트

all at once - 가장 빠름, 잠시동안 인스턴스 사용 불가, 부가 비용 안듦, 배포가 수행되는 동안 환경에 있는 모든 인스턴스가 잠시 서비스 중지됩니다. 다운타임 없음

rolling - 한번에 몇개의 인스턴스를(버킷=묶음) 업데이트 후 첫 번째 버킷이 정상이면 다음으로 이동 , 부가 비용없음, 오래걸림 각 배치는 배포 단계 동안 서비스에서 제외되므로 배치에 있는 인스턴스의 수만큼 환경의 용량이 감소합니다.기존 인스턴스 사용 / 애플리케이션 액세스 로그를 보관

rolling with additional batches : 롤링 원리, 배치를 위해 새로운 인스턴스를 스핀업, 이전 어플리케이션을 계속 사용, 오래걸림 (ex 원래 네개가 있었다면 두개를 새로 생성에 기존 네개를 업데이트 이전 업데이트 끝나면 새로 생성했던거 종료)

배포 프로세스 중에 모든 용량이 유지되도록 합니다. 비용 최소화

immutable (불변): 임시로 새롭게 한개를 만들어봄, 괜찮으면 나머지도 똑같이 만듦(4개라 가정하면 4개의새로운거 만드는거 ) 그리고 이들을 통합 비쌈, 가장 오래걸림 -> 롤백

elastic beanstalk환경에 새 버전을 배포하고 URL을 교체하는 것이 가장 빠르다.

루트 53을 통해서 가중치와 리다이렉트를 진행하기도 한다.

Traffic splitting

Canary Testing

새 어플리케이션 버전이 동일한 용량의 임시 asg에 배포된다.

배포상태가 모니터링되고 문제 발생시 피드백 빠르게

Lifecycle policy

1000개까지 버전을 저장할 수 있다. 예전 버전을 삭제해야 배포 가능

이전 버전을 쓰고싶으면 lifecycle policy를 사용해야 한다. 시간 기반(이전버전은 삭제된다), 공간 기반(너무 많은 버전을 가지면)

ebExtensions

코드를 담은 zip 파일이 배포되어야 할때 사용, 특정 명령 세트를 실행하도록 하려고 할 때 사용

Cloning

그대로 복사해서 테스트할 수 있음

Migration : Load Balancer

이전에 CLB를 쓰고 있고 ALB를 쓰고 싶으면 이 유형을 변경하는 것은 불가능하다. 새로 beanstalk를 생성해서 CNAME swap를 진행해야 한다.

Migration : RDS

rds db 의 스냅샷을 생성한다. rds 가 삭제되지 않도록 보호한다.

새로운 beanstalk를 생성 이전 버전의 rds와 연결한다. 그리고 CNAME swap를 진행해야 한다.(route53) 그리고 이전 버전은 삭제한다.

EB Docker

Beanstalk 이 있는 도커 컨테이너에서는 ECS를 사용하지 않는다.

Multi docker container : dockerrun.aws.json 이 필요하다 ecs 테스크 정의에 사용된다.

EB Custom Platform

매우 고급, 처음부터 새롭게 정의가 가능하다.

어플리케이션 언어가 beanstalk에서 호환되지 않고 도커를 사용하지 않는경우 사용한다.

vs Custom Image(ami) : 기존 beanstatlk 플랫폼에서 수정이 가능, custom platform에서는 전체적으로 새로운 플랫폼 생성가능

AWS CICD

Continuous Integeration(CI) 깃허브같이 코드를 레포지토리에 올리는,서버를 빌드 테스트 한다. 따라서 테스트 코드를 고칠 필요 없고 여기서 생기는 문제들을 고쳐내기만 하면 됨

Continuous Delivery(CD) 빌드가 패스된 이후에 통과된 모든 빌드는 배포 서버에 올라가게 된다. 어플리케이션 버전이 자연스레 업데이트 된다.

Code commit - > codebuild -> elastic beanstalk(codedeploy) : 이 전체 과정은 code pipeline에서 진행된다.

수동 승인 관리시 필요한 것 : 파이프라인에 승인 작업을 추가합니다. 승인이 필요할 때 Amazon SNS 주제에 게시하도록 승인 작업을 구성합니다. 파이프라인 실행이 중지되고 승인을 기다립니다.

CodeCommit

프라이빗 Git 리포지토리를 호스팅하는 안전하고 확장 가능한 소스 관리형 서비스

HTTPS 복제 URL를 제공하기 위해선 aws 자격증명 프로필을 사용하도록 git 자격 증명 도우미를 설정하고 도우미가 리포지토리로 경로를 보낼 수 있도록 한다. 이후 elastic beanstalk에 직접 배포한다. (최소한의 관리 노력, 업로드 시간 최소화 : 리포지토리에 커밋 시마다 시작)

여러 파일에 대한 일괄 변경 지원, 병렬 분기, 버전 추적

버전 통제가능, 다른 개발자와 협업 가능, 백업가능, 가시성

사적인 레포지토리, 규모 제한 없음, 고가용성,보안성 좋음(암호화), 다른 ci 도구와 연계 가능

security : 인증(ssh keys, https) 인가(IAM 정책, 암호화(KMS), 교차계정 접근)

CodePipeline

Source(codecommit,ecr.s3.github), Build, test, deploy 의 모든 과정, Cloud watch 사용 가능,

CodeBuild

source -> build 작업 -> 이후 출력 로그들이 cloudwatch나 s3에 저장될 수 있다. buildspec.yml을 작성해야한다.

env에서 환경 변수 작성,phases로 명령어를 구체화 한다, artifact로 무엇을 s3에 올릴지, cache : s3에 캐시하기 위한 파일들

로컬 빌드도 가능하다.VPC 구성

CodeDeploy

자동 배포하기 위한 기능 여러 배포 그룹을 생성합니다.

ec2 인스턴스나 온프레미스 서버는 무조건 codedeploy agent를 실행하고 있어야 한다.

1. s3나 깃허브에 코드와 appspec.yml(validateservice 중요)이 있어야 한다.

2. codedeploy로 trigger를 진행

3. poll (ec2인스턴스,온프레미스 서버)

내부 배포 : 응용 프로그램 중지 -> 설치 전 -> 설치 후 -> 응용 프로그램 시작

특정 배포 파일에 대한 파일 권한 변경 :AfterInstall

Deployment Configuration

once at a time(한번 실패하면 실패), half at a time(50% 반만 껐다 킴), all at once, custom (75%)

failure : 롤백을 위해선 이전 배포버전을 재배포해야한다.

green/blue : 그린새버전을 다 만들고 alb 연결을 파랑에서 초록으로 옮긴다.

Deployment to ASG

in - place Deployment : 기존 ec2인스턴스를 업데이트 , asg가 자동을오 배포한다.

blue/green : 새로 인스턴스를 만들면 v1 v2 모두 연결하고 괜찮으면 v1은 삭제

rollback : 자동,manually

롤백이 일어나면 가장 최근에 사용한 잘 되는 버전을 새 버전으로 사용한다.

Codestar

모든 그룹에 대한 통합 솔루션

CodeArtifact

artifact 관리 시스템 (보안, 의존성 관리)

CodeGuru

자동 코드 리뷰와 어플리케이션 수행능력 추천에 대한 머신러닝 서비스

reviewer : 버그나, 메모리 관련해서 피드백 주기 가능

profiier : 시각화, 어플리케이션 수행 능력에 대한 추천

CloudFormation

CloudFormation은 모든 리소스에 AWS Infrastructure의 개요를 설명하는 선언적 방법

필요한 기능이 있으면 순서대로 정확한 구성으로 만들어 준다.(생산성, 비용절감, 관리용이)

manual, auto(yaml사용)json 별로, 무조건 yaml

템플릿은 s3에 업로드 한다음 cloudformation에서 참조해야 한다.

업데이트를 하려면, 템플릿을 편집할 수 는 없다. 새 버전을 다시 업로드 해야한다.

스택은 이름으로 식별, 삭제하면 cloudformation에서 생성된 모든 아티팩트가 삭제된다.

배포콘솔을 활용해 매개변수 입력yaml파일 템플릿 편집, cli를 사용해 템플릿 배포

buillding block

리소스 : 템플릿에서 선언될 aws 리소스 선언(ec2, ip, 보안 그룹, load balancer)

파라미터 : 동적 인풋 cloudfront에 입력을 제공하는 방법

템플릿 재사용 case : nlb 재사용, 보안 그룹 재사용에는 nested stack이 사용된다. 일부 입력 결정 불가

매핑 : 정적 변수, ami 유형, 다양한 환경, 지역, 템플릿 내의 모든 값이 하드 코딩 된다. (findinmap)(mapping : stack)

아웃풋 : 생성된 항목에 대한 참조 (importvaule)

조건 : 리소스 생성을 수행할 조건 목록 (환경,,지역,매개변수,조건)메타데이터

람다 배포

템플릿에서 AWS::Lambda::Function 리소스를 생성한 다음 CloudFormation 템플릿 내부에 직접 코드를 작성합니다.

함수 코드가 포함된 .ZIP 파일을 Amazon S3에 업로드한 다음 템플릿의 AWS::Lambda::Function 리소스에 이 파일에 대한 참조를 추가합니다.

CloudWatch

원래는 ec2 머신에는 로그가 없다. cloudwatch 에이전트를 실행해서 사용한다. IAM 허가도 확실히 해둘 것, 온프레미스에서도

agent : 오래된 버전의 에이전트, 오직 log만을 보낸다.

unified agent ; 부가적인 시스템 레벨의 매트릭을 수집한다.

namespace

CloudWatch에 게시하는 각 데이터 포인트의 네임스페이스를 지정해야 합니다. 사용자는 지표(메트릭)를 생성할 때 네임스페이스 이름을 지정할 수 있습니다.

metric

‘지표’는 CloudWatch의 기본 개념입니다. 지표는 CloudWatch에 게시된 시간 순서별 데이터 요소 집합을 나타냅니다.

기간이 60초 미만으로 설정된 데이터 요소들은 3시간 동안 사용이 가능합니다.
기간이 60초(1분)로 설정된 데이터 요소들은 15일 동안 사용이 가능
기간이 300초(5분)로 설정된 데이터 요소들은 63일 동안 사용이 가능
기간이 3600초(1시간)로 설정된 데이터 요소들은 455일(15개월) 동안 사용이 가능

제 3자에 api 대해서 오류를 모니터링 받기 위해서는 사용자 지정 metric을 게시해야 한다.

metric filter

CloudWatch Logs는 필터가 생성된 후 발생하는 이벤트에 대한 지표 데이터만 게시합니다.

IntegrationLatency 측정치를 모니터링하여 백엔드의 응답 속도를 측정합니다. (시간초과여부확인)
Latency 측정치를 모니터링하여 API 호출의 전반적인 응답 속도를 측정합니다. (시간초과여부 확인)
CacheHitCount 및 CacheMissCount 측정치를 모니터링하여 캐시 용량을 최적화하고 원하는 성능을 달성합니다.(캐싱 여부 확인)

어플리케이션 지표 저장 : CloudWatch PutMetricData API 호출을 사용하여 CloudWatch에 사용자 지정 지표를 제출합니다. API 호출을 활성화하는 데 필요한 IAM 역할로 EC2 인스턴스를 시작합니다.

사용자 지정 메트릭 표시 : put-metric-data 명령 사용

alarms

어떤 매트릭에 대해서 안내를 하는 것, 중지, 종료, 회복, 재실행, 오토스케일링, sns

events

aws 서비스로부터 이벤트를 인터셉트한다.

json 형식

eventbridge

default event bus = events

partner event bus = saas service나 어플로부터 받는 이벤트

custom event buses = 내 어플

events와의 차이 : 내 서비스에 대한 확장된 이벤트가 가능하다.

X-Ray

애플리케이션이 처리하는 요청에 대한 데이터를 수집하는 서비스이며, 해당 데이터를 보고, 필터링하고, 통찰을 얻어 문제와 최적화 기회를 식별할 수 있는 도구를 제공합니다. (분산 어플리케이션, 성능 분석, 다른 구성 요소 호출)

추적 & 시각화 기능

lambda 기반 어플을 추적하기 위해선 IAM 실행 역할을 사용해 lambda 함수 권한을 부여하여 추적을 활성화한다.

응용 프로그램 서버에 x-ray 에이전트를 설치하여 x-ray를 시작한다.

x-ray 로 추적 이후 콘솔에서 분석 가능

x-ray Instrumentation

x-ray sdk를 통해서 제품의 퍼포먼스를 측정하는 것을 의미한다.

segment 문서 및 코드에 주석 추가(필터링 기능의 인덱싱)/오류 검사, subsegment, trace, sampling(여러 요청중 몇개만 뽑아), annotations(키 값 인덱싱), metadata(키 값 페어, 인덱싱 안된)

sampling 규칙 초당 하나의 요청 모음 + 5%의 어떤 부가적인 요청을 기록한다.

api : write(put) ,read(get)

x-ray & beanstalk : iam 허가 필요, sdk 활용, 도커에서는 불가

ecs + x-ray

amazon sqs

처리를 기다리는 메세지의 임시 저장소, 생산자와 소비자 사이의 버퍼 역할을 한다.

메세지 안보내지면 다시 보냄(한번 이상 보낸다) 30초 제한, 한번 보내지면 다른 소비자는 볼 수 없음

가시성 시간 초과를 사용하여 처리하는 동안 메시지를 잠급니다. 다른 소비자가 메시지를 처리하지 못하도록 합니다.

두 유형의 사용자가 있을 경우 두개의 대기열을 만들어 중요도가 높은 사용자 먼저 처리한다.

dead letter queue
메세지 처리를 실패하면 dead letter queue를 전송한다. 디버깅에 유용하다.
코드를 고쳐서 dlq 를 통해서 다시 보낼 수 있다.

delay queue
메시지는 대기열에 처음 추가될 때 구성 가능한 시간동안 숨겨진다.

메세지를 15분까지 지연시키는 것이다. 원래는 0초

long polling
대기열에서 메시지를 요청할 때, 대기열에서 메시지가 없을 경우, 선택적으로 메시지가 도착할 때까지 기다릴 수 있다.
api 요청을 줄인다. 효율성 지연율이 좋아진다. 비용 효율적

extended client
메시지 사이즈가 256kb 보다 더 큰 경우 사용한다.

crete,deletequeue,
purge : 모든 메세지 삭제
send,receive,deletemessage
maxnumberofmessagaes , 1~10 한번에 몇개 받을 지
receivemessagewaittimeseconds : long polling
changemessagevisibility: 메세지 타임아웃을 늘릴 수 있다.(다른 인스턴스가 이미 처리되었거나 현재 처리 중인 메시지를 검색할 수 없도록 할 때 사용)
send,delete,change 는 비용 절감 효과 동반

FIFO queue
선입선출, 초당 300개의 메세지 처리, 묶음이 없으면, 3000개 가능

deduplication
5분 간격
content-based : 메세지 암호화
message-grouping : messagegroupid 에서 같은 값을 지정하는 경우 대기열 id는 하나의 소비자만 가질 수 있고 순서대로 표시된다.

AWS SNS

비동기식

sns는 다양한 서비스를 통합한다. (시작 지점을 하나의 계정으로 중앙 집중화, 이벤트 시작마다 모든 함수를 호출)

SNS 주제에 대한 페이로드를 사용하여 SNS Publish API를 호출합니다.
암호화(https, kms), IAM 정책, sns polices(cross-account)
하나의 메세지를 다양한 수신자에게 보내는 경우

http, sms가능

sns-sqs : fan out pattern
sns로 전송, sqs로 받는 형식
완전한 분리로 데이터 소실이 없다.

유효한 인수

Topic Arn, Target Arn, Subject, Message, Message Structure, Message Attributes, Phone number

메세지 형식

MessageId, unsubscribeURL, Subject, Message 및 기타 값을 포함하는 JSON 객체

s3 events multiple queue
이벤트 타입(객체 생성) 하나당 하나의 s3 이벤트 규칙이 있다.
같은 s3이벤트를 많은 sqs 큐에 보낼 경우, fan-out을 사용

KINESIS

kinesis data firehose
지속적인 관리 없이 자동으로 컴퓨팅, 메모리, 네트워크 리소스를 프로비저닝하고 크기를 조정합니다.

데이터를 람다 함수를 사용해 변형을 할 지, 묶음 단위로 쓰기가 가능하다.

amazzon s3, redshift, elstic search

완전 관리 서비스, 서버리스, 자동 스케일링, 유료

data stream vs firehose

스트리밍 서비스 vs 스트리밍 데이터를 전송

커스텀 코드를 사용 vs 와전관리형

실시간 vs 실시간에 가까움

스케일링 관리 vs 자동 스케일링

데이터 저장 vs 데이터 저장 x

message filtering
json 정책에 따라 필터링을 할 수 있다. 그렇지 않으면 모든 메세지를 받게 된다.

kinesis data stream
모든 규모의 데이터 스트림을 쉽게 캡처, 처리 및 저장할 수 있는 서버리스 스트리밍 데이터 서비스입니다.
데이터를 넣으면 삭제 x 1일-1년까지 저장
provisioned mode : 공급할 shard를 고를 수 있다. 시간당 비용 있음
on-demand mode : 공급 관리의 필요가 없다. 시간과 용량당 비용 있음
iam,https.kms,vpc,api calls

kinesis producers
데이터 기록을 데이터 스트림에 넣는다.
aws, sdk, kinesis agent, producer library, 가 producer
해시함수 기능으로 stream에 접근

provisionedthroughputexceeded
일정 전송 속도를 초과하는 경우
고도로 분배된 파티션 키를 사용한다.
shards를 증가시킨다.

kinesis consumer
데이터 기록을 조회한다.
lambda, analytics, firehose, sdk, kinesis client library
shared(classic) fan-out consumer : 2mb/s shared 하나로 모든 consumer 에게 분배한다. - pull 적은 숫자 (max 5개의 요청) 비용 최소화
enhanced fan-out consumer : consumer 하나당 하나의 2mb/s shared를 분배 여러개 가능, 지연율 좋음, 비쌈

kinesis client library
kinesis data 로 부터 읽고 기록하는 것을 도와주는 라이브러리, ec2, 온프레미스에서 사용된다. 4개 버전 6개버전 존재

인스턴스의 수는 샤드의 수를 넘지 않는다.

shard--splitting

stream capacity 의 능력을 상승 : 양이 많은 shard를 두개로 나눈다. 오토 스케일링 불가능

merging-shard

두개의 shard를 하나로 합치기도 한다. 두개 이상 합치는 것은 불가

kinesis data analytics

스트림과 firehose 와 sql 구문으로 데이터 분석을 진행한다. 실시간 분석 가능

자동 스케일링, 완전관리, 유료

sqs vs sns vs kinesis

sqs

소비자가 데이터를 당겨올 수 있다.

데이터는 소비된 이후에 삭제된다.

우리가 원하는 마나큼의 많은 소비자를 가질 수 있다.

보관 필요 없음

fifo 큐에서 순서를 보장받는다.

데이터에 순서가 없다..fifo의 경우는 그룹 id를 쓰지 않는 경우 메세지들은 순서대로 보내지는데 한명의 소비자에게만 전달되게 된다.

sns

데이터를 많은 구독자에게 입력

데이터는 지속되지 않고 삭제 되기도 한다.

topic 굉장히 많음,

kinesis

fan out으로 데이터 푸시 가능

데이터 응답 가능성,

실시간 빅데이터 분석 가능

shard level 에서 순서화, 데이터 만료는 몇일

데이터를 순서대로 할당할 때 하나의 shard를 배치했을 경우 같은 성질의 파티션 키는 계속 처음 배정되었던 shard로 가서 역할을 다하게 된다.

ex 100개의 트럭 : 20개씩 나눈 5개의 sharad로 사용하게 될 것 같다.

AWS Lambda

세션 정보를 dynamodb 테이블에 저장한다.

배포는 템플릿에서 AWS::Lambda::Function 리소스를 생성한 다음 CloudFormation 템플릿 내부에 직접 코드를 작성합니다.

함수 코드가 포함된 .ZIP 파일을 Amazon S3에 업로드한 다음 템플릿의 AWS::Lambda::Function 리소스에 이 파일에 대한 참조를 추가합니다.

zip을 s3에 업로드했는데 새로운 코드로 변경해서 zip을 s3에 올리면 이전코드가 실행되는데,

업데이트 기능 코드 api를 호출하면 해결할 수 있다.

lambda 런타임에서 환경에 배포하는 경우

zip파일로 만들어 Lambda 환경 변수 LD_LIBRARY_PATH로 표시된 Amazon S3 버킷에 종속 라이브러리를 스테이징합니다.

아닌 경우 그냥 zip 파일로만 만든다.

동기 호출

함수가 이벤트를 처리하여 응답을 반환하기를 기다립니다.

CLI,SDK,API 게이트웨이, ALB

유저호출 : elastic load balancing, api gateway, cloudfront, s3batch

서비스 호출 : cognito, step functions

람다 integration with alb

ALB 사용 가능, 람다함수는 타겟 그룹에 등록되어야 한다.

json 으로 활용, alb는 멀티 헤더를 줄 수 도 있다.

Lambda@Edge

애플리케이션의 사용자에게 더 가까운 위치에서 코드를 실행하여 성능을 개선하고 지연 시간을 단축할 수 있게 해 줍니다

웹 애플리케이션을 전 세계로 배포하고 성능을 개선하여 효과를 향상해 줍니다.

a3 에 저장된 웹사이트 - > 유저가 웹사이트 방문 -> cloud front -> lambda@edge function(각 cloudfront edge에서 코드를 동작, 글로벌하게) -> db에 접근 -> 쿼리 데이터 제공

비동기 호출

처리를 위해 이벤트를 대기열에 저장하고 즉시 응답을 반환합니다. 비동기식 호출의 경우 Lambda는 재시도를 처리하고, 호출 레코드를 대상에 보낼 수 있습니다.

s3 버킷에서 새로운 이벤트 발생 -> 이벤트 큐에 놓이고 읽음 -> 잘못되면 에러를 발생시킨다.(3번의 시도 1분 2분 간격으로) -> 로그를 복사해서 재시도 ->dead letter queue 결정 (sns sqs)로 오류 처리

s3 , sns, cloudwatch/eventbridge, codecommit, codepipeline

cloudwatch events/ eventbridge

1시간 마다 실행, 상태 변화 -> 람다는 태스크를 수행

s3 events notifications

s3 -> sns -> sqs

sqs -> lambda

lambda -> sqs 가능

이벤트 소스 매핑

람다 기능이 동시에 호출된다..

에러 관리

기능이 에러가 발생하면 전체 배치는 기능이 성공할때까지 재처리되거나 혹은 만료된다.

오래된 이벤트 삭제, 횟수제한, 배치단위를 나눈다.

sqs&sqs fifo

dlq를 람다 함수가 아닌 이벤트 소스 매핑 단계에서 생성한다.

람다는 분당 60개가 넘는 인스턴스를 더한다. scale up 시에 (sqs)

1000개의 배치 메세지 그룹을 동시에 처리한다.(sqs)

같은 그룹아이디들의 메세지가 순서대로 처리된다.(sqs fifo)

람다 함수는 메세지 그룹의 숫자를 늘린다. (sqs fifo)

queues & lambda

10개의 배치 묵음이 하나의 shard 당 동시에 처리된다.

하나의 람다 호출이 하나의 stream shard를 호출

lambda destinations

실패시 dlq보다는 어떤 목적지로 이동하는 것을 추천

비동시적 호출 sqs, sns, lambda, eventbridge bus

람다 실행 역할(IAM)

이벤트 소스 매핑을 사용할경우 람다는 이벤트 데이터를 읽을 수 있는 실행 역할을 사용한다.

s3 버킷 정책과 유사

람다 환경 변수

키 / 값 쌍이다. 비밀을 저장하는 데에 도움이 된다.

람다 추적 x-ray

어플리케이션 구성요소 시각화, 오류 해결을 한다.

백그라운드 실행 가능, 람다 구성에서 가능, 람다 함수에 iam 역할이 있는지 확인

xray_daemon_address: ip와 포트가 어디 있는지

VPC 네트워킹

람다가 사적인 db 환경에 접근하지 못할 수 있다. vpc id 를 정의해야하고 서브넷과 보안그룹을 설정해야 한다.

람다는 eni를 생성한다. -> lambdavpcaccessexecutionrole 보안 그룹에 속해있는지 확인 후 사용

인터넷 접근

람다함수는 인터넷 접근이 없다. 람다 함수를 배포하는 것이 인터넷 접근을 허용하는 공용 ip를 주는 것이 아니다.

람다 함수는 NAT. 게이트웨이 인스턴스로 인터넷 접근을 사용한다.

NAT 접근 없이 vpc endpoint를 활용하여 사적입 접근을 가능하는 방법도 있다.

람다함수 구성

ram : 128mb ~ 10 gb

cpu가 한계에 있다면 ,ram을 늘려라

timeout : 3초 ~ 15분

람다 함수가 대용량 파일을 다운 받아야 한단면 /tmp 공간을 사용하면 된다. (512mb)

이보다 크면 s3에 업로드하고 --code cli파라미터를 사용해 s3를 참조한다.

람다 동시성 및 조절\

람다를 최대 100개까지 돌릴 수 있다.

동시 호출 -> error 429

비동시 호출 -> dlq

cold start : 새로운 인스턴스 => 코드가 로드되고 실행되는데 이 과정이 처음이라 오래걸릴 수 있다.

provisioned concurrency : 함수가 실행되기 전에 할당된다. cold start가 일어나지 않고 지연율이 낮아진다. vpc에서는 더 안일어난다.

람다와 cloudformation - inline : 매우 간단한 형식

람다와 cloudformation - sc through : s3에 람다 zip을 저장해야만 한다. s3 location의 위치도 참조해야 한다. s3의 코드를 업데이트 한다면 s3 버킷,키,objectversion은 업데이트 해서는 안된다.

여러 계정에 대해서는 버킷 정책에 따라 판단.

lambda layers

가벼운 패키지에 무거운 람다 레이어를 쌓는다. 이 레이어들은 나중에 다른 람다 함수에도 사용할 수 있도록 분리하는 형태

lambda container images

람다 함수를 컨테이너로 배포할 수 있다10gb까지 이미지를 새로 만들고 구현하려면 lambda runtime api를 사용한다.

lambda versions

람다는 일반적으로 최신 버전을 사용하는데 업데이트 시마다 버전을 남길 수 있다.

lambda aliases(가명)

dev,test,prod aliases 새로운 버전을 사용할 때 테스트 버전에 약간의 비중만 두어서 사용하기도 한다.

lambda codedeploy

배포를 100퍼센트가 아닌 일정 퍼센트를 설정해서 몇분마다 배포하도록 설정한다.\

lambda 컨텍스트 객체

주요 이벤트를 기록, 여기서 요청 식별자를 얻고 콘솔에 로그를 기록하도록 어플리케이션을 설계한다.

dynamoDB

DynamoDB에서는 IAM 정책을 사용한다.

사용자에게 테이블 또는 보조 인덱스의 특정 항목 및 속성에 대한 읽기 전용 액세스를 허용하는 권한을 부여할 수 있습니다.
사용자 ID를 기준으로 테이블의 특정 속성에 대한 쓰기 전용 액세스 권한을 해당 사용자에게 부여할 수 있습니다.

provisioined mode : 공급 비용 있음, 초당 읽고 쓰는 숫자를 명시한다.

온디맨드 모드 : 자동적으로 읽고 쓰고, 스케일링 한다. 더 비싸다

24시간마다 변경 가능

write capacity units(wcu)

초당 1개의 아이템 1kb 의 성능, 아이템이 1kb보다 크면 다음과 같음

10 items * 2kb크기 아이템 / 1kb = 20 wcu

강력한 일관된 읽기

쓰기만 한 후에는 수정된 데이터를 얻는다. (getitem 을 호출할 때 consistentread 파라미터를 true로 변경하면)

DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트가 반영된 최신 데이터를 포함하는 응답을 반환
단점
- 네트워크 지연 또는 중단이 발생한 경우에 사용 어려울 수 있고 DynamoDB는 서버 오류(HTTP 500) 를 반환할 수 있음
- 최종적 일관된 읽기보다 지연 시간 처리 용량을 더 많이 사용
- 글로벌 보조 인덱스에서는 지원되지 않음
예시) 위의 사진에서 쓰기를 하자마자 바로 읽어서 최신 데이터를 가져올 수 있음
항목 크기가 4KB인 12개의 강력한 일관된 읽기
We need 12 * (4KB/4KB) = 12RCUs

초당 최종적 일관된 읽기(eventually) 2개

default 설정
DynamoDB 테이블에서 데이터를 읽을 때, 응답에 최근 완료된 쓰기 작업의 결과가 반영되지 않을 수 있고 부실 데이터가 일부 포함될 수 있음
쓰기 작업을 하고 잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환합니다.
단지 쓰기만 한 후에는 복제때문에 오래된 데이터만 얻게 된다.
항목 크기가 8KB인 16개의 최종적 일관된 읽기
We need (16/2) * (8KB/4KB) = 16RCUs

partitions internal

데이터는 파티션에 저장된다.

파티션 키는 해싱 알고리즘을 거쳐 어떤 파티션으로 가게 될지 알게된다.

WCU와 RCU는 균등하게 파티션에 퍼져있다.

Throttling

관리하는 rcu wcu를 넘어서면 provisionedthroughputexceedexception을 얻는다.

distribute partitions keys, dynamodb accelerator 사용으로 해결

R/W capacity mode - 온디맨드

자동 스케일, 용량 설정 필요 없다.

writing data

putitem : 새로운 아이템을 생성하거나 기존 아이템을 대체한다. wcu사용

updateitem : 이미 존재하는ㄴ 아이템 특성을 편집, 혹은 새로운 아이템을 추가한다.

ataomic counter를 구현

conditional writes : write/ update/ delete 가능

reading data

getitem : pk에 기반, 해시 tkdyd, eventually rea

reading data(query)

쿼리는 다음을 기준으로 항목을 반환한다.

keyconditionexpression ( pk : = 사용, 다른 정렬 쿼리)

filterexpression( 해시 허용하지 않음)

returns: 명시된 아이템 숫자 한계

reading data(scan)

전체 테이블을 스캔하고 필터링한다.

1mb 데이터로 반환, 많은 rcu를 사용하게 된다.

더 빠른 수행력을 위해선 parallel scan을 사용한다.

delete data

deleteitem : 개별 항목을 삭제, 조건부 삭제

deletetable : 전체 테이블 삭제

batch operation

api 요청을 줄여 지연율을 줄여 저장

평행하게 작업이 진행됨

batche write tiem : 25putitem이나 deleteitem사용 가능 한번에

batchgetitem : 1개 이상의 테이블 반환

local secondary index

대체 가능한 정렬 키, table 생성 시간을 정의해야만 한다. attribute 내에서사용

global secondary index : 대체 가능한 pk 구분을 짓는 partitionkey가 다른 키로 변경되어 더 많이 포괄할 수 있도록 한다.

partiQL : sql : 문장형식으로 표현

optimistic locking : 업데이트(또는 삭제)하는 클라이언트 측 항목이 Amazon DynamoDB의 항목과 동일하도록 하는 전략쓰기가 다른 사용자의 쓰기에 의해 덮어쓰이지 않도록 보호되며, 그 반대의 경우도 마찬가지

DAX (db accelerator) : 마이크로 지연율, 완전과리 ,고가용성, 어플리케이션 로직 필요 없음, hotkey 문제를 해결

multi-az, 보안성, 가장 인기있느 아이템이나 쿼리를 기록해준다.

요청 수가 급증할 때 완화를 위해 사용, 대기시간 적게 소모, 실행 비용 감소

dax vs elasticache

개별 객체 캐시, 쿼리 스캔 캐시 vs 집합 결과를 저장

dynamodb streams

시간 순서에 따라 데이터 수정에 대한 정보를 포함합니다. 하루동안 로그에 저장한다.

stream에 쓰여질 정보를 고를 수 있는 능력이 있다.

이벤트 소스 매핑이 필용하고 적절한 허가, 람다 함수는 동시 호출이다.

복잡성을 최소화 데이터 보관

DynamoDB는 Streams의 이벤트에 자동으로 응답하는 코드 조각인 트리거를 만들 수 있도록 Lambda와 통합되어 있습니다. 트리거를 사용하면 DynamoDB 테이블의 데이터 수정에 응답하는 애플리케이션을 빌드할 수 있습니다.

테이블에서 DynamoDB Streams를 활성화할 경우 스트림 Amazon 리소스 이름(ARN)을 사용자가 작성하는 AWS Lambda 함수에 연결할 수 있습니다. 테이블의 항목이 수정되는 즉시 새로운 레코드가 테이블의 스트림에 표시됩니다. AWS Lambda는 새로운 스트림 레코드가 감지될 때마다 스트림을 폴링하고 Lambda 함수를 동기식으로 호출합니다.

Steam을 AWS Lambda에 대한 트리거로 구성합니다. 스트림의 레코드가 수정되면 Amazon S3에 레코드를 저장합니다.

TTL

0으로 설정하면 비활성화된다. 시간 만료되면 자동 삭제 기능 wcu 사용하지 않는다.

Cli

projection-expression : 하나 이상의 특성들이 재처리된다.

filter-expression : 나에게 반환되기 전에항목을 필터링한다.

page size : cli 가 재처리할 수 있는 전체 리시트 항목을 명시한다. api요청 수보다 크지는 않음

max-items : 최대 숫자의 아이템을 보여준다.

starting-token : 최신 nexttoken을 보여준다.

transaction

read mode : eventual consistency, strong consistency, transactional

write mode ; standard, transactional

2 * wcu & rcu를 사용

session state cache

vs elasticache : 인메모리 이지만 dynamodb는 서버리스다. 둘다 모두 key/value 저장

vs efs : efs는 ec2 인스턴스에 네트워크 드라이브로 붙어있어야 한다.

vs ebs & instance store : 오직 로컬 캐싱에만 사용된다.

vs s3 : 높은 지연율 작은 객체를 의미하는 것은 아니다.

write sharding

같은 키를 구분하기 위해 사용 하는 방법

write type

concurrent write : 한명이 먼저 편집한걸 뒷사람이 덮어쓰기 된다.

conditional write : 첫번째가 받아들여지면 두번째는 실패한다.

atomic write : 두명의 요구 모두 받아들일 수 있다.

batch write : 한번에 여러 항목을 수정할 수 있다.

Operations

table cleanup : scan+deleteitem, drop table + recreate table

db 테이블 복사 1. data pipeline 사용, 2. 백업하고 새로운 테이블에 저장해둔다. 3. 스캔 + 항목수정

security & other features

security : vpc, iam, kms, ssl

백업 하고 저장 가능

global table : multi-region, active, 완전복제, 높은 수행력

빈테이블 만드는 방법 : 작업을 완료하고 테이블을 생성하고 삭제한다.

API Gateway

Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다.

CORS 활성화 기능

람다를 gateway를 활용하여 api를 호출할 경우, 비용 증가 없이 성능을 개선하기 위해선

핸들러 함수 외부에서 실행하면 함수가 데이터베이스 연결을 재사용하여 성능을 높일 수 있습니다.

Lambda 함수에 필요한 모듈만 패키징합니다.

리소스 수를 최소화하면서 어플리케이션을 배포 : 여러 별칭이 있는 하나의 Lambda 함수를 사용하여 여러 단계의 API 게이트웨이 하나를 생성합니다.

api 버전관리, 다른 환경 관리, 보안 관리, api 키 생성, 리퀘스트 관리, api 정의, 웹소켓 프로토콜 관리

api 응답 캐싱

람다함수 : 호출한다. 백엔드에서 rest api 노출이 쉽다.

http : 백엔드에서 http 엔드포인트를 노출한다.

aws service : 어떤 api 서비스도 가능하다.

endpoint type

edge-otpimized : 글로벌 클라이언트, api-gateway는 오직 하나의 지역에 산다.

regional : 같은 지역에 있는 클라이언트 cloudfront와 결합 가능

private : vpc 로만 접근 가능

배포 단계

새로운 버전을 만들고 그에 맞는 url을 새로 만든다.

canary 배포

새로운 버전에 대한 걸 만들어 놓고 일정 테스트 버전에 트래픽을 조금 주며 테스트 해보며 변경

API 버전을 고유한 엔드포인트가 있는 고유한 단계로 배포하고 단계 변수를 사용하여 추가 컨텍스트 제공

매트릭과 로그는 분리 , 변수 덮어쓰기 가능, blue/green 배포

integration type

mock : api gateway는 백엔드에 요청 전달 없이 응답

http /aws : 통합 요청 통합 응답, 매핑 템플릿을 사용한다(sqs queue)

aws proxy(lambda proxy) : 요청이 람다에 들어온다. 매핑 템플릿없고,헤더,없고,쿼리스트링 없다. 바디에 내용을 담아 반환

httpproxy : 템플릿 없고, 프록시를 통해 백엔드와 소통

매핑 템플릿 : 쿼리 스트링 파라미터 수정 가능, 바디 내용 수정 가능, 헤더 추가 가능 (json(rest api), xml(soap api))

캐싱 api response

백엔드에서 만들어지는 요청을 줄인다. 고정 ttl은 300초, 단계마다 캐싱은 정의된다. 비싸다.

usage pelans & api keys

API를 생성, 테스트 및 배포한 후 사용량 계획을 사용하여 API를 고객을 위한 제품 혜택으로 제공

고객이 선택한 API에 액세스할 수 있도록 사용 계획 및 API 키를 구성하고 정의된 제한 및 할당량에 따라 해당 API에 대한 요청 제한을 시작할 수 있습니다

리소스 정책

지정된 보안주체가 api를 호출할 수 있는지 여부를 제어하기 위해 api에 연결하는 json 정책 문서

logging&tracing

cloudwatch logs : 설정 덮어쓰기, stage 수준에서 로깅 가능, 바디 요청 응답 정보가 들어있다.

액세스 로그 활성화 : 액세스하는 사람과 방법을 기록하고 로그가 보관되는 기간을 제어한다.

x-ray : 여분의 정보를 추정할 수 있다.

cloudwatch metrics

cachehitcount & cache miss countt: 캐시의 효율성

count : 총 api요청의 숫자

integrationlatency : api gateway에서 백엔드에 요청하고 응답을 받는 시간

latency : 클라이언트에게 요청을 받고 클라이언트에게 요청을 돌려주는 시간

IAM Permissions : 인가 = IAM, 인증 = IAM 정책

Resource polices : 교차 계정 접근 가능하다(iam 보안)

custom authorizer : 제 3자 인증 시스템을 돕는다.

cognito user pool : 사용자 풀을 관리한다. 커스텀 코드 사용 필요 없음 인증을 백엔드에서 구현해야함

http api : rest api

http api : 낮은 지연율, 비용 효

rest api : 모든 특징 커버 (람다, iam ,cognito)

websocket api

websocket : 정적이다. 실시간 어플리케이션엔서 사용한다.

SAM(Serverless Application Model)

cloudformation에서 만들어졌다.서버리스 리소스를 표현하기 위한 단순화된 구문을 정의하기 위해 어떤 도구

sambuild : 의존성 수정 그리고 로컬 배포 아티팩트 생성

sampackage : s3에 올리고 cf 템플릿을 실행한다

samdeploy : cloudformation에 배포한다.

재배포를 위한 명령 조합 : sam init, sam deploy

개발과 배포를 돕는 프레임워크 (yaml코드 구성)

람다함수fmf dnlgo codedeploy와 연계 사용 가능, api gateway , dynamodb 도 locally하게 사용할 수 있음

문서 : Transform(선택 사항) : 템플릿에 리소스, 버전 선언 가능

정책 탬플릿

람다함수 허가 적용 여부 리스트

s3readpolicy : 읽기만 가능한 허가

sqspollerpolicy : sqs 큐에서 뽑기를 허가

dynamodbcurdpolicy :CURD 가능케함

Codedeploy

람다함수를 업데이트 하기 위해 샘 프레임워크를 사용한다. 버전 변경에 따른 트래픽 전환 테스트를 진행하고 버전을 변경한다.

sar(serverless application repository)

서버리스 어플리케이션을 위한 관리된 리포지토리다.

람다 함수를 여러개 레포지터리에 보관한 상태에서 배포를 진행한다. 공유간응해 중복작업 삭제, 환경변수 커스텀 가능

CDK(Cloud Development Kit)

클라우드 구조를 친숙한 언어로 정의한다.

구조와 어플리케이션 실행 코드를 동시에 배포할 수 있다.

cloudformation은 yaml로 구조만 정의하지 그외의것은 설정할 수 없음..

cdk vs sam

sam : 서버리스에 초점이 맞춰져있고 템플릿이 json 이나 yaml로 선언되어있다. 빠르게 람다로 시작할 수 있음

cdk : 모든 aws 서비스에 초점 ,프로그래밍 언어에 초점

Cognito

간단하고 안전한 사용자 가입, 액세스를 제어한다.

사용자 자격 증명이 노출되지 않기 위해서 사용되는 것

IAM 역할 및 정책 또는 Lambda 권한 부여자를 사용하는 것 말고도

Amazon Cognito 사용자 풀을 사용하여 API Gateway에서 API에 액세스할 수 있는 사람을 제어할 수다.

게스트 엑세스를 사용하기 위해선 인증되지 않은 엑세스가 활성화된 cognito를 사용한다.

새 자격증명 풀을 생성하고 인증된 자격 증명에 대한 액세스를 활성화 하고 권한을 부여한다.

cognito user pools

cup(인가) api gateway (rest api + pass token) : cup의 인가 토큰을 처리한다.

유저 관련 정보 처리(소셜로그인, SAML), 사용자의 자격 증명이 다른 곳에서 손상된 경우 차단

람다 트리거 : 람다 함수를 동시 호출한다.

호스팅 된 ui 인가를 커스텀 가능(사용자 인터페이스 생성 가능)

cognito identity pools

aws 리소스에 직접적으로 접근할 수 있도록 유저에게 임시 aws 인증을 제공, 인가되지 않은 접근도 허가한다.

유저는 aws 서비스와 api gateway에 접근한다.

cognito sync : 백엔드 없이 사용 가능한 cognito 기능

vs iam : iam은 aws 환경에서 신뢰하는 유저 대상, cognito는 유저,모바일 유저, saml인가 유저 등을 대상으로 한다.

user pools vs identity pools

user pool : 유저의 웹과 모바일 에 대한 db, 연방 로그인된다. 호스팅 된 ui 인가를 커스텀 가능 aws lambda 사용가능

idnetity pool : aws 인증, 연방 로그인된다. 인가되지 않을 수 잇다. iam 역할 정책에 영향력 행사 가능

cup + cip = 유저 관리 패스워드 와 aws 서비스 접근 가능해짐

Step functions & appsync

Lambda 함수를 조정한다. 다른 방식으로 실행되고 있는 작업을 api gateway를 사용하여 동일한 순서로 호출한다.

json작성, 작업흐름을 시각화 모델링한다.

states

choice state : 브랜치에 보내는 조건을 테스트한다.

pass state : 입출력을 통과, 고정된 데이터를 주입

map state : 동적으로 동작을 반복한다.

error handling

재시도하거나 실패 경로를 캐치할 수 있다. application code 대신에

errorequals: 구체적인 에러의 종류 설정

intervelseconds : 재시도 전에 시도해보는 시간

backoffrate : 각 재시도마다 지연 비율을 곱한다.

maxattemps : 최대 시도 횟수, 최대까지 해보면 catch 함

catch : errorequals, next(오류 어디에 보낼지), result path ( 경로, 인풋에 에러를 포함해야 한다. 원래 입력에 오류를 포함하여 원래 입력과 오류를 모두 보존할 수 있다.)

standard vs express

1년 vs 5분

초당 2000 실행 vs 초당 10만 실행

appsync

graphQL : 어플리케이션이 정확히 필요로하는 데이터를 제공하도록 해준다.

nosql, rdbms, http, dynamodb, elasticsearch, lambda, 모두 결합 가능

실시간, mqtt 웹소켓으로 데이터 복구 가능

로컬 데이터 접근, 데이터 동기화 등을 가능하게 한다.

api key, iam, openid_connect, cognito_user_pools, cloudfront

amplify

모바일 웹 어플리케이션을 만들어준다.

데이터 저장소, 인가, 저장소, 머신러닝과 같은 요소들이 aws 서비스로 실행되고 있어야 한다.

sts(security token service)

IAM의 임시 보안 자격 증명

assumerole : 계정에 있는 역할을 추정

assumerolewithsaml ; saml에서 로그된 유저의 권한을 반환한다.

assumerolewithwebidentity : 유저의 로그 권한을 반환 cognito identity pools 사용

gettsession token : mfa aws root유저로부터 받음

getfederationtoken : 임시 권한 받음

getcalleridentity : 세부적인 iam 유저 역할을 받음

adecodeauthorizationmessage : 에러 메시지를 해석

iam 역항르 정의한다. 권한 회복 접근 가능, 임시 권한 15분간 획득 가능

aws:multifactorauthpresent : true

advanced iam

iam 정책과 s3 버킷 정책이 모두 있으면 둘을 합쳐 사용한다. (겹치는 부분에 대해서 더 명백한 정책을 사용)

IAM 동적 정책

모든 유저에게 적용되는 것이 아닌 일부 유저에게만 적용되는 정책의 경우 유저이름을 명시할 수 있도록 해 특정 유저에게만 적용되도록 한다.

인라인 vs 관리 정책

aws managed policy ( aws 에 의해 유지, 새로운 서비스 업데이트)

customer managed policy : 재사용, 다양한 원리에 적용, 버전 통제, 되돌리기

inline : 1대1 정책과 원리에 대해 엄격하다. iam 원리를 지우면 정책은 삭제된다.

유저 허가 권한 부여

aws 서비스를 구성하기 위해선 iam 역할을 통과해야 한다. 서비스는 역할을 추정하고 행동한다.

그들이 신뢰하는 것에서만 허가 통과를 낼 수 있다.

aws directory service

ms active directory : 윈도우 서버에서 찾을 수 잇따. db 객체 (유저계정, 컴퓨터 프린터,보안그룹)

중앙화된 보안 관리, 트리 형태, 숲 형태

managed ms ad : ad를 aws 에서 생성할 수 있다. 유저를 로컬에서도 관리 가능(mfa)

ad connector : 디렉토리 gateway( 프록시) 를 온프레미스 ad에 연결한다. (mfa)

simple ad : aws 디렉토리와 호환 가능하다 온프레미스와 결합 x

aws Security

암호화

서버측면 암호화 - 데이터는 서버에 의해 수신하기 전까지 암호화 되어있다. 데이터가 전송되기 전에 암호는 해독된다.

클라이언트 암호화:

클라이언트에 의해 데이터는 암호화되고 서버에 의해 해독되지는 않는다.
수신하는 클라이언트에 의해 해독됨.
데이터가 s3 서비스로 전달될 때 보안을 보장하기 위해 로컬에서 데이터를 암호화하는 작업
S3 서비스는 암호화된 데이터를 수신하며 데이터를 암호화 또는 복호화하는 과정에 기여하지 않습니다.

주의

IAM 사용자를 생성하고 사용자의 자격 증명을 애플리케이션에 전달하거나 자격 증명을 애플리케이션에 포함해서는 안 됩니다. 대신 EC2 인스턴스에 연결하는 IAM 역할을 생성하여 어플에 임시 보안 자격 증명을 제공합니다.

액세스 키 대신에 iam 역할을 사용하는 것이 좋다.

kms(keymanagement service)

KMS 기본 암호화를 사용하는 Amazon S3 버킷에 파일을 업로드할 때 액세스 거부 오류 메시지가 표시되는 이유

확인

AWS Identity and Access Management(IAM) 사용자 또는 역할에는 버킷에 대한 s3:PutObject 권한이 있습니다.
AWS KMS 키와 IAM 역할이 서로 다른 AWS 계정에 속해 있는 경우 IAM 정책과 KMS 키 정책을 업데이트해야 합니다. IAM 정책과 KMS 키 정책 모두에 KMS 권한을 추가해야 합니다.
IAM 정책을 사용하여 KMS 키에 대한 액세스를 제어하려면 KMS 키의 키 정책이 계정에 IAM 정책을 사용할 수 있는 권한을 부여해야 합니

symmetric(aes-256 keys) : 암호화 동봉, 키 비암호화에 대한 접근은 할 수 없다 kms api를 사용해야한다.

asymmetric(rsa&ecc key pairs) : 공용 그리고 priavte ke페어 , 임호화 해독, 인증, 사적인 키에 접근 불가, aws 외부 서비스를 이용할 경우 사용한다.

envelope encryption

4kb가 넘는 암호화

데이터를 암호화하면 데이터가 보호되지만 암호화 키를 보호해야 합니다. 한 가지 전략은 그것을 암호화하는 것. 엔벨로프 암호화는 데이터 키로 일반 텍스트 데이터를 암호화한 다음 다른 키로 데이터 키를 암호화하는 관행입니다.

고객 마스터 키는 데이터 키를 암호화/복호화하는 데 사용됩니다. 일반 텍스트 데이터 키는 고객 데이터를 암호화하는 데 사용됩니다.

대용량 데이터 암호화

일반 텍스트 키와 데이터 키의 암호화된 복사본을 반환하는 GenerateDataKey API 호출을 만듭니다.

일반 텍스트 키를 사용하여 데이터 암호화

encryption sdk

envelope encryption을 구현한다. cli툴로 되어있어 설치 가능, 프로그래밍 언어 사용 가능

data key caching : 데이터 키 재사용 가능, api 요청 감소 가능

KMS 요청 quotas

1. 암호화 운영의 경우 ,할당량 공 (요청 감소)

2. generatedatakey를 사용한다면 dek caching을 고려해야 한다. 요청 한계 수준을 상승

s3 암호화

sse-kms : kms 에서 처리 및 관리하는 키를 사용한 암호화, 유저 통제 + 감사 추적, 객체는 서버측에서 암호화된다. 헤더를 설정해야함 generatedatakey & 해독 kms api 요청이 가능하다. cloudtrail 에서 보여진다. kms policy , iam policy,

너무 많은 api 요청이 있으면 kms 한계에 다다른다.

s3 bucket key

데이터 키에 대한 영향력을 행사한다. kms가 직접적으로 접근할 수 없다. kms cloudtrail event를 덜 관측하게 된다.

System Manager(ssm) Parameter store

일반 텍스트 매개 변수 이름과 암호화된 매개 변수 값을 가진 매개 변수인 SecureString 매개 변수를 생성할 수 있다

이는 KMS를 사용하여 보안 문자열 매개 변수의 매개 변수 값을 암호화하고 하고 cmk를 사용하는 경우 iam 정책으로 암호화와 해독이 가능하다.

보안 모범사례 운영 요구사항을 준수하면서 민감한 정보를 저장한다. 구성과 비밀을 보안저장한다.

서버리스, 조절가능, 쉬운 sdk, 버전 트래킹 가능

IAM으로 애플리케이션 액세스 권한 부여(간단), cloudwatch 알림 가능, cloudformation과 통합 가능

파라미터 정책

업데이트나 삭제 할 수 있도록 ttl을 맡긴다.

sescrets manager

기밀 회전을 강제하는 기능, rds와 연계 가능, kms로 암호화 가능

SSM Parameter store vs secrets manager

secrets manager ( 더 비쌈) : 자격 증명이 안전하게 저장되고 액세스되는지 확인하기 위해 사용 자동 암호 교체를 활성화한다. lambda와 함께하는 기밀 자동 로테이션, 암호화 필수, cloudformation과 연계 가능

ssm parameter store (덜 비쌈) : 간단한 api, 기밀 순회는 없지만, 순회하려고 하면 가능 람다 트리거 사용)

kms 암호화 선택, cloudformation 과 연계

cloudwatch logs - encryption

cloudwatch 로그를 kms 키로 암호화할 수 있다. 암호화는 로그 그룹 레벨에서 사용 가능하다.

cloudwatch log api를 사용해야한다.

other aws service

ses : 이메일을 보내는 서비스

smtp 인터페이스, aws sdk를 사용하는 사람들에게 보낼 수 있음

이메일 받는 기능 : s3, sns, lambda

iam과 연계해 이메일 보내기 가능

elastic : in-memory db : (redis, cache capability)

redshift : OLAP 분석 처리

neptune : 그래프 데이터베이스

dms : db 이전 서비스

documentdb : aws mongodb 관리

cloud map : 백엔드 서비스/리소스 에 대한 맵을 생성한다.

새로운 버전 배포시에 어디로 이동을 해야 하는지를 탐색할 수 있게끔 도와준다.\

fault injection simulator(fis)

aws 워크로드의 실패 주입 실험 서비스

복잡하고 헷갈리는 엔지니어링 속에서 버그를 찾아준다.

ec2, ecs, eks, rds

추가 비용이 없는 서비스: auto scaling, cloudformation

교차 계정의 목적 : 감사

비동기식 : sqs, sns

권한 위임 : assumerole api, 사전 정의된 서비스 정책 사용

관리형 정책 : aws에서 권한을 제공할 목적으로 설계 (dynamodb fullaccess iamfullaccess, 재사용성, 중앙변경관리, 롤백, 권한위임관리)

인라인 정책 : iam 자격증명에 포함되는 정책

신뢰 정책 : 역할을 수임하도록 신뢰하는 보안 주체를 정의하는 json문서.(사용자,역할,계정,서비스)

400 오류 : s3 버킷이 허용하는 최대 스토리지 용량 초과, 람다 에러, 비동기 에러 코드, 복제 관련 에러, 객체 선택 에러

403오류

Missing permissions to s3:PutObject or s3:PutObjectAcl,

Explicit deny statement in the bucket policy

Bucket access control list (ACL) doesn't allow the AWS account root user to write objects

AWS Organizations service control policy doesn't allow access to Amazon S3

batchwriteitem하나 이상의 테이블에 여러 항목을 넣거나 삭제) transactwriteitems(25개까지의 작업을 요청을 그룹화하는 동시 쓰기 작업)

config 파일은 ebextensions 폴더에

yaml파일은 디렉토리 구조의 루트에서

공용 ip주소 찾기 : X-Forwarded-For 헤더를 HTTP 서버 로그 구성 파일에 추가합니다.

provision : 공급

compatible : 호환되는

syncronize : 동기화

quota ; 할당량

leverage : 영향력

assign : 맡기다.

concurrency : 동시성

세그먼트 : 일반적으로 정량화 할 수 있는 같은 속성을 공유하는 그룹

x-ray : 문제에 대한 해결책을 찾음

cloudtrail : 문제가 왜 발생했는지 탐색하는 역할(감사)

수평 수직 확장 : 수직확장scale up : 부하를 처리하기 위해 부족한 자원을 늘려 서버를 수직으로 확장

수평확장 : 서버의 수를 늘리고 동작하는 어플의 복제본을 실행해 이중 삼중화를 하는 방식으로 부하를 분산