IAM

사용자를 생성하고 그룹에 배치하기 떄문에 글로벌 서비스임

Permissions

사용자 또는 Group 에게 Policy 라고 하는 IAM Policy 를 JSON 문서를 지정할 수있다. 그렇게 사용자들의 권한을 정의 할수 있다.

How can users access AWS?

AWS 접근할때 Console,CLI,SDK 로 접근할수 있다.

AWS CLI

CLI 는 Command Line Interface 로 shell 에서 명령어를 사용해서 AWS 와 상호작용할수 있도록 한다.

AWS SDK

특정 언어로 된 라이브러리의 집합, 따라서 프로그래밍 언어에 따라 개별 SDK 가 있다.

IAM Role

몇몇 AWS 는 본인 게정에서 실행해야 한다. 이를 위해서는 사용자와 마찬 가지로 어떤 권한이 필요하다. 따라서 AWS 서비스에 권한을 부여해야 한다.

EC2

클라우드 가상 서버. Elastic Compute Cloud = Infrastructure as a Service

EC2는 하나의 서비스가 아니고 많은 서비스를 포함하고 있다.

Renting Virtual Machines - EC2
Storing Data on Virtual Drives - EBS
Distributing load across machines - ELB
Scaling the services using an auto-scaling group(ASG)

클라우드는 필요할때마다 언제든지 컴퓨팅을 대여할수 있고 EC2가 그 예이다.

User Data

Ec2 인스턴스에 부팅될때 실행되는 Script 또는 Data 를 의미한다. 주로 Ec2 인스턴스의 초기 설정을 자동화 하는데 사용된다.

Security Groups

AWS 에서 네트워크 보안을 실행하는데 핵심이 된다.
EC2 Instance 에 들어오고 나가는 Traffic 을 제어한다.
Security Groups 은 Allow 규칙만 포함한다.
IP 주소나 다른 Security Groups 을 참조할 수 있다.

SSH

Secure Shell 로 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해주는 프로그램

원래는 SSH 클라이언트를 사용해서 Ec2 Instance 에 접속해야했다. 근데 요즘은 AWS Console 에서 그냥 EC2 Instance 직접 연결할 수 있도록 했다고 한다.

SSH 클라이언트 설정 관리, SSH 서버 설치/구성에 작업을 줄일수 있다. 키를 다운로드 할 필요도 없다.

EC2 Instance Type

Private vs Public IP

네트워크는 IPv4,IPv6 두 가지의 유형의 IP 가 있다.
IPv4 는 온라인에서 가장 일반적으로 사용되는 형식이고
IPv6 는 사물 인터넷에 대한 문제를 해결하기 위해 새로 나온 기술이다.

Public IP 는 인터넷 상에서 기기가 식별될 수 있다.
두 기기가 동일한 공용 IP 를 가질수가 없다.

Private IP 는 기기가 Private Network 에서만 식별될 수 있다.
IP 는 Private Network 안에서만 고유하면 된다.
두개의 다른 회사는 같은 Private IP를 가질수 없다.
기기가 Private Network 에 있을때는 NAT 와 internet Gateway 를 사용해서 인터넷에 연결된다.

Elastic IP

EC2 를 중지하고 다시 시작하면 Instance 의 Public IP 가 변경된다.
Instance 에 고정된 Public IP 가 필요한 경우에는 Elastic IP 를 사용한다.

하나의 instnace 에만 Elastic IP 연결 가능 하다.
Elastic IP 사용하면 Instance 나 SW 오류를 빠르게 대처해서 주소를 계정 내 다른 Instance 에 빠르게 매핑할수 있다.

근데 Elastic IP 를 사용하는것 보다 Public IP 쓰고 DNS 이름을 할당하는게 더 좋다고 한다.

Placement Groups

Ec2 Instnace 가 AWS 인프라에 배치되는 방식을 직접 제어하고 싶을때 쓴다.

Cluster

단일 가용 영역 내에서 지연 시간이 가장 짧은 하드웨어 설정으로 Instance 를 그룹화 한다.

우수한 Network 를 가지는 반면에 Rack 에 Failure 가 발생하면 모든 EC2가 동시에 실패한다.

Spread

Instance 를 다른 HW 에 분산시킨다.

실패 위험을 최소화 하기 위함이다.
모든 EC2 가 Instance가 다른 하드웨어에 위치하게 된다.
동시 실패 위험 감소의 장점이 있지만 하나의 Place Group 마다 7개의 Instance로 제한되므로 Place Group 규모의 제한이 있다.

Partition

분산 배치 그룹과 비슷하게 인스턴스를 분산하려는것. 하나의 가용 여역 내에 다양한 파티션에 인스턴스를 분산시킨다.

각 Partition 은 AWS 의 Rack 을 나타낸다.

ENI

ENI 는 Elastic Network Interface 로 EC2 Instance 가 Network 에 엑세스 할 수 있게 해준다.

가상 네트워크 카드를 나타내는 VPC 의 논리적 구성 요소이다.

EC2 INstnace 와 독립적으로 ENI 를 독립적으로 생성하고 즉시 연결하거나, 장애 조치를 위해 ENI 를 EC2 Instnace에서 이동시킬수 있다.

EC2 Hibernate

최대 절전 모드 이다.
인스턴스를 중지하거나 다시 시작하면 OS 가 부팅되고 Ec2 User Script 가 실행된다.
OS 부팅되고 Application 실행,,, 까지 시간이 많이 걸린다.

Hibernate 를 사용해서 RAM에 있던 인메모리 상태는 그대로 보존하는거다.
RAM에 저장되었던 인메모리 상태는 Root 의 EBS Volume 에 기록한다고 한다.

EBS Volume

Instnace가 실행되는 동안 연결할 수 있는 network Drive 이다. Instance가 종료된 후에도 Data를 지속적으로 유지할 수 있도록 해준다.
한번에하나의 instance 에만 마운트 될수 있다.

