AWS CCP 자격증 - 6 (S3)

Amazon S3 

제한 없이 스케일할 수 있는 스토리지

 

Amazon S3는 스토리지라서 백업과 저장소로 활용된다.

파일을 저장할 수도 있고 디스크 역할도 합니다.

 

예를들어 리전이 다운되어 재해 복구를 위해 한 리전에 있는 데이터를 옮겨야 할 때, 백업용이나 보관용으로 사용됩니다.

 

Amazon S3에 아카이브 해두었다가 나중에 꺼내 쓸 수도 있습니다 (꽤 저렴한 비용)

 

S3 Buckets

S3는 사람들이 버킷에 객체(Object, Files)를 저장할 수 있도록 허용합니다.

버킷의 이름은 반드시 전 세계적으로 유일해야 합니다. (AWS에서 유일하게 전역적으로 고유한 이름)

버킷은 리전 레벨에서 정의된다.

S3은 글로벌 서비스처럼 보이지만 버킷은 리전 안에서 만들어 진다.

 

Objects (파일)

객체는 각각 키를 가지고 있습니다.

키는 해당 파일의 전체 경로 입니다.

 

• ex) s3://my-bucket/my_file.txt
• 키는 prefix와 object name으로 구성되어 있다.
  ex)s3://my-bucket/my_folderl/another_folder/my_file.txt

Amazon S3에선 디렉터리라는 개념이 없고 무엇이든 키라고 생각해야 합니다.

키에는 슬래시도 포함합니다.

 

Amazon S3 실습

 

누군가 이미 test라고 써버림 (이미 선정됨)

 

 

버킷은 전역적이지 않고, 단 하나의 리전에만 위치 (ap-northeast-2)

 

 

나머지는 권장값이나, 기본값으로 생성합니다.

기본적인 gomjong-demo-s3 버킷이 생성 완료 되었습니다.

 

이 버킷에 이제 오브젝트를 올려보겠습니다.

업로드 - 파일 추가 - 올리고싶은 파일 선택 후 업로드

coffee.jpg 파일이 객체 목록에 있는 걸 확인할 수 있습니다 

파일 이름을 클릭하면 파일의 상세 정보를 볼 수 있습니다.

 

아 파일은 S3의 버킷으로 업로드했고 위 열기 버튼으로 인해 이미지를 페이지로 열 수 있습니다.

https://gomjong-demo-s3.s3.ap-northeast-2.amazonaws.com/coffee.jpg?response-content-disposition=inline&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMn%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDmFwLW5vcnRoZWFzdC0yIkcwRQIgV1%2BkuczOKE0Ob4sIlklpJvvBw%2BOgUxxo1QqqBLoFXIsCIQChIEB%2F3eocAYcVjGaf34i7qGuoICcikgh%2Fg1UDrDYE9yqOAwiC%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F8BEAAaDDEwNjQzNjMwNzIwNCIMaAT50s2TLYi%2FMOyLKuICT5%2BE2jhU81EjalD72wkKxgwzPU9PrAjmVAtJaAJtMHqf18iMEYq9qq%2BSpWZHCoRKP7RG6L%2BG4PZn8MAjIUGaEjMrR2IfhYCKytjfdE2deE7Pe1RlqeLcZAwJxwcEd01oVYW%2BIsb79rfnJDIs%2FwFh8cnRqzTU6vNLSmpJvPPQ5%2BNUijbRAfZQuXxuhQBCyVjxzavaKeyH1ZO4hJGh0PpjcSnWheh1gc864wDKyx1heAqGBcX9uxGwGsFPN3pz8VN2bOkMIY%2FEvPUpKM7KyLHo19cL895smCymJOK85zGlej6v9N9deoMhFiFKWenzxNZn8Rmmi6KXTOTBFaZ1ZgMl4W%2FEnHveNTi%2BL1uZkl6mR50dvxOgJqjMyMLUCh6VaW9jp1TzRuuUyUq8bmczhmuUtcsDe2jURHfhP5%2F%2B5407EudRjxAwJUwfQTDJmeHOmMH9IDwHSd%2BXW%2FVfgrn5BFLFo%2FdgMPy9krQGOrMCQVyBzcJ3I4g0yqRNYe%2BZTKbKgfuK8goiftQ%2FUppyzl404i5rQCXjUdAgSpB19FI4BJN8H8ez9KfeqlvU9LVWFVeg7M0TN%2FZlr%2FU7o5KjH3Seb7x3FEXUsKgH0ve4CpjBVisXuO%2FDA1S%2F9VJBR5aqzLILSsSzZBVGXktbDt0PGneo%2F2g8CiuHH6M6a5WxDQnb6llUx7OkPZUomMXcXJUiv5nZtulCccFAct7duWaeFfHOcGtFjuzEg1zLODRztvQycoWcJt4Y9h0C%2FNKNsDVIigxTASG6yzrV2MkKere%2BLdzCWyAhnil8rZBJgN%2F%2FV%2BYqiek7Kxg%2B6VkdCdO6FwxELbaPfHE3SQuLaZ0V4jV8XL3MG53whvSIzO5aP2rd1LQ5tB5TM9OPKosHkWiG2fDFdABWBg%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20240703T012533Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIARRSAZFECLGQUF6VA%2F20240703%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Signature=088bf147106c2786855ab49068305ddc5d090330d04c473e050e8556287da16b

 

 

 

