April 15, 2023 8 min to read

AWS #2 / TIL

S3 / RDS

S3(Simple Storage Service)

AWS에서 제공하는 *클라우드 스토리지 서비스이다.
S3는 리전 위에 위치한 가용 영역(AZ)이 개별적 위치에 떨어져 존재하기 때문에, 한 곳의 AZ에서 가동이 불가 해져도 다른 가용 영역에서 백업 해 놓은 데이터를 활용해 문제 없이 서버가 가동된다. 따라서, AWS에서 제공하는 서비스들은 다음과 같은 이점들이 발생한다.

확장성이 높기 때문에 많은 시간과 수고를 들이지 않고 스토리지 규모를 확장 / 축소 할 수 있다.
스토리지 용량을 무한히 확장할 수 있다.
사용한 만큼만 비용을 지불하기 때문에 비용적 측면에서 효율적이다.
내구성이 엄청 강하기 때문에 파일을 잃어버릴 일이 없다.
가용성이 높기 때문에 파일들을 정상적으로 사용할 수 있는 시간이 길어진다.

클라우드 스토리지

인터넷 공간에 데이터를 저장하는 저장소
뛰어난 접근성을 가지고 있어 장소에 구애받지 않고 언제든 저장된 파일에 접근할 수 있다.

이 외에도 S3 사용 시 정적 웹 사이트 호스팅이 가능하다는 이점이 있다. *버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공한다. 버킷에 정적 파일을 업로드하고, 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있다.

버킷

객체를 저장하는 컨테이너 역할을 하는 최상위 디렉토리.

S3에 저장되는 모든 파일은 버킷 안에 저장되어야 하고, 버킷에는 무한히 많은 파일 저장이 가능하다.
한 버킷 내에 여러 폴더를 생성할 수도 있다.
버킷의 이름은 버킷이 속해 있는 리전(버킷이 생성된 지역)에서 유일해야 한다. 그래야 URL을 통해 해당 데이터에 접근할 수 있다.
버킷 정책을 생성하여 해당 버킷에 대한 다른 유저의 접근 권한을 수정할 수 있다.
버킷은 어느 리전에서나 생성할 수 있고, 명시적으로 복제 작업을 수행하지 않으면 한 다른 리전에 특정 버킷의 데이터가 복제되지 않는다.
S3 버킷은 버전 부여 기능을 제공하므로 객체가 버킷에 추가될 때마다 해당 객체에 유일한 ID가 할당된다.

객체

버킷에 저장된 모든 것. S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문에 객체라고 부른다.

객체는 파일과 메타데이터로 구성되며, 모든 객체는 고유한 키를 가진다.
파일은 키-값 페어 형식으로 데이터 저장를 저장하며, 파일의 키는 각 객체를 고유하게 만들어주는 식별자 역할을 하며, 키를 이용하여 원하는 객체를 검색할 수 있다.
메타데이터는 객체 생성일, 크기, 유형과 같은 객체에 대한 정보가 담긴 데이터이다.
URL 주소를 통해 객체에 접근이 가능하다.
URL 주소 형식 : http://[버킷 이름].S3.amazonaws.com/[객체의 키]

대표적인 스토리지 클래스

S3는 다양한 스토리지 클래스를 제공한다.

Standard Class : 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠르기 떄문에, 범용적인 목적으로 사용하기 좋다. 대신 데이터를 오래 보관하는 목적으로는 보관 비용이 높게 발생하기 때문에 효율적이지 않다.
Glacier : 저장된 데이터에 액세스하는 속도는 느리지만, 데이터 보관 비용이 매우 저렴하다.
이 외의 Storage Class : Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등

접근성 통제

S3 버킷에 누가 어떻게 접근하도록 할 것인지 정의하는 것. 주로 JSON을 이용해 작성된 정책을 통해 이루어지며, 접근 정책, 버킷 정책, 접근 제어 목록 등의 방식을 사용한다.

정책을 만드는 JSON 파일의 구조

하나의 Statement에는 하나의 permission 정보가 포함된다. 정책에 포함된 다수의 statement는 논리합(Logical OR) 관계를 맺는다.

