레오의 데이터 파밍

3장에서는

S3 객체 저장, 관리, 액세스

내구성 가용성 비용에 균형을 맞춘 스토리지 클래스 선택

Amazon Glacier를 설계에 통합해 맞춘 스토리지 클래스 선택

데이터 저장과 액세스에 사용할수 있는 다른 AWS 서비스 

S3 는 

S3는 개인 어플리케이션 다수 AWS 서비스의 데이터를 보관하며 다음 워크로드를 위한 플랫폼 이다. 

- 백업 아카이브 로그파일 재해복구 이미지 유지 관리 

- 분석을 위한 빅데이터 저장

- 정적 웹사이트 호스팅 

S3는 필요에 따라 AWS 내 외부에서 실행되는 작업에 밀접하게 통합할 수 있는 저렴하고 안정성 있는 스토리지를 제공하며 2장에서 다룬 운영체제 볼륨과는 다르다. 

운영체제 볼륨은 블록 스토리지에 저장돼 EC2 인스턴스를 구동하는 반면 S3는 무제한 객체 스토리지 공간을 효과적으로 제공한다. 

객체 스토리지와 블록 스토리지는 어떻게 다를까?

먼저 블록 스토리지는 물리적 디스크를 개별 블록으로 나눠 데이터를 저장하고 파일시스템으로 관리한다. 보통 Windows에서는 NTFS를 파일 시스템으로 사용하고 Linux는 ext4를 사용한다. 파일 시스템은 설치된 OS를 대신해서 기반 장치에 저장되는 파일과 데이터를 위해 공간을 할당하고 OS가 읽을 때마다 액세스 할 수 있게한다. 

반면 S3 와 같은 객체 스토리지 시스템은 구조화 되지 않은 평면 저장소에 데이터를 저장한다. 이렇게 단순하게 설계됨으로써 운영체제에 연결된 블록스토리지의 복잡함은 피하면서 전문적으로 설계되고 유지 관리되는 무제한스토리지 용량에 누구나 쉽게 액세스 한다. S3에 파일을 쓸때 최대 2KB 메타데이터가 함께 저장된다. 

메타데이터는 시스템 세부 정보를 구성하는 키로 만들어지는데, 시스템 세부 정보는 데이터 사용 권한과 파일 시스템 처럼 보여지는 중첩 버킷 내 위치 정보 같은 것들이다. 

S3 서비스 아키텍처

S3 파일은 버킷으로 구성되며, AWS 계정당 기본으로 만들 수 있는 버킷은 100개 다. 

다른 AWS 서비스와 마찬가지로 AWS에 할당량 증가를 요청할 수 있다. S3 버킷과 그 내용은 한 AWS 리전에만 존재하고 버킷 주소는 전체 S3 글로벌 시스탬 내에서 유일해야한다. 여기에는 이유가 있다. 운영이나 규정 요구사항을 충족하기 위해 데이터는 특정 리전에 있는 리전에 배치하지만, 한편으로 버킷 주소만으로 버킷에 엑세스 할 수 있도록 프로세스를 단순하게 만들기 위해서다. 

한 리전 2 에 위치한 버킨 bucketname의 파일 filename에 HTTP로 액세스 하는데 사용할 url은 다음과 같다. 

https://bucketname.s3.ap-northest-2.amazonaws.com/filename

주소를 통해 객체에 액세스 하려면 액세스 권한이 부여되어 있어야 한다. AWS CLI 를 사용해서 위 파일에 액세스 하는 주소는 다음과 같다. 

s3://bucketname/filename 

접두사와 구분 기호 

앞서 설명한 바와같이 S3버킷은 하위 폴더 구조가 없는 평면 구조이며, 객체는이 버킷에 저장된다 그러나 접두사와 구분 기호를 사용해서 버킷을 더 체계적인 모습으로 나타낼 수 있다. 

일반 텍스트 문자열을 접두사로 사용해서 구조화된 수준을 표현한다. 예를 들어 contracts 다음에 구분기호 / 를 넣어서 파일을 버킷 내 그룹 안에 있는 파일처럼 보이게 한다. 

폴더 또는 디렉터리 구조로 객체를 업로드하면 S3는 이 구조를 버킷 내 실제 계층인 것 처럼 나타내고 자동으로 구분 기호를 빗금 문자로 처리해서 변환한다 콘솔이나 API로 S3객체를 확인할 때 마다 폴더와 흡사한 구조로 볼 수 있는 이유가 여기에 있다. 

대용량 객체 작업

이론적으로는 버킷에 무한대 용량을 데이터를 저장할 수 있지만 단일 객체의 크기는 5TB를 넘을 수 없고 한번에 업로드 할 수 있는 용량 크기는 최대 5GB다. 100MB 보다 큰 객체는 멀티 파트 업로드를 사용해서 데이터가 손실되거나 업로드가 중지되는 위험을 줄이는 것이 좋다 

멀티파트 업로드는 말 그대로 큰 객체를 여러 작은 부분으로 나눠서 S3 대상 위치에 하나씩 만들어 전송한다. 개별 부분을 전송하다 실패하면 그 부분만 다시 전송하기 때문에 다른 부분에는 영향을 미치지 않는다. 

AWS CLI 나 상위 수준에 있는 API에서는 멀티 파트 업로드가 자동으로 실행되지만, 하위 수준으로 API 작업할때는 객체를 수동으로 나눠야한다. 

API는 코드나 명령줄로 작업을 할수있는 프로그래밍 인터페이스를 말하며, AWS는 서비스를 관리하는 기본 방법으로 API를 사용한다. 수작업으로 S3에 올릴 때를 대비해 하위 수준 API를 제공하고 신속한 자동화 작업을 위해서 상위 수준 API를 제공한다. 

암호화 

웹 사이트와 같이 퍼블릭 액세스 하는 용도가 아니라면 S3에 저장할 데이터는 항상 암호화 해야한다. S3에 저장중인 데이터를 보호하기 위해서 암호화 키를 사용할 수 있고 S3에서 다른 위치로 전송하는 데이터를 보호하기 위해서 Amazon 암호화 API 엔드포인트 만을 사용할 수도 있다. 

저장중 데이터는 서버측 암호화나 클라이언트 측 암호화를 통해서 보호할 수 있다. 

서버측 암호화 

