Ian's Archive 🏃🏻

thumbnail
AWS CertifiedDeveloper - Associate 대비 정리 1
Cloud
2023.08.09.

AWS를 통해 스케일 조정이 가능한 서비스 및 서버를 제공받는다.

1. AWS 개요

1.1 AWS의 구성요소

  • Regions, Availability Zone, Data Centers, Edge Locations / Points of Presence (리전, 가용영역 범위, 데이터센터, 엣지로케이션 / 전송지점)

리전(Region) : 데이터 센터 집합

  • 법률 준수 여부 - 법률 상 데이터가 대상 국가 내에 보관되길 원하는 경우
  • 지연시간 - 서비스를 하려는 국가 근처
  • 요금 - 서비스 요금
  • 리전 테이블을 통해 리전에서 특정 서비스가 제공되는지 여부 확인 가능

가용영역 (Availablility Zone) : 가용영역은 리전 내 존재 (2 ~ 6개, 보통 3개)

  • AZ를 표시할 땐 리전코드(국가코드 + 위치(숫자))와 식별문자(소문자) 조합하여 표현
  • 각각의 가용 영역은 여분의 전원 네트워킹, 통신기능을 갖춘 하나 또는 두개의 데이터 센터
  • 각각의 가용 영역들이 재난 발생에 대비해 서로 분리되어 있다.
  • 동일 리전 내 존재하는 복수의 AZ는 서로 물리적으로 격리되어 있지만, 좋은 품질의 네트워크 연결을 통해 논리적으로 연결되어 있다.
  • 서비스를 어느 AZ에 배포할 지는 인스턴스를 만들 때 AWS 사용자가 직접 선택할 수 있고, AWS가 사용자를 위해 선택 가능
  • AZ에 장애가 발생할 경우 Elastic IP를 사용해 다른 인스턴스에 신속하게 다시 매핑하여 인스턴스나 소프트웨어의 오류를 마스킹할 수 있다.

Edge Locations : 42개국에 200개가 넘는 전송지점 소유 -> 최소 지연 시간으로 사용자에게 컨텐츠를 전달하는데 유용

  • 기본 TTL : 24hr
  • Cache 기본 저장 시간 : 24hr

1.2 AWS 책임

AWS Shared Responsibility Model에 따르면 보안과 규정 준수는 AWS와 고객의 공동 책임


1.3 AWS Service Level

AWS의 서비스들은 아래와 같이 3종류의 Level 을 가지고 있으며, 각 Level에 따라 해당 서비스에 접근할 수 있는 범위가 달라진다.

  • Global Service : ID 및 액세스 관리 (IAM), Route 53(DNS서비스), CloudFront(콘 텐츠 전송 네트워크), WAF(웹 애플리케이션 방화벽)
  • Regional Level : VPC, S3, AMI, DynamoDB 등
  • AZ Level : EC2, Subnet, EBS 등

항목별로 간단히 설명하면

Global Level은 Region이나 AZ에 상관없이 사용할 수 있다.

Object Storage인 S3를 예로 들면, Regional Level이기 때문에 같은 Region에 있는 서비스(예를 들어 EC2)라면 AZ에 상관없이 S3에 자유롭게 접근할수 있다. 반면에 다른 Region에 있는 EC2라면 기본적인 방법으로는 접근할 수 없다.

lock Storage서비스인 EBS는 AZ Level이기 때문에, 동일 AZ에 있는 서비스만 사용할 수 있다. 반면에 같은 Region이더라도 다른 AZ에 있는 EC2라면 해당 EBS를 사용할 수 없다

화재나 지진 등 AZ단위의 장애발생시 EBS는 영향을 받기 때문에(S3는 영향을 받지 않는다) 장애가 복구되기 전까지는 저장되어 있는 데이터를 사용할 수 없다.

만일 AZ에 문제가 생기더라도 유지되어야 하는 데이터라면, 주기적인 Snapshot을 만들던가 S3같은 Region 단위의 스토리지 서비스를 사용해야 한다.

2. IAM