ID : 정책의 ID값. UUID를 사용하기를 권장한다.
SID : Statement ID로, statement를 구분하기 위해 사용한다.
Effect : 정책의 효과를 나타내며 허용, 거부 여부를 선택할 수 있다.
Principal : 대상 및 주체를 지정한다. (Users, Services 등)
Action : 정책을 통해 승인 혹은 거절할 동작을 의미한다.
Resource : Action이 영향을 미치는 리소스 리스트를 지정한다.
Condition : 조건이 충족되는 경우, 해당 정책을 적용시킬 수 있다.

접근 정책 (Identity-based policies)

IAM(신분 및 접근 관리 정책)으로 S3의 객체를 매우 세분화해 통제할 수 있다.

다음 예시를 보면서 알아보자. AWS 계정의 IAM 사용자에게 버킷 중 하나인 awxexamplebucket1에 대한 액세스 권한을 부여하고 이 사용자에게 객체를 추가, 업데이트, 삭제하도록 허용하려 한다.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource":"*"
    },
    {
      "Effect":"Allow",
      "Action":["s3:ListBucket","s3:GetBucketLocation"],
      "Resource":"arn:aws:s3:::awsexamplebucket1"
    },
    {
      "Effect":"Allow",
      "Action":[
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:DeleteObject"
      ],
      "Resource":"arn:aws:s3:::awsexamplebucket1/*"
    }
  ]
} 

위 예시에서는 하나의 정책에 총 3개의 statement가 삽입되었다. 이렇게 작성된 정책을 그룹, 유저 등에 할당하여 사용할 수 있다.

s3:PutObject, s3:GetObject, s3:DeleteObject 권한을 사용자에게 부여한다.
s3:ListAllMyBucket, s3:GetBucketLocation, s3:ListBucket 권한을 사용자에게 부여한다. (콘솔에 필요한 추가 권한)
s3:PubObjectAcl, s3:GetObjectAcl 작업을 하여, 콘솔에서 객체를 복사, 자르기, 붙여넣기를 할 수 있게 하였다.

버킷 정책 (Resource-based policies)

S3 버킷을 세분화된 방식으로 제어할 수 있도록 하는 버킷 레벨에서 생성한 정책을 의미한다.

대표적 버킷 정책 사례는 특정 버킷에 있는 객체에 대한 익명의 사용자로부터 리드 온리 접근을 허용하는 케이스이다. 이는 S3 리소스 기반의 정적 웹 사이트를 운영하거나, 웹을 통해 불특정 다수의 접근을 허용할 때 자주 사용되는 방법으로, 버킷에 GetObject 액세스 권한을 부여하면 된다.

