S3 개념 & 버킷

문한성·2023년 6월 22일

aws devops

부트캠프

목록 보기

116/123

S3 (Simple Storage Service) 개념

AWS S3는 업계 최고의 확장성과 데이터 가용성 및 보안과 성능을 제공하는 온라인 오브젝트(객체) 스토리지 서비스이다. (참고로 S 앞글자가 3개라서 S3 이라고 한다.)

쉽게 말하자면, 스토리지 즉 구글 드라이브 처럼 파일 저장 서비스이며, 데이터를 온라인으로 오브젝트 형태로 저장하는 서비스라고 보면 된다.

앞에 온라인이라는 글자가 붙는 이유는 데이터 조작에 HTTP/HTTPS를 통한 API가 사용되기 때문이다.

또한 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있어 개발자가 쉽게 웹 규모 컴퓨팅 작업을 수행할 수 있도록 한다.

S3는 저장하는 데이터 양에 대한 비용도 저렴하고, 저장할 수 있는 데이터 양이 무한에 가깝다.

또한 'elastic'한 성질때문에 별도의 스토리지 확장, 축소에 신경쓰지 않아도 된다.

S3는 FTP 서버처럼 단순한 파일 저장 영역으로 사용할 수도 있으며, 다양한 AWS 서비스의 사용 로그 저장, 정적 웹 사이트 호스팅, EBS 스냅샷의 저장 영역 기능 등을 가지고 있다.

이외에도 빅 데이터 분석의 데이터 소스로 활용하거나 On-Premise 환경의 재난복구 전용 데이터 백업, Auto Scaling을 활용한 EC2 인스턴스의 로그 저장 등으로 전 세계적으로 폭 넓게 활용되고 있다.

S3는 지역별 서비스로서 지역별 재난 상황에 대비하여 자동으로 반복 저장을 한다.

S3을 사용하는 이유

S3는 저장 용량이 무한대이고 파일 저장에 최적화되어 있다. 용량을 추가하거나 성능을 높이는 작업이 필요없다.
비용은 EC2와 EBS로 구축하는 것보다 훨씬 저렴하다
S3 자체가 수천 대 이상의 매우 성능이 좋은 웹 서버로 구성되어 있어서 EC2와 EBS로 구축했을 때 처럼 Auto Scaling이나 Load Balancing에 신경쓰지 않아도 된다.
웹하드 서비스와 비슷하지만, 별도의 클라이언트 설치나 ActiveX를 통하지 않고, HTTP 프로토콜(restful)로 파일 업로드/다운로드 처리가 가능하다.
S3 자체로 정적 웹서비스 가능 (html 파일을 스토리지에 저장하고, html 파일에 접근하면 그게 홈페이지)
동적 웹페이지와 정적 웹페이지가 섞여있을 때 동적 웹페이지만 EC2에서 서비스하고 정적 웹페이지는 S3를 이용하면 성능도 높이고 비용도 절감할 수 있다.

S3 버킷 / 객체 개념

S3에는 Bucket과 Object라는 단위가 있다.

객체(Object)는 데이터와 메타데이터를 구성하고 있는 저장 단위이며
버킷(Bucket)은 이러한 객체를 저장하고 관리하는 역할을 한다.

버킷은 그냥 디렉토리/폴더 개념으로 키는 파일명으로 이해해도 된다.

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

S3을 구성할때, 버킷(Bucket)이라는 컨테이너를 놓을 리전을 선택하고, 해당 컨테이너 내부에 객체(Object)라는 형태로 데이터를 저장하는 형태로 스토리지를 구축한다.

한 계정 당 Bucket은 최대 100개까지 사용이 가능하고, 버킷 단위로 접근 제한을 설정할 수도 있다.

단, Bucket의 소유권은 이전할 수 없기 때문에 주의해야 한다.

S3에 저장되는 데이터는 모두 객체라고 부른다.