Instance 한개에 EBS가 여러개 연결되는건 가능하지만 EBS 한개에 여러개의 Instnace는 연결될수 없다.

EBS Snapshots

EBS Volume의 특정 시점에 대한 Backup 을 생성할 수 있다.
SnapShot 은 Az 또는 region을 거쳐서 복사할 수 있다.

AMI

Amazon Machine Image 이다.
소프트웨어,구성,운영체제,모니터링 등을 직접 추가할수있다.
모든 SW가 미리 패키지되어 있다.-> 부팅,구성시간 빠름

Instance Store

EBS Volume 은 성능은 좋지만 제한적인 Network Drive 라고 한다.
그래서 고성능 Hardware Disk 가 필요한 경우에는 Ec2 Instance Store를 사용한다고 한다.

Instance Store 에는 instance 블록 수준의 임시 Storage 를 제공한다.

Instance 를 중지하거나 최대 절전 모드로 전환하거나 종료하면 Instance Sotre 의 모든 Storage의 Block 이 리셋된다.

EBS Multi-Attach

EBS Volume 은 딱 하나의 EC2 Instance 에만 연결 할수 있다고 했는데 사실 EBS Multi-Attach 를 제외하고는 사실이다.

EBS Multi-Attach 는 Io1 과 Io2 를 위한 것.

EBS Encryption

암호화 된 EBS를 생성하면 암호화가 동시다발적으로 일어난다.

저장 데이터가 Volume 내부에 암호화 , Instance 와 Volume 간의 전송 데이터 또한 암호화, 모든 Snapshot 암호화, Snapshot 에서 생성된 Volume 암호화...

KMS 에서 암호화 키를 생성하여서 AES-256 암호화 표준을 갖는다.

암호화되지 않는 스냅샷 복사를 통해 암호화 할수 있다.
암호화된 볼륨의 스냅샷은 암호화된다.

Encrypt an Unencrypted EBS Volume

1. 볼륨의 EBS Snapshot 을 생성한다
2. EBS Snapshot을 복사 기능을 통해 EBS Snapshot 을 암호화한다.
3. Snapshot에서 새 EBS Volume 생성
4. 암호화된 Volume을 원래 Instnace 에 연결한다.

EFS

Elastic File System 이다.
여러 EC2 Instance에 Mount 할 수 있는 관리형 NFS(Network File System) 이다. 여러 가용 영역에 걸쳐서 있을수 있다.
고가용성 및 확장성이 뛰어나다.

EFS에 대한 엑세스를 제어하기 위해서 Security Group 을 사용한다.

EBS VS EFS

EBS 는 한번에 하나의 Insance에만 연결 가능하다. 특정 가용영역에 제한
Instance Root EBS Volume 은 EC2 Instance가 종료되면 기본적으로 종료된다.

EFS는 여러 가용 영역에서 수백 개의 Instance를 Mount 할수 있다.

Scalability & HIgh Availability

Scalability 는 확장성으로 조정을 통해 더 많은 양을 처리할 수 있는 능력을 의미한다.

Vertical Scalability

Instance 의 크기를 확장하는 것이다. t2.micro 에서 t2.large 로 바꾸는것이다.
분산되지 않은 시스템에서 흔히 사용한다.
RDS,ElastiCache는 수직 확장이 가능한 서비스이다.

Horizontal Scalability

Instance/System 의 수를 늘리는것
수평확장을 한다는건 분산 시스템이 있다는것을 의미한다.

High Availability

수평 확장과 함께 사용되는 개념.
Applicatoin / System을 적어도 둘 이상의 AWS의 AZ 나 DC에서 가동 중인 것을 의미한다.
데이터 손실에서 살아남는것, 따라서 센터 하나가 멈처도 계속 작동이 가능하게끔 하는것이다.

Load Balancing

Network 또는 Application 의 Traffic 을 여러 대의 서버로 분산시켜주는 기술이다.
서버에 가해지는 부하를 분산하여서 서버의 성능을 최적화 하고 안정성을 향상시킬 수 있다.
로드 밸런서는 서버간의 트래픽을 고르게 분산하거나 서버의 가용성을 높이는데 사용된다.

또한 Elastic Load Balancer 는 Application에 사용 가능한 정적 DNS 이름을 제공한다.
다수의 AWS 서비스들과 통합되어 있다.

EC2,ASG,ECS,ACM,CloudWatch,Route53,WAF,Global Accelerator 등..

Health Checks

로드 밸런서가 전달하는 Traffic 을 처리할 수 있는 Instance 의 가용성을 파악할 수 있다.
상태확인은 특정 port 와 ROute 에서 수행된다.
응답이 200이아니면 해당 Instance 는 건강하지 않은 상태이다.

Load Balancer Security Groups

Types of Load Balancer On AWS

CLB

Classic Load Balancers 로 그냥 없어짐

ALB

Application Load balancer 로 Layer7 즉 HTTP 전용 로드 밸런서이다. 동일 EC2 Instnace 상의 여러 Application 에 대한 Load Balancing 이다.
Redirect 지원한다.

ALB 는 Micro Service , Container 기반 Application 에 가장 적합하다.

ALB는 여러 대상 그룹으로 Routing 할수 있으며 Health Checks 는 대상 그룹 수준에서 이뤄진다.

이렇게도 된다.

NLB

Network Load Balancer 이다.
Layer 4 계층에 해당하고 TCP 및 UDP Traffic 을 Instnace 로 전달한다.
가용 영역 당 하나의 고정 IP를 가진다.
Elastic IP를 각 가용 영역에 할당할 수 있다.

GLB

Gateway Load Balancer 이다.
배포 및 확장, AWS 의 3rd Party 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
Layer3 에서실행된다. IP 패킷의 Network 계층이다.

Sticky Session

고정세션이다. 로드 벨런서에 2가지 요청을 수행하는 client 가 요청에 응답하기 위해서 백엔드에서 동일한 Instnace 를 갖는것.

