Storage

Amazon S3

개요

• Amazon S3는 AWS의 핵심 요소
• 무한 확장 가능한 스토리지로 홍보됨
• 많은 웹사이트가 SE를 백본 스토리지로 사용
• 많은 AWS 서비스가 S3와 통합 연계됨

사용 사례

• 백업 및 스토리지
• 재난 복구
• 아카이브
• 하이브리드 클라우드 스토리지
• 애플리케이션 호스팅
• 미디어 호스팅
• 데이터 레이크 & 빅 데이터 분석
• 소프트웨어 배포
• 정적 웹사이트

Buckets

• S3는 객체(파일)을 “버킷”(디렉토리)에 저장할 수 있게 함
• 버킷 이름은 전 세계적으로(모든 리전, 모든 계정 포함) 유일해야 함
• 버킷은 리전 단위로 정의됨
• S3는 전역 서비스처럼 보이지만, 특정 리전에서 생성됨
• 네이밍 규칙
  • 대문자, 밑줄(_) 사용 불가
  • 3~63자
  • IP 형식 불가
  • 소문자 알파벳 또는 숫자로 시작해야 함
  • 접두사 xn-- 불가
  • 접미사 -s3alias 불가

Object

• 객체(파일)는 키를 가짐
• 키는 전체 경로 의미
  • s3://my-bucket/my_file.txt
  • s3://my-bucket/my_folder1/another_folder/my_file.txt
• 키는 접두사 + 객체 이름으로 구성
• 버킷 안에는 실제 디렉토리 개념 없음(UI에서만 디렉토리처럼 보이게 함)
• 사실상 슬래시(/)를 포함한 긴 문자열 키일 뿐임
• 객체의 값은 body의 내용
  • 객체 최대 크기는 5TB
  • 5GB초과 업로드 시 반드시 멀티파트 업로드를 사용해야 함
• 메타데이터 : 텍스트 키/값 쌍으로 구성되며, 시스템/사용자 메타데이터 모두 가능
• 태그 : 유니코드 키/값 쌍, 최대 10개까지 가능하며 보안, 라이프사이클 관리에 유용
• 버전 ID : 버저닝이 활성화된 경우 부여됨

보안

• 사용자 기반
  • IAM 정책 : 특정 IAM 사용자에 대해 어떤 API 호출을 허용할지 정의
• 리소스 기반
  • 버킷 정책 : S3 콘솔에서 설정하는 버킷 단위 규칙, 크로스 계정 접근 허용 가능
  • 객체 ACL(Access control List) : 세밀한 권한 제어(비활성화 가능)
  • 버킷 ACL(Access control List) : 잘 사용되지 않음(비활성화 가능)
• 주의 : IAM 정책은 아래 조건에서 S3 객체에 접근 가능
  • 사용자 IAM 권한이 허용되거나 리소스 정책이 허용하는 경우
  • 명시적 DENY가 없는 경우
• 암호화 : S3에 저장되는 객체는 암호화 키를 이용해 암호화 가능

S3 버킷 정책

• JSON 기반 정책
  • Resource(자원) : 버킷과 객체
  • Effect(효과) : Allow/Deny
  • Action(행동) : 허용 또는 거부할 API 집합
  • Principal(주체) : 정책을 적용할 계정 또는 사용자

• 버킷 정책 활용 예시
  • 버킷에 대한 퍼블릭 접근 허용
  • 업로드 시 객체 암호화를 강제
  • 다른 AWS 계정에 접근 권한 부여(Cross-Account)

퍼블릭 접근 차단 버킷 설정

• 이 설정은 기업 데이터 유출을 방지하기 위해 만들어짐
• 버킷이 퍼블릭하게 노출될 필요가 없다면, 해당 옵션을 켜둔 상태로 유지해야 함
• 계정 단위에서도 설정 가능

버저닝

• S3에서 파일에 버전을 적용할 수 있음
• 버저닝은 버킷 단위에서 가능
• 동일한 키를 덮어쓰면 새로운 버전이 생성됨
• 버킷에 버저닝을 적용하는 것이 모범 사례임
  • 의도치 않은 삭제에 대비해 복원 가능
  • 이전 버전으로 손쉽게 롤백 가능
