Storage, CloudFront 실습 회고

7 분 소요

Storage & Amazon CloudFront

Storage

클라우드 스토리지는 클라우드 컴퓨팅 제공업체를 통해 데이터와 파일을 인터넷에 저장할 수 있는 모델
퍼블릭 인터넷 또는 전용 프라이빗 네트워크 연결을 통해 스토리지에 액세스 가능
비용 효율성, 민첩성 향상, 더 빠른 배포, 효율적인 데이터 관리, 확장성이 장점

클라우드 스토리지의 종류

Block Storage

물리적 하드웨어(HDD, SSD)와 비슷한 역할
데이터를 Block 형태로 Read/Write
빠른 Read/Write을 위해 Block에 고유한 식별자(ID#) 부여해 사용
백업 기능 제공하기도 함 → SAN 역할
AWS 서비스: Amazon EBS

File Storage

데이터를 파일 단위의 계층 구조로 저장하는 데이터 스토리지
애플리케이션에 가장 널리 사용되는 유형
직접 데이터 관리(서버 기능도 수행) → NFS, NAS 기술 사용 가능
로컬 하드 드라이브와 유사한 접근 방식
AWS 서비스: Amazon EFS
사용 사례: 여러 서버나 사용자가 동일한 파일 시스템에 동시 접근하는 경우, 파일과 디렉토리를 통해 데이터를 관리하고 싶은 경우, 네트워크를 통한 파일 공유가 필요한 경우

Object Storage

대용량 미디어 파일, 이미지, 백업 등의 비정형 데이터를 저장하기 위한 스토리지
전송된 형식 그대로를 객체 데이터로 저장
사용자가 직접 메타데이터 지정 가능
객체는 보안 버킷이라는 저장 공간에 저장
HTTP 프로토콜 기반 REST API 호출을 통해 접근
AWS 서비스: Amazon S3
사용 사례: 정적 웹 컨텐츠(이미지, 비디오, HTML)를 호스팅하는 경우, 전 세계 여러 데이터센터에 데이터를 분산시키는 경우, 저렴한 비용으로 데이터를 오래 보관하는 경우

Amazon S3

데이터를 버킷 내 객체로 저장하는 객체 스토리지 서비스
파일을 하나의 객체로 저장 → Key를 통해 관리
확장성: 저장 용량 신경 안 써도 됨
데이터 보호: 버전 관리, 암호화, 복제 기능
비용 효율성: 사용한 만큼만 비용 지불
비즈니스 요구에 맞게 데이터에 대한 접근 제어 가능 (e.g. ACL, IAM 정책)

구성

S3는 버킷과 객체로 구성된다.

버킷

S3에 저장된 객체에 대한 컨테이너 (= 폴더?)
버킷에는 객체를 무제한으로 저장 가능
한 계정당 최대 100개의 버킷 생성 가능
AWS 전역에서 단 하나만 존재, 리전과 관계 없이 전역적으로 유일한 이름 사용

객체

S3에 저장되는 기본 개체 (= 파일?)
하나 이상의 버킷에 저장, 각 객체의 크기는 최대 5TB
객체 데이터와 메타데이터로 구성
Key와 버전 ID로 버킷 내에서 고유하게 식별됨
구성요소: Key, Value, Version ID, Metadata, 태그, 액세스 제어 정보

객체 URL 형식은 다음과 같다: https://{bucket-name}.s3.{region}.amazonaws.com/{key-name}

보안

데이터 암호화

서버 측 암호화 (SSE)

서버가 데이터를 자동으로 보호해주는 기능
업로드 시 AWS가 데이터를 대신 암호화해서 저장, 다운로드 시 자동으로 복호화해서 반환
종류: SSE-S3, SSE-KMS / DSSE-KMS / SSE-C
현재는 SSE-S3를 모든 버킷 암호화의 기본 수준으로 적용

클라이언트 측 암호화

전송 및 저장 시 보안을 보장하기 위해 로컬에서 데이터 암호화
AWS를 포함한 제3자에게 객체 노출 방지 가능
S3 암호화 클라이언트를 사용하여 객체 암호화 후 버킷에 업로드
높은 보안을 보장하지만 관리 및 구현 복잡성 증가

액세스 제어

IAM

자신의 계정 내의 IAM 사용자를 단위로 액세스 제어
적용 범위: 자신의 AWS 계정 내의 IAM User, IAM Group, IAM Role
사용자/역할 기준 → 누가 무엇을 할 수 있나?

ACL (액세스 제어 목록)

AWS 계정 단위로 액세스 권한을 설정
다른 AWS 계정에 대해 객체 또는 버킷에 대한 읽기/쓰기를 허용
계정 기준 → 어떤 계정이 접근할 수 있나?

버킷 정책

Bucket 단위로 액세스 권한 설정
자신의 AWS 계정의 IAM 사용자 / 또 다른 AWS 계정의 IAM 사용자에 대해 S3 리소스 액세스 권한 설정
버킷/객체 기준 → 이 버킷에 누가 접근할 수 있나?

CORS (Cross-Origin Resource Sharing)

교차 출처 리소스 공유
“CORS를 설정한다” = “출처가 다른 서버 간의 리소스 공유를 허용한다”
Access-Control-Allow-Origin 헤더 사용

Pre-signed URLs

S3 접근 권한이 없는 이용자 대상
미리 서명된 임시 URL 지정 → 일정 시간 후 public 접근 불가
URL 생성자가 유효한 보안 자격 증명 / 허용하려는 작업 권한을 보유하고 있어야 함

스토리지 관리

버전 관리

한 버킷에 여러 버전의 객체 보관 → 실수로 삭제되거나 덮어써진 객체 복원 가능
버전 관리를 활성화하면 저장되는 객체에 대해 고유한 Version ID 자동 생성
단! 한 번 활성화하면 비활성화 불가
각 버전은 독립적으로 존재

객체 복제

하나 이상의 대상 버킷에 대한 객체를 동일한 리전 혹은 다른 리전에 비동기적으로 자동 복제
SRR (동일 리전 복제): 동일 리전 버킷에서 새로운 객체를 복제 → 로그 집계, 계정 간 라이브 복제, 액세스 제어
CRR (리전 간 복제): 서로 다른 리전 버킷에서 새 객체 복제 → 대기시간 최소화, 운영 효율적
S3 배치 복제: 기존 객체를 온디맨드로 다른 버킷에 복제

스토리지 클래스

S3 버킷의 각 객체에는 그와 연결된 스토리지 클래스가 존재
사용자는 사용 사례 및 요구사항에 맞게 스토리지 클래스 선택
접근 빈도에 따라 선택: S3 Standard → S3 Intelligent-Tiering → S3 Standard-IA → S3 One Zone-IA → S3 Glacier Instant Retrieval → S3 Glacier Flexible Retrieval → S3 Glacier Deep Archive

수명 주기

객체를 효율적으로 저장/관리하기 위해 S3 객체 그룹에 적용할 작업을 정의하는 수명 주기 구성
전환 작업: 객체가 다른 스토리지 클래스로 전환되는 시기 정의 (ex. 30일 지나면 Standard-IA, 60일 지나면 Glacier Instant Retrieval로 이동)
만료 작업: 객체가 만료되는 시기 정의, 만료되면 S3가 해당 객체 자동 삭제

Amazon CloudFront

CDN(글로벌 콘텐츠 전송 네트워크) 서비스
짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전세계 고객에게 안전하게 전송
기본 보안 기능도 제공

CDN이란?

콘텐츠 전송 네트워크
콘텐츠를 효율적으로 전달하기 위해 여러 서버에 데이터를 분산시켜 캐싱
원본 서버 위치와 상관 없이, 사용자에게 더 가까이 있는 서버로부터 캐싱된 컨텐츠 배포 → 빠르다!
ex. 영국 웹사이트를 미국에서 접근하려면? → 미국 근처 서버에서 배포

Edge Location

CloudFront가 콘텐츠를 제공하는 방식
사용자에게 더 가까운 지리적 위치에 콘텐츠를 저장하는 Origin Server의 캐싱 서버
사용자 요청 발생하면 → 지연 시간이 가장 적은 엣지 로케이션으로 라우팅

Regional Edge Caches (REC)

Origin Server와 Edge Location 사이에 존재하는 캐시 계층
Edge Location에서 캐시하지 않는 콘텐츠 저장
Edge Location에서 캐시 Miss → Origin Server로?(X) REC으로?(O) → 빠르다!

CloudFront 동작 방식

클라이언트로부터 Edge Server로 요청
Edge Server: 해당 데이터 캐싱 여부 확인
캐시 사본 있으면 → 사용자에게 응답
캐시 사본 없으면 → Origin Server로 포워딩 → Edge Server에 캐싱 데이터 생성 → 사용자에게 응답

Origin Server

데이터의 원본이 위치한 곳
정적 콘텐츠와 동적 콘텐츠 모두 처리
정적 콘텐츠: EC2 서버가 필요하지 않는 콘텐츠 (ex. 이미지) → S3 bucket (기본)
동적 콘텐츠: 서버가 필요한 콘텐츠 (ex. 로그인 자료, 실시간 추가 자료) → EC2 Instance, ELB
- 동적 콘텐츠를 정적 캐싱하면 TTL(Time To Live) 시간 동안 사용자는 새로 추가/수정된 데이터를 못 봄

CloudFront 기능

1. HTTPS 지원

Origin에서 HTTPS를 지원해주지 않아도 HTTPS 통신을 알아서 해주는 기능
인증키 설치 등 작업 불필요 → 간편!

2. 특정 지역 콘텐츠 접근 제한

지리적 제한 가능
ex. 회사 사정으로 특정 지역 접근 제한 가능

3. Signed URL

S3 pre-signed URL과 비슷한 기능
허용된 사용자에게만 접근할 수 있는 signed URL 제공 (ex. 유료결제를 한 사용자에게만 동영상 URL 제공)
하나의 콘텐츠에만 사용 가능
접근 허용 사용자 정해둠 → signed URL 생성 → 사용자 검증 → URL 제공

4. Signed Cookie

다수의 파일에 대한 access 제공 (다수의 파일에 하나의 signed cookie)
만료 시간, IP주소 범위 등 지정
ex. ID/PW를 입력해 로그인한 유료 회원에게 유료 콘텐츠를 모두 제공
로그인 → 인증정보 기반 cookie 발급 → 이 cookie 포함해 보내면 인증 완료

핸즈온

Step 0. 빌드 파일 다운로드

압축 해제한 build 폴더 준비

Step 1. Amazon S3 버킷 생성

Amazon S3 콘솔 접속 후 [버킷 만들기] 버튼 클릭
지리적으로 가까운 버킷 리전 선택 (지연 시간 단축, 비용 절감)
버킷 이름 지정 (전역적으로 고유한 이름!)
그 외 기본 설정 유지 후 [버킷 만들기] 클릭

Step 2. 정적 파일 업로드

버킷 내 [업로드] 버튼 클릭
❌ 빌드 폴더 통째로 업로드 ❌
⭕ 빌드 폴더 안에 있는 파일 개별 업로드 ⭕
[업로드] 버튼 클릭

Step 3. 정적 웹 사이트 호스팅

버킷 상단 [속성] 탭 클릭
쭉쭉 스크롤 → 정적 웹 사이트 호스팅 도착
[편집] 버튼 클릭
정적 웹 사이트 호스팅 > 활성화 클릭
인덱스 문서 > index.html 입력
오류 문서 > index.html 입력
[변경 사항 저장] 버튼 클릭
다시 버킷 > 속성 > 정적 웹사이트 호스팅 확인하면 웹 사이트 엔드포인트 확인 가능!
클릭해보면..? → 403 Forbidden 🤔
퍼블릭 액세스를 허용하면 해결 가능하지만, 모든 사용자에게 데이터 액세스를 허용하게 되면 보안 문제 발생
→ CloudFront를 이용해 보다 안전하게 웹 사이트를 호스팅 해보자!

Step 4. CloudFront 배포 생성

CloudFront 콘솔 접속 후 [배포 생성] 버튼 클릭
Origin Domain으로 앞서 생성한 S3 버킷 선택
원본 액세스 > 원본 액세스 제어 설정(권장) 선택
[Create new OAC] 버튼 클릭 → 기본 설정 유지, [Create] 버튼 클릭
기본 설정 유지하면서 쭉쭉 스크롤
웹 애플리케이션 방화벽(WAF) > 보안 보호 비활성화 선택
설정 > 기본값 루트 객체 index.html 입력
[배포 생성] 버튼 클릭
배포 완료되면 배포 도메인 확인 가능!
접속해보면..? → 또 AccessDenied
CloudFront는 웹 사이트 호스팅을 위해 S3 버킷에 업로드 된 데이터에 액세스 하려고 하지만, S3 버킷은 CloudFront에 액세스를 허용한 적이 없기 때문!
→ CloudFront가 버킷에 업로드 된 데이터에 액세스 할 수 있도록 해당 S3 버킷의 정책을 수정해보자!

Step 5. S3 버킷 정책 수정

CloudFront 콘솔 접속 → 앞서 만든 배포 선택
상단 [원본] 탭 클릭 → 원본 클릭 후 [편집] 버튼 클릭
쭉 내리다 보면 [정책 복사] 버튼 클릭
다시 S3 콘솔 접속 → 앞서 만든 S3 버킷 선택
상단 [권한] 탭 클릭 → 버킷 정책 [편집] 버튼 클릭
정책 입력란에 CloudFront 배포에서 복사한 정책 붙여넣기
[변경 사항 저장] 버튼 클릭
다시 CloudFront 배포 도메인 접속

X Facebook LinkedIn Bluesky