about me
20'S LIFE IN SYDNEY and BUSAN
AWS 스토리지 서비스는 다음과 같이 세 개의 카테고리
객체 스토리지(Object Storage)
여기서 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터을 포함하고 있는 데이터를 의미하며, 인터넷으로 연결된 API를 통해 데이터를 애플리케이션에 제공합니다.
블록 스토리지(Block Storage)
블록 스토리지에서 데이터는 서버 인스턴스에 디스크 볼륨의 형태로 제공되는 데이터를 의미합니다. 이를 통해 EC2 인스턴스에 포함된 볼륨에 고속으로 접근 가능합니다. 대표적인 서비스인 Elastic Block Store, EBS는 EC2 인스턴스를 위한 부트 볼륨 및 데이터베이스로 널리 사용됩니다.
파일 스토리지(File Storage)
파일 스토리지에서 데이터란 서버 인스턴스에 파일 시스템 인터페이스 방식으로 제공되는 데이터를 의미하며, 서버 인스턴스에 파일 스토리지를 추가하면 로컬 파일 시스템처럼 작동합니다. 대표적으로 Elastic File System, EFS는 고속으로 다수의 EC2 인스턴스를 통해 데이터에 접근할 수 있도록 합니다.
S3 (Simple Storage Service)
클라우드 스토리지
클라우드 스토리지란 쉽게 말해서 인터넷 공간에 데이터를 저장하는 저장소입니다.
컴퓨터 부품으로 비유하면 하드디스크의 역할을 하는 서비스입니다.
우리는 알게 모르게 클라우드 스토리지 서비스를 이용해왔습니다. 구글의 Google Drive, 네이버의 MYBOX, 마이크로소프트의 Onedrive와 같은 서비스가 좋은 예시입니다.
클라우드 스토리지 서비스의 장점
클라우드 스토리지 서비스는 뛰어난 접근성을 가지고 있습니다. 컴퓨터의 하드디스크에 저장된 파일에 접근하기 위해서는 해당 컴퓨터를 이용해야만 합니다.
그러나 클라우드 스토리지를 이용하면 웹 환경이라면 언제 어디서나 저장된 파일에 접근할 수 있습니다.
또한 컴퓨터뿐만 아니라 웹에 접속이 가능한 다른 전자기기를 활용하여 클라우드 스토리지에 저장된 데이터에 접속할 수 있습니다.
S3는 Simple Storage Service의 약자로 AWS에서 제공하는 클라우드 스토리지 서비스입니다.
S3도 마찬가지로 뛰어난 접근성을 가지고 있습니다. 뛰어난 접근성 외에도 S3 사용 시 얻을 수 있는 이점은 여러 가지입니다.
S3 사용 시 이점
강력한 내구성
스토리지의 내구성이 높으면 저장된 파일을 유실할 가능성이 적어집니다.
S3는 99.999999999%의 내구성을 보장합니다.
길을 걷다가 벼락을 맞을 확률(약 0.0000007%의 확률)이 S3에 저장된 파일을 잃어버릴 확률의 700배라는 점을 생각하시면 S3 스토리지의 내구성이 얼마나 대단한지 가늠이 되실 거라 생각합니다.
99.99%의 가용성 보장
가용성이 높으면 스토리지에 저장된 파일들을 정상적으로 사용할 수 있는 시간이 길어집니다.
S3는 연간 99.99%의 스토리지 가용성을 보장하도록 설계가 되어 있습니다.
이는 다른 말로 1년 동안 S3에 파일을 저장했을 시, 8.76 시간 동안만 스토리지를 이용하는 데 있어서 장애가 발생한다는 뜻입니다.
현재까지 EC2, RDS, S3의 개념을 학습하고 있는데, 해당 서비스들이 공통적으로 '높은 가용성'과 '높은 내구성'을 보장한다는 점을 배우셨을 겁니다.
AWS는 어떤 원리로 해당 서비스들의 높은 가용성과 내구성을 보장할 수 있는 걸까요?
첨부된 지도를 보시면 주황색 동그라미가 쳐진 지역이 있습니다. 이 지역을 '리전(Region)'이라고 부릅니다. 리전이란 AWS에서 클라우드 서비스를 제공하기 위해서 운영하는 물리적인 서버의 위치를 뜻합니다.
그리고 지도를 다시 보시면 주황색 동그라미 안에 숫자가 새겨져 있는데, 이 숫자는 리전에 위치한 가용 영역의 수를 뜻합니다. 가용 영역(Availability Zone)이란 각 리전 안에 존재하는 데이터 센터(IDC)를 뜻합니다.
가용 영역은 각각 개별적인 위치에 떨어져서 존재합니다.
그래서 한 곳의 가용 영역이 재난이나 사고로 인해 가동이 불가능해지더라도 다른 가용 영역에 백업을 해놓은 데이터를 활용하여 문제없이 서버가 가동되게 합니다.
이런 가동 방식 덕분에 AWS에서 제공하는 서비스들은 높은 가용성과 내구성을 보장합니다.
다양한 스토리지 클래스를 제공
Standard Class
가장 일반적으로 사용되는 스토리지 클래스
데이터에 자주 액세스해야 할 경우 사용
또 다른 특징으로 S3는 다양한 스토리지 클래스를 제공합니다.
저장소를 어떤 목적으로 활용할지에 따라 효율적으로 선택할 수 있는 스토리지 클래스가 달라집니다.
S3 사용자들이 대표적으로 많이 선택하는 스토리지 클래스는 두 가지가 있습니다.
Standard 클래스와 Glacier 클래스입니다.
Standard 클래스는 범용적인 목적으로 사용하기 좋습니다. 데이터에 빠른 속도로 접근할 수 있고, 데이터 액세스 요청에 대한 처리 속도가 빠릅니다. 대신 데이터를 오래 보관하는 목적으로는 효율적인 선택지가 아닙니다. 보관 비용이 높게 발생하기 때문입니다.
Glacier Class
데이터의 장기보관 목적
데이터를 보관하는 데 드는 비용이 저렴
장기적인 보관 목적으로 스토리지를 사용하실 때는 Glacier를 사용하는 것이 효율적입니다.
비록 저장된 데이터에 액세스하는 속도는 느리지만, 데이터를 보관하는 비용이 매우 저렴하다는 장점이 있습니다.
이 외에도 Standard-IA, One Zone-IA, S3 Glacier Deep Archive 등등 여러 가지 스토리지 클래스가 존재하여 사용자의 이용 목적에 따라 다양한 스토리지 클래스를 사용할 수 있습니다.
정적 웹 사이트 호스팅이 가능
정적 파일 : 서버의 개입 없이 클라이언트에 제공될 수 있는 파일
웹 호스팅 : 서버의 한 공간을 빌려주어 웹 사이트의 배포, 운영이 가능하게 만들어주는 서비스
S3에서는 버킷을 통해 정적 웹 사이트 호스팅이 가능 - 버킷이라는것은?
S3 사용 시 얻는 이점 중 하나로, 정적 웹 사이트 호스팅이 가능합니다.
정적 웹 사이트 호스팅이란 뭘까요? 차근차근 알아보도록 하겠습니다.
먼저 정적 웹 사이트 호스팅이 무엇인지 알기 위해 '정적' 파일에 대한 이해가 선행되어야 합니다.
정적 파일은 서버의 개입 없이 생성된 파일을 뜻합니다.
반대로 클라이언트가 서버에 요청을 보내면, 서버가 요청에 맞추어 그 자리에서 생성한 파일을 '동적' 파일이라고 부릅니다.
그럼 웹 호스팅(Web Hosting)이란 뭘까요? 웹 호스팅이란 서버의 한 공간을 임대해 주는 서비스를 뜻합니다.
웹 호스팅 업체들을 통해 개인 또는 단체가 웹 호스팅 업체가 제공하는 서버의 한 공간을 빌려서 원하는 서비스를 배포할 수 있습니다.
S3에서는 버킷이 사용자들이 정적 웹 사이트를 배포할 수 있는 공간을 제공합니다.
버킷이라는 저장 공간에 정적 파일을 업로드하고 버킷을 정적 웹 사이트 호스팅 용도로 구성하면 정적 웹 사이트를 배포할 수 있습니다.
S3의 핵심 개념
S3에서 버킷에 담기는 파일을 객체라고 부릅니다.
왜 객체라고 부를까요?? S3에서 저장소에 데이터를 저장할 때 키-값 페어 형식으로 데이터를 저장하기 때문입니다.
S3에 저장되는 객체는 파일과 메타데이터로 구성됩니다.
파일에 대해서 먼저 알아보겠습니다. 파일은 위에 설명한 대로 키-값 페어 형식으로 데이터를 저장합니다.
파일의 값에는 실제 데이터를 저장합니다. S3 객체의 값으로써 저장될 수 있는 데이터의 최대 크기는 5TB입니다.
버킷(bucket)
버킷은 객체를 저장하는 컨테이너 역할을 하며, 컴퓨터로 비유하자면 파일을 담는 폴더 역할을 합니다. 따라서 한 버킷 내에 여러 개의 폴더를 생성할 수도 있습니다.
버킷 생성 시 주의해야 할 점은 버킷 이름을 붙일 때 여러 리전에서 유일무이한 이름을 사용해야 합니다. 그래야 사용자가 버킷 URL을 통해 해당 데이터에 접근할 수 있습니다.
버킷은 어떤 리전에서나 생성할 수 있고, 명시적으로 복제 작업을 수행하지 않으면, 한 다른 리전에 특정 버킷의 데이터가 복제 되지 않습니다. 또한 S3 버킷은 버전 부여 기능을 제공하므로 객체가 버킷에 추가될 때마다 해당 객체에 유일한 ID가 할당됩니다.
🖍 참고 만약 S3 버킷에 사용자 지정 도메인을 사용하고 싶다면? - 2단계: 두 개의 버킷 생성 부분을 참고하여 도메인과 같은 이름의 S3 버킷을 생성해야 합니다
Route 53에 등록된 사용자 지정 도메인을 사용하여 정적 웹 사이트 구성 - Amazon Simple Storage Service
변경 사항은 일반적으로 60초 이내에 모든 Route 53 서버로 전파됩니다. 전파가 완료되면 이 절차에서 생성한 별칭 레코드의 이름을 사용하여 트래픽을 Amazon S3 버킷으로 라우팅할 수 있습니다.
docs.aws.amazon.com
객체(object)
앞서 언급했듯 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터을 포함하고 있는 데이터로, 버킷에 저장한 모든 것을 객체라고 부릅니다. 이는 가장 기본적인 요소로, 각 객체는 데이터와 메타데이터를 가집니다. 메타데이터는 해당 객체를 설명하는 이름-값 쌍으로 표시하며 여기에는 최종 수정일, 파일 타입 등 부가 정보가 기록됩니다.
객체는 이름, 키 또는 버전 ID를 통해 식별할 수 있으며, 키를 통해 버킷에서 유일한 것으로 식별합니다. 따라서 버킷에 존재하는 모든 객체는 단 하나의 키를 가집니다.
접근성 통제
접근성 통제(Access Control)란, S3 버킷에 누가 어떻게 접근하도록 할 것인지를 정의하는 것을 말합니다. 접근성 통제 방식은 주로 JSON을 이용해 작성된 정책(Policy)를 통해 이루어지며, 접근 정책, 버킷 정책, 접근 제어 목록 등의 방식을 사용합니다.
정책을 만드는 JSON 파일의 구조는 아래와 같습니다.
하나의 Statement에는 하나의 permission 정보가 포함됩니다. 정책에 포함된 다수의 statement은 논리합(Logical OR) 관계를 맺습니다.
위의 정책에서 사용되는 각 필드는 다음과 같은 의미를 갖습니다.
ID : 정책의 ID 값으로, UUID를 사용하기를 권장합니다.
SID : Statement ID로 statement 를 구분하기 위해서 사용합니다.
Effect : 정책의 효과를 나타내며, 허용할 것인지 거부할 것인지를 선택할 수 있습니다.
Principal : 대상 및 주체를 지정합니다. Users, Services 등이 될 수 있습니다.
Action : 정책을 통해 승인 혹은 거절할 동작을 의미합니다.
Resource : Action이 영향을 미치는 리소스 리스트를 지정합니다.
Condition : 조건이 충족되는 경우에는 해당 정책을 적용시킬 수 있습니다.
더불어 정책은 사용자, 그룹, 및 롤에 할당하는 IAM 정책인 Identity-based policies 와 S3 Bucket, SES Queue 등 AWS 자원에 할당되는 정책인 Resource-based policies로 나뉘어 작성됩니다.
이 둘을 구분하기 위해서는 필드에 Principal이 있는지 확인해보면 됩니다. AWS 자원에 할당되는 정책에는 Principal 항목이 포함되어 있고, IAM 정책에는 Principal 항목이 포함되어 있지 않습니다.
접근 정책
Identity-based policies
IAM, 즉 신분 및 접근 관리 정책으로 S3의 객체를 매우 세분화해 통제할 수 있습니다.
먼저 유저, 그룹, 롤 등 IAM 정책을 정의합니다.
예를 들어, S3 풀 액세스 정책을 생성하고, 10명의 유저가 포함된 그룹에 해당 정책을 할당합니다.
그러면 해당 그룹에 속한 10명의 회원 모두 S3 버킷에 대한 풀 액세스 권한에 접근 가능합니다.
IAM과 S3를 이용하면 특정 IAM 유저와 공유되고 있는 버킷을 선택할 수 있고, 특정 유저가 해당 버킷에 접근하도록 허용할 수 있습니다.
또한 특정 버킷의 내용을 회원 모두 혹은 일부 회원이 열람하도록 할 수 있고, 고객 또는 파트너가 특정 버킷에 객체를 추가하도록 허용할 수 있습니다.
이 예제에서는 AWS 계정 의 IAM 사용자에게 버킷 중 하나인 awsexamplebucket1에 대한 액세스 권한을 부여하고 이 사용자에게 객체를 추가, 업데이트, 삭제하도록 허용하려 합니다.
{
"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:ListAllMyBuckets, s3:GetBucketLocation 및 s3:ListBucket 권한 역시 부여합니다. 이러한 권한은 콘솔에 필요한 추가 권한입니다.
세번째로 콘솔에서 객체를 복사, 자르기 및 붙여넣기를 할 수 있으려면 s3:PutObjectAcl 및 s3:GetObjectAcl 작업이 필요합니다. 따라서 총 세 개의 statement가 하나의 정책으로 작성된 것을 확인 할 수 있고, 이렇게 작성된 정책을 그룹, 유저 등에 할당하여 사용할 수 있습니다.
버킷 정책
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) 시스템을 활용합니다. MFA Delete를 설정하여 데이터 삭제 권한이 없는 사람은 삭제 할 수 없도록 제한합니다.
S3 스토리지 클래스
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/storage-class-intro.html
Amazon S3 스토리지 클래스 사용 - Amazon Simple Storage Service
S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive 스토리지 클래스를 선택하면 객체가 Amazon S3에 그대로 유지됩니다. 별도의 Amazon S3 Glacier 서비스를 통해 객체에 직접 액세스할 수 없습니다.
docs.aws.amazon.com
댓글