객체는 하나 당 1Byte에서 최대 5TB까지 저장이 가능하며 저장할 수 있는 객체의 수는 제한이 없다.

각 객체는 데이터와 메타데이터를 지니는데 S3 버킷에 올리는 객체가 바로 데이터이고 최종 수정일, 파일 타입 등의 데이터를 메타데이터라고 한다. (메타데이터는 네임-벨류 쌍으로 이우러져 있다.)

객체는 키를 통해서 버킷에서 유일한 것으로 식별될 수 있으며, 버킷에 존재하는 모든 객체는 단 하나의 키를 지닌다.

따라서 S3 내에서 버킷, 키, 버전 ID를 통해 특정 객체를 파악할 수 있다.

S3 리전(Region) 구성

S3가 생성한 버킷을 저장할 위치를 지정한다.
리전 간 객체 공유는 불가능
버킷 위치(리전)을 어디에 지정하냐에 따라 지연 시간, 비용 등이 결정되게 된다.

S3 버킷(bucket) 구성

Amazon S3에서 생성되는 최상위의 디렉토리이며, Amazon S3에 저장된 객체의 컨테이너 이다.
S3상의 모든 객체는 버킷에 포함된다.
버킷의 이름은 S3에서 유일해야 한다.게임 아이디같이 중복될수가 없다. 즉, 전세계에 어디에도 중복된 이름이 존재 할 수 가 없다.
한 계정 당 최대 100개의 버킷 사용 가능.
버킷 주소는 https://bucketname.s3.Region.amazonaws.com 형태로 이루어진다.
버킷을 생성하면 default로 private상태이다.
버킷 소유권은 이전할 수 없다.
버킷 안에 다른 버킷을 둘 수 없다.

S3 객체(Object) 구성

S3 Object에는 Key, Value, Version ID, Metadata, CORS(Cross Origin Resource Sharing)와 같은 다양한 구성요소가 존재한다.

Key : 파일의 이름
- 버킷 내 객체의 고유한 식별자. 버킷 내 모든 객체는 정확히 하나의 키를 갖는다.
- 버킷, 키 및 버전 ID의 조합은 각 객체를 고유하게 식별한다.
Value : 파일의 데이터
- S3은 Key - Value 형태로 저장되지만, Key의 접두어 및 슬래시를 이용하여 폴더 개념 같이 사용 가능하다.
- 윈도우 파일의 폴더 경로를 조회해보면 \Documents\img\cloud.png 이렇게 되어있는데, 이와같이url로 /awsinaction/img/cloud.png 같이 구성 되어진다는 말이다.
Version Id : 파일의 버전 아이디
- Version ID는 S3의 고유 특징 중 하나 이다.같은 파일이지만 다른 버전으로 올릴 수 있게 돕는 인식표 라고 보면 된다.만약 이전 버전으로 돌아가고 싶다면, Version ID를 통해 쉽게 복원시킬 수 있다.
MetaData : 파일의 정보를 담은 데이터
- 최종 수정일, 파일 타입, 파일 소유자, 사이즈 ..등
ACL : 파일의 권한을 담은 데이터 (접근이나 수정)
Torrents : 토렌트 공유를 위한 데이터
CORS(Cross Origin Resource Sharing) : 한 버켓의 파일을 지역을 무시하고 다른 버켓에서 접근 가능하게 해주는 기능

S3 버저닝 (Versioning)

앞서 소개했듯이, 파일을 실수로 삭제하고 저장을 해버렸을 경우, S3는 이를 위해 자동화된 백업 관리 기법인 버전 관리 및 생애주기 관리 기법을 제공한다.

버저닝(Versioning)은 특정 객체에 여러 버전을 유지하는 수단이다.

파일에 버젼 아이디를 붙임으로서, 버전 관리를 사용하여 S3 버킷에 저장된 모든 객체의 버전을 보존, 검색 및 복원할 수 있다. 또한 의도하지 않은 사용자 작업과 응용 프로그램 오류 모두 쉽게 복구할 수 있다.