로드 밸런서 뒤에 있는 동일한 instance 로 항상 Redirect 되도록 고정 세션을 구현할수 있다.
고정 세션에 사용되는 쿠키는 client 에서 로드 밸런서로 요청의 일부로 전송되는거임.

그러나 고정세션을 활성화하면 백엔드 EC2 INstnace 에 부하 불균형이 발생할 수 있다.

Cross-Zone Load Balancing

SSL/TLS

SSL 인증서는 Client 와 LB 간의 Traffic을 암호화하여 전송 중에 보호하는것이다. (In-Flight Encryption)

SSL 은 연결을 암호화 하는데 사용되는 보안 소켓 계층이고
TLS 는 새로운 버전의 SSL 이다.

SSL 은 만료 날짜가 있어서 주기적으로 갱신해야 한다.

Load Balancer -SSL Certificates

AWS 에는 이 인증서들을 관리할수 있는 ACM 가 있다. ACM에는 사용자 지정 인증서를 업로드 할수 있다.

SSL - Server Name Indication

SNI 는 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있도록 한다.

SNI 는 ALB & NLB , CloudFront 에서만 작동한다.

Connectoin Draining

인스턴스가 등록 취소, 혹은 비정상적인 상태에 있을 때 인스턴스에 어느 정도 시간을 주어 In-flight 요청, 즉 활성 요청을 완료할 수 있도록 하는 기능.
등록 취소 중인 EC2 Instance 에 새 요청을 보내지 않도록 한다.

ASG

Auto Scaling Group 이다. 웹사이트나 어플리케이션의 부하는 변할수 있는데 사용자는 Cloud 에서 서버를 빠르게 생성하고 종료할 수 있다.

CloudWatch Alarms & Scaling

ASG 를 CloudWatch 경보에 기반하여 Scale In/Out 할 수 있다.
Alarm 은 Metric(평균 CPU,Custom Metric) 을 모니터링 한다.
평균 CPU와 같은 지표는 전체 ASG Instance에 대해 계산된다.
경보를 기반으로 Scale-Out/Scale IN 할수 있다.

Auto Scaling Policies

Dynamic Scaling Polices

// Target Tracking Scaling 대상 추적 크기 방법
가장 간단하고 쉽게 결정할 수 있는 방법이다.
평균 ASG CPU 가 약 40% 대에 유지되도록 한다.

// Simple/Step Scaling 단계 크기 조정
CloudWatch 경보가 Trigger 될때 추가/제거를 한다.

// Scheduled Actions 예약된 크기 조정
알려진 사용 패턴에 기반하여 스케일링을 예상.

Predictive Scaling Polices

부하를 지속적으로 예측하고 미리 스케일링 일정을 예약하는 것

RDS

RDS 는 관계형 DB 서비스이다.
SQL 을 쿼리 언어로 사용하는 DB 용 관리형 DB 서비스이다.
AWS 에서 관리되는 클라우드 상의 DB를 생성할 수 있도록 해준다.

Advantage over using RDS Versus Deploying DB on EC2

RDS 는 관리형 서비스이고 AWS 는 DB 뿐만 아니라 다양한 서비스를 제공한다.

RDS - Storage Auto Scaling

데이터 베이스 Storage 가 부족해지고, RDS Storage Auto Scaling 기능이 활성화 되어 있으면 RDS 가 이를 감지하여 자동으로 Storage 를 확장해준다.

워크로드를 예측할 수 없는 Application 에서 유용하다.

RDS Read Replicas for read Scalability

복제는 비동기 방식으로 진행된다. 즉 읽기가 일관적으로 유지된다.
복제본은 자체 데이터베이스로 승격될 수 있다.

읽기 전용 복제본을 사용하려는 경우에는 주요 APplication은 모든 연결을 Update 해야하며 이를 통해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있다.

정상적인 작업 부하를 처리하는 Production DB 가 있다고 가정했을때 Data를 기반으로 몇 가지 보고와 분석을 실시하고자 한다. 새로운 작업 부하를 처리하기 위해 읽기 전용 복제본을 생성한다.

Network Cost

AWS 에서는 Data가 한 AZ에서 다른 AZ로 이동할때 Network Cost 가 발생한다. 하지만 동일한 Region 에서 RDS 읽기 전용 복제본에 대해서는 해당 비용을 지불하지 않는다.

RDS Multi AZ

Disaster Recovery 를 위해서 사용한다.

가용성 향상한다.
AZ 손실, 네트워크 손실, 인스턴스 또는 Storage 장애 발생시 Failover
읽기 전용 복제본은 재해 복구를 위해 다중 AZ로 설정될 수 있다.

Fron Single AZ to Multi AZ

다운타임이 없는 운영이다. DB를 중지할 필요 없다.
DB에 대해 수정하고 활성화 시키기만 하면 된다.

Aurora

Aurora 는 AWS 고유 기술로 오픈 소스는 아니다. Postgres와 MySQL 이 호환된다. Aurora는 AWS 클라우드 최저고하 되어 있으며 RDS 의 MySQL 에 비해 5배 높은 성능이고, RDS Postgres에 비해 3배 높은 성능을 낸다.

Aurora High Availability and Read Scaling

3개의 가용영역에 걸쳐 6개의 데이터 복사본을 저장한다.
마스터는 하나, 복제본은 여러개, 스토리지 복제, 작은 블록 단위로 자가 복구 또는 확장이 일어난다.

Aurora DB Cluster

자동 스케일링, 자동 확장되는 공유 스토리지 볼륨.
로드밸런싱이 statement level 이 아니라, connection level 에서 일어난다.

Features of Aurora

Aurora Replicas - Auto Scaling

Aurora - Custom Endpoints

일부 Aurora Instance를 사용자 지정 Endpoint 로 정의할수 있따.
특정 복사본에서 분석 쿼리를 실행한다.