• 주의 사항
  • 버저닝 활성화 전에 존재하던 파일은 버전 값이 null 임
  • 버저닝을 일시 중지해도 기존 버전은 삭제되지 않음

복제(CRR & SRR)

• 소스 버킷과 대상 버킷 모두 버저닝을 활성화해야 함
• CRR(Cross-Region Replication) : 리전 간 복제
• SRR(Same-Region Replication) : 동일 리전 간 복제
• 버킷은 서로 다른 AWS 계정에 속할 수도 있음
• 복제는 비동기 방식으로 수행
• S3에 적절한 IAM 권한을 부여해야 함

사용 사례

• CRR : 규제 준수, 지연 시간 단축, 계정 간 복제
• SRR : 로그 집계, 운영과 테스트 계정 간 실시간 복제

주의사항

• 복제를 활성화한 이후에 생성된 객체만 복제됨
• 기존 객체도 복제하려면 S3 Batch Replication 기능을 사용
  • 기존 객체 및 복제에 실패한 객체까지 복제 가능
• 삭제 작업 관련
  • 소스에서 생성된 삭제 마커를 타겟으로 복제할 수 있음(옵션 설정)
  • 특정 버전 ID를 가진 삭제는 복제되지 않음 → 악의적 삭제 방지를 위함
• 체이닝 복제 불가
  • 버킷 1 → 버킷2 → 버킷3 로 복제를 설정해도 버킷1에서 생성된 객체가 버킷3까지 자동 복제되지는 않음

S3 Storage Class

• Amazon S3 Standard – 범용
• Amazon S3 Standard-Infrequent Access (IA)
• Amazon S3 One Zone-Infrequent Access
• Amazon S3 Glacier Instant Retrieval
• Amazon S3 Glacier Flexible Retrieval
• Amazon S3 Glacier Deep Archive
• Amazon S3 Intelligent-Tiering

→ 스토리지 클래스 간 전환은 수동으로 하거나, S3 라이프사이클 설정을 통해 자동화 가능

S3 내구성 및 가용성

• 내구성
  • 여러 AZ(가용 영역)에 걸쳐 99.999999999%(11 9’s) 의 매우 높은 내구성 제공
  • 예: Amazon S3에 천만 개 객체를 저장한다면, 평균적으로 1만 년에 1개의 객체만 손실될 수 있음
  • 모든 스토리지 클래스에서 동일하게 제공됨
• 가용성
  • 서비스가 얼마나 즉시 사용 가능한지를 측정
  • 스토리지 클래스에 따라 다르게 제공됨
  • 예: S3 Standard는 99.99% 가용성을 제공하며, 이는 연간 약 53분 정도 접근 불가할 수 있음을 의미

S3 Standard - General Purpose

• 가용성 : 99.99%
• 특징 : 자주 접근되는 데이터에 사용
• 낮은 지연 시간과 높은 처리량 제공
• 내구성 : 동시에 2개의 시설 장애를 견딜 수 있음
• 활용 사례 : 빅데이터 분석, 모바일 & 게임 애플리케이션, 콘텐츠 배포 등

S3 Storage Classes - Infrequent Access(잘 사용되지 않는 데이터용)

• 특징 : 자주 접근하지 않지만 필요할 때는 빠른 접근이 필요한 데이터에 적합
• 비용 : S3 Standard보다 저렴
• Amazon S3 Standard-Infrequent Access(S3 Standard-IA)
  • 가용성 : 99.9%
  • 활용 사례 : 재해 복구, 백업 데이터 저장
• Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)
  • 단일 AZ 내에서 높은 내구성(99.999999999%) 제공, 단 AZ가 파괴되면 데이터 손실
  • 가용성 : 99.5%
  • 활용 사례 : 온프레미스 데이터의 보조 백업 저장, 다시 생성 가능한 데이터 저장

Amazon S3 Glacier Storage Classes

• 저비용 객체 스토리지, 주로 아카이브/백업 용도로 사용
• 가격 구조 : 저장 비용 + 객체 검색 비용
• Amazon S3 Glacier Instant Retrieval
  • 밀리초 단위 검색 지원, 분기마다 한 번 정도 접근하는 데이터에 적합
  • 최소 저장 기간 : 90일