변경내용을 추적할 수 있으므로 매우 편리하지만 비용을 조심해야한다.

aws 매니저에서 버킷을 만들때 기본적으로 비활성화 라서, 직접 활성화 해야한다.

단, 버킷에서 버전을 사용하도록 설정한 후에는 비활성화 상태로 돌아갈 수 없다. 대신 버전 관리 일시 중지 설정은 가능하다.

객체 버전 ID 수정 / 삭제 / 조회 동작

버킷에 대한 버전 관리를 사용 설정하면 저장되는 객체에 대해 고유한 버전 ID를 자동으로 생성되어진다.

예를 들어, photo.gif(버전ID : 111111) , photo.gif(버전ID : 121212)와 같이 하나의 버킷에서 키값은 동일하지만 버전 ID가 다른 두 개의 객체를 보유할 수 있게 된다.

이번에는 파일을 수정할때의 동작을 알아보자.

버전 관리를 사용하는 버킷에 객체를 PUT(REST API의 수정 동작 명령)할 때 파일을 덮어쓰지 않는다.

다음 그림처럼, 동일한 이름의 객체를 이미 보유하고 있는 버킷에 새 버전의 photo.gif를 PUT할 때 원래 객체(ID = 111111)는 버킷에 계속 남아 있으며 S3가 새 버전 ID(121212)를 만들어 버킷에 추가해 위로 올리게 된다. (맨 위에 올려진게 최신 데이터로 인식)

이 기능으로 실수로 객체를 덮어쓰거나 삭제하는 것을 방지하고, 객체의 이전 버전을 검색할 수 있는 것이다.

마찬가지로 객체를 DELETE하면, 다음 그림과 같이 버킷에 삭제 마커(Delete Marker)를 삽입을 하게 된다.

파일을 삭제 한것이 아니다. 삭제 마커를 최상단에 올림으로서 마치 파일이 삭제된것처럼 효과를 주는 것이다.

따라서 DELETE를 수행해도 파일의 전체적인 버전 정보를 유지시키게 된다.

만일 버전 관리되는 객체를 영구적으로 삭제하려면 버젼 ID 자체를 DELETE 해야 한다.

기본적으로 GET 요청은 가장 최근에 저장된 버전을 검색한다.

그런데 최신 버전이 삭제 마커일 때 간단한 GET Object 요청을 수행하면 다음 그림과 같이 404 Not Found 오류가 반환된다. (삭제된 파일이니까 정상 동작이다)

이때 버전 ID를 지정하여 특정 객체에 대해 GET을 실행할 수 있다. (특정 객체 버전인 111111을 GET)

S3 보안 / 권한 (접근 제어)

S3는 전세계에서 접속할 수 있는 스토리지 서비스 이다. 따라서 어느 누가 접속해 내용물을 변조할수 있기때문에 S3의 버킷의 기본 정책은 public이 아닌 private로 설정 되어있다.

하지만 만일 외부에서 접속해 S3의 버킷을 제어할 필요가 있다면 어떻게 할까?

이때는 버킷을 통째로 public으로 개방하는 것이 아닌 S3 권한 제어을 통해 접근 제어를 설정 할 수 있다.

S3 권한 설정에는 대표적으로 4가지가 있는데,

사용자를 생성하고 사용자의 버킷 권한 액세스를 관리하는 IAM
권한 있는 사용자에 대해 간단한 개별 객체(오브젝트)를 액세스 가능하게 만드는 액세스 제어 목록(ACL)
단일 S3 버킷 내 모든 객체에 대한 권한을 세부적으로 구성하는 버킷 정책(bocket policy)
임시 URL을 사용하여 다른 사용자에게 기간 제한(임시 권한) 액세스를 부여하는 쿼리 문자열 인증(pre-signed URL)

등의 액세스 관리 기능을 조합하여 사용함으로써 다른 사용자에게 액세스 권한을 부여할 수 있다.