IAM(Identity and Access Management) : 사용자 생성 및 그룹 배치

  • 루트 계정은 첫 번째 IAM 사용자와 몇 가지 계정/서비스 관리 작업을 생성할 때만 사용
  • 한사람이 여러개의 그룹을 가질 수 있다. (인라인 정책을 통해 개별 사용자에게 정책 설정 가능)
  • 그룹 별 정책 설정 가능
  • 사용자 권한 설정은 JSON 문서를 통해 작성 (editor를 통해 추가가능)
  • 최소 권한의 원칙 적용
  • 태그를 통해 사용자, 그룹, aws 내 리소스에 대한 정보추가 가능

추가로 태그는 AWS내 모든 리소스에 대해 정보 추가하는데 사용!


계정 Tip!

  • AWS의 root account는 ID가 숫자형식(계정번호) 인데, 계정에 별칭을 줘서 해당 별칭으로 로그인 가능
  • IAM 계정의 aws에 로그인하기 위해서는 https:{별칭}.signin.aws.amazon.com/console로 접속 -> 로그인 페이지로 리다이렉트 해준다.

그룹 Tip!

IAM 사용자 그룹에는 IAM 사용자만 포함


2.1 JSON 정책 문서 구조

  • 문서 상단에 위치하는 정책 전반의 선택적 정보
  • 하나 이상의 개별 문

IAM 정책은 하나 이상의 문으로 구성됩니다.

Keyword Description
Version 사용하고자 하는 정책 언어의 버전을 지정
ID 정책 식별자
Statement 이 주요 정책 요소를 다음 요소의 컨테이너로 사용, 정책에 설명문 둘 이상을 포함 가능
Sid(선택 사항) 선택 설명문 ID를 포함하여 설명문들을 구분
Effect Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명
Principal(일부 상황에서만 필요) 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시, 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함 불가능. 보안 주체는 사용자 또는 역할을 의미
Action 정책이 허용하거나 거부하는 작업 목록
Resource(일부 상황에서만 필요) IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정, 리소스 기반 정책을 생성하는 경우 이 요소는 선택 사항, 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스
copyButtonText
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": ["s3:List*", "s3:Get*"],
      "Resource": [
        "arn:aws:s3:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
    }
  ]
}

2.2 IAM MFA (Multi Factor Authentication)

  • IAM은 기본적으로 패스워드를 각종 정책을 통해 설정이 가능하다
  • 추가로 각종 MFA 디바이스를 사용해 보안강화 가능

AWS는 3가지 방법을 통해 접근 가능

  • AWS Management Console : 비밀번호 + MFA
  • AWS Command Line Interface : 엑세스 키
  • AWS Software Developer Kit : 엑세스 키

2.3 IAM Role & Security Tool

AWS는 서비스에 대한 IAM 설정이 가능

  • ex) EC2, Lambda

AWS security tool

  • IAM Credentials Report (account - level)
    • 사용자의 자격증명 상태 표기한 보고서 생성 가능
  • IAM Access Advisor (User-level)
    • 해당 서비스의 권한과 마지막으로 엑세스 시간 확인 가능

-> tool을 통해 권한 사용 여부를 파악해 최소 권한의 원칙을 지킬 수 있다.


정리해보면 AWS는 IAM기능을 통해 사용자를 추가할 수 있고 사용자에 대한 권한 부여는 정책을 통해 관리한다.

AWS 서비스가 다른 AWS 서비스에 대해 작업을 실행하도록 권한을 부여하려면 IAM Role을 부여 해 권한 설정 가능

3. EC2 (Elastic Compute Cloud)

3.1 EC2 Basic

EC2란 Amazon Elastic Compute Cloud의 줄임말로서 AWS에서 제공하는 클라우드 컴퓨팅으로 컴퓨터를 임대해주는 서비스로 대표적인 상품이다

EC2는 단순히 하나의 서비스가 아니라 여러 기능을 포괄하는 개념으로 기능에 따라 분류해보면

  • EC2 Instance : 가상 머신 임대
  • Network-attached storage : EBS, EFS
  • Hardware storage : EC2 Instance Store

EC2 인스턴스는 네트워크 카드와 IP설정이 가능하고 방화벽 규칙을 적용해 보안 기능을 적용할 수 있다.