• Amazon S3 Glacier Flexible Retrieval(구 Amazon S3 Glacier)
  • 검색 옵션 : Expedited(1~5분), Standard(3~5시간), Bulk(5~12시간, 무료)
  • 최소 저장 기간 : 90일
• Amazon S3 Glacier Deep Archive - 장기 보관용
  • 검색 옵션 : Standard(12시간), Bulk(48시간)
  • 최소 저장 기간 : 180일

S3 Intelligent - Tiering

• 소규모 월간 모니터링 및 자동 티어링 비용 발생
• 사용 패턴에 따라 객체를 Access Tier 간 자동으로 이동시킴
• S3 Intelligent-Tiering에서는 복구 비용 없음
• 자동 티어 구성
  • Frequent Access Tier : 기본 티어, 자주 접근되는 데이터 저장
  • Infrequent Access Tier: 30일 동안 접근되지 않은 객체 저장
  • Archive Instant Access Tier : 90일 동안 접근되지 않은 객체 저장
• 옵션 티어 구성
  • Archive Access Tier: 90 ~700일 이상 범위에서 설정 가능
  • Deep Archive Access Tier : 최소 180일 이상 범위에서 설정 가능

S3 Storage Classes 비교

S3 Storage Classes 가격 비교

S3 Express One Zone

• 고성능 단일 AZ(가용 영역) 스토리지 클래스
• 객체는 Directory Bucket(단일 AZ 내 버킷)에 저장
• 초당 수십만 건의 요청 처리 가능, 한 자릿수 밀리초 단위 지연 제공
• S3 Standard 대비 최대 10배 성능 향상, 비용은 50% 절감 가능
• 높은 내구성(99.999999999%)과 가용성(99.95%) 보장
• 스토리지와 컴퓨팅 리소스를 같은 AZ에 배치하여 지연을 줄일 수 있음
• 활용사례
  • 지연 시간에 민감한 애플리케이션
  • 데이터 집약적 애플리케이션
  • AI & ML 학습, 금융 모델링, 미디어 처리, HPC(고성능 컴퓨팅) 등
• 적합한 서비스 통합
  • SageMaker Model Training, Athena, EMR, Glue 등

스토리지 클래스 간 이동

• 객체를 서로 다른 스토리지 클래스 간에 이동할 수 있음
• 자주 접근하지 않는 객체는 Standard-IA로 이동하는 것이 적합
• 빠른 접근이 필요 없는 아카이브 데이터는 Glacier 또는 Glacier Deep Archive 로 이동
• 객체 이동은 Lifecycle 규칙을 통해 자동화할 수 있음

Lifecycle Rules

• 전환 작업 : 객체를 다른 스토리지 클래스로 이동하도록 설정
  • 객체 생성 후 60일 뒤 Standard-IA 클래스로 이동
  • 6개월 뒤 Glacier로 아카이브 전환
• 만료 작업 : 일정 기간 후 객체를 만료(삭제)하도록 설정
  • 접근 로그 파일을 365일 뒤 자동 삭제
  • 버저닝이 활성화된 경우, 오래된 파일 버전을 삭제 가능
  • 미완료 멀티파트 업로드를 삭제 가능