여기서 서버측 이라는 말은 S3 플랫폼을 의미한다. 데이터 객체를 암호화 해서 디스크에 저장하는 작업과 데이터를 가져올 때 적합한 인증으로 복호화하는 작업이 AWS에서 이루어진다. 아래와 같이 3가지 종류의 서버측 암호화가 있다. 

S3 가 관리하는 암호화키(SEE-S3)를 사용하면 AWS 가 자체 엔터프라이즈 표준 키를 사용해 암호화 복호화 프로세스의 모든 단계를 관리한다.  

AWS KMS -관리형 키를 사용하는 서버 측 암호화(SEE-KMS)를 사용하면 SSE-S3가 제공하는 기능에 더해 완벽한 키 사용 추적과 봉투키를 사용할 수 있다 AWS KMS 서비스에 자체 키를 가져와서 사용할 수도 있다. 

고객 제공 암호화 키에 의한 서버 측 암호화(SSE-C)는 고객이 S3에 제공한 자체 키로 객체를 암호화 한다. 

클라이언트 측 암호화 

S3로 데이터를 전송하기 전에 암호화 될 수 있다. AWS-KMS 관리형 고객 마스터키(KMS-CMK)를 사용하여 업로드 전에 고유키로 객체를 암호화 한다. 또한 S3 암호화 클라이언트에서 제공된 클라이언트 측 마스터 키를 사용할 수도 있다. 

복잡한 암호화 절차를 단순화 하기 때문에 서버측 암호화를 많이 이용하지만, 회사나 조직의 규정 또는 법 제한으로 암호화 키의 모든 권한을 가지고 있어야 할 수도 있다. 

로깅

S3 이벤트 추적을 로그 파일에 저장하는 기능은 처음엔 비활성화돼 있다. S3 버킷에서 일어나는 많은 활동을 로그 데이터로 만들어 모두 기록할 필요는 없기 때문이다. 

로깅을 활성화 할 때는 원본 버킷과 대상 버킷(로그를 저장할 버킷)을 지정해야한다. 하나의 대상 버킷에 여러 원본 버킷 로그를 저장햇을때 쉽게 식별할 수 있도록 구분기호와 접두사를 사용한다. 

S3 생성로그는 구성하면 잠시후 ㅏ음과 같은 작업 상세 항목이 기본으로 나타난다. 

요청자 계정과 IP 주소

원본 버킷의 이름

요청동작

요청 개시시간

응답상태 

S3 버킷은 CloudWatch나 CloudTrail 같은 다른 AWS 서비스가 로그 또는 다른 객체를 저장하는데에도 사용된다. 

S3 내구성과 가용성 

객체를 저장할 때 여러 S3 스토리지 클래스 중에서 선택할 수 있으며, 내구성(데이터가 손실되지 않을 확률), 가용성(객체가 사용 가능한 기간의 비율), 지출 가능 비용에 따라 선택한다. 

내구성

S3 는 내구성을 백분율로 측정한다. 예를 들면 대부분 S3클래스와 Glacier는 다음과 같이 99.9%의 내구성을 보장한다. 

즉 S3 Standard / Glacier 플랫폼에 저장한 데이터를 인프라 장애로 손실할 가능성은 거의 없다고 할 수 있다. 그렇다고 해서 중요한 데이터를 S3 한 버킷에만 저장해 놓는 것도 권장할만할 일은 아니다. 잘못된 구성, 잠김, 외부공격 등 영영 데이터에 액세스 하지 못할 수도 있으며, 정신나간 소리같지만 AWS가 파산할 가능성을 완전히 배제할 수 없다. 

S3는 최소 3개 가용영역에 데이터를 자동으로 복제하기 때문에 높은 내구성을 보장할 수 있다. 한 AWS 시설이 완전히 사라지더라도 다른 영역에 있는 데이터 복사본으로 복구할 수 있다. 

반면 복원력이 전혀 없는 두가지 스토리지 클래스도 있다 One Zone-IA 는 이름 그대로 데이터를 단일 가용영역에만 저장하고 RRS 는 다른 클래스보다 더 적은 영역에 복제하기 때문에 99.9%의 내구성만을 보장한다. 내구성 증감과 가용성 비용 등 기능의 균현ㅇ을 정해서 적합한 스토리지를 선택할 수 있다. 

가용성

객체 가용성도 백분율로 측정하며 1년동안 해당 객체를 요청했을때, 즉시 응답할 수 있는 시간을 백분율로 나타낸다. S3 Standard 클래스는 연간 99,99% 기간동안 데이터가 필요할때 사용될 수 있도록 보장하는데 이는 1년동안 1시간 이내라는 의미 이다. 

데이터의 일관성 

S3 데이터를 여러 장소에 복제하므로 기존 데이터가 업데이트 되면 시스템에 전파하는 동안에 약간의 지연이 발생할 수도 있다. 파일을 새 버전으로 업데이트 하거나 삭제할때 한 사이트 에서는 새로운 상태가 반영됐지만 다른 사이트에서는 변경이 반영되지 않을 수 있다. 

단일 객체의 버전 여려개가 충돌하면애플리케이션과 데이터 사이에 심각한 손상이 발생할 수 있는데 이를 피하기 위해서 최종 일관성 표준에 따라 데이터 처리를 설계해야하며 보통 2초 이하의 지연시간을 고려해야 한다. 

S3에 새로운 객체를 생성(PUT) 할때는 객체 버전이 충돌할 가능성이 없으므로 쓰기 후 읽기 일관성이 제공 된다. 

S3 객체 수명 주기 

S3 에서 시작하는 워크로드는 대개 백업 아카이브와 관련이 있다. 제대로 설계 됐다면 정기적으로 백업이 수행돼야하기 때문에 백업 아카이브가 늘어날 수 밖에 없다. 이전아카이브 버전을 유지하는 것도 필요하지만 오래된 버전을 정리하고 삭제해서 스토리지 비용을 절약하는 것도 중요한데 S3 버전관리와 수명주기 기능으로 이 모든 작업을 자동화 할 수 있다. 

버전 관리 

대부분의 파일 시스템은 기존 파일과 같은 위치에 같은 이름으로 파일을 저장하면 기존 객체를 덮어쓴다. 이 경우 항상 최신 버전을 유지할 수 있지만 기존 버전은 삭제된다. 실수로 덮어썼을 때는 다소 심각한 상황이 될 수 있다. 