Aurora Serverless

실제 사용량이기반하여 자동으로 DB Instance 화 및 자동 스케일링이 이뤄진다.
비정기적,간헐적,예측할 수 없는 워크로드에 적합하다.
용량 계획이 필요하지 않다.

Aurora Multi-Master

쓰기 노드의 즉각적인 장애 조치가 필요한 겅유.

Amazon RDS Proxy

Application이 DB 내에서 DB 연결 풀을 형성하고 공유할 수 있다.
DB Resource 에 가해지는 부하를 줄이고 Timeout 을 최소화 하여 DB 의 효율성 향상.
RDS proxy 는 Serverless 로 ASG 가 가능해 관리할 필요가 없고 가용성이 높다.

ElastiCache

RDS 와 동일한 방식으로 관계형 DB를 관리할수 있다.
ElastiCache 는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 한다.
읽기 집약적인 워크로드에서 DB의 부하를 줄이는데 도움.
Application 을 Stateless로 만드는데 도움이 된다.
ElastiCache를 사용하는 것은 Application 코드 변경이 많이 필요하다.

DB Cache

Application 은 ElastiCache에 쿼리를 보내고 ElastiCache 에 데이터가 없는 경우에는 RDS에서 가져와 ElastiCache에 저장한다.
RDS 의 부하를 완하하는데 도움된다.

User Session Store

Redis vs Memcached

Redis 는 읽기 스케일링에 사용되며 가용성이 높은 읽기 전용 복제본이다.
Memcached 는 가용성이 높지 않고 복제도 발생하지 않는다.

DNS

Domain Name Service 는 사람이 이해할 수 있는 호스트 이름을 대상 서버 IP 주소로 변환하는 역할이다.

Route 53

Route 53은 고가용성이 높고, 확장 가능하며, 완전히 관리되는 권위 있는 DNS 서비스이다.
권위적이다 라는 것은 고객이 DNS Record를 업데이트 할수 있다는 뜻.

Route 53은 Domain Registrar 로 사용된다.
Resource의 상태를 확인할 수 있는 기능을 제공한다.

Record Type

A 는 호스트 이름을 IPv4 로 매핑
AAAA 는 호스트 이름을 IPv6 로 매핑
CNAME 는 호스트 이름을 다른 호스트 이름에 매핑
NS 는 호스팅 존의 Name Server

Hosted Zones

Hosted Zones 는 도메인 및 하위 도메인에 대한 Traffic Routing 방법을 정의하는 Record를 포함하는 컨테이너

Public Hosted Zone은 인터넷에서 Traffic 을 Routing 하는 방법을 지정하는 Record 를 포함한다.

Private Hosted Zone은 하나 이상의 VPC 내에서 Traffic 을 Routing 하는 방법을 지정하는 Record를 포함한다.

Records TTL

Routing Polices

트래픽을 Routing 하는 LB의 Routing 과는 다르다.
DNS 는 Traffic을 Routing 하지 않으며 단지 DNS 쿼리에 응답하는 역할을 한다.

Simple 이다.
일반적으로 Traffic을 단일 리소스로 보내는 방식이다.
여러 값이 반환되면 그중에 하나를 임의로 선택하다.

Weighted 기반 이다.
각 특정 리소스로 전송되는 요청의 % 를 제어한다.
각 Record 에 상대적인 가중치를 할당한다.

Latency Based Routing이다.
지연 시간이 가장 짧은 즉 가장 가까운 리소스로 Redirect 하는 정책이다.
사용자의 지연시간이 우선 순위인 경우 매우 유용한 정책이다.
지연 시간은 사용자와 AWS 지역 간의 Traffic 을 기반으로 한다.

Failover 장애 조치 Routing 이다.
Amazon Route 53 과 Health Check 를 사용한다.

Geolocation Routing 이다.

GeoProximity 지리 근접 ROuting 이다.
사용자와 리소스의 지리적 위치를 기반으로 Traffic을 라우팅한다.

Amazon S3

Amazon S3 는 무한하게 확장할 수 있는 Storage 로 소개되고 있음.

Buckets

Amazon S3 는 파일을 Bucket에 Object 를 저장한다.
Bucket 이름은 전체 지역과 계정에서 전역적으로 고유한 이름을 가져야한다.

Object

객체는 키를 가지고 있다.
키는 전체 경로를 의미한다.
S3 그 자체로는 Directory 의 개념은 없다.

Security

// User-Based
IAM Policies - IAM 에서 특정 사용자에 대해 허용되어야 하는 API 호출 지정

// Resource-Based

Bucket Policies - S3 콘솔에서 직접 할당 할 수 있는 전체 버킷 큐칙

IAM Princiapl 이 S3 객체에 엑세스 하려면 사용자 IAM 권한이 허용하거나 리소스 정책이 허용해야 한다. 명시적인 거부가 없어야한다.

S3 Bucket Policies

Static Website Hosting

S3는 정적 웹사이트를 호스팅하고 인터넷에서 엑세스할 수 있게 만들 수 있다.

Versioning

S3에서 파일을 Version 관리 할수 있따.
버전 관리는 버킷 수준에서 활성화 된다.
동일한 키를 덮어쓰면 버전이 변경된다.
버킷에 버전 관리를 적용하는 것이 좋은 방법이다.

Replication(CRR & SRR)

소스 버킷과 복제 대상 버킷에서 둘 모두 버전 관리 기능이 활성화 되어야 한다.
CRR 은 교차 리전 복제 이고 SRR 는 같은 리전으로 복제이다.
복제는 비동기적으로 진행된다.
S3 에 적절한 IAM 권한을 부여해야한다.

Requester Pays

일반적으로 버킷 소유자는 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 담당한다. 근데 요청자가 비용을 담당하는 Requester Pays 버킷의 경우, 버킷 소유자 대신 요청자가 요청 및 버킷에서 객체 데이터 다운로드 비용을 지불한다.