• 규칙은 특정 Prefix에 대해 생성 가능(s3://mybucket/mp3/*)
• 규칙은 특정 객체 태그에 대해서도 생성 가능(Department: Finance)

시나리오1

• EC2에서 동작하는 애플리케이션이, 사용자가 Amazon S3에 프로필 사진을 업로드하면 썸네일 이미지를 생성
• 이 썸네일은 쉽게 재생성 가능하며 60일 동안만 보관하면 됨
• 원본 이미지는 60일 동안 즉시 복구 가능해야 하며, 그 이후에는 사용자가 최대 6시간까지 기다려도 무방함
• 설계방법
  • S3 원본 이미지는 Standard 스토리지 클래스에 저장 후, 라이프사이클 설정을 통해 60일 이후 Glacier로 전환
  • S3 썸네일은 One-Zone IA 클래스에 저장 후, 라이프사이클 설정을 통해 60일 뒤 만료(삭제 ) 처리

시나리오2

• 회사 규칙에 따르면, 삭제된 S3 객체는 30일 동안 즉시 복구 가능해야 하며, 이런 상황은 드물게 발생
• 30일 이후부터 최대 365일까지는 삭제된 객체를 48시간 이내에 복구 가능해야 함
• 설계 방법
  • S3 버저닝을 활성화하여 객체 버전을 유지 → 삭제된 객체는 실제 삭제가 아닌 삭제 마커로 가려져 복구 가능
  • 객체의 비현재 버전을 Standard-IA 클래스로 전환
  • 이후 비현재 버전을 Glacier Deep Archive로 전환

Amazon S3 분석 - 스토리지 클래스 분석

• 객체를 언제 적절한 스토리지 클래스로 전환할지 결정하는 데 도움을 줌
• Standard 및 Standard-IA에 대한 추천 제공
  • One-Zone IA나 Glacier에는 적용되지 않음
• 리포트는 매일 업데이트 됨
• 데이터 분석이 나타나기 시작하는 데 24 ~ 48시간 소요됨
• 라이프사이클 규칙을 수립(또는 개선)하기 위한 좋은 첫 단계임

S3 이벤트 알림

• 지원 이벤트 : S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication 등
• 객체 이름 필터링 가능(예: *.jpg)
• 활용 사례 : S3에 업로드된 이미지에 대해 자동으로 썸네일 생성
• 원하는 만큼 S3 이벤트 생성 가능
• S3 이벤트 알림은 일반적으로 몇 초 내에 전달되지만, 경우에 따라 1분 이상 지연될 수 있음

IAM Permissions

Amazon EventBridge와 함께 사용하는 S3 이벤트 알림

• JSON 규칙을 활용한 고급 필터링 옵션 제공(메타데이터, 객체 크기, 이름 등)
• 다중 목적지 : 예) Step Functions, Kinesis Streams / Firehose 등
• EventBridge 기능 : 이벤트 아카이브, 이벤트 재생, 신뢰성 있는 전달 지원

S3 성능

기본 성능

• Amazon S3는 자동으로 확장되어 높은 요청 처리율을 지원하며, 지연은 100~200ms 수준임
• 애플리케이션은 버킷 내 prefix 당 초당 최소 3500건의 PUT/COPY/POST/DELETE 요청 또는 5500건의 GET/HEAD 요청을 처리 가능
• 버킷 안의 prefix 개수에는 제한 없음
• 예시(객체 경로 ⇒ prefix)
  • bucket/folder1/sub1/file → /forder/sub1/
  • bucket/forder1/sub2/file → /folder1/sub2/
  • bucket/1/file → /1/
  • bucket/2/file → /2/
• 읽기 요청을 위 네 개 prefix에 균등하게 분산한다면, GET 및 HEAD 요청을 초당 22000건 까지 처리 가능

Multi-part Upload

• 100MB 이상의 파일은 권장, 5GB 이상 파일은 반드시 사용해야 함
• 업로드를 병렬화하여 전송 속도를 높일 수 있음

S3 Transfer Acceleration

• 파일을 AWS 엣지 로케이션으로 전송한 뒤, 해당 데이터가 대상 리전의 S3 버킷으로 전달되도록 하여 전송 속도를 높임
• 멀티파트 업로드와 호환됨

S3 Byte-Range Fetches

• 특정 바이트 범위를 지정하여 GET 요청을 보내면 병렬화 가능
• 장애 발생 시에도 더 나은 복원력을 제공
• 다운로드 속도를 높이는 데 활용 가능

• 파일의 일부분(예: 파일 헤더)만 가져올 때도 사용 가능

객체 암호화

• S3 버킷에 저장된 객체는 4가지 방식 중 하나로 암호화할 수 있음
• 서버 측 암호화(SSE)
  • SSE-S3(Amazon S3 관리 키) - 기본 활성화
    • AWS가 암호화 키를 소유, 관리하며 S3 객체를 암호화
  • SSE-KMS(AWS KMS 키)
    • AWS Key Management Service(KMS)를 사용해 암호화 키 관리
    • 보다 세밀한 키 관리 및 감사 로깅 가능
  • SSE-C(고객 제공 키)
    • 고객이 직접 암호화 키 관리
    • 키를 요청 시 직접 제공해야 함
• 클라이언트 측 암호화
  • 데이터를 S3에 업로드하기 전에 클라이언트에서 직접 암호화 수행

⇒ 시험에서 각 암호화 방식이 어떤 상황에 쓰이는지 구분할 수 있어야 함