항목	버킷 정책	ACL	IAM 제어
AWS 계정 단위 제어	○	○	X
IAM 사용자 단위 제어	△	X	○
S3 버킷 단위 제어	○	○	○
S3 객체 단위 제어	○	○	○
IP 주소/도메인 단위 제어	○	X	○

버킷 정책은 버킷 단위로 접근 제어를 확정하고 이후에 변경이 적을 때, ACL은 객체 단위로 접근 제어할 때, IAM 제어는 사용자 단위로 접근 제어할 때 사용하는 것이 일반적이다.

지금 부터 각 S3 권한에 대해 알아보자.

Public Access

퍼블릭 액세스 권한은 말 그대로 모두에게 액세스 권한을 오픈할 것인지 아니면 임의의 사용자에게는 접근 권한을 제한할 것인지 설정하는 것이다.

옵션을 보면 4가지가 있는데 특수한 경우에 대해 퍼블릭 액세스가 허용되는 경우을 각각 설정할 수 있다.

단, 최상위의 모든 퍼블릭 엑세스 차단을 설정 할 경우 어떤 경우이든 모두 접속을 차단하게 된다.

각자 필요한 경우에 대한 퍼블릭 제한을 오픈하고 사용하면 된다.

Tip

실무에서 사용할 경우에는 모든 액세스 차단 혹은 ACL을 이용하여 액세스 차단해주는 것이 보안을 위해 좋다.

ACL (Access Control List)

ACL은 버킷이나 객체에 대해 요청자의 권한 허용 범위를 어디까지 설정할 것인가에 대해 간단하게 설정할 수 있다.

여기서 요청자는 일반 퍼블릭한 사용자가 될 수도 있고, 계정의 owner나 resouce group, 특정 사용자가 될 수 있다.

버켓 주인과 오브젝트 주인이 다를 경우의 권한 설정, log 저장용 버킷에 대한 권한 설정 등을 설정 할 수 있다.

그리고 각각의 버킷과 그 속에 포함된 객체는 ACL과 연동된다. 따라서 ACL로 S3 버킷이나 객체의 접근을 제어하는게 가능하다.

ACL은 IAM이나 버킷 정책에 비해 더 넓은 범위에서 제어할 수 있지만, 단지 접근 승인을 한 곳과 접근 승인을 받은 곳으로만 나타낼 수 잇다. (간단한 것만 설정 가능)

버킷 정책(Bucket Policy)

Bucket Policy는 버킷을 사용할 권한을 가진 여러 명의 사용자 별로 각각의 행위에 대한 권한 범위를 설정할 수 있다.

예를 들어 누군가는 읽기만 가능하고 누군가는 읽기, 쓰기 모두 가능한 상태 같이 말이다.

즉, Bucket에 대한 전반적인 권한 설정은 Bucket Policy를 통해 설정된다.

단, 버킷 안의 파일 하나하나의 권한 설정은 불가능하다.

Info

ACL과 Bucket Policy 차이ACL이나 버킷 정책이나 둘다 버킷에 대한 엑세스를 제한하거나 허용하는 권한 설정이다.버킷정책은 버킷에대해서만 권한을 설정할 수 있지만, ACL은 버킷 뿐만 아니라 개별 객체에도 가능하다.버킷정책은 JSON을 통해 세분화된 권한을 설정할 수 있지만, ACL은 버킷 정책만큼 세분화된 엑세스 모드를 제공하지 않는다.

Bucket Policy는 JSON 형식으로 이루어져 있다.

