Amazon S3 ( Simple Storage Service)

쿡쿡·2023년 6월 22일
0

AWS

목록 보기
1/7

📌 S3 버킷 생성

확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스.

S3 생성 시 글로벌로 잡혀, 리전에 종속적이라는 사실을 놓칠 수 있다.


S3 생성 두번째 항목이 리전인 것을 볼 수 있다.


ACL 활성화를 하면 다른 AWS 계정에서도 소유권을 가지거나 접속제어가 가능해진다.

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

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


퍼블릭 엑세스 차단 설정은 외부에서도 파일을 읽을 수 있다, 없다의 의미다.

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

버킷 버전 관리를 활성화 하면 파일을 버전별로 관리한다. 해서 비용이 더 들게 된다.
하지만 실수로 파일을 삭제해도 복원할 수 있다.

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


태그는 버킷이 많아지면 버킷을 그룹화 시킬 수 있다. 태그로 버킷을 검색할 수 있다.


기본 암호화를 활성화 하면 버킷에 저장되는 모든 새 객체를 암호화해서 저장 한다. 그리고 객체를 다운 로드할 때 암호를 복호화해서 제공해준다.


버킷정책은 버킷을 사용할 권한을 가진 여러 명의 사용자 별로 각각의 행위에 대한 권한 범위를 설정할 수 있다. 버킷에 대한 전반적인 권한 설정은 버킷 정책를 통해 설정된다.

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

<< 정책생성기 링크 >>

{
    "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",
                    ]
                }
            }
        }
    ]
}

ACL과 Bucket Policy 차이

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




📌 S3 요금 정책

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

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

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

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




📌 S3을 사용하는 이유

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



📌 S3 리전(Region) 구성

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



📌 S3 버킷(bucket) 구성

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

  • 버킷을 생성하면 default로 private상태이다.
  • 버킷 소유권은 이전할 수 없다.
  • 버킷 안에 다른 버킷을 둘 수 없다.



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

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

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

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

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



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

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

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



📌 버킷 파일 공유

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

profile
https://www.notion.so/Devops-89178b1cd6694d35810201f129641db1

0개의 댓글