오늘은 AWS Storage Service 중 하나인 S3에 대해서 얘기를 해보려고 합니다. 개인적으로 EC2 다음으로 제가 많이 사용하고 있는 서비스입니다. S3를 이용하여 정적파일 웹 호스팅도 가능하고 load balancer 액세스 로그로 저장 가능하고 AWS cloudformation의 템플릿도 저장하는 등 많은 서비스들과 연동하여 사용할 수도 있습니다.
S3의 특징을 간단히 얘기해보고 S3 활용하는 법에 대해서 얘기해 보겠습니다.
S3 (Simple Storage Service)
- 업계 최고의 확장성, 데이터 가용성 및 보안과 성능을 제공하는 Object Storage Service
- 99.9999999%의 내구성을 제공하도록 설계
- 간편하게 데이터를 관리할 수 있고 액세스 제어 가능
- Lambda, CloudFront, ELB, CloudFormation등 여러 서비스와 연동하여 사용 가능
- 정적 웹 호스팅 가능
[S3 실습] S3 버킷 생성해보기
AWS console 창에서 스토리지 서비스인 S3에 들어갑니다.
S3 서비스에 들어가서 버킷 만들기를 클릭합니다. 버킷은 S3에 저장되는 데이터의 컨테이너입니다. 쉽게 생각하면 하나의 데이터 저장소라고 생각하면 됩니다.
버킷 이름을 원하는 이름으로 만들고 S3를 만들고 싶은 리전을 선택해 줍니다. 밑에 버킷의 퍼블릭 액세스 차단 같은 경우는 나중에 밑에서 하나씩 얘기해보겠습니다.
버킷 버전 관리를 할 것인지 안할 것인지 선택하고 태그와 객체에 암호화를 할 것인지 선택합니다. 고급 설정에는 객체 잠금을 활성화할 것인지 비활성화 할것인지에 대한 선택이 있습니다. 지금 실습에서는 간단하게 S3 버킷을 생성할 것이기에 기본 세팅 그대로 바꾸지 않고 버킷을 만들어 줍니다.
버킷이 생성이 되었으면 해당 버킷을 클릭하여 안으로 들어가봅니다. 다음과 같은 구조를 볼 수 있습니다. 객체 부분에서는 파일을 업로드 하거나 폴더를 업로드 할 수 있고 폴더를 만들어서 해당 폴더 안에 파일을 업로드 할 수 있습니다.
S3의 권한에 대해서 얘기를 해보겠습니다. 권한을 클릭하면 다음과 같이 나옵니다. 권한 개요에 버킷 및 객체가 퍼블릭 여부에 대해 나오고 퍼블릭 액세스 차단(버킷 설정)에 대한 정보가 나옵니다. 퍼블릭 액세스 차단 기능은 액세스 포인트, 버킷 및 계정에 대한 설정을 제공하여 S3 리소스에 대한 퍼블릭 액세스를 관리하는데 도움을 줍니다. 기본적으로는 모든 퍼블릭 액세스 차단을 활성화합니다. 퍼블릭 액세스 차단 설정이 제공하는 4가지 설정에 대해 더 자세히 알아보겠습니다.
- 새 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단
- 새로 추가된 버킷 또는 객체에 적용되는 퍼블릭 액세스 권한을 차단하며, 기존 버킷 및 객체에 대한 새 퍼플릭 액세스 ACL 생성을 금지합니다. 이미 적용되고 있는 ACL의 경우 기존 권한을 유지하지만, 이 설정이 활성화 되어 있는 경우 새롭게 ACL 생성을 할 수 없습니다.
- 임의의 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단
- 버킷 및 객체에 대한 퍼블릭 액세스를 부여하는 모든 ACL을 무시합니다. 새롭게 ACL을 생성할 수도 없고 기존에 부여한 ACL도 무시합니다.
- 새 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단
- 버킷 및 객체에 대한 퍼블릭 액세스를 부여하는 새 버킷 및 액세스 지점 정책을 차단합니다. 이 설정은 S3 리소스에 대한 퍼블릭 액세스를 허용하는 기존 정책을 변경하지 않습니다.
- 임의의 퍼블릭 버킷 또는 액세스 지점 정책을 통해 부여된 버킷 및 객체에 대한 퍼블릭 및 교차 계정 액세스 차단
- 버킷 및 객체에 대한 퍼블릭 액세스를 부여하는 정책을 사용하는 버킷 또는 액세스 지점에 대한 퍼블릭 및 교차 계정 액세스를 무시합니다.
위의 4가지 설정 중 3번째와 4번째를 보면 퍼블릭 버킷이라는 용어가 있습니다. 저도 어떤 경우에는 버킷을 수정할 수 있고 어떤 경우에서는 버킷을 수정하면 access denied라는 오류가 떴습니다. 퍼블릭이라는 용어의 의미를 알아야 합니다. 퍼블릭 버킷이라고 하면 특정 유저에게만 권한이 있거나 특정 조건(ip 등등)일 때만 권한을 주는 것이 아니라 모든 사람들에게 권한을 주었을 때를 말합니다. 자세한 정보를 알고 싶으면 AWS S3 퍼블릭의 의미 파트를 확인해보면 됩니다.
다음은 버킷 정책입니다. 버킷 정책 부분에서는 버킷 정책을 작성하여 버킷에 저장된 객체에 대한 액세스 권한을 제공합니다. 편집을 눌러서 버킷 정책을 작성하는 법을 알아보겠습니다.
버킷 정책 편집에 들어오면 버킷에 대한 정책을 생성할 수 있습니다. 정책 예제를 클릭하여 자신에게 필요한 정책을 볼 수 있습니다. 또한 정책 생성기를 눌러서 정책을 직접 만들어 줄 수 있습니다.
버킷 정책을 생성하는 페이지를 누르면 AWS 정책 생성기 페이지가 보입니다. S3 bucket 정책뿐만 아니라 IAM 정책, SQS, SNS 정책 등 여러 정책을 생성 할 수 있습니다. 저희는 S3 정책을 만들것이기에 S3 bucket policy를 선택합니다. 두 번째 Step을 보면 Effect라고 보이는데 이 설정은 등록할 action을 금지 시키는 것인지 하게 하는것인지를 선택하는 것입니다. 다음으로는 Principal이라고 보이는데 여기에는 자신의 계정을 입력하면 됩니다. 계정이라 하면 아이디인지 닉네임인지 헷갈릴 수 있습니다. aws 오른쪽 위를 보면 종 모양 옆에 자신의 닉네임이 있는데 이 닉네임을 클릭하면 내 계정이라고 나오고 옆에 숫자가 있습니다. 이 숫자를 기입하면 됩니다. action 설정은 자신이 원하는 action을 선택하면 됩니다. ARN 부분에는 이 사진 바로 위 사진을 보면 버컷 ARN을 볼 수 있습니다. 이 내용을 가져다가 기입하면 됩니다. 다 기입을 했으면 Add Statement 버튼을 클릭해 줍니다.
Add Statement 버튼을 누르면 다음과 같이 statement가 생성이 된것을 볼 수 있습니다. 다른 action도 생성을 하고 싶으면 필요한 만큼 계속 추가를 해줍니다. 원하는 statement를 다 만들었으면 Generate Policy 버튼을 클릭하여 정책을 생성해 줍니다.
정책을 생성하면 밑에와 같이 JSON 형태로 만들어진 정책이 보입니다. 이 정책을 복사하여 버킷 정책에 붙여넣기를 하면 됩니다. 그런 후에 변경 사항 저장을 클릭하여 버킷 정책을 저장해주면 됩니다. 만든 버킷 정책의 내용에 따라 버킷이 저장이 될 수도 있고 access denied라는 오류가 나올 수도 있습니다. 위에서 말한 것처럼 access denied가 나오면 퍼블릭 액세스 차단의 3번 4번 설정을 확인하거나 버킷 정책을 퍼블릭 버킷처럼 생성한 것이 아닌지 확인을 해주면 됩니다.
※ 버킷 정책을 복사하여 붙여 넣기하면 해당 resource를 못 찾는다는 오류가 나옵니다. 그 때 뒤에 접근을 허락하는 object를 명시해주거나 전부 다 정책 action을 허용해 줄 것이면 /*를 붙이면 됩니다.
ex) "Resource": "arn:aws:s3:::hanrabong/*"
다음은 ACL 편집하는 기능입니다. 기본적으로 버킷 소유자 많이 객체에 나열하고 쓸 수 있고 버킷 ACL을 읽고 쓸 수 있습니다. ACL을 편집하기 위해서는 퍼블릭 액세스 차단 설정의 첫번 째 옵션인 <새 ACL(액세스 제어 목록)을 통해 부여된 버킷 및 객체에 대한 퍼블릭 액세스 차단>을 비활성화 해줘야 합니다. 첫 번째 옵셥을 비활성화해야 새롭게 권한을 부여해줄 수 있습니다. 비활성화 하지 않으면 Access Denied라는 오류가 나옵니다. 또한 권한을 부여하고 이 권한을 유지하기 위해서는 2번 째 옵션을 비활성화해야 합니다. 조금 복잡할 수도 있지만 간단하게 말하자면 첫 번째 권한은 새로운 ACL을 생성해준다고 생각을 하면 되고 두 번째 권한은 만든 ACL을 사용하기 위해 필요하다고 생각을 하면 됩니다.
다음은 CORS에 대한 정책을 생성하는 부분입니다. 이 부분은 S3를 이용하여 웹 호스팅을 보여줄 때 자세하게 설명하겠습니다.
마지막으로, S3에 권한을 줄 수 있는 방법에 대해 간략하게 정리하고 비교를 해보겠습니다. 제가 생각하기에는 크게 IAM policy(user, role), S3 Bucket policy, S3 Bucket ACL이 있습니다.
IAM Policy | Bucket Policy | Bucket ACL | |
AWS 권고 | 사용 가능하면 IAM Policy를 사용 | IAM과 비교해서 좀 더 단순하게 적용시킬 때 사용 | 예전에 S3 bucket을 관리했던 방식으로 권한 관리에 한계가 있어 추천하는 방식은 아님 |
Environment | AWS에 대한 모든 권한을 중앙 집중식으로 관리 한다. | S3 환경에만 제한 | S3 환경에만 제한 |
사용 범위 | AWS service/resource에게 권한을 부여할 수 있다. | S3에서만 사용 가능 | S3에서만 사용 가능 |
사용의 편의성 | 사용자가 늘어나도 그 사용자에게 권한을 주기만 하면 된다. 유지하기 쉽다. | 정책을 생성하기는 쉽지만, 사용자가 많아지고 사용자의 권한을 바꿔야 할 때 유지하기 어렵다. 한 명이 s3에 대한 권한을 더 필요로 할 때 모든 버킷에 대한 권한을 수정해야 한다. | 사용자가 많아지고 사용자의 권한을 바꿔야 할 때 유지하기 어렵다. |
control level | root level의 버킷에만 가능하다. | 버킷 뿐만 아니라 객체 단위로도 가능 | 버킷 뿐만 아니라 객체 단위로도 가능 |
오늘 S3에 대해 간략하게 이야기를 해보았고 권한 부여에 대해서 얘기를 해보았습니다. S3에 권한을 부여해주는 여러가지 방법이 있습니다. 자신이 필요로 하는 서비스에 맞게 권한을 부여해주면 될꺼 같습니다. 많은 블로그와 스스로 해보면서 정리를 한 내용이지만 미흡한 내용도 많기에 참고용으로만 보면 될꺼 같습니다!!! S3 web hosting과 CloudFront와 연동 ALB access log등 내용을 얘기해보려고 했는데 내용이 너무 많아 다음에 다루겠습니다
※ 혼자 공부하며 정리한 내용이니 잘못된 내용이 있거나 궁금한 내용이 있으면 언제든 댓글 달아주세요!!
참고 자료
http://analyticshut.com/iam-policies-vs-s3-policies-vs-bucket-acls/
'AWS' 카테고리의 다른 글
[AWS] EC2 ssh port 변경하기 (2) | 2022.01.19 |
---|---|
[AWS] Public Subnet, Private Subnet, ALB, ASG 를 이용한 서버 아키텍쳐 구축(2) - AutoScaling Group 만들기 (0) | 2022.01.15 |
[AWS Run Command]Run Command로 원격으로 명령어 실행하기 (0) | 2021.08.20 |
[AWS] Public Subnet, Private Subnet, ALB, ASG 를 이용한 서버 아키텍쳐 구축(1) - VPC 구축하기 (0) | 2021.08.20 |
[AWS Session Manager] SSH 없이 Session manager로 EC2 instance에 접속 하기 (0) | 2021.08.18 |