S3 객체도 이와 같은 방식으로 작동하지만, 버킷 수준에서 버전 관리를 활성화 하면 덮어쓴 이전 객체를 보존할 수 있어서 기존 버전에 계속 액세스 할 수 있다. 이로서 실수로 기존 데이터를 잃게 되는 문제를 해결할 수 있지만 아카이브가 늘어나는 것은 감수해야한다

수명주기 관리 

버킷에서 수명주기 규칙을 구성하면지정한 기간이 경과했을때 자동으로 객체가 다른 스토리지 클래스로 옮겨진다 예를 들면 새로운 객체는 첫 30일 동안 S3 Standard 클래스에서 보관되고 30일이 지나면 더 저렴한 One Zone IA로 옮겨진다. 과거 버전을 유지해야하는 조직의 규정이 있다면 파일을 저렴한 장기 저장용 스토리지 서비스인 Glacier로 옮겨서 365 일 보관하고 기간이 지나면 영구 삭제된다. 

S3 객체 액세스 

S3에 데이터를 저장해서 사용하겠다고 결정했다면 데이터의 중요성에 맞게 S3에 저장된 객체에 액세스 하는 방법과 업무 보안상 필요에 맞는 요청만 액세스 하도록 제한하는 방법을 이해해야한다. 

액세스 제어

새롭게 S3 버킷과 객체를 생성한 즉시, 만든 사용자 계정에서는 완벽하게 액세스 할 수 있지만, 다른 AWS 계정이나 외부 사용자는 기본적으로 해당 버킷과 객체에 액세스 할 수 없다. 액세스 제어 블록 규칙,세분화된 S3 버킥 정책 IAM 정책을 사용해서 버킷이나 객체 수준에서 타 계정이나 외부 사용자에게 액세스를 허용할 수 있다. 

3가지 액세스 제어방식은 일부 중복 되어 있다 

사실 ACL 은 IAM을 만들기 전에 사용하던 정책이다. 지금은 ACL 대신 S3 버킷 정책이나 IAM 정책을 적용할 것을 권장한다. 

S3 버킷 정책은 외부 계정과 사용자가 S3 버킷에 액세스 하는 것을 제어할 수 있게 하는 반면 IAM 정책은 IAM이 관리하는 계정 즉 사용자와 역할이 S3를 비롯한 여러 리소스에 액세스하는 방을 제어하고자 할 때 사용한다. 

다음 코드는 특정 AWS 계정에 있는 루트 사용자와 사용자 Steve가 S3 MyBucket과 그 내용에 액세스 할 수 있게하는 S3 버켓 정책의 예이다. 두 사용자 모두 이 규칙에서 보안 주체가 된다. 

다음 IAM 정책을 IAM 엔터티 에 연결할 때 앞의 S3 버킷 정책과 같은 효과를 얻을 수 있다.

미리 서명된 URL

외부 액세스가 제한된 프라이빗 객체에 임시로 액세스 할 수 있게 할 때, 미리 서명된 URL 을 사용할 수 있다. 미리 서명된 URL 은 지정된 기간만 사용할 수 있으며, 기간이 지나면 사용할 수 없고 프로그래밍 방식으로 객체에 액세스 할 수 있도록 미리 서명된 URL 을 생성하는 명령을 코드에 포함해서 빌드 할 수 있다. 

정적 웹사이트 호스팅 

S3 버킷은 정적 웹사이트 HTML 파일 호스팅에도 사용된다. 정적 웹사이트는 웹 페이지와 스크립트를 랜더링 할 때 서버가 아닌 클라이언트 시스템 서비스를 사용하며, 클라이언트 브라우저에서 간단하고 유연한 HTML 코드를 실행한다. 

S3 정적 사이트를 호스팅하는데 저렴하고 안정된 플랫폼으로 사용할 수 있다. S3 버킷을 정적 호스팅으로 구성하면, 버킷 URL 트래픽이 자동으로 지정된 루트 문서로 연결된다. 보통 루트문서는 index.html 이며 HTML 페이지 내 링크를 클릭하면 링크된 문서나 미디어 리소스가 전송된다. 오류 처리와 리다이렉션도 정적 웹사이트 호스팅 프로파일에 통합할 수 있다.

DNS 도메인 이름을 정적 사이트로 라우팅하려면 Route53에서 버킷 엔드포인트를 도메인 이름과 연결한다. S3 버킷이름을 도메인 이름과 똑같게 만들어야 제대로 작동한다. 

무로 SSL/TLS 인증서를 ACM 에 요청해서 사이트를 암호화 하고 S3 버킷을 원본으로 하는 CloudFront 배포판에 인증서를 가져올 수 있다. 

S3 Select와 Glacier Select

AWS 는 S3나 Glacier에 저장된 데이터에 액세스 할 수 있는 또다른 방법을 제공하는데 그것이 바로 Select이다. 이 기능을 사용하면 SQL 과 유사한 쿼리로 저장된 객체에서 관련 데이터만 검색할 수 있으므로 훨씬 효율적으고 저렴하게 작업할 수 있다. 

예를 들어 소매 사이트 판매 , 제고 데이터를 대용량 CSV 파일로 저장하는 경우 회사 마케팅 팀이 영업데이터 중 특정 매장 영업데이터만 정기적으로 분석해야 한다. 이때 S3 Select를 사용하면 전체 데이터를 내려받아서 발생하는 비용을 고려할 필요 없이 일부 데이터만 정확하게 가져올 수 있다. 

Glacier

Glacier는 S3 스토리지 클래스의 일부로 보여진다 대부분 S3 클래스와 마찬가지로 99.9%의 내구성을 보장하고 S3 수명주기에 통합할 수 있다 

Glacier에는 S3와 크게 다른 점이 있는데 S3 단일 객체 최대 크기는 5TB인 반면 Glacier는 40TB까지 대형 아카이브를 지원하고 S3 에서는 암호화를 선택하지만 Glacier는 암호화가 기본이라는 점! 그리고 S3에서는 인간이 읽을 수 있는 이름으로 키를 만들지만 아카이브에는 기계가만든 ID가 주어진다는 점이다. 

