Architecting_on_AWS
AWS 서비스를 파악하고 기능을 비교하며, 복원력있고 안전하며 가용성이 뛰어난 IT 솔루션을 AWS에서 설계한다.
- 모범 사례에 따라 클라우드 인프라를 어떻게 구성?
- AWS 글로벌 인프라 어떻게 구성?
- 리소스에 대한 액세스 제어?
- 민첩성 증가: 출시 기간 단축, 혁신 확대, 원활한 스케일링
- 복잡성 및 위험성 감소: 비용 최적화, 보안 강화, 관리 복잡성 감소
- AWS 관리 콘솔 (70% 정도 제공됨, ID/PW)
- AWS CLI (Access key ID / Secret access key)
- AWS SDK (Access key ID / Secret access key)
AWS 내부는 거의 모든 부분이 API로 구성되어 있다.
명령들이 API로 전달되어 행해진다.
EC2 생성 방법
- AWS 관리 콘솔: 일회용 또는 임시 인스턴스를 빠르게 시작
- 스크립트: 반복 사용할 수 있고, 안정적인 방식으로 인스턴스 생성
- CloudFormation: 관련 리소스를 함께 시작하는 경우, 코드형 인프라 개념을 사용하려는 경우
-
비관리형 서비스
- OS 설치, 서버 유지 관리 등 인프라는 AWS가 관리.
- 인프라에서 발생하는 상황은 고객이 제어.
- ex. EC2
-
관리형 서비스
- 고객은 애플리케이션 최적화만 신경 쓰고, 나머지는 AWS가 관리.
- ex. RDS
-
서버리스 서비스
- 사용자가 가상 머신이나 서버를 소유하지 않고, 필요에 따라 서비스를 프로비저닝.
- VPC 인프라 내에서 작동하지 않음. (리전 서비스라고도 불림.)
- 엔드 포인트 URL로 서비스에 접근. (엔드포인트를 통해서 다이렉트로 접근할 수 있다.)
AWS 글로벌 클라우드 인프라는 업계에서 가장 안전하고 광범위하고 안정적인 클라우드 플랫폼으로, 전 세계 데이터 센터를 통해 완전한 기능을 갖춘 200가지가 넘는 서비스를 제공함
- 리전 간의 완전히 독립적. (내결함성, 안정성 보장)
- 가용 영역 2개 이상을 가지고 있음. (서울 4개 AZ)
- 가버넌스(규칙), 지연 시간, 서비스 가용성, 비용에 따라 선택
- 리전 내 데이터 센터들의 집합. (1개 이상의 데이터 센터를 가지고 있음)
- 내결함성을 갖도록 설계.
- 고속 프라이빗 링크를 통해 상호 연결.
- 고가용성 달성에 사용됨.
- 사용자로 부터 가장 가까운 AWS 데이터 센터
- CloudFront의 캐싱 콘텐츠가 한다.
- Route 53, CloudFront, Global Accelerator, WAF, shield의 제한된 서비스만 제공. (EC2, RDS 서비스 등을 설치할 수 없음)
- 고객이 소비할 데이터가 상파울로의 S3에 있다면 접근할 때마다 시간이 많이 소요될 것이다. 이러한 데이터를 엣지 로케이션에 저장하여, 지연 시간과 비용적 측면에서 이점을 볼 수 있다.
- 리전까지 너무 멀어서 속도가 너무 느릴 때, 엣지 로케이션에서 특정 서비스를 사용하고 싶을 때 사용.
- 엣지 로케이션에서 EC2, RDS 서비스 등을 제공하는 서비스.
(한국은 거리가 먼 지역이 없어서 존재하지 않음) - 미디어 및 엔터테인먼트 콘텐츠, 실시간 게임, 기계 학습 추론, 스트리밍, AR/VR
- 5G 사업자를 위한 서비스
현재 구축된 아키텍쳐가 잘 구성되었는지 모범 사례와 비교하여 확인하기 위함 (QnA)
- 보안
- 최소 권한의 원칙
MFA(다중 인증) 사용
- 비용 최적화
- 비용 효율적 리소스 사용
- 안정성
- 장애 복구 절차 테스트
- 스케일링으로 가용성 최대화
- 성능 효율성
- 지연 시간 감소
- 서버리스 아키텍처 사용
- 운영 우수성
- 운영 도구를 사용하는가
- 예기치 않은 이벤트 대응
- 지속 가능성
- 환경에 대한 영향 이해
- 모범 사례와 비교하여 아키텍처 검토
- 워크로드 정의 > 아케턱처 검토 수행(QnA) > 모범사례 적용
- 모범 사례를 따르는데 도움이 되는 권장 사항 제공.
- Access Advisor: 서비스에 대한 권한 액세스가 일어난 최근 파악
- AWS IAM Access Analyzer: 외부 entity와 공유되는 리소스 파악 용이
권한을 받는 주체
- IAM 사용자
- IAM Role
- AWS 서비스
- AWS 서비스에 대한 전체 액세스 권한 보유.
- Account ID(12자리 숫자)가 주어짐. > 이 안에 많은 사용자를 생성할 수 있음
- AWS와의 일반적으로 사용하면 안 됨.
- MFA를 설정할 수 있음
- 누가, 무엇을, 어떻게 관리할지 인증/인가를 제어하는 서비스
- AWS 서비스 및 리소스에 대한 접근 관리
- 암호 정책 설정 가능
- 액세스 제어 분석
- 계정 내에서 권한을 관리
- 다른 계정에 권한을 부여할 수 없음
- 인증을 위한 리소스
- 관리 콘솔에 로그인하기 위한 비밀번호
- 자격증명 (Access-key, Secret-key)
- 반드시 사람일 필요는 없으며, 자격 증명 키를 통해서 인증을 하기도 함
- User에 대한 권한 할당을 상속 형태로 간편화하기 위해 사용
- 그룹 아래 사용자들은 모두 권한을 가지게 됨
- 임시로 서비스에 대한 특정 권한을 위임하여, 작업을 하는 동안만 유효하게 사용 가능.
- 역할이 있을 때는 역할 정책이 우선적으로 처리됨
- 직원에게 교차 계정 접근 권한을 부여
- AWS 또는 오프레미스에서 실행되는 애플리케이션이 AWS API 호출을 수행하도록 허용
- AWS 서비스가 사용자 대신 AWS API 호출을 수행하도록 허용
STS(Security Token Service)를 통한 임시 보안 자격 증명을 생성- Access key, Security Key, Session Token
- SAML: 인증을 위임
- 예시
- 운영 계정에서 IAM Role을 생성하고, 부여 (운영 권한을 활용 가능)
- EC2가 S3에 접근할 때마다 Role을 부여받아 사용한다. (EC2 메타데이터를 활용)
- Account가 다를 때, switching role을 통해서 다른 Account의 권한을 변환할 수 있음
Json 형태로 액세스 권한을 평가
- 자격 증명 기반 정책: 사용자 중심 (Users, Groups, Role)
- managed: 대상이 사라져도 유지가 됨 (1:n) (AWS, Customer)
- inline: 대상이 사라지면 사라짐 (1:1)
- 리소스 기반 정책: 리소스 중심 (S3, Bucket), 모두 inline (리소스가 사라지면 사라짐)
- IAM 권한 경계
- AWS Organizations 서비스 제어 정책 (SCP)
자격 증명 기반 정책과 리소스 기반 정책은 함께 평가된다.
- 명시적 거부? > DENY
- 명시적 허용? > ALLOW
- 묵시적 거부 > DENY
- 사용자 > (IAM 정책) > IAM Role
- IAM Role > (VPC 엔드포인트 정책) > Amazon S3 VPC 엔드포인트
- Amazon S3 VPC 엔드포인트 > (버킷 정책) > S3 버킷
- AWS KMS 키 > (AWS KMS 키 정책) > 문서
- Effect* : 정책에서 액세스를 Allow/Deny 표시
- Principle : 계정, 사용자, 역할 또는 페더레이션 사용자로 액세스를 허용할 것인가 (리소스 정책에서만)
- Action* : 정책이 허용하거나 거부하는 작업 목록
- Resource* : Action이 적용되는 리소스 목록 (arn: 리소스 식별)
- Condition : 정책에서 권한을 부여하는 상황 정의
{
"Version": "2012–10–17",
"Statement": {
// Allow 또는 Deny
"Effect": "Allow",
// 해당되는 작업에 접근할 수 있다.
"Action": [
"dynamodb:*",
"s3:*",
"iam:GetGroup"
],
// 해당 리소스에 접근할 수 있다.
"Resource": [
"arn:aws:dynamodb:region:account-number-without-hyphens:table/EXAMPLE-TABLE"
"arn:aws:iam::609103258633:group/Developers",
"arn:aws:iam::609103258633:group/Operators"
],
// 사용자가 Owner일 때만 Action을 하겠다.
"Condition" : {
"StrginEquals":{
"ec2:ResourceTag/Owner": "${aws:username}"
}
}
}
}- 다수의 팀
- 보안 및 규정 준수 제어
- 결제
- 격리
- AWS와 사전에 서로 인증정보를 공유하겠다 Federation을 맺고 서비스 이용에 따른 권한은 Role로 제공
- 팀 인증을 단순화하기 위함
- 통합 인증(SSO)를 위해 회사 계정과 AWS 계정을 일치 시킴
- 다중 계정 관리를 위해서 계정을 조직 단위(OU, Organization Unit)으로 그룹화하여 계층 구조를 생성
- OU 내 모든 계정에 SCP가 적용
- 통합 과금 방식의 장점을 활용, 무료임.
- Organization의 정책 관리 방법
- 조직의 모든 계정에서 사용 가능한 권한을 중앙 제어
- SCP에서 모든 서비스와 작업을 허용하더라도 IAM 권한 정책을 받아야 접근 가능
- SCP: 기본적으로 모든 action을 허용 / 특정 서비스 및 action 금지
- IAM: 기본적으로 모든 action을 금지 / 특정 서비스 및 action 허용
- 초기에 다중 계정을 모범사례를 활용하여 쉽게 구축.
- 거버넌스(규약)를 적용.
- 로그 아카이브, 프로비저닝된 계정 등의 여러 서비스를 추상화하여 적용.
AWS에서 IP 주소 공간 계획하기.
- AWS에서는
0, 1, 2, 3, 255를 예약함 > 사용자 소스 IP로 할당될 수 없음- 10.100.100.1 > 사용자 IP X
- VPC 안에서 어떻게 IP를 사용할 것인가를 결정
- 192.168.1.0/24
앞에 3개는 고정하고(24/8=3) 맨 뒤만 변경해서 2^8 만큼 사용하겠다. - 10.0.0.0/16
앞에 2개는 고정하고(16/8=2) 2 개만 변경해서 2^8 * 2^8 만큼 사용하겠다.
- 192.168.1.0/24
- 총 5개의 CIDR 블록이 있음
- 보조 블록을 추가해서 IP 풀을 확장할 수 있음
- CIDR은 수정이 불가능
- 워크로드의 논리적 격리를 제공
- 단일 리전
- 2개 이상의 가용 영역을 포함함
- 초기에 기본 VPC가 제공됨
- 여러 가용 영역에 VPC 배포
- 여러 가용 영역에 배포하여 고가용성 달성.
- 각 가용 영역에 서브넷을 생성, 리소스를 배포
- ELB를 통해서 가용 영역 간에 트래픽을 분산
- 다중 VPC 이점
- 각 애플리케이션 환경의 모든 리소스 프로비저닝 및 관리를 완전히 제어하는 단일 팀 또는 조직에 적합
- 다중 VPC는 논리적 격리를 생성할 수 있음
- 리전 간, 계정 간 VPC를 서로 연결하는 완전 관리형 서비스
- Private IP 주소 사용
- 온프레미스와의 피어링은 불가능
- 사용 요금이 없음
- 전이적 피어링 관계 없음 (VPC A <-> VPC B <-> VPC C : VPC A와 VPC C는 연결 X)
- 피어링 연결
- 라우팅 테이블에 VPC 피어링을 추가한다.
- 글로벌 AWS 서버에서 유지됨 (인터넷 연결이 필요없음)
- VPC CIDR 블록의 하위 집합 (VPC의 IP를 나누어 사용하겠다.)
- 하나의 가용 영역에 여러개가 포함될 수 있음
- 생성시, 기본 Private 서브넷
- 일반적으로 public 서브넷 개수 < Private 서브넷 개수
- Public 서브넷
- 공인 IP 주소를 통한 외부 통신이 가능 (공인 IP와 사설 IP를 가짐)
- 라우팅 테이블에 (대상위치: 0.0.0.0/0 | 대상: igw-id) 추가
- igw: 인터넷 게이트웨이
- 라우팅 테이블 : 대상위치, 대상이 정의되어 있음
- 인바운드/아웃바운드 가능
- VPC 외부의 서비스에 접근할 때, 내부 네트워크를 통해 접근 (S3, DynamoDB 등)
- S3, Cloudwatch, Cloudfront 등은 외부 리소스임
- 외부 리소스에 접근할 때, 내부 트래픽이 노출될 수 있는 위험이 있음
- Endpoint를 통해서 외부 리소스에 접근
- 장점: 보안 강화, 비용 절감(외부에서 들어오는 통신은 비용이 발생)
- NAT의 경우에는 인터넷을 통해서 외부에 접근하기 때문에 비용 발생
- VPC 인스턴스와 인터넷 간 통신을 위해서 반드시 필요
- VPC당 하나 설정할 수 있음
- 기본적으로 수평 확장, 중복, 고가용성
- 인터넷으로 라우팅 가능한 트래픽에 대한 서브넷 라우팅 테이블에 대상을 제공
- IPv6 라우팅 가능
- Private EC2 인스턴스가 인터넷을 연결하기 위해서 필요
- NAT 게이트웨이/인스턴스는 Public subnet에 위치
- EC2가 인터넷에 노출되지 않는 형태
- NAT 게이트웨이
- Private IP를 Public IP로 변환해주는 작업을 진행
- 인터넷 게이트 웨이가 존재하고, 라우팅 테이블에 등록이 되어있어야 함
- SG를 적용할 수 없음
- NAT 인스턴스보다 더 많은 트래픽
- IPv4 주소만 가능
- NAT 인스턴스
- EC2에 직접 NAT 서비스를 복잡한 설정을 통해 설치/운영해야함
- S3, DynamoDB 외에 AWS 서비스 접근
- ENI 형태로 제공됨 (라우팅 테이블)
- 온프레미스 <-> S3에서도 사용됨
- 중앙에서 네트워크 트래픽을 라우팅 테이블을 통해서 어디로 보내야할지 지정
- 모든 VPC, VPN을 모아 중앙 관리형 네트워킹 가능
- 최대 5000개의 VPC와 온프레미스 환경 연결
- 모든 트래픽의 허브 역할
- 멀티 캐스트 및 리전 간 피어링 허용
- 유연한 라우팅 및 세분화
- 리전당 1개 생성
- 완전관리형 서비스
- Priavet IP 주소, Elastic IP 주소, Mac 주소를 유지
- 인스턴스가 다른 네트워크 리소스와 통신할 수 있도록 함
- 동일한 가용영역의 리소스 간에 이동이 가능
- VPC Subnet 기준 적용
- 모든 VPC에는 기본 NACL이 포함된다.
- 기본: 인바운드/아웃바운드 모두 허용
- 하단의 모든 인스턴스에 적용
- 룰에 대한 허용 및 거부 규칙 지원
- 등록된 규칙의 번호순으로 트래픽 허용 및 거부
- 인스턴스 기준 적용
- 룰에 대한 허용 규칙만 지원
- 기본적으로 inbound: 모두 거부 / outbound: 모두 허용
- inbound를 어떤 규칙만 허용할지 설정
- outbound 요청은 자동 허용
- 모든 규칙을 평가하여 트래픽 허용
- source를 다른 보안 그룹으로 연결하여 마치 체인 연결처럼 구성
온프레미스 서버와 AWS Cloud 간의 연결
- 공용 인터넷 사용
- 인터넷 프로토콜에 랩을 씌워
보안을 강화함- 사내망에서 AWS EC2에 접근하기 위한 안전한 방법
- 온프레미스 <-> *고객 Gateway <-> 공용 인터넷(VPN 연결) <-> *VPN 연결 옵션 <-> VPC
- 데이터 센터에서 AWS 리소스까지 광링크로 구축
- 인터넷을 거치지 않아 속도가 빠름
- 설치 시간이 오래 걸림
- 비용이 비쌈
- 가상 Private Gateway 활용
- 고객 Gateway <-> 고객 라우터 <-> AWS 라우터 <-> 가상 Private Gateway
- 백업 툴. 백업 전용 Gateway를 열어주는 서비스
- 로컬
캐시를 사용해서 짧은 지연시간 유지 및 S3 데이터 마이그레이션 HTTPS 포로토콜사용 (전송 대상이 S3밖에 없음)- 유형
- File Gateway
- 데이터를 S3에 저장 후 NFS/SMB 등으로 액세스
- NFS: 리눅스, SMB: 윈도우즈
- Volume Gateway(iSCSI)
- 데이터를 비동기적으로 EBS 스냅샷 형식으로 S3에 저장
- Stored Volumes: 모든 데이터를 로컬에 저장하고 비동기적으로 AWS에 백업
- Cached Volumes: 자주 사용하는 데이터만 로컬에 남겨두고 모두 AWS에 백업
- Tape Gateway(VTL)
- 이미 존재하는 Tape 기반 백업 어플리케이션을 위한 서비스
- File Gateway
r
- AWS의 DNS 서비스
- 위치는 VPC 외부에 존재
- AWS에서 서버 성격을 가진 S3, EC2, CloudFront 등의 서비스를 쉽게 연동
- 도메인을 통해 여러 개의 서비스로 부하 분산
- AWS 내부, 외부 인프라를 라우팅하는데에도 사용
- 서로 다른 리전에 있는 리소스들을 라우팅하는 데에 사용
- 기능
- 도메인 구입, 네임 서버 등록 등의 기능 제공
- 각종 다양한 로드밸런싱 기능 지원
쿼리 로깅 구성을 통해서 모니터링 가능
- 라우팅 정책
- 장애 조치: 헬스 체크를 해서 반응하지 않으면 트래픽을 보내지 않음
- 지리적 위치: 사용자의 위치를 기준으로 가까운 리전에 트래픽을 보냄
- 지연 속도 기반: 트래픽을 보낼 때 테스트를 하며 지연속도가 빠른 쪽으로 트래픽을 보냄
- 다중값 응답: DNS에 여러 IP주소가 있을 때, 여러 값에 반응
- 가중치: 트래픽에 %를 지정하여 트래픽 분산 가능
- Route 53 Resolver
- 하이브리드 클라우드용
- 온프레미스와 AWS 간에 원활한 DNS 질의 확인이 가능
- Amazon EC2
AWS 클라우드 컴퓨팅의 중심 구성 요소. 가상화 서버 - Amazon ECS(Elastic Container Service)
Docker 컨테이너를 사용하여 EC2 인스턴스의 관리형 클러스터에서 분산 애플리케이션 기능 도입 - AWS Lambda
서버리스. 완전 관리형 서비스. - AWS Fargate
ECS는 결국 가상 서버에 올리는 것이다. (EC2에 올라감)
따라서 컨테이너를 좀 더 자동화하여 사용하기 위해서 나타남
- 안전하고 크기 조정 가능한 컴퓨팅 용량을 제공함.
- 수요 변화에 맞춰 컴퓨팅 용량 추가/제거 가능.
- 리전의 물리 서버가 EC2 인스턴스를 호스트.
- 인스턴스의 소프트웨어를 결정한다.
- Linux, Windows, 64/32 bit 등
- 이점: 반복, 재사용, 복구 가능
- 작성된 인스턴스에서 생성할 수 있음. (Amazon EC2 Image Builder)
- AWS 기본 제공/Marketplace/community AMI
- 인스턴스의 하드웨어를 설정한다.
- F.G.A.S 유형 (t3n.large)
- Family: CPU 타입을 저장한다.
- 범용: 메모리:vCPU = 4:1
(t시리즈: 기준 성능 이상의 버스팅을 할 수 있음. 트래픽이 들쑥날쑥할 때 사용 / m시리즈. 트래픽이 안정적일때) - 메모리 최적화: 메모리:vCPU = 8:1
- 컴퓨팅 최적화: 메모리:vCPU = 2:1
- 스토리지 최적화: 스토리지 읽고 쓰기가 빈번한 컴퓨팅
- 액셀러레이티드 컴퓨팅: GPU 중심. 머신러닝 등을 위한 컴퓨팅.
- 범용: 메모리:vCPU = 4:1
- Generation: 인스턴스 세대 (최신 CPU가 가성비가 좋음)
- Attribute: 속성 (n: 네트워크 )
- Size: 인스턴스 크기
- Family: CPU 타입을 저장한다.
- Compute Optimizer: 기계 학습을 사용하여 최적의 인스턴스를 사용할 수 있도록 권고
- EC2, EBS, Lambda
- 클러스터 배치 전략
- 동일한 AZ에 배치하는 전략
- 네트워크 성능을 최대로 올림
- 데이터 교환에 드는 비용 X
- HPC에 사용됨
- 분산 배치 전략
- 여러 AZ에 분산해서 배치
- 가용성에 초점을 맞춤
- 한 AZ당 최대 7개 인스턴스 배치 가능
- 파티션 배치 전략
- 여러 AZ 안에 파티션을 두고, 여러 인스턴스를 클러스터처럼 배치
- 고가용성과 내구성을 높이기 위한 데이터 복제 (Hadoop과 같은 분산 처리 환경 시스템)
아래 설명되는 인스턴스들을 섞어서 사용함
- 온디맨드
- 들쭉날쭉 워크로드 또는 일시적 필요
- 약정없이 시간 단위로 컴퓨팅 용량을 구입
- 예약 인스턴스
- 1년~3년 약정 및 안정적 상태의 사용량
- 수요 예측이 확실할 때 사용
- 온디맨드 요금 대비 할인
- 표준 예약 인스턴스
- 온디맨드 대비 최대 72% 할인
- 사용량이 지속적인 경우
- 컨버터블 예약 인스턴스
- 온디맨드 대비 최대 54% 할인
- 변경 결과가 동일하거나 더 높은 값이면 예약 인스턴스의 속성 변경 가능
- 표준 예약 인스턴스
- 1년~3년 약정 및 안정적 상태의 사용량
- Savings Plans
- 예약 인스턴스에서 더 높은 유연성
- Fargate, Lambda 사용량에 적용됨
- 1년~3년
- 예약 인스턴스에서 더 높은 유연성
- 스팟 인스턴스
- 내결함성, 유연성, 무상태 워크로드
- 온디맨드 요금 대비 최대 90% 할인
- AWS 용량을 필요할 때 가져다 쓸 수 있다.
- AWS가 필요할 때 언제든지 가져감 (2분 Notice)
- 가용성이 낮음
- 전용 호스트
- 물리적 서버 전체를 예약하고 인스턴스 배치 제어
- 기존 서버 결합 소프트웨어 라이센스 사용이 가능해서 비용 절감 가능
- 호스트를 타 고객과 공유할 수 없는 수준의 컴플라이언스
- 가격이 비쌈
- 전용 인스턴스
- 단일 고객 전용 하드웨어의 VPC에서 실행되는 인스턴스
- 단일 테넌트 하드웨어 실행되는 인스턴스 비용을 시간단위로 지불
- 블록 단위로 데이터가 저장됨
- 단일 가용영역의 EC2 연결 가능
- EC2 인스턴스와 독립적으로 지속됨 (비휘발성)
- 가용 영역 내에서 정의됨 (인스턴스와 연결하기 위해서)
- 컴퓨터의 SSD나 HHD역할
- 99.999% 가용성
- 스냅샷을 통한 백업 (S3)
- EC2에 포함된 스토리지
- 지속적이지 않음 (휘발성)
- 물리적으로 연결되어 있어 EBS보다 빠른 IOPS
컴퓨팅 집약도가 높은 워크로드를 실행하는 데 필요한 모든 요소를 지원
- 전산 유체 역할
- 에너지 및 공공 설비 시뮬레이션
- 자율 주행 차량
- 탄력적 네트워크 네트워크: 최대 10GB
- 탄력적 네트워크 어댑터: 최대 100GB
- Elastic Fabric Adapter: 최대 400GB
- 관리나 운영을 AWS에서 해주는 서비스
- 어플리케이션만 신경쓰면 됨
- 서버리스 컴퓨팅
- 다양한 언어 지원
- 최대 15분간 실행. 최대 10GB 메모리 지원
- 이벤트 방식으로 작동 (ex. S3에 데이터가 들어올 때)
- 웹 어플리케이션 (자유 사용하지 않지만, 꼭 필요한 어플리케이션)
- 백엔드
- 데이터 처리
- 챗봇
- Amazon Alexa
- IT 자동화
- 블록 스토리지: 원시 스토리지. 데이터가 관련없는 블록의 Array로 구성
- 파일 스토리지: 파일(서비스) 시스템이 관련 없는 데이터 블록을 관리
- 객체 스토리지: 데이터, 데이터 속성, 메타 데이터, 객체 ID 등을 객채화 후 저장
내구성이 뛰어난 객체 스토리지 솔루션
- 객체 = File + Meta data + key(고유 식별자, URL) 으로 저장
- URL이 주어지기 때문에 바로 접근할 수 있음
- 정적 데이터에 적합 (HTML, CSS, JavaScript)
- 조금만 바껴도 처음부터 다시 저장함
- 백업 및 복원
- 버킷 전체에 걸쳐서 비동기식으로 자동 복사 가능
- 만약 다른 리전에 복사하고 싶다면
교차 리전 복제가 가장 효율적 - 소유자 변경, 스토리지 클래서 설정 가능
- 비용 절감
- 공유 스토리지 중 비용 효율이 가장 좋음
수명 주기 구성을 통해서 데이터 삭제 가능- 지불
- 월별 GB, 다른 리전 또는 인터넷 전송, PUT/COPY/POST/LIST/GET 요청
- 비지불
- S3로 수신, 동일 리전 또는 CloudFront로 전송
요청자 지불 버킷을 통해 요청자만 비용을 지불할 수 있도록 설정 가능
- 보안 강화
- 저장되는 모든 데이터에 접근 권한을 줄 수 있음 (IAM)
- 버킷에 접근 권한을 설정할 수 있음
- IAM을 통해서 유저별, 그룹별 접근 제어 가능
- 외부 접근 차단 가능
- 새 ACL을 통해 부여된 버킷 및 객체
- 모든 ACL을 통해 부여된 버킷 및 객체
- 저장시 암호화를 할 수 있음
- SSE-S3: AWS 회사 자체에서 관리되는 키를 통해 암호화
- AES-256 알고리즘 사용
- 서버측 암호화만 지원 (클라이언트 측 암호화 X)
- SSE-KMS: KMS를 이용해서 암호화
- AWS가 마스터키 관리 / 사용자가 데이터 키 관리
- 키 관리 및 교체 자동화
- 키에 접근 가능한 유저 제어
- 고객 관리형 키여야지 제어 가능
- SSE-C: 사용자에 의해 직접 정의된 키를 통해 암호화
- HTTPS 프로토콜 반드시 사용
- SSE-S3: AWS 회사 자체에서 관리되는 키를 통해 암호화
미리 서명된 URL을 통해서 보안 강화- 임시로 생성하며, 일정 기간이 지나서 만료되면 사용할 수 없음
교차 계정 액세스 허용을 통해서 다른 계정과 공유 가능CORS를 통해서 다른 버킷에 대한 액세스가 가능- A 버킷에서 파일을 호출하며, B 버킷의 파일이 필요한데 이것이 원래 안 됨
- 저장되는 모든 데이터에 접근 권한을 줄 수 있음 (IAM)
- 버전 관리 가능
- 데이터 관리
- 거버넌스 모드: 일부 사용자에게 보관 설정을 변경하거나 삭제할 수 있는 권한 부여
- 규정 준수 모드: 루트 사용자를 포함한 어떤 사용자도 객체를 수정할 수 없음
- Linux 파일 공유 스토리지로 부적합
- S3에서는 데이터를 버캣 내에 객체 단위로 저장
- 버킷 무제한, 파일 하나당 5TB
- 리전 서비스. URL을 통한 외부에서 다이렉트 접근이 가능하다
- https://(버킷).s3.amazonaws.com/(prefix)/(파일명)
- https://my-bucket.s3.amazonaws.com/2006-01-01/pup.jpg
- Standard
- 자주 접근하는 활성 데이터
- 밀리초 내에 접근
- Intelligent-Tiering
- 접근 패턴이 변경되는 데이터
- 밀리초 내에 접근
- Standard-IA
- 자주 접근하지 않는 데이터
- 밀리초 내에 접근
- One Zone-IA
- 3개의 AZ에 저장하지 않고, 1개만 사용
- 재생성이 가능하고, 자주 접근하지 않는 데이터
- 밀리초 내에 접근
- 최소 과금 기간: 30일
- Glacier
- 가장 접근 빈도가 낮은 데이터 (분기당 1번)
- 접근 속도가 느림 (3~5 시간 소요)
비용 효율성이 높음- 저장소 잠금을 통해서 지우지 못 하도록 할 수 있음
- 분류
- Instant Retrieval(검색이 빠름)
- Fexible Retrieval(신속, 표준, 대량 검색으로 적당한 시간이 소요 검색 가능)
- Deep Archive(12시간 내에 검색이 가능)
- 용어
- Vault: Glacier의 최상위 폴더 디렉토리
- Archive: Vault 아래 실질적으로 데이터 저장되는 단위
- 가장 접근 빈도가 낮은 데이터 (분기당 1번)
- 수명 주기 정책을 통해서 객체 사용 기간에 따라 조치를 취할 수 있다
- 30일 이상 경과하면 S3 Standard-IA로 이동
- 365일 이상 경과하면 S3 Glacier로 이동
- S3 Transfer Acceleration
- 인터넷을 통해 S3 버킷에서 더 빠르게 데이터 업로드 가능
- 설정하게 되면 URL이 생성되어, Data > CloudFront > S3로 전송
- 장거리에 걸친 대규모 데이터 전송에 유리
- 추가 비용 발생
- AWS Transfer for SFTP
- Transfer Family를 이용해서 외부 S3로 SFTP 이용하여 액세스
- 이를 통해서 내부 외부에서 파일을 쉽게 액세스할 수 있음
- SFTP: 데이터를 안전하게 전송하는 데에 사용되는 네트워크 프로토콜 (SSH(Secure Shell) File Transfer Protocol)
- SSH의 모든 보안 및 인증 기능을 활용
- Transfer Family를 이용해서 외부 S3로 SFTP 이용하여 액세스
- 데이터 형식 간에 변환을 한다. (ex. XML > Json)
- 다른 서비스 또는 DB의 정보를 사용하여 데이터를 보강
- 다운로드할 때 파일을 압축 또는 해체한다
- 여러 인스턴스가 동일한 스토리지를 사용해야할 경우
- Snowball에서 바로 불러올 수 없음
- 서버리스 File System으로 공용 저장소로서 활용
- 스토리지 기준으로 오토 스케일링
- S3보다 비교적 빠르고 대규모 분석 작업 및 대량의 데이터 처리에 적합
- 수십~수백대의 EC2 연결 및 인스턴스 간에 데이터 공유
- 리전 서비스 > 3개 이상의 가용영역(AZ)에 저장됨 (99.999% 가용성, 내구성)
리눅스 OS인스턴스 용도NFS프로토콜 사용
- Throughput Mode: 데이터를 넣을 때 모드 (스토리지 사이즈 결정시 결정됨)
- Busting: 부하가 많이 걸리면 순간적으로 성능을 늘림
- Provisioned: 용량 크기에 상관없이 일정한 성능을 보임
라이프사이클 정책: 적절한 날짜 후에 변환 가능
EFS Infrequent Access(EFS IA): 드물게 액세스되는 파일 대상- 공식적으로 내구성에 대한 보장이 없음
- 완전 관리형 파일 시스템 제공
- Windows File Server
- Window 7까지 호환성
AD 인증지원SMB프로토콜 지원
- Lustre
- 고성능 컴퓨팅 환경(HPC)에 사용
- S3와 원활히 통합
- Linux 기반의 분산 파일 시스템
- 종류
- 스크래치 파일 시스템: 임시 스토리지 및 단기 데이터 처리
- 영구 파일 시스템: 장기 스토리지 및 워크로드 용도
- NETapp ONTAP
- OpenZFS
- 온프레미스 > 클라우드에 데이터를 옮김
- 오프라인 마이그레이션 솔루션
- 장비를 배송받고 보내는 시간이 일주일 넘게 소요됨
- 사례
- 네트워크가 간헐적이고 안정적이지 않음
- 네트워크 대역폭이 낮음
- 종류
- AWS Snowcone
- AWS Snowball Edge: 페타바이트. 데이터를 처리하여 AWS 서버에 데이터를 올릴 수 있음
- AWS Snowmobile: 초 대용량 엑사바이트
- 주로 데이터 전송 및 이동을 목적으로 하는 서비스
- 온프레미스와 AWS 스토리지 서비스 사이에서 데이터 이동을 자동화 및 가속화
- AWS 안에서 데이터를 이동할 때도 사용
- 다양한 프로토콜 지원 (NFS, SMB, HDFS, S3 API)
- 필터링, 무결성 검사, 스케쥴링, 재전송 등의 기능 제공
- DB 복제를 위해 복제 서버 생성
AWS에서는 다양한 데이터베이스를 제공함
- 정형화된 테이블로 구분됨
- 데이터 정확성 및 일관성을 제공 (데이터 관리에 용이)
- SQL을 활용하여 데이터에 접근할 수 있음 (분석을 위한 데이터의 경우)
- 관계형 데이터베이스
- 컴퓨팅 및 스토리지 크기 조정 (최소한의 애플리케이션 가동 중단)
- 자동 다중 가용영역에 데이터 복제
내결함성 - 다중 리전을 사용할 시에 속도가 줄어들 수 있음
스토리지 자동 확장활성화
- 자동 다중 가용영역에 데이터 복제
- 성능 향상
읽기 전용 복제본만들고 트래픽 연결 가능- 프로비저닝된 IOPS 옵션
- Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server 지원
- 암호화
- AWS KMS에서 관리
- 고유 데이터 키로 데이터 암호화
- 모든 RDS 엔진에서 사용 가능
- MySQL 및 PostgreSQL 호환되는 관계형 DB (특정 RDBMS만 지원)
- 성능 및 확장성 (3~5배)
- 가용성 및 내구성
- 3개의 AZ에 2개씩 복제본을 가짐. 최대 15개
- 단일 DB 인스턴스라도 데이터는 여러 AZ에 복제 및 분산 저장됨
- 다중 클러스터로 하나 죽으면 다른 하나 사용할 수도 있음
- 뛰어난 보안
- 완전관리형
- 간헐적으로 DB를 사용할 경우 사용
- 온디맨드로 시작하고, 사용하지 않으면 종료됨
- 서버리스를 선택하면 (EC2 서버를 선택하지 않음)
- Aurora 멀티 마스터 클러스터: 쓰기 가용성!
- S3에 저장된 데이터를 SQL로 분석하는 서비스
- 서버리스 분석 서비스
- 표준 SQL을 사용하여 S3에 저장된 데이터를 손쉽게 분석
- 다양한 데이터 유형에 대해서 분석 수행 가능
- AWS의 데이터 웨어하우스 (쓰기용 스키마, 정형 데이터, SQL 호환)
- 페타바이트 규모의 완전관리형 DW
- 온라인 분석 처리 (OLAP)
- 대규모 병렬 처리
- Amazon S3로 지속적인 자동 백업
- 예시
- 비지니스 인텔리전스 (
QuickSight 대시보드) - 이벤트에서 운영 분석
- 서비스형 데이터
- 예측 분석
- 비지니스 인텔리전스 (
- 완전 관리형
ETL서비스- 별도의 저장소가 없음
- 메타 데이터만으로 ETL 작업
- 데이터 스토어 및 데이터 스트림 간에 데이터 분류, 정리, 보강, 이동
- 북마크 기능
- 고성능 워커로 빠른 수행 가능
- 스케쥴링 기능
- 비정형화된 데이터베이스
- 유동적인 스키마 (데이터가 기존 스키마에 적합하지 않을 때 사용)
- 읽기/쓰기 속도가 SQL보다 빠름 (초당 수백만)
- 완전관리형 NoSQL DB
서버리스- 장애에 대한 복원력이 뛰어남
- 데이터가 수평적으로 확장되어 일관된 성능을 제공
- 규모에 따른 성능 향상
- Key-value 구조
- 키-값 페어로 구조화
- 단순하기 때문에 읽기/쓰기에 최적화됨
지정 시간 복구를 구성해서 원하는 시점으로 복원 가능- 5분전부터 가능
- 읽기 정합성
- 최종적 일관된 읽기
- 기본값
- 최근 완료한 쓰기 결과는 반영 못 할 수 있음 (1 초 내에 일관성)
- 강력된 일관된 읽기
- 성공적 응답을 수신한 모든 쓰기를 반영한 결과를 반환
- 최종적 일관된 읽기
스트림기능을 통해서 새로운 데이터에 대한 트리거를 걸 수 있음- 글로벌 테이블
- 리전 간 복제를 자동화
- 데이터가 손상되면 손상된 것도 반영되어버림
- 게임 서버의 경우 사용
- 리전 간 복제를 자동화
- 완전관리형 인-메모리 캐시
- 최대 10배의 성능
- 고가용성
- DynamoDB API 호출과 호환
읽기 성능 향상을 위한 솔루션
- 캐싱은 더 빠른 스토리지를 사용하여 읽기 성능을 객선
- 인메모리 데이터를 사용한다.
- 캐시에서 읽어옴 > 없으면 DB에서 읽어옴 > 캐시 업데이트 (Write-through)
- 인메모리 DB
- 탁월한 성능
- 완전 관리형
- 캐싱 성능을 사용해서 읽기 전용 복제본의 성능을 높일 수 있음
- 밀리 초 미만의 응답 제공 가능
- Redis, Memcached와 호환성
- Redis
- hash, set, list 등의 다양한 데이터 구조 지원
- 디스크 영구 저장 가능> 고가용성 제공
- 데이터 복제 지원
- 트랜잭션 지원
- Memcached
- 정적데이터 캐싱에 효과정
- 직렬화도니 형태의 데이터 저장에 효과적
- 멀티쓰레드 제공 > 데이터 손실없이 스케일링
- Redis
- TTL(Time To Live) 값을 각 애플리케이션 쓰기에 추가함
- TTL이 만료되면 DB에 데이터를 쿼리한다
- 운영 상태: 운영 가시성 및 인사이트 확보
- 애플리케이션 성능: 성능 스택의 모든 계층에서 데이터 수집
- 리소스 사용률: 리소스 최적화
- 보안 검사: 보안 및 무결성 관리
- 비용:
Cost Explorer에서 보고서 생성 및 다운로드
- 지표 및 로그를 거의 실시간으로 수집
- 경보를 생성하고, 알림을 전송
- 대시보드를 생성하고 확인
지표를 식별하여 경보를 생성하고, 정의된 작업을 실행한다.
- 지표 식별
임계값을 초과함/임계값을 초과하지 않음/정보가 부족함 - 경보 생성
- 작업 정의
- Event Bridge
자동화된 워크플로를 시작 (AWS 서비스 외의 이벤트에도 반응하게 설정할 수 있음)
Lambda, Step Function(Lambda 병렬 처리), SNS 등의 규칙을 정해서 실행시킬 수 있음
- Event Bridge
로드 데이터, 저장소 및 액세스 로그 파일을 사용하여 앱을 모니터링
- 로그 스트림을 통해 로그 이벤트를 수집 (인스턴스 등에서 발생)
- 로그 그룹(필터, 액세스 제어 설정, 보존, 모니터링)으로 묶을 수 있음
- CloudWatch 경보를 유도할 수 있음
- AWS 계정의 모든 활동에 대해서 기록하는 서비스
- "누가" 변경했는지 감시
- 사용자 활동 및 대부분의 API 사용량을 추적
- 자동으로 활성화, 최대 90일 기록
- 기능
- 로그 파일 유효성 검사: 파일이 유지, 삭제, 수정되었는지 확인
- Insights: Write API 호출에 관련한 비정상 활동 감지
- Organization과 연동하여 조직 내 모든 계정을 추적 가능
- AWS 리소스의 구성 변경에 대한 기록과 변경 알림
- "무엇이" 변경되었는지 감시
- 규칙 설정
- 규칙을 만들어 리소스 구성을 평가
- 리소스 구성이 규칙을 준수하는지 운영자에게 정보 제공
- 모든 규칙은 트리거 또는 주기적으로 설정될 수 있음
- 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보 수집
- ENI > VPC Flow Logs > Cloud Watch, S3
- Flow Log
- AWS 계정, 네트워크 인터페이스 ID, 시간 등을 포함
- 5분 간격으로 로그를 모은다 > S3에 저장
부하를 분산시킬 수 있는 솔루션
- 자동으로 트래픽을 여러 대상에 분산
- 상태 확인: 상태가 죽어있으면 트래픽을 보내지 않음
- 고가용성 제공
- EC2, ECS, Lambda 등 대상
- 엔드 포인트 제공
- 보안 기능 통합
- SSL: 전송 암호화
- TLS 리스너: 서버 인증
리스너 규칙을 통해서 리다이렉션 가능- HTTP > HTTPS
- Classic Load Balancer (CLB)
- 가장 초기에 제공된 서비스
- 서버의 기본 주소가 바뀌면 새로 생성해야함 (불편)
- Application Load Balancer (ALB)
- HTTP, HTTPS (리디렉션: HTTP<>HTTPS)
- IP 주소 + 포트번호 + 패킷 내용 확인
- 헤더정보를 이용해서 부하분산을 실시할 수 있음
- SSL 인증서 탑재 > EC2 대신에 암호화/복호화 대신 진행 가능
- 요청 수준(7계층)에서 작동
- HTTP, HTTPS (리디렉션: HTTP<>HTTPS)
- Network Load Balancer (NLB)
- TCP, UDP > 고성능을 요구하는 환경에 적합
공인 IP를 고정할 수 있음- 파티션 배치 그룹: 같은 가용영역 내에 서버 집합
- 연결 수준(4계층)에서 작동
- Gateway Load Balancer (GWLB)
- 트래픽의 고급 로드 밸런싱
- 요청 수준(3계층)에서 작동
- 3rd-party도 가능
- 부하가 늘어났을 때 자동적으로 서버를 줄이고, 늘릴 수 있는 기능
Cloudwatch, ELB와 함께 동작함- 모니터링하다가 서버를 늘리고, 이를 ELB에 정보를 보내준다.
- 주로 메트릭을 기반으로 조정
- 여러 서비스에서 짧은 간격으로 애플리케이션 스케일링을 제공
예측 확장활성화: 머신러닝을 이용해 필요한 용량 예측하여 확장- 충분한 데이터 필요
- 시작 구성
- 새로운 인스턴스를 시작할 때 기반이 되는 구성
- 시작 구성은 변경이 불가능
- 조정 정책
- 대상 추적 조정
- Autoscaling 그룹에 포함된 인스턴스의 부하량에 따라서 적용됨
- CPU 사용률, 네트워크 입출력 등 선택 가능
- 인스턴스 과부하 > CPU 사용률 확인
- 단순 조정 정책
- CloudWatch 경보로 설정한 인스턴스의 부하량에 따라서 AutoScaling이 적용된
- 그룹에 포함되어 있지 않은 인스턴스라도 가능
- CloudWatch 경보로 설정한 인스턴스의 부하량에 따라서 AutoScaling이 적용된
- 대상 추적 조정
수명주기 후크- 인스턴스 값을 조정한 후, 정의한 작업을 수행
- 인스턴스 시작/종료 시 작업 수행
- 인스턴스 설치/설정 등의 작업이 주로 이루어짐
- 인스턴스 값을 조정한 후, 정의한 작업을 수행
간편성 기준으로 오름차순
- Elastic Beanstalk
- CloudFormation
- Systems Manager
- EC2
- AWS의 서비스를 가장 효율적이고 유연한 인프라로 관리할 수 있도록 조합
- 인프라를 프로비저닝하고 운영
- 다중 AZ 설정 가능
- EC2 및 OS 설치
- 웹 애플리케이션 소프트웨어 구성
- 오토 스케일링 구성
- 로드 밸런서 구성
- 모니터링 관리 설정
- 인프라를 프로비저닝하고 운영
- 전문 DevOps 인력이 없는 조직에서 유용
- 템플릿 및 스택을 통해서 리소스 관리 및 프로비저닝
- 템플릿을 업로드 > API 요청으로 변환 > 리소스 스택을 형성
- AWS 리소스 스택을 정의하여 생성
- 구성
- 템플릿: 스택 리소스 프로비저닝 및 구성을 위한 파일 (Json, Yaml)
- 스택
- 하나의 단위로 관리할 수 있는 AWS 리소스 모음
- 스택의 모든 리소스는 템플릿을 통해 정의
- 스택을 삭제하면 모든 리소스 삭제
- 코드형 인프라(IaC. Infrastructure as Code)
- 복제, 재배포 및 용도 변경에 용이
- 새 버전 관리 제어
- 장애 발생시 서비스를 마지막으로 양호한 상태로 롤백
- 지원되는 언어를 활용하여 템플릿 생성
- 자동 완성 및 인라인 문서 지원
- 동일한 기본값 및 재사용 가능
많은 데이터를 중앙에서 한번에 관리하기 위해서 사용
- 운영 관리 (Explorer, OpsCenter)
- 애플리케이션 관리 (Resource Groups, AWS AppConfig, Parameter Store)
- 작업 및 변경 (자동화, 유지 관리 기간)
- 인스턴스 및 노드 (Inventory, Run Command, 패치 관리자)
- 무료 서비스
- 문제 탐지에 걸리는 시간 단축
- 작업을 자동화하여 효율성 향상
- 가시성 및 제어 개선
- 하이브리드 환경 분리
- 반복 가능
- 독립적 환경
- VM보다 더 빠른 가동/중단
- 이동성, 확장성
- 각각의 서비스들을 나누어서 개별성과 독립성을 넓힘
- 서비스 독립성은 장애 저항성을 높임
- 소결합: 로드밸런서와 메시지 대기열을 통해서 구성 요소들을 디커플링 한다.
- 마이크로서비스 및 서버리스 아키텍처를 사용하여 구축된 애플리케이션을 분석. 디버깅.
- 데이터 수집, 트레이스 기록, 문제 분석
- VM: 격리되어 있지만 동일한 OS 및 바이너리/라이브러리를 공유하지 않음
- OS가 각각 구축되어 있어야하기 때문에 무겁고, 느리다.
- Container: 격리되어 있지만 OS를 공유하고, 필요한 경우 바이너리/라이브러리 공유
- Container Image를 빌드 및 저장
- Container Image를 EC2에서 구동 및 관리
- Application Load Balancer에서 받은 작업을 여러 인스턴스에 분배한다. (장애가 나는 것에 대비)
- 대규모 컨테이너 실행
- 오픈 소스이기 때문에 클라우드에 종속적이지 않음
- 어디서든 실행 가능
- 별도로 인스턴스를 생성 관리하지 않고, 도커 컨테이너를 실행시킬 수 있는 서버리스 컨테이너 상품
- Docker 이미지가 push되어 있다면 클러스터 > 작업 정의 > 서비스로 생성 가능
- 상위 개념의 ECS, EKS를 선택해야함
- EC2와 달리 트래픽에 따라서 인스턴스 수가 관리될 수 있는 강점이 있음
- 프로비저닝 또느 관리할 인프라가 없음
- 오토 스케일링
- 내장된 보안, 고가용성 컴퓨팅
- 소결합, 확장성이 뛰어난 워크로드를 생성
- API 생성/관리/배포하는 완전관리형 서비스
- 마이크로 서비스를 위한 통합 API 생성
- 수천 건의 동시 API 호출
- Proxy 역할
- 사용자는 각 서비스를 호출할 필요 없이 API Gateway에 요청을 전달하여 관리가 용이해짐
- 보안
- WAF와 연동하여 DDoS 보호 및 제한 기능을 제공
- 인증/인가, 사용량 제어등
- CloudWatch로 모니터링 가능
- 활용
- Lambda와 연동하여 Serverless 서비스를 구축하는데 많이 사용
- 엣지 최적화 API 엔드포인트를 통해서 지연 시간을 줄일 수 있음
API Gateway response cache: 자주 사용하는 API를 관리
- 완전관리형 메시지 대기열 서비스
- 처리 및 삭제될 때까지 메시지를 저장
- 발신자와 수신자 간 버퍼 역할 담당
- 대기열 유형
표준- 순서 미지정
- 최소 1회이상의 수행을 보장
- 제한이 없는 초당 API 호출
FIFO- 순서 지정
- 1회 수행
- 제한된 초당 API 호출
- 가격이 더 비쌈
SQS 액세스 정책생성 및 다른 회사 계정에 공유 가능- 요청 오프로딩: 오래 걸리는 것들을 별도로 빼서 처리할 수 있음
- 성능 요구를 위한 오토 스케일링
- DLQ (Dead-Letter Queues)
- 최대 처리 시도 수를 넘어간 메시지
- 다른 큐에 따로 처리한다.
- 단일 메시지를 단방향으로 보냄
- 게시자와 구독자가 존재한다. (1:N)
- 구독자 유형: Email/SMS/모바일 푸시 알림
- 메시지가 지속되지 않음
| 기능 | Amazon SNS | Amazon SQS |
|---|---|---|
| 메시지 지속성 | X | O |
| 전송 매커니즘 | 푸시(수동적) | 풀링(능동적) |
| 생산자 및 소비자 | 게시자 및 구독자 | 발송 또는 수신 |
| 배포 모델 | 1:N | 1:1 |
- 실시간 데이터 수집 및 분석
- Kinesis Data Stream
- 실시간으로 data를 받으며, 저장소 역할을 함
- 일주일까지 데이터를 가지고 있을 수 있음
- 최소 지연시간
- 파이프라인 역할
- 리스닝 중인 애플리케이션에 데이터를 전달
- Kinesis Data Stream이 직접 작업하는 것이 아니라, 작업하는 곳에 전달함
- 샤드 수를 조정해서 수동으로 스케일링을 해야함
- 실시간으로 data를 받으며, 저장소 역할을 함
- Kinesis Data Firehose
- 정의된 목적지에 데이터를 안전하게 전달
- S3, ElasticSearch, Redshift 등의 Data Lake 등이 목적지
- 자체적으로 데이터를 가지고 있지는 않음
- 람다와 함께 Data Transfer 역할을 수행할 수 있음
- 스케일링이 자동으로 이루어짐
- 정의된 목적지에 데이터를 안전하게 전달
- 애플리케이션 기능을 단계별 실행
- 각 단계를 자동으로 시작하고 추적
- 단계가 실패할 경우, 간단한 오류 파악 및 로깅 제공
- 시각적 워크플로를 사용하여 마이크로서비스 조정
- 병렬 수행, 반복 수행도 가능
- 엣지 로케이션(사용자로 부터 가장 가까운 데이터 센터)에서 진행되는 솔루션
- 따라서
글로벌 서비스에 적합
- 따라서
- 어플리케이션의 성능을 증가시키기위한 솔루션
- AWS의 글로벌 콘텐츠 전송 네트워크(CDN, Content Delivery Network)
- 400개의 엣지로케이션 네트워크를 사용한다
- 지연 시간 감소 + 비용 감소
- 보안 강화
- WAF, Shield와 통합
서명된 URL을 사용해서 승인된 사용자만 접근할 수 있도록 제공 가능
- 동적 데이터, 정적 데이터 모두 캐싱.
- 동적 데이터는 변경되는 데이터라 의미가 없어보이지만, CloudFront와 Origin 사이가 AWS 전용망으로 구성되어있어 더 빠름
- 오리진 그룹 설정 가능 (오리진 장애조치/Failover)
- A 버킷을 기본, B 버킷을 보조
- 네트워크 성능 최적화 (TCP, UDP)
- 사용자와 AWS 사이에서 인터넷을 사용할 필요 없이
AWS 전용망을 이용 - 글로벌 사용자들에게 애플리케이션 성능을 향상시켜주는 서비스
- 사용자와 AWS 사이에서 인터넷을 사용할 필요 없이
2개의 글로벌 고정 IP허용- 정상 활동 중인 엔드포인트로 리디렉션 가능
| CloudFront | Global Accelerator |
|---|---|
| 7 계층 HTTP 또는 HTTPS | 4 계층 TCP 또는 UDP |
| 콘텐츠 캐싱 O | 콘텐츠 캐싱 X |
| DNS 기반 | AnyCast (최적의 경로의 IP에 연결) |
| 동적 IP | 2개의 글로벌 고정 IP주소 |
- DDoS: 감염된 호스트가 트래픽을 비정상적으로 높여 서비스를 이용하지 못 하게 공격
- DDos > Shield > AWS Firewall Manager (AWS WAF)
- AWS WAF 와 연동: CloudFront, Route 53, API Gateway
- 일반적인 DDos 공격을 막음.
- 3, 4 계층 네트워크 방어 (SYN 플러드, UDP 리플렉션 공격 방어)
- 무료. 기본 제공.
- 인바운드 트래픽에 대해서 웹 ACL을 만들어 보호
- 웹 ACL 규칙 구문을 사용하여 트래픽 제어
- 공격 방지: XSS 탐지, AWS의 관리형 규칙
- 트래픽 필터링: 비율 제한, IP 필터링
- 패턴 일치: 정규식, 문자열 일치
- 로깅(Kinesis Data Firehose), 지표(CloudWatch)
- AWS WAF > CloudFront > S3 (원본 액세스 ID/OAI) / EC2
- 만약 악성 IP가 발견되는 WAF에 설정
- OAI를 생성해서 S3 URL으로는 직접 접속하지 못 하도록 설정 가능
- 특정 국가 액세스 제한 가능
AWS WAF나 VPC 보안 그룹의 운영 및 유지 관리를 단순화
- 계정 및 리소스 수가 많을 때
- 지속적으로 새 애플리케이션이 생성됨
- 조직 전체의 위협에 대한 가시성
- 사내 앱과 AWS 앱을 연결해준다
- 짧은 지연 시간을 구현
- 리소스
- 컴퓨팅 및 스토리지: EC2, EBS, S3
- 네트워킹: VPC, Load Balancer
- DB: RDS, ElastiCache
- 컨테이너: ECS, EKS
- GuardDuty: AWS 계정 및 워크로드 모니터링 및
보안 - Congnito: 로그인 및 인증
- Inspector: EC2 및 컨테이너의 소프트웨어 취약성
- Macie: 머신러닝을 활용 민감 데이터 보호
- ACM(AWS Certificate Manager): 인증서 관리
- ASM(AWS Secrets Manager): 자격 증명 관리, 자동 교체
- 고가용성: 앱의 가동 중단 시간 최소화 (빠른 재해 복구)
- 내결함성: 내장된 중복성
- 백업: 데이터를 안전하게 유지
- 재해 복구: 재해 발생 후 앱 및 데이터를 복원, 새로운 리전에 재해 복구
- RPO (복구 시점 목표)
- 얼마나 자주 데이터를 백업해야하는가?
- RTO (복구 시간 목표)
- 앱을 얼마나 오래 사용할 수 없는가?
- 다중 리전
- 1개의 리전 내 2개 이상의 가용 영역을 사용
- 리전을 중복으로 사용할 때도 있다. (글로벌 서비스의 경우)
- 스토리지 복제
- Amazon S3: 교차 리전 복제 (기본적으로 리전에 3개의 AZ에 저장)
- Amazon EBS: 특정 시점 볼륨 스냅샷
- 스냅샷을 시간이 꽤 걸림
- Snowball: 대용량 데이터 빠르게 전송
- DataSync: 온프레미스 또는 클라우드 파일 시스템의 파일을 EFS와 동기화
- 복구용 AMI 구성
- 사용자 지정 AMI(골든 이미지) 사용
- EC2 인스턴스 또는 컨테이너가 죽었을 때, 이미지를 활용하여 복원한다.
- 네트워크 설계
- Route 53: 트래픽 분산 및 장애 조치
- ELB: 로드 밸런싱, 상태 확인 및 장애 조치
- VPC: 온프레미스 네트워크 토폴로지
- Direct Connect: 온프레미스 환경의 빠르고 일관적인 복제 및 백업
- DB 백업 및 복제본
- Amazon RDS: 읽기 전용 복제본을 다중 AZ와에 저장, 데이터 스냅샷을 다른 리전에 저장 (자동 백업을 보존)
- Aurora 글로벌 데이터베이스
- DynamoDB: 전체 테이블을 몇 초만에 백업, 글로벌 테이블로 전 세계에 다중 마스터 테이블 생성
- 중앙 집중식 백업 전략
- AWS 리소스 간에 백업
- 완전 관리형 서버리스 서비스
- 백업 일정의 시점 및 빈도를 정의
- 수명 주기 정책을 사용하여 이동 시점 및 보존 기간을 결정
- 태그 또는 리소스 이름을 사용하여 리소스 할당
- 백업을 관리하고 모니터링