부트스트랩 스크립트를 이용해 인스턴스를 처음 시작할 때 업데이트나 소프트 웨어 설치같은 작업을 자동화 할 수 있다.(root 권한으로 이루어짐 / 사용자 데이터)

인스턴스의 이름은 다음과 같은 네이밍 컨벤션이 있다.

t2.micro

t : 인스턴스 클래스
2 : 버전
micro : 인스턴스 클래스 내 크기

인스턴스의 몇가지 종류에 대해 살펴보면

t : 범용 인스턴스 -> 웹서버, 코드 레포지토리
c : 컴퓨팅 최적화 인스턴스(고성능 프로세서 활용) -> batch, 고성능 웹서버
m : 메모리 최적화 -> DB, 웹 캐시 저장
l, D : 스토리지 최적화 -> 로컬 스토리지의 대규모 데이터 세트에 대한 높은 읽기, 쓰기 엑세스 권한이 필요한 경우 (고성능 DB)

AWS 인스턴스 종류


3.1.1 EC2 Security

EC2는 Security Group(보안그룹)을 traffic(InBound, Outbound) 허용 규칙을 설정할 수 있다.
(허용 규칙만 사용)

인스턴스는 여러 보안 그룹을 가질 수 있다

기본적으로 모든 인바운드 트래픽은 기본적으로 차단되고, 아웃바운드 트래픽은 승인된다.

하나의 인스턴스는 여러 보안그룹을 가질 수 있는데 Region, VPC에 따라 적용 된다.
따라서 Region이나 VPC가 변경되는 경우 새로운 보안 그룹을 적용한다

-> SSH 전용으로 별도의 보안 그룹을 관리하는 방법이 좋다.


3.1.2 EC2 Purchasing

type description
On-Semand Instances 기본 옵션, 장기 약정이나 선 결제 금액 없이 초단위로 사용한 인스턴스에 대한 요금 지불
Saving Plans 1년 or 3년 기간 동안 시간당 USD로 특정 사용량을 약정해 비용 절감 (약 72%)
초과 시 온디맨드 가격으로 청구
Reserved Instance(RI) 1년 or 3년 기간 동안 인스턴스 유형 또는 지역을 포함해 인스턴스 구성을 예약하고 비용 절감, Convertible Reserved Instance로 설정 시 인스턴스 타입 변경 가능
거의 변경 못함
Spot Instance 가장 할인률이 큰데, 짧은 단기 워크로드용 인스턴스로 스팟 가격보다 사용자가 제시한 최고 가격이 더 높을 때만 실행된다 (중단 되어도 되는 App에 적합, DB X)
배치 작업, 데이터 분석, 이미지 처리 및 분산된 워크로드
EC2 Dedicated Hosts 실제 물리서버 예약, 보안 규정 상 호스트를 타 고객과 공유할 수 없는 수준의 컴플라이언스(compliance)를 지켜야 하는 경우 혹은 기존에 온-프로그레미스 환경에서 보유한 고정 서버 방식의 소프트웨어 라이선스를 재사용하여 비용을 아껴야 하는 경우
가장 비싼 옵션
EC2 Dedicated Instance 인스턴스를 구동하게 되면 그 인스턴스가 할당된 물리적 서버는 같은 AWS 계정(account)의 인스턴스만 할당되어 사용하는 옵션

dedicated

Dedicated Instance -> 하드웨어에 고유한 인스턴스를 가지는 것 / 호텔의 방

Dedicated Host -> 물리적 서버를 점유 (ex - CAD) / 호텔 전부

3.2 EC2 Instance Storage

물리적 서버에 연결된 하드웨어 드라이브를 EC2 Instance라 한다.

주의 할 점으로 EC2 인스턴스를 종료시키면 해당 스토리지 또한 손실된다.

즉, 버퍼나 캐시, 임시콘텐츠를 잠시 저장하는 용도 (최고 I/O성능 제공)

3.2.1 AMI(Amaozn Machine Image)

소프트웨어 구성이 기재된 템플릿

AMI를 토대로 원하는 운영체제, 런타임, RAM, 용량, CPU등이 세팅된 EC2 생성 가능