그러나 가장 큰 차이점은 데이터를 가져오는데 걸리는 시간으로 S3에서는 데이터를 거의 즉시 액세스 할 수 있지만 Glacier 에서는 객체를 가져오렴녀 몇시간이 걸릴 수있다. 이 차이점은 Glacider 목적을 규정한다. 즉 데이터의 필요성과 사용빈도가 낮은 환경에서 장기적으로 데이터를 보관할 수 있는 저렴한 스토리지로 사용할 수 있다는 것이다. 

Glacier 에서 아카이브라는 용어는 문서 비디오 TAR, ZIP 과 같은 객체를 의미하며 아카이브는 S3 버킷에 해단하는 볼트에 저장된다. 

스토리지 요금 

이번 절에서는 기업의 일반적인 스토리지 사례를 통해 S3 와 Glacier 의 비용을 비교한다. 

회사에서 영업 데이터를 매주 백업할 때 5GB 아카이브가 만들어 진다고 가정한다. 첫 30 일 동안은 Standard 에서 아카이브를 보관하고 다음엔 S3 One Zone으로 변환헤서 90일간 유지하며 120일이 지나면 Glacier로 이동해서 그 이후에는 삭제된다고 가정한다. 

기타 스토리지 관련 서비스 다른 스토리지 관련 AWS 서비스도 알아보자 

EFS

EFS는 자동 확장 가능한 공유 파일 스토리지 로서 VPC 내에서 NFS 로 여러 EC2 인스턴스에 장착하거나, Direct Connect 연결로 온프레미스 서버에서 액세스 할 수 있도록 설계됐다. EFS는 여러 인스턴사가 짧은 지연 시간으로 안전하고 내구성있게 파일을 공유하는데 사용할 수 있다. 

AWS Storage Gateway

온프레미스 로컬 백업과 아카이브 운영 요구 사항을 클라우드 스토리지 서비스를 사용해 해결하려면 구성이 복잡해진다. Storage Gateway를 사용해 소프트웨어 방식의 게이트 웨이 어플라이언스로 다양한 가상 연결 인터페이스를 구현해서 이러한 요구를 해결할 수 있다. 테이프 드라이브 같은 물리적 백업장치를 연결하는 것처럼 어플라이언스를 로컬 장치에 연결하면 S3나 EBS 와 같은 AWS 플랫폼에 저장할 수 있다. 

AWS Snowball 

대용량 데이터 세트를 일반 인터넷 연결로 클라우드에 마이그레이션 하려면 많은 시간과 대역폭이 필요하게 된다 테라바이트 또는 페타 바이트 크기를 백업 또는 실제 사용을 위해 AWS 로 이동할 때 사용할 수 있는 장치가 바로 Snowball 이다. 사용자가 요청하면 AWS는 256 로 암호화한 물리적 Snowball 저장 장치를 사용자에게 배송한다. 사용자가 데이터를 snowball 에 복사한다음 장치를 돌려보내면 Aws 는 그 데이터를 S3 버킷에 올린다. 

2장에서는

EC2 환경을 완벽하게 활용하기 위한 도구와 활용 사례를 알아본다. 

프로젝트에 적합한 하드웨어 리소스 구성 및 EC2 인스턴스 프로비저닝 

애플리케이션 요건에 맞는 운영체제 구성

인스턴스에 필요한 안전하고 효과적인 네트워크 환경 구축

인스턴스에 부팅 스크립트 추가로 애플리케이션을 시작/지원

기관의 요구에 부합하는 EC2 요금 모델 선택

EC2 인스턴스 수명 주기 관리 및 활용 방법 

처리 성능 요구에 맞는 스토리지 드라이브 유형 선택

키 페어 보안그룹 IAM 역할을 이용한 EC2 리소스 보호

관리자 또는 최종 사용자로 인스턴스에 액세스하는 방법 

EC2 인스턴스

물리서버의 기능을 함축적으로 가상화 했지만 실제 서버와 유사하게 작동하며, 스토리지, 메모리, 네트워크 인터페이스 그리고 운영체제가 새로 설치된 기본적인 드라이브가 제공된다. 

사용자는 인스턴스에서 사용할 리소스의 종류 운영체제 종류 실행할 소프트웨어 스택을 선택해서 인스턴스의 운영비용을 결정한다. 

인스턴스 프로비저닝

사용자는 운영체제, 소프트웨어 스택, 하드웨어 사양, 인스턴스를 시작할 환경을 구성할 수 있다. 운영체제는 아마존 머신 이미지를 선택하고 하드웨어는 인스턴스 유형으로 지정한다. 

머신 이미지

EC2를 시작할 때 루트 볼륨에 설치될 운영체제와 소프트 웨어를 기술한 템플릿 문서 이며 네가지 AMI 가 있다. 

빠른시작 AMI

인스턴스 시작 콘솔 화면의 맨 위에 있으며 다양한 리눅스 베포판 등 공동 작업을 수행하기 위한 특수이미지를 포함하고 최신 버전으로 업데이트 하고 공식적으로 지원한다. 

마켓 플레이스 AMI

프로덕션(실제 서비스가 운영되는)환경에서 사용가능한 공식 이미지이며 시스코와 같은 공급업체가 제공하고 지원한다. 

커뮤니티 AMI

십만개 이상의 이미지가 제공되고 있으며 특정한 요구에 맞도록 공급업체가 제작하고 관리한다.

프라이빗 AMI

사용자가 자체 배포한 인스턴스에서 이미지를 생성하여 저장하면 자체 AMI를 만들 수 있다. 

청구에 관한 주요 사항 

EC2 인스턴스의 기본 요금과는 별도로 소프트웨어의 시간당 사용량 또는 라이선스 요금이 계정에 청구될 수 있다. 

인스턴스 유형 

하드웨어 프로파일 즉 인스턴스 유형에 따라 하드웨어 리소스를 인스턴스에 할당한다. 인스턴스 유형은 어떤 워크로드를 계획하고 있느냐에 따라서 달라진다. 

인스턴스 환경 구성

유형 선택만큼 중요한건 어디에서 운영할지 이다. 지리적 리전, 가상 프라이빗 클라우드, 테넌시 모델을 살펴본다. 

AWS 리전

