AWS S3는 업계 최고의 확장성과 데이터 가용성 및 보안과 성능을 제공하는 온라인 객체 스토리지 서비스입니다.
구글 드라이브처럼 파일 저장 서비스이며, 데이터를 온라인에서 객체 형태로 저장하는 서비스입니다.
데이터 조작에 HTTP/HTTPS를 통한 API가 사용되고 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있습니다.
S3는 저장하는 데이터 양에 대한 비용 저렴, 저장할 수 있는 데이터양이 무한에 가깝습니다.
단순한 파일 저장 영역 + 다양한 AWS 서비스의 사용 로그 저장, 정적 웹 사이트 호스팅, EBS 스냅샷의 저장 영역 기능 등을 가지고 있습니다.
반대가 EBS
CPU, 램카드, 그래픽카드, SSD, HDD가 다같이 장착되어 컴퓨터가 돌아가는 것처럼 EC2 인스턴스가 연산에 관한 처리를 한다고 하면, 이 데이터를 저장하는 역할을 하는 것이 EBS입니다.
EC2와 같은 가용영역에 존재합니다. AZ가 같아야 연결 및 통신이 빠르기 때문입니다.
EBS 볼륨
EBS로 생성한 디스크 하나하나 저장 단위입니다.
EBS 볼륨을 인스턴스에 연결한다는 의미는 EC2에 물리적 하드 드라이브처럼 사용하겠다는 의미입니다.
윈도우에서 C드라이브, D드라이브가 각각 디스크이며 볼륨에 해당합니다.
객체 스토리지는 객체로 된 파일을 다루는 저장소인데 S3에서는 OS나 게임 프로그램을 본체에 꽂혀있는 하드라는 스토리지에 저장하고 구동할 수는 없습니다.
즉 파일을 설치하는 행위는 할 수 없고, 그냥 이미지나 동영상 파일 등만을 저장할 수 있습니다.
1️⃣ 저쟝 용량이 무한이고 파일 저장에 최적화되어 있습니다. 용량을 추가하거나 성능을 높이는 작업이 필요없습니다.
2️⃣ 비용은 EC2와 EBS로 구축하는 것보다 훨씬 저렴합니다.
3️⃣ S3 자체가 수천 대 이상의 매우 성능이 좋은 웹 서버로 구성되어 있어서 EC2와 EBS로 구축했을 때처럼 Auto Scaling이나 Load Balancing에 신경 쓰지 않아도 됩니다.
4️⃣ 별도의 클라이언트 설치나 ActiveX를 통하지 않고, HTTP 프로토콜로 파일 업로드/다운로드 처리가 가능합니다.
5️⃣ S3 자체로 정적 웹서비스 가능합니다.
6️⃣ 동적 웹페이지와 정적 웹페이지가 섞여있을 때 동적 웹페이지만 EC2에서 서비스하고 정적 페이지는 S3를 이용하면 성능 높이고 비용 절감 가능합니다.
사용 예시
1. 클라우드 저장소
2. 서비스의 대용량 파일 저장소 - 이미지, 동영상, 빅데이터
3. 서비스 로그 저장 및 분석
4. AWS 아데나를 이용한 빅데이터 업로드 및 분석
5. 서비스 사용자의 데이터 업로드 서버(이미지/동영상 서버)
6. 중요한 파일은 EC2의 SSD에 저장 X. S3에 저장.
7. glacier와의 연동으로 비용 절감 및 규정 준수 가능. (자주 사용하지 않는 데이터를 S3에서 자동으로 변환)
S3에는 Bucket과 Object라는 단위가 있습니다.

https://[BucketName].[Region].[amazonaws.com]/object key.file
만약 User라는 이름의 버킷에 profile.png 객체 파일을 저장하면 http://User.s3.amazonaws.com/profile.png라는 URL이 생성되게 된다.

