AWS S3, 제대로 이해하기 - S3 Basics

AWS S3에 대한 이해부터 활용까지 이해하는 것이 본 포스팅의 목표입니다.

 

 

===== AWS S3, 제대로 이해하기 Series.  =====

👉🏻 AWS S3, 제대로 이해하기 - S3 Basics

✔️ AWS S3, 제대로 이해하기 - Storage Classes

✔️ AWS S3, 제대로 이해하기 - Lifecycle

✔️ AWS S3, 제대로 이해하기 - Replication & Event Notification

 

 

Simple Storage Service ?

S3는 AWS가 제공하는 다양한 데이터를 저장하고 검색할 수 있는 서비스입니다. S3에 저장할 수 있는 '다양한 데이터'는 범위가 굉장히 넓습니다. 컴퓨터를 사용하면서 다루는 다양한 파일일 수도, 사진이나 동영상과 같은 미디어일 수도 있고, 웹 사이트를 띄우기 위한 코드가 될 수도 있습니다. AWS에서는 S3를 아래와 같이 소개합니다.

 

 

https://aws.amazon.com/s3/getting-started

 

시작하기 전, S3에 대한 감을 얻기 위해 빠르게 훑어보도록 하겠습니다. 해당 부분은 무시하고 아래 섹션으로 넘기셔도 됩니다. 

 

개발자 입장에서 이해를 돕자면, 블로그 서비스를 제작할 때 사용자가 이미지나 동영상을 업로드할 수 있도록 개발하는 상황을 생각해봅시다. video-1를 저장해서 사용자가 적은 글과 함께 띄워야 합니다. 그렇다면, 이 비디오를 어떻게 처리해야 할까요? 모든 사용자가 업로드하려는 파일들을 서버에 저장하기에는 서버 메모리에 부담이 됩니다. 또, 서버에 장애라도 발생하면 모두 잃게 됩니다. 그래서 Naver mybox, Google drive 처럼 클라우드 서버 공간에 파일을 업로드하고 해당 파일의 참조가 되는 링크로 다룰 수 있습니다.

 

또, 다양한 영상을 볼 수 있는 페이지가 있을 때, 20개의 동영상을 조회한다고 생각해봅시다. 서버에서 프론트로 20개의 모든 영상을 전부 전달하기에는 백엔드의 부담이 커지고 네트워크 소모가 상당하겠죠. 그래서 영상을 클라우드 환경에 업로드하고, 영상들을 참조할 수 있도록 링크를 프론트로 보내고 각 프론트에서 20개의 영상을 조회하면 더 빠르고 효과적인 서비스가 될 수 있습니다.

 

 

Overview

S3는 다양한 데이터(이미지, 백업 파일, 데이터, 영화 등)를 저장하고 검색할 수 있는 파일 저장 관리 시스템입니다.

 

✔️ Term

: S3에서는 데이터를 저장할 때 Bucket과 Object라는 용어를 사용합니다. Bucket은 사용자가 데이터를 담을 수 있는 공간을 명시적으로 구분합니다. Object는 사용자가 업로드하는 모든 데이터를 통칭합니다. 

 

✔️ Security

: Object는 모두에게 공개할 수도, 회사 내의 접근으로 제한할 수도, 개인만 접근할 수도 있습니다. S3 Bucket Policy를 포함한 보안 정책을 설정하여 공개 범위와 업로드 권한을 조정할 수 있습니다. 

 

✔️ Versioning

: Object는 버전 정보를 가질 수도 있고, S3가 버전을 관리해주기도 합니다. 버전 정보는 사용자의 실수나 롤백이 필요한 상황에 유용하게 사용될 수 있습니다.

 

✔️ Storage Class

: 백업용, 상시 접근 용, 장애 대응용 등 다양한 상황에 따라 관리되는 성격이 다르며, 이를 감안하여 저장 성격을 각 다르게 설정해서 비용 절감을 절감할 수 있습니다.

 

✔️ Replication

: 중요한 Object일 경우, 복제를 해두어 사용자의 실수나 AWS 장애에 대응할 수 있습니다.

 

✔️ Lifecycle Rules

: Lifecycle Rules를 이용하여 객체를 복제하고, 관리하는 규칙을 정해둘 수 있습니다.

 

 

Concepts

S3에서는 데이터를 저장할 때 Bucket과 Object라는 용어를 사용합니다. 하나씩 살펴보도록 하겠습니다.

 

Bucket 

S3에서는 사용자들이 "Bucket"에 객체를 저장할 수 있습니다.