AWS는 전 세계 데이터 센터에 서버를 보유하고 있으며 이는 지리적 리전으로 구성되어 있다. EC2 리소스는 사용자가 선택한 리전에서만 관리할 수 있으며 기본값을 CLI나 SDK에서 설정한다. 리전마다 서비스의 기능 특징, 비용이 다르다. 

VPC

가상 프라이빗 클라우드는 훌륭한 AWS 네트워크 구성 도구로서 인프라를 쉽게 구성할 수 있게한다. VPC를 사용하면 인스턴스를 다른 인스턴스와 쉽게 분리해서 실행할 수 있고 프로젝트 단위나 단계별로 만들어 사용할 수 있다. 예를 들어 

테스트, 스테이징, 프로덕션으로 나누어 사용할 수 있다. 

NAT 게이트웨이나 VPN 연결을 사용하지 않는다면 간단한 생성에는 비용이 들지 않는다. 

테넌시

인스턴스를 시작할 때 테넌시 모델을 선택할 수 있다. 기본 설정은 공유 테넌시이며 여러 인스턴스가 한 물리서버에서 동시에 가상머신으로 실행된다. 기본 설정은 공유 테넌시 이며 여러 인스턴스가 한 물리서버에서 동시에 가상 머신으로 실행된다. 

같은 물리 서버에서 다른 AWS 고객이 소유한 가상머신이 동시에 실행될 가능성은 있어도 인스턴스에 안전하지 않은 상호작용이 발생할 가능성은 희박하다. 

조직의 규정에 인스턴스를 다른 환경과 특별히 격리해야하는 규제사항이 있는 경우 전용인스턴스를 선택하면 그 조직만을 위한 서버에서 인스턴스가 실행된다. 단 전용 인스턴스와 전용 호스트는 공유 테넌시를 사용하는 인스턴스보다 높은 비용이 부과 된다.

인스턴스 동작 구성

EC2 에서 인스턴스 구성 단계에서 사용자 데이터를 지정해 인스턴스가 부팅할 때 명령을 실행할 수 있게하는데, 이를 부트 스트랩이라고 한다. 스크립트 파일을 작성해 콘솔에서 인스턴스를 시작할때 인스턴스의 세부 정보 구성에서 지정하거나 CLI 에서 user-data 값을 사용하면 필요한 상태로 인스턴스를 구성할 수 있다. 

사용자 데이터는 웹 서버를 설치하고 웹 루트에 배포하는 간단한 명령으로 구성할 수 있고 엔터프라이즈 기반 플랫폼에서 작업노드를 설정하는 등 정교한 스크립트로 구성할 수 있다. 

인스턴스 요금

세가지 모델 중 하나를 선택해 EC2 인스턴스를 구매해서 사용할 수 있다.

보통 12개월 미만으로 언제든지 시작할 수 있는 인스턴스를 배포할 때는 시간당 요금으로 지급하는 온디맨드 모델을 선택한다. 

필요에 따라 인스턴스를 시작하고 중지해서 비용을 철저하게 관리할 수 있지만 다른 모델과 비교하면 시간당 요금이 가장 비싸다. 

인스턴스를 1년이상 가동할 계획이라면 1년 또는 3년 기간 약정으로 예약 인스턴스를 구매하면 대폭 할인된 요금 해택을 누릴 수 있다.

갑자기 중단 돼도 피해가 크지 않은 워크로드를 가동할때 스팟 시장에서 인스턴스를 구매하면 비용이 많이 절감된다. 스팟 인스턴스의 개념은 특정 리전에서 실행되는 인스턴스 유형에 대해 사용자가 최대 입찰 요금을 입력해서 인스턴스를 사용하는 것이다. 

인스턴스를 종료하면 기본 스토리지(인스턴스 스토어)에 저장된 데이터는 삭제되는것이 기본이지만

EBS 를 사용하면 인스턴스가 종료된 후에도 데이터를 유지할 수 있다. 

인스턴스 수명 주기

EC2 인스턴스의 상태를 관리하는 방법은 몇가지가 있다. 어떤 방법을 적용하든 인스턴스를 종료하면 사용하던 리소스는 AWS 풀로 반환된다. 

인스턴스를 일정기간동안 사용하지 않을 때는 인스턴스를 중지해 놓고 필요할 때 재시작하면 비용을 절약할 수 있다. 

다만 이때 인스턴스 스토어 볼륨의 데이터는 삭제된다. 

또한 인스턴스에 할당된 임시 퍼블릭 IP 주소는 중지했다가 재시작하면 대개 다른 주소로 바뀌며 재시작 해도 바뀌지 않은 IP 주소가 필요하면 탄력적 IP 주소를 할당해서 인스턴스에 연결해야한다. 

인스턴스가 실행되는 동안에도 언제나 보안 그룹을 편집하거나 변경해서 인스턴스 액세스 정책을 업데이트 할 수 있고 물리서버에서 작업하듯이 인스턴스 유형을 변경해 메모리 스토리지 용량을 줄이거나 늘릴 수 있지만 인스턴스를 중지하고 유형을 변경한 뒤에는 반드시 다시 시작해야한다.

리소스 태그

AWS 계정에 리소스를 많이 배포할수록 리소스를 제대로 추적하기 어려워진다. 또한 VPC 두세개에 스토리지 볼륨, 보안 그룹, 탄력적 IP 주소를 연결한 EC2 여러개를 분산해 놓으면 매우 복잡해진다. 

이런 경우, 리소스를 빠르게 식별할 수 있도록 리소스마다 목적 및 다른 리소스와의 관계를 지정해 놓으면 복잡성이 줄어들텐데, 이를 위한 가장 좋은 방법은 일관된 명명 규칙에 따라 태그를 붙이는 것이다. 

AWS 계정에서는 리소스에 식별 표를 붙일 수 있으며 이것이 바로 리소스 태그다. 

EC2를 비롯해 AWS 환경에서 사용할 수 있는 모든 리소스에 태그를 붙일 수 있으며 하나의 태그는 키와 값으로 구성된다. 프로덕션에 배포한 각 구성요소에 태그를 연결할 때, 서버 인스턴스의 키로 프로덕션서버, 값으로 서버1, 서버2등을 지정할 수 있다. 서버에 연결된 보안 그룹에도 키는 프로덕션 서버로 값은 시큐리티그룹1 으로 부여할 수 있다. 태그를 적절히 사용하면 리소스의 가시성을 높이고 더 쉽고 효과적으로 관리할 수 있다. 