하지만 객체 URL을 복사해서 주소창에 입력하면

 

접근이 거절됩니다.

이 메시지가 이야기 하는것은 제 오브젝트에 퍼블릭 URL로는 접근이 불가능합니다.(이 퍼블릭 URL은 동작하지않고있다.)

 

무슨 차이일까요? 

 

위 열기 URL을 보면 앞부분은 퍼블릭 URL이랑은 같은데 뒤에 나머지 부분이 매우 복잡하고 깁니다.

이 복잡하고 긴 내용 안에는 S3의 미리 서명된 URL 이라는 내용인데

URL안에 서명을 담고있습니다 즉 제 자격 증명을 가지고 있는 셈이고, 자격 증명이 인코딩된 채로 URL에 들어가 있어서 

https://gomjong-demo-s3.s3.ap-northeast-2.amazonaws.com/beach1.jpg 이 URL에 대해 뒤에 자격증명으로 미리 서명을  함으로써 접근이 가능하도록 하는것 입니다.

 

퍼블릭 URL에서 이미지에 접속할 수 있는 방법은 나중에 배워 볼 예정입니다.

 

일단 다시 버킷으로 돌아와서 오브젝트에 Images 폴더를 생성합니다. 이 폴더 안에도 파일을 업로드 할 수 있습니다.

객체 안에 폴더를 만들고 그 폴더 안에도 파일을 업로드 할 수 있었습니다.

 

저희가 알고 있는 구글 드라이버, 네이버 클라우드 그런 것과 다를게 없습니다.

 

Amazon S3에서도 비슷한 UX를 제공합니다. 그래서 당연히 Images라는 폴더도 삭제할 수 있고 삭제하면

폴더 내의 내용물도 다 삭제합니다.

 

 

Amazon S3 보안

 

 User 기준

사용자에게는 IAM 정책을 적용하는데,

IAM 정책이 정의하는 건 어떤 API가 어떤 IAM 사용자에 의해 호출될 수 있는가 입니다.

 

Resource 기준

 

버킷 정책 : S3 콘솔에서 여러 버킷에 적용되는 규칙을 생성할 수 있습니다.

이 규칙은 특정 사용자에게 이용을 허용하거나 또 다른 계정 사용자를 허용할 수도 있습니다 (교차 계정 액세스 허용)

액세스 컨트롤 리스트 (ACL)도 있는데, 세밀하게 보안을 관리하는 장치 입니다.

Object Access Control List - 오브젝트 단위로 관리

Bucket Access Control List -  버킷 단위로 관리

 

IAM 정책으로 S3 오브젝트에 접근할 수 있는 건 언제일까요?

 

IAM 권한이 허용으로 돼 있거나 리소스 정책이 허용으로 돼 있거나, 접근 거절 액션이 명시되어 있지 않다면

API 호출 시 정책에 기반해 S3오브젝트에 접근할 수 있습니다.

 

마지막의 보안 방식은 함호화 키를 이용하여 오브젝트를 암호화하는것입니다.

 

S3 버킷 정책은 JSON으로 정의합니다.

Resource엔 어떤 버킷 또 어떤 오브젝트에 이 정책이 적용되는지를 명시합니다.

 

이 예시는 버킷에 있는 모든 오브텍트에 적용이 됩니다. (*)

 

Effect로는 허용이나 거절을 결정합니다

무엇을 결정하냐면 Action에 있는 API목록이 있습니다. (예시에서는 GetObject) 

Principal은 보안 주체를 설정하는데 여기서 *으로 되어 있기 때문에 "아무나" 허용됩니다. 

보안 주체는 이 정책이 적용되는 대상 계정이나 사용자를 명시합니다.

 

익명의 www 웹사이트 방문자의 접근을 허용하려면 퍼블릭 액세스를 허용하는 S3 정책을 적용합니다.

 

이 방법은 AWS IAM 사용자가 S3에 접근하려고 하는데 이때 사용자에게 IAM 권한을 부여하여 버킷에 접근합니다.

 

EC2 인스턴스가 S3 버킷에 접근해야 한다면 EC2 인스턴스 역할을 만들고 적합한 IAM권한을 부여하면 됩니다.

 

 

 