파일들이 저장되는 최상단 폴더라고 볼 수 있습니다. 

 

✔️ Region

Bucket의 이름은 S3 내에서 고유한 이름을 가져야 합니다. 즉, 누군가 bucket-A 라는 버킷을 생성했다면, 본인은 bucket-A 이름의 버킷을 생성할 수 없습니다. 계정이 다르고 Region이 다르더라도 말이죠.

 

 

S3는 리전이 구분되지 않는 Global 서비스로 보이지만, 사실 각 리전을 가집니다.

그래서 버킷을 생성할 때 리전을 설정합니다.

 

 

 

Object

S3는 Object라는 개념으로 모든 데이터를 다룹니다. 

 

Object는 Key를 가지고 있는데, prefix(folders) + object 이름(object name)으로 구성됩니다.

파일의 전체 경로라고 볼 수 있습니다. 

 

가령, myFile.txt 이라는 파일을 s3-bucket-example 버킷에 업로드 한다고 해봅시다. 그럼 Object의 Key는 아래와 같습니다.

 

s3://s3-bucket-example/myFile.txt

 

혹은, s3-bucket-example 버킷 내의 /folder_one/folder_two/ 위치로 myFile.txt 를 저장한다고 하면, Key는 아래와 같습니다.

 

s3://s3-bucket-example/folder_one/folder_two/myFile.txt

 

Bucket 내에서는 Folder로 UI가 구성되어 있지만, 실제로 S3는 directory의 개념이 없으며, Key 값으로 구분합니다. S3에서는 편의상 폴더로 지칭합니다. 

 

 

실제로 Bucket에 folder를 생성하고 파일을 저장하면 아래와 같이 표기됩니다.

Bucket: gngsn

Folder: /folder_one/folder_two

Object: IMG_8768.jpeg

 

 

 

Object overview의 Key 항목을 보면 folder_one/folder_two/IMG_8768.jpeg 라고 명시되어 있는 것을 확인할 수 있습니다.

 

또, 주목할만한 내용으로 Versions 탭인데요. Bucket의 Version 관리를 활성화했다면(default: 비활성), Object은 Version ID를 가집니다. 만약, Bucket의 버전 사용을 활성화하기 전에 저장된 객체들은 활성화된 이후 null 값을 가집니다. 자세한 내용은 Versioning에서 살펴보도록 하겠습니다.

 

 

✔️ Content

Object의 최대 크기는 5TB (5000GB) 이며, 한 번 업로드 제한은 5GB입니다.

20GB 크기의 파일을 업로드 하려면 Multi-Part Upload로 4번에 거쳐 5GB 씩 업로드한다는 의미입니다. 

 

 

 

Security

Bucket에 업로드한 Object는 URL을 통해 쉽게 접근할 수 있습니다. 하지만, 원하지 않는 누군가가 업로드한 파일에 접근하는 것을 막아야할 때가 있습니다. 가령, 회사 내의 문서를 외부로 노출하지 않는 아주 보편적인 경우가 있습니다. 보안과 관련해서는 사용자 기반으로 제한할 수도, 리소스 기반으로 제한할 수 있습니다.

 

User-based

- IAM Policy

 

Resource-Based Policy

- Bucket Policies

- Object Access Control List

- Bucket Access Control List

 

사용자를 기반으로 제한하고 싶다면, IAM Policy를 통해 특정 유저의 접근을 허용하거나 거부할 수 있습니다.

리소스를 기반으로 제한하고 싶다면, Bucket Policies, Object ACL (Access Control List), Bucket ACL (Access Control List)로 관리할 수 있습니다. Access control list(ACL) 은 기본 값으로 비활성 상태입니다. Ownership에서 ACL을 활성화하여 사용할 수 있습니다. 가장 일반적으로 사용되는 Bucket Policies 대한 내용만 살펴보겠습니다.

 

Bucket Policies

Bucket Policies는 JSON으로 작성된 정책입니다.

어떤 리소스(Resource)를 어떤 대상(Principal)에게 어떤 동작 시(Action) 어떻게 처리할지(Effect)를 명세합니다.

 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPublicReadCannedAcl",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111122223333:root",
                    "arn:aws:iam::444455556666:root"
                ]
            },
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
        }
    ]
}

 

 

위의 정책을 살펴보면,

Principal  |   IAM 유저 중 계정 ID가 111122223333인 root 사용자와 계정 ID가 444455556666인 root 사용자에 대해,