{
    "Version": "2012-10-17", // Bucket Policy의 문법이 언제 날짜 기준으로 확정된 문법을 사용하는지 → 2008-10-17 버전 후 2012-10-17 버전이 있는데, 그 뒤로는 업데이트가 안됐음
    "Id": "S3PolicyId1", // Bucket Policy의 고유 아이디, 자동으로 부여되는 경우가 많음
    "Statement": [
        {
            "Sid": "IPAllow", // 각 Statement의 고유 아이디. 무슨 역할을 하는 policy인가
            "Effect": "Allow", // 버킷에 대한 명령을 허락(allow)하거나 거부(deny). 특정 사용자에 대해 명령을 제한하거나, 허용하는 식으로 사용
            "Principal": {"AWS": "arn:aws:iam::spark323:user/spark"}, // Bucket Policy의 적용대상 (spark323 아이디의 유저에 대해서)
            "Action": [ // Bucket Policy에서 허용한 Action
                "s3:GetObject", // 객체 가져오는 행동
                "s3:GetBucketLocation", // 버켓 위치를 확인하는 행동
                "s3:ListBucket", // 버켓 리스트를 확인하는 행동
            ],
            "Resource": "arn:aws:s3:::bucketname/*", // 대상이 대는 Bucket에 대한 명세
            "Condition": { // 어떤 조건 하에
                "NotIpAddress": { // 이 IP비허용
                    "aws:SourceIp": "1.1.1.1/32"
                },
                "IpAddress": { // 이 IP허용
                    "aws:SourceIp": [
                        "192.168.1.1",
                        "192.168.1.2/32",
                    ]
                }
            }
        }
    ]
}

보다 시피 굉장히 세세하게 키값을 정의해 권한을 설정해 주고 있다.

위의 JSON 권한 형식을 해석하자면, 계정 spark323 아이디인 유저에 대해서 Resource(해당버킷)에 대해 Action(객체를 가져오거나 버켓 위치를 확인하거나)을 Effect(허용) Condition(아이피 192.168.1.1, 192.168.1.2/32 인 하에) 한다는 말이다.

Tip

버킷 정책의 IAM 사용자 단위 제어는 IAM 사용자의 명칭과 일치하는 버킷만 사용할 수 있게 제한되어 있다.

따라서 IAM 사용자를 제어할 때는 IAM 정책을 사용하는 것이 좋다.

Access Log 전송 가능

Access Log란 버킷의 모든 파일들에 대한 접근 기록을 말한다.

이 접근 기록을 다른 S3 버킷 혹은 다른 계정으로도 전송 가능하다.

MFA(이중 인증)를 활용해 삭제 방지 기능

AWS 계정 생성할때 설정 했던 이중 인증 옵션이다.

간단히 말하면 파일 지울때 보안 토큰 입력하라는 방지책이다.

S3 요금 정책

S3는 사용한 만큼만 요금을 지불한다.

요금 자체가 저렴한 편이라서 로그 등을 저장해두는 용도로 많이 사용한다.

S3 Glacier 같은 장기 보관용 등급의 경우 storage 저장 비용은 정말 저렴하지만 데이터를 꺼낼때 요금이 굉장히 세다.

동일한 리전의 EC2와는 데이터 전송 요금이 발생하지 않으므로 S3와 EC2의 리전은 동일하게 설계한다.

유형	정책
스토리지 요금	객체 저장 비용(객체크기, 해당 월에 객체 저장한 기간, 스토리지 클래스에 따라 다름)
요청 및 데이터 검색	GET, LIST 및 기타 요청에 대한 비용 발생(DELETE 및 CANCEL 요청은 무료)
데이터 전송	특정 케이스를 제외하고 모든 송수신 대역폭에 대해 요금 지불인터넷에서 전송된 데이터, 동일한 리전의 EC2 인스턴스로 전송된 데이터, CloudFront로 전송된 데이터

S3 버킷 생성하기

버킷 만들기

이 버킷의 퍼블릭 액세스를 차단한다는 것은 외부에서도 파일을 읽게 하지 못한다는 의미다.

퍼블릭 액세스를 경우에 따라 차단하고 싶다면, "모든 퍼블릭 액세스 차단"은 비활성화하고 세부적인 옵션을 선택하면 된다.