서비스 할당량

기본적으로 AWS 계정당 시작할 수 있는 특정 서비스의 인스턴스 수는 제한 되어있다. 계정 내에서 리전당 할당량이 있는 서비스도 있고 글로벌 할당량이 있는 서비스도 있다. 예르르 들어 한 리전당 만들수있는 VPC는 5개고 계정당 허용된 키페어는 5000개 이다. 많일 사용자가 특정서비스의 할당량을 올리길 원한다면 AWS에 요청하면된다. 

EC2 스토리지 볼륨 

스토리지 볼륨은 물리 드라이브를 가상으로 나눈 공간이며, 인스턴스에서 실행되는 운영체제에서는 모든 AWS 볼륨이 실제 물리 드라이브 처럼 보인다. 

EBS 볼륨

EBS는 필요한 수만큼 인스턴스에 연결할 수 있으며, 물리서버의 하드 드라이브, 플래시 드라이브 USB 드라이브와 유사하게 사용된다. 물리 드라이브에서와 같이 어떤 EBS 볼륨 유형을 선택하느냐에 따라 성능과 비용은 달라진다. 

AWS는 SLA 에서 99.9% 가용성으로 EBS 볼륨에 저장한 데이터의 안정성을 보장하고 있으므로 장애에 대한 걱정은 하지 않아도 된다. EBS 드라이브에 장애가 생겨도 그 데이터는 이미 중복으로 저장돼 있어서 문제를 인식하기 전에 복구될 가능성이 크다. 따라서 사용자는 실질적으로 얼마나 빠르고 효과적으로 액세스 할 것인가에 관심을 기울이면 된다. 

현재 EBS 볼륨 유형에는 SSD 기술을 사용하는 두가지 유형과 기존 HDD 기술을 사용하는 두가지 유형이 있다. 불륨 유형의 성능은 최고 IOPS 로 측정한다. 

EBS 볼륨 기능

모든 EBS 볼륨은 스냅샷을 통해 복사할 수 있고, 기존 스냅샷을 다른 인스턴스에 공유해서 연결할 수 있으며, AMI로 등록할 수 있는 이미지로 변경할 수 있다. 실행중인 인스턴스에 연결된 EBS 볼륨에서도 직접 AMI 이미지를 생성할 수 있지만 데이터 손실이 없게하려면 우선 인스턴스 운영체제를 종료하고 이미지를 생성하는 것이 좋다. 

EBS 볼륨을 암호화해서 EC2 인스턴스가 저장하거나 송수신 하는 데이터를 보호할 수 있으며 EBS 에서는 내부에서 암호화키를 자동으로 관리하거나 KMS 에서 제공하는 키를 사용할 수 있다. 

인스턴스 스토어 볼륨

인스턴스 스토어 볼륨은 EBS 볼륨과는 다른 임시 디스크며, 디스크가 연결된 인스턴스가 종료됐을 때 저장된 데이터는 영구히 삭제된다. 

EBS 대신 인스턴스 스토어를 사용하는 이유는 다음과 같다. 

인스턴스 스토어 볼륨은 인스턴스를 호스팅하고 있는 서버에 물리적 고속 인터페이스로 연결된 SSD 이다. 

인스턴스 스토어 볼륨 요금은 인스턴스 요금에 포함되어 있다. 

인스턴스 스토어 볼륨은 단기 수행역할 이나 외부에서 데이터를 가져와서 처리 후 폐기하는 배포 모델에서 특히 적합하다. 

인스턴스 스토어 볼륨을 사용할 수 있는 인스턴스 유형은 따로 있으므로 배포할 때 이 점을 염도해야한다. 

EBS와 인스턴스 스토리지를 잘 사용하고 있더라도 외부에 대용량 데이터 세트를 두는 것이 훨씬 나을 때가 있다 S3 서비스의 사용사례는 다양하며 컴퓨팅 작업에 직접 사용되는 파일 부터 데이터 베이스까지 저장할 수 있으면서도 훨씬 저렴하게 사용할 수 있다. 

인스턴스 액세스

인스턴스는 네트워크에 연결된 모든 장치와 마찬가지로 고유한 IP로 식별된다. 모든 인스턴스에는 기본적으로 최소 한개의 프라이빗 IPv4주소가 할당된다. 

프라이빗 서브넷에서 만들어진 인스턴스는 서브넷 내부에서만 통신할 수 있고 인터넷과 직접 연결할 수 없다. 

다른 리소스와 연결이 필요로 되는 인스턴스에 여러개의 네트워크가 있어야 하는 경우 하나 이상의 가상 탄력적 네트워크 인터페이스를 만들어 인스턴스에 연결할 수 있다. 

이때, 각각의 인터페이스는 기존 서브넷과 보안그룹에 연결돼어 있어야 하며, 인터페이스에 서브넷 범위의 정적 IP 주소를 할당하거나 인터넷에 액세스 하기 위한 퍼블릭 IP 주소를 할당할 수 도 있다. 앞서 인스턴스 수명주기에서 살펴봤듯 인스턴스에 할당된 기본 퍼블릭IP 는 일시적이고 재부팅하면 바뀔수 있으므로 장기적인 배포를 위해서는 영구적이고 탄력적인 IP를 할당하는 것이 바람직 하다. 

실행중인 인스턴스에 연결돼 있기만 하면 탄력적 IP 에는 비용이 부과되지 않는다. 

2장 후반부에서는 보안 측면에서 관리자로 인스턴스에 액세스 하는 방법을 다룬다. 실행중인 인스턴스에 대한 많은 정보를 인스턴스 메타 데이터 시스템을 통해 확인할 수 있으며, 인스턴스에 로그인 한 후 명령줄에서 curl 명령을 실행하면 아래와 같은 데이터 목록이 표시된다. 

인스턴스 보안

사용자에게는 무단으로 EC2 인스턴스가 사용되지 않도록 적절하고 효과적으로 액세스 제어를 구성해야할 책임이 있다. 

AWS 는 이를 위해 보안그룹, IAM 역할, NAT 인스턴스 , 키페어 등 네가지 도구를 지원한다.

보안 그룹 

