자격증/AWS
AWS Associate 자격증 공부 요약 (SAA-C02)
게킴의 블로그
2022. 11. 14. 13:34
section 1 ~ section 3
1. 리전 & 가용영역
-
리전을 선택하는 기준
1) complience (준수)
: 데이터가 프랑스에 저장되어야 하는 법이 있다면 프랑스가 리전이어야 함
2) proximity (근접)
: 지연시간을 줄이기 위해, 데이터를 사용하는 사용자가 미국에 많으면 미국을 선택
3) 배포하고자 하는 서비스가 그 리전에 있는가
4) Pricing (가격) : 리전마다 가격이 다름
-
가용영역은 대체로 하나의 리전 당 일반적으로 3개 존재함 (최소 2 ~ 최대 6)
ex ) ap-southeast-2a , ap-southeast-2b, ap-southeast-2c 가용영역 내 데이터센터가 둘 이상 존재할 수 있음
2.AWS 관리 콘솔
Global infrastructure (글로벌 인프라) - 각 리전에서 어떤 서비스를 사용할 수 있는지 검색 가능함
section 4
1. IAM & MFA
1) IAM 란?
: ID Access Management (ID와 Access 관리)
- 유저, 또는 그룹은 JSON 형식의 정책 문서로 권한 할당
- 정책은 사용자의 권한을 의미함 (특정 서비스를 이용할 수 있도록 권한 허용/ex) ELB, Cloudwatch, EC2 사용 권한)
즉, 모든 사용자들이 모든 서비스를 이용할 수 있진 않음
-> 돈절약, 보안에 좋음
- 최소한의 권한만 준다. (사용자가 원하는 권한 외에는 주지 않는다)
* Root 계정 : 맨 처음 default 계정, 공유되어서는 안 되는 계정
-> 초기 IAM 사용자를 만들 때만 사용하도록 권장, 이후 동작은 IAM 사용자를 통해서만 하게
* Users : 조직 내 한 사람, user를 그룹화할 수 있음, 한 사용자는 여러 그룹에 속할 수 있음 (그룹에 들지 않는 것도 O)
* 그룹 : 사용자만 속할 수 있음, 다른 그룹에 속할 수 없음.
- 관리자 그룹 내의 단일 사용자는 AWS에 대한 관리자 액세스 권한이 필요함
-> 그룹명 : admin / 그룹 권한 : Administrator Access
- 어찌저찌 사용자 생성 하면 콘솔 로그인이 가능한 URL을 줌. 그 URL 주소는 커스텀이 가능
-> 이메일로 받은 주소로 받거나, 저 주소로 받거나
-> 이 사용자 로그인은 Root 로그인 아니고 IAM 로그인으로 함
2) IAM 역할
서비스에 역할을 부여
대표 서비스 : EC2/Lamda
*EC2 인스턴스에 대해 read only 권한을 줄 수 있음
(cli 를 통해 user list 를 볼 수 있게 권한 설정)
IAM 보안 Tool 도구
- IAM 자격 증명 보고서
- IAM Access Advisor
사용자에게 부여된 권한, 액세스 시간 등을 보여줌
2. IAM Password Policy 방법 2가지
1) 암호 정책 설정
- 암호 최소 길이
- 특정 문자 유형 (대소문자, 특수문자)
- 패스워드 변경 주기
- 비밀번호 재사용
- IAM 사용자를 허용할 것인가?
* AWS 콘솔 >
패스워드 정책 설정
IAM - Account Setting - Change Password Policy
2) MFA (Multi Factor Authentication)
AWS에서 인증할 때 쓰임
- 비밀번호
- 사용자 소유의 보안 장치 필요
장점 : 비밀번호를 도난당해도 보안에 문제 없음!
* MFA Device Option
- Virtual MFA Device (Google OTP, Authy) 가상 장치
: 많은 사용자를 가질 수 있음 (루트, IAM 사용자, 다른 계정, 다른 IAM 사용자)
- Universal 2nd Factor (U2F) Security Key
: 물리적 장치. (Yubikey). 여러 루트 사용자를 가질 수 있음
- Hardware Key Fob MFA Device (열쇠고리 같이 생김)
- AWS Gov Cloud (정부에서 쓰는 경우)
* AWS 콘솔 >
MFA
내 보안 자격증명(dmy security credentials) - Acticate MFA
2. AWS에 Acces 하는 세 가지 옵션
- AWS Management Console (웹UI, 패스워드 보호 + MFA)
- AWS CLI (Command Line Interface) : Access key로 보호됨
- AWS SDK (Software Developer Kit) : API 호출
라이브러리 세트임
프로그래밍 방식으로, 프로그래밍 언어에 따라 다름
터미널 내에서 사용하지 않고 어플에서 코딩함
동일한 Access Key 값으로 위 세가지에 접근한다.
Access Key는 비밀번호처럼 공유되면 안됨.
Access Key = username
Secret Access Key = password
section 5
1. EC2 란?
- AWS에서 가장 인기있는 서비스
- Elastic Compute Cloud
- IaaS (Intrastructure as a service)
- 온디맨드 방식
1) EC2에 포함된 구성 기능
- EC2 가상 머신을 임대할 수 있음
- EBS 볼륨 또는 가상 드라이브에 data 저장
- 시스템 간 부하 분산 (ELB)
- 서비스 확장 (ASG 오토스케일 그룹)
2) 구성 옵션
- OS : Linux, Window, Mac OS
- CPU
- RAM
- Storage
EBS/EFS 네트워크 스토리지
하드웨어 (EC2 Storage)
- 네트워크 유형, public ip 주소
- 보안 그룹
- 부트스트랩 -> User Data (EC2 시작 시 구성)
3) 부트스트랩
- 부트 작업을 자동화 하기 위해 User Data 스크립트를 실행
- EC2 시작때 실행되는 스크립트임
- 처음 한 번만 실행됨
4) EC2 Type
t2.micro 무료 한달 750시간: 1vCPU / 1GB Mem / EBS
- 인스턴스 타입 이름 규칙
m5.2xlarge
m : instance class
5 : generation (AWS 하드웨어 버전, 더 향상되면 6이 출시될거임)
2xlarge : 크기, 크기가 클 수록 메모리 커
(1) Compute 최적화 옵션 - C 시리즈
(2) Memory 최적화 - R 시리즈
고성능 : 관계/비관계형 데이터베이스
분산형 캐시 저장?
(3) 스토리지 최적화 -I, G, H ( 기억 안해도 됨)
- 프로비저닝된 IOPS 볼륨은 일관되고 지연 시간이 짧은 스토리지를 제공하며 대규모 관계형 또는 NoSQL 데이터베이스와 같은 I/O 집약적 애플리케이션을 위해 설계되었습니다.
- 마그네틱 볼륨은 모든 EBS 볼륨 유형 중 가장 낮은 기가바이트당 비용을 제공하며 데이터에 자주 액세스하지 않는 워크로드 및 가장 낮은 스토리지 비용이 중요한 애플리케이션에 이상적입니다.
2. 보안 그룹
- 트래픽 흐름 제어, EC2 방화벽임
- 보안 그룹 간 서로 참조 가능
- 여러 인스턴스 연결 가능(일대일 아님)
- 여러 보안 그룹 생성 가능. 근데 다른 지역으로 가면 보안 그룹을 새로 만들어야 함
- default 룰은 인바운드 트래픽 다 차단/아웃바운드 다 허용임
* 기본 포트는 알고 가자
22 : SSH ( Secure Shell)
21 : FTP (File Tranfer Protocol)
80 : HTTP
443 : HTTPS
3389 : RDP
3. 인스턴스 시작 유형 (중요!!!!! - 차이점 알 것)
1) 예약 인스턴스 Reserved Instance : 긴 작업일 경우
- 그냥 Reserved Instance :일반적인 예약 인스턴스
- Convertible Reserved Instance : 전환 가능한 인스턴스. 시간이 지나서 유형 변경 가능
- Scheduled Reseved : 1년동안 쓰지만 매주 목요일에 필요
- 할인이 있음
- 부분 선결제, 전체 선결제 있음
- 특정 인스턴스 유형을 예약해야 함( 안정적인 상태로 운영될 때)
## 미리 예약해서 숙박 (아주 오랫동안 머물러야 할 때 장기 예약하고 할인 받음)
새 인스턴스 유형으로 변경한 후, 기간 만료 전에 프로젝트를 종료한 후, 비즈니스 요구 사항이 변경될 때 또는 필요하지 않은 용량이 있는 경우
예약 인스턴스 마켓플레이스에서 인스턴스를 판매할 수 있습니다.
2) Spot Instance : 워크로드 짧고 저렴
- 가장 높은 할인을 줌 (90 %)
- 언제든 잃을 수 있는 인스턴스임 (중요한 작업은 이거 노노)
## 호텔주가 방을 비울 수 없어서 싸게 할인해서 숙박받게 해줌
더 비싼돈 준 사람 나오면 내쫓을 수 있다
3) 온디맨드
- 사용한 만큼 지불, 전형적인 클라우드임
- 비용이 많이 들지만 선불 아님
- 장기 약정기간 없음 (단기 사용임)
- 서버 중단이 없고 동작 예상이 가능할 때
## 원할 때 호텔에 가격 지불해서 숙박
4) Dedicated Host (전용 호스트)
- 물리 서버임 (AWS IDC에서 임대함)
- Server-bound Software Licenses : 사용자의 기존 제품을 사용할 수 있도록 하여 비용을 절감함
- 자신의 라이선스를 가져와야 할 때
- 기존 소프트웨어나 복잡한 라이선스 모델이 있을 때
## 호텔 건물 자체를 예약
5) Dedicated Instance (전용 인스턴스)
- 하드웨어에서 실행되는 EC2 인스턴스
- 하드웨어를 다른 인스턴스와 공유 가능
* 전용 호스트는 호스트 당, 전용 인스턴스는 인스턴스 당 청구받음
4.Auto Scaling 조정 정책 유형
대상 추적 조정 - 특정 메트릭에 대한 대상 값을 기반으로 그룹의 현재 용량을 늘리거나 줄입니다. 이것은 온도 조절기가 집의 온도를 유지하는 방식과 유사합니다. 온도를 선택하면 나머지는 온도 조절기가 알아서 합니다.
단계 조정 - 경보 위반의 크기에 따라 달라지는 단계 조정 이라고 하는 조정 조정 세트를 기반으로 그룹의 현재 용량을 늘리거나 줄 입니다.
단순 조정 - 단일 조정 조정을 기반으로 그룹의 현재 용량을 늘리거나 줄입니다.
Auto Scaling 그룹의 인스턴스 수에 비례하여 증가하거나 감소하는 활용 메트릭을 기반으로 조정하는 경우 대상 추적 조정 정책을 사용하는 것이 좋습니다. 그렇지 않으면 대신 단계 조정 정책을 사용하는 것이 좋습니다.
예약된 조정 - 예측 가능한 로드 변경에 대한 자체 조정 일정을 설정할 수 있는 일정을 기반으로 조정
section 6
1. Private vs Public vs Elastic IP
- private ip : 사설 네트워크에서만 고유함 (다른 회사는 동일한 사설 ip 를 가질 수 있음) , NAT / Proxy (Internet GW) 으로 인터넷 연결함
- elastic ip : 삭제하지 않는 한 인스턴스는 이 ip를 유지함
1. Placement Groups (배치 그룹)
인스턴스가 함께 그룹화되는 위치에 따라 다름
1) 클러스터 배치 그룹 (동일한 하드웨어)
: 단일 가용 영역 내에 있는 논리적 그룹
동일한 하드웨어를 의미하는 동일한 랙에 위치, 동일한 가용 영역
짧은 네트워크 지연 시간, 높은 네트워크 처리량
하드웨어 장애 발생 시 모든 ec2 인스턴스가 고장남
2) 분산형 배치 그룹 (<-> 클러스터)
: 각각 고유한 랙에 배치된 인스턴스 그룹
가용 영역 당 최대 7 개 인스턴스
랙마다 자체 네트워크 및 전원이 있음 (진ㅉㅏ 랙)
서로 떨어져있어야 하며, 중요 인스턴스 수가 적은 경우
3) 파티션 배치 그룹
: 배치그룹 내 각 파티션으로 나눔 (두 파티션은 동일한 물리적 하드웨어를 공유하지 않는다. )
가용 영역 당 최대 7 파티션
인스턴스를 논리적 파티션에 분산해, 한 파티션에 있는 인스턴스 그룹이 다른 파티션의 인스턴스 그룹과 기본 하드웨어를 공유하지 않게 합니다
2. Hibernate (ec2 절전 모드)
- 인스턴스를 다시 시작할 때 최대 절전 모드 후 인스턴스 부팅
(os, 중지 , 다시시작 된 게 아님, 그저 ec2 동면한거임)
RAM 덤프 -> 암호화된 ebs -> ec2 멈춤 -> 다시 시작 시 os 부팅부터 xxxx ebs 볼륨 부터
- 언제 사용할까?
장기 실행 프로세스
ram 상태 저장
시간이 많이 걸리는 서비스
초기화하고 싶지않은 경우
* 모든 인스턴스에 지원3되지 않음 (C 4, 5, 3)
인스턴스 RAM 크기는 150gb 미만이어야 함
* 온디맨드 및 예약 인스턴스에서만 사용 가능함
* 인스턴스는 최대 60일 이상 절전모드될 수 없다.
* 인스턴스 다시시작 할 때 uptime 이 유지됨.
3. EC2 Nitro ( 추가 인스턴스 유형)
- 더 고성능 (더 빠른 EBS 볼륨이 필요한 경우 사용)
64000 IOPS ( 보통은 최대 32000임)
C5, C6, D3, M5
4. vCPU
cpu당 2개의 스레드
4 cpu == 8 스레드 == 8 vCPU
##!! 용량을 미리 예약해야 하는 경우 EC2 용량 예약을 사용하자!!
section 7
1. EBS (Elastic Block Store)
인스턴스에 마운트해서 사용할 수 있고, 인스턴스 종료 후에도 유지하여 사용할 수 있음.
기존 EBS에 새 인스턴스를 연결하면 데이터 유지 가능
- 한번에 하나의 인스턴스 마운트
** 하지만 인스턴스에는 두 EBS 장착할 수 있음
- 가용 영역 : 인스턴스와 연결할 가용영역과 같은 곳이어야 함
- 간단하게 말하면 USB임 하지만 물리적 드라이브가 아님 (네트워크 드라이버임)
- 볼륨 생성 시 원하는 GB 용량을 정의해야 함.
- 인스턴스 종료 시 삭제 할 수 있는 옵션이 있음 (기본적으로 인스턴스 종료시 삭제됨 - root 볼륨에 적용)
* 인스턴스 만들 때 만든 애 : root - 기본적으로 종료 시 삭제 버튼 활성화
* 수동으로 만든 애 : 인스턴스 종료해도 삭제 안 됨
- EBS의 Raid 구성
2. EBS 스냅샷 (Snapshots)
- 볼륨 스냅샷 찍으면 그 스냅샷으로 다른 가용영역에서 동일한 데이터를 사용할 수 있음 (마이그레이션)
3. AMI (Amazon Machine Image)
- EC2를 커스텀할 수 있음
* AWS 에서 제공하는게 있고, 다른 사람이 만든게 있고, 자체 구축할 수 있음
- EBS 볼륨을 스냅샷찍음 -> 다른 가용 영역에서 사용 가능
4. 인스턴스 성능 벌크업
인스턴스 스토어 -> 인스턴스가 하드웨어로 임시 벌크업
- 하드웨어 디스크를 EC2에 연결할 수 있음 . (가상머신이지만 실제 하드웨어 서버에 연결되어 있기 때문에)
더 나은 IO 성능을 위해 사용함 , 높은 디스크 성능을 원할 때
- EC2 종료 시 스토리지가 손실된다 . == 임시 스토리지라고 함
- 그러니까 백업을 잘 하자.
ENA(Elastic Network Adapter)
EC2 에서 향상된 네트워킹 기능을 제공합니다. 지원되는 인스턴스 유형에 대해 최대 100Gbps의 네트워크 속도를 지원
5. EBS 볼륨 타입
EC2 가 부팅될 때 사용되는 볼륨
- gp2 / gp3 볼륨 스토리지 : 범용 SSD (gp3가 최신임) -> 효율적인 대기시간!!
설정한 IOPS가 부족할 경우 EBS 볼륨 크기를 늘리면 됨
- io1 / io2 :짧은 대기시간, 높은 성능 SSD
16,000IOPS 이상을 원할 때 gp -> io로 ㄱㄱ
Nitro 인스턴스의 경우 60,000 IOPS 까지 지원하지만, 아닌경우 30,000~32,000
최대 256,000 IOPS
st1 / sc1 -> 부트 볼륨이 될 수 X
- st1 (HDD) : 자주 액세스가 필요할 때 , 집약적 워크로드용
처리량에최적화됨 (빅데이터)
데이터 웨어하우징 및 로그 처리
- sc1 (HDD) : 가장 저렴한 HDD, 액세스 빈도가 낮을 때
아카이브 데이터용
자주 엑세스 하지 않는 데이터
저렴이 버전
6. EBS Multi-Attatch (io1 / io2 제품군만 가능)
같은 가용영역 내 동일한 ebs 볼륨을 여러 인스턴스에 연결하기 위해 설정 --> 같은 가용영역에서 다른 인스턴스들이 볼륨 공유하는 거임
인스턴스는 볼륨에 대해 쓰기, 읽기 권한을 가져야 함
7. EBS 볼륨 암호화 Encrypt (볼륨 생성 시 선택 가능)
스냅샷은 모두 암호화됨
AES-256 암호화
- 기본적으로 암호화 는 지역별(리전) 설정입니다. 리전에 대해 활성화하면 해당 리전의 개별 볼륨 또는 스냅샷에 대해 비활성화할 수 없습니다.
<암호화되지 않은 볼륨 암호화법 >
EBS 볼륨 스냅샷 생성 - EBS 스냅샷 암호화
- 스냅샷에서 새 ebs 볼륨 생성 시 해당 볼륨도 암호화됨 - 암호화된 볼륨 연결 가능
7. EFS (Elastic File System)
다중 AZ 기능 탑재 (EBS는 단일 가용 영역에서만 가능)
여러 다른 가용영역의 인스턴스가 하나의 nfs에 연결 가능
사용한만큼만 지불 (저장하는 데이터만큼 비용 지불)
웹서비스, 데이터 공유 등
Linux 기반 AMI에서만 작동 (Window 안됨)
- 스케일 (최대 10 gb 처리량의 고성능)
1) 성능 모드
웹서버 사용 경우 빠르게 액세스 가능
최대 i/o를 활성화 시 빅데이터 작업 부하 감당 가능
2) 처리량 모드
버스트 처리량 모드 (초당 최대 100 mb)
프로비저닝 처리량 모드 : 파일시스템이 작은 경우 높은 처리량이 필요할
3) 스토리지 계층
스토리지 수명 주기 관리 기능 - 파일 계층을 N 일 후 이동시킴. 계층에 따라 파일을 검색하여 액세스할 때 비용이 다름
표준 : 자주 액세스하는 파일
저비용 계층 : 드문 액세스 (EFS-IA)
* 인스턴스에 efs 연결 시
amazon-efs-utils 패키지 설치 필요
efs 연결할 마운트 디렉토리 생성
연결 명령어로 해당 디렉토리에 연결 가능 ( 보안그룹데서 nfs 허용해야함)
*온프레미스에서 EFS 마운트 가능함 (단, Linux 서버여야 하고 커널이 4.0 이상)
<< EBS VS EFS >>
EBS : 하나의 인스턴스, 하나의 가용영역
gp2 유형은 디스크 크기가 증가함에 따라 증가
io1 : 중요 데이터베이스 실행할 경우
서로 다른 가용영역에서 사용할 경우 스냅샷을 찍어야 함
루트 EBS 볼륨은 인스턴스 종료 시 삭제됨
사용할 크기를 미리 청구
EFS : 여러 인스턴스, 여려 가용영역
워드프레스, 웹사이트 공유 가능
Only linux임 --> windows에서는 작동하지 않음
EBS보다 약 3배 비쌈
수명주기 정책으로 비용 절감 가능
사용한 만큼만 청구 (온디맨드)
section 8 elb / asg
1. CLB (Classic Load Balancer) - 이전 세대로 사용 권장 안함
tcp -> layer4
http/https: layer7
2. NLB (Network Load Balancer)
tcp/udp 트래픽을 인스턴스에 전달 (layer4)
가용 영역 당 하나의 고정 IP를 지원 (elastic ip)
프리티어 아님
3. Sticky Sesstions (고정 세션)
쿠키가 있는 동안 클라이언트 요청이 특정 인스턴스로 연결됨
쿠키 만료 시 다른 인스턴스로 리디렉션됨
부하 불균형이 올 수 있음
쿠키 종류 >
- 어플리케이션 기반 쿠키 (Application based Cookies)
1) 커스텀 쿠키
응용 프로그램 자체 맞춤 속성
쿠키 이름은 지정 필요함, AWSALB, AWSLBAPP,AWSALBTG 이런 이름은 안됨
2) 어플리케이션 쿠키
로드밸런서 자체에서 생성됨 (AWSALBAPP)
- 기간 기반 쿠키 (Duration based Cookies)
로드밸런서에서 생성됨
ALB의 경우 AWSALB, CLB는 AWSELB임
4. Cross Zone Roadbalancing
서로 다른 두 elb가 있을 때,
elb1 - 인스턴스 1 , 2
elb 2 - 인스턴스 1 ,2 ~ 8
사용자가 두 elb에 각각 50 씩 (총 100) 트래픽을 전송했어도
균등하게 각각 10씩 나눠서 고르게 트래픽 분배됨
(크로스존이 아니었으면 elb1은 25, 25씩 나눴을 거임)
- alb (application load balancer)
항상 켜져있으며 비활성화할 수 없음
- nlb
비활성화 가능
az 내 데이터 전송은 비용 지불하지 않지만, 다른 az간 통신은 비용 지불
- clb
콘솔로 하면 기본 활성, api로 생성은 비활성
5. SSL / TSL인증서
1) ssl (secure sokets layer) : 클라이언트 - 로드밸런서 간 통신 중 암호화 (in-flight encryption 기내 암호화)
네트워크를 통해 전송되는 데이터 암호화
2) TLS : SSL 인증서의 최신 버전
클라이언트 --> Https 연결 --> ELB --> HTTP 연결 --> EC2
X509 인증서 사용
ACM : (AWS Certificate Manager)을 통해 SSL 인증서를 관리할 수 있음
클라이언트는 SNI (Server Name Indication) 를 사용할 수 있음
3) SNI (Server Name Indication)
하나의 웹서버에 여러 ssl 인증서를 로드함 (여러 웹사이트를 제공하기 위해)
ALB, NLB , CloudFront에서 사용
--> 서버 이름을 표시하여 로드밸런서에 여러 타겟 그룹을 가질 수 있음
--> CLB의 경우, 하나의 ssl 인증서만 지원하기 때문에 여러 호스트이름을 원하는 경우 여러 clb를 사용함
--> ALB의 경우, 여러 리스너를 지원함 (https)
--> NLB도 마찬가지 (TLS)
5. Connection Draning (연결 드레이닝)
CLB -> Connection Draning 연결 드레이닝
ALB / NLB ->Deregistration Delay 등록 취소 지연 이라고 함.
인스턴스가 등록 취소 (삭제)되는 동안 연결되는 것
이미 연결된 사용자는 연결되어있지만, 새 연결은 되지 않음
6. ASG 스케일링 정책
1) 동적 확장 정책 (Dynamic Scaling Policies)
심플 정책? 기본 베이스라인
cloudwatch와 함께 사용 (단계정 scaling) - cpu 사용률이 30 미만이면 추가 및 삭제
예약 스케줄 (특정 시간에 자동으로 스케일 out)
2) 예측적 스케일링 (Predictive Scaling)
분석을 통해 분석 결과로 예측해서 스케줄링
- 측정 항목 : cpu 사용률, 대상당 요청 수 , 네트워크 인/아웃바운드 트래픽
- 스케일링 쿨다운 : 인스턴스가 자동 추가/제거될때마다 쿨다운 기간에 들어감 (5분, 300 초), 이 기간동안 ASG는 인스턴스를 시작하거나 종료하지 않음
ASG 축소 삭제 기준
ASG는 2개의 가용 영역에 걸쳐 생성됩니다. AZ-A에는 3개의 EC2 인스턴스가 있고 AZ-B에는 4개의 EC2 인스턴스가 있습니다. ASG가 축소 이벤트에 들어가려고 합니다. 무슨 일이 일어날 것?
- ASG에 대한 기본 종료 정책을 기억해야 합니다. 먼저 AZ 전체에서 균형을 유지한 다음 시작 구성의 기간을 기준으로 삭제를 시도합니다.
- 인스턴스의 유형을 늘리면 수직, 갯수를 늘리면 수평
section 9 RDS
1. RDS 관계형 데이터베이스 서비스 (Relational Database Service)
- SQL 을 쿼리 언어로 사용하는 데이터베이스
엔진 : PostgreSQL, Mysql,MariaDB,Oracle , Microsoft SQL Server, Aurora
- 데이터베이스 프로비저닝
- 자동 백업 활성화 (특정 시각으로 복원 가능- Point in Time Restore)
1) 일일 전체 백업
2) 트랙잭션 로그는 5분 마다 백업
3) 7일의 보존 기간 (최대 35일까지 확장 가능)
* 스냅샷 백업은 사용자가 지정하지만 RDS 백업은 자동임
스냅샷은 원하는 기간까지 복원임
- 읽기 전용 복제본 생성 가능 (읽기 성능 향상) : 비동기
- 다중 AZ 설정 (DR) : 동기
- EBS 지원 (gp2, io1)
- SSH 에 연결할 수 없음
- Storage Auto Scaling !!
자동으로 스토리지 용량 확장해줌 (최대 임계값을 설정함)
예측 불가능한 워크로드가 있는 어플리케이션의 경우 유용함
2. Read Replicas (읽기 전용 복제 - SELECT문 SQL문만 사용 가능)
- DB에 read 요청이 너무 많은 경우 사용
- 최대 5개까지 복제본 생성 가능
- 같은 AZ, 다른 AZ, 다른 리전에서도 가능
- 비동기식 복제
- 복제본을 자체 데이터베이스로 승격 가능 (읽기전용 복제본 목록 수정)
- 네트워크 비용
관리형 서비스이기 때문에 다른 AZ간 통신이 있더라도 무료임
하지만 서로 다른 리전일 경우는 비용 발생
3. Multi AZ
- DR 구성 시 사용 (MHA + Maxscale 동작이랑 비슷함)
- 동기식 복제
- 마스터 수정 -> 슬레이브 수정
- 마스터 죽으면 -> 슬레이브가 마스터
- 하나의 DNS 이름을 가짐
- 읽기 전용 복제본도 다중 AZ 설정이 가능함
- 다중 AZ로 구성할 경우 다운타임을 없앨 수 있음
!! 동작
메인 DB 스냅샷 찍음 -> 새로운 AZ에 DB 생성 -> 스냅샷 복원
4. RDS Security
1) Encryption (암호화)
- At rest encrytopn : 저장 시 암호화
처음 생성될때만 수행
마스터 암호화
읽기 전용 복제본 암호화 : AWS KMS 서비스 (AES-256) --> 마스터가 암호화 안되어있으면 복제본도 암호화 안됨
TDS : Oracle, SQL Server용 암호화
- In-flight encryption : SSL 암호화 (기내 암호화)
클라이언트 -> DB 연결 시 SSL 인증서로 암호화
PostgrSeQL : rds.force_ssl=1 -> 매개변수 그룹
MySQL : GRANT USAGE ON *.* TO 'mysqluser'@%'REQUIRE SSL; -> SQL 명령
암호화 방법
- 암호화 되지 않은 DB 생성 -> 스냅샷 생성 (암호화 활성화됨) -> 스탭샷으로 DB 생성
2) 네트워크 & IAM 보안
- RDS는 프라이빗 서브넷에 생성됨
- 보안그룹으로 제어할 수 있음
- IAM 정책으로 RDS 관리 가능 (복제본 만드는 사람, 읽는 사람 등)
IAM 인증 ?
인증 토큰을 이용해 인증하며, 암호화가 필요 없음
3. AWS Aurora (RDS 상위호환)
-AWS 에서 지원하는 DB 엔진 (오픈소스 아님)
자동 확장 가능
- 다중 AZ
- 10GB~ 64TB 까지 지원
- 5 ~ 15 읽기 전용 복제 가능 (겁내 빠르단다) , 각 데이터의 복제본 6개
RDS는 최대 5개 읽기 전용 복제본 가짐
- 자가 회복, 자동 확장
- 리더 앤드포인트가 복제본을 연결시켜줌
- DB 서버리스 구현 가능
- 비용 : EC2 인스턴스 유형에 에 따라 시간당 지불 / 스토리지 양
Aurora Serverless : 예측 불가능한/간헐적 작업 부하가 있는 경우
Aurorra Multi-Master : 지속적인 쓰기 장애 조치를 원할 경우 (write failover)
- RDS와 동일한 사용사례로 쓰이지만, 더 높은 성능을 원할 때 사용
4. AWS Elastic Cache (Dynamo DB의 DAX랑 헷갈 ㄴㄴ)
- 관리형 Redis 또는 Memcached (따라서 캐시용으로 쓰이는 애임)
- RDS처럼 작동하지만 캐시임 --> 데이터베이스가 아님. (SQL 못써) 키/값 저장소, 쿼리에 대한 결과 캐시 저장-> Write Through 패턴
인스턴스 타입 프로비저닝해야 함
다중 AZ
읽기 전용 복제본 제공 (Redis에서는 클러스터링이라고 함 == 샤딩 Sharding)
모니터링은 Cloud Watch
- 메모리 내 db 임 (캐시) -> db 부하를 줄이는 데 도움됨
- 캐시에 저장된 쿼리 결과를 검색함 (db는 매번 쿼리되지 않고 기억하는 결과를 내놓음)
동일한 쿼리 응답
- IAM 인증을 지원 X -> Redis AUTH를 통해 인증한다. (클러스터 생성 시 암호 가짐)
- 보안그룹, KMS 암호화
- 백업, 스냅샷 지원
- 밀리초 미만의 성능
elastic cache load 패턴
1) Lazy Loading (지연 로딩) - 모든 읽기 데이터가 캐시되는 곳. 오래된 캐시 데이터 존재
2) Write Through 데이터 추가 또는 업데이트 : 캐시는 기록될 때마다 오래된 데이터가 없는 데이터베이스로 이동한다.
3) 세션 저장소 : TTL (Time To Live) 기능으로 세션 만료 가능
Sorted sets 기능을 알고 가자
실시간 리더보드 - 순서 정하는 거임?
-Dynamo DB의 Dax VS ElasticCache (뒤에 이 얘기 또 할거임)
DAX : Dynamo DB용
Elasticache는 Memcached 또는 Redis를 기반으로 하는 캐시 엔진으로 RDS 엔진 및 DynamoDB와 함께 사용할 수 있습니다.DAX는 AWS 기술이며 DynamoDB에서만 사용할 수 있습니다.
section 10 Route 53
https://opentutorials.org/module/288/2802 --> 도메인 기초 알기
1. route 53
- 도메인 등록 기관
- 사용자가 dns 레코드를 등록할 수 있음
client -> route 53 -> 도메인의 맞는 ip 찾기 - ec2 연결
( 레코드는 특정 도메인에 트래픽 라우팅하는 방법을 정의함 )
- 도메인 구입하면 연간 돈을 지불함
- 레코드 종류
A레코드 : IPv4
AAAA : IP v 6
CNAME : 호스트 이름 (Route53은 최상위 노드(루트 도메인)에 대한 CNAME 생성 안됨
example.com에 대한 CNAME 생성 X
www.example.com 은 됨)
NS : 호스팅 영역의 DNS 이름 또는 IP 주소
apex 레코드 : Cname 구성 안됨!!!!!!
- 호스팅 영역이란?
레코드의 컨테이너? 도메인 및 하위 도메인에 트래픽 라우팅할 방법을 정의함
1) 공개 영역 -public domain name, 모든 사람들이 사용할 수 있는 url
2) 비공개 영역 - private domain , 가상 사설 클라우드, VPC 내에서만 사용할 수 있는 url
콘솔창에 dig [도메인] 입력하면 도메인 정보 볼 수 있음
2. TTL (Time To Live)
TTL 값이 300일 경우, 300초 동안 dns 쿼리를 재실행하지 않고 그냥 보여줌
높은 TTL값을 가질 수록 Route53이 갖는 부하가 적음
대신 레코드 기록을 바꾸고 싶을 경우 TTL 시간동안 기다려야 함 (캐시가 만료되어야만 다시 route53에 dns 쿼리를 물어봄)
3. CNAME VS Alias
공통 : 호스트네임으로 연결해야할 때 (ELB , CloudFront 도메인 등에 연결)
1) CNAME 레코드
- 루트 도메인 이름이 아닌 경우에만 작동 (CNAME 레코드는 루트에 등록될 수 없음.. 그냥 test.com 이랑 cname으로 연결 안됨)
* 루트도메인(Origin, naked domain)은 서브도메인이 없는 도메인 그 자체를 말하는 것으로써 예를 들어, 도메인이 domain.com 이면 www.domain.com 과 같이 www/mail 등의 서브도메인이 붙지 않은 domain.com 을 의미
2) Alias == 별칭 레코드
- 특정 AWS 리소스에 도메인 매핑, 리소스 도메인을 가리킬 수 있음 (무료임)
ALB IP 가 변경될 경우 alias는 자동으로 인식함 (생성 시 리소스, 리전을 선택하게 함)
- 루트도메인도 다 가능
- A레코드 또는 AAAA레코드
- TTL 설정 안됨 (Route 53에서 자동으로 설정됨)
- EC2 DNS Name에는 대상으로 사용할 수 없음 !
4. 라우팅 Policy - dns 쿼리를 라우팅하는 정책
헷갈리지 말것. dns 쿼리는 트래픽을 라우팅하지 않음. dns는 dns 쿼리에만 응답
지원 가능한 라우팅 정책
- simple 단순
- Weighted 가중치
- Latency based 대기시간 기반
- Failover 장애조치
- Geolocation 지리적 위치
- Multi-Value Answer 다중 값 응답
- Geoproximity 지리적 근접성
1) Simple 단순 라우팅 정책
- 다중 연결 가능
test.com 에 대해 3개의 A 레코드로 응답이 왔으면 클라이언트는 셋중에 하나 무작위로 연결함.
- health check 안됨
2) Weighted 가중치
- 인스턴스마다 가중치를 다르게 줘서 가중치만큼만 응답되게 함.
- health check 가능
- dns 레코드는 같은 타입이어야 함
- 가중치가 0일 경우 전송이
중단되지만, 모든 리소스 가중치가 0일 땐 균등하게 비율이 전송됨
3) Latency based 대기시간 기반
- 여러 지역에 리소스가 존재할 경우, 클라이언트가 가장 빠르게 연결할 수 있는 리전 리소스에 연결해줌 (미국에 살면 미국 리전 리소스에 연결)
4) Health Check
- DNS 장애 조치를 위해 사용
- check 방법 3가지
앤드포인트 상태 체크 : ELB, EC2 같은 리소스에 대한 체크- 15개의 global 체커가 있음
calculated health check 계산된 상태 확인 : 부모 checker가 아이들 checker 확인 -> 아이들 checker 는 리소스 상태 check. OR/ AND /NOT 선택으로 상태 인식
cloud watch 알람 사용 - 개인 리소스에 대해 모니터링 하고 싶을때 (온프레미스 환경 리소스)
5) Failover 장애 조치
- health check 가 unhealthy면 자동으로 정상 리소스로 트래픽이 우회됨
레코드 생성 시 primary - secondary 두 가지에서 선택 가능
6) Geolocation 지리적 위치
- 실제 사용자의 위치 기반 (Latency 랑 헷갈 ㄴㄴ) - 프랑스는 어떤 리소스, 미국은 어떤 리소스 이렇게 지정 가능
프랑스에서 오면 프랑스어가 지원되게 할 수 있음
- Default 레코드를 생성해야 함 (기본 위치이기 때문에, 내 위치가 지정 안되어있을 경우 여기로 응답됨)
7) Geoproximity 지리 근접 라우팅
지리적 위치의 편향 값을 지정. (특정 지역에 더 많이 트래픽을 몰 수 있음)
편향이 더 높은 곳에 사용자가 자석처럼 몰리게 됨 (n극 s극 같은 너낌..?)
Route 53 고급 기능을 사용
8) 트래픽 흐름 (Traffic Policy) -> 무료 아님
- 트래픽 라우팅 정책을 GUI로 설정할 수 있음.
9) 다중 값 Multi Value
- Route 53은 여러 값, 여러 리소스 반환이 가능함 (최대 8개의 정상 레코드 반환)
- unhealthy는 반환 x
10) 도메인 등록 기관과 DNS 서비스의 차이 !!!
* 일반적으로 일부 도메인 등록 기관에서 DNS 서비스를 함께 제공하지만 둘은 다름
타사 등록 기관에서 도메인 구입해도
Route 53을 DNS 서비스 공급자로 사용 가능 :
퍼블릭 호스팅 영역 생성
NS 또는 네임서버 레코드를 도메인 구입한 타사 웹사트로 업데이트
section 11 클레식 솔루션 아키텍처 (각 사이트마다 구성해야할 구조가 다르다는 것)
(1~3 안봐도됨 생각만하삼)
1. WhatlsTheTime.com : 시간만 입력하면 데이터베이스 필요 x (Route 53, ELB, ALB)
2. MyClothes.com : 데이터베이스 필요한 웹사이트 (다중 AZ, 다중세션, RDS, elastic cache 등)
3. MyWordPress.com : 여러 인스턴스에 한 웹사이트 사용하는경우 ( EFS, EBS 볼륨 사용 )
4. 인스턴스 시작을 빨리 하려면
- AMI를 사용해서 어플리케이션 설치
- RDS 스냅샷
- EBS 볼륨 스냅샷
5. Elastic Beanstalk (무료)
- 아키텍쳐 자체를 빠르게 배포할 수 있도록 함. (코드로 배포)
- 개발자 중심의 작동방법임
- 서버 계층 : 일반적으로 알고있는 3티어 계층 구조
- 작업자 계층 : 접근하는 클라이언트가 없음. EC2가 작업자이며, SQS 대기열에서 메시지를 가져옴 (몬말이지 이게)
** cloud formation > elasicbeanstalk 임
빈스톡이 formation 기반으로 만들어짐
Elastic Beanstalk은 복잡한 CloudFormation 템플릿을 작성(서버 구성, 설치, 배포 설정) 하지 않고 간단하게 사용할 수 있도록 만든 서비스
section 12 S3 **** 시험에 잘나옴
1. S3 Buckets
- 지역 리소스 (리전)
- 파일 또는 디렉토리를 객체로 저장
- 고유의 이름이 있어야 함 (중복으로 사용 x)
언더바 x
대문자 x, 소문자나 숫자로 시작해야 함
3~63자 이내
IP가 아니어야 함
- 객체 생성시 객체는 항상 키를 가짐
Key : 전체 경로를 뜻함
S3://my-bucket/test.txt
S3://my-bucket/test.d/text.txt
* key의 분해 (접두사 + 개체 이름 )
S3://my-bucket/test.d/text.txt
- 5TB까지 저장 가능하지만, 한번에 5GB 만 업로드 가능 (multi part upload) 멀티 파트 업로드
- 메타데이타, 태그, 버전 ID를 가짐
* 요청자 지불 버킷
S3 버킷을 요청자 지불 버킷으로 구성하여 요청자가 버킷 소유자 대신 요청 및 데이터 다운로드 비용을 지불하도록 할 수 있음
2. S3 Version 관리
- 파일 업로드 시 덮어씌워지는 걸 방지하기 위함 (해당 파일의 새 버전을 만듦)
이전 버전으로 롤백 가능
매 버전마다 버전 ID가 할당됨
- 버킷 versioning 옵션에서 활성화를 시켜야 함 (나중에 비활성화해도 버전은 유지됨. 대신 새로 생성하면 버전 null값으로 생성됨)
- 활성화하지 않으면 지정되지 않은 모든 파일 버전은 null
- 특정 파일을 삭제해도 이전 버전은 삭제되지 않음
3. S3 Encrytion 암호화 (4가지 방법)
- SSE-S3 : S3 객체 암호화. AWS에서 관리하는 키 사용
- SSE-KMS : 키 관리 서비스
- SSE-C : 암호화 키를 내가 관리하고 싶을 때
- 클라이언트 측 암호화
1) SSE-S3
아마존에서 관리되는 키로 암호화해서 저장됨
서버 암호화임 (SSE 는 무조건 서버암호화)
AES-256암호화 타입
헤더에 반드시 "x-amz-server-side-encrytion":"AES256" 이 포함됨
2) SSE-KMS
키 관리 서비스 , 서버 암호화임
누가 키에 액세스할 수 있는지 감사 추적 가능
헤더에 반드시 "x-amz-server-side-encrytion";"awskms" 이 포함됨
3) SSE-C (CLI에서만 가능)
AWS 외부에서 가져온 키로 암호화 (서버측 암호화)
클라이언트 측에서 키를 전송 (HTTPS + 헤더에 data key를 전송)해서 그 키로 암호화
HTTPS는 필수임
4) 클라이언트 측 암호화 (서버측 암호화 XXX)
클라이언트가 개체를 암호화할 때
S3 로 보내기전에 이미 암호화를 함 (고객이 전적으로 관리해야함)
3. S3 Security
- User 사용자 기반 : IAM 정책을 통해 승인된 경우 액세스
- 리소스 기반 : S3 콘솔에서 설정할 수 있는 버킷 전체 규칙
객체 ACL, 버킷 ACL
교차 계정 액세스 수행할 수 있음 (?) cross account
** 교차 계정 액세스란?
교차 계정 액세스를 설정하면 각 계정에 개별 IAM 사용자를 생성할 필요가 없음. 다른 계정으로 쉽게 로그인 전환 가능
- JSON 코드로 이루어짐 (ADA 정책 생성기 사용)
- 공개 액세스를 차단할 수 있음
- vpn 네트워크를 통해 비공개 액세스 가능
- s3 액세스 로그를 감사로그로 남길 수 있음
- 객체 삭제 시 MFA 로 인증해서 삭제하게 설정 가능 (MFA 삭제 활성화)
- 제한된 시간에서 가능한 url 제공 (제한시간 내에만 열리는 url 사이트인 경우)
4. S3 Website웹사이트
- 정적 웹사이트 호스팅 가능 (활성화해야함)
- 이 경우, 권한에서 공개 액세스 차단을 비활성화 (모두가 접근가능해야 함)
버킷 정책을 누구든 모든 개체에 접근 가능하도록 생성
5. CORS (Cross origin Resource Sharing)
- 다른 origin 사이트에서 요청을 허용하는 경우 요청 가능 (파일을 가져오거나 삭제 및 업데이트)
*같은 origin : http://example.com/app1 & http://example.com/app2 (같은 버킷)
*다른 origin : http://www.example.com/app1 & http://other.example.com/app2 (다른 버킷)
- 클라이언트가 교차 출처 요청을 수행하는 경우 *** ( 시험 )
웹사이트로 활성화된 교차 출처 s3 버킷에서 CORS 헤더를 활성화해야 함
6. Database 관점
객체에 대한 키/ 값 저장소임
객체의 전체 경로 , 값
객체를 저장하고 검색함
큰 객체 저장에 적합하지 않음
서버리스 무한한 저장 공간, 최대 5tb의 객체 저장을 알고 있다면 db 대용으로 사용해라
section 13 AWS SDK, IAM 역할 및 정책
- IAM Policy Simulator로 테스트함
1. EC2 인스턴스 메타데이타
IAM 역할로 인스턴스가 학습하도록 함
중요 *** CURL http://168.254.169.254/latest/meta-data/
인스턴스는 이 url로 iam 역할 이름 검색 가능
- 둘 차이 헷갈 ㄴㄴ
metadata : ec2 인스턴스에 대한 정보
userdata : ec2 인스턴스 시작 시 스크립트
2. SDK (software development kit) *아마존 접근하는 세 가지 옵션에 나왔음
- CLI 사용하지 않고 어플리케이션 코드에서 직접 실행 (개발자 영역)
section 14 Advanced 고급 Amazon S3 & Athena 아테나
1. Delete MFA
- S3 버킷에서 버전 관리를 활성화해야 사용 가능 (루트 사용자-버킷 소유자만 활성 가능함, CLI 보안 자격 증명으0로 활성 가능)
- 삭제할때도 CLI로 삭제해야댐
2. S3 Default Encrytion VS Bucket Policies
- 기본 암호화 옵션 : 암호화되지 않은 객체 업로드 시 해당 옵션으로 암호화됨 (암호화가 이미 되어있으면 패스함)
- 버킷 정책은 기본 암호화 전에 식별됨
3. Access Logs 감사로그
- 버킷의 모든 액세스를 s3 버킷에 기록 (타겟 버킷을 지정할 수 있음)
- 로깅 버킷과 어플리케이션 버킷을 분리해라 ( 아니면 루프돌면서 용량 커짐 )
4. S3 Replication 복제
- 버킷 버전 관리를 활성화해야함
- 복제하고자 하는 두 버킷이 같은 리전인지, 다른 리전인지
CRR : Cross Rision Replication 교차 리전 복제 ex) 로그 중앙집중화
SRR : Same Rision Replication 동일한 리전 복제
다른 계정에 있는 경우 S3 복제를 사용하여 다른 계정에 복사한다. (IAM 역할 권한 필요 )
- 복제 체인 X
- 이전 겍체는 복제하지 않고 새 객체만 복제함 (삭제는 복제하지 않음)
5. Pre-Signed URL 사전 서명된 URL
- 생성 시 만료 시간 설정 가능
- 일시적으로 사용자를 허용하고 싶을 때
6. S3 Storage classes 클래스
- S3 Standard : 범용 스토리지. 일반적으로 사용
- S3 Standard-Infrequent Access (IA)
- S3 One Zone IA : 데이터 재생성
- S3 Intelligent Tiering : 데이터 이동
- Amazon Glacier
- Amazon Glacier Deep Archive
- S3 Reduced Redundancy Storage (감소 중복 스토리지)
1) S3 Standard
- 일반적으로 사용. AZ 재해에 강함
- 최소 보관 기간이 업음
--------------------------
이 밑으로는 최소 보관 기간이 있으며, 보관 기간마다 비용이 청구됨
2) S3 IA
- standard보다 저렴
- 개체에 덜 액세스할때
- 데이터 저장소, 재해복구, 백업
- 최소 30일 보관
3) S3 One Zone IA
- IA 와 동일하지만 단일 가용성 영역에 저장됨
- 비용 저렴
- 보조 백업 복사본을 저장할 때
- 최소 30일 보관
4) S3 Intelligent Tiering
- 자주 쓰는 데이터, 아닌 데이터 구분해서 데이터 간 자동으로 클래스 이동 (standard -> IA)
- 수수료 지불
- 월별 모니터링 비용 있음
- 최소 30일 보관
***Glacier는 파일 업로드 시 open할 수 없고 복원해야 가능함
5) Amazon Glacier (실시간으로 필요하지 않은 경우 사용)
- 버킷이 아닌 금고
- 개체가 아닌 아카이브
- 오래된 데이터를 저장할 때 사용하며 저렴함 (쿨~)
- 최대 40tb
- 최소 90일 보관 ***
- 복원하는데 3가지 옵션 ***중요
Expedited (1~5분) / Standard (3 ~ 5시간) / Bulk (5~12시간)
Amazon Glacier에 저장된 모든 데이터는 서버 측 암호화를 사용하여 보호됩니다. (AES-256)
6) Amazon Glacier Deep Archive (연 단위는 무조건 glacier임)
- 초장기 보관용 (더 저렴함)
- 최소 180일 보관 ***
- 긴급하게 검색할 필요가 없는 파일의 경우 (*** standard 12 ~ bulk 48시간 이내는 검색 x)
Glacier와 달리 검색. 예상치 못한 연간 데이터 감사가 발생하는 경우 데이터를 검색할 수 있기까지 몇 시간이 걸릴 수 있습니다.
** 주의 !!
S3에서 객체를 전환하는 데 시간 제약이 있는 경우
객체의 스토리지 클래스를 S3 Standard 스토리지 클래스 -> STANDARD_IA 또는 ONEZONE_IA 스토리지로 30일 후에 변경가능함 (IA는 30일)
INTELLIGENT_TIERING, GLACIER 및 DEEP_ARCHIVE 스토리지 클래스에는 적용되지 않습니다.
7. S3 Lifecycle Rule 수명 주기 규칙 *** 시나리오에 따라 클래스를 구분할 수 있어야함
- 개체 클래스를 전환하려는 경우 사용한다.
- 개체 클래스 전환 기간, 삭제 기간 등을 정의할 수 있음
- 버킷당 여러개 설정 가능
8. S3 Analysis 클래스 분석
- 객체 클래스 전환 시기를 분석해서 결정해줌
- Standard / Standard IA 전용임. (One Zone IA, Glacier에서는 지원 XXX)
- 리포트는 매일 업데이트됨 (처음시작 시 24~48시간 소요)
9. S3 Baseline
- 버킷의 접두사마다 초당 3500개의 Put 5500개의 Get
10. S3 Performance (속도 향상법)
- Multi Pard upload : 5gb 초과 시 병렬로 전송하여 효율 향상
- S3 Transfer Acceleration : 전송 속도를 높이기 위해 사설 aws 네트워크 사용 ?
- S3 Byte Range Fetches : 한꺼번에 다운받지 않고, 특정 바이트 범위씩 다운로드를 병렬로 수행, 다운로드 속도 향상 (GET)
11. S3 Select & Glacier Select
- 간단한 Sql문을 사용해서 S3에 요청하여 검색 가능함 (cpu, 네트워크 자원 적게 사용)
12. S3 Event Notifications 이벤트 알림
- 특정 이벤트에만 알림이 반응하도록 설정 가능 (ex jpg 업로드시만 알림)
- lamda, sns, sqs 대기열 와 연동하여 사용 가능
- 버킷 버전관리 활성화하면 자잘한 이벤트도 받게 됨
13. Requester Pays
- 대용량 데이터를 다른 계정과 공유할 때
- 그 데이터를 요청하는 사람은 인증된 사람이어야 함
- 다운로드 요청자에게 비용을 청구하게 됨
14 Athena
- S3 에서 직접 로그 데이터를 분석해야 할 때 사용
- S3에서 데이터를 쿼리함 (S3 위에 쿼리 엔진= presto 고성능 엔진을 제공)
- 쿼리당 요금이 청구됨. 실제로 사용한 만큼만 청구됨
- 서버리스 서비스
- IAM + S3 보안 구성
- 일회성 SQL 쿼리 , 로그 분석 , 서버리스 쿼리
Athena는 Amazon S3에 저장된 비정형, 반정형 및 정형 데이터를 분석하는 데 도움이 됩니다. 예에는 CSV, JSON 또는 Apache Parquet 및 Apache ORC와 같은 열 데이터 형식이 포함됩니다. Athena에 데이터를 집계하거나 로드할 필요 없이 Athena를 사용하여 ANSI SQL을 사용하는 임시 쿼리를 실행할 수 있습니다.
15. 객체 잠금
Glacier Vault Lock
- WORM 모델 (Write Once Read Many)
- 객체 잠금 (아무도 변경할 수 없음), 삭제도 불가능
- 데이터 보존을 위해 사용
S3 Objent Lock
- WORM 모델
- 객체 버전 관리 활성화 필요
- 객체 버전 삭제를 차단함 (보유 기간, 고정 기간동안 개체가 잠김)
- 2가지 모드
Governance 거버넌스 모드: 특별한 권한이 없으면 개체 버전 재정의,삭제 안됨
Compliance 준수 모드 : 루트 사용자를 포함한 그누구도 덮어쓰기, 삭제 안됨
section 15 Cloud Front & Global Accelerator
1. ClounFront
- 콘텐츠 전송 네트워크 CDN
- 전 세계에 퍼져있는 엣지 로케이션을 통해 전송됨
- DDOS 공격 방지 방화벽도 있음
- 보통 S3 앞에 배치함
버킷을 S3 웹사이트로 활성화 필요 (디버그 웹사이트)
- 요청에 대한 응답을 캐시한 후, 비슷한 요청시 캐시를 통해 응답함
- 연결점(origin) 이 S3의 경우 자격증명, EC2는 보안그룹으로 액세스 허용이 되어야 함
- 배포에 액세스할 수 있는 사람을 지리적으로 제한할 수 있음 (IP 제한)
- CloudFront VS S3 교차 리전 복제
cloudfront : 글로벌, TTL 사용 , 정적 콘텐츠일 때 유용
교차 리전 복제 : 복제 시 각 AZ에 대해 설정, 읽기 전용, 실시간, 동적 콘텐츠에 유리
- OAI?
** JSON 템블릿 구성 형식
- 형식 버전 Format Version
- 설명 Description
- 메타데이터 Metadata
- 매개변수 Parameters
- 매핑 Mappings
- 조건 Conditions
- 변형 Transform
- 자원 Resouece (필수)
- 출력 Outputs
2. Cloud Front Signed URL 서명된 url / 쿠키
- url또는 쿠키가 만료되는 시점, ip 범위 등을 정의해야 함
- url 쿠키 차이 ?
url : 개별 파일에 대한 액세스 제공 (파일이 100개면 100개 url 제공)
쿠키 : 여러 파일에 쿠키를 재사용 가능
- Cloud Fron Signed URL VS S3 Signed URL
CloudFront : 연결 끝점(origin)과 상관없이 경로 액세스를 허용한다.
루트계정만 키 관리함
S3 : URL을 가진 사람은 권한을 가지고 있으야 함.
IAM 키
3. 비용
- 엣지 로케이션당 데이터 비용은 다양함
- 엣지 로케이션의 수를 줄여서 비용 절감할 수 있음
Price Class All , 200 ,100
4. Multi Origin
- 연결 리소스를 동시에 여러개로 연결 가능 (ALB, S3를 한 아키텍처에서 연결)
-origin group 설정해서 Failover 구현 가능
5. Field Level Encryption
- 엣지 로케이션이 암호화진행
- 비대칭 암호화를 사용. 개인 키에 액세스할 경우 복호화 가능
6. Global Accelerator 글로벌 가속기
- 접근하고자 하는 어플리케이션 서버가 너무 먼 곳에 있을때, 대기시간을 줄이고자 사용함
- Anycast IP 방식을 사용함 (가장 가까운 엣지 로케이션에 전송)
Anycast IP : 접근할 서버들이 같은 IP 를 보유중일 때, 가장 가까운 서버에 전송됨
Unicast IP : 각 서버당 IP 1개씩 보유
- health check 할 수 있음 (heathy한 앤드 포인트로 전송)
- Global Accelerator VS CloudFront
둘다 글로벌 네트워크, 엣지 로케이션 사용, DDOS 보호 쉴드 있음
CloudFront : 이미지, 비디오와 같은 콘텐츠 제공, 연결 orign 에서 콘텐츠 가져옴
Accelerator : 광범위한 응용 프로그램 성능 향상
두개 이상의 리전에서 실행되는 애플리케이션
section 16 AWS Storage Extras
1. AWS Snow Family
- 데이터 마이그레이션 서비스임
- Data Magration : Snowcone / Snowball Edge / Snowmobile
- Edge Computing : Snowcone / Snowball Edge
- Snow family는 오프라인 장치임. 실제 물리적 장치를 aws에서 보내줌
데이터 로드 후 다시 aws로 반환
1) Data Magration
Snowball Edge
- 테라, 페타바이트의 대용량 데이터를 이동할 때 사용하는 물리적 장치임
- 두 가지 버전
Snowball Edge Storage Optimized : 최대 80tb + S3 객체 제공
Snowball Edge Compute Optimized : 최대 42tb + S3
* 더 대용량을 원할 경우 Storage 옵션으로 사용
Snowcone
- 휴대용 컴퓨팅 물리적 장치. 작고 가벼움
- 8tb 스토리지 저장
- 드론에 장착 가능.
- 네트워크 연결이 없는 곳에서 데이터 수집 후 aws 로 데이터 전송 가능
Snowmobile (snowball보다 대용량)
- 데이터를 전송하는 트럭임
- 100테라파이트 ~백만테라바이트
- 10 페타바이트 이상 전송 시 snowball보다 이걸 사용
2) Edge Computing
- edge location 에서 생성되는 데이터의 마이그레이션
* edge location : 인터넷이 통하지 않는 곳 (광산, 바다 등)
- snowball , snowcone 모든 장치는 ec2 인스턴스 중 하나 실행가능
- lambda 함수는 iot GreenGrass 서비스 사용
- OpsHub : snow 장치에 연결하기 위한 gui 인터페이스 명령줄
2. Snowball into Glacier X, S3 OK
- Snowball은 데이터를 Giacier로 직접 가져올 수 없음
*** 방법 : S3를 사용하자 ( S3 Lifecycle 정책 구성하자)
3. Storage Gateway
- 온프레미스 - cloud data 간 연결 지원 (S3, EBS, EFS)
- 온프레미스에서 aws 스토리지 백업을 누리고 싶을 때
- 온프레미스에서 데이터 액세스가 가능하다.
*** 게이트웨이 특징 구분 필요
1) File Gateway
- S3 연결 지원 (NFS, SMB 프로토콜)
- S3 Class 지원 (standard s3 , IA , onezone IA 등)
- IAM Rule 설정 가능
- 온프레미스 AD 와 통합하여 사용자 인증 가능
- 많이 사용되는 파일은 파일 게이트웨이에 캐시됨 (액세스 지연시간 단축)
2) Volume Gateway
- ISCSI 프로토콜
- EBS 볼륨 스냅샷을 생성함 (S3 지원), 실제 볼륨을 백업하는 것
- 두가지 옵션
캐시볼륨 Cached volumes : 짧은 액세스를 위해, 자주 액세스 하는 하위 집합 대상
저장볼륨 Stored volumes :예약된 백업, 전체 데이터 세트에 대한 짧은 액세스일때
3) Tape Gateway
- 테이프 기반 프로세스 사용 및 ISCSI 인터페이스 사용
- 테이프를 S3 , Glacier 에 저장
- 테이프 기반 백업 서버 지원
*** 헷갈 ㄴㄴ!!!
Storage gateway VS DataSync
AWS Storage Gateway 는 거의 무제한의 클라우드 스토리지에 대한 온프레미스 액세스를 제공하는 하이브리드 클라우드 서비스 세트입니다. 고객은 Storage Gateway를 사용 하여 AWS 클라우드 스토리지를 기존 온사이트 워크로드와 통합 하여 스토리지 관리를 간소화하고 주요 하이브리드 클라우드 스토리지 사용 사례에 대한 비용을 절감할 수 있습니다. 여기에는 백업을 클라우드로 이동하고, 클라우드 스토리지가 지원하는 온프레미스 파일 공유를 사용하고, 온프레미스 애플리케이션을 위해 AWS의 데이터에 대한 짧은 지연 시간 액세스를 제공하는 것이 포함됩니다.
AWS DataSync 는 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간, AWS 스토리지 서비스 간 데이터 이동 을 간소화, 자동화 및 가속화하는 온라인 데이터 전송 서비스입니다 . DataSync를 사용하여 활성 데이터 세트를 AWS 로 마이그레이션 하고, 데이터를 아카이브하여 온프레미스 스토리지 용량을 확보하고, 비즈니스 연속성을 위해 데이터를 AWS에 복제하거나, 분석 및 처리를 위해 데이터를 클라우드로 전송할 수 있습니다.
AWS Storage Gateway와 AWS DataSync는 모두 온프레미스 데이터 센터에서 AWS로 또는 그 반대로 데이터를 보낼 수 있습니다.
AWS Storage Gateway는 데이터를 복제하여 스토리지 서비스를 통합하는 데 더 적합하고
AWS DataSync는 데이터를 이동하거나 마이그레이션해야 하는 워크로드에 더 적합합니다.
4. Hardware Applience
온프레미스 가상화가 없는 경우, Storage Gateway 하드웨어 주문 가능
--> Storage Gateway 하드웨어 어플라이언스 설치 가능
5. Amazon FSX Storage
1) Windows FSX
- EFS 는 Window 환경에서 지원하지 않음 --> EFX가 지원해줌
- SMB ,Window NTFS 프로토콜 지원함
- AD 사용자 인증 지원
- SSD 지원, 용량 확장 가능
- 다중 AZ 구성 가능
- data는 매일 무료로 백업됨
2) Lustre FSX
- 병렬 분산 파일 시스템 (대규모 컴푸팅용)
* Lustre : Linux 인스턴스용. 대규모 컴퓨팅을 위해 만들어짐
- 고성능을 요구할 때 (클러스터가 있는 경우, 고청능 컴퓨팅 필요할때)
- 수백만 IOPS , 겁나 짧은 대기시간
- S3 버킷과 통합 가능
- 온프레미스 서버에서 사용할 수 있음
6. FSX Deployment Option 배포 옵션
1) Scratch File System 스크래치 : 임시 저장소, 데이터 복제 X, 대신에 높은 성능
단기간 데이터 처리할 때 비용을 최적화하려는 경우
2) Persistent File System 영구 : 장기 보관, 데이터 복제 O, 동일한 AZ
민감한 데이터의 저장
7. Transfer Family 전송 제품군
- S3(API), EFS(네트워크 파일 시스템)를 사용하지 않고
오로지 FTP 프로토콜만 사용하고 싶을 때 이걸 사용
FTP용 AWS 전송 지원 (FTP, FTPS, SFTP)
- AD, LDAP으로 사용자 인증 가능
section 17 Decoupling 비동조화 applications: SQS, SNS, Kinesis, Active MQ
1. Amazon SQS
- 대기열 매세지 큐
- producer : 메세지를 보내는 자
- FIFO 방식
- poll-based (polling)
- Visibility timeout : 특정 기간안에 process가 끝나지 않으면 다시 큐에 들어옴. 최대 12시간
- Long polling 방식 : sqs에 메시지 들어오기전엔 (sqs에서) response를 안줌
** 가시성 시간 제한 (Component TimeOut)
SQS 대기열에서 다른 소비 구성 요소가 메시지를 수신 및 처리하지 못하도록 하는 기간
메시지의 기본 표시 제한 시간은 30초입니다. 최대 시간은 12시간
1) Standard queue 표준 대기열
초당 무제한 처리량 (무한 tps)
4일 동안 메시지는 대기열에 유지됨. 최대 14일
256kb 미만의 메시지어야 함
(order 미보존)
2) FIFO Queue : order 보존, (딱 한번 300tps)
3) Consuming Messages 소비자 메시지
consumper : EC2, Lamda
한번에 최대 10개의 메시지 받을 수 있음
4) 멀티 Consumer
sqs 대기열에 여러 소비자가 붙을 수 있음
소비자는 메세지를 보내면 삭제해야댐 (다른사람 메시지큐에도 보일 수 있음)
cloud watch 지표 : ApproximateNumberOfMessages (대기열 길이)
대기열 길이가 특정 수준을 초과할 때마다 경보 알람 ( 높을 수록 주문량이 많은 거임)
2. Amazon SNS (Simple Notification Service)
- Push notification, SMS, Email, Http endpoint
- 토픽 : "access point" - 카프카의 구독 같은 개념인듯
- multiple AZ 가능
- (SQS와 다르게) push-based
주제를 생성해서 사용자한테 전송
결제 관련 문자 송신이 필요하면
결제 == 주제임
결제 시 처리 대기열 == sqs <--폴링 : ec2의 메시지를 가져와서 분석함
3. Kinesis
Streaming data를 실시간으로 분석
3 타입
-
Kinesis Data Stream : 여러 샤드에 데이터 스트림을 보관 (24h ~ 7days 보관)
-
Kinesis Data Firehose : 바로 분석 , aws -> 데이터 저장소로 데이타 스트림을 로드
-
Kinesis Analytics : 위 두개에 같이 사용, SQL 또는 Apache Flink로 데이터 스트림을 분석
-
Kinesis Video Streams : 비디오 스트림을 저장
4, Kinesis VS SQL FIFO 의 데이터 주문 방식
1) Kinesis
3개의 샤드 (샤드는 == 도로임. 샤드가 3개면 도로개 3개임)
5개의 트럭이 있음. 트럭은 각각 트럭 ID가 있음.
*트럭 - 데이터 레코드
* 데이터 레코드가 데이터 스트림으로 전송되면 24시간 ~7일 데이터 저장됨
파티션 키가 있음 파티션 키에 맞게 도로 진입
(파티션 키 1번과 샤드 1을 해시함 -> 트럭 ID 와 매칭된 동일한 키는 동일한 샤드에 들어가게 됨. -> 초록 트럭은 3번만)
- 샤드가 많을 수록 성능 up
2) SQS FIFO
선입 선출
그룹 ID를 사용하지 않으면 모든 메시지가 순서(주문 순서)대로 사용됨
5. SQS vs SNS vs Kinesis
1) sqs
Pull data 모델 : 소비자가 데이터를 가져오는 모델
데이터가 처리되면 소비자는 대기열에서 삭제해야 함
Why? 다른 소비자가 읽을 수 없도록
소비자가 원하는 만큼의 작업자를 가질 수 있음
처리량을 프로비저닝할 필요가 없음.
* 프로비저닝 : 미리 할당하는 것
FIFO 대기열에서만 주문 가능
개별 메시지 지연 기능 (예: 30초), 소비자에게 메시지를 표시할 수 있음
2) SNS
Push data 모델
Pub/Sub 모델
많은 소비자들에게 주제를 퍼뜨릴 수 있음
SNS 주제 당 최대 12,500,000 천이백오십만명 의 구독자 확보 가능
한 번 SNS로 전송된 데이터는 영구적이지 않음
배달되지 않으면 잃어버릴 가능성이 있음
수십만개의 주제를 확장할 수 있음
처리량 프로비저닝할 필요 없음
SQS 와 결합 가능(FIFO 대기열이 있는 SNS 사용일 경우)
3) kinesis
두가지 소비 모드
- pull data (사용자가 kinesis에서 데이터를 가져옴 get)
샤드당 초당 2mb 를 얻음
- push data (데이터를 소비자가 푸시) : enhanced향상된-fan out
소비자를 위해 샤드당 초당 2mb
데이터를 재생(다시 생성?)할 수 있음
실시간 빅데이터일 경우 ETL이 필요함
kinesis 데이터 스트림 당 미리 원하는 샤드 수를 지정해야 함
(== 직접 샤드를 확장해야 함)
(== 처리량을 프로비저닝해야 함 )
즉!! sqs / kinesis 프로미저닝 O <=> sns 프로비저닝 X
section 18 컨테이너 ECS, Fargate, ECR & EKS
1. Amazon ECS (Elastic Container Service)
AWS Docker 컨테이너 서비스
EC2 인스턴스는 ECS 클러스터를 지원함 -->컨데이너는 쨌든 EC2 인스턴스에 배치됨
ECS는 어느 EC2에 배치할건지 도와줌
1) ECS 시작 유형
- EC2 시작 유형
EC2 컨테이너 인스턴스에는 ECS 에이전트가 심어져있음
ECS 가 이걸 실행해서 컨테이너를 만드는 거임
* 이 방법은 EC2 인스턴스를 생성한 후에 컨테이너 실행D이 됨
EC2 인스턴스에는 임의의 포트가 할당됨 (ALB 동적 포트 연결 기능으로 ELB에 해당 포트를 연결하여 서비스 노출 가능)
--> ALB 보안 그룹에서 오는 모든 포트는 다 허용하도록 EC2 보안그룹 설정해야함
- Fargate
EC2 를 따로 시작할 필요 없이 컨테이너를 시작할 수 있음
서버리스 오퍼링
Forgate 클러스터에서 ECS 새 작업으로 컨테이너 실행
작업이 많을 수록 ENI 가 늘어남? (Fargate 작업이 6개 -> ENI 6개 실행됨)
* ENI 고유 IP임
작업마다 고유 IP를 다 다르게 가지되, 포트는 다 그대로임
-> ENI 보안그룹에서 ALB로 오는 포트를 허용해야 함
- 두 방식으로 생성된 컨테이너 다 EFS와 마운트할 수 있음
-> EFS와 연결하려는 경우는 영구 다중 AZ 공유 스토리지를 갖는 것
2) ECS Task Role *******
- 작업을 만들 때 작업 역할을 첨부함
- 각 작업은 특정 역할을 가질 수 있음
* ex) 특정 작업만 S3, 또는 DB에 액세스하도록 허용하게 할 수 있음
--> 보안 유리
2. ECS Scaling 확장
- cloudwatch metric으로 특정 자원 사용량을 넘기면 자원 확장 가능
(EC2 Farget 둘다 가능)
EC2의 경우, Ec2 수를 확장해야할 수 있음 - Ec2가 ECS 용량 공급자이기 때문
- SQS 대기열을 이용한 확장
SQS에서 읽어오는 메시지로 인해 대기열이 많아질 때 이로인한 확장
3. ECS 업데이트 -> Rolling Update 약간 ECS버전 블루그린임
최소 작업 백분율, 최대 작업 백분율
모든 작업은 종료되고 시작할 때 업데이트된 새 버전으로 시작하게 됨
ex
최소 4, 최대 100일 때 작업이 AA AA 가 있을 경우
AA AA
AA
AA BB
BB
BB BB
4. ECR
Elastic Container Resistry
스토리지 측면에서 컨테이너 사용함. (s3 통합)
5. EKS
Elastic Kubernetes Service
도커와 다르게 쿠버네티스는 오픈소스임
모든 클라우드 환경에 공통되는 거임 (단일 클라우드 제공업체에 구애받지 x, 에저, aws, 구글클라우드 등에 공통)
-> 마이그레이션 시 유리
도커처럼 ec2 시작, fargate 시작 유형 있음
eks node가 있음, 컨테이너 오토스케일, alb 연결하여 어플리케이션 노출 가능
6.미션 크리티컬 및 비필수 배치 작업
ECS를 컨테이너 관리 서비스로 사용한 다음 미션 크리티컬 및 비필수 배치 작업을 각각 처리하기 위해 예약 및 스팟 EC2 인스턴스의 조합을 설정하는 것입니다. 1년 기간 동안 지정된 시작 시간과 기간으로 매일, 매주 또는 매월 반복되는 용량 예약을 구매할 수 있는 정기 예약 인스턴스(정기 인스턴스)를 사용할 수 있습니다. 이렇게 하면 미션 크리티컬 배치 작업을 처리할 수 있는 중단 없는 컴퓨팅 용량을 확보할 수 있습니다.
section 19 Serverless
1. Lambda
서버리스 서비스.
코드만 배포하면 됨
자동 오토스케일 지원
온디맨드로 실행될때만 비용 지불함
실행제한시간이 있고 짧은 실행시간?
도커 이미지 실행 시 ECS / Fargate 사용할 수 있음 -> 도커에서 이미지 구현이 되어야 함.
환경변수 암호화 == 암호화 도우미 사용
* 람다는 기본적으로 kms로 암호화하긴 하지만, 어쨋든 중요한 정보가 노출이 된다고 함 그래서 암호화 도우미 사용해야댐
1) 장점
비용 계산이 쉽다
- 실행 시간에 따라 비용 계산 (수신 요청 수, 호출 횟수, 컴퓨터 시간 등)
- 프리티어 존재함(1백만 요청까지)
많은 프로그램 언어 지원 (node jk - java - C# - Powershell - Golang - ruby - custom API Runtime 등)
cloud watch 모니터링 가능
최대 10gb 프로비저닝 가능하며, RAM 함수를 늘리면 능력 향상됨
2) 한계 **
- 메모리 할당 : 128m ~ 10gb
- 최대 실행 시간 : 900초 = 15분
- 환경변수 : 4kb
- disk 임시 공간 = /tmp 512 mb
- 최대 동시 요청 최대 1000
- 배포 : 압축 zip - 50mb / 압축 안했을 경우 250mb (더 큰 파일일 경우 /tmp 이용)
2. Lamda@Edge -> 람다 함수를 cdn으로 배포
전 세계, 각 지역에 cloudFront CDN을 이용하여 Lamda 함수를 배포한다.
더 빠른 애플리케이션 빌드를 위해
lamda로 cloudfront의 사용자 응답/요청을 수정할 수 있음
User --- (viewer request) --> Cloud Front -- (origin request) --> Origin
<- (origin response --- <- (origin response) --
- viewer request : cloudfront가 시청자로부터 요청을 받아 요청 수정
- origin request : cloud front 가 요청을 전달하기 전
- origing response : cloud front가 응답을 수신 (origin에서 응답 수정)
- viewer response : clound front가 전달하기 전, 시청자 반응 수정
원본에 요청을 보내지 않고 viewer request를 사용하여 응답
Step Function
서버리스 컴퓨팅에 사용되지만 여러 AWS 서비스를 서버리스 워크플로로 조정하는 직접적인 방법을 제공
애플리케이션이 실행될 때 Step Functions는 애플리케이션 상태를 유지하여 애플리케이션이 어떤 워크플로 단계에 있는지 정확히 추적 후 애플리케이션 구성 요소 간에 전달되는 데이터의 이벤트 로그를 저장합니다.
즉, 네트워크에 장애가 발생하거나 구성 요소가 중단되는 경우 애플리케이션이 중단된 위치에서 바로 시작할 수 있습니다.
3. Dynamo DB
확장 가능한 DB는 DynamoDB
Elastic cache(메모리의 캐시)의 서버리스 버전 (elastic cache를 프로비저닝 가능)
-> 밀리초 미만의 성능은 아님 / 1 또는 9밀리초의 성능
고가용 (multi AZ)
NOSQL (관계형 DB 아님) ,SQL 수행 못해 '
* 관계형과 다르게 스키마 변경에 유연하다!!
수평 확장 분산형 db
처리속도가 빠름 (적은 지연)
IAM 으로 관리 가능
프로비저닝 필요 없음
KMS 암호화 활성화 가능
멀티 AZ
한자리수 밀리초 성능
완전 관리형 클라우드 데이터베이스이며 문서 및 키-값 저장소 모델을 모두 지원합니다. 유연한 데이터 모델, 안정적인 성능, 처리량 용량의 자동 확장을 통해 모바일, 웹, 게임, 광고 기술, IoT 및 기타 여러 애플리케이션에 적합
1) 기본
- 테이블을 만듬 (DB의 개념이 없음)
테이블은 기본 키가 있으며, 기본 키는 생성 시 결정
각각 테이블은 무한한 수의 행을 가질 수 있음
기본 키에 대해서만 쿼리할 수 있음
- 최대 400 KB 지원하며, 큰 객체를 저장하는데 적합 X
- 데이터 지원 타입
1) Scalar 스칼라 타입 : String, Number, Binary, Boolean, Null
2) Document 타입 : List Map
3) Set 세트 타입 : String Set, Number Set, Binary Set
2) Table
- 기본 키는 하나 또는 두 개의 열로 만들 수 있음
기본 키가 아닌 다른 항목은 속성이라고 함.
행이나 항목은 데이터일 뿐
4. 테이블의 용량 제어 방법**
- DynamoDB 실행 후 테이블에 필요한 읽기, 쓰기 용량만 정의한다.
->EC2에서 프로비저닝 따로 필요 없음
1) Provisioned Mode (default)
- 미리 읽기 RCU /쓰기 WCU 양을 지정 후 그만큼 비용을 냄
* Read / Write Cost Unit
- DB 부하 만큼 오토스케일 가능함
- capacity plan 용량 계획이 미리 필요함
2) On-Demand Mode 주문형
- 읽기쓰기 용량을 자동 확장
- 유연하지만 더 비쌈 (2~3배)
- 용량 게획 필요 없음
- 예측할 수 없는 워크로드일 경우 사용
cloudwatch 모니터링 : DynamoDB 테이블 데이터의 변경 사항이 아닌 서비스 지표만 모니터링
DynamoDB 테이블에 새 항목이 생성될 때마다 CloudWatch 경보를 사용하여 Lambda 함수를 트리거할 수 XXXX
5. DAX (DynamoDB Accelerator)
- DynamoDB를 위한 고가용성 메모리 캐시 기능
- 가장 많이 읽은 데이터를 캐싱하여 읽기 혼잡을 줄임
- 어플리케이션 로직을 변경할 필요 없음
- 어플리케이션 -- DAX 클러스터 --> D
- Dax VS ElasticCache
DAX : Dynamo DB용
Elasticache는 Memcached 또는 Redis를 기반으로 하는 캐시 엔진으로 RDS 엔진 및 DynamoDB와 함께 사용할 수 있습니다.DAX는 AWS 기술이며 DynamoDB에서만 사용할 수 있습니다.
6. DynamoDB Stream
테이블의 실시간 변경사항 저장하고 싶을 때
테이블 항목을 생성, 업데이트 , 삭제할 때마다 Stream에 저장 (24시간까지 보관)
Lamda, Kinesis로 보낼 수 있음
7. Global Table
- 데이터를 여러 지역에서 짧은 대기 시간으로 액세스
어플리케이션은 테이블을 어느 리전에서나 읽을 수 있음
쓰기 - -> 다른 지역애들이 복제 (양방향 복제)
- DynamoDB Stream이 활성화돼있어야 함
8. DynamoDB TTL - 특정 달의 데이터만 유지하려는 경우 TTL 설정해서 자동 삭제
9. Indexes 인덱스 : 높은 수준에서 인덱스 이외 속성에 대한 쿼리 수행
속성에 대해 쿼리하려는 경우 테이블 위에 인덱스(GSI / LSI)를 생성해야 함
1) GSI (Global Secondary Indexes) 글로벌 보조 인덱스
2) LSI (Local Secondary Indexes) 로컬 보조 인덱스
10. Transaction
두 개 테이블 사용할 수 있음??
11. API Gateway (람다 짝꿍)
AWS 어떤 서비스에 대해 API 를 노출하여 프록시
람다 함수가 지원하는 Rest API 노출 하여, 클라이언트와 람다 함수에 Proxy
HTTP 앤드 포인트 (ALB 등) 을 둘 수 있음
- Lamda + API Gateway : 서버리스
- 웹 소켓 프로토콜 지원
- API 버전 별로 관리할 수 있음 (여러 환경 처리)
- 인증, 권한 부여에 대한 키 생성 가능
- API 응답 캐시
- 서버리스에 최적화된 RestAPI , Websocket API 구축
- 수신 / 전송된 데이터 양만큼 비용 지불
- GraphQL 과 유사한 쿼리 언어 제공
- 하나 이상의 애니케스트 IP 제공
1) API Gateway 를 배포하는 세 가지 방법 (Endpoint Type)
- Edge-Optimized (default) 앳지 최적화 : Cloud Front를 통해 gateway를 여러 지역에 배포
- Regional : 클라이언트가 같은 리전 내에서 생성하고 싶을 때
- Private : 프라이빗 API 게이트웨이에만 액세스할 수 있도록 VPC에서 ENI용 인터베이스 VPC 앤드포인트를 사용
또는 리소스 정책 사용
12 API gateway 보안 증명
1) AMI : api gateway를 호출해서 AMI 자격증명을 얻은 후 앤드포인트에 접근
- rest api w sig v4를 사용해서 호출
- 추가 비용이 없음
2) Lamda Authorizer 람다 맞춤 승인전달되는 토큰을 사용하기 위해 람다를 사용
요청 헤더에 인증 결과를 캐시해서 그때그때 람다를 호출 할 필요 X
OAuth / SAML / 3rd party 인증 타입시 사용
람다 호출 당 비용 지불(호출 제한 둘 수 있음)
3) 사용자 인증 Cognito
사용자 정의 코드를 구현할 필요는 없고
인증하는 것만 구현함
페북 로그인, 구글 로그인 등 지원 가능
13. Cognito --> 페북/구글 간단 로그인 생각하면 댐
사용자에게 서버 어플과 연결할 수 있도록 ID 제공
- Cognito User Pools (==CUP)
앱 사용자를 위한 로그인 기능
모바일 앱을 위한 서버리스 사용자 데이터베이스임 (간단 로그인)
-> Json 웹 토큰 (JWT)를 얻어서 사용자 신분 확인 가능 -> API GW에 통합
다단계 인증 사용 가능
API Gateway와 연동됨
페북, 구글, SMAL을 통해 사용자 풀에 ID를 가져옴
- Cognito Identity Pool 자격 증명 (==Federated Identity Pool)
클라이언트 측에서 AWS 리소스에 직접 액세스 -> 프록시x , api x
페더레이션 ID 공급자에 로그인 -> 임시 AWS 자격증명을 얻음
- Cognito Sync --> 이제 안써
장치에서 Cognito로 데이터 동기화
더이상 사용되지 않으며, App Sync로 대체됨 (시험 x)
14. SAM (Serverless Application Model)
서버리스 어플리케이션 모델
서버리스 어플리케이션 구성을 위한 YAML 코드
람다 함수 구성 / DynamoDB Table / API Gateway / Cognito
section 20 AWS에서 올바른 Database 선택하기
1. RDS
2. Aurora
3. ElasticCache
4. Dynamo DB
5. S3
6. Athena (데이터베이스는 아님)
7. Redshift
- PostgreSQL 기반 사용
- OLTP 에는 사용하지 않음
- 온라인 분석 처리를 위한 OLAP (온라인 거래 처리)
- 데이터는 행 대신 열에 저장됨 .
- 대규모 병렬 쿼리 실행 엔진(MPP)
- 인스턴스 프로비저닝 된 노드 당 비용 지불
- 노드 유형 - Compute node : 쿼리 수행, 결과를 리더에게 보냄
- Redshift Spectrum : 쿼리를 직접 수행하는 데 사용되는 S3를 클러스터에 추가 (데이터 로드 필요 없음) -> s3가 db임
Redshift를 이용하여 분석하려는 경우
주의 : 이미 사용 가능한 redshift 클러스터가 있어야 함
쿼리하려는 테이블이 S3에 있어야 함
- 백업 및 복원 가능, IAM , KMS
- 라우팅 : Redshift Enhanced VPC Routing - VPC를 통해 공공인터넷에 연결됨
upload, copy는 s3를 통과
- Multi 다중 AZ 모드 없음. 모든 클러스터는 하나의 가용 영역에 존재
스냅샷은 클러스터의 특정 시점 복원
클러스터를 다른 리전에서 생성 후 수동이든 자동이든 복사해야 함
자동 백업 (8시간 5gb 마다 보존 설정) , 수동 스냅샷은 수동으로 삭제해야 삭제됨
- Redshift로 데이터를 수집하는 방법
1) Amazon Kinesis Data Firehose --> 스트리밍 데이터를 캡쳐하고 변환
데이터를 수신할 Firehose가 있음.
다양한 출처 -> Redshift로 데이터 전송(s3 버킷으로 쏘면 firehose 자동으로 실행)
2) S3 복사 명령 실행
Redshift에서 S3 버킷의 데이터를 복사해옴 (인터넷을 통하든, VPC 라우팅으로 프라이빗하게 쨋든 가져옴)
3) 데이터 삽입
EC2 인스턴스 및 어플리케이션에 데이터를 삽입해야 하는 경우
Redshift 클러스터에 JDBC 드라이버를 사용
- Athena < Redshift 보다 더 빠른 쿼리 제공
- 기억하자 : Redshift == Analytics / BI / Data Warehouse
비즈니스 인텔리전스, 데이터 웨어하우징 솔루션
8. Glue
- ETL 서비스 (extract 추출, transform 변환 , load 로드)
- 분석을 위해 데이터 변환
- 완전 서버리스임
S3/ RDS 가 Glue ETL에서 데이터를 가져옴
- Catalog
메타데이터 = 데이터에 대한 정보를 의미
- Glue Data Crawlers
JDBC와 호환되는 모든 DB 엔진에서 데이터를 크롤링
-> 크롤링 결과 데이터를 카탈로그에 넣음
9. Neptune
- 관리형 그래프 데이터베이스
관계 데이터가 높을 때 그래프를 사용함
ex ) 소셜 네트워킹 : 얘는 쟤랑 친구고 누구한테 좋아요를 누르고 이런 데이터들
한 기사에 다른 기사에 대한 링크 첨부 이런 다이어그램들
3개의 Multi AZ 고가용성
KMS 암호화, HTTPS 지원 , IAM (RDS랑 유사함)
클러스터링 사용 가능
10. Elasticsearch
DB에 대한 모든 필드를 검색 가능.
기억하자 : Elasticsearch = Search / Indexing 집계
부분적으로 일치하는 항목 검색 등
DB 로 데이터를 저장 + ElasticSearch로 검색하는 기능을 많이 사용함
(Graylog=mongodb + elasticsearch)
데이터 수집을 위해 통합 기능 제공 (kinesis, data firehose, aws IOT, cloudwatch 등)
오픈소스임
보안 : IAM, KMS, SSL 및 VPC 보안
시각화 : Kibana
로그 수집 : Logstash
비용 : 인스턴스 수, 프로비저닝한 클러스터 수에 따라 비용 지불
section 22 Monitoring (Cloud Watch , Cloud Trail) , Audit (Config)
1. Cloud Watch
1) Meric
- AWS 서비스에 대한 Metric을 제공
Metric : 모니터링으로 측정한 값 (cpu 사용률 등)
EC2의 경우 5분마다 측정하지만, 세부 모니터링 활성화 시 (비용발생) 1분마다 측정 가능
단, Ram 측정량은 커스텀으로만 측정 가능함
10개 메트릭 설정까지는 무료임
2) Custom Metric
사용자 정의 측정 항목
RAM 측정, 인스턴스 id 등등 지정 가능
기본은 1분단위 측정이지만, 더 짧게 설정할수록 비용이 나감
기억하자 : EC2 인스턴스 시간이 실제 메트릭과 동기화가 되어야 함.
과거 측정 내용은 오류가 발생하지 않음
타임스탬프로 최대 2주까지 측정기간 지정할 수 있음
3) Dashboards
글로벌함. 여러 지역의 걸쳐 표시 가능
다른 계청의 그래프를 포함할 수 있음 **
대시보드를 다른 사람들과 공유할 수 있음 (AWS 계정이 없는 사람도 공유 가능)
자동 대시보드로 만들어진 템플릿이 여럿 있음
2. CloudWatch Logs
- 어플리케이션에서 로그를 보내서 측정 (SDK를 통해 cloudwatch에 전달)
- 어디서 로그 수집을 가져오는가?
Elastic Beanstalk : 어플리케이션
ECS : 컨테이너
Lambda : 함수 로그 (function log)
VPC : VPC 흐름 로그
API Gateway 로그
CloudTrail (필터를 설정한 경우)
EC2 인스턴스에 로그 에이전트를 설정한 경우 Cloud Watch
Route53 : DNS 쿼리
- 로그를 받아서 어디에 보내는가?
S3 또는 Elasticsearch 클러스터 (로그 검색을 위해)
- 로그 그룹 설정하여 저장할 수 있음
-> 로그 스트림을 얻음 (로그 스트림 만료 정책 설정 가능)
-> 30일동안 유지하려면 로그를 S3로 보내고 cloudwatch에서 삭제
- CLI 사용 시, IAM 권한이 없으면 작동 안할 수 있음
- EC2
기본적으로는 로그 발생 안함
EC2에 agent 설치를 따로 해주고 시작해야 함 (CloudWatch Log Agent)
인스턴스에 IAM 역할 있어야 함(로그 보낼 수 있도록 정책 추가)
3. cloud logs Filter Expressions 필터 표현식
- 로그 내 특정 IP 검색 가능
- 메트릭 필터 : 메트릭을 제공해야 하며, 정의한 필터를 기반으로 알람 발생
특정 IP에 대해 메트릭 설정 가능->알람 발생
4. Cloud Watch Log Insights
로그 쿼리 기능 제공 (로그를 쿼리하여 대시보드에 추가)
쿼리를 직접 추가할 수 있음
5. Cloud Watch Agent
Log Agent & Unified 통합 Agent
- 둘 다 가상서버용임 (EC2)
- Log Agent가 구식이고 통합이 최신임
- log agent는 로그만 보내고, 통합은 log랑 메트릭이랑 다 보냄
- 통합 에이전트 측정 항목 (더 높은 수준의 세분화된 모니터링)
CPU , Disk Metric, RAM, Netstat (TCP/UDP), Process , Swap Space
6. Cloudwatch Alarms
- 모든 측정 항목에서 알림을 트리거할 때 사용
cli로 트리거를 임의로 발생시킬 수 있음 (테스트를 위해)
- 알람 상태
OK :트리거되지 않음(정상임)
Insufficient_Data : 수집 데이터가 부족함
Alarm : 임계값 위반으로 인한 알람 발생
- 알람 대상 예시
EC2 : 중지, 종료, 재부팅
ASG : 스케일 인, 아웃
SNS : sns 송신
7. EC2 인스턴스 복구
특정 인스턴스를 모니터링함. (하드웨어 상태 체크)
알람 트리거되면 인스턴스 복구 작업을 수행할 수 있음
동일한 사설 IP, 탄력적 IP, 동일한 그룹 내 복구됨
8. Amazon EventBridge
cloudwatch 이벤트 상위 호환
cloudwatch 이벤트 사용 시 default로 bus를 생성함 (cloudwatch event)
cloudwatch 이벤트를 기반으로 구축하고 확장함
SaaS기반 (또는 고객 어플리케이션 기반)의 이벤트 버스가 있음
스키마 레지스트리
9. CloudTrail - 어떤 행위에 대해 감시
AWS 계정에 대한 규정 준수 및 감사 (기본적으로 활성화되어 있음)
계정 내 모든 이벤트의 기록을 얻을 수 있음
계정에서 이루어진 API 호출, CLI 콘솔, SDK 등의 로그가 표시됨
CloudWatch Log 또는 S3로 로그 전달 가능
누군가가 어떤 작업을 했을 때 CloudTrail에 표시 가능
이벤트 :
읽기 이벤트 , 쓰기 이벤트가 존재 (리소스를 수정했느냐)
데이터 이벤트는 발생하지 않음 (작은 이벤트, s3에서 get , delete, put 등)
CloudTrail Insight 이벤트 (비용 발생)
관리 이벤트가 많을 때 이벤트를 분석해줌
비정상적인 활동 감지
*헷갈 ㄴㄴ :
CloudTrail 로그 는 Amazon S3에서 사용자, 역할 또는 AWS 서비스가 수행한 작업(행위)에 대한 기록을 제공하는 반면
Amazon S3 서버 액세스 로그 는 S3 버킷에 대한 요청에 대한 자세한 기록을 제공
10. AWS Config -> 변경 내용 확인
감사를 박을 수 있는 서비스
언제 누가 무엇을 변경했는가
리소스의 규정 준수를 기록
SSH 보안 그룹에 대해 아무나 접근 가능한지
S3 버킷에 아무나 접근 가능한지
갑자기 ALB 구성이 변경되었을 때
--> 알림 또는 sns 알림 보낼 수 있음
이런 것들을 집계해서 데이터 저장, 분석 가능
기본 75 구성이 있고, 직접 정의 가능
알림을 발생하기만 하지, 행위를 막진 않음 (no deny)
규정 미준수인 애들을 문서로 출력할 수 있음
알림 : Event Bridge 또는 SNS 를 이용하여 트리거
11. CloudWatch VS CloudTrail VS Config 간 구분 ***
1) cloudwatch (성능 지표)
성능 지표를 위해 대시보드 생성
이벤트 알림 받고, 로그 집계 분석 가능
ex ) elb에서 오는 연결 수 , 오류 코드의 수를 시각화
2)cloud trail (누가 무엇을 했는가?)
모든 계정에서 발생한 API 호출을 기록하는 것
특정 리소스에 대해 일부 추적 정의
ex) API 호출로 elb 구성을 누가 변경을 수행했는가 추적
3)config (무엇이 변했는가? 규정준수에 맞는가?)
구성 변경 사항을 기록
리소스 규정 준수를 평가하기 위해
ex ) elb의 구성 변경사항 확인
section 23 IAM (Identity and Access Management)
1. STS (Security Token Service)
모든 서비스에 대한 임시 액세스 토큰 제공 (15분 ~ 최대 1시간 유효함)
Assume Role (보안 강화를 위해) 사용할 수 있음 - ex 특정 계정에 특정 권한 적용
Assume Role With SAML : 사용자 증명을 SAML 을 통해 함
Assume Role With Web Identity : ID 공급자를 통해 로그인됨. 구글, 페북 로그인 등의 자격증명으로 반환됨
GetSesstion Token : 다단계 인증을 위한 토큰 (MFA 인증 시 사용)
기억하자 : 교차 계정 액세스 (Cross Account Access), Assuming Roles == STS
2. Identity Federation
ID 연합
- 외부 사용자가 AWS의 임시 역할을 맡음
- SMAL , Custom Identity Broker 등으로 페더레이션 수행
- 페더레이션을 수행하면 IAM을 생성할 필요 없음 (user는 AWS 외부에서 관리되기 때문)
외부 사용자가 AWS가 아닌 외부에 로그인을 한 후 AWS 리소스에 액세스함 (AWS 외부 소스를 신뢰해야함)
임시 자격증명 얻는 수단
- SAML 2.0 반환 : AD 통합 (ADFS - AWS)
ADFS 가 SAML과 호환되는 경우, ADFS로 인증 후 SAML 반환
AWS IAM과 SAML 간 신뢰 양방향 설정 필요
웹 기반 교차 도메인 (SSO) 활성화 필요
API AssumeRoleWithSAML 사용
federation SAML 방식은 이전 방식임
- SAML 2.0과 호환되지 않을 경우
AssumeRole API 또는 Get Federation Token API 사용
자격증명을 제공하는 건 STS와 통신할 ID 브로커임
3. Cognito (추천)
- 외부 클라이언트 -> AWS 리소스로 직접 액세스 제공
- 외부에서 접근하고자 하는 사용자가 겁나 많을 때 일일히 IAM 사용자를 만들 수 없음
-> cognito 사용하여 ID 연합 사용
- 접근 방식
외부 ID 제공자에 클라이언트 로그인 -> coginto API 가 AWS 리소스 액세스 자격증명을 받음
-> 로그인 ID 토큰을 받음 STS -> 임시 자격증 얻음
4. Microsoft AD 및 AWS Direcrtory Service
중앙집중식 보안 관리
Microsoft AD : 모든 Window 서버에서 찾을 수 있는 AD 서비스
도메인 컨트롤러 : 계정을 만듬
모든 window 시스템은 도메인 컨트롤러에 접근하여 로그인 인증함
AWS Directory Service (** 3가지 차이 이해 필요)
1) AWS Managed Microsoft AD
AWS에서 고유한 Active Directory 생성
로컬에서 사용자 관리 가능
MFA 지원
온프레미스 AD와 연결가능
2) AD Connector
프록시
온프레미스 - Gateway 간 프록시
사용자는 온프레미스 AD로 단독 관리됨
3) Simple AD
AWS의 AD 호환 관리형 디렉터리
AWS 의 AD로만 관리됨
온프레미스 AD와 조인할 수 없음 (온프레미스 AD가 없는 경우)
5. Organizations 다중 계정
글로벌 서비스
여러 AWS 계정을 관리할 수 있음
- 마스터 계정: 변경할 수 X
- Other 계정 : 조직 내 다른 계정
- Member 회원 계정 : 하나의 조직에만 속할 수 있음 (조직을 이동할 수 있음 =마이그레이션)
OU 내 회원 계정 제거 -> 새 OU 조직에 계정 초대
root 계정을 마이그레이션 하려는 경우, 그 안의 모든 단일 계정을 함께 마이그레이션한 후 OU 삭제
- 모든 계정에서 통합 결제를 할 수 있음 (마스터 계정 아래로)
- API로 AWS 계정을 생성할 수 있음
- 부셔별, 비용별, 환경별(서비스 제한) 계정 생성할 수 있음 -> OU 생성하여 구성
- 청구 목적을 위한 태그 지정 가능
6. IAM 고급
1). IAM Condition 옵션
aws:SourceIP - API 호출이 이뤄지는 클라이언트 IP 제한
Aws:RequestedRegion - API 호출이 이뤄지는 지역 제한
StartStopTags - 태그기반 제한 (ex ec2:ResourceTag)
MultiFactorAuthPresent - MFA 인증이 안되어있으면 거부
2) S3 용 IAM
- 특정 리소스에서 특정 버킷에 행위를 허용함
- 둘의 차이를 아는게 중요함 **
개체 수준 권한* > GetObject / PutObject / DeleteObject 권한을 객체에 할당
> arn:awn:s3:::test/*
버킷 수준 권한 > arn:aws:s3:::test
3) IAM Permission Boundaries 권한 경계
최대한으로 얻을 수 있는 권한에 대해 경계를 지을 수 있음
7. AWS Resource Access Manager (RAM)
다른 계정과 리소스를 공유 가능
보안 그룹은 공유 X
공유된 사람은 리소스 수정 안됨
기본 VPC 내 공유된 사용자만 공유됨
8. SSO (Single Sign-On)
- 계정 중앙 관리
- 여러 계정에 액세스 및 타사 어플에 액세스할 때
SSO 포털로 로그인하면 모든 AWS 계정에 로그인할 수 있음
(연동되어있는 o365, slack 등에 다시 로그인을 입력하지 않아도 됨)
- SMAL 2.0 / 온프레미스 AD와 통합됨
기억하자 : 여러 AWS 계정 또는 비즈니스 어플리케이션에 SAML2.0이 필요한 경우== SSO
- SSO vs Assume Role With SAML 과 차이 알기
1) Assume 은 타사 ID 로그인 포털을 설정해야 함
그리고 SMAL 을 보내야 함, 올바른 SAML을 사용하려면 STS에서 자격증명 토큰을 얻어옴
2) SSO 은 브라우저 인터페이스가 로그인(로그인 포털 자체가 SSO 서비스임) 추가로 설정 필요 X
section 24 Security & Encryption : KMS , SSM , HSM, Shield, WAF
1.Encryption 방식
1) SSL 암호화 - Encrryprion in flight
데이터는 내가 보내기 전에 암호화하며, 받기 전에 복호화함
HTTPS 암호 인증을 지원함
중간에서 공격하는 행위로부터 보호받음
2) 서버 측 암호화
데이터는 저장 시 암호화
클라이언트에 보내기 전에만 복호화
data key라는 키 덕분에 암호화된 형태로 데이터가 저장됨
이렇게 저장된 키는 KMS(키 관리 서비스)로 관리됨
데이터를 검색할 때 데이터 키로 복호화
3) 클라이언트 측 암호화
클라이언트에 의해 암호화 되고, 복호화도 클라이언트가 함 (서버 복호화 X)
== 데이터 키가 클라이언트한테 있다는 말임
2. KMS (Key Management Service)
- 일반적으로 서버 암호화는 KMS일 가능성 높음
- IAM과 통합됨 (모든 게 IAM으로 관리됨, 마마보이임)
- API 호출에 대해 비용 지불 (10000 건당 0.03$)
- 건당 최대 4kb 킬로바이트 데이터만 암호화하 수 있음
더 많은 데이터를 암호하하려면 envelope 암호화를 써야 함
- 언제 사용할까
민감한 정보를 공유해야 할 때
외부 서비스에 대한 자격 증명
SSL 인증서의 개인 키
- 다른 사람에게 KMS에 대한 액세스 권한을 부여하려면?
사용자가 키에 액세스 가능하도록 허용
API 호출을 허용하는 IAM 정책
--> 두가지가 모두 있어야 함
- 한 지역에서만 제한됨(리전 A 키전 키를 B 리전에서는 사용할 수 없음. B에서 키를 새로 만들어서 지정해야 함--> 스냅샷 암호화 볼륨을 복사할 때 다시 암호화해야 함)
1) CMK (Customer Master Key) 고객 마스터 키
- 대칭 키 Symmetric (AES-256) **
데이터 암호화 시 단일 암호화 키 사용
대칭 키 생성할 때 해당 키를 사용하려면 KMS API를 사용해야 함
- 비대칭 키 Asymmetric (RSA & ECC key pairs) 키 쌍
키가 두개임 (암호화 -> 공개키 , 복호화 -> 개인 키로 함)
서명/확인 작업 사용 사례
2) CMK 타입
- AWS 기본 관리형 서비스 : EBS 키 사용시 무료
AWS 소유 CMK (AWS Owned)
AWS 관리형 CMK(AWS MAnaged)
고객 관리형 CMK (Customer Managed)
- User Key create : 자신의 키 만드는 경우 월 1$
- User key imported : 자신의 키를 가져오는 경우(대칭키여야 함)- 월 1$
3) KMS Policies
S3 policies 정책과 유사하지만,
키 정책을 지정하지 않으면 아무도 키에 액세스할 수 없음. S3는 여러 방법이 잇음
4) 스냅샷 교차 계정 복사
스냅샷 생성 시 CMS 로 암호화됨
키 정책 첨부
해당 키에 교차 계정 액세스를 승인 (대상 계정이 KMS 키를 읽을 수 있도록 허용)
암호화된 스냅샷 공유
대상 계정은 스냅샷을 이용해 볼륨 생성
3. KMS Automatic Key Rotation
-고객 관리형 CMK용 (AWS 관리형 CMK가 아님)
-enable 했을 때 자동으로 1년이 지나면 키가 rotate 돼서 새 키로 바뀜
-기존의 키는 유지됨 (예전의 데이터를 볼 수 있다는 것)
- rotate 돼도 CMK ID는 동일하다는 것
- 수동으로 rotate 할 수 있음 (90일 또는 180일 가능)
새 키를 만들고 이름 (Alias)를 기존키랑 똑같이 함
그럼 수동으로 rotate 실행 시 어플리케이션이 변경된 키를 인식해서 연결함
기존의 키는 유지되며, 새 키는 새로 만든거니까 CMK ID는 달라짐)
- key alias는 업데이트 할 때 update alias api가 있음
4. SSM Parameter Store
- SSM 매개변수 저장소
- 서버리스 KMS 암호화를 위해 사용
- SDK를 사용함
- 보안 구성 저장용 스토리지
보안 구성의 버전 관리가 필요할 때
- 접근제어 - IAM 정책
어플리케이션에서 SSM에 파라메터를 불러오려고 할 때 IAM 권환 확인
암호화 구성에 대해 가져오려 하면, KMS 권환도 확인해야함 -> KMS에서 해독 API 호출
- 모니터링 - cloudwatch
- 매개변수 cloudFormation과 통합
- 저장소 내 계층 분류 가능 (/test/testtest 이렇게 하위 디렉토리 분류 가능)
- 매개변수 계층 (Tiers) ***
1) 표준 계층 Standard
계정 당 최대 10000 매개변수까지 무료 지원 (4kb)
2) 고급 계층 Advanced
계정 당 100,000 매개변수까지 가능 (최대 8kb)
매개변수 비용 지불
- Parameters Policies (고급 계층의)
TTL 할당해서 만료 날짜 설정 가능 (업데이트, 삭제)
한번에 여러 정책 할당 가능 -> 만료 정책과, cloud watch 알람 조합 등
5. Secrets Manager
비밀 저장할 수 있는 또 다른 서비스임 (SSM 저장소 이후에 나옴)
비밀 관련 데이터를 자동 Rotate 할 수 있음 (X day) --> Lambda 사용
예를 들어, RDS와 통합할 경우 데이터베이스 비밀 관리자가 되는 거임
KMS 암호화
6. Cloud HSM
- KMS => 소프트웨어 암호화 관리자 , AWS 키로 암호화
- HSM 장비 =>하드웨어 암호화 장비, 보안 모돌임 , 하드웨어 자체 키로 암호화함
- CloudHSM => 하드웨어 암호화 장비를 프로비저닝
- IAM 과 관리하는 부분 차이
IAM => HSM 클러스터 (읽기, 업로드, 삭제) 관련 권한 관리
CloudHSM Software => 키관리, 키 사용자 관리
KMS 와 다른 점은 KMS는 IAM마마보이임, 모든 게 IAM으로 관리 됨
- FIPS 140-2 Level 3 준수 (암호화 모듈 인증 표준)
- 대칭, 비대칭 암호화 키 지원 (SSL/TLS)
암호화 가속 설정 가능 (로드밸런서-ssl/tls , olacle 및 TDE Acceleration)
- 무료 아님
- 클라이언트 소프트웨어 설치해야 함
- Redshift와 통합됨 (database를 암호화하려는 경우)
- SSE-C 유형을 구현하려는 경우 유용함
- multi AZ 가능
- KMS 와 비교
KMS는 멀티 테넌트 <=> CloudHSM 은 단일 테넌트
AWS 소유, AWS 관리, 고객 관리 CMK <=> 고객 관리형 CMK만 있음
Audit : CloudTrail , CloudWatch <=> CloudTrail , CloudWatch , MFA Support
Free Tier <=> 돈내라
** 온프레미스에 비대칭 키를 사용하는 키 관리 시스템이 AWS로 이전 시 CloudHSM을 사용해야만 해
7. Shild (DDoS Protection)
- DDoS 공격을 막자잉
- 두가지 유형 있음
-- Shield Standard (표준) : 무료임
-- Shield Advanced (고급) :
월 $3,000 (공격땜에 수수료 나온건 면제해줌)
EC2, ELB, Global Accelerator , Route 53 여러 서비스도 보호해줌
DRP 라는 ddos 대응 팀에 24시간 액세스 가능
8. WAF (Web Application Firewall)
웹 어플리케이션을 보호 (7계층)
SQL 인젝션, Cross Site Scripting (XSS) ***
배포 방법 3가지
ALB , API Gateway , CloudFront
웹 ACL 정의 필요 (웹 엑세스 제어 목록)
http 헤더 및 본문 또는 URL 문자열로 방화벽 규칙을 만들 수 있음
쿼리의 양을 조절하여 사이트 부하 줄일 수 있음
특정 국가 차단
IP는 초당 5개 이상의 요청을 수행할 경우 공격으로 감지함
Firewall Manager : AWS 조직 내 WAF 공통 보안 규칙을 관리함
9. GuardDuty
지능형 위협 검색,탐지 서비스 (AWS 계정 보호)
머신러닝 알고리즘을 사용함
30일 평가판이 있으며, 소프트웨어 설치 안해도 됨
- input data
CloudTrail 로그를 input 후 비정상적인 API 호출 등을 감지함
VPC 흐름 로그 트래픽에서 비정상 IP주소 감지
DNS 로그에서 DNS 쿼리 분석
- 모니터링 : cloudwatch 트리거
- cloudwatch 이벤트 규칙 타겟 : lambda, SNS 으로 알람 받음
**CryptoCurrency Attacks 암호화폐 거래소 해킹 공격 으로 보호할 수 있음
10. Ispector
EC2 인스턴스에 대해(Only) 자동화된 보안 평가를 수행한다 (== Azure Qualys)
- 실행중인 OS 취약점 분석, 네트워크 액세스 방지등 분석
- 취약점 보고서를 받을 수 있음 (보고서에 대한 알림을 SNS으로 보낼 수 있음)
- Inspector Agent 설치 필요
네트워크 분석용일 땐 설치 필요 없지만
호스트 내 수행 작업에 대해 분석 시엔 에이전트 필요함
11. Macie
데이터 보안 및 데이터 개인 정보 보호 서비스
AWS 내 민감한 데이터를 발견하고 보호 및 경고함
어떻게 찾냐? S3의 경우 대상 버킷을 지정함
12 . Security & Compliance 보안 및 규정 준수(각자의 책임)
적어도 2~3개 문제 나온대
- AWS 측 책임
AWS에서 사용중인 모든 서비스는 AWS의 책임
S3 , DynamoDB, RDS 와 같은 것들은 예를 들어 AWS의 책임
- 고객 측 책임
AWS 에서 제공하는 서비스를 사용하는 방법은 고객 책임
고객으로서 클라우드 보안을 책임져야 함
EC2 인스턴스의 경우 os업데이트, 방화벽 구성 등 책임을 져야 함
- 공유 책임
패치 관리, 구성 관리를 규정 준수 요구에 따라 같이 맞춰야 함
section 26 Disaster Recovery 재해 복구
1. 재해 복구
- 복구 유향
온프레미스 -> 온프레미스 : 겁내 비쌈
온프레미스 -> Cloud : 하이브리드 복구
cloud 리전 A -> 리전 B
- 용어 알기
RPO (Recovery Point Objective) : 복구 지점 목표
얼마나 자주 백업하는가 (데이터 복구 시 데이터 유실이 없게 함)
RTO (Recovery Time Objecive) :
어플리케이션 가동 중지 시간. 다운타임임.
- 재해 복구 전략 (밑으로 내려갈수록 더 비싸지만 RTO 작아짐)
백업 및 복원
스노우볼 뭐 이런걸로 함. RPO / RTO높음
파일럿 라이트 Pilot Light
중요한 핵심 복구할 때 서비스를 실행하면서 복구 가능 (RDS가 항상 실행해야 할때 등)
웜 스탠바이 Warm Standby
전체 시스템이 가동중일 때 복구
핫 사이트 Hot Site / 다중 사이트 접근 방식 Multi Site Approach
온프레미스, cloud 환경에서 데이터가 리플리케이션 됨
2. DMS (Database Migration Service)
- 온프레미스 데이터베이스 -> 클라우드로 이전할 때 사용
- 탄력적임
- 마이그레이션 중에도 DB는 계속 사용 가능
- CDC (Chage Data Chapture변경 데이터 캡쳐) 를 이용한 지속적인 데이터 복제 지원
- DMS를 사용하려면 EC2를 생성해야 함. 그 EC2가 복제 작업을 수행해 줌
연속 복제 설정 (Continue Replication)
- 여러 데이터베이스 엔진 지원함
- 만약 원본 데이터베이스와 대상 데이터베이스가 같은 엔진이 없을 경우
-> AWS SCT 사용 (스키마 Convert Tool) :한 엔진에서 다른 엔진으로 변환해줌
** 즉, 동일한 데이터베이스 엔진일 땐 SCT 사용할 필요 없다는 거임
온프레미스 PostgreSQL == RDS PostgreSQL 같은 엔진임 (RDS는 플렛폼, PostgreSQL은 엔진임)
3. 온프레미스 - > AWS 전략
- VM Ware, KVM ,등 온프레미스 이미지를 ISO 형태로 다운 -> 가상머신 IAM 이 됨
- VM Import / Export : 어플리케이션을 EC2에 마이그레이션 (반대도 가능)
- AWS Discovery Service (검색 서비스임) : 온프레미스 서버 검색해서 마이그레이션 계획에 유용 (종속성 등)
- AWS Migration Hub : 모든 마이그레이션 추적 (모든 마이그레이션에서 가능, aws -> aws 이것도)
- SMS (Server Migration Service 서버 마이그레이션 ) :라이브 서버를 AWS에 증분 복제 가능
4. Data Sync
온프레미스 -> AWS 로 많은 양의 데이터를 이전할때 사용
AWS -> AWS 데이터 이전
S3 동기화 때도 유용함
NAS 스토리지 데이터를 NFS , SMB 통애서 이전 가능
마이그레이션 스케줄 예약 가능
Data Sync 에이전트 설치해야 함
이전 시 대역폭 제한 둘 수 있음
vs storage gateway : 얘는 온프레미스에서 aws 스토리지 백업을 누리고 싶을 때 사용
5. AWS Backup
완전 관리형 백업 서비스
중앙 집중식 관리 가능 (AWS서비스 백업을 자동화)
AWS 에서 지원하는 대부분의 서비스 리소스를 백업하는 거임
PIRT 지원 : 주문형 서비스
주문형 및 예약 백업 지원함
태그를 기반으로 백업 생성
백업 정책 만들 때 백업 계획이 필요함 (예를 들어 백업 빈도, 보존 기간 설정 등)
section 28 Other Service
1. CICD
- Continuous Integration 지속적인 통합
개발자 코드 푸쉬 = github = aws CodeCommit
코드 빌드 및 테스트 = jenkins = aws CodeBuild
- Continuous Delivery 지속적인 배포 (테스트 후 배포서버로 배포함)
릴리즈 배포를 자동으로
CodeDeploy
- 순서
code : CodeCommit (=github) 코드 검사
build & Test : CodeBuild (=Jenkins)
Deploy & Provision : Elastic Beanstalk 코드 배포
Deploy만 : CodeDeploy
Provision만 : CloudFormation
얘네를 이어서 수행하기 위해서는 ==> AWS CodePipeline 으로 파이프라인 연결
2. Cloud Formation (가볍게 원리 이해 필요)
- AWS 구축한 인프라 자체의 코드 (다른 리전으로 똑같이 자동 배포 시 유용함)
- 배포할 코드는 Git으로 버전 제어 가능
- 비용 : 각 리소스에 부여되는 태그(스택)으로 리소스 비용 주적
- 기존 템플릿이 있어서 따로 안만들고 써도 됨
- YAML 형식
- CloudFormation StackSets
여러 계정에서 동시에 CloudFormation 스택 삭제 , 생성 가능
stackset을 업데이트 하면 다른 계정, 리전들 동시에 업데이트 됨
3. Step Funtions
람다 오케스트레이션 프로우를 서버리스에 빌드
JSON State Machine형태임
기억하자, Lambda의 오케스트레이션 , 워크플로 , State Machine 은 State Machine
4. EMR
Elastic Map Reduce (Reduce => 빅 데이터 용어임)
Hadoop 클러스터 생성을 지원하고 빅 데이터에 사용됨
클러스터는 수백 개의 EC2 인스턴스를 만들 수 있음
대부분의 엔진을 모두 사용 가능
모든걸 프로비저닝 가능, 스팟 인스턴스도 가능
5, Opsworks
Managed Chef and Puppet 의 또 다른 이름
Chef & Puppet ? => 자동 서버 구성 및 반복수행해주는 오픈소스 소프트웨어
온프레미스, AWS 둘다 가능한 소프트웨어임
구성을 코드로 관리하는 데 도움됨
일관성있는 배포 (많은 기계에 동일한 코드를 적용할 수 있기 때문에)
SSM 서비스의 일종의 대안 (둘이 유사함)
기억하자 Chef and Puppet == Opsworks
6. AWS WorkSpaces
관리형 보안 클라우드 데스크탑 (가상 클라우드 데스크탑 VDI )
VDI를 프로비저닝함
보안 암호화, 네트워크 격리 등 가능
사용한 만큼만 비용 지불 (온디맨드 액세스)
AD 통합 가능 (VDI에 액세스하기 위해)
기억하자 AWS 에서 VDI 구축 == WorkSpaces
7. AppSync
모바일 및 웹 앱에서 실시간으로 데이터를 저장하고 동기화 하는 서비스
GraphQL 사용자를 만듬 (페이스북에서 나온 모바일 기술이래)
클라이언트 코드가 자동으로 생성됨
기억하자 : 모바일과 웹 앱에서 , 실시간으로 동기화
-> Cognio Sync , App Sync 두개 있는데 (Cognio는 이제 안쓴대)
GrapghQL 나오면 App Sync임
8. Cost Explorer 청구 서비스
시간에 따른 AWS 비용 및 사용량에 대해 분석해서 보고서를 생성할 수 있음
과거 기록을 기반으로 앞으로 지불할 예상 금액도 책정해줌
저축 계획을 만들 수 있음
9. SWF (Simple Workflow Service)
분산된 구성요소 간 작업을 조정함 (온프레미스도 가능)
(ex : EC2 재시작 등)
애플리케이션은 API를 사용하여 Amazon SWF와 통신하여 작업의 성공 또는 실패 여부를 기록합니다.
Amazon SWF는 다음 워크플로 작업을 애플리케이션 호스트에 할당하거나 실패한 작업을 사용자의 비즈니스 논리에 따라 다시 실행함으로써 일련의 작업을 계속 진행하게 됩니다.
API 호출 기능은 모든 종류의 언어로 작성된 코드로 실행될 수 있으며, EC2 인스턴스는 물론 인터넷에 액세스할 수 있는 전 세계 모든 장소의 모든 컴퓨터에서 실행 가능
AWS X-Ray
Amazon API Gateway API를 통해 기본 서비스로 이동하는 사용자 요청을 추적하고 분석 할 수 있습니다 .
API Gateway는 모든 API Gateway 엔드포인트 유형(리전, 엣지 최적화, 프라이빗)에 대해 AWS X-Ray 추적을 지원합니다.
X-Ray를 사용할 수 있는 모든 리전에서 Amazon API Gateway와 함께 AWS X-Ray를 사용할 수 있습니다.
AWS System Manager Run Command
관리형 인스턴스의 구성을 원격으로 안전하게 관리
일반적인 관리 작업을 자동화하고 규모에 따라 임시 구성 변경을 수행
AWS 콘솔, AWS Command Line Interface, Windows PowerShell용 AWS 도구 또는 AWS SDK 얘를 사용
Run Command는 추가 비용 없이 제공
Internet gateway 라우팅
경로는 0.0.0.0/0으로 생성하고 인터넷 게이트웨이를 대상으로 해야 합니다.