AMI는 AZ마다 구축이 되며, 다른 AZ에서 사용할 경우 복사한 다음 사용해야 한다.

3.2.2 EBS(Elastic Block Store)

EBS : 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브

  • 인스턴스가 종료 된 후에도 데이터 유지가능
  • CCP level - 1개의 인스턴스에 하나의 ebs 마운트, Associate level 1개의 인스턴스에 다수의 ebs마운트 가능
  • 특정 Availability zone에 연결 가능
    • ex) us-east-1a에서 생성된 경우 us-east-1b 연결 불가
    • snapshot기능 활용 시 볼륨 옮기기는 가능
  • EC2 인스턴스를 통해 EBS Volume을 생성하는 경우 종료 시 삭제 옵션이 default(비활성화 가능)
    • ex) 인스턴스 시작 후 root 볼륨, EBS볼륨 2가지가 있을 때 인스턴스 삭제하면 root볼륨은 삭제되고, EBS볼륨은 삭제되지 않는다.

EBS는 다양한 볼룸을 가지고 있는데 총 6개의 유형이 있다.

중요한 내용으로는 gp2와 프로비저닝을 마친 IOPS가 있는데 각각 살펴보자

여기서 나오는 IOPS는 (Input/output Operations Per Second)로 저장장치의 속도를 나타낸다.

  • gp2는 범용 ssd로 대부분의 워크로드에 이 볼륨을 사용하는 것이 좋다.
    • 디스크 크기가 증가하면 IO증가 (5334GB / 16000IOPS IOPS최대 더이상 늘리지 못함)
  • 프로비저닝 된 IOPS SSE(io1, io2)는 높은 스토리지 성능과 일관성이 필요한 부분에 사용한다. (64000IOPS)
    • 독립적으로 IO증가 가능
  • st1(HDD)은 자주 엑세스 하고 처리량이 많은 빅데이터나 로그 처리에 적합
  • sc1은 접근 빈도가 낮은 데이터에 적합 (백업)
  • 부팅 볼륨으로는 gp2, gp3, io1, io2 (ssd)만 가능

추가로 다중 첨부 기능을 사용하면 동일한 EBS볼륨을 동일한 AZ(가용영역)에 있는 EC2 인스턴스에 첨부 가능
-> io1, io2 제품군에서만 사용이 가능하고 하나의 볼륨은 한번에 최대16개의 EC2 인스턴스에 부착 가능

EBS SnapShot

EBS Snapshot : 특정 시점에 백업 된 EBS 볼륨

AZ에서 EBS 볼륨을 마이그레이션 하려면 Snapshot기능 활용
-> 기능 사용 시 볼륨 내 IO를 전부 사용하니 인스턴스가 EBS를 사용중이 아닐 때만 실행해야 한다.

  • EBS Snapshot archive : 75% 저렴하고 복구 시 24시간에서 72시간 소요
  • EBS Recycle Bin : 스냅샷 삭제 시 보관, 1일 ~ 1년 설정 가능
  • FSR(Fast Snapshot Restore) : 스냅샷 완전 초기화 (가격이 비싸다)

3.2.3 EFS(Elastic File System)

관리형 NFS(Network File System)

  • 많은 EC2 인스턴스에 마운트 가능 (16개 까지)
  • 서로 다른 AZ(가용영역)에 있는 EC2도 가능
  • 가용성이 높고, 확장성이 뛰어나면서 비용도 gp2 EBS볼륨의 3배 (사용량에 따라 부과, 자동 확장)
  • Linux기반 AMI와만 호환가능
  • KMS를 사용하여 미사용 데이터 암호화 가능
  • 필요에 따라 I/O를 높은 모드로 사용 가능(default 범용)
  • 온프레미스와 연동 가능

EFS는 스토리지 클래스라는 기능이 있는데 자주 엑세스 하지 데이터는 EFS-IA에 저장 가능

  • 사용 시 생명주기 정책을 설정해야 한다.
  • 비용 절감 가능(90%) 단, 검색 시 비용 발생

4. ELB(Elastic Load Balanceer) + ASG(Auto Scaling Group)