새 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단→ 지정된 ACL이 퍼블릭이거나, 요청에 퍼블릭 ACL이 포함되어 있으면 PUT 요청을 거절한다.
임의의 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단→ 버킷의 모든 퍼블릭 ACL과 그 안에 포함된 모든 Object를 무시하고, 퍼블릭 ACL를 포함하는 PUT 요청은 허용한다.
새 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단→ 지정된 버킷 정책이 퍼블릭이면 PUT 요청을 거절한다. 이 설정을 체크하면 버킷 및 객체에 대한 퍼블릭 액세스를 차단하고 사용자가 버킷 정책을 관리할 수 있으며, 이 설정 활성화는 기존 버킷 정책에 영향을 주지 않는다.
임의의 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단→ 퍼블릭 정책이 있는 버킷에 대한 액세스가 권한이 있는 사용자와 AWS 서비스로만 제한되며, 이 설정 활성화는 기존 버킷 정책에 영향을 주지 않는다.

Info

만일 버킷을 비공개로, 나만 보고 싶다면 모든 옵션에 체크한다.

퍼블릭 액세스가 차단되었을 경우 IAM에서 AWSAccessKeyId와 AWSSecretKey를 발급받고 이를 이용해서 S3 객체에 접근할 수 있다.

Tip

실무에서 사용할 경우에는 모든 액세스 차단 혹은 ACL을 이용하여 액세스 차단해주는 것이 보안을 위해 좋다.

Info

버킷 버전 관리기능을 활성화하면 파일을 버전별로 관리 하기 때문에 비용이 더 들게 된다.

대신 사용자가 실수로 파일을 삭제해도 복원할 수 있다.

태그는 서비스를 하다가 버킷이 많아지면, 버킷들을 그룹화 시키는 것이다.

서비스 운영에 따라 사용하는 방법이 달라지는데, 특정 버킷을 태깅해놓고 이후에 비용 측정이라던지 많은 버킷중에 태그로 검색을 한다던지 할때 쓰이게 된다.

기본 암호화를 활성화 하면 버킷에 저장되는 모든 새 객체를 암호화해서 저장 한다.

그리고 객체를 다운 로드할 때 암호를 복호화해서 제공해준다.

단지 우리는 파일 업로드가 잘 되는지 테스트를 해야하기 때문에 비활성화 해두자.

고급 설정은 보안과 관련된 내용이다

버킷에 파일 업로드 하기

버킷에 폴더 생성

버킷의 [객체] 메뉴로 들어오면, 폴더를 생성하거나 객체를 업로드할 수 있다.

폴더의 객체에 액세스할 때 URL을 사용할 것이기 때문에, 폴더 이름에는 '/'를 포함할 수 없다.

폴더를 생성하게되면, 버킷 경로는 다음과 같이 된다.

s3://버킷명/폴더명/

s3://tistory-test-bucket-01/test1/

이제 폴더내에서 객체(파일)을 업로드해 관리하면 보다 효율적으로 스토리지를 구성할 수 있게 된다.

버킷에 파일 업로드

생성한 버킷/폴더에 이미지 파일을 업로드 해보자.

Info

S3는 파일 드래그 앤 드롭 방식도 지원한다.

[파일 추가]는 폴더가 아닌 일반 파일을 추가하는 용도이고, [폴더 추가]는 폴더째로 추가하는 용도이다.

하단에, 업로드할 파일들에 대하여 스토리지 클래스를 설정할 수 있는데, 스토리지 용도에 따라 기간과 요금 등을 잘 고려하여 선택하면 된다.

모든 설정을 마치고 [업로드]를 다시 한 번 누르면 업로드가 시작된다.

S3 버킷을 만들때 분명 퍼블릭으로 설정하여 만들었지만, 이상하게 객체 접근이 Access Denied가 뜬다.

앞서 생성한 S3 버킷을 보면 객체를 퍼블릭으로 설정할 수 있음 메세지가 있는 것을 확인할 수 있다.