SSE-S3

• AWS가 키를 소유, 관리, 운영하는 방식으로 암호화 수행
• 객체는 서버측에서 암호화됨
• 암호화 방식은 AES-256
• 요청 시 HTTP 헤더를 “x-amz-server-side-encryption”: ”AES256” 설정해야 함
• 새로운 버킷과 새로운 객체에 대해서는 기본적으로 활성화됨

SSE-KMS

• AWS KMS(Key Management Service)가 키를 관리, 운영하는 방식으로 암호화 수행
• KMS 장점 : 사용자가 키 사용을 제어할 수 있고, CloudTrail을 통해 키 사용 내역을 감사 가능
• 객체는 서버 측에서 암호화됨
• 요청 시 HTTP 헤더를 “x-amz-server-side-encryption”: ”aws:kms” 설정해야 함

SSE-KMS 제약사항

• SSE-KMS를 사용할 경우 KMS 서비스 한도의 영향을 받을 수 있음
• 업로드 시 : GenerateDataKey KMS API 호출 발생
• 다운로드 시 : Decrypt KMS API 호출 발생
• 이 호출들은 리전 별 KMS 초당 요청 한도(예: 5500 / 10000 / 30000 req/s)에 포함됨
• 필요 시 Service Quotas 콘솔을 통해 한도 증가 요청 가능

SSE-C

• 고객이 AWS 외부에서 직접 관리하는 키를 사용하는 서버 측 암호화 방식
• Amazon S3는 사용자가 제공한 암호화 키를 저장하지 않음
• 반드시 HTTPS를 사용해야 함
• 모든 HTTP 요청마다 암호화 키를 HTTP 헤더에 포함시켜 제공해야 함

Client-Side Encryption

• Amazon S3 Client-Side Encryption Library 같은 클라이언트 라이브러리를 사용
• 클라이언트가 데이터를 S3에 업로드하기 전에 직접 암호화해야 함
• 클라이언트가 데이터를 S3에서 가져올 때 직접 복호화해야 함
• 고객이 키와 암호화 주기 전체를 직접 관리해야 함

전송 중 암호화(SSL/TLS)

• 전송 중 암호화는 SSL/TLS라고도 불림
• Amazon S3는 두 가지 엔드포인트를 제공
  • HTTP 엔드포인트 : 암호화되지 않음
  • HTTPS 엔드포인트 : 전송 중 암호화 적용
• HTTPS 사용 권장
• SSE-C를 사용할 때는 HTTPS가 필수
• 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트 사용

전송 중 암호화 강제

• “aws:SecureTransport”:”false”인 경우 s3:GetObject를 Deny 하도록 설정
• http 요청인 경우 false, https 요청인 경우 true
  • http 요청이 들어올 경우 GetObject 오퍼레이션이 거부됨

DSSE-KMS(Dual-Layer Server-Side Encryption based on KMS)

• KMS 기반 이중 계층 서버 측 암호화
• 2023년 6월에 출시
• 시험 범위에 포함 X

기본 암호화 vs 버킷 정책

• SSE-S3 기본 암호화 : S3 버킷에 저장되는 새로운 객체에는 자동으로 SSE-S3 암호화가 적용됨
• 버킷 정책으로 강제 암호화 : 버킷 정책을 사용해 암호화를 강제할 수 있으며, 암호화 헤더(SSE-KMS 또는 SSE-C)없이 PUT 요청하는 API 호출은 거부하도록 설정 가능
• 주의 : 버킷 정책은 기본 암호화보다 먼저 평가됨

Access Points

• 액세스 포인트는 S3 버킷의 보안 관리를 단순화해 줌
• 각 액세스 포인트는 다음을 가짐
  • 자체 DNS 이름(인터넷 Origin 또는 VPC Origin)
  • 액세스 포인트 정책(버킷 정책과 유사) → 규모에 맞는 보안 관리 가능

VPC Origin

• 액세스 포인트를 특정 VPC 내부에서만 접근 가능하도록 정의할 수 있음
• 액세스 포인트에 접근하려면 반드시 VPC 엔드포인트를 생성해야 함(Gateway 또는 Interface 엔드포인트)
• VPC 엔드포인트 정책은 대상 버킷과 액세스 포인트에 대한 접근을 허용해야 함