S3 Event Notifications

S3 Event Notifications with Amazon EventBridge

JSON 규칙을 사용한 Advanced Filtering 옵션

Multi-Part Upload

업로드를 병렬화 하여 전송 속도를 높여 대역폭을 최대화 할수 있다.
모든 파트가 업로드 되면 자동으로 모든 파트를 다시 합쳐 다시 하나의 큰 파일로 만든다.

S3 Transfer Acceleration

파일을 AWS Edge Location 으로 전송하고 해당 데이터를 대상 지역의 S3 버킷으로 전달한다.
Multi Part Upload 와 호환된다.

S3 Byte Range Fetches

특정 바이트 범위를 요청함으로써 GET을 병렬화하여 수행한다.
특정 바이트 범위를 가져오는데 실패한 경우에도 더 작은 바이트 범위에서 재시도 한다. 따라서 실패의 경우에도 복원력이 높다.
다운로드 속도를 높일수 있다.

S3 Select & Glacier Select

Server-side filtering 을 통해 SQL 을 사용하여 데이터의 일부를 검색할 수 있다.
간단한 SQL 문을 사용하여 행 및 열로 필터링 할수 있다.

S3 Batch Operation

단일 요청으로 기존 S3 객체에 대한 대량 작업을 수행하는 서비스

S3 Inventory 를 사용하여 객체 목록을 가져오고 S3 Select를 사용하여 객체를 필터링 한 후 S3 Batch Operations 에 수행할 작업, 매개 변수와 함께 객체 목록을 전달하면 S3 배치가 작업을 수행하고 객체를 처리한다.

Encryption

S3 에서는 4가지 방법으로 S3 버킷의 객체를 암호화 할수 있다.

Server-Side Encryption(SSE) 와 Client-Side Encryption(SSE-C) 로 나뉜다.

Server-Side Encryption 에는 Amazon S3 관리형 키를 사용하는 SSE-S3 와 AWS KMS 키를 사용하는 SSE-KMS 그리고 고객이 제공하는 키를 사용하는 SSE-C 가 있다.

Client-Side 는 그자체

SSE-S3

AWS 에서 처리,관리,및 소유하는 키를 사용하여 암호화 한다.
객체는 서버 측에서 암호

SSE-KMS

KMS 키를 통해 처리되고 관리되는 키를 사용하여 암호화 한다.
사용자가 키를 제어할수 있고 CloudTrail 을 사용해서 키 감사한다.
객체는 서버 측에서 암호화 한다.

근데 KMS 제한 사항에 영향을 받을수 있다.
업로드/다운로드 할때 API를 호출한다. KMS 서비스에 API 호출을 수행해야 하는데 API 호출은 초당 KMS 초당 할당량에 포함된다.

그래서 처리량이 매우 높은 S3 버킷이 있고 모든 파일이 KMS 키로 암호화 되어 있다면 스로틀링 오류 등의 사례가 발생할 수 있다.

SSE-C

키는 AWS 외부에서 가지고 있지만 AWS 로 키를 보내기 때문에 서버측 암호화다.
Amazon S3는 제공된 암호화 키를 저장하지 않는다.

Client-Side Encryption

Client 는 데이터를 S3로 전송하기 전에 직접 암호화해야한다. S3에서 검색할떄 직접 데이터를 복호화 해야한다..

CORS

Cross-Origin Resourse Sharing 이다.
웹 브라우저에서 메인 오리진을 방문하면서 다른 오리진으로의 요청을 허용하기 위한 기능이다.

요청 Protocol 의 일부로 다른 웹사이트에 요청을 보내야할 떄 다른 오리진이 CORS Headers를 사용해서 요청을 허용하지 않는 한 해당 요청은 이행되지 않는다.

S3 Access Logs

감사 목적으로 S3 Bucket의 모든 Access 를 Logging 할수 있다.
승인 또는 거부 여부와 상관없이 모든 계정에서 S3 에 대한 요청이 로그로 남는다.

Pre-Signed URLs

S3 콘솔, AWS CLI 또는 SDK 를 사용해서 생성할 수 있는 URL 이다.
미리 서명된 URL을 받은 사용자는 GET/PUT에 대한 권한을 URL 을 생성한 사용자로 부터 상속받는다.

로그인한 사용자만 S3 Bucket 에서 프리미엄 비디오를 다운로드 할수 있도록 허용한다.
URL을 동적으로 생성하여 계속 변경되는 사용자 목록이 파일을 다운로드 할수 있도록 허용한다.

S3 Glacier Vault Lock

WORM 모델은 Write Once Read Many 이다.
Vault Lock 정책 생성한 다음 향후 편집을 위해 정책을 잠군다.

Object Lock

지정된 기간 동안 특정 객체 버전 삭제되는 것을 차단한다.
객체 잠금은 전체 S3 버킷 수준의 잠금 정책이 아니라 버킷 내의 모든 객체에 각가 적용할 수 있는 잠금이다.

모드가 2개가 있는데 compliance 인 규정 준수는 루트 사용자를 포함한 어떤 사용자도 객체 버전을 덮어쓰거나 삭제할수없다.

Governance 인 거버넌스 는 대부분의 사용자는 객체 버전을 덮어쓰거나 삭제하거나 잠금 설정을 변경할수 있따.

규정 준수는 누구도 객체를 삭제할수 없지만 거버넌스는 일부 사용자가 삭제가 가능하다.

S3 Access Points

각 엑세스 포인트마다 고유 DNS 이름과 정책을 가지고 있다. 이를 통해 사용자나 그룹의 엑세스를 제한 할수 있다.

사진 처럼 Finance 의 유저는 Finance Access Point 를 통해서 /Finance 에만 접근을 할수 있게 한다는 뜻.

S3 Objcet Lambda

AWS S3 Object Lambda는 Amazon S3의 새로운 기능 중 하나로, S3 객체에 대한 실시간 데이터 변환을 수행하는 서비스입니다.