보안 그룹은 방화벽 역할을 한다. 보안 그룹의 기본 설정은 수신하는 모든 트래픽을 거부한다. (수신 거부) 보안 그룹에 지정한 트래픽 유형만을 허용하는 정책 규칙을 설정하며, 네트워크에서 송수신하는 모든 데이터 패킷은 그 규칙에 따라 평가해서 허용 또는 거부된다. 

보안 그룹은 원본과 대상 대상 네트워크 포트 사용 프로토콜을 검사해서 트래픽을 재평가 한다. 예를 들어 사무실 컴퓨터의 퍼블릭 IP 주소를 원본 IP 주소로 하고 TCP-SSH(22) 포트를 사용하는 패킷이 특정 인스턴스에 액세스 하도록 허용할 수 있다. 

보안 그룹에서는 정교한 규칙 세트를 쉽게 만들어서 서비스 액세스를 관리할 수 있으므로 전 세계에 웹사이트를 공개하더라도 백엔드 서버에는 팀 구성원만 액세스 하게 할 수 있다. 

보안 그룹에서는 인스턴스 수준에서 트래픽을 제어한다 

인스턴스 수준이 아닌 서브넷 수준에서 트래픽을 제어할때는 NACL을 사용한다. 

IAM 역할

IAM 역할을 사용해서 EC2 인스턴스를 비롯한 AWS 리소스에 액세스하는 것을 제어할 수 있다. IAM 역할은 AWS 계정 내 특정 서비스 또는 리소스에 작업을 수행할 수 있는 권한을 부여하며 특정 사용자나 리소스에 역할을 할당하면 그 사용자나 리소스는 역할 정책에 포함된 다른 리소스에 액세스 할 수 있다. 

제한된 수의 다른 리소스나 사용자에게 역할을 부여하면 EC2 인스턴스 등의 리소스에 독점적으로 액세스 할 수 있는 권한을 부여할 수 있다. 

NAT 디바이스

때로는 EC2 인스턴스에 퍼블릭 IP 주소를 연결하지 않고 네트워크 노출을 제한할 필요가 있다. 그러나 보안 패치와 소프트웨어 업데이트 등을 받으려면 제한적으로 인터넷에 연결돼야하는 문제점이 있다. 

이를 해결하는 방법은 특수한 장치를 통해 프라이빗 인스턴스에서 인터넷으로 향하는 트래픽을 라우팅하는 것이다. 이를 위해 AWS는 NAT 인스턴스와 NAT 게이트웨이를 제공해서 트래픽을 라우팅하게 한다. NAT 게이트웨이는 관리형 이므로 직접 인스턴스를 시작하고 유지 관리할 필요가 없다. 두가지 모두 매월 요금이 청구된다. 

키 페어

관리를 위해 실행중인 인스턴스에 연결할 때 암호화 되지않은 일반 텍스트를 사용한 원격 세션 연결방식은 사용하지 않는다 세션을 제대로 보호하혀면 키 페어를 생성해서 퍼블릭 키는 인스턴스에 저장하고 다른 절반인 프라이빗 키는 사용자 단말에 저장해야한다. 

AWS 가 생성하는 키 페어는 생성한 리전 내에 설치되어 있으며 삭제할 때 까지 새로 시작하는 인스턴스에 사용할 수 있는데, 만약 분실되었다가 노출되었다면 저장한 키를 반드시 삭제해야한다. 

기타 관련 서비스 

시스템 매니저

시스템 메니저 서비스는 AWS 클라우드와 온프라미스 인프라에서 운영하는 리소스를 모니터링하고 관리하기 위한 도구 모음이다.

배치 그룹

배치 그룹은 지연시간이 짧은 네트워크 상호 연결이 필요한 여러 EC2 인스턴스에 특히 유용하며 다음과 같은 두가지 전략이 필요하다. 

클러스터 그룹은 단일 가용영역안에서 물리적으로 근접하고 서로 연결된 인스턴스를 시작한다. 

분산형 그룹은 장애 관련 데이터나 서비스 손실을 줄이기 위해 분리된 하드웨어에 인스턴스를 분산한다.

Beanstalk

사용자가 Beanstalk 에서 몇몇 파라미터를 정의하고 앱 코드를 올리려면 실행에 필요한 인프라를 구성 실행 유지한다. Beanstalk 에는 인스턴스 로드 밸런싱 오토스케일링, RDS 데이터 베이스 인스턴스 전체 네트워크 패치 등이 포함되어 있는데 이들은 Beanstalk를 사용하지 않으면 직접 설치해야하는 항목들이다. 인프라 비용 이외 추가 비용은 없다. 

ECS 와 Fargate

대규모 도커 컨테이너 기반에서 실행하는 앱은 본질적으로 AWS 와 같은 클라우드 플랫폼에서 적합하다. 

이러한 작업을 하려면 예전에는 잘 구성한 인스턴스를 여러개 만들어서 직접 Docker 호스트에 구성해야 했다. 

그러나 ECS를 사용하면 미리 구축된 호스트 인스턴스를 시작하고 도커 컨테이너가 작업하는 방식을 정의 할 수 있다 

컨테이너를 자동화하고 리소스와 완벽하게 통합된 인프라에서 운영할 수 있다. 

최근에 출시된 Fargate 도구는 ECS 구성 프로세스를 더욱 추상화 했기 때문에 컨테이너 인스턴스를 실행하고 구성할 필요조차 없으며 패키징과 환경요구 사항 설정만 수행하면 된다. 

AWS Lambda 

서버리스 앱은 프로그래밍 코드 기반으로 실행된다. 서버에서 동작하지만 사용자가 서버를 제어하는 대신 사전 설정된 이벤트로 람다 서버를 트리거 해서 코드를 실행하도록 구성한다. 

VM Import/Export 

VM Import/Export를 사용하면 온프레미스 VMware 환경과 계정간에 S3를 거쳐서 가상 머신 이미지를 쉽게 이동할 수 있으며, 마이그레이션이 가능하다. 

ELB와 Auto Scaling

로드 밸런서는 외부 사용자의 요청을 여러 인스턴스에 전송해 리소스를 더욱 효율적으로 분산해서 사용할 수 있게하고 사용자 경험을 향상시킨다.

Auto Scaling은 사전정의된 임곗값에 반응해서 수요에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄인다. 

워크로드란 무엇인가