다음 devopscodestates를 위한 S3 버킷 정책의 예시를 통해 알아보자.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"PublicRead",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::devopscodestates/*"]
    }
  ]
}

devopscodestates 버킷의 모든 리소스를 GetObject 작업으로 누구나 접근(“*“)할 수 있음을 Principal 필드의 값을 통해 확인할 수 있다.

S3의 보안 Best Practice

보통의 경우 S3 버킷에 대한 퍼블릭 액세스를 허용하서는 안된다. S3 버킷을 퍼블릭 액세스할 수 있다는 말은 모든 파일이 아무에게나 노출될 수 있다는 의미이다.
최소한의 접근 권한 전략을 사용한다. S3 버킷에 접근해야 하는 사람에게도 관련 작업에 해당하는 만큼만 권한을 부여하고, 그 외 사람에게는 접근 거부 정책을 적용한다.
다중인증 시스템(MultiFactor Authentication)을 활용한다. MFA Delete를 설정하여 데이터 삭제 권한이 없는 사람은 삭제할 수 없도록 제한한다.

» S3 스토리지 클래스 레퍼런스 «

EBS (Elastic Block Store)

EC2 인스턴스에 사용할 수 있는 블록 수준 영구 스토리지 볼륨. 영구 스토리지는 EC2 인스턴스의 수명 주기를 넘어서서 존재할 수 있는 스토리지를 의미한다.

EBS는 볼륨에 대한 특정 시점의 스냅샷을 지속적으로 작성해 S3에 저장하는 방식으로 다수의 AZ에서 자동 복제 기능을 제공한다. 이를 통해 생성된 스냅샷은 또 다른 EBS 볼륨 생성을 위한 시작점으로 활용될 수 있으며, 장기간 서버와 관련된 데이터를 안전하게 보호할 수 있다. 이 스냅샷은 리전 간 복제해서 사용할 수도 있으므로, 재난 복구, 데이터 센터 마이그레이션 등에도 편리하게 사용할 수 있다.

EBS 볼륨

형식이 지정되지 않은 원시 블록 디바이스처럼 동작한다.
인스턴스에 연결된 볼륨의 구성을 동적으로 변경할 수 있다.
EBS 볼륨은 EC2 인스턴스의 부트 파티션으로 이용될 수 있다. 이 때, EC2 인스턴스가 정지 후 재 시동 돼 해당 인스턴스 상태를 유지하기 위한 스토리 리소스로서의 기능만 담당하여 재시동 후에도 유지되므로, 기존에 저장된 내용은 그대로 남게 된다.
EC2 인스턴스에 EBS 볼륨을 부착하면, 서버를 위한 하드 드라이브와 같은 기능을 수행하게 된다.
하나의 EC2에 여러 개의 EBS 볼륨을 부착하면, 부트 볼륨과 데이터 볼륨을 별도로 관리할 수 있다.
EC2에 부착한 EBS 볼륨은 언제든 분리할 수 있고, 다른 EC2 부착도 가능하지만, EBS 볼륨은 특정 AZ에 속한 자원이기도 하므로, 서로 다른 AZ 간의 EC2에 EBS 볼륨을 분리하고 부착하는 것은 불가능하다.
EC2 인스턴스의 로컬 스토리지에 비해 훨씬 높은 수준의 견고성을 제공한다.

EFS (Elastic File System)

서버를 사용하지 않는 간단하고 탄력적인 파일 시스템을 빠르고 쉽게 구성할 수 있는 간편 웹 서비스 인터페이스를 제공하고, EC2 인스턴스에 파일 시스템을 탑재한 후 파일 시스템에 데이터를 작성하거나 파일 시스템에서 데이터를 읽을 수 있다.

이 서비스에서 모든 파일 스토리지 인프라를 관리해주므로, 사용자는 복잡한 파일 시스템 구성을 배포, 패치, 및 유지보수 하는데 따르는 복잡성에서 벗어날 수 있다.

애플리케이션을 중단하지 않고 온디맨드 방식으로 페타바이트 규모까지 확장되도록 구축되어, 사용자가 파일을 추가하고 제거할 때 자동으로 확장/축소되므로 데이터 증가에 맞춰 용량을 *프로비저닝 및 관리할 필요가 없다.

*DBMS : 데이터 저장, 조직화, 인출과 관련된 제반 업무를 관장하는 소프트웨어. RDB는 열과 행으로 이루어진 테이블에 저장되고, 테이블에 저장된 데이터는 공통 키 또는 컨셉에 따라 서로 관계를 유지하며, 테이블에서 데이터를 인출할 때 이와 같은 관계성을 이용한다는 측면에서 관계형 데이터베이스라는 이름이 붙었다.

EBS (Elastic Block Store)

EFS (Elastic File System)

RDS (Relational Database Service)

단어 정리

*정적 파일 : 서버의 개입 없이 클라이언트에 제공될 수 있는 파일

*웹 호스팅 : 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스

*프로비저닝 : 컴퓨터 시스템이나 네트워크에 필요한 자원, 서비스, 애플리케이션 등을 사전에 설정하거나 준비하는 과정

See also

Final Project

Project 4 #3 / TIL

Project 4 #2 / TIL

FairyCode v3.1.2

AWS #2 / TIL

S3(Simple Storage Service)

클라우드 스토리지

버킷

객체

대표적인 스토리지 클래스

접근성 통제

S3의 보안 Best Practice

AWS #3 / TIL