확장 종류

  • 수직적 확장 : 인스턴스 크기 확장 (RDS, Elastic Cache, EC2)
  • 수평적 확장 : 인스턴스 수 확장 (EC2 추가)
  • 고가용성 : 수평 확장과 함께 실행 (RDS 다중 AZ, 여러 AZ에서 동일 APP실행)

4.1 ELB

여러 서버에 트래픽을 전달해 부하 분산

  • 로드 분산
  • 단일 엑세스 지점(DNS) 노출
  • 인스턴스 상태 확인 (ELB Health Checks : 비정상 인스턴스로 트래픽 전송x)
  • 웹사이트에 SSL 제공
  • App에서 사용할 수 있는 static DNS이름 제공
  • ALB의 경우 동일한 클라이언트에 대한 트래픽이 동일한 인스턴스로 리다이렉트 할 수 있는 기능을 제공하는데 ELB Sticky Session이라 한다
    • Application 기반 쿠키는 AWSALBAPP라는 이름을 가지고, 로드밸런서에서 생성되는 기간 기반 쿠키는 AWSALB라는 이름을 가짐
  • 보안 처리 시, 해당 쿠키 제거에 주의해야 함

종류

  • CLN (Class Load Balancer) : HTTP, HTTPS, TCP
    • app개수만큼 로드 밸런서 필요
  • ALB (Application Load Balancer) : HTTP, HTTPS, WebSocket
    • 자신의 이름에 해당하는 리스너 ID, 사용자 요청을 건네줄 판단 기준이 되는 규칙 보유
    • 경로 기반 라우팅
    • 쿼리 문자열과 헤더 기반 라우팅
    • 호스트 이름 기반 라우팅
    • MSA기반, Container기반 App에 가장 좋은 로드 밸런서 (포트 매핑 기능 존재)
    • X-Forwarded-For헤더로 사용자 IP전달해 사용자 구별
  • NLB (Network Load Balancer) : HTTP, HTTPS,TLS, UDP
    • AZ당 하나의 정적 IP를 가지며 탄력적 IP할당
    • AWS프리티어에는 포함되지 않고 높은 성능이 필요할 때 사용
    • 경로, 호스팅 기반 사용 불가
  • GWLB (Gateway Load Balancer) : 레이어 3(네트워크 계층)에서 작동 (IP프로토콜)
    • 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용
    • 6081포트를 사용하고 GENEVE 프로토콜

4.2 Cross-Zone Load Balancing

교차 영역 로드밸런싱을 사용할 경우 모든 AZ의 등록된 인스턴스에 고르게 분산된다.

  • ALB : 기본적으로 활성화, AZ간 데이터에 대한 요금 x
  • NLB : 기본적으로 비활성화, 활성할 경우 AZ간 데이터에 대한 요금 지불

4.3 SSL / SNI

SSL사용 시 암호화 통신 가능

SNI : 하나의 웹 서버에 여러 SSL을 로드해 여러 웹사이트 지원

최신 프로토콜이며 클라이언트가 초기 SSl 핸드셰이크에서 대상 서버의 호스트 이름 나타내도록 요구 (ALB, NLB, CloudFront에서 작동)

4.4 Connection Draining(등록 취소 지연)

인스턴스가 등록 취소, 비정상인 상태에 있을 때 어느정도 시간을 주어 활성 요청을 완료할 수 있게 설정하는 기능

  • 취소중인 인스턴스로 새요청 전송 중지 시간 1~3600 (기본 300)

4.5 Auto Scaling 그룹

트래픽에 따라 ec2 추가 및 제거

  • 기능은 무료, EC2 인스턴스와 같은 리소스 비용만 추가
  • 스케일링 정책 정의 필요 (최소 크기, 최대 크기, 초기 용량)
  • CloudWatch를 통해 경보 가능
  • 정책 설정 시 참고 지표 : CPU사용률, RequestCountPerTarget률(인스턴스 당 요청 수) 등