S3 Object Lambda

• AWS Lambda 함수를 이용해 호출 애플리케이션이 객체를 가져오기 전에 객체를 변환할 수 있음
• 단일 S3 버킷만 필요하며, 그 위에 S3 액세스 포인트와 S3 Object Lambda 액세스 포인트를 생성하여 사용
• 활용 사례
  • 분석 또는 비프로덕션 환경에서 개인 식별 정보(PII)를 마스킹 처리
  • 데이터 형식 변환(예: XML → JSON 변환)
  • 요청자 세부 정보에 따라 이미지를 실시간 리사이징 또는 워터마킹 처리

Storage Lens

• AWS 전체 조직 단위에서 스토리지를 이해, 분석, 최적화할 수 있음
• 비정상 탐지, 비용 효율성 확인, 데이터 보호 모범 사례 적용 가능(30일 사용량 및 활동 메트릭 제공)
• 조직 전체, 특정 계정, 리전, 버킷, prefix 단위로 데이터 집계 가능
• 기본 대시보드 제공 또는 사용자 정의 대시보드 생성 가능
• 메트릭을 매일 S3 버킷으로 내보내도록 설정 가능(CSV, Parquet 형식)

기본 대시보드

• 무료 및 고급 메트릭 모두에 대해 요약된 인사이트와 트렌드를 시각화 가능
• 기본 대시보드는 멀티 리전, 멀티 계정 데이터를 보여줌
• Amazon S3에서 미리 구성해 제공
• 기본 대시보드는 삭제는 불가능하지만, 비활성화는 가능

메트릭

• 요약 메트릭
  • S3 스토리지에 대한 일반적인 인사이트 제공
  • 예: SotrageBytes, ObjectCount 등
  • 활용 사례 : 가장 빠르게 증가하는(또는 사용되지 않는) 버킷 및 prefix 식별
• 비용 최적화 메트릭
  • 스토리지 비용을 관리, 최적화할 수 있는 인사이트 제공
  • 예 : NonCurrentVersionStorageBytes, IncomplteMultipartUploadStorageBytes 등
  • 활용 사례 : 7일 이상 된 미완료 멀티파트 업로드가 있는 버킷 식별, 더 저렴한 스토리지 클래스로 전환 가능한 객체 식별
• 데이터 보호 메트릭
  • 데이터 보호 기능 관련 인사이트 제공
  • 예 : VersioningEnabledBucketCount, MFADeleteEnabledBucketCount, SSEKMSEnabledBucketCount, CrossRegionReplicationRuleCount 등
  • 활용 사례 : 데이터 보호 모범 사례를 따르지 않는 버킷 식별
• 액세스 관리 메트릭
  • S3 객체 소유권 관련 인사이트 제공
  • 예 : ObjectOwnershipBucketOwnerEnforceBucketCount 등
  • 활용 사례 : 버킷이 어떤 객체 소유권 설정을 사용하는지 식별
• 이벤트 메트릭
  • S3 이벤트 알림 관련 인사이트 제공
  • 예 : EventNotificationEnabledBucketCOunt → S3 이벤트 알림이 설정된 버킷 식별
• 성능 메트릭
  • S3 전송 가속 관련 인사이트 제공
  • 예 : TransferAccelerationEnabledBucketCount → 전송 가속이 활성화된 버킷 식별
• 활동 메트릭
  • 스토리지 어떻게 요청되는지에 대한 인사이트 제공
  • 예 : AllRequests, GetRequest, PutRequests, ListRequests, BytesDownloaded 등
• 상세 상태 코드 메트릭
  • HTTP 상태 코드 관련 인사이트 제공
  • 예 : 200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount 등

무료 vs 유료

• 무료 메트릭
  • 모든 고객에게 자동으로 제공
  • 약 28개의 사용량 메트릭 포함
  • 데이터는 14일 동안 조회 가능
• 고급 메트릭 & 추천
  • 유료 추가 메트릭 및 기능 제공
  • 고급 메트릭 : 활동, 고급 비용 최적화, 고급 데이터 보호, 상태 코드
  • CloudWatch 발행 : 추가 비용 없이 CloudWatch에서 메트릭 조회 가능
  • Prefix 집계 : prefix 단위로 메트릭 수집 가능
  • 데이터는 15개월 동안 조회 가능