Resource |  S3 내 DOC-EXAMPLE-BUCKET 버킷 내의 모든 리소스(/*)에 대해

Action      |  PutObject 를 실행하는 것을

Effect       |  허용하겠다

는 의미입니다.

 

 

Block all public access

Public 설정을 할 때에는 주의할 점이 있습니다. Bucket의 Public Access를 제한하는 "Block all public access" 이 Default option이라는 점입니다. 

 

 

만약, 업로드한 Object를 공개된 사이트에서 사용하고자 한다면, 이를 비활성해야 합니다. 해당 옵션이 활성화되어 있는 이유를 잘생각해보면, S3를 가장 많이 사용할 "기업" 입장에서 데이터 유출 방지를 보장해야 하는 것이 우선이 되어야 하기 때문입니다.

 

Static Website Hosting

S3를 활용하는 사례로, 정적 웹 사이트 호스팅이 있습니다. 가령, S3에 my-simple-page.html 파일을 업로드하고 Public한 상태로 공개하면 정적 사이트로 활용할 수 있습니다. 

 

이를 언급한 이유는, 정적 웹 사이트를 호스팅할 때 403 Forbidden이 보인다면, 반드시 위의 Block all public access을 비활성화 시켜야 해결할 수 있기 때문입니다.

 

 

 

Versioning

Object의 속성 중에는 Version ID가 있습니다. 이는 곧 Object의 버전을 관리할 수 있다는 의미인데요.

Bucket 수준에서 해당 Bucket 내 저장되는 Object의 Version을 관리할지 말지를 설정할 수 있습니다(Bucket Level). 버전 관리를 하는 이유로 아래와 같은 두 가지를 생각해볼 수 있습니다.

 

- 의도되지 않은 삭제 방지: 이전 버전으로 복구 가능

- 이전 버전으로의 쉬운 롤백

 

Bucket의 Version은 기본적으로 비활성화 되어 있으며, 이 때 해당 Bucket에 저장된 Object는 아래와 같이 표시됩니다.

 

 

 

Enable Bucket Versioning

Bucket의 Versioning을 활성화한 이후를 살펴보도록 하겠습니다.

 

 

Versioning 활성 전에는 보이지 않던 Show versions 토글과 Objects 테이블의 Version ID 열을 확인 할 수 있습니다. Show versions을 활성화하면 Version ID을 확인할 수 있는데, Versioning을 활성화하기 전에 업로드한 객체는 null 값을 가집니다.

 

 

UPLOAD: New Object

이 상태에서 새로운 파일을 업로드해보도록 하겠습니다.

 

 

문자열의 Version ID를 가진 객체가 업로드 된 것을 확인할 수 있습니다.

 

만약, 동일한 파일을 업로드하면 어떻게 될까요? 

Version ID가 null 이었던 Group 43.png 파일을 다시 한 번 업로드해보겠습니다.

 

 

위와 같이 기존의 Group 43.png가 아닌 새로운 이미지가 보이게 되며, 새로운 Version ID를 가진 것을 확인할 수 있습니다.

 

 

DELETE: a Previous Object

이번엔 Show versions를 비활성 시키고 해당 객체를 삭제해보겠습니다.

 



삭제를 확인하는 과정으로 "delete"를 입력하게끔 유도합니다.

 

 

 

실제로 삭제되는 것이 아니라, Delete marker가 생성되는 것을 확인할 수 있습니다.

 

 

 

 

DELETE: a Delete marker

Delete marker가 표시된 상태에서 기존의 버전을 삭제하면 어떻게 될까요?

 

 

첫 번째 업로드했던 버전을 삭제해보도록 하겠습니다.

주목할 만한 것은, 이번에는 delete가 아닌 permanently delete를 입력하게끔 유도합니다.

 

 

삭제를 하면 아래와 같이 이전 버전이 완전히 삭제된 것을 확인할 수 있습니다.

즉, 특정 버전의 Object에 Delete marker가 존재할 때 삭제를 하게되면 해당 Version의 Object는 영구적으로 삭제됩니다.

 

 

이번엔 Delete marker 자체를 삭제해보겠습니다.

 

 

Delete marker를 삭제 할 때에도 permanently delete를 입력하게끔 유도를 했으며, 삭제를 진행하게 되면 Delete marker가 제거되면서 아래와 같이 다시 특정 객체의 삭제 행위가 취소 된 것을 확인할 수 있습니다.

즉, Delete marker를 삭제하면 해당 객체의 취소 행위가 취소됩니다.