이는 아직 퍼블릭으로 설정되지 않았다는 뜻이며 외부에서 접근할 수 없다는 것을 의미한다.

따라서 외부에서 해당 버킷에 접근 가능하도록 하기 위해서는 버킷 정책을 수정해야 한다.

버킷 정책 설정하기

버킷 정책은 JSON으로 이루어진 데이터이다.

다음 사이트에서 버킷 정책을 손쉽에 생성할 수 있다.

AWS Policy Generator

JSON

{
  "Id": "Policy1649421058532", // 정책 ID
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1649420985040", 
      "Action": [ // 버킷에 수행할 액션(행동)
        "s3:GetObject", // 객체 가져오기
        "s3:PutObject" // 객체 업로드하기
      ],
      "Effect": "Allow", // 정책 적용
      "Resource": "arn:aws:s3:::tistory-test-bucket-01/*", // 어떤 버킷에 어떤 리소스에 적용? tistory-test-bucket-01 버킷에 있는 모든 리소스(객체)
      "Principal": "*" // 정책 적용 대상 모두
    }
  ]
}

Tip

위의 JSON을 정리하자면,

모든 대상(Principal)에 대해서, tistory-test-bucket-01 버킷에 있는 모든 파일(Resource)에 대한, 객체 가져오기, 객체 업로드 하는 특정 행동(Action)을 허용(Effect) 한다는 뜻이다.

버킷 메뉴로 들어가서 버킷 정책 편집을 클릭해 준다.

그리고 정책이 명시된 JSON 값을 복사 한 뒤 버킷 정책에 입력해주고 변경사항 저장 버튼을 눌러준다.

버킷이 완전히 퍼블릭으로 설정되었다.

이제 다시 업로드했던 이미지 버킷 url로 브라우저에 접속을 해보면, 정상적으로 사진이 보이게 될 것이다.

버킷 ACL 설정하기

위에서 버킷 정책 JSON을 생성해 접근 권한을 설정 해줬지만,

버킷 정책 JSON 설정이 복잡하다면, 보다 간편하게 ACL 메뉴를 통해 S3 버킷 접근 제어를 할수 있다.

버킷 접근 제어 3가지 방법

항목	버킷 정책	ACL	IAM 제어
AWS 계정 단위 제어	○	○	X
IAM 사용자 단위 제어	△	X	○
S3 버킷 단위 제어	○	○	○
S3 객체 단위 제어	○	○	○
IP 주소/도메인 단위 제어	○	X	○

위 표에서 볼 수 있듯이 버킷에 접근을 제어하는 방법은 3가지 정도 존재한다.

IAM 제어는 말 그대로, IAM 계정에 S3 접근 권한(policy)를 설정해 사용자 단위로 엑세스를 제어하는 것이고,

바로 위에서 배운 버킷 정책은 버킷 단위로 상세한 접근 제어를 확정하고 이후에 변경이 적을 때,

ACL은 객체 단위로 간단하게 접근 제어할 때, 사용하는 것이 일반적이다.

Info

접근정책(ACL)과 버킷정책(Bucket Policy) 선택사용 권한이 비슷한 오브젝트를 고유한 버킷으로 구성할 수 있다면 버킷정책(Bucket Policy)을 사용하는 것을 권장되는 편이다.단, 이러한 방식으로 개별 객체를 구성할 수 없는 경우에는 접근정책(ACL)을 이용해도 된다.그러나 접근정책(ACL)은 버킷정책을 통해 사용할 수 있는 권한보다 세부적인 제어를 제공하지 않는다.읽기 및 쓰기 엑세스 권한 이외의 세부 권한을 찾고 있는 경우 접근정책(ACL)을 통해 버킷정책(Bucket Policy)을 선택하여 구성이 가능하다.단, 버킷정책은 파일형태로 만들어 버킷에 적용하며 이 파일은 20KB를 초과할 수 없다.