EC2 인스턴스 스토리지

EBS 볼륨이란

• EBS(Elastic Block Store) 볼륨은 실행 중인 EC2 인스턴스에 연결할 수 있는 네트워크 드라이브
• 인스턴스 종료 후에도 데이터를 영구적으로 보존할 수 있게 함
• 한 번의 하나의 인스턴스에만 마운트 가능(CPP 레벨 기준)
• 특정 가용 영역(AZ)에 종속됨
• 비유 : 네트워크 USB 메모리라고 생각하면 됨

특징

• 네트워크 드라이브(물리 디스크가 아님)
  • 인스턴스와 네트워크를 통해 통신하므로 약간의 지연 발생 가능
  • Ec2 인스턴스에서 분리 후 다른 인스턴스에 빠르게 연결 가능
• 특정 가용 영역(AZ)에 종속됨
  • 예 : us-east-1a에 있는 EBS 볼륨은 us-east-1b 인스턴스에 직접 연결 불가
  • 다른 AZ로 옮기려면 먼저 스냅샷을 생성해야 함
• 프로비저닝된 용량을 가짐(GB 단위, IOPS 단위)
  • 프로비저닝한 용량 전체에 대해 요금이 청구됨
  • 시간이 지남에 따라 드라이브 용량을 늘릴 수 있음

종료 시 삭제 속성(Delete onTermination)

• EC2 인스턴스가 종료될 때 EBS 볼륨을 어떻게 처리할지 제어하는 속성
• 기본값:
  • 루트 EBS 볼륨은 삭제됨(속성 활성화)
  • 추가로 연결된 다른 EBS 볼륨은 삭제되지 않음(속성 비활성화)

• 이 속성은 AWS 콘솔 또는 AWS CLI로 제어할 수 있음
• 활용 사례 : 인스턴스가 종료되더라도 루트 볼륨을 보존하고 싶을 때 설정 변경

Amazon EBS 탄력적 볼륨

• 볼륨을 분리하거나 인스턴스를 재시작하지 않고도 변경 가능
  • 콘솔에서 actions/modify volume 메뉴를 통해 설정 가능
• 볼륨 크기 확장
  • 용량 증가만 가능, 축소는 불가
• 볼륨 유형 변경(예: gp2 → gp3)
  • 원하는 IOPS 또는 처리량 지정 가능(지정하지 않으면 AWS가 자동으로 추정)
• 성능 조정 가능
  • 성능을 높이거나 낮출 수 있음

Amazon EFS - 탄력적 파일 시스템

• 관리형 NFS(Network File System)로, 여러 EC2 인스턴스에 동시에 마운트 가능
• EFS는 멀티 AZ 환경의 EC2 인스턴스와 함께 동작
• 고가용성 및 확장성을 제공하지만, 비용이 비쌈(gp2 대비 약 3배)
• 사용량 기반 과금 방식

• 활용 사례 : 콘텐츠 관리, 웹 서비스, 데이터 공유, WordPress 등
• 프로토콜 : NFSv4.1 사용
• 보안 : 보안 그룹으로 EFS 접근 제어
• 호환성 : Linux 기반 AMI와 호환, Windows는 지원하지 않음
• 암호화 : KMS를 사용한 저장 시 암호화 지원
• 파일 시스템 특성 : POSIX 규격을 따르는 파일 시스템(일반 Linux 파일 API와 유사)
• 확장성 : 자동으로 확장되며, 사용량 기반 과금 → 용량 계획 불필요

성능 & 스토리지 클래스

• EFS Scale
  • 수천 개의 동시 NFS 클라이언트 지원
  • 초당 10GB+ 처리량 제공
  • 자동으로 페타바이트(PB) 규모까지 확장 가능한 네트워크 파일 시스템
• Performance Mode(EFS 생성 시 설정)
  • General Purpose(기본 값) : 지연에 민감한 경우(예: 웹 서버, CMS 등)
  • MAX/IO : 더 높은 지연, 높은 처리량 및 병렬성(빅데이터, 미디어 처리 등)