버킷 정책에서 퍼블릭 액세스를 허용해도 위 설정이 활성화 되어 있다면 버킷은 절대 퍼블릭에서 접근할 수 없습니다.

S3 버킷 정책을 잘못 설정하는 실수를 해도 보호해줍니다 (AWS가 기업데이터 유출을 위해 이중 보안)_

 

S3 버킷 정책

 

이번엔 버킷 정책을 만들어 아까 접근이 안되었던 퍼블릭 url로 접근할 수 있도록 해보겠습니다.

권한 탭으로 이동하고 퍼블릭 액세스 차단이 활성화 되어있기 때문에 편집을 진행합니다.

퍼블릭 액세스 차단을 해제한 뒤 이제는 오브젝트가 공개될 수 있는 상태가 되었습니다.

 

 

이제 버킷 정책 부분을 편집하겠습니다. 

정책 예제를 보면 다양한 유스케이스들이 나열되어 있고, 어떤 정책이 적합한지와 알맞는지 보여줍니다.

 

저는 정책 생성기를 통해 S3 버킷 정책을 생성하겠습니다.

 

정책 유형을 설정합니다

그 다음 effect를 설정하고, 보안주체에는 *을 이용하여 모든 주체에게 권한을 줍니다

그리고 버키엣 있는 object를 읽는게 목적이니 action은 get object로 진행합니다.

그리고 ARN은 의 S3 버킷 정보를 복사하고 값을 붙여넣습니다.