Tip

※ 참고

접근정책(ACL)과 버킷정책(Bucket Policy)은 동시에 사용할 수 있다.

이 경우 오브젝트 저장소 리소스에 대한 엑세스를 제한하는 모든 규칙은 엑세스 권한을 부여하는 규칙을 재정의한다.

예를 들어 접근정책(ACL)이 버킷에 대한 사용자 엑세스를 허용하지만, 버킷정책(Bucket Policy)이 해당 사용자 엑세스를 거부하는 경우 사용자는 해당 버킷에 접근할 수 없다.

버킷 ACL 설정하기

만일 ACL로 원하는 파일을 퍼블릭으로 만들기 위한 절차를 소개한다.

우선 버킷 메뉴에 들어가 권한 탭을 클릭하고 밑으로 쭉 내려본다.

버킷을 퍼블릭으로 설정했으면, 각 파일에 대해서도 퍼블릭으로 설정해주어야 한다.

파일을 처음 업로드할때 밑의 ACL 메뉴에서 파일에 대한 접근 권한을 설정해줄 수 있고,

이미 업로드된 객체일 경우, 작업 메뉴에서 파일을 ACL을 통해 퍼블릭으로 지정하면 된다.

이렇게 버킷 정책 없이, 파일을 업로드할 때 acl을 붙이면 정상적으로 퍼블릭 읽기가 된다.

버킷 파일 공유

일반적인 객체(파일) 공유는 URL을 그대로 복사해서 제공해주면 된다.

하지만 만일 버킷이 보안을 위해 퍼블릭 설정이 안되어있을때,

public에서 접근해서 object를 다운받거나 업로드 해야 하는 경우, 버킷 자체를 public으로 열기엔 부담스럽고, 그렇다고 pulblic에 있는 사용자에게 S3 접근권한을 일일히 부여하기도 번거로울 때 사용할 수 있는게 pre-signed url(임시 권한)이다.

pre-signed URL 공유하기

pre-signed url은 임시자격증명서 라고도 하며, S3 접근을 위한 임시 url로 일정 시간이 지나면 만료되면 public 접근이 불가능해진다.

버킷 삭제하기

계속 버킷을 놔두면 과금될 수 있으니 필요할 때만 설정해두고 사용하지 않을 때는 삭제해두는 것이 좋다.

버킷을 삭제할 때는 일단 안에 들어있는 모든 파일을 삭제해야 한다.

파일을 다 삭제했으면 버킷 탭에서 삭제할 수 있다.

참조

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-S3-%EB%B2%84%ED%82%B7-%EC%83%9D%EC%84%B1-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%8B%A4%EC%A0%84-%EA%B5%AC%EC%B6%95
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/Welcome.html

문한성

기록하고 공유하려고 노력하는 DevOps 엔지니어

이전 포스트

ECS private subnet에 배포하기

다음 포스트

S3 개념 & 버킷

부트캠프

S3 (Simple Storage Service) 개념

S3을 사용하는 이유

S3 버킷 / 객체 개념

S3 리전(Region) 구성

S3 버킷(bucket) 구성

S3 객체(Object) 구성

S3 버저닝 (Versioning)

객체 버전 ID 수정 / 삭제 / 조회 동작

S3 보안 / 권한 (접근 제어)

Public Access

ACL (Access Control List)

버킷 정책(Bucket Policy)

Access Log 전송 가능

MFA(이중 인증)를 활용해 삭제 방지 기능

S3 요금 정책

S3 버킷 생성하기

버킷 만들기

버킷에 파일 업로드 하기

버킷에 폴더 생성

버킷에 파일 업로드

버킷 정책 설정하기

버킷 ACL 설정하기

버킷 접근 제어 3가지 방법

버킷 ACL 설정하기

버킷 파일 공유

pre-signed URL 공유하기

버킷 삭제하기

참조

ECS private subnet에 배포하기

EC2 개념 원리

0개의 댓글