AWS S3

개인적인 경험을 바탕을 정리한거라 틀린 부분이 있을 수 있습니다.
어떤 피드백이라도 감사히 받겠습니다.
요금 같이 중요한 부분은 제가 책임질 수 있는게 없어 별도로 공식 문서를 참고하시길 바랍니다.

도입

S3 Tables 에 관한 내용은 제외되었습니다.

서버의 정적 파일들을 S3 에 저장하게 되어 정리하려 합니다.

AWS S3 (Simple Storage Service) 는 AWS 의 Object Storage 서비스 입니다.

파일을 객체의 개념으로 다루며 단순히 파일 데이터 뿐만 아니라 부가 정보 (메타데이터) 들도 같이 다루게 됩니다.

다루게 될 객체들의 패턴에 따라 유리한 클래스 들이 존재합니다. 서비스 모델이라 생각하셔도 좋습니다.

비용은 일반적으로 S3 보관 비용, 요청 비용, 통신 대역 비용이 존재합니다.

그리고 괜찮은 SLA 를 제공하며 AWS CloudFront 와 같이 사용하면 정적 파일 전송 관련한 부분은 상당히 쾌적하다 하네요.

본문

Classes

보통 다루는 객체들의 사용성이 다 다릅니다. 가벼운 조회용 페이지 같은 경우 수시로 호출이 될 수 있고 오래된 사진 파일 같은 경우 운 좋아야 한 달에 한 번 조회 될 수 있습니다.

S3 에선 이러한 경우들을 고려해 다양한 서비스 모델들을 제공하고 비용을 다르게 받고 있습니다.

일반적으로 중요한 데이터

• standard : 높은 내구성 (99.999999999) 과 가용성 (99.99%) 을 제공하며 네 곳의 가용 영역에 자동으로 복제하기에 복원에 유리합니다.

빈번히 접근하지 않는 데이터 (Infrequently Accessed)

• standard-IA : standard 보다 보관 비용이 낮으나 요청 및 검색 비용은 더 높습니다.
• One Zone-IA : standard-IA 보다 저렴하지만 단일 가용 영역에 저장합니다. 복구 가능성이 낮아집니다.

접근 빈도가 너무 낮아 단순 아카이빙 데이터 (Glacier)
보관 비용이 가장 낮습니다.

• Glacier Instant Retrieval : 밀리초 단위로 복구가 가능합니다.
• Glacier Flexible Retrieval : 몇 분 ~ 몇 시간 내 복구가 가능합니다.
• Glacier Deep Archive : 12 시간 이상의 복구 시간이 소요됩니다.

패턴이 불분명한 데이터 (Intelligent-Tiering)

• Inteligent-Tiering : 접근 빈도에 따라 여러 티어를 두어 객체들의 패턴을 통해 유동적으로 객체들을 옮깁니다.

지연 시간에 민감한 경우

• Express One Zone : 단일 가용 영역에 저장합니다. 따라서 복구 가능성이 낮아집니다. 하지만 낮은 지연 시간 과 높은 요청 처리량을 가집니다.

standard 설명에 있듯 내구성 99.999999999 % 를 제공합니다. 그리고 가용성은 99.99% 를 제공합니다. 정말 우수한데 이게 일년으로 환산하면 52분 정도의 시간이 나옵니다.
서비스에 따라 52분의 장애는 심각할 수 있어 이럴 경우 다른 리전에 복제하여 가용성을 향상시킬 수 있습니다. 약 0.32초 정도..
AWS 에선 Cross Region Replication 이란 기능도 제공합니다.

저장 공간 관리

이런 설정, 옵션들을 잘 사용하면 비용을 최적화할 수 있습니다.

• Lifecycle : 만료기간에 달한 객체를 다른 class 로 옮길 수 있습니다.
• Object Lock : 삭제, 수정이 안되도록 객체 별 잠금이 가능합니다.
• Replication : Region 상관 없이 객체를 복제할 수 있습니다.
• Batch Operation : API 와 콘솔에서 수 많은 객체들을 처리할 수 있습니다.

접근 관리

기본적으로 S3 의 객체들은 private 하게 관리되어 권한 관리를 통해 다뤄집니다.

• Block Public Access : 버킷의 Public Access 여부 결정
• IAM : IAM 사용자 단위로 제한하는 방법
• Bucket Policies : 버킷 단위로 제한하는 방법
• ACL : 자신 외 다른 AWS 게정에 대해 허가, 거부를 설정한 리스트로 관리

공식 문서에선 ACL 대신 IAM, Bucket Policies 를 사용하는걸 권장하는 것 같습니다.
As a general rule, we recommend using S3 resource-based policies (bucket policies and access point policies) or IAM user policies for access control instead of ACLs.

중요 개념