ARN 마지막에 /* 을 추가해 버킷안에 있는 모든 오브젝트에 이 서비스를 적용한다고 편집을 마무리합니다.

 

 

아래 요약

정책 생성을 누르면 JSON형식으로 정책을 제공해줍니다.

이걸 복사하여 

 

버킷 정책 편집에 붙여넣어줍니다.

 

이 정책의 요약은 누구든지 이 버킷 내에 있는 아무 오브젝트에 GetObject를 수행할 수 있게 한것입니다.

버킷정책 생성을 완료하고, 이제 퍼블릭 접근이 허용됐습니다.

아까 접근이 안되었던 객체 URL (퍼블릭URL) 이 이제 접근이 허용된것을 볼 수 있습니다.

 

 

이제 Amazon S3 버킷에 어떤 오브젝트를 올리든지 퍼블릭 URL로 접근할 수 있는 상태가 됐습니다.

 

Amazon S3 - 정적 웹사이트

 

S3은 정적 웹사이트를 호스팅할 수 있습니다. 

사이트를 인터넷상에서 접근할 수 있게 할거고 웹 사이트의 URL은 어느 리전에서 생성하느냐에 따라 약간씩 다릅니다만

기본적으로 매우 비슷합니다. (bucket-name.s3-website.or-)

 

정적 웹사이트를 호스팅하는 원리는, S3 버킷에 파일을 담고(HTML, 이미지파일) 그 버킷의 url을 버킷정책을 통해 

접근을 활성화 합니다.

 

실습을 진행해보겠습니다.

 

속성 탭에 들어가서 정적 웹사이트 호스팅을 편집합니다.

 

index.html은 업로드 해야하는거고 이 파일은 웹사이트의 기본, 홈 페이지 역할을 합니다.

여기에도 보면 웹 사이트 엔드포인트의 콘텐츠에 액세스할 수 있게 하려면 모든 콘텐츠를 공개적으로 읽기 가능하도록 설정해야 한다고 나와있습니다.

 

이대로 저장한 후 정적 웹사이트 호스팅을 활성화 하고 index.html파일을 업로드 하겠습니다.

 

index.html을 업로드 하고, 다시 속성 탭으로 가면 

버킷 웹사이트 엔드포인트가 생깁니다.

이 url에 접속하면

url 마지막 부분에 /beach.jpg로 하면

 

html이 해변사진으로 바귑니다.

 

S3 버킷에 정적 웹사이트 호스팅 옵션을 활성화됐고 S3 버킷 정책이 퍼블릭 접근을 허용하여 이 url에 접근이 가능했습니다.

 

Amazon S3 버전관리

 

Amazon S3에서 파일에 버전을 매길 수가 있습니다.

이 설정은 버킷 단위에서 설정을 해야합니다. 버킷에 버전 관리 기능이 활성화되어 있다면,

사용자가 파일을 업로드할 때마다 해당 파일의 새 버전이 생성되고 키가 할당됩니다.

버전 관리의 장점

 

의도치 않게 파일 삭제하는 것을 막아준다. (파일을 삭제하면 삭제하기 전 버전으로 롤백)_

 

버전 기능을 활성화하기 전 파일의 버전값은 null입니다.

버전 기능을 쓰다가 중단해도 이전 파일 버전들을 삭제하지 않습니다. 안전하게 이용할 수 있습니다!

 

버전관리 실습

 

S3의 속성탭으로 이동하여 버킷 버전 관리 편집 클릭

이 시점부터 같은 파일을 다시 올리면 버킷에서 파일 버전이 생성됩니다.

 

아까 index.html의 내용을 수정하여 다시 업로드 해보겠습니다.

내용을 수정하고 다시 업로드 하니 덮어씌워졌고 마지막 수정 시간이 바뀌었습니다.

 

다시 퍼블릭 url을 들어가서 index.html을 가보면

 

I love coffee -> I really love coffee로 바뀐것을 확인할 수 있습니다.

 

객체로 돌아가서 버전을 표시하면

버전 관리 하기전 업로드했던 beach, coffee, index.html은 버전 ID가 null이고

index.html 파일은 버전이 두 개가 있는 것을 알 수 있습니다.

그 전에 올린 파일의 버전 ID는 null이고

버전관리기능을 활성화 하고나서 올린 파일의 버전 ID는 생성된 것을 알 수 있습니다.

 

여기서  대상 오브젝트의 버전 id가 있는 파일을 삭제하게 되면

이렇게 오브젝트의 어떤 버전 id를 삭제하는 행위를 영구 삭제라고 합니다. (파괴 행위)

 

다시 그냥 i love coffee가 저장되어 있는 index.html이 올라와있는것을 볼 수 있습니다 (롤백)

버전 표시를 끄고 커피의 이미지를 삭제하면 영구삭제가 아닌 삭제 자체가 버전 id가 남는 기록이 됩니다.

 

 

실제로 삭제 되는건 아니고 삭제마커가 남습니다.

 

Cross-Region Replication

: CRR, 교차 리전 간 복제

특정 리전에 S3 버킷이 있을 때, 다른 리전의 S3 버킷에 복제하는 것을 의미합니다.

 

가령, ap-northeast-2 리전에 S3 버킷이 있고, 이를 us-east-2 리전의 S3 버킷에 비동기 복제를 해야 하는 상황에 적합합니다. 소스 버킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화되어야 합니다.

 

Use cases

: compliance, lower latency access, replication across accounts

CRR은 여러 Region에 분포되어 있어야 성능이나 기능 상 유리할 때 사용합니다.

 

가령, 사용 사례는 법규나 내부 체제 관리(compliance)일 때 여러 리전 S3로 분산시킬 수 있고,

여러 서버에서 S3 객체를 접근할 때 발생할 수 있는 지연 시간(lower latency access)을 줄일 수 있습니다. 가령, 한국과 싱가포르, 프랑스 리전에 서버를 단독 리전의 S3에 접근하는 것보다 각각 한국, 싱가포르, 프랑스 리전의 S3로 복제해 접근하면 훨씬 빨라집니다.

마지막으로 계정 간 복제(across accounts)에도 쓸 수 있습니다.

Same-Region Replication

: 같은 리전으로 복제

쉽게 구분하면, CRR은 이름 그대로 두 리전이 달라야 하며, 반대로 SRR은 같은 리전이어야 합니다

 

Use cases

: log aggregation, live replication between production and test accounts.

SRR은 다수의 S3 버킷간의 로그를 통합할 때나, 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용될 수 있습니다.

 

Amazon S3  복제실습

 

 

origin 으로 이름을 정하고 버킷 버전 관리를 활성화하여 생성합니다.

 

또 다른 버킷은 replica 이름으로 정하고, 버킷 버전 관리를 활성화하여 총 2개의 버킷을 생성합니다.

 

 

이제 origin 버킷에 파일을 올려보겠습니다 

 

 

여기 origin 버킷에 beach 사진을 올렸고, 원하는것은 replica버킷에도 복제가 되는 것 입니다.

 

origin 버킷에서 관리 섹션을 가면 복제 규칙이 있는데 규칙을 생성해보겠습니다.

 

 

설정을 하고 복제 규칙을 생성 완료하면

기본 객체도 복제할 것 인지 물어봅니다.

 

기본적으로 복제규칙을 이용한 복제를 활성화 시키는 시점부터 복제가 활성화되기 때문에 기존에 있는 객체들은 복제가 되지 않습니다.

따라서 AWS S3에서 기존 객체를 복제 할 것이냐고 물어봅니다.

 

저는 일단 아니오를 선택하겠습니다

 

그리고 replica 버킷에 들어가보면 beach는 복제 되어있지 않습니다.(위에서 아니오를 선택했기 때문에)

 

이제 origin에 복제 규칙이 설정 되었으니 origin 버킷에 coffee 사진을 업로드해보겠습니다.

 

origin 버킷에 coffee.jpg 파일을 업로드했고, 이 경우 버전 id는 zgcl ~~~ 입니다.

 

이제 replica 버킷에가서 복제가 되었는지 확인해보겠습니다.

이 버킷에 보면 coffee.jpg가 업로드 되어있고 버전 id도 zgcl ~~ 로 파일과 버전 id가 같이 복제된것을 알 수 있습니다.

 

만약 beach.jpg도 복제를 하고싶다면 origin에서 다시 업로드하여 해당 파일의 새 버전을 업로드하면

replica에도 새로운 버전의 id와 함께 복제가 됩니다.

 

 

S3 Storage Classes (중요)

 

Amazon S3에서 객체를 생성할 때, 클래스를 선택할 수 있습니다. (상황에 적절한 비용절감을 위해)

스토리지 클래스를 수동으로 수정할 수도 있고

Amazon S3 수명 주기 구성을 이용해서 모든 스토리지 클래스 간에 객체를 자동으로 이동시킬 수도 있습니다.

 

S3타입들을 알아보기 전에 내구성과 가용성의 개념을 알아보고 가겠습니다.

내구성이란 Amazon S3로 인해 객체가 손실될 수 있는 확률입니다.

Amazon S3의 내구성은 아주 높습니다.

99.999999999% (9가 11개)로 Amazon S3에 객체 천만 개를 저장했을 때 1만 년에 한 번 객체가 손실된다는 의미입니다.

모든 스토리지 클래스의 내구성은 동일합니다.

 

가용상이란, 얼마나 쉽게 서비스를 이용할 수 있느냐 입니다.

S3 Standard의 가용성은 99.99%입니다. 1년에 약 53분 동안 서비스를 이용할 수 없다는 뜻인데

서비스를 처리할 때 오류가 생긴다는 의미이므로 애플리케이션을 개발할 때 고려해야할 부분입니다.

 

S3 Standard - General Purpose

가장 보통의 범용 클래스입니다. S3에 저장되는 Object의 Default Class 입니다.

S3에서 설명하는 설계 목적은 아래와 같습니다.

Frequently accessed data (more than once a month) with milliseconds access
- 밀리세컨드 내 접근해야하며 자주 접근(한 달에 한 번 이상)하는 데이터

 

Standard 특징

- 99.99%의 가용성(Availability)을 제공

- 지연 시간이 짧고 (Low Latency), 높은 처리량 (High throughput)

- 한 시설의 데이터가 손실될 경우에도 작동을 유지할 수 있도록 설계

 

Standard 활용 사례 (Use cases)

- Big Data Analytics 

- Mobile and Gaming Applications

- Content Distribution

- Dynamic Websites

- Cloud Applications

Standard IA (Infrequent Access)

자주 사용하지는 않지만 빠르게 접근해야 하는 데이터를 위한 클래스입니다.

S3보다 저렴한 가격이지만, 검색 비용이 발생합니다. 

 

Standard IA의 특징은 99.9%의 가용성을 제공하는데, 이는 Standard 보다 0.09% 적습니다.

 

Standard IA 활용 사례 (Use cases)

- Disaster Recovery 재해복구

- Backups 백업

 

Standard와 가격을 비교해보면 다음과 같습니다.

 

One Zone-Infrequent Access

 

One Zone-IA는 Standard IA 종류 중 하나로, 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. 해당 클래스는 이름에 명시된 One Zone, 즉 하나의 지역에만 사용 가능한 S3 클래스입니다.

 

단일 AWS 가용 영역에 데이터를 저장하기 때문에 스토리지 클래스에 저장된 데이터는 가용성 영역이 파괴되는 경우 손실됩니다.

 

S3 One Zone-IA는 단일 AZ에 데이터를 저장하며 비용이 S3 Standard-IA보다 20% 적게 듭니다.

조금 더 저렴하면서, S3 Standard-IA 스토리지와 같은 가용성 및 복원력이 필요 없을 때 적합합니다. 

가령, 쉽게 다시 생성할 수 있는 데이터의 보조 백업 복사본을 저장하는 업무에 사용될 수 있습니다.

 

Standard-IA와 가격을 비교해보면 다음과 같습니다.

Glacier Storage

Glacier 저장소는 아카이빙 또는 백업을 위한 저가의 객체 저장소입니다.

가격은 저장 비용과 객체 검색 비용이 계산됩니다.

Glacier 저장소는 세 가지 종류가 있습니다.

 

세 가지 클래스 모두 아카이빙 또는 백업 용이지만, 상황에 따라 구별하여 비용을 최적화하여 사용해야 합니다.

 

- S3 Glacier Instant Retrieval: 즉각적인 액세스 (밀리초 단위의 검색 시간)

- S3 Glacier Flexible Retrieval: 큰 데이터 집합이 필요 시 (용량의 유연성), 즉각적인 액세스 X

- S3 Glacier Deep Archive: 장기 보관용

 

아주 대략적인 구분인데요. 각각의 보관 기간, 검색 속도가 다르고 그에 따라 가격이 다르기 때문에 하나씩 살펴보겠습니다.

 

Intelligent Tiering

 

S3 Intelligent-Tiering(S3 Intelligent-Tiering)은 사용 패턴에 따라 액세스된 티어 간에 객체를 이동할 수 있게 해줍니다. 즉, 성능, 검색 요금 또는 액세스 빈도에 따라 가장 비용 효율적인 액세스 티어로 데이터를 자동으로 이동하기 때문에 운영 부담없이 편하게 스토리지를 관리할 수 있습니다. 세분화된 객체 수준에서 스토리지 비용을 자동으로 절감해주는 효과를 줍니다.

S3 Intelligent-Tiering은 접근 빈도와 저장 기간에 따라 3개의 액세스 티어에 객체를 다음과 같이 자동으로 저장합니다.

Frequent Access: 기본 티어 (빈번한 액세스에 최적화)

Infrequent Access: 30일 동안 액세스하지 않는 객체 (빈번하지 않은 액세스에 최적화). 40% 더 저렴.

Archive Instant Access: 90일 동안 액세스하지 않는 객체 (거의 액세스하지 않는 데이터). 8% 더 저렴.

 

Archive Access: 90일에서 최대 730일까지 액세스하지 않은 객체. 표준 검색 시간 3~5시간

Deep Archive Access: 180일에서 최대 730일까지 액세스하지 않는 객체. 성능은 S3 Glacier Deep Archive와 동일. 표준 검색은 12시간

 

 

 

S3 Encryption

서버 측 암호화 :

S3 버킷에 대한 기본 암호화 동작을 설정하여 모든 새 객체가 버킷에 저장될 때 암호화되도록 할 수 있습니다.

Amazon S3로의 모든 새 객체 업로드는 추가 비용 없이 성능에 영향을 미치지 않고 자동으로 암호화(기본값: SSE-S3)됩니다.

• Server-Side Encryption
  - SSE-S3
  - SSE-KMS
  - SSE-c

클라이언트 측 암호화 : 사용자가 파일을 업로드하기 전에 직접 암호화 

• Client-Side Encryption

서버 측 암호화가 기본적으로 항상 활성화되어있다.

 

IAM Access Analyzer for S3

Amazon S3 버킷을 모니터링 하는 기능

접근을 허용한 사람만 의도된 대로 S3 버킷에 접근할 수 있나를 확인합니다.

 

버킷 규칙, S3 ACL, S3 액세스 포인트 규칙 등을 분석합니다.

어떤 버킷이 퍼블릭 액세스가 가능한지, 또 어느 버킷이 다른 AWS 계정과 공유가 됐는지를 확인합니다.

우리는 분석된 결과를 보고 보안이슈 등을 판단할 수 있습니다.

 

Amazon S3 공동책임 모델

AWS 측

늘 그렇듯 AWS에게는 인프라에 대한 전반적인 책임이 있습니다.

내구성, 가용성, 두 개의 시설에서 동시에 데이터 손실이 발생하는 사실도 해당됩니다.

여기에 자체적인 내부 구성과, 취약성 분석도 따르며 인프라 내부에서 자체적인 규정 준수 검증도 수반됩니다.

 

사용자 측

올바른 S3 버킷 정책 설정을 함으로써 버킷 내에서 데이터가 보호될 수 있도록 해야 합니다.

복제 작업이 필요할 시에는 직접 설정하며 로깅과 모니터링은 선택사항이므로 사용자가 자체적으로 활성화해야 합니다.

또한 사용자가 직접 스토리지의 클라우드를 선택하여 사용하는 것도 사용자 본인의 책임입니다.

마지막으로 Amazon S3 버킷에 데이터를 암호화할지 여부 또한 사용자에게 달려있습니다.

 

AWS Snow Family

AWS Snow 제품군은 보안성이 높고, 엣지에서 데이터를 수집하고 처리하기 위해 사용되거나 AWS 안팎으로 데이터를 마이그레이션 할 때 사용하는 휴대용 장치입니다.

데이터 마이그레이션을 위한 Snow 제품군으로는 Snowcone, Snowball Edge, Snowmobile이 있습니다.

엣지 컴퓨팅을 위한 Snow 제품군으로는 Snowcone, Snowball Edge가 있습니다.

 

왜 AWS Snow 패밀리를 이용해서 데이터를 이관(마이그레이션)할까요?

 

일반적인 네트워크를 사용해서 대량의 데이터를 전송하려면 시간이 엄청 오래걸립니다.

예를 들어 100TB를 1Gbps 속도를 지원하는 네트워크에서 전송하면 총 12일이 소요됩니다.

만약 전송할 데이터의 단위가 PB가 넘어가게 된다면 상상도 할 수 없을 만큼 오랜 시간이 걸릴 것 입니다.

 

이 뿐 만이 아니라 네트워크 회선을 사용하는 비용도 무료가 아니라 클라우드 회사에 엄청나게 많은 비용을 지불해야 합니다. 따라서 문제점은 아래와 같습니다.

 

• 대역폭 공유 문제 (AWS에서 10TB의 파일을 다운 받아서 가용 대용폭을 다 써버려 공유되고있는 네트워크 마비)
• 높은 네트워크 비용 
• 제한된 대역폭 문제
• 연결 안정화 문제 

이런 문제들 때문에 Snow 제품들이 사용됩니다. Snow 제품들은 오프라인에서 데이터 마이그레이션을 실행하는 장치입니다. snow 패밀리는 오프라인 기기입니다.

 

AWS가 사용자에게 실제 물리적인 기기를 전송합니다. 그럼 사용자는 기기에 데이터를 담아 다시 AWS로 보냅니다.

 

핵심은 AWS로 데이터를 이전하는 건데, 물리적인 경로로 한다는 것 입니다 ( 네트워크가 아님)

Snowball Edge

• TB 나 PB 이상의 데이터를 전송해야 할 경우 사용한다.
• 데이터 전송 건마다 비용이 청구된다.
• 자체적으로 블록 스토리지를 사용하나 Amazon S3 호환되는 객체 스토리지도 제공해준다.
• Snowball Edge 에는 두 가지 옵션이 있다.
  1. Snowball Edge Storage Optimized : 블록 스토리지로 사용할 수 있도록 80 TB 의 HDD 를 제공해주고 필요하다면 S3 와 호환되는 객체 스토리지를 제공해준다.
  2. Snowball Edge Compute Optimized : 42 or 28TB 의 HDD 를 제공해주고 필요하다면 S3 와 호환되는 객체 스토리지를 제공해준다.
• Snowball Edge 를 데이터 전송에 쓰는 경우는 보통 온프레미스에서 클라우드로 전환할 때 대량의 데이터를 클라우드에 마이그레이션 하거나 재해 복구를 위해 AWS 에 데이터를 백업하는 경우다.

Snowcone

• Snowball Edge 보다 더 작은 장치로 휴대 가능한 장치이며 무게는 2.1kg 정도 된다. 어느 환경에서도 사용할 수 있다.(사막이나 물속이든 상관 없다.)
• 8TB HDD or 14TB SSD를 저장할 수 있고 용도는 엣지 컴퓨팅이나 데이터 전송에 사용된다.
• Snowcone 은 보통 환경이나 공간의 제약을 받는 상황에 사용한다. 드론에 연결하여 데이터를 저장할 수도 있고 이외에도 활용 방법은 많다.
• Snowcone를 사용해서 AWS로 데이터를 보내는 방법은 두 가지가 있는데, 우편으로 보내는 방법과 기기를 연결하는 방법입니다. 데이터센터의 데이터를 저장했으면 인터넷 연결이 가능한 기기랑 연결한 다음 AWS Datasync를 이용해 AWS로 데이터를 보내는 방법이 있습니다.

Snowmobile

• Snowmobile은 실제 트럭입니다. 데이터 트럭
• Snowmobile로 이전할 수 있는 데이터는 엑사바이트 단위입니다. 1 EB = 1024 PB = 1,000,000TB
• Snowmobile 한 대당 저장할 수 있는 데이터는 100PB이고 1EB를 처리하려면 10대를 주문해야 합니다.
• 안전성이 굉장히 높은 데이터 전송방법을 사용합니다 (온도조절, GPS, CCTV) 데이터를 10PB 이상 이전한다면 Snowball보다는 Snowmobile을 사용하는 것이 좋습니다.

 

 

Snow Family - Usage Process

 

1. 콘솔에서 기기를 요청

2. 사용자의 서버에 Snowball 클라이언트나 AWS OpsHub 설치

3. Snowball을 서버와 연결하고 클라이언트를 이용해 서버의 데이터를 복사

4. 복사가 끝나면, 기기를 우편으로 보냄

5. 기기의 있는 E-잉크 마커에 따라 적합한 AWS 시설로 보냄

6. 데이터는 S3 버킷에 로딩되고 Snowball에 기록된 데이터는 깔끔하게 삭제 

 

원래는 Snowball 기기 용도가 이게 유일했으나 엣지 컴퓨팅이라는 용도도 생겼습니다.

 

엣지 컴퓨팅?

• 데이터가 엣지 로케이션에서 생성될 때 실시간으로 데이터를 처리하는 방식을 뜻한다.
• 엣지 로케이션이란 데이터를 생성은 하지만 인터넷과 연결되어 있지 않는 모든 장소를 뜻한다(바다 위 배, 광산, 도로 위 트럭 등) 인터넷이 연결되지 않는 곳에서 데이터 처리를 해야 할 경우 엣지 컴퓨팅이 필요로 하다.
• Snowball Edge 나 Snowcone 장치를 주문해서 엣지 로케이션에 장착시키면 엣지 컴퓨팅을 시작할 수 있다.
• 엣지 컴퓨팅의 예시를 들면 데이터 전처리, 클라우드에서 머신 러닝을 하지 않고 엣지 컴퓨팅으로 머신 러닝을 하거나 미디어 스트림을 트랜스 코딩하는 작업들이 있다.
• 어찌됐든 간에 데이터를 AWS 로 보내야 하는 경우 Snowcone 이나 Snowball Edge 장치를 AWS 로 보내주면 된다. 즉, Snowball Edge, Snowcone 에서 엣지 컴퓨팅을 하고 완료된 작업물을 AWS 로 보내서 클라우드에 업로드하는 것이다.

AWS OpsHub

원래는 snow 기기를 이용하려면 CLI가 필요하고 이용이 까다로웠는데,

이를 AWS가 인지하고 Opshub라는 프로그램을 만들었습니다.

 

컴퓨터나 노트북에 설치하는 프로그램이고, 이 프로그램이 실행되면 UI상에서 기능을 제공합니다.

Snow 기기에 연결하기도 하고 기기의 설정을 바꾸기도 하며 아주 간편하게 사용할 수 있습니다.

 

제공하는 기능은 단일 기기나 클러스터 내 기기를 해제하기, 설정하기, 파일을 이전하기, 인스턴스 실행, 관리가 있습니다.

OpsHub를 이용하여 Snow 패밀리 기기에서 실행되는 EC2 인스턴스들을 간편하게 제어할 수 있습니다.

 

Snowball Edge Pricing

d

Amazon S3 로 전송되는 데이터의 요금은 GB당 0.00 USD입니다.

 

디바이스가 물리적 위치에 있는 전체 기간(일)을 기준으로 요금이 부과됩니다.

10일 이용에 80TB, 15일에 210TB가 있고 10일,15일이 경과한 시점 이후 하루당 비용이 발생합니다.

 

선불 약정

엣지 컴퓨팅과 관련하여 Snowball Edge 기기 이용료로 할인율은 62%입니다. (온디맨드, 월별 이용요금 대비)

월간, 연간, 혹은 3년 단위 이용을 위해 선불로 지불합니다.

 

AWS의 다양한 스토리지 옵션

 

블록 스토리지 : EBS, EC2인스턴스

파일 스토리지 : Amazon EFS

객체 스토리지 : Amazon S3, Glacier

 

Storage Gateway

 

AWS 내 사용자의 온프레미스 데이터와 클라우드 데이터를 연결합니다.

즉 하이브리드 스토리지를 사용하여 온프레미스 시스템에서도 문제없이 클라우드를 이용할 수 있도록 확장합니다.

정리하면 Storage Gateway를 이용하면 온프레미스에서 발생하는 작업이 바로 AWS 클라우드로 연결이 됩니다

 

Amazon S3 - 요약

 

버킷과 오브젝트의 차이 

 

버킷의 이름은 전역적으로 고유해야 합니다. 그리고 특정 리전에 위치해야 합니다.

오브젝트는 버킷 안에 존재합니다.

S3 보안을 위해서는 사용자나 역할에 IAM 규칙을 적용할 수 있고, 버킷 규칙을 이용하는 방법도 있습니다.

S3 버킷에 퍼블릭 액세스를 허용하고, 특정 파일을 보호하기 위한 암호화도 있었습니다.

 

S3 버킷에서 웹사이트를 서비스하기 위해 버킷을 퍼블릭으로 만들어 파일을 정적으로 호스팅도 하였습니다.

S3 버전 관리 기능을 통해 파일을 버전 단위로 관리해 실수로 삭제하는것을 방지할 수 있었고 이전으로 롤백할 수도 있었습니다.

S3 복제 종류에는, 동일 리전 복제와 리전 간 복제가 있었습니다. 복제를 하려면 버전 관리 기능을 활성화 시켰어야 합니다.

 

S3 스토리지 클래스간의 차이도 확인했는데

Standard, Infrequent Access, One Zone Infrequent Access, Intelligent, 아카이브를 위한 Glacier에 클래스가 세 개 있는것도 확인했습니다.

 

Snow 패밀리로 Amazon S3로 데이터를 임포트할 수 있는 물리적인 기기도 봤으며, Snowmobile, Snowcone, Snowball등도 봤습니다. Snowcone, Snowball Edge 기기를 이용하면 데이터에 엣지컴퓨팅을 잘 활용할 수 있었습니다.

 

OpsHub는 데스크탑 애플리케이션으로,  Snow 패밀리 기기를 관리하고 데이터를 기기에 옮겨줍니다.

 

AWS Storage Gateway를 이용하여 온프레미스 스토리지를 Aazon S3로 확장할 수도 있습니다