S3를 구성할 때, 버킷이라는 컨테이너를 놓을 리젼을 선택하고, 해당 컨테이너 내부에 객체라는 형태로 데이터를 저장하는 형태로 스토리지를 구축합니다.
Bucket의 소유권은 이전 불가능.
S3에 저장되는 데이터는 모두 객체라고 부릅니다.
객체는 하나 당 1Byte에서 최대 5TB까지 저장이 가능하며 저장할 수 있는 객체의 수는 제한이 없습니다.
각 객체는 데이터와 메타데이터를 지니는데 S3 버킷에 올리는 객체가 바로 데이터고 최종 수정일, 파일 타입 등의 데이터를 메타데이터라고 합니다.
객체는 키를 통해서 버킷에서 유일한 것으로 식별될 수 있고, 버킷에 존재하는 모든 객체는 단 하나의 키를 가집니다.
그래서 S3내 버킷, 키, 버전 ID를 통해 특정 객체를 파악할 수 있습니다.
S3는 전 세계에서 접속할 수 있는 스토리지 서비스입니다. 따라서 어느 누가 접속해 내용물을 변조할 수 있기 때문에 S3의 버킷의 기본 정책은 private으로 되어 있습니다.
그래서 버킷을 통째로 public으로 개방하는 것이 아닌 S3 권한 제어를 통해 접근 제어를 설정할 수 있습니다.
사용자를 생성하고 사용자의 버킷 권한 액세스를 관리하는 AIM
권한 있는 사용자에 대해 간단한 개별 객체를 액세스 가능하게 만드는 액세스 제어 목록(ACL)
단일 S3 버킷 내 모든 객체에 대한 권한을 세부적으로 구성하는 버킷 정책
임시 URL을 사용하여 다른 사용자에게 기간 제한(임시 권한) 액세스를 부여하는 쿼리 문자열 인증 (pre-signed URL)
버킷 정책은 버킷 단위로 접근 제어를 확정하고 이후에 변경이 적을 때, ACL은 객체 단위로 접근 제어할 때, IAM 제어는 사용자 단위로 접근 제어할 때 사용하는 것이 일반적입니다
AWS에서 S3의 권한에 가보면 퍼블릭 액세스 차단(버킷 설정)이 있습니다.

실무에서는 모든 액세스 차단 혹은 ACL을 이용하여 액세스 차단해주는 것이 일반적이라고 합니다.
버킷을 사용할 권한을 가진 여러 명의 사용자 별로 각각의 행위에 대한 권한 범위를 설정할 수 있습니다.
ex) 누군가는 읽기만 가능, 누군가는 읽기, 쓰기 모두 가능한 상태.
버킷에 대한 전반적인 권한 설정은 Bucket Policy를 통해 설정됩니다. (단 버킷 안의 파일 하나하나의 권한 설정은 불가능.)
버킷정책은 버킷에대해서만 권한을 설정할 수 있지만, ACL은 버킷 뿐만 아니라 개별 객체에도 가능하다.
버킷정책은 JSON을 통해 세분화된 권한을 설정할 수 있지만, ACL은 버킷 정책만큼 세분화된 엑세스 모드를 제공하지 않는다.
버킷이나 객체에 대해 요청자의 권한 허용 범위를 어디까지 설정할 것인가에 대해 간단하게 설정할 수 있습니다.
일반 퍼블릭한 사용자가 될 수도 있고, 계정의 Owner나 Resource Group, 특정 사용자가 될 수 있습니다.
각각의 버킷과 그 속에 포함된 객체는 ACL과 연동되어 ACL로 S3 버킷이나 객체의 접근을 제어하는 것이 가능합니다.


S3는 nginx와 비슷하다고 생각하면 된다. 정적 데이터를 유저에게 제공할 때 좋고 용량이 크기 때문에 일반적으로 이미지, 폰트, 영상 같은 것들을 제공할 때 쓰인다.
React(SPA), HTML/CSS/JS 제공 (static 웹사이트 호스팅이라고 함.)
S3 요소로는 User-Based, Resource-Based가 있다.
Resource-Based는 Bucket 단위가 되면 Bucket ACL(Access Control List), Object 단위가 되면 Object ACL이다.
Bucket 특징
Object 특징
Object 표현법으로는 S3://my-bucket/folder1/folder2/hello.txt 식으로 작성한다.
디렉토리처럼 보이지만 실제 디렉토리는 아니고 전부 full-name이다.

일반적으로 S3는 저장할 때 Client와 S3가 있으면 저장 요청을 하고 저장 완료 시 S3 URL을 반환한다.
S3에 저장하고자 할 때 Front가 Backend에게 multipart로 파일을 주고 다시 S3에 저장하면 비용이 많이 든다. 그래서 미리 Backend가 S3로부터 Pre-signed URL을 받고 URL을 Front에게 전달만 한다. Front가 직접 S3에 저장을 하여 인증 정보 없이 업로드 가능하다.