S3 는 버킷 안에서 객체(파일과 메타데이터) 를 저장합니다. 이 객체들은 key 를 가지는데 이 key 를 통해서 한 버킷 내에서 유일하게 식별됩니다.

• Bucket :
  S3 에서 객체를 담는 컨테이너입니다. 모든 객체는 Bucket 담기며
  객체의 이름이 images/hi.jpg 이며 Asia Northeast2 Region 의 my-bucket 이라는 이름의 버킷일 때 객체에 접근하기 위한 URL 은
  https://my-bucket.s3.ap-northeast-2.amazonaws.com/images/hi.jpg 로 생성됩니다.
  
  S3 Versioning 과 Storage 관리 기능을 둘 수 있습니다.

• Object :
  File 데이터와 메타데이터로 이루어졌습니다. 메타데이터 내부는 name-value pair 의 집합입니다. 여기에 last modified, Content-Type 같은 HTTP 메타데이터 정보가 담겨 있습니다.
  Object 는 Key(name) 과 version ID(versioning 중일 경우) 로 버킷에서 유일하게 식별됩니다.

• versioning :
  활성화 시 버저닝을 할 수 있으며 데이터 복구가 가능합니다. S3 가 유일한 version ID 를 생성해 줍니다.

• bucket policies : 실습 후 추가 예정

• access points : 실습 후 추가 예정

비용

비용 관련 공식 문서

크게 세 가지를 신경써야합니다.
스토리지 저장 비용 , 요청 비용, 데이터 전송 네트워크 비용

서울 리전 기준

• 스토리지 저장 비용
  S3 Standard 는 월마다 처음 50TB 는 GB당 USD 0.025 가 소요됩니다. (36.50 원 25.01.08 기준)
  1TB : (37,372.88 원 25.01.08 기준)
  50TB : (1,868,640.00 원 25.01.08 기준)
  
  다음 450TB 는 GB당 USD 0.024 가 소요됩니다. (35.04 원 25.01.08 기준)
  500TB : 16,145,049.60 + 1,824,843.75 원 (450TB + 50TB, 25.01.08 기준)
  
  500TB 초과 시 GB당 USD 0.023 가 소요됩니다.

• 요청 비용
PUT, COPY, POST, LIST 요청 (1,000 개당) USD 0.0045 가 소요됩니다. (6.57 원 25.01.08 기준)
  GET, SELECT 및 기타 모든 요청 (1,000 개당) USD 0.00035 가 소요됩니다. (0.51 원 25.01.08 기준)

• 데이터 전송 네트워크 비용
  S3 에서 인터넷으로 아웃바운드

처음 10TB/월 GB당 USD 0.126 (183.94 원 25.01.08 기준)
다음 40TB/월 GB당 USD 0.122 (178.10 원 25.01.08 기준)
다음 100TB/월 GB당 USD 0.117 (170.81 원 25.01.08 기준)
150TB 초과/월 GB당 USD 0.108 (157.67 원 25.01.08 기준)

다른 리전으로
CloudFront로는 무료
다른 Region 은 GB당 USD 0.08

다음 사항은 S3의 대역폭 비용을 생략합니다.

• 매월 100GB의 인터넷 트래픽 (정말?!)
• 인터넷에서 수신된 데이터 (PUT, Inbound)
• 동일한 리전의 S3 버킷 간에 전송된 데이터 (가용 영역 복제에 비용 x)
• S3 버킷에서 버킷과 동일한 리전의 AWS 서비스에 전송된 데이터 (반대도 무료로 알고 있습니다. 참고)
• CloudFront 로 전송된 데이터

정적 웹 사이트 호스팅

단순히 객체 보관 뿐만 아니라 정적 웹 사이트 호스팅 용으로도 사용할 수 있습니다.
버킷에서 정적 웹 사이트 호스팅 기능을 활성화 시켜주고 모든 퍼블릭 액세스 차단을 비활성화하고 버킷 정책에 모든 접속을 허용시키면 됩니다

문제점
1. HTTP 통신
2. 버킷이 public 하게 공개됨
3. S3 의 엔드포인트가 그대로 드러남

1, 2 번 문제는 CloudFront 를 도입함으로 해결이 가능합니다. (CloudFront ACM, OCI)
3 번 문제는 Route53 을 통해 다른 도메인을 지정해줄 수 있습니다.

AWS 에선 S3, CloudFront 를 통한 정적 웹 호스트만이 베스트 프랙티스일까?

이러한 방법 외에도 EC2 에서 직접 웹서버를 배포해 호스팅할 수 있습니다. 그리고 Amplify 나 Lightsail 을 통해서도 손쉽게 할 수 있습니다.