워크로드는 고객 대면 앱이나 백엔드 프로세스 같이 비즈니스 가치를 창출하는 리소스 및 코드 모음을 말한다. 

워크로드는 단일 AWS 계정에서 리소스 하위 집합으로 구성되거나, 여러 AWS 계정에 적용되는 다수의 리소스 컬렉션이 될 수 있다. 

AWS = 워크로드에 최적화 된 플랫폼

AWS는 각 기업이나 기관의 워크로드에 최적화된 플랫폼을 제공한다.

1장에서 알아볼 내용?

클라우드 컴퓨팅과 다른 앱 및 클라이언트 서버 모델의 차이점

AWS 플랫폼이 제공하는 안전하고 유연한 가상 네트워크 환경

AWS 가 제공하는 높은 수준의 서비스 안정성

AWS 기반 리소스 액세스와 관리

AWS 배포에 관한 문서와 지원 

클라우드 컴퓨팅과 가상화

모든 클라우드 운영기술의 토대 = 가상화 

가상화를 사용하면 단일 물리서버의 하드웨어 리소스를 더 작은 단위로 나눌 수 있으며 

물리 서버는 가상머신 여러 개를 호스트 할 수 있다. 

가상머신은 자체적인 메모리, 스토리지, 네트워크를 가지고 자신만의 운영체제를 독자적으로 실행한다. 

이런 가상화의 장점인 유연성 덕분에 가상 서버를 단 몇초만에 프로비저닝해서 필요한 시간만 정확하게 실행하고,

언제든지 종료해서 사용하던 리소스를 언제든지 종료하고 다른 워크로드에 즉시 활용이 가능하다. 

가상화는 또한, 리소스를 집적해서 사용하므로 하드웨어 가치를 최대한 끌어낼 수 있다. 

클라우드 컴퓨팅 아키텍처

AWS 와 같은 클라우드 제공업체는 수십만대의 서버와 그것을 연결하기 위한 네트워크를 소유하고 있으며 효율적으로 조합하여 가상 서버를 제공한다. 

클라우드 컴퓨팅 플랫폼에서는 컴퓨팅 리소스 풀을 구축하며, 

온디맨드와 셀프 서비스 방식을 사용한다.

여기서, 온디맨드는 사용량을 측적하고 사용량에 따라 비용을 청구한다. 

클라우드 컴퓨팅 최적화

클라우드는 확장성과 탄력성을 가지고 있으며 기존 인프라보다 저렴하므로 기업의 워크로드에 널리 사용된다. 

클라우드에서 앱이나 서비스를 배포하기 위한 3요소는 다음과 같다. 

확장성 : 수요가 급격히 증가해도 인스턴스를 동적으로 추가하여 대응(Auto Scaling)

탄력성 : 수요가 떨어질때 용량을 자동으로 줄임

비용관리 : 자본지출에서 운영비용으로 지출을 바꿀수 있다. 

AWS 클라우드

AWS 서비스 범주 

컴퓨팅

네트워킹

스토리지

데이터베이스

애플리케이션관리

보안과 자격 증명

애플리케이션 통합

AWS 핵심 서비스 

컴퓨팅: EC2, Lambda, AutoScaling, ELB, Beanstalk

네트워킹 : VPC, Direct Connect, Route 53, Cloud Front

스토리지 : S3, Gracier, EBS(Elastic Block Store), Storage Gateway

데이터베이스 : RDS, DynamoDB

애플리케이션 관리 : Cloud Watch, CloudFormation, CloudTrail, Config

보안 자격 증명 : IAM, KMS, Directoy Service

애플리케이션 통합 : SNS, SWF, SQS, API Gateway 

AWS 플랫폼 아키텍처

AWS는 전세계를 거쳐서 데이터 센터를 유지 관리하고 있다. 

(+) 엔드포인트 주소는 AWS 리소스에 원격으로 액세스 하기 위해 애플리케이션 코드나 스크립트에 포함된다. 

특정 서비스를 지정하기 위해 cloudformation.us-east-2.amazonaws.com 과 같이 작성된다. 

짧은 지연시간 액세스를 보장하는 것은 매우 중요하기 때문에 Cloud Front, Route 53, Firewall Manager, Sheild, WAF 등의 서비스는 엣지 로케이션에서 제공된다. 

AWS 계정 내 물리적 AWS 데이터 센터는 AZ 또는 가용영역으로 불리며 us-sasr-1a 같은 이름으로 표시된다. 

한 리전 내에 가용영역은 최대 6개 까지 있으며, 리전 내에는 일종의 네트워크 주소공간인 VPC가 있는데 리소스는 이 VPC에 배포된다. VPC는 그 안에 네트워크 서브넷을 만들 때, 특정 가용영역과 연결된다. 

VPC를 이용하면 리소스를 효과적으로 격리하고 내구성을 높이기 위한 복제를 수행할 수 있다. 

AWS 안정성과 규정 준수

다양한 인증을 준수한다. 

AWS 공동 책임 모델 

AWS와 사용자가 책임을 분담하는 구조를 따르고 있다. 

클라우드 인프라를 안정적으로 관리하는 일은 AWS 책임이지만, 리소스를 사용하는 것은 사용자의 일이며 그에 따른 책임도 사용자에게 있다. 

사용자 책임

-> 사용자 데이터, 사용자 앱과 액세스 관리, 운영체제와 네트워크 액세스 구성, 데이터 암호화 

AWS 책임

-> 하드웨어와 네트워크 유지보수, AWS 글로벌 인프라, 관리형 서비스 

AWS 서비스 수준 계약

클라우드에서 성능과 안전을 보장한다는 것은 AWS에 서비스 중단이나 보안 침해가 발생하지 않는다는 의미는 아니다. 이때 중요한점은 언제 장애가 발생할 것인가 이다. 

앱을 지리적으로 분산하고 내결함성이 있도록 구축하면 장애가 발생하더라도 사용자는 거의 모르고 지나갈 것이기 때문애 장애에 대한 적절한 대응이였다고 볼 수 있다. 

AWS 작업

AWS 서비스를 실행하려면 해당 서비스를 관리할 도구가 있어야한다. 

종류 

Management Console

AWS CLI

AWS SDK

기술지원 및 온라인 리소스

지원플랜 

기타 지원 리소스