정책

  • Target Tracking Scaling (대상 추적 스케일링) : 기준선 설정 (ex - CPU)
  • Simple / Step (단순, 단계) 스케일링 : 몇가지 조건에 따라 설정
  • Scheduled Actions(예약된 작업) : 사용 패턴을 바탕으로 스케일링
  • Predictive Scaling(예측 기반) : 시간에 걸쳐 과거 로드를 분석하고 예측된 정보를 바탕으로 스케일링
  • Scaling Cooldown : 스케일링 작업이 끝날 때 마다 안정화 시간을 가짐, 새로운 지표의 양상을 살펴보기 위함
    • 요청을 빨리 처리하고 cooldown 시간을 줄이기 위해선 즉시 사용 가능한 AMI사용

Instance Refresh

  • 모든 EC2 인스턴스 재 생성
  • 구성 변경에 따라 인스턴스 교체 할 때, Auto Scaling 그룹에 포함된 인스턴스 수가 많을 때 사용
  • AMI에 새로운 데이터 스크립트가 있는 경우 유용

5. RDS + Aurora + ElastiCache

  • Postgres, MySQL, Oracle, MSSQL, Aurora
  • 백업 및 복원 지원
  • 모니터링 대시보드
  • DR(재해 복구)를 위한 다중 AZ지원
  • 스토리지를 동적으로 늘릴 수 있도록 지원

DB 복제

  • DB Replica : 최대 15개의 읽기 전용 인스턴스 지원 (약간의 시간차가 있어 데이터가 일치하지 않을 수 있음)
    • 같은 지역 / 다른 AZ 무료 , 다른 지역 일 경우 유료
  • Multi-AZ 복제(재해 복구) : 가용성 향상 (데이터 항상 일치, 복제 된 예비 인스턴스에서 읽기작업 불가)
    • 재해 복구를 대비해 읽기 전용 복제본도 다중 AZ로 설정 가능
  • Single-AZ to Multi AZ : 다운 타임이 전혀 없고, DB 수정 클릭 후 다중 AZ기능 활성화
    • 내부적으로 1) 스냅샷 생성 2) 새 AZ에 DB 생성 3) 동기화 설정

AuroraDB

AWS 최적화 RDS

  • 복제 프로세스가 MySQL보다 빠르다.
  • 비용이 20% 높지만 효율적
  • 백업 없이 언제든지 데이터 복원 가능

Aurora Cluster 엔드 포인트 유형

  • 클러스터 엔드 포인트 : writer에서 쓰는 엔드포인트, Failover가 발생해서 reader가 writer가 되면 자동 연결
  • 리더 엔드 포인트 : reader에서 쓰이는 엔드 포인트
    • DNS 기반의 Round Robin방식으로 로드밸런싱 기능 제공
    • reader 사용 불가 혹은 삭제같은 갑작스러운 outage 발생 시 다른 reader 사용하도록 유도
  • 커스텀 엔드 포인트 : writer, reader 바라볼 지 선택 가능
  • 인스턴스 엔드 포인트 : 인스턴스 자체 고유 엔드포인트

Aurora Cluster의 엔드포인트는 단순히 인스턴스를 바라보게 하는 수준에 그치지 않고

load balancing 등 여러 기능을 포함하고 있다.

AWS서비스를 사용한다면 ip 주소나 host이름을 사용하는 온프레미스와는 다르게 가능한 엔드포인트를 사용하여 RDS 및 Aurora Cluster를 사용하도록 권장한다


5.2 RDS 보안

암호화

  • KMS를 사용해 마스터와 복제본 암호화
  • 마스터 DB가 암호화 되지 않은 DB는 암호화된 읽기전용 복제본 생성 불가
  • IAM을 사용하여 DB접근 가능
  • DB에 ssl 강제 적용 시 모든 DB사용자에게 REQUIRE SSL SQL문 실행

5.3 RDS Proxy

  • Proxy를 사용하면 APP이 데이터 베이스로 설정된 연결을 풀링하고 공유 가능
  • DB 리소스 부하를 줄이고 커넥션을 최소화 하여 효율성 향상
  • DB에 대한 IAM 인증을 시행하고 자격 증명을 AWS Secrets Manager에 안전하게 저장
  • RDS Proxy는 공개적으로 액세스 할 수 없고, VPC에서 엑세스 해야 함