• EC2 + WebServer :

  • 사용 시간 별로 비용이 나감
  • 웹서버를 직접 관리해야함
  • 다양한 기술 스택을 유연하게 적용 가능

• S3 + CloudFront :

  • 기본적으로 사용한만큼 나가는 비용
  • 서버를 관리할 필요 없습니다
  • 정적 데이터 전달 용으로 매우 적합
  • 버킷 정책, IAM 권한 등을 잘 설정해야함

• Amplify :

  • AWS 에서 제공하는 완전 관리 정적 웹 호스팅 서비스
  • 배포 등 웹 개발에 필요한 전반적인 도구들을(CI/CD 자동화, SSL 인증서) 다 제공하는 서비스
  • EC2 처럼 자유롭게 세팅하긴 힘듦
  • 단순히 정적 웹 호스팅이 목적이라면 비용적으로 S3 + CloudFront 가 적합할 수 있음

• Lightsail :

  • 서비스 전체를 고정비용으로 사용할 수 있는 서비스
  • OS, 워드프레스, 고정 IP 주소 등을 제공
  • EC2 보다 자유로운 세팅은 힘듦
  • 확장이 불가해 고트래픽에 대처 힘듦

특성	EC2	S3 + CloudFront	Amplify	Lightsail
초기 설정	복잡함	간단함	매우 간단함	간단함
유지보수	높음	없음	없음	낮음
확장성	높음	매우 높음	매우 높음	제한적
비용	상대적으로 높음	저렴함	중간	저렴함
트래픽 처리	Auto Scaling 필요	CloudFront로 자동 처리	자동 처리	제한적
적합성	커스텀 구성 필요 시	정적 웹사이트	CI/CD 통합 필요 시	소규모 프로젝트

수명 주기 정책

실습 후에 작성

대용량 데이터 업로드 방법

• API 와 SDK :
  서드 파티 도구를 사용해 개발 환경에서 편리하게 사용할 수 있습니다. 기본적으로 IAM 사용자에게 AccessKey 를 발행해 사용할 수 있게 합니다.

• Multipart upload :
  특성 상 여러 파일로 나누게 되면 그만큼 요청을 더하게 되는데 처음 요청의 비용만 받고 이후 비용은 무료입니다!
  complete, abort 명령어로 멀티파트 업로드의 성공 처리와 실패 시 잔존한 잔재 멀티파트 파일들을 제거하도록 할 수 있습니다.

• AWS Transfer for SFTP :
  SFTP 서버를 통해서 전달합니다. 보안적으로 우수할 수 있습니다.

• AWS DastaSync :
  온프레미스 스토리지와 AWS 스토리지 간의 대용량 데이터 이동 시 유용합니다.

PB, EB 규모 데이터를 업로드하는건 아무래도 어렵습니다.
그럴땐 AWS가 HDD에 데이터를 넣어 보내는 Snowball 서비스, Snowball Edge 서비스, 트럭으로 배송해주는! Snowmobile 서비스가 있다네요! 뭔가 낭만적이다. 이름도 그렇고 ❄️

주의할 점

• S3 를 안전하게 사용하는 방법에 대해 잘 정리된 글이 있어 공유드립니다. (글이 재밌는게 보안과 DX 를 둘 다 지키려는게 느껴지네요)
  우아한 Tech Blog 안전한 S3 사용 가이드
  요약하자면
  CloudFront 를 통해 S3 직접 접근 막고 HTTPS 사용하자,
  Route53으로 CloudFront 도메인을 지정해주자,
  IAM 정책은 최소한으로만 둬서 민감한 정보를 저장하는 버킷의 정보를 얻기 힘들게 하자.
  민감한 정보 담당 버킷과 일반적인 정보 담당 버킷은 관리자를 분리해서 더 조심히 사용하자. 관리가 잘 안되고 있음의 증거

• 버킷이 한 번 생성되면 이름과 리전을 바꿀 수 없습니다.

• 버킷은 폴더보다는 윈도우의 드라이브 개념이라 버킷 안에 버킷을 만들 순 없습니다.

• S3 는 리전 단위이며 VPC 에 속하지 않습니다.

마무리

공식 문서에서 일관성, 동시성 관련해서 어떻게 모델링 했는지 설명해주는데 참고해도 좋을 것 같네요. 실습하면서 보강할 부분은 보강해야겠습니다.

S3 를 쓴다면 CloudFront 도 같이 쓰는 경우 많다네요.
S3 가 PUT 을 담당한다면 CloudFront 는 GET 을 담당하는 느낌으로 Cloud Front곧 공부해야겠습니다.

얼렁 실습해야지

참고 출처
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/WebsiteEndpoints.html
https://techblog.woowahan.com/6217/
https://aws.amazon.com/ko/s3/pricing/
https://www.yes24.com/product/goods/102368122