AWS Lambda 함수를 사용하여 호출한 Applicatoin이 객체를 회수하기 전에 객체를 수정한다.

한개의 S3 Bucket 만 필요하며 S3 버킷 상위 수준에 S3 엑세스 포인트를 생성하고 Lambda 함수와 연결한다.

CloudFront

Content Delivery Network 이다
컨텐츠를 서로 다른 Edge Location에 미리 캐싱하여서 읽기 성능을 향상시킨다.
DDOS 공격에서 보호받을 수 있으며 Shield,AWS Web Firewall 과 통합해서 사용할수 있다.

먼저 전 세계에 퍼져있는 CloudFront의 엣지가 있고 연결한 원본(S3 or HTTP) 가 있다.
Client 가 연결해서 Edge Location에 HTTP 요청을 보내면 Edge는 이것이 캐싱되어 있는지 확인한다.
캐싱되어 있지 않은 경우에는 원본으로 가서 요청 결과를 가져오고 이를 로컬 캐시에 저장해서 다른 클라이언트가 같은 컨텐츠를 같은 엣지에서 요청할 시 사용한다.

S3 as an Origin

어떤 Region 에 있는 S3 Bucket 이 원본이다. 전 세계에 Edge Location 이 있다. LA 가 예시

LA Edge에 접근하는 사용자는 LA Edge가 직접 Content 를 제공하게 된다. 하지만 먼저 내부 AWS 망을 통해 S3 Bucket Origin 을 받아온다.

CloudFront vs Cross Region Replication

//CloudFront
파일은 TTL 동안 캐싱된다.
전세계적으로 사용 가능한 정적 컨텐츠에 적합하다.

//S3 Cross Region Replication
각 복제를 원하는 리전마다 설정해야한다.// 전세계 대상이 아님
파일은 거의 실시간으로 갱신된다.
일기 전용
일부 리전을 대상으로 동적 컨텐츠를 낮은 지연 시간으로 제공할떄 적합

결국 Cloud Front 는 전세계에 걸친 컨텐츠 전송 네트워크 이고 S3 교차 리전 복제는 다른 리전으로 버킷을 복제하는것.

ALB or EC2 as an Origin

ALB 는 퍼블릭으로 설정되어야 한다.
Ec2 는 Private 으로 해도 된다. LB와 Instance 사이에 가상 Private Network 가 설정 되어 있기 때문.
EC2가 LB의 Security Group 을 허용해주면 된다.
Edge Location 으로 접근하기 때문에 APplication 의 공용 IP가 LB의 보안 그룹 정책에 허용 되어야 한다.

AWS Global Accelerator

Application 은 한 리전에 배치되어 있지만 사용자들은 전세계적으로 걸쳐있다.
사용자들이 Application 접근할떄는 공용 Internet 을 통하게 되는데 Router 거치는 동한 수많은 홉으로 인해 지연 발생할수 있다.
그래서 Global Accelerator 사용한다.

Unicast IP 는 하나의 서버가 하나의 IP 주소를 보유하는것이고
Anycast IP 는 모든 서버가 동일한 IP 주소를 가지며 Client 는 가장 가까운 서버로 Routing 된다.

가장 가까운 Edge Location 으로 Traffic 전송하고 Edge Location 은 안정적이고 지연시간이 적은 AWS Network 를 거쳐서 Application LB로 Traffic을 전송한다.

Global Accelerator vs CloudFront

둘다 Global Network 를 사용하고 Edge loaction 을 사용한다.
Shield 와 통합해서 DDOS 보호를 제공한다.

CloudFront 는 캐시가 가능한 Content의 성능을 개선함
API 가속 및 동적 사이트 전달과 같은 동적 Content에도 적용된다

Global Accelerator 는 TCP 또는 UDP 를 통해 Applicatoin 성능을 개선한다.

Amazon FSx

타사 고성능 파일 시스템을 실행하는거다.
S3,EFS 가 아니라 다른 File System 을 사용하고 싶을때 사용한다.
RDS 에서 AWS 에 MYSQL 이나 Postgres 를 실행하는 것과 같은 개념이다. RDS 가 FSx로 바뀌었고 파일 시스템을 실행한다는 점이 다르다.

Amazon FSx for Window(File Server)

완전 관리형 Window 파일 시스템 공유 드라이브다.
SMB 와 NTFS 를 지원한다.

Amazon FSx for Lustre

Lustre 는 Linux 와 cluster 를 합친 말이다.
원래는 대규모 컴퓨팅을 위한 분산 파일 시스템으로 쓰였다.
고성능 연산에 사용된다고 한다.

Amazon FSx for NetAPP ONTAP

AWS 의 관리형 NetAPP ONTAP 파일 시스템

Amazon FSx for OpenZFS

OpenZFS 파일 시스템

AWS Storage Gateway

AWS 는 Hybrid Cloud 를 권장한다. 일부는 AWS 에 있고 일부는 On-Premis 에 있는것.

S3는 EFS/NFS 와 다르게 독점 Storage 라고 한다. 이 S3 데이터를 On-Premis 에 두려면 어떻게 해야하나?

그때 사용하는게 Storage Gateway 이다.
S3 와 On-Premis infra 를 연결하면 된다.

결국 온프레미스 데이터와 클라우드 데이터 간의 연결을 제공한다.

Amazon S3 File Gateway

NFS 및 SMB protocol 을 사용해서 구성된 S3 Bucket에 엑세스할수있다.
Life Cycle Policy 를 사용해서 S3 Glacier 로 전환 가능하다.
각 File Gateway에 대한 IAM Role 을 사용하여서 Bucket 엑세스 설정한다.

Amazon FSx File Gateway

Amazon FSx for Window 파일 서버에 대한 네이티브 엑세스 제공한다.

Volume Gateway