• Throughput Mode
  • Bursting : 1TB = 50MiB/s, 최대 100MiB/s까지 버스트 지원
  • Provisioned : 스토리지 크기와 상관없이 처리량을 직접 설정(예 : 1TB에 대해 1GiB/s 지정)
  • Elastic : 워크로드에 따라 처리량이 자동 확장/축소됨
    • 읽기 최대 3GiB/s, 쓰기 최대 1GiB/s 지원
    • 예측 불가능한 워크로드에 적합

스토리지 클래스

• Storage Tiers(라이프 사이클 관리 기능 - N일 이후 파일 이동 가능)
  • Standard : 자주 접근되는 파일용
  • Infrequent Access(EFS-IA) : 파일 복구 시 비용 발생, 저장 비용은 저렴
  • Archive : 1년에 몇 번만 접근하는 데이터용, 저장 비용은 50% 더 저렴
  • 라이프사이클 정책을 적용하여 파일을 스토리지 티어 간에 자동으로 이동 가능

• 가용성 및 내구성
  • Standard : 멀티 AZ, 프로덕션 환경에 적합
  • One Zone : 단일 AZ, 개발 환경에 적합, 기본적으로 백업 지원, IA와 호환(EFS One Zone-IA)
• 최대 90% 비용 절감 효과 가능

EBS vs EFS

Elastic Block Storage

• EBS 볼륨 특징
  • 한 번에 하나의 인스턴스에만 연결 가능(단, Multi-Attach io1/io2 예외)
  • 가용 영역(AZ) 단위로 종속됨 → 다른 AZ로 직접 이동 불가
  • gp2: 디스크 크기가 커질수록 IO 성능 증가
  • gp3 & io1 : 디스크 크기와 무관하게 I/O 성능을 독립적으로 증가시킬 수 있음
• EBS 볼륨을 AZ 간 마이그레이션
  • 스냅샷 생성 후 다른 AZ 에서 해당 스냅샷을 복원
  • EBS 백업은 IO를 소모함 → 애플리케이션이 많은 트래픽을 처리 중일 때는 백업 실행 권장하지 않음
• EC2 인스턴스가 종료되면 해당 인스턴스의 루트 EBS 볼륨도 기본적으로 함께 종료됨(비활성화할 수 있음)

Elastic File System

• 수백 개 인스턴스를 AZ 전체에 걸쳐 마운트할 수 있음
• EFS는 웹 사이트 파일 공유(예: WordPress)에 활용 가능
• Linux 인스턴스에서만 사용 가능(POSIX 호환)
• EFS는 EBS보다 가격이 더 비쌈
• 스토리지 티어를 활용해 비용 절감 가능
• 반드시 기억할 것 : EFS vs EBS vs Instance Store 차이

AWS Backup

• 완전 관리형 서비스
• AWS 서비스 전반의 백업을 중앙에서 관리하고 자동화할 수 있음
• 사용자 정의 스크립트나 수동 프로세스를 만들 필요 없음
• 지원 서비스
  • Amazon EC2 / Amazon EBS
  • Amazon S3
  • Amazon RDS(모든 DB 엔진) / Amazon Aurora / Amazon DynamoDB
  • Amazon DocumentDB / Amazon Neptune
  • Amazon EFS / Amazon FSx(Lustre & Windows File Server)
  • AWS Storage Gateway(Volume Gateway)
• 크로스 리전 백업 지원
• 크로스 계정 백업 지원
• 지원 서비스에 대해 PITR(Point-In-Time Recovery, 시점 복구) 지원
• 온디맨드 백업 및 예약 백업 가능
• 태그 기반 백업 정책 지원
• Backup Plans라는 백업 정책 생성 가능
  • 백업 주기 : 12시간마다, 매일, 매주, 매월, cron 표현식
  • 백업 윈도우
  • 콜드 스토리지로 전환 : 안함, 일 단위, 주 단위, 월 단위, 연 단위
  • 보존 기간 : 항상, 일 단위, 주 단위, 월 단위, 연 단위

AWS Backup Valt Lock

• AWS Backup Vault에 저장된 모든 백업에 대해 WORM(Write Once Read Many, 한 번 쓰고 여러 번 읽기) 상태를 강제
• 백업을 보호하기 위한 추가 보안 계층 제공
  • 실수 또는 악의적인 삭제 작업
  • 보존 기간을 단축하거나 변경하려는 업데이트
• 활성화되면 루트 사용자조차도 백업을 삭제할 수 없음