5.4 Elastic Cache

  • Elastic cache가 Redis또는 Memcached가져 오는 것

ex) DB캐시, 사용자 세션 저장

  • 읽기 전용 복제본 최대 5개

캐시 전략

  • Write Through : 데이터가 DB에 기록될 때 마다 데이터를 추가 or 업데이트, 쓰기가 길지만 읽기가 빠르고, 데이터가 항상 캐시에 업데이트
  • Lazy Loading : 필요할 때만 캐시에 데이터 로드

Redis용 Amazon MemoryDB

  • 초고속 성능, 다중 AZ 트랜잭션 로그를 사용한 내구성 있는 인메모리 데이터 스토리지

캐시 제거 및 TTL

3가지 전략 사용

  • 명시적 삭제
  • 캐시 메모리가 가득 차있거나 사용 하지 않을 때 (LRU)
  • 항목 당 사용 가능 시간 설정 (TTL)

6. Route 53

Route 53을 통해 DNS 등록 가능

  • 사용자가 DNS레코드를 업데이트 할 수 있음
  • A, AAAA, CNAME, NS(필수)
  • CAA, DS, MX, NAPTR 등 제공
  • A : 호스트 이름 (IPv4)
  • AAAA : 호스트 이름 (IPv6)
  • CNAME : 또 다른 도메인 주소로 매핑시키는 형태의 DNS 레코드 타입
  • NS : DNS 서버가 참조하는 다른 DNS 서버
  • TTL : 클라이언트가 레코드를 캐시에 저장하는 시간

CNAME vs ALIAS

CNAME : 호스트 이름이 다른 호스트 이름으로 라우팅 가능
ALIAS : 호스트 이름이 특정 AWS 리소스(로드 밸런서, cloud front) 로 라우팅 가능

  • 별칭 레코드는 루트 및 비루트 도메인에 모두 작동 (CNAME은 루트 도메인 이름이 아닌 경우에만 가능)

  • ALIAS사용 시 TTL설정 불가능 (Route 53이 자동 설정)

  • ELB, CloudFront, API Gateway, Elastic Beanstalk, S3, VPC, Route 53 Record(Same Hosted Zone)

  • EC2의 DNS 이름에 대해서는 별칭 레코드 불가능

호스팅 영역

퍼블릭 호스팅 영역 : 인터넷에서 트래픽을 라우팅 하는 방법 지정

프라이블 호스팅 영역 : 하나 이상의 VPC내에서 트래픽을 라우팅 하는 방법 지정

영역당 매월 0.5USD

6.1 Route 정책

  1. 단순

    • 일반적으로 트래픽을 단일 리소스로 보내는 방식
  2. 가중치

    • 레코드에 상대적 가중치 할당
      ex) 지역간 로드 밸런싱, 새로운 app버전 테스트
  3. 지연시간 (Latency)

    • 대기시간이 가장 짧은 곳으로 연결
  4. 장애 조치 (Failover)

    • 기본 EC2인스턴스와 보조 EC2인스턴스를 두고 기본 인스턴스가 장애 발생 시 보조 인스턴스로 전송
  5. Trffic flow (트래픽 플로우 및 지리적 근접성)

    • 사용자 위치 기반으로 라우팅
    • 기본 레코드 필수 (위치에 해당하는 항목이 없는 경우)
  6. IP

    • 사용자 IP기반으로 라우팅
  7. 다중 값

    • 트래픽을 여러 리소스로 라우팅 할 때 사용

Route 53을 DNS 서비스 공급자로 사용 시 퍼블릭 호스팅 영역 생성 및 타사 레지스트리 NS레코드 업데이트


Tip!!

요금 관련 설정

  • builing - bills 페이지에서 확인 가능
  • 프리티어 사용 시 builing - freetier 페이지에서 사용량 확인 가능
  • Cost Management - Budgets 에서 설정한 사용량 초과 시 메일 알림 기능
  • 비용 예상 기능을 사용 가능 ( 예산 예측 사용하려면 5주 걸림)

Reference

AWS JSON 정책 문서 구조

Thank You for Visiting My Blog, I hope you have an amazing day 😆
© 2023 Ian, Powered By Gatsby.