ISCSl Protocl 을 사용하여서 S3를 백업으로 하는 Block Storage
온프레미스 Volume 복원에 도움이 되는 EBS 스냅샷을 지원.

Tape Gateway

일부 회사들은 물리적 테이프를 사용한 백업 프로세스를 가지고있다.
Tape Gateway를 사용하면 회사들은 테이프 대신 Cloud를 활용해 백업할 수 있게 된다.

Storage Gate way -Hardware Appliance

Storage Gateway 를 사용하려면 온프레미스 가상화가 필요하다.
온프레미스 Server 가 없는 경우 Storage Gateway 하드웨어 어플라이언스를 사용할수 있다.
미니 서버가 될 하드웨어 어플라이언스를 인프라에 설치한 후 게이트웨이로 설정하면 된다.
소규모 데이터 센터의 일일 NFS 백업 처럼 가상화가 없는 경우 상당히 유용하다.

AWS Transfer Family

Amazon S3 또는 EFS 안팎으로 파일 전송을 위한 완전 관리형 서비스다.

AWS DataSync

대용량의 데이터를 한 곳에서 다른 곳으로 옮김
온프레미스/다른 클라우드 에서 AWS로 데이터 이동 한다 이때 DataSync 에이전트 필요하다.
AWS 서비스 간 데이터 이동 한다.

Integrating Message

어플리케이션 간의 동기적인 통신은 Traffic 의 갑작스러운 증거가 발생할 경우 문제가 될 수있다. 에를들어 평소에는 10개의 동영상을 인코딩 하는 서비스가 1000개의 비디오를 인코딩하는 경우, 인코딩 서비스가 압도될 것이고 운용이 정지될 것이다.

이런 경우 Application 을 분리하고 SQS,SNS,Kinesis 를 사용하는것이 좋다.

SQS 는 대기열 모델 사용,SNS 는 Pub/Sub 모델 , Kinesis 는 실시간 스트리밍을 하고 대용량 데이터를 다루는 경우

Amazon SQS

대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 한다.

SDK 사용해서 SQS 에 메세지 생성

메세지를 가져오기 위해 SQS 폴링한다.
메세지를 처리하고 DeleteMessage API를 사용하여 메세지를 삭제한다.

병렬로 수신하고 처리할수도 있다.
최소 한번의 전송을 보장하고 순서를 보장할수 있따.

SQS with Auto Scaling Group

ASG 는 일종의 Metric 에 따라 확장되어야 하는데 이때 사용하는 Metric 은 대기열의 길이로 할수있다.
SQS QUeue 의 대기열 크기가 특정 수준을 넘어가면 CloudWatch Alarm을 설정하면 된다.

Website에 오더가 폭주해서 ASG 이 더많은 EC2 인스턴스를 제공하면 메세지들을 더 높은 처리량으로 처리할 수 있게 된다.

SQS to decouple between application tiers

SQS 는 Application 계층 간에 분리를 위해 사용된다.

프론트에서 S3 Bucket 에 삽입하는데 처리 시간이 매우 오래 걸릴 수 있다. 웹사이트 속도가 느려질수 있다.

Application 을 분리하여 파일 처리 요청과 실제 파일 처리가서로 다른 어플리케이션에 발생할 수 있도록 할수 있다. 파일 처리 요청을 받을 때 마다 SQS 대기열로 메세지를 전송하면 된다.

Message Visibility Timeout

소비자가 메세지를 폴링하면 그 메세지는 다른 소비자에게는 보이지 않게 된다.

가시성 시간 제한 기간 내에는 메세지는 다른 소비자에게 보이지 않고, 가시성시간 제한이 초과되고 메세지가 삭제되지 않았다면 메세지는 대기열에 다시 넣어진다.

메세지가 가시성 시간 제한 내에 처리되지 않으면 메세지는 두번 처리될수도 있다.

FIFO Queue

처리량 제한이 있다
중복 메세지를 제거하여 정확하게 한번만 전송 가능하다.
소비자에 의해 메세지는 순서대로 처리된다.

Amazon SNS

메세지 하나를 여러 수신자에게 보낸다고 가정한다.

직접 통합을 쓸수 있는데 구매 서비스 애플리케이션을 예로 이메일 알람을 보내고 사기 탐지 서비스,배송 서비스,SQS 대기열에도 메세지를 보낼수 있따.

게시,구독을 사용해서 구매 서비스가 메세지를 SNS 주제로 전송할 수 있다.

이벤트 생산자는 한주제에만 메세지를 보낸다.
이벤트 수신자는 해당 주제와 관련한 SNS 알림을 받으려는 사람이다.
주제에 대한 구독자는 모든 메세지를 수신한다.

SNS + SQS : Fan Out

메세지를 여러 SQS 대기열에 보내고 싶은데 모든 SQS 대기열에 개별적으로 메세지를 보내면 문제가 발생할 수 있다. 애플리케이션이 비정상적으로 종료 될수도 있고 전송에 실패하거나 SQS 대기열이 추가될수도 있다.

SNS 주제에 메세지를 전송한 후 원하는 수의 SQS 대기열이 SNS 주제를 구독하게 하는것.

S3 Events to multiple queues

이벤트 세 개를 여러 대기열에 넣는 경우다.
여러 대기열에 동일한 S3 이벤트를 보내고 싶다면 팬아웃 패턴을 사용해야한다.

Message Filtering

SNS 주제의 구독으로 전송되는 메세지를 필터링 하기 위해 JSON 정책을 사용한다.
구독에 필터링 정책이 없는 경우,해당 구독은 모든 메세지를 수신한다.

Amazon Kinesis

Kinesis 를 활용하면 실시간 스트리밍 데이터를 쉽게 수집하고 처리하여 분석할 수 있다.

Kinesis Data Streams

데이터 스트림을 갭처, 처리 및 저장

Kinesis Data Firehose

데이터 스트림을 AWS 데이터 저장소로 로드

Kinesis Data Streams vs Firehose

