AWS 가이드, SAA-C02 개념 정리
Architecting on AWS 6.8 (KO): Student Guide를 학습하며 직접 요약한 내용입니다.
- 목차 -
01_AWS 소개
02_가장 간단한 아키텍처
03_컴퓨터 계층 추가
04_데이터 베이스 계층 추가
05_AWS 네트워킹 1부
06_AWS 네트워킹 2부
07_AWS IAM
08_탄력성, 고가용성 및 모니터링
09_자동화
10_캐싱
11_결합 해제된 아키텍처 구축
12_마이크로 서비스 및 서버리스 아키텍처
13_RTO/RPO 및 백업 복구 설정
01_AWS소개
1-1 클라우드의 장점
- 자본 비용을 가변 비용으로 대체
- 규모의 경제로 얻게 되는 이점
- 용량 추정 불필요
- 속도 및 민첩성 개선
- 중요한 문제에 집중
- 몇 분 만에 전 세계에 배포
1-2 Well Architected 프레임 워크 (WAF)
1. 다섯 가지 핵심 요소
1.1 보안
- 자격 증명 기반
- 추적 가능성 활성화
- 모든 계층에서의 보안
- 위험 평가 및 완화 전략
1.2 안정성
- 컴퓨터 리소스를 동적으로 확보하여 수요 충족
- 인프라 또는 서비스 장애로부터 신속하게 복구
- 구성 오류, 일시적인 네트워크 문제 완화
1.3 비용 최적화
- 효율성 측정
- 불필요한 비용 제거
- 관리형 서비스 사용을 고려
1.4 성능 효율성
- 효율적인 리소스를 선택하고 수요 변화에 맞춰 효율성 유지
- 고급 기술을 대중화
1.5 운영 탁월성
- 시스템을 실행 및 모니터링하는 기능
- 지원 프로세스 및 절차를 지속적으로 개선
1-3. AWS 데이터 센터
- 보통 단일 데이터 센터에서 수만 개의 서버 운영
- 모든 데이터는 온라인으로 연결
- 여러 리전에 클러스터 형태로 구축
1-4. AWS 가용 영역
- AWS 데이터 센터는 가용 영역 내에 편성
- 각 가용 영역은 하나 이상의 데이터 센터로 구성
- 내결함성을 갖도록 설계
- 프라이빗 링크를 통해 다른 가용 영역과 상호 연결
- 사용자가 선택 가능
1-5. AWS 리전
- 각 AWS 리전은 두 개 이상의 가용 영역으로 구성
- 전 세계에 22개의 리전 보유
- 사용자는 리전 간 데이터 복제를 활성화하고 제어 가능
- 리전 간 통신은 AWS 백본 네트워크 인프라 사용
02_가장 간단한 아키텍처
2-1. Amazon S3
- 객체 수준 스토리지 : 파일 일부를 변경하려면, 파일을 변경한 다음 다시 업로드
- 99.999999999% 내구성을 제공하도록 설계
- 이벤트 트리거 : 특정 이벤트가 발생할 때 자동 알림을 보낼 수 있음
- 웹 기반 AWS Management Console, API 및 SDK를 통한 프로그래밍 방식 또는 API/SDK를 사용하여 액세스 가능
- 업로드한 파일은 S3 객체로 저장. 객체는 파일 데이터와 메타 데이터로 구성
2-2 . Amazon S3 사용 사례
- 정적 웹 콘텐츠 또는 미디어를 저장하고 배포 가능
- 콘텐츠 전송 네트워크 (Amazon CloudFront)의 오리진으로 사용 가능
- 뛰어난 탄력성이 요구되는 웹사이트에 효과적
- 저렴하고 고가용성이며 확장 가능한 솔루션 제공
- 금융 거래 분석, 클릭스트림 분석같은 연산 또는 대규모 분석을 위한 데이터 스토어로 사용 가능 (수평 확장성)
- 뛰어난 내구성 및 확장성 덕분에 백업 및 아카이브 도구로 유용
2-3. Amazon S3 엑세스 제어
- 기본적으로 모든 S3 리소스, 즉 버킷, 객체 및 관련 하위 리소스는 비공개
- 리소스를 생성한 AWS 계정만이 리소스 액세스 가능
- 정적 컨텐츠를 갖는 S3의 정적 웹 사이트 사용 사례는 AWS 아키텍처를 빠르게 설정할 수 있는 좋은 예지만, S3에 대한 퍼블릭 액세스는 일반적인 사례가 아님
- 버킷 정책을 수정하면 추가 액세스 활성화 가능
2-4. 버킷 정책
- S3 버킷에서 정책을 추가하여 다른 AWS 계정 또는 사용자에게 그 안에 저장된 객체에 액세스 하도록 허용할 수 있음
- ACL 엑세스 정책을 보완하며, 경우에 따라 이를 대체할 수 있음
2-5. CORS (Cross Origin Resource Sharing)
- 한 도메인에서 로드되어 있는 클라이언트 웹 애플리케이션이 다른 도메인에 있는 리소스와 상호 작용하는 방법을 정의
- CORS 지원을 통해 Amazon S3로 다양한 기능의 클라이언트 측 웹 애플리케이션을 구축하고 개별적으로 Amazon S3 리소스에 대한 교차 오리진 액세스 허용 가능
2-6. 데이터를 Amazon S3로 이동하는 방법
- 콘솔, AWS CLI를 사용하여 전송. 데이터가 소량이거나 이미 AWS 네트워크 내에 있는 경우 사용.
- S3 버킷에 업로드
- AWS DataSync 사용. 온프레미스 스토리지와 Amazon S3 / EFS 간에 데이터 이동을 쉽게 자동화할 수 있는 데이터 전송 서비스
- AWS Transfer for SFTP 사용. 완전 관리형 고가용성의 보안 파일 전송 프로토콜인 SFTP 서비스
2-7. Amazon S3 Transfer Acceleration
- 전세계에 분산된 Amazon CloudFront의 엣지 로케이션을 통해 S3 버킷으로 빠르고 간편하게 데이터 전송
- 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅
- 전세계각지에서중앙의버킷으로업로드하는고객이있는경우 • 전 세계에서 정기적으로 기가바이트 또는 테라바이트 규모의 데이터를 전송하는 경우 • 인터넷을 통해 Amazon S3로 업로드할 때 사용 가능한 대역폭을 충분히 활용하지 못하는 경우 사용
2-8. Amazon S3 Glcaier
- 저렴한 스토리지 비용, 즉시 검색 불가능
- 데이터를 검색할 일이 별로 없고, 데이터를 꺼낼일이 거의 없을 때 사용
- 99.999999999%의 객체 내구성
2-9. 수명 주기 정책
- 생성 후 기간을 기준으로 객체를 삭제 또는 이동 가능
- 다양한 Amazon S3 스토리지 유형 간에 데이터가 주기적으로 순환 가능
- 데이터의 중요도가 감소하면 비용을 더 적게 지불 할 수 있음
2-10. 리전 선택
- 지연 시간의 작은 차이가 고객 경험에 영향을 미칠 수 있으므로 가까운 리전 선택
03_컴퓨터 계층 추가
3-1. Amazon EC2
- 웹 호스팅, 애플리케이션, 데이터베이스, 인증 서비스를 비롯해 서버가 수행할 수 있는 모든 워크로드 지원
- 일회용 리소스로 취급 가능하여 고정적이고 유한한 IT 인프라의 경직성과 제약에서 자유로움
3-2. AMI (Amazon Machine Image)
- 클라우드의 가상 서버인 인스턴스를 시작하는 데 필요한 정보를 제공
- 인스턴스를 시작할 때 소스 AMI 지정
- 유사한 인스턴스의 클러스터를 구축하거나 컴퓨팅 환경을 재생성하기가 쉬워짐
- 반복성, 재사용성, 복구성, 백업
3-3. AMI를 가져오는 세 가지 방법
- 사전 구축 : Amazon에서 제공하는 미리 빌드된 AMI. Linux 및 Windows 옵션이 포함
- AWS Marketplace : 수천개의 소프트웨어 솔루션이 나열된 디지털 카탈로그
- 자체 생성 : AMI를 생성할 때, Amazon EC2는 인스턴스를 중지하고, 루트, 볼륨 스냅샷을 생성하고, 마지막으로 이 스냅샷을 AMI로 등록
3-4. Amazon EBS (Elastic Block Store)
- Amazon EC2 인스턴스를 위해 안정적이고 분리 가능한 블록 수준 스토리지 제공
- 인스턴스에 직접 연결되어 있어 매우 짧은 지연 시간 제공
- 외부 하드 드라이브 역할
3-5. Amazon EBS 볼륨 유형
- 범용 SSD : 다양한 워크로드에 사용 가능. 가성비 우수.배부분의 워크로드에 추천
- 프로비정닝된 IOPS SSD : 지연 시간이 짧거나 처리량이 많은 미션 크리티컬 워크로드에 적합. 대규모 데이터베이스 워크로드에 추천.
- 처리량 최적화 HDD : 자주 액세스하고 처리량 집약적인 워크로드에 적합. 저렴.
- 콜드 HDD : 자주 엑세스하지 않는 워크로드에 적합. 최저 비용.
3-6. Amazon EBS 최적화 인스턴스
- 최적화된 구성 스택
- Amazon EBS I/O를 위한 추가 전용 용량
- Amazon EBS와 기타 트래픽 간 경합을 최소화
3-7. Amazon EFS (Elastic File System)
- AWS 클라우드 서비스와 온프레미스 리소스에서 사용할 수 있는 간단하고 확장 가능하면 탄력적인 Linux 기반 워크로드용 파일 시스템 제공
- AWS Direct Connect / AWS VPN을 통해 수천 개의 EC2 인스턴스와 온프레미스 서버 간에 파일을 공유하면서 가용 영역 AWS 리전, VPC에 걸쳐 파일 시스템에 액세스 가능
- 많은 사용자가 공통 데이터 소스를 엑세스 및 공유 가능
- 파일 시스템과 VPC는 동일한 AWS 리전에 위치해 있어야 함
3-8. Amazon FSx for Windows File Server
- 엔터프라이즈 애플리케이션용으로 설계되었으며, 네이티브 Windows 파일 시스템을 지원하는 완전 관리형 서비스
- CRM, ERP, .NET 애플리케이션 및 사용자 홈 디렉터리 등 공유 스토리지가 필요한 Windows 워크로드 지원에 적합
- SMB 프로토콜, Windows NTFS, AD 통합, DFS 지원
3-9. Amazon FSx for Lustre
- 고성능 컴퓨팅(HPC), 기계 학습, 미디어 처리 워크플로에 최적화된 완전 관리형 파일 시스템
- 방대한 데이터를 1밀리초 미만의 지연 시간과 초당 수백 기가바이트의 처리량
- Amazon S3와 통합 가능. 장기간의 데이터 처리 가능
3-10. AWS Compute Optimizer
- 기계 학습을 사용하여 과거 사용률 지표를 분석하고, 비용을 절감하고 서능을 개선할 수 있도록 워크로드에 가장 적합한 AWS 컴퓨팅 리소스 제안
- 최대 25% 비용 절감
- 실행 가능한 권장 사항을 통해 성능 최적화
3-11. 태그
- AWS 리소스에 태그 형태의 메타 데이터 지정
- 간편하게 리소스를 관리, 검색, 필터링 가능
04_데이터베이스 계층 추가
고가용성이고 확장이 용이하며 애플리케이션 서버와 분리된 데이터베이스가 필요합니다.
4-1. 데이터베이스 계층 고려 사항
- 확장성 : 얼마나 많은 처리량이 필요한가?
- 총 스토리지 요구 사항 : 데이터베이스가 얼마나 커야하는가?
- 객체 크기 및 유형 : 단순 데이터 구조, 대용량 데이터 객체, 또는 모두를 저장해야 하는가?
- 내구성 : 어떤 수준의 데이터 내구성, 데이터 가용성 및 복구성이 필요한가?
4-2. SQL vs NoSQL
4-3. 비관리형 데이터베이스
- 일반적으로, 사용자가 모든 보안 백업, DB 튜닝 및 복제를 책임짐
- 규정 준수 의무에 따라 애플리케이션에 대해 자체 관리형 DB 솔루션을 생성해야 할 수 있음
4-4. 관리형 데이터베이스
- 시스템에 고가용성, 확장성, 백업 제공
- 반복적 업무 부담을 경감
- 사용자는 데이터베이스 계층이 애플리케이션과 최대한 잘 연동하도록 앱 최적화만 책임
4-5. Amazon RDS
- 완전 관리형 관계형 DB
- 몇 분이면 새 인스턴스를 프로비저닝
- 몇 번의 마우스 클릭으로 수직으로 조정
- 데이터베이스 삭제 후 자동 백업 보존 지원
4-6. Amazon Aurora
- MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 DB
- MySQL 처리량의 최대 5배
- PostgreSQL의 처리량의 최대 5배
- 3개의 가용 영역에 6개의 복제본
4-7. Amazon DynamoDB
- 완전 관리형 비 관계형 DB
- 이벤트 중심 프로그래밍
- 최상의 수평 확장 기능
- 게임, 광고 기술, 모바일 및 기타 다양한 애플리케이션에 적합
- 사용자의 요구에 맞게 쉽게 확장하거나 축소 가능
- 여러 항목에 대한 삽입, 삭제, 업데이트를 조정해야 하는 어플에 사용 가능
4-8. Amazon RDS 보안 제어
- DB 자체에 대한 액세스 : 누가 가시성을 보유하고 데이터베이스에 대한 작업을 실행할 수 있는가?
- 저장 시 암호화 : 저장시 암호화되는 데이터에는 DB 인스턴스에 대한 기본 스토리지, 자동 백업, 읽기 전용 복제본, 스냅샷이 포함
- 전송 중 암호화 : 전송 중 암호화는 SSL을 사용하여 수행
- 이벤트 알림 : Amazon RDS 인스턴스에서 발생할 수 있는 다양한 중요 이벤트에 대한 알림 받기 가능
4-9. DynamoDB 보안 제어
- 정의 가능한 액세스 권한 : DynamoDB에서는 데이터베이스의 테이블에서 항목, 심지어 속성까지 모든것에 대해 엑세스 권한을 부여할 수 있습니다.
- 저장 시 암호화 : DynamoDB는 완전 관리형 저장 암호화 기능을 제공
- SSL/TLS : 기본적으로 DynamoDB와의 통신은 SSL/TLS 암호화를 사용하여 네트워크 트래픽을 보호하는 HTTPS 프로토콜을 사용
- 고객 관리형 키 : DynamoDB데이터의 보안을 암호화하고 관리하는 방법을 완벽하게 제어
4-10. AWS DMS (Database Migration Service)
- 대부분의 상용 및 오픈 소스 데이터베이스와의 마이그레이션 지원
- EC2, RDS, S3 및 온프레미스의 데이터베이스 간 마이그레이션 사용 가능
4-11. AWS Schema Conversion Tool
- 사용자가 기본 데이터베이스 스키마를 한 데이터베이스 엔진에서 다른 데이터베이스 엔진으로 변환하도록 해주는 독립형 애플리케이션
05_AWS 네트워킹 1부
워크로드 격리를 제공하는 네트워크 환경에서 AWS 리소스를 배포하고 관리해야 합니다.
5-1. VPC
- AWS Cloud의 프라이빗 네트워크 공간
- 워크로드에 대한 논리적 격리 제공
- 리소스에 대한 사용자 지정 액세스 제어 및 보안 설정 허용
5-2. VPC 배포
- VPC는 21개의 AWS 리전 중 1개 리전에 배포
- VPC 리전 내 모든 가용 영역의 리소스를 호스팅 가능
5-3. CIDR, 서브넷
- 가상 네트워크를 생성하고 이를 서브넷으로 분할 가능
- 서브넷 배치는 EC2 인스턴스를 여러 위치에 올바르게 분산할 수 있도록 보장하는 메커니즘
5-4. 라우팅 테이블
- 네트워크 트래픽이 향하는 방향을 결정하는 데 사용되는 경로
- VPC 리소스 간에 트래픽은 연결하는데 필요
- 각 VPC에는 주요 라우팅 테이블 존재
- 사용자 지정 라우팅 테이블 생성 가능
- 모든 서브넷에는 연결된 라우팅 테이블 필요
5-5. 퍼블릭/프라이빗 서브넷
- 퍼블릭 인터넷에 대한 인바운드/아웃바운드 액세스를 지원하도록 인터넷 게이트웨이에 대한 라우팅 테이블 항목을 포함
- 프라이빗 서브넷은 인터넷 게이트웨이에 대한 라우팅 테이블 항목 없음
- 프라이빗 서브넷은 퍼블릭 인터넷에 직접 엑세스 불가
- 일반적으로 제한된 아웃 바운드 퍼블릭 인터넷 엑세스를 지원하기 위해 NAT 게이트웨이 사용
5-6. 인터넷 게이트웨이
- 수평적 확장으로 이중화를 지원하는 고가용성 VPC 구성요소로서 VPC의 인스턴스와 인터넷 간 통신이 가능한 이유도 이 때문
- 네트워크 트래픽에 가용성 위험이나 대역폭 제약이 발생하지 않음
- IPv4 및 IPv6 트래픽을 지원
5-7. NAT 게이트웨이
- 프라이빗 서브넷의 인스턴스가 인터넷 또는 다른 AWS 서비스로의 아웃바운드 트래픽을 시작하도록 활성화
- 프라이빗 인스턴스가 인터넷에서 인바운드 트래픽을 수신하는 것을 차단
5-8. 탄력적 네트워크 인터페이스
- VPC에서 인스턴스에 장착할 수 있는 가상 네트워크 인터페이스
- 동일한 가용 영역 안에서 EC2 인스턴스 간에 이동할 수 있음
5-9. 탄력적 IP 주소
- 인스턴스 또는 네트워크 인터페이스에 연결 가능
- 즉시 트래픽을 재연결하고 전송 가능
- AWS 리전당 5개 허용
5-10. 보안 그룹
- AWS 리소스에 대한 인바운드 및 아웃바운드 트래픽 제어하는 가상 방화벽
- 트래픽은 모든 IP 프로토콜, 포트 또는 IP주소로 제한 가능
- 규칙은 상태 저장
- 기본적으로 모든 인바운드 트래픽 차단, 아웃바운드 트래픽 허용
5-11. 네트워크 ACL
- 서브넷 경계의 방화벽
- 기본적으로 모든 인바운드 및 아웃바운드 트래픽 허용
- 상태 비저장 이므로 인바운드 및 아웃바운드 트래픽 모두에 대한 명시적인 규칙 필요
06_AWS 네트워킹 2부
애플리케이션은 훨씬 더 큰 사용자 기반 및 변동 로드를 지원해야 하며 가용 영역 수준의 장애를 처리해야 합니다.
6-1. 가상 프라이빗 게이트웨이 (VGW)
- Amazon VPC와 다른 네트워크 사이에 프라이빗 연결(VPN)을 설정할 수 있습니다.
6-2. AWS Direct Connect (DX)
- 인터넷을 통한 단순한 연결을 넘어, 중요한 애플리케이션을 위해 AWS 네트워크에 규모, 속도 및 일관성을 가지고 액세스 할 수 있는 고유한 솔루션
- 인터넷이 필요하지 않음
- 온프레미스 솔루션과 AWS 간에 프라이빗 네트워크 연결 사용
- 하이브리드 클라우드 아키텍처
- 지속적인 대용량 데이터 세트 전송
- 네트워크 성능 예측 가능성
- 보안 및 규정 준수
6-3. Transit Gateway
- 단일 게이트웨이로 최대 5000개의 VPC와 온프레미스 환경 연결
- 네트워크 사이를 이동하는 모든 트래픽의 허브 역할 담당
- 가용성이 뛰어나고 유연한 완전 관리형 라우팅 서비스
- 멀티캐스트 및 리전 간 피어링 허용
6-4. VPC 엔드포인트
- AWS를 벗어나지 않고 EC2 인스턴스를 VPC 외부 서비스와 프라이빗하게 연결
- 인터넷 게이트웨이, VPN, NAT 디바이스 또는 방화벽 프록시 사용할 필요 없음
- 동일한 리전에 있어야 함
- 가용성이 뛰어나고, 중복적이며, 수평적으로 확장
6-5. 인터페이스 엔드포인트
- 지원되는 서비스로 향하는 트래픽의 진입점 역할을 하는 프라이빗 IP 주소가 할당된 탄력적 네트워크 인터페이스
6-6. 게이트웨이 엔드포인트
- 라우팅 테이블의 지정된 라우팅의 대상인 게이트웨이
- 지원되는 AWS 서비스의 트래픽에 사용
6-7. 프록시 팜
- Amazon S3 트래픽을 VPC 엔드포인트로 프록시
- ACL을 사용하여 VPC 엔드포인트 트래픽에 대한 추가 제어를 제공
6-8. ELB (Elastic Load Balancing)
- 수신되는 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스, 컨테이너 및 IP 주소에 걸쳐 분산하는 관리형 로드 밸런싱
- HTTP, HTTPS, TCP, UDP, SSL 프로토콜 사용
- 외부 또는 내부에 위치 가능
- 각 로드 밸런서에 DNS이름이 부여
- 비정상 인스턴스를 인식하고 이에 대응
6-9. 애플리케이션 로드 밸런서 (ALB)
- OSI 모델의 7 계층 애플리케이션 계층에서 작동
- 대상이 EC2 인스턴스이든 컨테이너이든 관계없이 상태 확인
- EC2 인스턴스 또는 컨테이너에서 실행되는 웹 사이트 및 모바일 앱은 ALB를 사용하는 이점을 누릴 수 있음
6-10. 네트워크 로드 밸런서 (NLB)
- 사용자가 아무런 조치를 하지 않아도 높은 처리량과 매우 짧은 지연 시간을 유지
- 클라이언트로부터 수신되는 트래픽을 수락하고 이 트래픽을 동일한 가용 영역 내 대상 전체로 분산
- 4 계층에서 작동
6-11. Amazon Route 53
- 가용성과 확장성이 뛰어난 클라우드 DNS 서비스
- DNS 도메인 이름을 IP 주소로 변환
- 도메인 이름을 구입하여 관리하고 DNS 설정을 자동으로 구성
6-12. 옵션
- 단순 라우팅 : 라운드 로빈이랑 동일한 의미, 다수의 요청을 모든 참여 서버로 최대한 균일하게 분산
- 가중치 기반 라운드 로빈 : 각 응답이 처리되는 빈도를 지정하기 위해 리소스 레코드 세트에 가중치 할당
- 지연 시간 기반 라우팅(LBR) : 전세게 사용자를 대상으로 앱 서능 향상. 앱이 실행되고 있는 여러 AWS 리전의 실제 성능 측정치를 기준으로 가장 빠른 환경을 제공하는 AWS 엔드포인트로 고객을 라우팅
- 상태 확인 : 웹 애플리케이션, 웹 서버 및 기타 리소스의 상태와 성능을 모니터링.
- 지리 위치 라우팅 : 사용자의 지리적 위치에 따라 트래픽을 지원할 리소스를 선택 가능. 배포 권한이 있는 위치에만 콘텐츠 배포 가능. 예측 가능하고 관리가 쉬운 방법으로 엔드포인트 간에 로드를 분산함으로써, 각 최종 사용자 위치를 일관되게 동일한 엔드포인트로 라우팅 가능
- DNS 장애 조치 : 웹 사이트의 가동 중단을 탐지하고 최종 사용자를 애플리케이션이 제대로 작동하는 대체 위치로 리디렉션 가능
- 지리 근접 라우팅 : 사용자와 리소스 사이의 물리적 거리를 기반으로 트래픽을 라우팅 할 수 있게 도움. 각 리소스로 라우팅 되는 트래픽 증감 가능
07_AWS IAM
팀원이 전문적인 역할을 맡고 있을 만큼 충분히 큰 규모의 조직입니다. 필수 권한을 통한 보호 및 액세스 제어 기능이 필요합니다.
7-1. AWS 계정 루트 사용자
- 이 계정은 모든 AWS 서비스 및 리소스에 대한 전체 엑세스 권한 가짐
- 강력한 권한을 가지며 제한을 받지 않음
7-2. AWS Identity and Access Management (IAM)
- 다른 AWS 서비스와 통합
- 연동 자격 증명 관리
- 애플리케이션의 안전한 엑세스
- 세부적 권한
- 기본적으로 주어진 권한 없음
- AWS Management Console 또는 CLI에 대한 액세스는 명시적으로 부여되어야 함
7-3. IAM 역할
- 역할을 사용하면 사용자 또는 서비스가 필요한 리소스에 액세스하기 위한 권한 집합을 정의할 수 있음
- 권한을 IAM 사용자 또는 그룹에 연결하지 않음
- 권한을 역할에 연결하고 역할을 사용자 또는 서비스에 위임
7-4. SAML
- 사용자 관점에서 프로세스가 투명하게 처리
- 사용자는 조직의 내부 포털에서 시작하여 AWS 자격 증명을 제공할 필요 없이 AWS Management Console에 로그인
7-5. Amazon Cognito
- 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 제공하는 완전 관리형 서비스
- 사용자 풀 : 앱 사용자의 가입 및 로그인 옵션을 제공하는 사용자 디렉터리
- 자격 증명 풀 : 다른 AWS 서비스에 대한 엑세스 권한을 사용자에게 부여 가능. 자격 증명 풀과 사용자 풀은 별도로 또는 함께 사용 가능
7-6. AWS Landing zone
- AWS 모범 사례에 따라 안전한 다중 계정 AWS 환경을 빠르게 설정할 수 있도록 도와주는 솔루션
- 안전하고 확장 가능한 워크로드 실행을 위한 환경이 자동으로 설정되고 핵심 계정 및 리소스 생성을 통해 초기 보안 기준이 구현되므로 시간 절약 가능
7-7. AWS Organizations
- 계정 관리를 위한 관리형 서비스
- 조직은 모든 AWS 계정을 통합하고, 중앙에서 확인하고, 관리하기 위해 생성하는 엔티티
- 그룹 기반 계정 관리
- AWS 서비스에 대한 정책 기반 액세스
- 자동화된 계정 생성 및 관리
- 통합 결제
- API 기반
08_탄력성, 고가용성 및 모니터링
8-1. 고가용성 요소
- 내결함성 : 애플리케이션 구성 요소의 내장된 중복성
- 확장성 : 애플리케이션의 설계 변경 없이 성장을 수용하는 능력
- 복구성 : 재해 발생 후 서비스 복구와 관련된 프로세스, 정책 및 절차
8-2. 탄력성
- 용량 요구 사항이 변화함에 따라 지능적으로 확장 및 축소될 수 있음
- 트래픽 급증 시 웹 서버 수 증가
- 트래픽이 줄어들 때 데이터베이스의 쓰기 용량 감소
8-3. 탄력성의 세 가지 유형
- 시간 기반 : 리소스가 사용되지 않을 때 리소스 끄기
- 볼륨 기반 : 수요 강도에 맞게 규모 조정
- 예측 기반 : 일일 및 주간 추세를 기반으로 향후 트래픽 예측
8-4. 모니터링(비용)
- Cost Optimization Monitor : 서비스 사용량 및 비용 분석 정보를 제공하는 보고서를 생성할 수 있습니다. 기간, 계정, 리소스 또는 태그를 기준으로 분류할 수 있는 예상 비용을 제공
- AWS Cost Explorer : 지난 13개월까지 데이터를 볼 수 있으므로 시간 흐름에 따른 AWS 리소스 소비 패턴을 확인할 수 있음
8-5. Amazon CloudWatch
- 리소스에 대한 지표를 수집하고 추적
- 경보를 생성하고 알림을 전송
- 설정한 규칙에 따라 리소스의 용량 변화를 트리거
8-6. AWS CloudTrail
- 계정에서 이루어지는 모든 API 호출을 기록하고, 저장된 Amazon S3 버킷에 로그를 저장
- 사용자 활동 및 API 사용 추적
- 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있음 (허튼 짓하면 걸리는 이유)
- 리전 단위로 활성화
8-7. VPC Flow Logs
- VPC의 트래픽 흐름 세부 정보를 캡처
- 허용, 거부 또는 모든 트래픽
- VPC, 서브넷 및 ENI에 대해 활성화
- 로그는 CloudWatch Logs로 게시
- 로그는 Amazon S3로 게시
8-8. Auto Scaling
- 지정된 조건에 따라 인스턴스를 추가/제거
- 지정된 경우, 새 인스턴스를 로드 밸런서에 자동으로 등록
- 여러 가용 영역에 걸쳐 시작 가능
- 최소/최대 용량 설정 후 그 사이의 개수가 생성됨
8-9. Auto Scaling 고려 사항
- 여러 유형의 Auto Scaling을 결합해야 할 수 있음
- 단계 조정을 사용하여 아키텍처를 조정하려면 더 많은 작업이 필요할 수 있음
- 일부 아키텍처의 경우 둘 이상의 지표를 사용하여 조정해야 함
- 초기에 빠르게 확장하고 시간이 지남에 따라 천천히 축소
- 수명 주기 후크 사용
8-10. Amazon RDS
- 노드를 수직적으로 확장/축소
- micro부터 24xlarge까지 모든 크기 지원
- 멀티 에이지 이용 시 다운타임 없이 스토리지 크기 변경 가능, 인스턴스 유형 변경 시 다운 타임 필요
- 읽기 전용 복제본 쉽게 생성 가능. 읽기:쓰기 비율은 8:2정도.
- 멀티 에이지와 읽기 전용 복제본은 다름
8-11. 샤딩
- 데이터베이스 서버를 여러 대 사용하여 쓰기 성능을 개선하는 기술
- 샤딩이 없으면 모든 데이터가 하나의 파티션에 상주
- 예) A~M으로 시작하는 데이터는 1번 데이터베이스, N~Z로 시작하는 데이터는 2번 데이터베이스에 보관
8-12. DynamoDB
- 워크로드 예측이 어렵거나 짧은 시간 동안 대규모 스파이크가 있는 경우 온디맨드 적합
- 프로비저닝 > 온디맨드 변경 : 하루 한 번
- 온디맨드 > 프로비저닝 변경 : 자유롭게 가능
8-13. DynamoDB 조정 용량
- 트래픽이 테이블의 프로비저닝 된 용량이나 파티션 최대 용량을 초과하지 않을 경우 조절 없이 핫 파티션에 계속 읽기 및 쓰기 작업을 수행 가능
- 조정 용량은 더 많은 트래픽을 받는 파티션의 처리량 용량을 자동으로 증가
- 기준점을 잘 잡아야 고르게 분배
09_자동화
지속적 성장을 위해서는 자동화를 시작해야 합니다. 조직에 있는 다양한 아키텍처를 일관되게 배포, 관리, 업데이트를 위해 필요합니다.
9-1. 자동화는 왜 필요한가?
- 프로덕션 환경에서 뭔가를 수동으로 변경해야 하는 경우, 위험이 따름
- 수동 프로세스는 보상 없는 위험임
9-2. AWS CloudFormation
- AWS 인프라를 설명하는 공통 언어를 제공
- 설명된 리소스를 자동화된 방식으로 생성하고 구축
- 수동 작업을 수행하거나 사용자 지정 스크립트를 작성할 필요 없이 인프라와 애플리케이션을 구축 및 재구축 가능
- 템플릿을 처리하는 엔진
9-3. AWS CloudFormation 템플릿
- 생성할 리소스를 설명하는 JSON/YAML 형식 파일
- 템플릿을 코드로 취급하고, 원하는 버전 제어 방법(Git, SVN 등)으로 이를 관리
- 기존 리소스 가져오기
- 스크립트랑 비슷한 개념
9-4. AWS CloudFormation 조건
- 프로덕션 환경과 개발 환경을 동일한 스택에서 구축해야 함
- 개발 환경과 테스트 화녕에서 동일한 스택을 사용해야 함
9-5. IaC (코드형 인프라)
- 환경을 구축하면서 반복성과 재사용성의 이점
- 템플릿 하나로 복잡한 동일 환경을 반복해서 구축 가능
9-6. AWS Quick Start
- AWS 클라우드에서의 모범 표준 배포
- 표준 샘플들이 존재해서 쉽게 생성 가능
- 클릭 한 번으로 1시간 내에 전체 아키텍처 생성
- 실험 및 간편한 구축에 적합
9-7. System Manager
- 자동화된 구성 및 대규모 시스템의 지속적 관리가 가능한 기능의 집합
- 명령 실행, 유지 관리 기간, 패치 관리, 상태 관리자, 세션 관리자, 인벤토리 가능
- 모든 Windows 및 Linux 워크로드
- Amazon EC2 혹은 온프레미스에서 실행
9-8. AWS OpsWorks
- Chef를 사용하여 모든 형태와 규모의 애플리케이션을 구성하고 운영하도록 지원하는 구성 관리 서비스
- AWS CloudFormation과 동시에 사용할 수 있음
9-10. AWS Elastic Beanstalk
- 목표 : 개발자가 기본 인프라에 대해 걱정할 필요 없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포/유지
- 인프라를 프로비저닝 및 운영하고 사용자를 위해 애플리케이션 스택을 관리
- 완전한 투명성 : 생성되는 모든 것을 확인 가능
- 적절한 규모 유지. 애플리케이션의 크기를 자동으로 늘리거나 줄임
9-11. 알맞은 솔루션 선택
- AWS Elastic Beanstlak : 널리 사용되는 컨테이너인 Java, PHP, Node.js, Python, Ruby 및 Docker로 웹 애플리케이션을 구축할 수 있는 사용이 간편한 애플리케이션 서비스입니다. 코드를 업로드하길 원하고, 환경을 사용자 정의할 필요가 없다면, Elastic Beanstalk가 적합
- AWS OpsWorks : 애플리케이션을 시작하고 애플리케이션의 아키텍처 및 각 구성 요소의 사양을 정의할 수 있음
10_캐싱
동일한 요청으로 인프라 용량이 지속적으로 과부하 됩니다. 이는 비효율적으로 비용 및 지연 시간을 늘립니다.
사용자가 반복적으로 요청하는 경우 중간에 캐싱을 생성하면 빠르게 접근이 가능합니다.
10-1. 무엇을 캐시 해야 할까?
- 수집하려면 느리고 비싼 쿼리가 필요한 데이터
- 비교적 정적이고 자주 액세스 하는 데이터
- 공개 거래되는 주식 가격처럼, 일정 기간 동안 변화가 없을 수 있는 정보
10-2. 캐싱의 이점
- 애플리케이션 속도 향상
- 시간이 많이 걸리는 DB 쿼리의 부담 완화
- 응답 지연 시간 감소
10-3. 엣지 캐싱
10-4. CDN (콘텐츠 전송 네트워크)
- 웹 트래픽이 지리적으로 분산된 경우, 전체 인프라를 전 세계에 복제하는 것은 불가능
- CDN에서는 웹 콘텐츠의 캐시 된 사본을 고객에게 제공하기 위해 엣지 로케이션의 글로벌 네트워크를 사용 할 수 있음
- 응답 시간을 줄이기 위해 CDN은 고객 또는 발신 요청 위치에 가장 가까운 엣지 로케이션 사용
10-5. Amazon CloudFront
- Amazon의 글로벌 CDN
- 기본적인 멀티 티어 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화
- 아키텍처에 추가적인 보안 계층 제공
- WebSocket 프로토콜 지원
- 최초의 데이터 이용자는 속도가 느릴 수 있지만, 그 이후엔 오리진에서 가져와서 캐싱하기 때문에 빠름
10-6. 콘텐츠 만료 방법
- 몇 달, 몇 년 캐싱을 저장하는 건 말이 안 됨
- TIme To Live(TTL) : 고객이 설정, 기간 고정(만료 기간)
- 객체 이름 변경 : 파일 명만 보지 파일 내용은 보지 않음. 이름을 변경해야 새롭게 캐싱
- 객체 무효화 : 강제로 캐싱 제거. 마지막 수단. 매우 비효율적이고 비용이 많이 듦
10-7. 웹 티어 캐싱 - 세션 관리 - 고정 세션
- 사용자의 세션을 관리하는 특정 서버로 요청을 라우팅 할 수 있음. 사용자는 애플리케이션을 실행하는 웹 서버에 세션을 저장하기 때문에 고정 세션을 비용 효율적.
- 네트워크 지연 시간을 없애고, 해당 세션의 검색 속도를 높임.
- 장애 발생 경우, 하나의 노드에 저장된 여러 세션이 손실될 가능성 존재
10-8. 데이터베이스 캐싱 - Amazon DynamoDB Accelerator (DAX)
- 탁월한 성능 : 10밀리 초 미만의 일관된 지연 시간
- 뛰어난 확장성 : 온디맨드 조정 기능 보유
- 완전 관리형 : 프로비저닝, 설정 및 구성, 소프트웨어 패치, 조정 작업 중 노드를 통한 데이터 복제 등 가능
- DynamoDB와 API 호환
- 유연성
- 보안
10-8. Amazon ElastiCache
- 클라우드에 있는 인메모리 데이터 스토어를 웹 애플리케이션에 제공
- 관리형 인 메모리 데이터 스토어에서 정보를 검색할 수 있는 기능을 제공함으로써 웹 애플리케이션 성능 향상
- 완전 관리형 서비스
- 연속 쓰기 : 최신 데이터가 DB에 쓰일 때마다 캐시 저장. 최신 정보 저장 가능. 사용자가 요청하지 않은 정보까지 저장하기 때문에 공간 낭비 있음.
- 레이지 로딩 : 사용자가 요청한 데이터에 대해 캐시 저장. 정보가 최신이 아닐 수도 있지만, 공간 활용 good
11_결합 해제된 아키텍처 구축
이제 아키텍처는 수십만 명의 사용자들을 지원하지만 일부가 실패하면 전체 애플리케이션이 실패합니다. 종속성을 제거해야 합니다.
11-1. 밀결합
11-2. 느슨한 결합
11-3. Amazon SQS (Simple Queue Service)
- 완전 관리형 메시지 대기열 서비스
- 메시지는 처리 및 삭제될 때까지 저장
- 발신자와 수신자 간 버퍼 역할을 담당
- 하루에 수십억 건 메시지 처리 가능
- 메시지를 큐에 받고 App이 처리할 수 있는 상태일 때 큐에서 메시지 하나 가져와서 처리, 처리가 끝나면 삭제
11-4. 대기열 유형
- 표준 대기열 : 최소 1회 전송 및 최선의 정렬 제공. 하지만 가끔 중복 처리를 할 수 있음
- FIFO 대기열 : 메시지가 전송된 순서대로 정확히 한번 처리될 수 있음
11-5. Amazon SNS (Simple Notification Service)
- 손쉽게 알림 기능을 설정, 작동 및 전송할수 있는 웹서비스
- 게시자는 각 메시지에 특정 대상 주소를 포함하는 대신 메시지를 해당 주제를 전송 할 수 있음. 주제와 해당 주제를 구독하는 구독자 목록을 일치시켜 각각의 구독자에게 메시지 전송
11-6. Amazon SNS 구독 유형
- 이메일
- HTTP/HTTPS
- SMS
- Amazon SQS
- AWS Lambda
11-7. SQS vs SNS
12_마이크로 서비스 및 서버리스 아키텍처
모놀리식 아키텍처가 분리되면 개별 구성 요소가 별도의 팀에서 관리되며, 이에 따라 한 팀에서 구성 요소를 변경하는 경우 충돌이 발생할 수 있습니다.
12-1. 마이크로 서비스
- 서로 독립되어 있기 때문에 서로 다른 언어를 써서 구성 가능
- 서로 연결만 잘된다면 복잡한 동작 수행 가능
12-2. 컨테이너
- 리소스 격리 프로세스에서 애플리케이션과 종속 항목을 실행하게 해주는 운영 시스템 가상화 방법
- 고속이고 휴대 가능하며 인프라에 구애받지 않는 실행 환경을 사용할 수 있음
- 다양한 환경에서 소프트웨어를 안정적으로 진행
12-3. Amazon ECS (Elastic Container Service)
- 도커 컨테이너를 지원하는 확장성과 성능이 뛰어난 컨테이너 관리 서비스로서, 서비스를 사용하여 Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 손쉽게 실행할 수 있음
- 컨테이너의 실행을 조정
- 컨테이너를 실행하는 노드 플릿을 유지, 관리, 확장
- 인프라 구축의 복잡성 제거
12-4. 모놀리식 애플리케이션에서 컨테이너 기반 마이크로 서비스 변환
- 모놀리식 포럼 애플리케이션을 마이크로 서비스 접근 방식으로 전환하려면 코드를 캡슐화된 개별 서비스로 분할
- 각 서비스가 제 기능을 하는지 확인 후, Amazon ECS Container Registry에 등록
- Amazon ECS 내부에서 원래 애플리케이션의 이러한 요소 각각에 대해 서비스 생성
- 서비스를 위한 대상 그룹 인스턴스 등록
- Amazon ECS 앱 서비스를 가리키는 대상 그룹을 포함하는 ALB 생성
12-5. AWS Fargate
- 서버 또는 클러스터를 관리할 필요 없이 컨테이너를 실행할 수 있게 해주는 Amazon ECS 및 EKS용 기술
- 사용하면 더 이상 컨테이너를 실행하기 위해 가상 머신을 프로비저닝, 구성 및 조정할 필요 없음
- 애플리케이션을 실행하는 인프라의 관리 대신 애플리케이션 설계 및 구축에 집중 가능
12-6. 서버리스 컴퓨팅
- 서버를 관리하지 않고 앱과 서비스를 구축하고 실행. 서버는 아마존이 관리
- 사용자가 서버를 프로비저닝, 확장, 관리할 필요 없음
12-7. AWS Lambda
- 서버를 프로비저닝 하거나 관리할 필요 없이 코드를 실행할 수 있음
- 사용자는 Npde.js, Java, C#, Python, Ruby 중 하나로 코드를 제공하기만 하면 됨
- 완전 관리형 컴퓨팅 서비스
- 상태 비저장 코드 실행
- 일정에서 또는 이벤트에 대한 응답으로 코드 실행
- 엣지에서 실행 가능
- 해당 코드는 자고 있다가 이벤트가 실행되면 코드 실행
- 코드 동작 시간 15분 제한
12-8. Amazon API Gateway
- 애플리케이션의 현관 역할을 하는 API를 생성
- 최대 수십만 건의 동시 API 호출
- 특정 자원들을 외부에 직접 공개하지 않기 때문에 보안 강화 가능 (엔드 포인트 노출 방지, Ddos 보호)
12-9. AWS Step Function
- 시각적 워크플로를 사용한 마이크로 서비스 조정
- 각 단계를 자동으로 트리거하고 추적
- 단계 실패 시 단순 오류를 파악하여 로깅 제공
13_RTO/RPO 및 백업 복구 설정
인프라를 사용할 수 없는 경우 적절한 시간 내에 적절한 비용으로 애플리케이션을 다시 실행할 수 있어야 합니다.
13-1. 복구 시점 목표 (RPO)
- 수용 가능한 데이터 손실량을 시간으로 측정한 값
- 예를 들어 어떤 재해가 낮 12시에 발생하고 RPO가 1시간이라면 시스템은 오전 11시 이전에 시스템에 있던 모든 데이터를 복구해야함.. 데이터 손실은 오전 11시부터 낮 12시까지 1시간에 불과함.
- 짧을수록 좋음
13-2. 복구 시간 목표 (RTO)
- 복구까지 걸리는 시간
- 예를들어 어떤 재해가 낮 12시에 발생하고 RTO가 1시간이라면, 오후 1시가 되면 서비스가 재개
- 짧을수록 좋음
13-3. AWS 기반 재해 복구
여기서 부터는 개인 공부 저장용
S3 standard IA
S3 Standard-IA는 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. S3 Standard-IA는 S3 Standard의 뛰어난 내구성, 높은 처리량 및 짧은 대기 시간을 저렴한 GB당 스토리지 요금과 GB당 검색 요금으로 제공합니다. 저렴한 비용과 높은 성능의 조합을 제공하는 S3 Standard-IA는 장기 스토리지, 백업 및 재해 복구 파일용 데이터 스토어에 이상적입니다.
Direct Connect vs Site to Site
요금은 VPN이 많이 저렴합니다. Direct Connect가 다양한 대역폭을 제공하지만 사용하는 대역폭에 따라 많은 비용이 부과됩니다.
또한 통신을 위해 전용망을 사용하는지 인터넷 망을 사용하는지도 나뉘게 됩니다. 데이터의 보안이 훨씬 중요한 네트워크라면 VPN 보다 Direct Connect를 이용하는 편이 좋습니다.
AWS Health
AWS Health리소스 성능 및 가용성에 대한 지속적인 가시성을 제공합니다.AWS 서비스및 계정. 사용할 수 있습니다.AWS Health 행사서비스 및 리소스 변경이 실행 중인 애플리케이션에 미치는 영향 알아보기AWS.AWS Health는 진행 중인 이벤트를 관리하는 데 도움이 되는 시기적절한 정보를 제공합니다.AWS Health또한 계획된 활동을 인식하고 준비하는 데 도움이 됩니다. 이 서비스는 AWS 리소스의 상태가 변경되면 경보 및 알림을 트리거하므로, 사용자는 이벤트 정보와 지침을 거의 즉각적으로 파악하고 문제를 신속하게 해결할 수 있습니다.
AWS S3 객체 잠금
S3 객체 잠금을 사용하면 write-once-read-many(WORM) 모델을 사용하여 객체를 저장할 수 있습니다. 객체 잠금은 고정된 시간 동안 또는 무기한으로 객체의 삭제 또는 덮어쓰기를 방지하는 데 도움이 될 수 있습니다. 객체 잠금을 사용하면 WORM 스토리지가 필요한 규제 요구 사항을 충족하거나 객체 변경 및 삭제에 대한 보호 계층을 추가하는 데 도움이 됩니다.
Amazon Inspector
Amazon Inspector는 지속적으로 스캔하는 취약성 관리 서비스입니다.AWS취약성을 위한 워크로드 Amazon Inspector는 Amazon ECR (Amazon 엘라스틱 컨테이너 레지스트리) 에 있는 Amazon EC2 인스턴스와 컨테이너 이미지를 자동으로 검색하여 소프트웨어 취약성과 의도하지 않은 네트워크 노출이 있는지 검사합니다.
Aws war (well architected review)
amazon guard duty
아마존 GuardDuty 다음을 분석하고 처리하는 지속적 보안 모니터링 서비스입니다.데이터 원본:AWS CloudTrail관리 이벤트 로그,AWS CloudTrailS3, DNS 로그, EKS 감사 로그 및 VPC 흐름 로그에 대한 데이터 이벤트입니다. 악성 IP 주소 및 도메인 목록 등 위협 인텔리전스 피드를 바탕으로 Machine Learning을 적용하여 예기치 않게 발생하는 잠재적 무단 활동과 악의적 활동을 찾아냅니다.AWS환경. 여기에는 권한 에스컬레이션, 노출된 자격 증명 사용 또는 악의적인 IP 주소 또는 도메인과 같은 문제가 포함될 수 있습니다.
amazon shiled advanced
AWS Shield는 AWS에서 실행되는 애플리케이션을 보호하는 디도스(DDoS) 보호 서비스입니다. AWS Shield는 애플리케이션 가동 중지 및 지연 시간을 최소화하는 상시 탐지 및 자동 인라인 통합을 제공하므로 DDoS 보호를 위해 AWS Support를 이용할 필요가 없습니다. AWS Shield에는 두 계층 – Standard 및 Advanced가 있습니다.