SQS vs SNS vs Kinesis

Docker

앱을 배포하기 위한 소프트웨어 개발 플랫폼
컨테이너에 패키지화 되어 어떤 운영 체제에서든 실행할 수 있게 된다.

마이크로서비스 아키텍쳐,온프레미스에서 AWS Cloud 로의 앱 이동에 사용 된다.

Docker on an OS

다수의 도커 컨테이너가 동시에 실행될 수 있어서 Java 혹은 Node.js 애플리케이션을 가진 도커 컨테이너가 있을수 있다.
도커 내에서 MySQL DB 도 실행 가능

Docker vs Virtual Machines

//Virtual Machines

EC2 의 원리이다. 하이퍼 바이저에 실행되는 가상 머신과 같다.
가상 머신의 EC2 Instance 는 각자 분리되어 있다.
리소스를 공유하지 않는다.

// Docker

도커 Daemon 에서 가볍게 실행되는 컨테이너라 공존할 수 있다.
가상머신보다 덜 안전하지만 하나의 서버에 많은 컨테이너를 실행할 수 있기 때문에 도커 컨테이너를 많이 사용한다.

Amazon ECS

Elastic Container Service 이다.
ECS Cluster 에서 ECS Task 를 실행하여 AWS 상에서 Docker 컨테이너를 실행할 수 있다.

ECS Launch Type 으로 ECS 클러스터를 사용할 떄는 인프라를 직접 프로비저닝하고 관리해야 함

Fargate Launch Type

Docker 컨테이너를 AWS 에서 실행하는 또 다른 옵션
인프라를 직접 프로비저닝하거나 관리할 필요가 없다.
서버리스 이다.

IAM Roles for ECS

Amazon ECR

Elastic Container Registry 이다.
AWS에 도커 이미지를 저장하고 관리하는데 사용 된다.

Amazon EKS

Serverless

서버가 없는게 아니라 서버를 관리할 필요가 없는것.
단지 코드를 배포하고 함수를 배치하기만 하면 된다.

AWS Lambda

관리할 서버가 없고 짧은 실행 시간을 가지고 온디맨드로 호출 시 실행된다. 스케일링 자동화 이다.

AWS 전체 서비스와 통합 가능하고 다양한 프로그램이 언어 사용 가능하다
Cloudwatch 로 쉬운 모니터링 가능하다.

Lambda@Edge & CloudFront Functions

모던 어플리케이션에는 어플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요규하딕도 한다.

Lambda in VPC

Lamba 함수는 사용자 VPC 가 아닌 AWS VPC 에 실행된다. 그래서 VPC 내 리소스에 엑세스할 수 없다.
그래서 사용자 VPC에서 Lambda 를 시작하면 된다.

사욪아 VPC 에서 Lambda 함수를 시작하려면 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야한다. Lamba 는 사용자의 서브넷에 ENI 를 생성한다.

Lambda with RDS Proxy

Lambda 함수가 DB에 직접 엑세스 하게 되면 RDS DB의 로드가 상승해 시간 초과 의 문제가 이어짐 그래서 RDS 프록시 사용한다.

Amazon DynamoDB

관리형 DB 이다.
다중 AZ 간 데이터 복제를 통해 고가용성 제공한다.
대규모 워크로드로 확장 가능한 분산 데이터베이스이다.

Dynamo Accelerator(DAX)

DynamoDB를 위한 완전 관리형 무결절 인메모리 캐시이다.
DynamoDB 테이블에 읽기 작업이 많을때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다.

DAX vs ElastiCache

집계결과 저장할떄는 ElastiCache 가 좋고 대용량의 연산을 저장할 떄에는 DynamoDB가 좋다.

Amazon DynamoDB에 캐싱 솔루션을 추가할때는 보통 DAX 쓴다.

Stream Processing

스트림 처리는 데이터의 변경 사항을 실시간으로 감지하고 이를 처리하는 기술.

실시간 변경 사항에 대흥,실시간 사용 분석 등.

DynamoDB Global Table

여러 리전 간에 짧은 지연 시간으로 엑세스 할 수 있도록 하는 기능

Integration with Amazon S3

S3 로 내보내기 된다.PITR 기능 활성화 해야한다. 그리고 Athena 로 데이터 분석 수행 가능 하다.

S3 에서 데이터를 가져와서 DynamoDB에 새로운 테이블로 임포트한다.

AWS API Gateway

HTTP Endpoint 뿐만 아니라 사용량 계획,개발 단계 등의 기능을 제공한다.
API Gateway 를 사용해서 AWS Serverless Service 로 REST API 를 생성할수 있으므로 클라이언트가 Public 엑세스 할수 있게 된다.

AWS Lambda + API Gateway 로 서버리스이다.

CloudWatch

Cloudwatch 는 AWS 의 모든 서비스에 대한 지표를 제공한다.

CloudWatch Metric Streams

CloudWatch 지표를 선택한 대상으로 지속적으로 스트리밍 하면 거의 실시간으로 전송되고 지연 시간을 짧아진다.

Amazon EventBridge

이번에 이름은 CloudWatch Event 였다.

대상이 다양하다면 labmda 함수를 트리거해서 SQS,SNS 메시지 등을 보낼 수 있따.

Amazon EventBridge Rules

Resuorce-based Policy

특정 이벤트 버스에 대한 권한을 관리할 수 있다.
AWS 계정이나 다른 지역에서의 이벤트 수신을 허용 또는 거부할수 있다.

AWS CloudTrail

AWS 계정의 거버넌스,규정 준수 및 감사를 제공하는 서비스.
CloudTrail 은 기본적으로 활성화 되어 있다.

AWS COnfig

AWS 리소스의 감사 및 규정 준수 여부를 기록할 수 있게 해주는 서비스
시간에 따른 구성 및 변경 사항 기록을 지원한다.

Config Rules

AWS 에서 사전 정의된 Config 규칙