AWS SAA-C02 - (1) 개념 정리 ; 모의고사 오답 개념 정리

[Redshift]

● 스냅샷용으로 무료 스토리지를 제공하고 있지만, 스토리지 용량이 일정 수준을 넘어서면 과금이 발생한다. 빈 스냅샷의 용량이 상한에 도달하면 과금이 된다. 따라서 자동 스냅샷을 저장하고, 보존기간을 바꿔 불필요한 수동 스냅샷을 줄일 필요가 있다. 

● 확장 VPC 라우팅

확장 VPC 라우팅을 사용하면 Amazon Redshift는 클러스터와 데이터 리포지터리 사이의 모든 Copy와 Unload트래픽이 Amazon VPC을 통하도록 강제한다. 이 설정을 통해 VPC 엔드 포인트, VPC 엔드 포인트 정책, 인터넷 게이트 웨이, 도메인 네임 시스템(DNS)서버 등의 VPC의 기능을 Redshift로 사용하는 것이 가능하다. 이러한 기능을 사용하여 Amazon Redshift 클러스트와 다른 리소스간의 데이터 플로우를 상세히 관리할 수 있게 되어, VPC 플로우 로그를 사용한 Copy와 Unload 트래픽을 감시할 수 있다. 이 기능은 무료로 비용에 영향을 미치지 않는다.

 확장된 VPC라우팅은 VPC 보안 그룹, 네트워크 ACL, VPC 엔드 포인트, VPC 엔트포인트 정책, 인터넷 게이트 웨이, 도메인 네임 시스템(DNS) 서버 등의 스탠다드 VPC 기능을 사용할 수 있다.

 이 기능을 사용하여 Redshift 클러스터와 다른 리소스간의 데이터 흐름을 상세하게 관리한다. 확장 VPC 라우팅을 사용하여 VPC로부터 트래픽을 라우팅하는 경우에는 VPC 플로우 로그를 사용하여 Copy와 Unload트래픽을 감시하는 것도 가능하다.

● Amazon Redshift에서 이용가능한 것은 서브 인스턴스이다. Redshift는 1년 혹은 3년간 계약을 하여 온디맨드 요금과 비교하면 최대 75%까지 비용을 절약할 수 있다.

● Redshift Spectrum

Redshift Sepctrum을 이용하여 S3 버킷을 RedShift의 해석용 데이터 레이크로써 구성할 수 있다.

Amazon S3의 엑사 바이트의 비구조화 데이터에 대해서 SQL 쿼리를 직접실행할 수 있다. 얻어진 데이터를 바탕으로 쿼리의 합산능력을 자동적으로 스케일링하기 때문에, 데이터셋의 사이즈와 관계없이, Amazon S3에 대한 쿼리는 고속으로 실행된다. 

Redshift Sepctrum을 사용하면 Amazon S3에 저장되어 있는 파일을 Redshift에 로드하거나 별도의 특수 준비없이 고속의 쿼리를 실행할 수 있다.

※ Redshift Sepctrum 은 S3의 오브젝트 일부를 취득하여 분석을 할 수는 없다.

● WorkLoad Management(WLM)

Redshift의 WorkLoad Management(WLM)를 이용해서 쿼리 처리를 실시할 때에 쿼리 처리를 큐로써 실행 순서를 정의하는 것이 가능하다. WLM은 Redshift의 쿼리 처리에 대해서 할당된 Redshift의 리소스를 지정하는 기능이다. 사전에 WLM로써 큐를 준비해두고 큐에 대해 할당된 메모리의 비율이나 병렬도, 타임아웃의 시잔을 지정하는 것으로 쿼리에 대해 리소스 배분을 결정하거나, 장시간 실행된 쿼리를 멈추고 클러스터 리소스를 낭비하지 않도록 할 수 있다.

※ Lambda함수나 SQS를 작성하여 Redshift에 대한 큐를 처리하는 것이 불가능한 것은 아니지만, 모든 기능이 이미 준비되어 있는 WLM을 사용하는 것이 좋다.

● Redshift는 행지정의 클러스트 처리를 통한 고성능 DWH를 제공하고 있다.

※ Redshift에는 스팟 인스턴스를 설정할 수 없다.

※ Redshift에서는 예약된 리저브드 노드라는 노드는 선택할 수 없다.

● Amazon Redshift는 클러스트에 대해서 데이터 베이스의 암호화를 유효화하여 보관 데이터를 보호할 수 있다. 클러스터에 대해 암호화를 유효화하여 클러스터와 그 스냅샷의 데이터 블록 그리고 시스템 데이터가 암호화할 수 있다.

Amazon Redshift는 암호화 키의 계층을 사용하여 데이터 베이스를 암호화한다. AWS Key Management Service(AWS KMS) 혹은 하드웨어 세큐리티 모듈(HSM) 중 하나를 사용하여 그 계층의 최상위 암호화 키를 보관할 수 있다. Amazon Redshift로 암호화에 사용하는 프로세스는 키의 관리 방법에 의해 다르다. 

Amazon Redshift는 AWS KMS와 통합되어, 암호화를 구성할 수 있다. 따라서 HSM은 통합될 수 없다. HSM을 사용할 때에는 클라이언트와 서버의 증명서를 사용하여 Amazon Redshift와 HSM 사이에서 신뢰할 수 있는 접속을 설정할 필요가 있다.

※ SSL/TSL은 통신의 암호화에 이용한다. Redshift내의 데이터의 암호화에 이용되지 않는다.

※ CSE는 클라이언트 사이드 암호화의 약어이다. Redshift에서는 서버 사이드 암호화에 사용된다.

 

[Auto Scaling]

● 인스턴스 실행시에 문제가 발생하면 Auto Scaling은 그룹 내에 실시되는 1개 이상의 프로세스를 중단하여 개발자는 그 프로세스는 임의의 기간에 재개할 수 있다. 그 특정 기간에 Auto Scaling의 스케일링 설정에서 스케일링를 바탕으로 스케일 아웃을 설정할 필요가 있다. 

● Auto Scaling은 실행한 인스턴스에 대해 정기적으로 헬스체크를 실시한다. 이 헬스케츠에는 EC2 타입과 ELB타입 두 가지스 타입이 존재한다.

1) EC2 타입

EC2 상태가 running이 외의 다른 상태일 경우, 혹은 시스템 상태가 imparied인 경우에는 그 인스턴스에 이상이 있다고 판단한다. 

2) ELB 타입

인스턴스의 상태 확인과 ELB의 헬스 체크로부터 인스턴스의 상태를 파악한다. 

따라서 Auto Scaling이 EC2타입의 헬스체크를 이용하고 있는 경우, ELB의 헬스 체크의 결과 여부와 관계없이, EC2 인스터스쪽의 상태에 문제가 있다면 Auto Scaling이 실행되지 않는다.

● 쿨 다운 기간에 의해 이전의 스케일링 액티비티가 실행되기 전, 일정 기간 Auto Scaling 그룹은 추가 인스턴스를 실행 혹은 해방하는 것이 불가능해진다. 이 "일정 기간"을 길이는 인스턴스의 웜업(Warm up)기간이나 그 외의 어플리케이션의 니즈를 근거로 설정할 수 있다. 기본 설정은 300초이다. Auto Scaling 그룹의 쿨다운 기간을 0로 설정할 수 있으므로, 대기시간없이 EC2를 정지하는 것도 가능하다.

 Auto Scaling 그룹에 예정된 스케일링 정책을 설정하여 오전 10시전에 스케일링하여 과부하되기 전에 EC2 인스턴스 수를 늘리는 처리를 할 수 있다.

● Auto Scaling의 동적 스케일링을 통해 CPU 이용율 상황에 따른 자동 스케일링을 유효화한다. 

● Auto Scaling의 Desired capacity의 인스터스 수를 늘리는 것으로 일시적인 리퀘스트 유입 증가에 대비하여 현재 인스턴스 수를 수정으로 증분시킬 수 있다. Desired capacity를 설정하는 것으로 기존의 Auto Scaling 그룹의 사이즈는 언제든지 수동으로 변경하여 실행하는 인스턴스 수를 증가시킬 수 있다.

● Auto Scaling 설정 방법

1) 수동 스케일

수동 스케일을 이용하여 기존의 Auto Scaling 그룹의 사이즈를 언제든지 변경할 수 있다. 수동 스케일링은 부하 시간이 명확한 오토 스케일링 설정에 부적합하다.

2) 스케줄드 스케일링

스케줄에 따라 스케일링하여 예상 가능한 부담의 변화에 대응하는 독립의 스케일링 스케줄을 설정할 수있다. 일정한 시간에 부하가 급격히 증가하는 경향이 있다면 그 시간을 지정하여 스케줄드 스케일링을 설정하는 것이 최적의 방법이다.

3) 동적(다이나믹) 스케일링

동적 스케일링을 설정하는 것으로 수요증감에 맞게 스케일하는 방법을 정의해서 자동으로 스케일링이 일어나도록 할 수 있다.

4) 스텝 스케일링 정책

스텝 스케일링 정책은 일련의 스케일링 조정값(스텝 조정값)을 바탕으로, Auto Scaling그룹의 현재의 용량을 증감시킨다. 단계 스케일링 정책은 CloudWatch 매트릭스로부터 얻어진 값(CPU사용율이나 SQS 큐 사이즈 등)의 임계값을 넘어 발생된 알람에 대응하여 값 베이스로 스케일링 액션을 개별로 설정할 수 있는 기능이다. 

설정시에 알람 초과를 바탕으로 인스턴스 수를 동적으로 스케일링하는 1개 이상의 스텝 조정값을 지정한다. 각 스텝 조정값은 아래와 같이 지정할 수 있다.

- 메트릭스 값의 최저값 

- 메트릭스 값의 최고값

- 스케일링 조정 타입을 바탕으로 스케일링할 양

Amazon EC2 Auto Scaling는 CloudWatch로부터의 최신의 메트릭스 데이터 포인트를 값으로써 적용한다. 스텝 조정에 의해 정의되어 있는 최고값과 최저값에 대해 이 집약 메트릭스 값을 비교하는 것으로 실행할 스텝이 조정된다.

스텝 스케일링 정책을 통해 임계값이 50%이면 1대 추가, 60%면 2대 추가, 70%이면 3대 추가와 같은 식으로 일정 임계값을 넘었을때 알람으로부터 보고된 값에 의해 몇 대를 추가할 것인지 지정할 수 있다.

5) 간단 스케일링 정책

보통의 스케일링을 이용하는 정책으로 상세한 스텝을 조정할 수 없다.

● Auto Scaling 그룹

Auto Scaling의 쿨 다운 기간 동안, Auto Scaling 그룹이 추가의 인스턴스을 실행 혹은 삭제하는 것이 불가능하게 된다. 이 기간은 인스턴스 웜업 기간이나 그 외 다른 어플리케이션의 니즈에 근거해서 설정할 수 있다. Auto Scaling 그룹은 단순한 스케일링 정책을 이용하여 동적으로 스케일링한 후에 스케일링 액티비티를 재개하기 전에 쿨다운 기간이 끝나기를 기다린다. 

※ Auto Scaling에 의해 증가되는 최대 인스턴스 수를 늘려도 스핀 업했을 때, 어플리케이션의 쿨 다운 시간에 대해서는 영향을 미치지 않는다. 어디까지나 최대 사용 대 수를 늘릴 뿐이다.

 

[Storage Gateway]

● AWS Storage Gateway는 온프레미스로부터 실질 무제한의 클라우드 스토리지로의 액세스를 제공하는 하이브리드 클라우드 스토리지 서비스이다. Storage Gateway를 사용하여 스토리지 관리를 간략화하고 주요한 하이브리드 클라우드 스토리지의 사용예로 비용을 절감할 수 있다.

● Storage Gateway의 게이트웨이

▷ 볼륨형 게이트웨이

스케줄된 스냅샷이라는 기능이 존재한다. 이 기능은 스냅샷을 취득하는 것을 스케줄로써 관리하는 방식이다.

▷ 캐시형 볼륨

자주 액세스하는 데이터를 로컬에 저장해두면서 Amaozn S3를 프라이머리 데이터 스토리지로써 사용할 수있다. 캐시된 볼륨은 빈번히 액세스하는 데이터에 대해 낮은 레이턴시(지연)으로 액세스할 수 있도록 하고 있다. 최대 32TiB의 사이즈의 스토리지 불륨을 작성하고 그것을 온프레미스 어플리케이션 서버로부터 iSCSI 디바이스를 매개로 붙이는 것도 가능하다. 캐시형 볼륨은 AWS쪽을 프라이머리로써 이용할 때 사용한다.

 

[Amazon ECS(Elastic Container Service)]

● Docker 컨테이너를 서포트하는 확장성과 퍼포먼스가 우수한 컨테이너  오케레이션 서비스이다. ECS에 의해 컨테이너된 어플리케이션을 AWS에서 간단히 실행 혹은 스케일 할 수 있지만, 디플로이 관리와 자동화는 AWS Elastic Beanstalk와 연동할 필요가 있다.

● Amazon EC2 컨테이너 오케스트레이션

Amazon EC2 컨테이너 오케스트레이션에 의해서 중요한 작업과 중요하지 않은 작업 양쪽에 대해서 태스크 정의를 나눠 인스턴스 구성을 구분할 수 있다. 이러한 작업에 의해, 관리 업무는 일시적으로 실행되는 날 중요한 업무와 중기간 이용할 필요가 있는 중요한 업무를 나눌 수 있다. 일시적인 업무에는 스팟 인스턴스를 이용하고 중중기 이용되는 업무에 관해서는 리저브드 인스턴스를 이용하여 비용을 낮출 수 있다.

● 실행 타입

1) Fargate 실행 타입

백엔드 인프라 구조를 프로비저닝 혹은 관리할 필요 없이, 컨테이너화된 어플리케이션을 실행할 수 있다. 태스크 정의를 등록하는 것으로, Fargate가 컨테이너를 실행한다.

Fargate 기동 타입에서는 유저가 실시하는 설정 작업은 컨테이너 안에 어플리케이션의 패키지화, CPU 요건이나 메모리 요건의 지정, 네트워킹 정책이나 IAM 정책을 정의, 어플리케이션의 기동만이 존재한다. EC2와 같이 인스턴스의 상세한 설정 등이 필요하지 않기 때문에 EC2 실행 타입보다 관리할 필요가 없다.

※ Fargate는 ECS 혹은 EKS를 이용할 때에 선택할 수 있는 컴퓨터 엔진 실행타입이다.

2) EC2 실행 타입

관리하고 있는 Amazon EC2 인스턴스의 클래스터로 컨테이너화된 어플리케이션을 실행할 수 있다. EC2의 설정이 필요한 실행 타입이다.

컨테이너 어플리케이션을 실행하는 인프라스트럭처에 대해서 서버 레벨의 상세한 컨트롤을 실행할 수 있다. EC2 인스턴스와 동일한 서버 클래스에서 상세한 조정을 할 수 있어 커스터마이즈의 폭이 넓지만, 관리 오버헤드가 높아진다.

※ 2019년 11월부터 AWS Fargate 상에서 Kubernetes를 이용할 수 있게 되어 ECS와 Fagate 조합보다 EKS와 Fargate를 조합해서 사용하는 것이 자동화에 최적화된 조합이다. 

 

[프로토콜]

NFSv4	SMB	Secure File Transfer Protocol(SFTP)
Amazon EFS Amazon Elastic Block Store (EBS)	Amazon FSx	S3

 

[사전 서명된 URL]

유저가 객체에 접근하도록 허가하고 있는 경우 다른 유저가 그 사전 서명된 URL를 사용하여 대상 객체에 액세스할 수 있다. 이 기능을 이용하여 특정 유저가 어플리케이션이 대상 이미지로의 접근이 가능한 기간을 정하는 것도 가능하다.

 

[CloudFormation]

● CloudFormation은 AWS의 인프라 구조를 JSON와 YMSL로 작성하여 프로비저닝하기 위해 공통 언어를 제공하는 서비스이다.

● 템플릿

템플릿으로부터 AWS 리소스를 자동 구축하기 위한 일련의 셋 사양이다. AWS 리소스를 항상 일정한 설정으로 프로비저닝할 수 있다. 템플릿을 통해 테스트 환경 등의 환경을 만들기에 용이하다. 

1) Resources로는 EC2 등의 스택 리소스와 그 프로퍼티(속성)을 지정한다.

2) Parameters로는 실행시에 템플릿에 전달한 값을 지정한다.

3) Description 섹션에는 그 템플릿에 관련된 커맨트를 지정한다.

● CloudFormation은 1개의 스택의 출력값을 다른 스택에 전달하여 스택간을 연동해서 인프라를 구성하는 것도 가능하다. 즉  CloudFormation 스택은 기존의 리소스를 import하는 것이 가능하다. 이것은 export된 출력값을 다른 스택쪽에 이용할 때 사용한다. 스택간에 정보를 공유하기 위해서는 스택의 출력 값을 export한다. 스택의 출력 값을 export하기 위해서는 스택의 템플릿을 Output 섹션의 Export 필드를 사용한다.

● AWS SAM

AWS SAM은 서버리스 어플리케이션 구축용의 디플로이 툴이다. YAML을 사용하여 서버리스 어플리케이션의 Lambda함수, API, 데이터베이스, 이벤트 소스맵핑을 모델링한다. AWS SAM은 CloudFormation과 연계하여 서버리스 어플리케이션을 전개한다. 이때에 SAM이 SAM 구문을 AWS CloudFormation 구문으로 변환 및 확장하여 서버 리스 어플리케이션의 구축을 고속화할 수 있다.

● CloudFormation 스택셋

CloudFormation 스택셋을 이용하면 CloudFormation 템플릿 안에 AWS 리소스의 설정을 정의하여 1개의 템플릿에 의해 여러 개의 AWS 계정이나 리전에 리소스를 전개할 수 있다. 크로스 어카운트나 크로스 리전의 시나리오를 해결하는 AWS기능의 기본 레벨의 셋업에 이 기능을 활용할 수 있다. 한 번 셋업해두면, 추가 어카운트나 리전에 대해서도 간단히 전개할 수 있다. 

● CloudFormation 변경셋

변경셋은 CloudFormation의 템플릿 내용을 변경을 실시하는 구조이다. 스택을 변경할 필요가 있는 경우에 변경의 실시하기 전에 실행중인 리소스에 끼치는 영향을 충분히 이해하여 안심하고 스택을 변경할 수 있다. 변경셋을 사용하는 것으로 스택의 변경안이 실행중의 리소스에 미칠 가능성이 있는 영향(예를 들어, 변경에 의해 중요한 리소스가 삭제되거나 변경되거나)를 확인할 수 있다.

● CloudFormation 드리프트

실제 리소스와 CloudFormation 템플릿의 내용 사이에 괴리가 있는 것을 "드리프트"라고 부른다.

 

[CodePipeline]

● 완전 관리형의 영속성이 있는 딜리버리 서비스로 어플리케이션과 인프라 구조의 빠르고 효율적인 업데이트를 위해 리소스를 자동화한다.

● CodeDeploy나 ECS등의 서비스를 파이프라인으로써 설정하여 릴리즈 스택을 자동화한다.

● CodePipeline은 인프라 환경의 설정하기 위해 다른 서비스를 이용할 필요가 있다.

 

[AWS Direct Connect]

데이터 센터 등의 온프레미스 환경으로 부터 AWS로의 전용 네트워크 접속을 간단하게 구축할 수 있다. 이 서비스를 통해 대부분의 경우 네트워크의 비용을 절감하고 대역폭의 스루풋을 향상시켜 안정적인 네트워크 경험을 제공한다.

 

[데이터베이스의 암호화]

데이터 베이스의 작성중에 암호화를 시시할 수 있다. Amazon RDS DB 인스터스와 스냅샷을 암호화하기 위해서는 Amazon RDS의 DB인스턴 설정 메뉴에 있는 암호화 옵션을 유효화할 필요가 있다. 암호호된 데이터는 DB 인스턴스, 자동 백업, Read replica, 스냅샷 등이 포함된다.

 

[Aurora]

● 가용성이 높은 수백만의 쿼리를 처리할 수 있는 데이터베이스로는 Aurora를 이용할 수 있다. Aurora는 표준적인 MySQL와 비교해서 5개의 스루풋, 일반 PostgreSQL와 비교하면 3배의 스루풋을 실현할 수 있다. Aurora는 클러스터가 3개의 AZ에 분산된 구성으로 되어있지만, 더욱이 RDS와 동일하게 멀티 AZ failover구성을 유효화할 수 있다. 따라서 더욱 높은 가용성을 담보할 수 있다.

Amazon Aurora 레플리카가 작성되어 있는 경우에 fail over의 실행시간은 시작부터 종료까지 보통 30초 이내에 완료된다. Amzon Aurora 리플리카가 없는 경우는 fail over은 15분내에 완료된다. 따라서 Read replica를 구성하는 것이 최적의 구성이 된다.

● 프라이머리가 되는 DB 클래스터가 설치되어 있는 리전과는 다른 리전에 Read replica를 작성하는 것이 가능하다. 이 방법이 채용되면 장애 회복 기능을 향상킬 뿐만 아니라 읽어들이기 조작을 유저와 가까운 리전에 확장하면서 동시에 원래의 리전으에서 부터 다른 리전으로의 이동을 간단히 할 수 있다. 

● Aurora의 멀티 AZ 구성으로 인한 고속 Fail over(장애 극복 기능)은 Aurora의 innodb_read_only 글로벌 변수를 이용해 Master과 Slave의 접속처를 변경하는 방법이다. 이 기능을 사용하기 위해서는 replica를 사전에 준비해둘 필요가 있다. 이 기능을 통해 AZ 장애로 인한 몇 분의 다운 타임을 피할 수 있다. 그러나 이 설정은 리전 장애에는 대응하지는 못 한다.

● Aurora는 최대 15개의 Read relica를 이용한 고속 읽어들이기가 가등하다.

 

[VPC]

● VPC 피어링 접속

프라이빗 IPv4 주소 혹은 IPv6주소를 사용하여 2개의 VPC간에 트래픽을 라우팅하는 것을 가능하게 하는 네트워크 연결이다.  이 기능을 통해 2개의 VPC내에 설정된 인스턴스가 마치 동일한 네트워크내에 있는 것 처럼 상호 통신할 수 있다.

VPC 피어링 접속은 자신의 AWS 계정의 VPC간, 다른 AWS 계정의 VPC나 다른 리전에 있는 VPC등에 작성이 가능하다.

※ VPC 피어링 접속은 엣지간 라우팅을 서포트하지 않는다. 즉, 피어링 관계인  VPC에 다음과 같이 접속되어 있는 경우에는 피어링 관계를 확장할 수 없다.

① 인터넷 게이트웨이를 통해서 인터넷에 접속

② NAT디바이스를 통해서 프라이빗 서브넷 내의 인터넷에 접속

③ AWS 서비스(S3 등)으로의 VPC 엔드포인트

④ (IPv6) ClassicLink 접속

예를 들어, VPC A와 VPC B간에 피어링 접속이 되어 있어 VPC A에 Direct Connect 연결이 되어 있는 경우에는 VPC B의 인스턴스는 이 Direct Connect 접속처에 VPC 피어링을 통해서 접속할 수 없다. 동일하게 접속의 대응쪽의 리소스는 그 접속을 통해 VPC B에 액세스할 수 없다.  

● VPC 엔드 포인트

VPC 엔드 포인트를 사용하여 인터넷 게이트 웨이, NAT 디바이스, VPN 접속, 혹은 AWS Direct Connect연결 등을 이용하지 않고도 PrivateLink로 서포트되고 있는 AWS 서비스 및 VPC 엔드 포인트 연결 서비스에 이용하는 것이 가능하다. 따라서 DynamoDB와 연결하는 것도 가능하다. VPC와 다른 서비스 간의 트래픽을 AWS  네트워크 내에서 처리기 위해 사용하는 것이므로 인터넷에 연결에는 사용되지 않는다.

VPC 엔드 포인트는 리전 내의 포인트이므로 리전밖으로부터는 액세스할 수 없다. 따라서 엔드포인트를 사용하기 위해서는 사용되고 있는 리전에 S3 크로스 리전 레플리케이션를 사용해 S3 오브젝트를 복사할 필요가 있다. 이 방법을 통해 대상 리전에 S3 객체를 레플리케이션하여 그 리전에 대해 VPC 엔드포인트를 통한 액세스를 구성할 수 있다. 

1) 게이트웨이형

루트 테이블의 지정된 타켓이 되는 게이트 웨이이다. 지원되는 AWS의 서비스를 수신처으로하는 트래픽을 VPC내외에서 연결할 때에 사용한다. 아래의 AWS의 서비스를 지원한다.

▷ Amazon S3

▷ DynamoDB

2) 프라이빗 링크형(인터페이즈 엔드 포인트)

대상 서비스를 수신처로 하는 트래픽의 엔트리 포인트가 되는 프라이빗 IP를 가지는 Elastic Network Interface이다. 아래의 서비스를 지원한다.

▷ Amazon API Gateway

▷ Amazon CloudWatch

▷ Amazon CloudWatch Events

▷ Amazon CloudWatch Logs

▷ AWS CodeBuild

▷ Amazon EC2 API

▷ Elastic Load Balancing API

▷ AWS Key Management Service

▷ Amazon Kinesis Data Streams

▷ Amazon SageMaker ランタイム

▷ AWS Secrets Manager

▷ AWS Service Catalog

▷ Amazon SNS

▷ AWS Systems Manager

▷다른 AWS계정에 의해 호스트된 엔드포인트 서비스

▷ 지원되고 있는 AWS Marketplace 파트너 서비스

● DNS hostnames 옵션

이 옵션을 유효화히지 않으면 서ㅂ넷에서 실행된 인스턴스는 DNS명을 취득할 수 없다.

VPC내에 실행된 인스턴스가 퍼블릭 IP주소에 대응하는 퍼블릭 DNS 호스트명을 받는지 아닌지 그리고 Amazon DNS 서버을 통해 DNS 해결이 VPC에 적용되는지는 VPC의 조작으로 결정된다. 

VPC의 DNS hostnames 옵션을 유효화하기 위해서는 enaleDnsSupport 속성을 'true'로 설정한다. 그럼 VPC내의 인스터스가 DNS 호스트명을 취득하는 것이 가능해진다.

● VPC 플로우 로그

VPC 플로우 로그를 유효화하여 EC2 인스턴스와 네트워크 인터페이스간에 왕래하는 IP 트래픽 정보를 캡쳐할 수 있다. 이 데이터를 CloudWatch등에 집약하여 로그를 중앙관리할 수도 있다.

● VPC에 CIDR 블록을 추가할 때의 규정

허용 블록 사이즈 범위는 "/28" 서브넷 마스크부터 "/16"의 서브넷 마스크 사이이다. 다만 CIDR 블록은 VPC에 관계되어 있는 기존의 CIDR 블록와 중복되면 안된다.

● Amazon의 VPC와 온프레미스 환경을 네트워크로 연결하기 위한 방법

1) Direct Connect

2) IPsec VPN 접속

3) AWS VPN CloudHub

4) 서드파티 소프트웨어의 VPN 어플라이언스

● 네트워크 ACL

네트워크 ACL은 서브넷과 VPC의 프로토콜 통신 설정을 실행하는 방화벽(1개 이상의 서브넷의 인바운드 트래픽과 아웃바운드 트래픽을 제어)이다. 네트워크 ACL에 있어서 서브넷을 지정한 인스턴스로의 통신 허가를 설정할 필요가 없다. 어디까지나 2개의 서브넷에 배치된 리소스에 필요한 프로토콜 통신이 허가되도록 네트워크 ACL를 올바르게 설정하면 된다.

네트워크 ACL룰은 낮은 값으로부터 높은 값을 걸어서 평가되므로 일치하는 허가/부정 룰이 설정되면 바로 실행된다.

● AWS managed VPN

Amazon VPC에는 리모트 고객의 네트워크와 VPC 간에 IPsec VPN 연결을 생성하는 옵션이 있다. AWS managed VPN를 이용하여 온프레미스 환경와 VPC간과의 사이트간 접속을 실행하는 것이 가능하다.

 

 

[VPN]

● 커스텀 게이트웨이 디바이스는 유저쪽에서 온프레미스 네트워크에서 소유 혹은 관리하고 있는 물리적 어플라이언스 혹은 소프트웨어 어플라이언스이다. AWS 쪽의 프라이빗 게이트웨이에 접속하여 사이트 사이의 VPN이 접속하도록 할 수 있다. 

● VPN 접속을 만들기 위해서는 유저쪽의 커스텀 게이트웨이를 설정하고 AWS쪽에서는 커스텀 게이트웨이를 만들 필요가 있다. 이러한 설정을 통해 커스텀 게이트웨이 디바이스에 관련된 정보를 AWS에 제공하도록 한다. 그 다음 커스텀 게이트웨이의 외부 인터페이스의 인터넷에 라우팅이 가능한 IP주소(정적)을 설정할 필요가 있다. 

※ AWS VPN Hub라는 서비스는 존재하지 않는다. 

● AWS VPN CloudHub

AWS VPN CloudHub에 의해 사이트간 접속하도록 하는 것이 가능하다. AWS VPN CloudHub를 사용하기 위해서는 여러 개의 커스텀 게이트웨이를 사용하여 가상 프라이빗 게이트웨이를 작성할 필요가 있다.

● Accelerated 사이트 간의 VPN

Accelerated 사이트 간의 VPN은 Global Accelerator을 이용한 사이트 간의 VPN을 의미한다. VPN의 통신은 AWS 글로벌 네트워크를 경우해서 연결되기 때문에 고가용성·높은 퍼포먼스가 유지된다. VPC에 있어서 Acceleration을 유효화하면 AWS 글로벌 네트워크를 사용하여 성능을 향상 시킬 수 있다. 커스텀 게이트 웨이 디바이스의 트래픽은 최대한 가까운 AWS 엣지 로케이션을 경유하여 라우팅된 AWS 글로벌 네트워크를 통과하여 AWS의 VPN 엔드 포인트를 달성한다.

 

[AWS Transit Gateway]

AWS Transit Gateway은 여러 개의 VPC나 VPC 피어링을 메시 방법으로 연결·관리하는 것이 가능한 VPC를 확장하는 서비스이다. 중앙 게이트 웨이로부터 네트워크 상에 있는 Amazon VPC, 온프레미스의 데이터 센터, 리모트 오피스 각각에 하나의 연결을 구축하여 관리할 수 있다. 

AWS Transit Gateway가 네트워크 허브가 되어, 트래픽이 스포크와 같이 연결된 네트워크 간의 라우팅을 제어한다. 이러한 기능에 의해 대폭으로 관리를 간략화하여 운용 비용을 절감할 수 있다. 새로운 VPC를 추가하는 경우는 AWS Transit Gateway에 연결하는 것으로, 동일 AWS Transit Gateway에 연결되어 있는 다른 네트워크에도 자동적으로 연결된다.

 

[AWS OpsWorks]

● Chef를 활용하여 AWS에의 인프라 전개를 실시할 수 있다. AWS OpsWorks는 Puppet 혹은 Chef를 사용하여 클라이언트 기업내의 어플리케이션을 설정 혹은 운영하는 환경을 자동화하는 서비스이다. OpsWorks 스택 및 Chef Automate용 OpsWorks를 사용하여 구성 관리에 Chef 쿡북 혹은 솔루션을 사용할 수 있다. 

※ Web 어플리케이션의 디플로이에는 사용하지 않는다.

● AWS OpsWorks Stacks

OpsWorks Stacks를 사용하면 부하분산, 데이터베이스, 어플리케이션 서버 등, 다양한 레이어를 포함하는 하나의 스택으로써 모델화할 수 있다. 스택 베이스로 다른 레이어를 준비하기 위해서는 CloudFormation 보다도 OpsWorks으로 상세한 설정하는 것이 좋다.

 

[Elastic Beanstalk]

● Java, .NET, PHP, Node.js, Python, Ruby, Go 및 Docker을 사용하여 개발된 웹 어플리케이션이나 서비스를 Apche, Nginx, Passenger, IIS 등 익숙한 서버에 디플로이 혹은 스케일링하기 위한 서비스이다.

● ECS등의 Docker 서비스와 연계해서 용량의 프로비저닝, 부하의 분산, 스케일링, 및 어플리케이션의 상태를 상세 감시를 자동화할 수 있다.

● AWS Elastic Beanstalk를 통한 디플로이 업무의 자동화 설정은 WEB 어플리케이션을 Docker 컨테이너로부터 디플로이할 수 있다. Docekr 컨테이너는 자기완결형으로 모든 설정 정보와 웹 어플리케이션을 실행하기 위한 소프트웨어가 포함되어 있다. 

● AWS Elastic Beanstalk를 통해 어플리케이션이 호스트된 AWS 리소스를 유저쪽에서 완전히 제어할 수 있다. 혹은 Elastic Beanstalk 콘솔을 운영 대시보드로써 환경 상태와 어플리케이션의 상태를 한 눈에 알 수 있도록 표시할 수도 있다. 

 

[S3]

● 프리픽스를 사용하여 날짜를 베이스로 업로드를 분산하여 최소 3500 리퀘스트(1초당), 데이터의 취득은 5500리퀘스트(1초당)으로 할 수 있도록 포퍼먼스를 자동적으로 향상시킬 수 있다. 이전에는 S3가 이러한 성능을 발휘하도록 하기 위해서 배쉬를 사용한 랜덤 프리픽스를 구현하여 퍼포먼스가 향상되도록 하는 것이 필수 불가결이었지만, 이제는 S3의 기존의 프리픽스로 이 정도 성능을 낼 수 있게 되었다.

● 바로 활용할 수 있는 데이터를 축적할 경우네는 S3 표준 스토리지 클래스를 이용하는 것이 최적의 방법이다. 그리고 버저닝(Versioning)을 설정하여 오브젝트의 이전 버전을 간단히 복원할 수도 있다. "버전닝"이란 같은 S3 버킷 내에 오브젝트의 베어리언트(variant)를 유지하는 수단이다. 버저닝을 사용하여 Amazon S3 버켓에 저장된 어떠한 오브젝트의 한 버전을 저장, 취득, 복원하는 것이 가능하다. 버저닝을 사용하면, 의도하지 않은 유저 액션이나 어플리케이션 장애로부터 간단히 데이터를 복원할 수 있다.

● 서버 사이드 암호화를 사용하면 Amazon S3는 오브젝트를 데이터 센터 내의 디스크에 저장하기 전에 암호화하고 오브젝트를 다운로드 할 때 S3쪽에서 자동으로 복호화한다. 이는 S3 버킷의 암호화이외에 별도로 설정할 필요는 없다.

● S3의 암호화

1) SSE-S3

Amazon S3에서 관리되는 암호화키에 의해 실시되는 서버 사이드 암호화이다. AES-256를 이용한다. 유저가 키(열쇠)에 관련된 액세스 관리는 할 수 없지만, 서명 버전4에 의해 액세스 제한이 설정되어 소유자인 AWS 계정 ID 이외에는 접근이 금지되어 있다. SSE-S3는 암호화와 복호화를 S3쪽에서 자동으로 실시해주기 때문에 제일 수고를 들여도 되지 않는 암호화방식이다.

S3쪽에서 자동적으로 암호화·복호화하기 때문에 이용 상황을 감시하고 추적할 수 없다는 것이 디메리트이다. 한편, SSE-S3는 추가 요금없으며 API콜의 제어를 고려하지 않아도 된다는 것이 메리트이다.

2) Client Side Encryption(CSE)

유저가 독자의 암호화 키를 사용하여 암호화한 오브젝트를 S3에 저장하고 암호화 키를 생성, 감시는 클라이언트에서 실행하는 방식이다.

3) SSE-C 

 유저가 관리하는 열쇠로 암호화를 실시할 수 있다. 이 방식으로 S3상에 있는 컨텐츠를 유연히 보호할 수 있다. 유저가 준비한 암호화키로 SSE-C에 사용하면 독자적인 암호화키를 설정할 수 있다.

4) SSE-KMS

 SSE-KMS는 암호화 키의 관리 기능을 관리형 서비스로 제공해준다. 따라서 CloudTrail을 이용해 액티비티의 흔적 로그를 얻을 수 있어, 추적이 필요한 경우에 이 암호화 방식을 사용한다.

● 멀티 하드 업로드 API

 대용량 오브젝트를 몇 개로 나눠서 업로드할 수 있다. 이 기능으로 새로운 대용량 오브젝트를 업로드하는 것이 간단해지고 업로드 처리의 부담이 경감된다.

※ S3에 고속 업로드 혹은 업로드 레플리케이션이라는 기능은 없다.

● S3 Transfer Acceleration

클라이언트와 S3 버킷 간에 장거리 파일 전송을 고속, 간단, 안전히 실행할 수 있게 된다. 이 기능을 통해, 각 리전으로부터 S3에 데이터를 전송하는 것이 간단해진다. Transfer Acceleration에서는 세계에 분산되어 있는 Amazon CloudFront의 엣지 로케이션을 이용하고 있다. 엣지로케이션에 도착한 데이터는 최적화된 네트워크 경로로 S3에 라우팅 된다.

어디까지나 S3 버킷 안의 컨텐츠로의 고속 액세스를 가능하게하는 것이다.

● Amazon S3 Select

간단한 SQL 스테이트먼트를 사용하여 Amazon S3 객체의 컨텐츠를 필터링하고 필요한 데이터의 서브셋만 얻을 수 있다. 결과로써는 Amazon S3가 전송될 데이터를 감소할 수 있어 데이터 취득에 요구되는 비용을 삭감할 수 있고 대기 시간도 개선할 수 있다.

S3 Select를 이용하면 바로 활용할 수 있는 쿼리를 사용해여 S3 오브젝트(및 AWS의 다른 데이터 셋) 전체에 대해서 데이터 분석을 실행할 수 있다. S3 Select는 오브젝트 전체가 아닌 오브젝트 데이터의 일부(서브 셋)을 얻을 수 있으므로 쿼리의 성능이 최대 400%까지 향상된다.

● S3의 정적 호스팅

S3 버킷의 정적 WEB 호스팅에 의해 HTML오브젝트에 액세스할 때에 오브젝트의 읽어 들이기 액세스를 허가하지 않으면 웹 사이트 엔드 포인트로부터 HTTP 응답 코드 403(Accesss Denied)가 돌아온다. 이럴 때, 정적 WEB 호스팅을 사용하기 위해서는 먼저 S3정적 웹 호스팅 기능을 유효화해야한다. 다음 index.html을 설정하면 WEB 사이트의 설정이 완료된다. 추가적으로 인터넷으로 부터의 액세스가 허용되는 액세스 관리 설정이 필요하다. 퍼블릭 액세스 블록를 무효화하는 것과 버킷 정책의 설정을 통해 인터넷에서 버킷으로의 s3:GetObject를 설정할 필요가 있다.

 또한 S3는 HTTPS를 이용할 수 없으므로, 보안이 철저해야할 웹 사이트 작성에는 알맞지 않다. 그러나 CloudFront와 S3를 연결하면 HTTPS를 이용하는 것이 가능하다.

● BLOB 데이터

DynamoDB 등의 NoSQL 데이터베이스에 저장하기에는 너무 큰 데이터이다. DynamoDB가 아닌 S3에 BLOB 데이터를 저장해야한다. Amazon S3는 최대 5TB의 라지 오브젝트의 저장이 가능하여 비구조화의 BLOB 저장에 적합하다.

● S3의 이벤트 발행

Amazon S3에서는 아래의 서비스를 이용해서 이벤트를 발행할 수 있다.

▷ Amazon SNS 토픽

구독하고 있는 엔드 포인트 혹은 클라이언트로의 메시지의 배신을 실행, 관리하는 서비스이다. S3를 트리거로하여 메일 등을 통지할 수 있다.

▷ Amazon SQS 큐

컴퓨터간에 메시지를 통신하기 위해 사용되는 신뢰성이 높은 scalable 큐잉 서비스이다. S3를 트리거로하여 Standart 큐를 배달할 수 있다.

▷ AWS Lambda

코드를 업로드하여, 서비스가 AWS 인프라스트럭처를 이용하여 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스이다. Lambda함수를 작성하여 커스텀 코드를 패키지화하여 AWS Lambda에 업로드한다. S3를 트리거로하여 Lambda함수를 실행시킬 수 있다. 

● 스토리지

▷ S3 Intelligent-Tiering

저장한 데이터가 예측 불가능한 액세스 패턴을 가진 경우에는 S3 Intelligent-Tiering을 사용하는 것이 비용 최적화에 도움이 된다. S3 Intelligent-Tiering에는 높은 빈도와 낮은 빈도 2개의 액세스 단계로 구성되어 있다. 양쪽의 단계는 Standard(표준)스토리지 클래스와 동등한 낮은 레이턴시를 제공한다. S3 Intelligent-Tiering는 액세스 패턴을 모니터링하여 연속 30일간 액세스되지 않는 데이터를 낮은 빈도의 액세스 단계에 이동한다. 그 이후에 그 데이터에 대한 액세스가 있는 경우 높은 빈도의 액세스 단계에 자동으로 돌아간다. 즉 액세스 패턴이 변화하는 상황에서도 성능의 영향이 없이 이용 요금을 절약할 수 있다.

※ 별로 액세스하지 않은 데이터라고 확실하 수 있는 경우에는 비용 절약의 관점에서 Standard-IA(표준-저빈도 액세스)를 이용하는 것이 바람직하다.

▷ S3 Standard 스토리지 클래스

표준 빈도에 이용하는 데이터 스토리지로써 이용된다. 이것은 S3 중에서도 최고로 비용이 높은 스토리지이다. 중요성이 낮은 재생가능한 데이터를 저장하는데에 이전에는 RRS가 좋았지만, 현재는 RRS는 추천하지 않는 스토리지 타입이되어 현재는 거의 사용하지 않는다. 또한 Standart클래스가 가격이 저렴해졌으므로, RRS의 가격은 Standard보다 비싸다. 레포트 작성이 완료된 다음, 필요하지 않은 내용에 대해 일정 기간안에 삭제하는 라이프 사이클 룰을 설정한다.

▷ One Zone-IA

액세스 빈도가 그렇게 높지않은 데이터를 탄력성이 낮은 하나의 AZ에 저장하여 비용을 절약할 수 있다. 백업의 복사나 재작성이 가능한 데이터 서머리 등, 액세스가 빈번하지 않은 다른 데이터에 대해서는 One Zone-IA가 보다 낮은 가격에 가능하다. 

▷ Standard-IA

저빈도 액세스용이지만, 읽어들이기 바로 되기 때문에 갑작스러운 이용에도 대응할 수 있다. Standard보다 저비용으로 이용가능하다. Amazon S3 Standard-IA는 액세스 빈도가 낮은 마스터 데이터의 장기보존에 적당하다. 

▷ RRS(저확장화 스토리지)

현재 AWS에서 비추천하는 스토리지이다.

● S3 버킷 조작 권한

다른 AWS 어카운트에 자신의 계정이 소유하고 있는 S3 버킷의 이용을 허가하고 싶은 경우, 그 어카운트와 유저에 대해 IAM 정책과 버킷 정책 양쪽의 모두 허가를 설정할 필요가 있다. 버킷 정책은 IAM 유저나 AWS 계정 지정을하여 변경할 수 있다. 한쪽만 허가가 되어 있는 경우에는 액세스가 불가능하다.

● Amazon S3 오브젝트 사이즈 범위

최소 0 바이트부터 최대 5테라 바이트로, 1개의 PUT 조작으로 업로드 할 수 있는 최대 오브젝트는 5기가바이트이다. 

● Amazon S3 액세스 포인트

S3의 공유 데이터 셋으로의 대규모 데이터 액세스의 관리를 단순화하는 액세스 설정에 S3 액세스 포인트를 이용하는 것이 요구된다. 

Amazon S3 액세스 포인트는, S3의 공유 데이터셋으로의 대규모 데이터 액세스의 관리를 단순화하는 기능이다. 액세스 포인트는 버킷에 붙여진 이름이 붙은 네트워크 포인트로 S3 오브젝트의 오퍼레이션(GetObject나 PutObject등)을 실행하기 위해 사용할 수 있다. 각 액세스 포인트는 바탕이 되는 버킷에 붙인 버킷 정책과 연계하여 기능하는 커스터마이즈된 액세스 포인트 정책을 적용하여 액세스를 제어하는 것도 가능하다.  

● S3에서는 Sercure File Transfer Protocol(SFTP)를 사용하여 Amazon S3와의 사이에 파일 을 직접 전송할 수 있도록 한다.

※ SMB프로토콜은 사용하지 않는다.

※ S3는 배송될 컨텐츠의 압축 처리 기능이 존재하지 않는다.

● S3의 CORS(Cross-Origin Resource Sharing)

CROS는 어플리케이션상에 여러 개의 도메인으로부터 컨텐츠 액세스를 S3 버킷에 허가할 때에 이용하는 구조이다.

CORS를 유요화하면 기존의 도메인이 설정되어있는 S3버킷을 다른 도메인에 공유할 수 있다. CORS는 특정 도메인에 로드된 클라이언트 웹 어플리케이션이 다른 도메인 내의 리소스와 통신하는 방법을 정의한다. CORS에 의해 Amazon S3를 사용하여 기능이 풍부한 클라이언트 쪽 웹 어플리케이션을 구축하고 Amazon S3리소스에 대해서 크로스 오리진 액세스를 선택적으로 허가하는 것이 가능하다.

※ CROS는 VPC 엔드포인트를 이용하지 않는다. 

● HTTP 503은 "서비스를 이용할 수 없을 때" 표시되는 에러이다. 버저닝을 유효화한 버킷에 대해 해당 에러가 발생하게 되는 원인은 수 백만 개의 버전이 있는 1개 이상의 오브젝트가 존재하고 있기 때문이다. 수 백만개의 버전이 가진 오브젝트가 있는 경우에 Amazon S3는 과도한 리퀘스트 트래픽으로부터 유저를 보호하기 위해 버켓으로의 리퀘스트를 자동적으로 조정한다.

이 문제가 발생하지 않도록 하기 위해서는 라이프 사이클 관리의 "NonCurrentVersion" 유효기간 정책과 "ExpiredObjectDeleteMarket" 정책을 유효화하고 이전 버전의 객체를 기간 만료시키는 것이다. 따라서 버켓 내에 관련된 데이터 객체가 존재하지 않는 마커를 사용하다. 

● AmazonS3ReadOnlyAccess

IAM 정책을 이용해 다음과 같이 작성할 수 있다.

      "Effect": "Allow",

      "Action": [

        "s3:Get*",

        "s3:List*"

      ],

      "Resource": "*"

이 정책은 EC2인스턴스상의 프로그램(AWS CLI, AWS SDK를 이용한 프로그램)으로부터 S3 리소스에 대해 참고조작(Get, List)이 가능하게 된다.

※ S3에서는 AmazonS3ViewOnlyAccess이라는 권한 설정이 존재하지 않는다. 

● S3 버킷 공개 제어

ACL 혹은 버킷 정책으로 버킷 공개 제어를 실행한다. 버킷 정책은 버킷에만 설정되는 액세스 제어이지만, ACL은 버킷과 오브젝트 양쪽에 설정하는 것이다. ACL에서는 버킷 단위의 ACL의 설정과 관계 없이 객체 단위의 ACL이 우선되도록 설정된다. 즉 버킷 ACL에서 퍼블릭 액세스를 허가하지 않는 설정하고, 더욱이 객체에 대해서도 ACL에서 퍼블릭 액세스를 허가하지 않도록 할 필요가 있다.

이러한 ACL의 설정은 매우 귀찮기 때문에, 추가된 것이 S3의 퍼블릭 액세스 설정 기능이다. S3의 퍼블릭 액세스 설정 기능은 버킷 레벨 혹은 계정 레벨로 모든 객체로의 퍼블릭 액세스를 블로킹할 수 있다. 이 기능을 이용해 블록을 유요화하는 것으로 S3 버킷 전체에 대해서 퍼블랙 액세스를 거부할 수 있다. 

 

[AWS Lake Formation]

AWS Lake Formation을 이용하여 S3를 이용한 데이터 레이크 구성을 간단히 실현할 수 있다. AWS Lake Formation은 데이터 베이스와 오브젝트 스토리지로부터 데이터를 수집 및 카탈로그화하여 데이터를 Amazon S3데이터 레이크에 이동하여 저장할 수 있다. 그리고 기계학습 알고리즘을 사용하여 데이터를 클린업 및 분류하여 기밀 데이터로의 액세스를 보호한다. 이러한 업무가 완료되면 유저는 일원화된 데이터 카탈로그에 액세스할 수 있게 된다. 이 데이터 카탈로그는 이용가능한 데이터 셋 및 적절한 사용방법이 표시되어있다.

※ S3 데이터 레이크, AWS Glue 데이터 레이크 구성이라는 기능은 존재하지 않는다.

 

[EFS]

● 스토리지 클래스

Amazon EFS는 표준 스토리지 클래스와 저빈도 액세스 스토리지(EFS IA)이라는 두 가지 스토리지 클래스가 존재한다.

▷ EFS IA

EFS IA는 매일 액세스 하지 않는 파일에 최적화된 비용 효율의 요금/성능을 제공한다. 파일 시스템에서 EFS 라이프 사이클 관리를 유효화하는 것만으로 선택한 라이프 사이클 정책에 의해 액세스 하지 않는 파일은 자동적이고 투명하게 EFS IA에 이동된다. EFS IA스토리지 클래의 비용은 단지 0.025 USD/GB-매월이다. 

※ EFS IA를 사용하는 것 뿐만 아니라, 라이프 사이클을 유효화 시켜야 제대로 이용 가능하다.

※ 라이프 사이클 관리는 설정할 수 있지만, Glacier으로의 데이터 이동은 할 수 없다.

● 스루풋 모드

스루풋 모드는 파일 시스템에서 제공할 수 있는 전체 스루풋을 결정할 때에 사용하는 기능이다. 이것은 유효화가 아닌 버스트 및 프로비저닝 2개의 스루풋 모드 중 선택하는 것이다.

▷ 버스트 스루풋

버스트 스푸룻에서는 스루풋은 파일 시스템의 사이즈에 맞게 변경되어 파일베이스의 많은 수의 워크 로드의 불규칙한 성질에 대응하도록 필요에 따라 동적으로 버스트된다.

▷ 프로비저닝 스루풋

프로비저닝된 스루풋은 기본의 버스트 모드보다 높은 전용 스루풋을 필요로 하는 어플리케이션을 지원하도록 설계되어 있어 파일 시스템에 저장되어 있는 데이터의 양과는 관계 없이 설정할 수 있다.

● 퍼포먼스 모드

Amazon EFS는 폭 넓은 워크 로드에 대응하기 위해 필요한 스루풋, IOPS, 및 낮은 레이턴시를 제공할 수 있도록 설계되어 있어 범용과 최대 I/O의 두 종류의 퍼포먼스 도를 제공한다.

▷ 범용 모드

범용 모드는 파일 시스템 오페레이션 단위에 최소 레이턴시를 실현할 뿐만 아니라, 랜덤 혹은 시퀀셜(순차) IO패던에서도 같은 결과를 얻을 수 있다.

▷ 최대 I/O 모드

최대 I/O 모드의 파일 시스템은 파일 오페레이션의 지연 시간이 약간 길어지는 대신 스루풋이 고성능으로 확장 된다.

● 고부담의 워크 로드에 있어서 Amazon EFS는 10GB(1초당)이 넘는 퍼포먼스, 및 50000을 넘는 IOPS를 서포트하고 있다. 

● Amazon EFS는 Amazon EC2와 조합하여 사용하는 파일 스토리지 서비스이다. Amazon EFS에는 파일 시스템 인터페이스와 파일 시스템의 액세스 시멘틱스(강력한 정합성이나 파일의 lock등)이 준비되어 있어 최대 수천 개의 Amazon EC2 인스턴스로부터의 동시 액세스가 가능한 스토리지로써 제공된다. 

● EFS는 클라우드 서비스 및 온프레미스 리소스에서 이용할 수 있는 심플, 스케일러블, 신축 자유자채한 파일 시스템을 제공하는 Linux베이스의 파일 스토리지이다.

※ Lists(ACLs), 샤드 복사, 유저 쿼터 등, Windows 네이티브 파일 시스템의 기능을 서포트하지 않는다.

● AWS DataSync

AWS DataSync는 온프레미스 스토리지와 Amazon EFS 간에 데이터를 빠르고 간단히 이동시킬 수 있는 매니지드 형의 데이터 전송 서비스이다. AWS DataSync를 사용하면 오픈 소스 툴과 비교해 최대 10의 속도로 액티브한 데이터 셋을 AWS Direct Connect 혹은 인터넷 경유로 전송할 수 있다.

● AWS 백업(AWS Backup)

AWS 백업은 EFS 파일 시스템의 중앙 관리와 백업의 자동화를 간단히 할 수 있는 매니지드 형의 백업 서비스이다.

AWS Backup은 AWS Storage Gateway를 사용하여 온프레미스 및 AWS 서비스 전체의 데이터의 백업의 일원화와 자동화를 간단히 실행할 수 있는 완전 매지니드 형의 백업 서비스이다.

백업 정책을 일원적으로 설정하여 Amazon EBS 볼륨, Amazon RDS 데이터 베이스, Amazon DynamoDB 테이블, Amazon EFS파일 시스템, AWS Storage Gateway 볼륨 등의 AWS 리소스의 백업 액티비티를 모니터링할 수 있다.

※ AWS 백업은 EFS의 데이터 이동에는 이용할 수 없다.

※ AWS DMD이라는 서비스는 존재하지 않는다.

● EFS는 NFSv4 프로토콜 경우로 기존의 파일로의 액세스를 실시하는 스토리지이다. Amazon EC2 인스턴스와 온프레미스 서버의 수 천개의 접속이 안전하게 동시에 액세스할 수 있도록 한다. 

※ SMB프로토콜은 사용하지 않는다.

 

[STS(AWS Security Token Service)]

일시적인 인증허가 위한 기능으로 중장기적인 액세스 권한 부여에는 부적한 기능이다. 

 

[SQS]

● 분산형 어플리케이션에 대해 사용되는 메세지큐 서비스로, 풀링 모델을 통해 메시지를 변환하고 컨포넌트의 송수신을 분리하기 위해 사용할 수 있다. FIFO설정해 순서대로 메시지 처리하도록 할 수 있다.

※ SQS는 푸시방식이 아니라 풀링방식이다.

● SQS는 병렬처리 등의 분산 처리시에 이용해야하는 것으로 이벤트에 연동한 메시지 통지에는 SNS를 이용하는 것이 바람직하다.

● 시스템의 분산 처리화에 사용된다. 큐 내에 워크 프로세스의 동적 처리 요구를 저장하고 비동기처리를 통해 확실한 처리 실행을 가능하게 한다. 그리고 큐 내의 메시지를 EC2인스턴스에 분산 처리하는 것으로 복수의 "워크" 프로세스를 병렬 실행할 수 있다. 각 메시지는 한 번만 소비된다. SQS 큐잉을 이용하는 것으로 분산 병렬 처리의 성능을 향상시킬 수 있어 신뢰성이 보장된다.

● FIFO 큐를 이용하여 높은 스루풋, 베스트 effort 순서 확립, 적어도 한 번의 배달을 한다.

● SQS는 메시지의 중복배제 ID를 이용하여 중복 메시지 발생을 사전에 방지할 수 있다. 참고로 메시지의 중복 배제 ID는 송신된 메시지의 중복 배제에 사용되는 일종의 토큰이다. 

● AWS 리소스의 수평방향의 스케일링에 도움이 된다. SQS를 이용하여 여러 개의 EC2인스턴를 통한 병렬 처리가 가능해져 부담 분산이나 처리 프로세스의 최적화에 도움이 된다.

● SQS를 이용해여 가시성 타임아웃을 설정할 수 있다. 이 설정으로 특정 인스턴스에 대해 일정 기간이상 큐가 처리되지 않은 경우에 한해서, 가시성 타임아웃을 초과하는 경우에 스팟 인스터스쪽에서 큐가 보이도록 처리가 된다. 따라서 특정 EC2 인스턴스에서 처리가 우선되고 있는가를 확인할 수 있고 가시화 타임 아웃을 초과한 경우에만 다른 인스턴스에 의해 처리되로록 설정할 수 있다. 

● SNS로부터 메시지를 SQS에서 중단시켜 풀링 처리를 실시해도, EC2 인스턴스간에 처리 우선 순위는 변경되지 않는다.

● Amazon SQS 큐에 저장할 수 있는 메시지의 수는 무제한이다.

● SQS의 기본 큐

기본 큐는 단순한 표준 큐로 FIFO(선입선출)큐는 아니므로 순서를 보증할 수 없다. 더욱이 SQS는 중복 송신이 될 가능성이 있다.

SQS는 최장 메시지 보관기간을 넘긴 큐에 남아있는 메시지는 자동으로 삭제된다. 기본 메시지 보관 기간은 4일간이다. 따라서 SQS의 큐잉을 이용하여 컨포넌트간의 연계를 할 때에 처리되지 않은 큐를 4일까지 보호한다.

※ 데드레터 큐는 데이터 보관기간설정 항목이 없다. 데드레터큐는 정상으로 처리(소비)되지 않은 메시지의 송신처로써 다른 (소스)큐를 사용할 수 있는 큐이다. 

● SQS에서 메시지 중복을 배제하는 ID나 가시성 타임아웃 등 메시지를 중복 처리를 예방할 수 있는 방법이 있지만, 이것은 시스템적으로 서버간에서 같은 메시지를 중복하여 처리하는 것을 방지하기 위한 구조이다. 

※ 업무적으로 발생할 가능성(사람의 입력 실수 등)을 예방하고 싶은 경우에는 SQS 자체의 기능보다 Step Function을 작성해 메시지 중복을 예방하는 것이 좋다. 

● SQS큐의 수요 변화에 따라 Auto Scaling 그룹을 스케일링하는 것이 가능하다. SQS 큐 사이즈를 확인하는 Auto Scaling트리거를 구성하는 것으로 SQS 큐 사이즈에 따른 EC2인스턴스의 AutoScaling을 실행할 수 있다.

Amazon SQS큐의 액티비티에 따른 스케일링을 검토할만한 시나리오는 몇 가지가 있다. 유저가 이미지를 업로드하여 온라인으로 사용할 수 있는 웹 어플리케이션의 경우, 어플리케이션은 처리를 위한 이미지의 raw 비트맵 데이터를 Amazon SQS큐에 배치한다. EC2인스턴스에 의해 이미지가 처리되어 처리 후의 이미지를 배달이 가능해진다. 따라서 SQS 큐 사이즈의 증가에 대응하는 AutoScaling을 설정하는 것으로 이미지 처리가 스케일될 수 있다.

※ 큐의 우선도에 따른 AutoScaling을 구성하는 메트릭스 설정은 존재하지 않는다.

 

[RDS]

● 멀티 AZ 구성으로 구성하는 것으로 DB 인스턴스의 가용성을 향상시킬 수 있지만, 읽어들이기 성능을 향상 시키는 것은 불가능하다.

● ElastiCache를 RDS 앞에 설치해두면 캐시 처리를 이용해 DB처리 성능을 향상시킬 수 있다.

※ Read replica를 늘려서 성능을 향상시킬 수 있지만, 비용을 고려하지 않아도 된다면 ElastiCache를 이용하는 것이 좋다.

● DB인스턴스 상의 다양한 프로세스 혹은 스토리지가 CPU를 어떻게 사용하고 있는가를 상시 모니터링하기 위해 RDS의 확장 모니터링을 유효화할 필요성이 있다. 이 기능을 통해 DB 인스턴스의 OS의 실시간 매트릭을 확인할 수 있다. RDS콘솔을 사용하여 DB인스턴스의 매트릭스를 표시할 수 있어, CloudWatch Logs로부터 확장 모니터링을 사용하는 것이 가능하다. 기본적으로 확장 모델링 매트릭스는  30일간 CloudWatch Logs에 저장된다.

● RDS MyISAM는 MySQL의 스토리지 엔진으로써 사용할 수 없다. MySQL에 있어서 추천되는 스토리지 엔진은 InnoDB이다. 참고로 스토리지 엔진이란 다양한 테이블형에 대해 SQL 조작을 처리하는 MySQL 컨포넌트이다.

● Lambda에서부터 RDS로 액세스하기 위해서는 RDS쪽의 SecurityGroupIngress에 Lambda 보안그룹을 허가하는 설정이 필요하다. SecurityGroupEgress는 보통, Ingress 룰과 Egress 룰 중에 보안 그룹이 상호 참고할 수 있도록 할 필요가 있는 경우에만 사용한다.

※ RDS는 데이터 웨어 하우스로써 사용할 수 없으므로, 온라인 분석 처리(OLAP)를 실시할 수 없다.

※ RDS는 파일 시스템와의 연계를 지원하지 않으므로 연계를 실현하기 위해서는 EC2 인스턴스에 데이터 베이스를 인스톨하여 데이터 베이스 서버를 커스터마이즈해서 구축할 필요가 있다.

● RDS는 PostgreSQL11을 지원하고 있다.

● RDS로 데이터베이스를 구축하여도 특정의 CRM와 연계하는 것이 가능하다.

● 관계형 데이터 베이스의 랜던 I/O 지연 방지

RDS의 인스턴스 타입에 있어서 IOPS 성능이 높은 타입을 선택하여 고성능 처리가 이루어지도록 설정하는 것으로 랜덤 I/O지연을 방지할 수 있다. 또한 필요에따라 Read replica를 증강시키는 방법도 좋다.

● 타입

1) RAID0

여러 개의 스토리지(외부기억장치)를 모아서 한 대의 장치와 같이 관리하는 RAID기술의 방식(RAID레벨)의 하나로 여러 개의 장치에 균등히 데이터를 분할해 병렬로써 동시에 기록하므로 읽고 쓰기를 고속화할 수 있다. 

RAID0 구성에서는 여러 개의 gp2, io1, st1, 혹은 sc1 볼륨을 통합하여 이것들의 인스턴스에 이용가능한 대역폭을 사용할 수 있다.

2) RAID1 

EBS 볼륨을 여러개 붙여서 RAID1 구성을 실현하여 미러링을 실시할 수 있다. RAID1으로 인해 EBS 볼륨이 정지 혹은 파손되었을 경우에 있어서도 정지하는 것이 아닌 데이터를 보호, 복원하는 것이 가능하다. 

RAID1에 의해 데이터의 확장성은 담보되지만, 백업의 정기 취득은 불가능하다.

※ RAID1은 미러링 구성으로 확장성 및 장애 극복성을 제공하고 있지만 성능을 향상시키진 않는다.

● RDS의 IAM DB인증

RDS유저나 EC2인스턴스로의 액세스를 실시하는 EC2인스턴스 등은 IAM 유저 혹은 IAM 역할의 인증 정보와 인증 토큰을 사용하여, RDS DB 인스턴스 혹은 클러스터에 접속하는 것이 가능하다. 이것은 RDS 인스턴스의 생성시에 "Enable IAM DB Authentication(IAM의 DB인증)"을 유효화하여 이용할 수 있다.

● RDS의 DB 인스턴스를 실행할 때에 DB쪽의 보안 그룹에 3306 포트를 설정할 필요가 있다. 데이터 베이스는 퍼블릭 서브넷(10.0.0.0/16)내의 Web 서버로부터만 액세스하도록 할 필요가 있으므로, 타켓 소스에 10.0.0.0/16를 설정하여 퍼블릭 서브넷으로부터만 액세스 할 수 있도록 한다. Web서버는 SSH접속의 고객만이 액세스 할 수 있도록 하기 위해, 보안 그룹의 인바운드 룰에 있어서 SSH접속을 허가할 필요가 있다. 

● RDS의 읽어 들이기 성능을 향상시키기 위해서 아래와 같은 대응을 고려해 볼 수 있다.

▷ Amazon RDS Read replica 를 추가하고, 읽기처리를 분산한다.

▷ ElastiCache에 의한 캐시 레이어를 추가하여 액세스사 집중되는 일부 쿼리를 캐시처리하여 고속처리를 실현해, RDS로의 부담을 감소시킨다.

▷ 스토리지 타입을 IOPS의 커다란 사이즈에 변경하는 것으로, RDS 자체의 I/O 퍼포먼스를 향상시킨다.

● RDS Oracle의 자동 백업

웹 서버와 어플리케이션 서버 및 Oracle 데이터베이스에 구성된 어플리케이션의 데이터 백업을 실현하길 바라는 경우에 사용할 수 있다. 

● RDS 프록시

RDS 프록시는 어플리케이션과 RDS 데이터 베이스 사이의 중개역할을 하는 기능이다. RDS 프록시는 필요한 데이터 베이스의 커넥션풀을 확립 및 관리하고, 어플리케이션으로부터의 데이터 베이스 연결이 적어지도록 억제하는 기능히다.

Lambda함수는 RDS 엔드 포인트가아닌 RDS 프록시를 이용하여 연결할 수 있다. RDS 프록시는 Lambda함수의 동시 실행에 의해 작성된 대량의 동시접속을 스케일링하기 위해 필요한 커넥션을 풀링한다. 이로인해, Lambda어플리케이션은 Lambda 함수를 호출할 때마다 새로운 커넥션을 생성하는 것이 아닌, 기존의 커넥션을 재이용할 수 있게 된다. RDS 프록시를 이용하지 않고 엔드포인트를 이용하면 Lambda함수에 의해 커넥션이 대량 발생해 처리가 제대로 되지 않는 문제가 발생할 수 있다.

● Amazon RDS 멀티 AZ 구성

데이터 베이스(DB) 인스턴스의 확장된 가용성과 지속성을 제공한다. Muti-AZ DB 인스턴스를 프로비저닝하면 Amazon RDS는 프라이머리 DB 인스턴스를 자동적으로 생성함과 동시에 다른 AZ에 있는 스탠바이 인스턴스에 데이터를 복제한다. 인프라 구조 장애가 발생하면, Amazon RDS는 스탠바이(Amazon Aurora의 경우는 Read replica)에 자동적으로 fail over하여 세컨더리 DB를 메인으로 변경하여 데이터 베이스의 동작을 재개할 수 있다.

 

[RMAN]

● RMAN는 Oracle이 작성한 Oracle 데이터베이스용으로 제공되는 백업 및 리커버리 매니저이다. 데이터 베이스의 백업, 복원, 및 회복 기능을 제공하고 고가용성과 재해복원 처리를 한다. 이것을 이용하면 Oracle 데이터 베이스의 백업을 자동화할 수 있다.

AWS에서는 RMAN을 이용한 백업 설정이 가능하지만, Amazon RDS는 DB인스턴스로의 쉘 액세스를 제공하고 있지 않다. 또한 고급 권한을 필요로하는 특정의 시스템 프로세서나 테이블로의 액세스를 제어한다. 

● EC2인스턴스에 Oracle데이터 베이스 엔진을 설치한 후에 Oracle이 제공하는 Oracle RMAN을 이용하여 일자별로 설정하는 것이 가능하다. 그러나 RDS를 이용하지 않고 바로 EC2인스턴스에 데이터 베이스를 전개하는 방법은 온프레미스로부터의 특수한 전환의 경우 등과 같이 한정적인 케이스이며, 보통은 RDS 사용을 권장한다. 

 

[VM Import/Export]

가상 머신(VM) 이미지를 기존의 가상화 환경에서부터 Amazon EC2에 Import하고, 이것을 원래의 환경에 Export 할 수 있다. 이 방법을 사용하면 어플리케이션 및 워크로드를 Amazon EC2로 이동시키거나, VM 이미지 카탈로그를 Amazon EC2에 복사하거나, 백업 그리고 화재 대책을 위한 VM 이미지의 리퍼지터리를 작성할 수 있다.

 

[리플리케이션 랙(lag)]

Read replica는 비동기적으로 리플리케이트되어 개별의 데이터 베이스 인스턴스에 있기 때문에, 리플리케이션 데이터의 취득이 늦어지는 경우가 많아 최근 몇 가지 트랜잭션이 표시되지 않는 문제가 발생할 가능성이 있다. 이것을 리플리케이션 랙이라고 말한다.

 

[Amazon FSx for Windows]

● Windows File Server 구조를 사용할 수 있는 서비스이다. Windows Server에 구축하는 Amazon FSx는 마이크로소프트 어플리케이션이 의존하는 호환성과 가능을 제공한다.

Amazon FSx는 SMB 프로트콜을 사용하여 최대 수천대의 컴퓨팅 인스턴스로부터 액세스 가능한 NTES 파일 시스템을 제공한다.

● Amazon FSx for Windows 파일 서버

Access Control Lists(ACLs), 샤드 복사, 유저 쿼터등, Windows 네이티브 파일 시스템의 기능을 지원하고 있는 스토리지 타입이다.

파일 시스템에 있어서 최대 2GB/1ch의 스루풋, 수백만의 IOPS, 일관되게 밀리초 미만의 레이턴시로 고속성능을 실현하는 고가용성의 스토리지이다.

Amazon FSx for Windows 파일 서버는 DFS이름공간을 사용하여 수백 베타 바이트의 데이터 전체를 최대 매초 수십 기가바이트의 스루풋으로 수백만의 IOPS까지 퍼포먼스를 스케일업할 수 있다. 

Amazon FSx for Windows파일 서버는 서브넷형의 네이티브 Microsoft Windows 파일 시스템을 제공하고 있다. 따라서 공유 파일 스토리지를 필요로 하는 Windows 베이스의 어플리케이션을 AWS에 전환할 수 있다. Windosws Server에 구축하는 Amazon FSx는 Microsoft 어플리케이션이 의존하는 호환성과 기능을 제공한다. SMB프로토콜을 사용하여 액세스 가능한 NTFS 파일 시스템이다.

 

[AWS WAF]

● AWS WAF는 어플리케이션에 대한 일반적인 웹 공격으로부터 웹 어플리케이션을 보호하는 웹 어플리케이션 방화벽이다. 부정 액세스 처리에 이용되는 점에서 AWS Shiled와 비슷할 수 있지만 DDoS공격에 대한 직접대응은 하지 않는다.

● Referer 제한으로 직접 URL링크를 참고하는 것을 제한할 수 있다.

● AWS Firewall Manager

AWS Firewall Manager 은 유저의 여러 개의 계정과 어플리케이션에 있어서 일원화된 AWS WAF를 간단히 설정하고 관리할 수 있는 세큐리티 관리 서비스이다.

 

[Lambda]

● Lambda 함수는 stateless한 어플리케이션 처리 비용을 최적화한다.

● Lamdba는 서버리스 컴퓨팅에 사용할 수 있으나, 여러 개의 AWS 서비스를 이용한 서버리스 워크플로우를 구성하는 것은 불가능하다. 

● Lamdba의 /tmp 디렉토리의 스토리지는 512MB까지 사용할 수 있으며, 동시 실행 수는 1000으로 함수와 레이어 스토리지 75GB이다.

● Lamdba는 서버를 프로비저닝하거나 관리할 필요없이 코드를 실행할 수 있는 컴퓨팅 서비스이다. AWS Lambda는 필요할 때에만 코드를 실행하고 하루에 여러 개의 리퀘스트로부터 1초마다 수천 개의 리퀘스트까지 자동적으로 스케일링한다. Lambda함수를 이용하여 DynamoDB부터 일정 간격으로 데이터를 취득하여 로그 분석을 실시한 후에 분석 결과를 S3 서버에 저장하는 구조로 만들 수도 있다.

● Lambda Layer

여러 개의 Lambda함수로 라이브러리를 공유할 수 있는 조합으로 일정의 기능을 Layer로써 모아서 이용할 수 있다. 지금까지는 같은 라이브러리를 이용하는 함수가 여러 개 있는 경우, 모든 함수에 대해 라이브러리를 포함하여 패키징할 필요가 있었다. 따라서 라이브러리를 Layer로써 업로드해놓는 것으로 각각의 함수는 공통의 Layer를 사용하는 것이 가능하다. 즉 Lambda Layer를 사용하는 것으로 중복 부분을 공유화하는 것이 가능하다.

● Lamabda 엣지

Lamabda 엣지를 사용하면 서버 관리를 하지 않아도 웹 어플리케이션을 글로벌로 분산시켜 퍼포먼스를 향상시킬 수 있다.

● Invocation

Invocation이란 Lamdba함수의 이름공간에 있는 매트릭스이다. 이벤트 혹은 API를 호출로 인해 호출된 함수의 횟수를 측정한다. 

● C# 언어로 된 코드를 호스트할 수 있다.

※ AWS Config, DynamoDB, AWS Batch 등에서는 C# 프로그래밍 언어 코드를 호스트 할 수 없다.

 

[Route53]

● Amazon Route53 헬스체크에서는 웹 어플리케션, 웹 서버, 그 외의 리소스가 정상적으로 작동하는지 감시한다. 다음의 방법 중 하나로 Route53는 퍼포먼스를 모니터링한다.

1) 웹 서버 등의 지정 리소스의 헬스 체크

2) ELB등의 다른 헬스 체크의 상태

3) Amazon CloudWatch 알람의 상태

● Route53의 위치 정보 라우팅을 사용하면 유저의 위치 정보, 즉 DNS 쿼리의 발신 위치를 바탕으로 트래픽을 처리하는 리소스를 선택할 수 있다. 예를 들어, 유럽에서 부터 모든 쿼리를 노르웨이 지역의 ELB 로드 밸런서에 라우팅하고, 아시아 지역의 쿼리는 도쿄 리전의 ELB 로드 밸런서에 라우팅하도록 설정할 수 있다.

● Route53는 동일 기능을 실행하는 EC2 인스턴스가 여러 개 있는 경우, 리소스가 정상인지 체크하고 정상적인 리소스만을 사용하여 DNS 쿼리에 응답하도록 설정할 수 있다. 구체적으로 "example.com 사이트"가 세계 중 세 개의 거점의 데이터 센터에 각각 2대씩, 도합 6개의 서버에서 호스트되고 있다. 이러한 서버들의 정상 여부를 체크하고 그 시점에 정상적인 서버만을 사용하여 example.com의 DNS 쿼리에 응답하도록 Route53을 사용하여 설정하는 것이 가능하다.

● Route53의 성능 설정의 액티브/액티브 구성으로 레이턴시 라우팅 등의 라우팅 정책을 사용하여 fail over를 구성할 수 있다. 이 경우에는 액티브 / 액티브 구성이 되어 설정된 모든 리소스를 균등이 이용할 수 있다. 리소스를 이용할 수 없게 되면, 그 리소스의 Route 53이 이상(비정상)을 검출하고 쿼리에 대한 응답을 포함하지 않도록 한다.

● 실제 DR환경( 재난 복구) 와 원격 DR 환경을 다른 리전에 설정하고 그 관리를 Route 53으로 실시하여, AWS 의 관리형 서비스를 이용한 자동 fail over가 이용가능해지므로, DB대응을 자동화할 수 있다.

● Route53을 이용한 DR환경의 방식으로써는 아래의 두 가지가 있다.

1) 콜드 스탠바이

Amazon S3를 백업 데이터의 저장소로써 이용한다. 사전에 시스템 이미지를 클라우드에 준비해둔다. 재난발생시 클라우드 상에 있던 시스템을 실행하고 Route53으로 바꿔 복원할 수 있다.

2) 웜 스탠바이

클라우드의 스탠바이 환경에 데이터를 항시 리플리케이션한다. 보통은 스탠바이 환경을 최소한로 구성해 실행시키다가 재난 발생시 필요한 capacity로 변경한다.

스탠바이 환경의 운영이 항상필요하지만, Route53에서 시스템 교체를 빠르게 실행할 수 있다.

● Route53 네임 서버에 ALB를 지정하기 위해서는 Alias 타켓의 IP 주소를 수반하는 A레코드 (IPv4주소의 경우) 혹은 AAAA레코드 (IPv6주소의 경우)을 설정한다. Amazon Route53 Alias레코드를 사용하는 것으로 Route53은 ELB나 CloudFront등의 AWS 리소스에 트래픽을 라우팅할 수 있다. 또한, Alias 레코드를 사용하여 호스트 존안에 어떤 레코드로부터 다른 레코드에 트래픽을 라우팅할 수 있다. 도메인 트래픽을 ELB에 라우팅하기 위해서는 Amazon Route53을 사용하여 로드 밸런서를 지정하는 Alias레코드를 작성한다. Route53의 Alias레코드는 맨 처음의 AWS 리소스 등의 Alias 타켓의 DNS 명이 할당되어 있다.  

● Route53의 라우팅 정책

1) 심플 라우팅 정책

도메인에 특정 기능을 실행하는 단 하나의 리소스만 있는 경우에 사용한다. 예를 들어, example.com웹 사이트에 컨텐츠를 제공하는 1개의 웹 서버등을 생각할 수 있다.

2) fail over  정책

액티브/패시브등의 fail over를 구성하는 경우에 사용한다. 각각의 EC2인스턴스 단위에서는 정상·비정상에 대응하여 라우팅하는 것도 가능하지만, 이 설정은 세컨더리와 프라이머리 리소스에 설정한 경우에만 가능하다.

※ fail over 라우팅 정책은 IP주소를 바탕으로 EC2인스턴스 베이스의 헬스 체크가 불가능하다.

3) 위치 정보 라우팅 정책

유저의 위치(IP주소)를 기반으로 트래픽을 라우팅하는 경우에 사용한다. 유저와 리소스를 기반으로한 지리적 근접성 루팅과 비슷하지만, 리소스에 근거를 두지 않는다는 점등 부분적으로 다른다.

4) 지리적 근접 라우팅 정책

유저와 리소스의 지리적 장소를 바탕으로 트래픽을 라우팅하고 필요에 따라 트래픽을 어떤 장소의 리소스로부터 다른 장소의 리소스로 이동하는 경우에 사용한다. 또한 바이어스라는 값을 지정하여 특정의 리소스에 라우팅하는 트래픽의 양을 변경할 수 있다. 바이어스는 리소는에 라우팅되는 트래픽의 라우팅처인 지리적 리전의 사이즈를 확대 혹은 축소한다. 지러적 급천 라우팅을 설정하기 위해서는 Route 53 트래픽 워크 플로우를 사용할 필요가 있다.

5) 레이턴시 라우팅 정책

여러 개의 AWS 리전에 리소스가 있어, 레이턴시(지연)의 최소화할 수 있는 리전에 트래픽을 라우팅하는 경우에 사용한다. 이 라우팅 정책을 통해 유저에 의한 리퀘스트를 레이턴시가 낮은 리전에 리다이렉트하여 어플리케이션의 처리를 고속화한다.

6) 여러 개의 값을 회답하는 라우팅 정책

랜덤으로 선택된 최대 8개의 정상 레코드를 사용하여 Route53이 DNS쿼리에 응답하는 경우에 사용한다. 이 정책을 이용해 Amazon Route 53이 DNS 쿼리에 대한 응답으로써 여러 개의 값(웹 서버의 IP 주소 등)을 반환하도록 설정할 수 있다. 복수값 회답 라우팅은 각 리소스가 정상인지 아닌지를 확인하기때문에 Route53은 정상적인 리소스 값만을 반환할 수 있다. 따라서 EC2인스턴스 단위로 정상·비정상을 판단하여 라우팅할 수 있다. 이것은 로드 밸런서에 대신하는 것은 아니지만, Route53이 설정한 인스턴스의 트래픽이 정상인 것을 헬스 체크한 후에 여러 개의 IP주소를 반환하는 것이 가능해, DNS를 사용하여 가용성 및 로드 밸런싱을 향상시킬 수 있다.

7) 가중 라우팅 정책

지정한 비율로 여러 개의 리소스에 트래픽을 라우팅하는 경우에 사용한다.

● 퍼블릭 호스트 존 설정

퍼블릭 호스트 존은 인터넷상에 공개되어있는 DNS 도메인 레코드를 관리하는 컨테이너이다. 예를 들어 example.com 등의 도메인의 트래픽을 인터넷 혹은 특정 도메인에 라우팅하는 정보를 보유하고 있다. 또한 인터넷의 DNS 도메인에 대응하는 트래픽의 라우팅 방법을 정의하고 있다.

※ Amazon Route53은 SSL증명서와 도메인의 대응 관계를 검증하는데에는 이용하지만 SSL 증명서의 작성·관리는 할 수 없다.

 

[Glacier]

● Glacier Deep Archive 스토리지 클래스

내구성이 있고 안전한 대량 데이터용의 스토리지를 AWS에서 제일 저렴한 가격에 제공할 수 있도록 설계되어 있다. 데이터는 3개 이상의 AWS AZ에 골고루 저장되어 12시간 이내에 데이터를 뽑아낼 수 있다.

S3와 연계해서 S3의 라이프 사이클 관리를 특정 S3에 적용해서 일정 기간이 넘은 객체를 자동적으로 다른 스토리지에 전환하거나 삭제하는 것이 가능하다. 

● 데이터 취득

1) 표준 데이터 취득

표준 취득으로는 3~5시간 이내에 모든 아카이브에 액세스할 수있다.

2) 신속한 데이터 취득

아카이브의 서브넷이 당장 필요한 경우에 데이터에 빠르게 액세스할 수 있다 최대 규모의 아카이브(250MB이상)을 제외하고 모든 아카이브에 대해 빠르게 취득하여 액세스한 데이터를 1~5분 이내에 사용할 수 있게 된다. 프로비전드 Capacity는 신속한 데이터 취득을 필요로 할 때에 이용할 수 있도록 보장한다. 

3) 대용량 데이터 취득

Glacier에서 최고로 저렴한 데이터 취득 옵션으로 이것을 사용하여 대량의 데이터 (페타바이트의 데이터를 포함하여)를 1일이내에 취득할 수 있다. 보통 대용량 취득은 5~12시간이 필요하므로 10시간이내에 대응할 수없다.

● Vault lock 정책

Vault lock 정책을 사용하여, Glacier의 각 Vault에 대해 컴플라이언스 관리를 간단히 디플로이하여 적용할 수 있다. 그리고 Vault lock 정책을 사용해 "write once read many(WORM)"등의 컨트롤을 지정하여 정책을 lock하여 이후에 편집할 수 없도록 한다. 

● Glacier은 기본적으로 암호화하기 때문에 별도의 유효화 기능은 없다.

● Glacier에는 Read Only을 유효화하는 기능은 없다.

 

[DynamoDB]

● AWS 에서는 DynamoDB가 섹션 데이터나 유저 설정, 메타 데이터등을 저장하기 위한 이상적인 데이터베이스 서비스이다.

● DynamoDB스트림

데이터베이스에 저장된 데이터 항목에 대해 추가, 변경, 삭제가 발생한 이력을 저장하기 위해 DynamoDB를 사용할 수 있다. DynamoDB 스트림을 DynamoDB 테이블에 저장된 항목의 변경을 캡쳐할 수 있다. 예를 들어, 유저가 데이터를 DynamoDB테이블을 추가했을 때에 이 이벤트를 기점으로 데이터 관리자에 메일 송신하여 DynamoDB 변경을 통지를 알리는 것고 구현할 수 있다. 

 따라서 DynamoDB스트림을 유효화하여 DynamoDB 테이블에 데이터 등록이나 갱신 등의 이벤트를 트리거 설정하여 Lambda함수 등을 실행하여 처리할 수 있다.  이 기능을 통해 DynamoDB의 데이터를 취득하는 것도 가능하지만 정기적으로 데이터를 취득할 수 있도록 하는 것이 아닌, 이벤트 기반으로 실행되도록 할 수 있다.

● AppSync

DynamoDB는 리얼타임의 데이터 집계 처리에 사용할 수 있다. 내구성, 확장성 및 가용성이 높은 데이터 저장소이기 때문이다. AppSync를 사용하여 DynamoDB의 데이터를 실시간으로 최신 상태를 유지하는 콜라보레이션 어플리케이션을 간단히 구축할 수 있다. 따라서 어플리케이션은 Amazon DynamoDB 데이터에 액세스하거나 EC2 인스턴스나 AWS Lambda함수가 데이터 처리를 실행하는 등의 기능을 구현할 수 있다. 

즉 DynamoDB와 AppSync을 연동하여 실시간 처리 기능을 구현할 수 있다.

● DynamoDB와 EMR을 합쳐서 DynamoDB에 축척된 빅데이터를 EMR로 분석처리할 수 있다. EMR는 빅데이터 분석 처리의 Apach Hadoop등을 실행할 수 있는 서비스이다. 다만 리얼타임 행동 분석이나 랭킹 처리에는 AppySync를 이용하는 것이 최적의 선택이다.

● DynamoDB와 API Gateway그리고 Lambda함수를 합쳐서 API로부터 DynamoDB 데이터를 호출할 수 있다.

● DynamoDB Accelerator

DynamoDB 전용의 인메모리형 캐시 클래스를 추가하여 캐시로부터의 응답을 밀리초 단위로부터 마이크로초 단위까지 고속화할 수 있다.

● DynamoDB 글로벌secondary index

에러처리의 유연성을 높이는 기능이다.

● DynamoDB는 1일 10조건이상의 리퀘스트를 처리할 수 있어, 매초 2000만건이 넘는 리퀘스트 처리가 가능한 NoSQL형의 데이터 베이스이다. DynamoDB는 키-값 형의 연계된 단순 데이터형식을 고속으로 처리하는 데에 적당하여, IoT 데이터나 섹션 데이터 관리 등에 이용된다. 또한, DynamoDB의 Time-to-Live(TTL) 매커니즘을 통해 주로 키를 이용해 인덱스를 붙인 구조화 데이터를 저장할 수 있다. 이것으로 1바이트부터 최대 400KB까지의 범위의 항목에 대해 낮은 레이턴시로 읽어들이기 및 쓰기 액세스가 가능해 메타데이터의 저장에 적합하다.

● 결과 정합성 모델

DynamoDB에서는 강력한 정합성을 설정할 것인지를 지정할 수 있다. 결과 정합성 모델을 선택하면 읽어들이기 스루풋이 최대 한계치까지 향상된다. 그러나 결과 정합성 읽어들이기에서는 최신의 결과가 반영되어 있지 않을 가능성이 있다. 따라서 이러한 문제를 해결하기 위해서는 결과 정합성 모델을 강력한 정합성 모델로 변경할 필요가 있다. 

● DynamoDB의 DAX

특정의 데이터 영역에 처리가 집중될 때, DXA를 유효화하여 인메모리 DB를 이용한 고속 처리를 실현할 수 있다. 1초당 리퀘스트 수가 수백만건이 되는 처리에 대해서도 미리 세컨드부터 마이크로세컨드로 최대 10배 성능이 향상된다. 

※ 이것은 오래된 데이터를 읽어 들일 가능성을 방지하는데에는 사용하지 않는다.

※ DAX는 인메모리 DB를 이용하기 때문에 비용이 높다. 따라서 스파이크 개선을 위해 비용 대비 효과가 좋은 솔루션은 SQS큐에 의한 처리를 분산하는 것이다. SQS는 어느정도 규모의 분산 소프트웨어 요소와 마이크로 서비스간에 통신을 확실시 하기 위해 완전히 관리되는 메시지 큐 서비스이다. DynamoDB로의 처리 리퀘스트를 SQS뉴로써 Lambda와 합쳐서 DynamoDB으로의 데이터 처리를 설정하는 것으로 DynamoDB는 처리할 수 없는 리퀘스트 큐를 대기시킬 수 있다.

※ 글로벌 인덱스를 작성하고 DynamoDB를 멀티AZ에 전개하는 것으로 가용성을 높일 수 있지만, 스파이크를 개선하지 못한다. 

● DynamoDB의 글로벌 테이블 설정

이 설정을 통해 여러 개의 리전의 테이블을 동기화할 수 있다.

※ DynamoDB에는 레플리케이션의 설정을 유효화하는 기능이 존재하지 않는다.

● CloudWatch를 사용하여 DynamoDB를 모니터링하는 것으로, DynamoDB로부터 raw 데이터를 수집하고 거의 리얼 타임으로 메트릭트를 가공하는 것이 가능하다. 

※ 여기서 CloudWatch는 DynamoDB 테이블의 데이터가 변경된 경우의 메타 데이터를 저장할 수는 없다. 

 

[CloudFront]

● 글로벌한 컨텐츠 배송을 위한 CDN 서비스로 엣지에 캐시를 축적하는 방법을 사용한다.

● ALIAS 레코드를 사용해 CloudFront를 구성하는 것으로 Route53에 CloudFront를 설정해 도메인을 관련짓는 것이 가능하다.

일반적인 Route 53 레코드는 표준 DNS 레코드를 사용하지만, CloudFront등의 AWS리소스를 구성하는 경우는 ALIAS 레코드를 반드시 시용해야한다. ALIAS 레코드는 DNS 기능에 대한 Route 53 고유의 확장 기능을 제공하고 있다. IP주소 혹은 도메인명 대신에 ALIAS레코드에서는 CloudFront, Elastic Beanstalk 환경, ELB, 정적 Web 사이트로써 설정되어 있는 Amazon S3버킷으로의 포인터, 혹은 같은 호스트 존내의 다른 Route53레코드를 설정할 수 있다.

● CloudFront의 IP 매치 조건은 주로 리퀘스트의 발신처의 IP주소를 바탕으로 하여 착신 Web 리퀘스트를 허가 혹은 블록하기 위해 사용된다.

● CloudFront의 서명이 붙은 Cookies기능을 통해 프라이빗 파일에 액세스할 수 있는 유저 권한을 관리할 수 있다.

● CloudFront의 서명이 붙은 URL와 서명이 붙은 Cookie는 같은 기본 기능을 제공하고 있어, CloudFront가 배달하는 컨텐츠에 액세스할 수 있는 유저를 제어할 수 있다. 차이점은 다음과 같다.

서명이 붙은 URL을 사용하는 경우는 아래의 경우이다.

1) 어플리케이션의 인스톨 다운로드등, 각각의 파일으로의 액세스를 제어하고 싶다. 

2) 유저가 쿠기를 서포트하고 있지 않은 클라이언트를 사용하고 있다.

그리고 다음과 같은 경우에 서명이 붙은 Cookie를 사용한다.

1) HLS형식의 동영상 모든 파일, 혹은 Web 사이트의 구독자 영역의 모든 파일 등, 제한이 있는 다수의 파일에 액세스를 제공하고 싶다.

2) 현재 오브젝트 URL를 변경하고 싶지 않다.

● OAI(오리진 액세스 아이덴티티)

OAI로 특별한 CloudFront유저를 작성하여 S3 버킷으로의 액세스를 제한할 수 있다. 이것에 의해 유저는 S3버킷에 직접 URL을 사용하여 파일에 액세스할 수 없게 되어, CloudFront를 통해 제공하는 파일으로의 안전한 액세스를 유지하는 것이 가능해진다.

※ CloudFront에서 Referer제한에 의한 액세스 제한을 직접 구현할 수 없다. 이 기능을 구현하기 위해서는 WAF를 사용할 필요가 있다.

※ S3의 데이터 암호화를 실시하여 암호화키를 CloudFront에 연계해 액세스 범위를 제어하는 대응은 할 수 없다.

※ CloudFront내에 CloudFront의 액세스 설정을 유효화하는 별도의 설정은 존재하지 않는다. 

● CloudFront 디스트리뷰션

CloudFront 디스트리뷰션에는 fail over옵션이 제공되어 있다. CloudFront으로의 fail over은 기존의 Route53의 DNS fail over을 이용하여 구현할 필요가 있다. 따라서 CloudFront쪽에서 fail over의 컨트롤을 할 수 있게 된다. CloudFront fail over 옵션은 사이트 단위에서의 fail over이 아닌 객체 단위의 fail over이다.

● 비용 산출 요소

▷ 트래픽의 분산

데이터 운송과 리퀘스트의 가격이 리전에 따라 달라, 가격은 컨텐츠가 배달되는 엣지의 장소에 따라 다르다.

▷ 리퀘스트 수

리퀘스트(HTTP혹은 HTTPS)의 수와 종류, 및 리퀘스트가 실행된 지역.

▷ 데이터 운송 아웃

Amazon CloudFront엣지 로케이션으로부터 전송된 데이터의 양

● Cloudfront는 쿼리 문자열을 사용하여 오리진에 일정한 정보를 송신하므로 쿼리 문자열에 대해서 처리를 변경하는 것이 가능하다. 쿼리 문자열은 웹 리퀘스트의 일부로 "?"의 뒤에 추가된다. 이 문자열에 &문자로 구분되는 패턴을 1개 이상 포함시키는 것도 가능하다.

예를 들어 쿼리 문자열에 2개의 패턴(color=red, size=larget)가 포함되어야 한다면 다음과 같이 작성할 수 있다.

http://pintor.cloudfront.net/images/image.jpg?color=red&size=large 

● AWS 책임 공유 모델을 바탕으로 PCI 혹은 HIPAA 준거한 워크 로드를 실행하고 있는 경우, 감찰을 위해서 과거 365일간의 CloudFront사용 상황 데이터를 기록하는 것이 중요하다. 사용 상황 데이터를 기록하기 위해서는 CloudFront 액세스 로그를 유효화하여 CloudFront API에 송신된 리퀘스트를 캡쳐할 수 있도록 할 필요가 있다.

● CloudFront 캐시 통계 레포트

CloudFront 캐시 통계 레포트를 이용하여 CloudFront 엣지 로케이션에 관련된 통계를 그래프로 표시할 수 있다.

● CloudFront는 각 엣지로케이션에서 파일을 압축할 수 있다. 즉 콘텐츠의 압축이 가능하다. 뷰어가 리퀘스트 헤더에 Accept-Encoding:gzip을 포함하고 있는 경우에 CloudFront는 파일을 압축하여 전송하도록 설정할 수 있다. 콘텐츠가 압축되어 있으면 파일이 작아지므로, 다운로드 시간이 단축된다. 따라서 경우에 따라서는 오리지널의 4분의 1이하로 사이즈까지 압축시킬 수 있다. 특히 JavaScript와 CSS 파일에서는 다운로드 시간이 단축되면 유저에 웹 페이지가 표시되기까지의 시간이 단축된다. 또한 CloudFront의 데이터 전송 비용은 공급되는 데이터의 총량을 바탕으로 하기 때문에 압축 파일을 공급하면 압축하지 않은 파일을 공급하는 것보다 비용이 저렴해진다.

● CloudFront에서 캐시 보관 기간을 줄이면 캐시의 유효기간이 짧아져 오리진 서버로 부터 파일을 자주 가져와야하므로 비용이 높아진다.

● CA 증명서

오리진이 ELB가 아닌 경우 안전한 통신을 위해, 신뢰할 수 있는 CA를 이용해 증명서가 발행되도록 할 필요가 있다. 그리고 이 CA증명서를 오리진과 CloudFront엣지쪽 양쪽에 이용하여 HTTPS로 데이터 통신이 될 수 있도록 해야한다.

CloudFront 디스트리뷰션 내에 1개 이상의 캐시 동작을 설정하여 뷰어와 CloudFront와의 통신으로 HTTPS가 필수가 되도록 할 수 있다. 또한 1개 이상의 캐시 동작으로 HTTP와 HTTPS 둘 다 허가하도록 구성하고, CloudFront에 대하여는 일부 오브젝트에 HTTPS가 필수가 되도록 할 수 있다. 설정 방법은 오브젝트 URL내에 사용하고 있는 도메인명에 따라 다르다.

독자적인 도메인명(example.com 등)을 사용하고 있는 경우, CloudFront의 몇 가지 설정 변경이 필요하다. 또한 AWS Certificatite Manager(ACM)이 제공하는 SSL/TLS 증명서를 사용할 것인지, 서드 파티 인증 기관으로부터 증명서를 ACM 혹은 IAM 증명서 저장소에 import할 것인지를 정해 자기 서명한 증명서를 작성하여 import할 필요가 있다.

▷ 뷰어와 CloudFRont간의 HTTPS Comodo, DigiCert, Symantec 혹은 그 외의 서드파티 프로바이더 등과의 신뢰할 수 있는 증명국(CA)에서 발행된 증명서를 사용할 수 있다. 또한 AWS Certificate Manager(ACM)이 제공하는 증명서도 사용할 수 있다.

▷ CloudFront와 커스텀 오리진 간의 HTTPS 오리진이 ELB 로드 밸런서 이외의 오리닞인 경우, 신뢰되는 서드 파티 인증 기관(CA)(Comodo, DigiCert, Symantec등)에 의해 서명된 증명서를 사용할 필요가 있다.

 

[NAT게이트웨이]

● NAT 게이트 웨이는 프라이빗 서브넷의 인스턴스로터 인터넷에 견결하기 위한 주소변환을 실시하는 라우팅 서비스이다. 

※ 사이트간의 접속에는 사용되지 않는다.

● NAT 인스턴의 대신에 사용할 수 있는 관리형 서비스이다. 이것은 AWS쪽에서 확장성등의 성능이 보증하기 때문에 NAT 게이트웨이를 사용하는 것으로 NAT 인스턴스의 보틀넥의 개선으로 이어진다. NAT 인스턴스 자체의 인스턴스 타입을 변경하는 등의 스케일링에도 효과가 있지만, 향후에 문제가 발생하지 않는다고는 보장할 수 없다.

● 보틀넥 현상이 나타나는 NAT 게이트 웨이에 의한 주소 변환 처리를 고가용이 되도록 하기위해 2개 이상의 AZ의 여러 개의 퍼블릭 서브넷에 대해 여러 개의 NAT 게이트 웨이를 구성할 필요가 있다. 따라서 1개의 AZ가 정지된 경우에도 다른 NAT 게이트웨이가 인터넷 트래픽을 처리할 수 있게 된다.  

또한, NAT 게이트웨이를 복수의 AZ에 배포한 후에 각 NAT 게이트 웨이에 대해, 각 AZ에 있어서 프라이빗 서브넷으로의 라우팅 테이블에서 루트를 설정할 필요가 있다. 

 

[Amazon Elastic Transcode]

동영상의 트랜코스 처리의 작업은 파이프라인이 요청을 수신한 순서대로 처리가 실행된다. 작업의 변경 프로세스로는 입력 파일 사이즈, 해상도, 비트레이트 등 많은 변수가 변환 속도에 영향을 준다.

 

[최대한 보안을 강화한 구성]

Web서버와 데이터베이스 서버 어느쪽에라도 프라이빗 서브넷을 통해 이동하고, NAT 게이트웨이를 퍼블릭 서브넷에 위치시키는 구성이다. 퍼블릭 서브넷의 거점 서버 혹은 ELB를 통해 WEB 서버로 액세스를 가능하게 한다.

 

[EC2 인스턴스]

● EC2 인스턴스의 재실행

 EC2인스턴스의 퍼블릭 IP주소는 인스턴스의 정지후에 해방된다. 따라서, 도메인명에 맵핑되어있던 이전의 IP주소가 무효화되어 액세스할 수 없게 된다. EC2인스턴스에 Elastic IP를 설정하여 EC2 인스턴스의 재실행후에도 IP주소를 유지할 수 있게 되어 IP주소에 대응하는 도메인명을 계속해서 이용할 수 있게 된다.

 또한 Route53의 트래픽 설정이 필요하다. IP주소의 변경이 발생하지 않도록 대응하는 것이 본질적인 해결책이 된다. Route53의 설정 변경은 IP주소의 변경된 경우의 사후대응이다.

● 라우팅의 종류

1) 심플 라우팅

도메인에 특정 기능을 실행하는 단 하나의 리소스가 있는 경우에 사용한다. 심플 라우팅에서는 트래픽을 여러 개의 인스턴스 등에 분산하여 라우팅하므로 랜덤으로 제어가 된다.

2) 가중 라우팅

지정한 비율로 여러 개의 리소스에 트래픽을 라우팅하는 경우에 사용한다. 이것은 하나의 도메인 명(example.com) 혹은 서브넷명 (axme.example.com)에 여러개의 리소스를 관련지어 각 리소스에 라우팅된 트래픽의 수를 선택할 수 있다. 이것은 부담 분산이나 새로운 버전의 소프트웨어의 테스트 등, 다양한 목적으로 사용된다.

3) 레이턴시 라우팅(연장 라우팅)

여러 개의 AWS 리전에 어플리케이션이 호스트되어 있는 경우, 네트워크 레이턴시가 최대한 낮은 AWS 리전을 바탕으로 리퀘스트를 처리하여 유저의 성늘을 향상시키는 것이다. 

4) Fail over 라우팅

fail over에 의한 이상한 리소스로의 라우팅을 중지시키고, 정상적인 리소스로 트래픽을 라우팅하도록 한다. 

● EC2 인스턴스의 디폴트 매트릭스 이외의 상세한 로그 정보를 취득하기 위해서는 CloudWatch의 두 가지 서비스를 이용할 필요가 있다. 

1) CloudWatch에이전트

이 에이전트를 대상 EC2인스턴스에 인스톨하여 CloudWatch에 의한 서버 내부의 상세 로그를 취득할 수 있게 된다.

2) CloudWatch Logs

CloudWath Logs는 취득한 로그를 집약할 수 있어, EC2인스턴스의 로그 관리를 할 수 있다. 

● 로드 밸런스

ELB를 이용하여 SSL/TLS 프로토콜을 사용하여 통신을 암호활 할 수 있다. 이 기능에 의해 로드 밸러서와 HTTPS 섹션을 개시하는 클라이언트간, 및 로드 밸러서와 EC2 인스턴간의 접속의 트래픽 암호화를 할 수 있다. 

1) ALB

ALB는 URL 경로는 바탕으로한 리퀘스트를 전송하는 룰을 가진 리스너를 작성할 수 있다. 이 방식을 패스 라우팅이라고 부른다. 여러 개의 태스트를 실시하는 EC2인스턴스 그룹이 있는 경우에 패스 라우팅을 사용하여 1개의 ALB에 여러 개의 백엔드 서비스에 트래픽을 라우팅하는 것이 가능하다.

< ALB의 특징 >

- L7에 대응

- URL 패턴을 바탕으로 라우팅이 가능한 패스 베이스 라우팅이 가능

- WebSocket와 HTTP/2의 리퀘스트를 이용할 수 있다.

- 하나의 인스턴스에 여러 개의 포트를 등록할 수 있다.

- EC2 인스턴스를 타켓 그룹에 할당할 때, 여러 개의 포트를 각각의 타켓으로써 등록하는 것이 가능하므로, 포트를 이용하는 컨테이너를 로드 밸런싱할 수 있다.

- 타켓 그룹으로의 헬스체크가 가능

- 액세스 로그를 취득할 수 있다.

- EC2와 동일하게 삭제 보호가 가능하다.

- ALB자체가 자동적으로 Capacity를 증감한다.

※ ALB에는 fail over 트래픽 제어라는 기능이 존재하지 않는다. 

2) CLB

CLB는 여러 개의 백엔드 서비스에 트래픽을 라우팅할 때에 서브도메인을 분할하는 등의 구조가 복잡하다.

3) NLB

NBL는 OSI모델의 제 4층에 기능하며, 매초 수 백만의 리퀘스트를 처리할 수 있는 고성능 로드 밸런서이다. 패스 라우팅은 실행가능하지만, 대규모 시스템용의 고성능 ELB이다.

● EC2 인스턴스내에서 클라우드와 ELB간의 데이터 보호 방법

1) AWS Certificate Manager

AWS Certificate Manager를 이용해서 SSL 증명서를 생성하고 ELB에 설정하여 증명서의 비용의 실질적인 추가없이 안전히 사이트를 준비할 수 있다. 즉 AWS Certificate Manager을 이용해서 클라우드와 ELB간의 데이터 보호를 실현할 수 있다.

2) ALB를 이용해서 리스너 설정에 HTTPS(443)를 추가하고 SSL증명서를 설정한다.

※ 단순히 ALB를 이용한다고해서 자동으로 SSL 증명서가 설정되는 것은 아니다.

● EC2 인스턴스는 IAM데이터 베이스 인증을 이용하여 DB인스터스에 액세스할 수 있다. 이 인증 방식은 DB인스턴스에 접속할 때에 패스워드가 아닌 인증 토근을 사용한다. 인증 토큰은 Amazon RDS가 리퀘스트에 대응해 생성되는 임의의 문자열로 AWS 서명버전4를 사용하여 생성된다. 각 토큰은 15분의 유효시간이 있다. 인증 토큰은 IAM를 사용해 외부에서 관리되기 때문에 유저 인증 정보를 데이터 베이스에 보존할 필요가 없다.

● 클러스터 플레이스먼트 그룹

클러스터 플레이스먼트 그룹은 여러 개의 EC2 인스턴스간에 통신을 향상 시키는 구조로 되어 있다. 1개의 500GB EBs 볼륨을 가진 EC2인스턴스로, 이 데이터 베이스는 하나의 EC2 인턴스로 구성되어 있다.

● 확장 네트워킹 기능

확장 네트워킹 기능은 EC2 인슨터스에 대해 높은 I/O 퍼포먼스와 낮은 CPU 사용률을 제공하는것으로, 이것은 PV AMI의 대신에 HVM AMI를 사용할 필요가 있다.

● 인스턴스 종류

1) 3en 인스턴스

Amazon EC2에 있어서 GB당 가격이 가장 저렴한 스토리지 최적화 인스턴스이다. 이 인스터 타입은 수만개의 IOPS도 낮은 레이턴시로 랜덤 I/O오퍼레이션용으로는 사용되지 않는다. 

2) T3 인스턴스

이 인스턴스는 범용 인스턴스의 하나로 베이스 라인 수준의 CPU 퍼포먼스를 제공하는 차세대 범용 인스턴스타입이다. 언제든 필요할 때에 CPU 사용율을 버스트 시키는 기능이 제공된다.

3) D2 인스턴스

스토리지 최적화 인스턴스이지만, HDD 베이스이다. 이 인스턴스 타입은 최대 48TB의 HDD 베이스의 로컬 스토리지를 이용하고 있다.

4) H1 인스턴스

스토리지 최적화 인스턴스이지만, HDD베이스이다. 이 인스턴스는 최대 16TB의 HDD 베이스의 로컬 스토리지가 준비되어 있어 높은 디스크 스루풋 및 밸런스의 컴퓨팅과 메모리를 실현하고 있다.

5) R5 인스턴스 

메모리 바운드의 워크 로드에 최적화된 인스턴스 타입이다. 우수한 네트워크 스루풋 및 패킷율 퍼포먼스를 활용할 수 있는 애플리케이션에 이상적인 인스턴이다.

이 인스턴스는 높은 퍼포먼스 데이터베이스, 웹 규모의 분산형 인메모리 캐시, 중간 규모 인스턴스 메모리 데이터 베이스, 실시간 빅 데이터 분석, 그 외의 기업 어플리케이션 등에 이용된다. 따라서 빅데이터 센터를 리얼타임으로 처리하는 워크플로우에 최적화된 인스턴스인다.

6) A1 인스턴스

범용 인스턴스의 하나이다. 스케일 아웃형의 Arm베이스의 워크로드에 최적화된 인스턴스 타입으로 대폭 비용 절감을 실현할 수 있다. 빅데이터 분석용 인스턴스는 아니다.

7) M5 인스턴스

범용 인스턴스의 하나로 이 패밀리는 밸런스 잡힌 컴퓨팅, 메모리 및 네트워크의 리소스를 제공하여 많은 어플리케이션에 적합하다. 

Amazon EC2 M5인스턴스는 차세대 Amazon EC2 범용 컴퓨팅 인스턴스이다. M5인스턴스는 다양한 워크로드용으로 컴퓨팅, 메모리, 네트워킹 리소스를 좋은 밸런스로 제공하고 있다. 

새로운 EC2 인스턴스를 실행하는 경우, EC2는 상관성의 에러를 최소한으로 하기 위해 모든 인스턴스의 기반이 되는 하드웨어에 분산되어 있도록 인스턴스를 배치한다. 플레이스먼트 그룹을 사용하는 것으로 워크 로드의 니즈에 대응하도록 독립한 인스턴스의 그룹의 플레이스먼트에 영향을 미칠 수 있다. 이 설정은 그곳에 플레이스먼트 그룹을 구성한 뒤, 그 안에 인스턴스 타입과 인스턴 수를 결정하면 된다.

● 온디맨드 capacity예약

정기적인 인스턴스를 이용하기 위해서는 스케줄드 리저브드 인스턴스를 이용하는 것이 최고의 방법이지만, 현재는 사용할 수 없게 되었다. 따라서 그 대신에 온디맨드 capacity예약을 사용한다.

※ Amazon EC2 스폿 인스터를 사용하면, AWS 클라우드 내 사용되지 않는 EC2 Capacity를 활용할 수 있다. 스폿 인스턴스는 온디맨드 요금과 비교하면 최대 90% 저렴한 요금으로 이용할 수 있다. AWS에 의해 정지될 수 있는 위험ㅇ ㅣ있으므로 안정성이 요구되는 경우에는 사용하지 않는 것이 좋다.

● Amazon EC2 Instance store-backed AMI

Amazon EC2 Instance store-backed AMI를 이용하여 EC2 인스턴스를 작성하면 그 인스턴스의 데이터는 인스턴스 스토어에 보존된다. 인스턴스 스토아 볼륨 상의 데이터는 인스턴의 존속 기간중에만 지속되기 때문에 인스턴스가 종료되면 데이터도 자동적으로 삭제된다. 

인스턴스 스토어는 인스턴스용의 블록 레벨의 일시 저장소이다. 이 저장소는 호스트 컴퓨터에 물리적으로 붙어 있는 디스크 상에 있다. 인스턴스 스토어는 빈번히 변경되는 정보(캐시, 스크래치 데이터, 다른 일시 컨텐츠 등)의 일시 스토리지로써 최적이다. 또한 인스턴스의 플리트 전체에서 리플리게이트된 데이터(부하가 분산된 웹 서버 전체 등)에도 적합하다.

● 인스턴스 타입 종류

▷ 온디맨드 인스턴스

보통의 EC2인스턴스이다. 클라우드 상에 가상 영역을 빌리는 형식으로 다른 AWS 꼐정과 물리적으로 공유하고 있다.

▷ Dedicated Host

Dedicated Host는 물리적인 서버를 점유하는 인스턴스 타입이다. Dedicated Host에서 유저는 라이센스 항목의 범위안에서 소켓 단위, 코어 단위, 혹은 VM 소프트웨어 단위의 기존 라이센스를 시용할 수 있다. IAM 유저이 같은 AWS 계정에 속해있어도 권한이 다른 또 다른 IAM 유저나 IAM 그룹과 물리 서버를 공유하지 않는다.

▷ 하드웨어 전용 인스턴스

하드웨어 전용 인스턴스는 호스트 HW의 레벨에서 다른 AWS 어카운트에 속해있는 인스턴스로부터 물리적으로 분리되어 있지만, 동일 AWS 계정의 인스턴스와 HW를 공유할 가능성이 있다.

▷ 베어메탈(인스턴스 타입)

베어메탈 인스턴스를 이용하여 보통의 클라우드 서버에서는 할 수 없던 호스트 컴퓨팅의 OS등에 액세스 하는 것이 가능하다. 따라서 어플리케이션은 기반이 되는 서버의 프로세서와 메모리에 직접 액세스 가능해진다. 이 인스턴스 타입을 사용함으로써 유저는 상세한 성능 분석 툴을 이용한 어플리케이션이나 베어메탈의 인프라 구조로의 직접 액세스할 필요가 있는 특수한 워크로드, 가상환경에서는 지원하고 있지 않던 레거시의 워크플로우, 그리고 라이센스 제한이 있는 티어1의 비지니스 크리티컬한 어플리케이션을 작동시키는 것이 가능하다.

▷ 리저브드 인스턴스 타입

① 컨버터블

도중에 속성 변경이 가능하다. 인스턴스 패밀리, OS, 및 테넌시를 포함한 다른 구성으로 1개 이상의 다른 컨버터블 리저브드 인스턴스로 교환할 수 있다. 교환처의 컨버터블 리저브드 인스턴스가 기존의 컨버터블 리저브드 인스턴스와 동등 혹은 그 이상의 값인 경우에 한에 교환의 실행 횟수는 제한이 없다.

[컨버터블에서만 변경 가능한 내용]

- 인스턴스 패밀리

- OS

- 테넌시

- 지불 옵션

컨버터블 리저브드 인스턴스를 교환하는 경우, 현재의 인스턴스 수는 타켓의 컨버터블 리저브드 인스턴의 설정과 동일 혹은 그 이상의 값을 함유하는 수의 인스턴스와 교환된다.

② 스탠다드 

컨버터블과 비교하여 가격이 저렴하지만 속성 변경에 한계가 있다

③ 스케줄드

스케줄드 인스턴스는 구입 후 구입을 취소, 변경, 혹은 재구입할 수 없다.

※ 엘라스틱이라는 리저브드 인스턴스 타입은 존재하지 않는다.

● IP플로팅

EC2 인스턴스에 ELB이나 Route53을 구성하고 있으면, 특정의 EC2인스턴스에 장애가 발생했을 때에 다운타임을 최소화하여 대기열 인스턴스로 교체할 수 있다. 이 때 호스트명을 대기열의 IP주소로 다시 향하도록 하면, DNS 정보가 전달되기 전에 일정 다운타임이 발생할 가능성이 있다. 이러한 현상을 방지하기 위해서는 플로팅 IP를 이용하는데 Elastic IP 주소를 플로팅하여 즉시 다른 EC2인스턴스로 트래픽을 전환할 수 있다. 장애 발생이에는 가동계에서 Elastic IP 주소를 제외하고, 대기열 인스턴스에 재할당하여 순간적으로 트래픽의 행선지를 변경할 수 있다.

● Amazon EC2에서 인스턴스를 설정했을 때에 유저 데이터를 설정하면, 인스턴스 실행시에 스크립트을 실행할 수 있다. AWS 에서는 쉘 스크립트와 cloud-init 디레기브이라는 2개의 타입 유저 데이터를 Amazon EC2에 전달하는 것이 가능하다. 또한, 이 데이터는 일반 텍스트, 파일 혹은 base64로 인코드된 텍스트(API 콜의 경우)로 하여 실행 위저드에 전달 할 수 있다.

● EC2인스턴로부터 Amazon EBS 볼륨을 떼어내기 위해서는 명시적으로 detach할 필요가 있다. 루트 볼륨의 경우의 기본 설정은 인스턴스가 삭제될 때에 볼륨도 삭제된다.

또한, 인스턴스가 실행중인 경우에는 먼저 인스턴스부터 볼륨을 언마운트할 필요가 있다. EBS 볼륨이 인스턴스의 루트 디바이스인 경우, 볼륨을 detach하기 전에, 인스턴스가 정지되었어야한다. 따라서 오래된 EC2인스턴스를 정지한 후에 볼륨을 detach한다.

● Amazon EC2에 자신의 IP주소를 사용하기(BYIOP)

▷ Route Origin Authorization(ROA)

RIR을 통해 작성된 문서이다. ROA에는 주소의 범위, 그 주소 범위를 공개함으로써 허가되는 ASN, 및 유효기간을 포함하고 있다. ROA는 Amazon이 특정의 AS 번호의 주소 범위를 공개하는 것을 승인한다.

더욱이 AWS 계정에 대한 주소 범위를 AWS에 반입하는 것을 승인하기 위해서는 주소 범위에 대해 RDAP의 주석으로 자신의 서명이 붙은 X509 증명서를 발행할 필요가 있다. 증명서에는 공개키가 포함되어 있어 AWS는 이 공개키를 사용하여 내가 제공하고 있는 인증 컨텍스트 서명을 확인한다. 비공개 키를 안전히 관리하고 이것을 사용하여 인증 컨텍스트 메시지를 서명한다. 이러한 일련의 설정을 통해 기존의 온프레미스 환경에서 사용하고 있던 화이트 리스트를 AWS에 이동하는 것이 가능해진다.

● EC2인스턴스의 요금 발생

▷ 실행중인 EC2 인스턴스

EC2인스턴스가 AMI 인스턴스의 실행 시퀀스를 시작하면 비용 청수가 시작된다. 인스턴스를 종료시키면 비용 청구가 종료된다. 따라서 실행 중인 EC2인스턴스는 비용이 소용된다.

▷ EC2 인스턴스에 연결되어 있는 Amazon EBS 볼륨

정지된 인스턴스에 대해서는 1시간 마다의 사용료와 데이터 전송 요금이 청구되지 않지만, 연결되어 있는 Amazon EBS 볼륨의 스토리지에 대해서는 요금이 발생한다.

※ CloudFormation은 무료로 이용 가능하다.

※ VPC를 작성하고 사용하기 위한 추가 요금은 발생하지 않는다.

● 인스턴스간의 트래픽 제어

보안그룹을 사용하는 것이 적당하다. 보안 그룹에 의해 EC2 인스턴스의 IP 주소를 지정하여 특정 EC2인스턴스로부터의 트래픽을 제어할 수 있다.

※ 네트워크 ACL도 트래픽 제어할 수 있지만, 네트워크 ACL은 서브넷에 적용된다. 보안그룹은 EC2 등의 인스턴스의 트래픽을 제어한다.

● 특정 주소로만 EC2인스턴스로 액세스를 허가하는 방법은 세큐리티 그룹의 설정을 통해 가능하다. 보안그룹으로 TCP 포트범위22를 선택한다. 또 IP주소의 범위로 특정IP주소/32로 선택한다.

※ UDP가 아닌 TCP 포트 범위를 설정해야한다.

● ELB가 아닌 방법으로 트래픽 분석등의 고가용성과 내결함성을 적용하기 위해서는 가상의 Elastic IP주소를 사용하여 EC2인스턴스에 부여하는 것이 있다. Elastic IP를 사용하여 EC2인스턴의 상황을 체그하는 커스텀 스크립트를 작성한다. 스크립트를 통해 인스턴스의 응답이 정지된 경우에 Elastic IP를 스탠바이 EC2인스턴스에 할당할 수 있다. 또한 EC2인스턴스에 Elastic IP를 인스턴스에 적용하여 프록시 서버를 설치하는 것으로 외부 시스템와의 연계시에 IP주소를 특정한 연결도 가능하다. 

※ Route53을 EC2인스턴스에 설치하여 고가용성을 실현할 수 있지만, ELB대신에 Elastic IP주소를 이용한 트래픽 분산처리하는 구성을 구축할 필요가 있다. 

● Fault Tolerance(내결함성)

Fault Tolerance이란 시스템의 콤포넌트의 일부에 장애가 발생해도 할당 시스템이 동작을 계속할 수 있는 능력이다. AWS에서는 서버 장애나 시스템 장애가 발생한 경우, 실행중의 EC2인스턴스 수가 필요가 인스턴스의 최소한 수보다 떨어지지 않는 것응ㄹ 의미한다. 따라서 어플리케이션이 최저 4개의 인스턴스를 필요로 하는 경우, AZ의 1개가 정지된 경우, 혹은 서버에 문제가 발생한 경우, 적어도 4개의 인스턴스가 실행될 상황을 확보할 필요가 있다. 즉 AZ1개가 정지된 경우에도 시스템은 최저 4개의 인스턴스가 실행되어야한다는 것이다.

● ENI(Elastic Network Interface) 어태치먼트의 옵션

Elastic Network Interface(ENI)는 가상 네트워크 가드를 표시하는 VPC의 논리 네트워크 콤포넌트 서비스이다. 아래의 방법으로 네트워크 인터페이스를 EC2인스턴스에 연결할 수 있다.

▷ 실행중의 연결(핫 어태치)

▷ 정지중의 연결(웜 어태치)

▷ 인스턴스 기동중의 연결(콜드 어태치)

이 중에 스탠바이의 세컨더리 인스턴스에 연결하여 트랙픽 플로우가 몇 분이내에 재개할 수 있도록 하기 위해서는 정지시에 이용하는 웜 어태치를 사용한다. 핫 어태치에서는 항상 스탠바이의 인스턴스를 실행해 두어야하므로 비용이 저렴하다고 할 수 없다.

※ 자동연결(오토 어태치)라는 옵션은 존재하지 않는다.

● Elastic IP주소와 관련해서 요금이 발생하는 경우

▷ Elastic IP주소가 EC2 인스턴스에 연결되어 있을 때

▷ Elastic IP주소에 연결되어 있는 인스턴스가 실행중일 때

▷ 인스턴스에 1개의 Elastic IP주소만 첨부되어 있지 않은 경우

● AWS Globel Accelerator

AWS Globel Accelerator는 세계의 고객에 제공하는 어플리케이션의 가용성과 성능을 개선하는 네트워크 서비스이다. AWS 상의 어플리케이션에 대해 고정 엔트리 포인트가 되는 정적 IP 주소를 제공하는 것으로 다양한 AWS 리전, AZ의 특정 IP주소의 관리의 복잡함을 낮춰준다. EC2인스턴스를 AWS Globel Accelerator에 연결하기 위해서는 Accelerator을 작성하고 EC2 인스턴스 ID를 사용하는 엔드포인트를 EC2 인스턴스에 추가할 뿐이다. 

● 삭제·삭제 정책

▷ NewestInstance

새롭게 설취된 인스턴스부터 삭제되는 정책 설정이다.

▷ OldestInstance

오래된 인스턴스부터 삭제를 실행하는 종료 정책이다. 기존의 EC2인스턴스부터 삭제되게 된다.

▷ OldestLaunchConfiguration

OldestLaunchConfiguration는 실행 설정을 오래한 순서대로 삭제되므로 기존의 EC2 인스턴스부터 삭제될 가능성이 높다. 다른 정책을 선택하지 않는다면, 기본으로 이 정책이 실행된다. 

● 효율적으로 EC2 인스턴스를 여러 개 실행시키기

효율적으로 EC2 인스턴스를 여러 개 실행시키기 위해서는 부트스트랩과 골든 이미지를 활용할 수 있다.

▷ 부트스트랩(유저 데이터의 사용)

Amazon EC2 인스턴스를 AWS 리소스를 실행할 때, 유저 데이터를 이용하여 Bash쉘 스크립트를 이용하여 자동적으로 설정을 반영하는 것이 가능하다. 이것을 이용하여 소프트웨어를 인스톨하거나 데이터를 복사해두거나 인스턴스의 설정을 자동화할 수 있다.

▷ 골든 이미지

Amazon EC2 인스턴스, Amazon RDS DB인스턴스, Amazon EBS 볼륨등의 특정의 AWS 리소스 타입에 있어서 유저에게 맞는 최적화된 상태를 유지하는 것을 "골든 이미지"라고 부른다. 부트스트랩 어프로치와 비교하면 골든 이미지는 기동시간을 단축하고, 구성 서비스 혹은 서드 파티의 리퍼지토리로의 의존 관계를 삭제한다. 이것은 수요의 변화에 대한 대응으로 추가의 리소스를 신속하고 확실하게 실행할 수 있도록 하는 자동 스케일링 환경에서 굉장히 중요하다. 

● 2019년 9월까지는 리전 내에 실행할 수 있는 온디맨드 인스턴스 수의 최대 수는 모든 인스턴스 패밀리를 포함하여 20개로 제한되어 있었지만, 2019년 9월 24일 이후로 Amazon EC2에서 vCPU베이스의 온디맨드 인스턴스 제어가 적용되게 되었다.

● 핫 스탠바이 혹은 웜 스탠바이 등의 구성을 다른 리전에 구축하는 대응

이 구성을 실현하기 위해서는 다른 리전의 EC2 인스턴스의 복사를 실행하게 된다. Amazon EC2 인스턴스의 Amazon 머신 이미지(AMI)를 작성하고 다른 AWS 리전에 그 AWI를 복사한다. 

백업용의 리전의 Auto Scaling그룹이 설정되어 있다면 거기에서 이용되고 있는 실행 설정의 AMI ID를 변경할 필요가 있다.

※ AMI은 EBS의 복사와 인스턴스의 설정 양쪽이 포함되어 있다. 따라서 스냅샷이 아닌 AMI를 전개하는 것이 적절하다.

※ CloudFormation에 다른 리전에 있어서의 AMI ID를 셋업하여 다른 리전에서의 인프라 구성을 전개하기 위한 표준을 만드는 것이 가능하지만, 즉시 실행되지는 않으므로 요건에 따라 사용할 수 없는 경우가 있다.

● 레코드 종류

▷ CNAME레코드

도메인을 별도의 도메인에 관련짓기위해서는 CNAME레코드를 이용한다. CNAME 레코드는 별칭에 대해 정식 명칭을 지정하기 위해서의 리소스 레코드이이다. 호스명에는 정식명이외에 별명을 붙이는 것이 가능하다. DNS의 이름해결에는 CNAME리소스 코드가 발견되면, 도메인 명을 정식명으로 바꿔서 이름 해결을  계속한다.

▷ A레코드

A 레코드는 도메인 혹은 서브 도메인을 IP주소용으로 사용하는 등에 이용된다. 도메인명을 바꾸는 설정의 경우는 A레코드상에 도메인 설정을 전환하는 것도 대응 가능하지만, 도메인과 도메인의 관계 짓는 것에는 사용하지 않는다.

▷ AAA레코드

AAA 레코드는 DSN 로 정의된 그 도메인에 대한 정보 종류의 하나로, 특정 호스트명에 대응하는 IPv6주소를 정의하는 레코드이다.  

● Savings Plans

1년 또는 3년 기간 동안 일관된 양의 컴퓨팅 사용량(예: 10 USD/시간)을 약정해 Amazon EC2 및 AWS Fargate 사용 요금을 최대 72% 절감할 수 있는 새롭고 유연한 요금 모델이다.  Savings Plan을 사용할 경우 약정 사용량을 초과하지 않는 사용량에 대해서는 할인된 Savings Plan 요금이 청구되고 약정 사용량을 초과하는 사용량에 대해서는 일반적인 온디맨드 요금이 청구된다. Savings Plans는 예약 인스턴스와 마찬가지로 온디맨드보다 훨씬 나은 절감 효과를 제공할 뿐 아니라 사용량이 변동되는 경우에도 모든 AWS 리전에서 고객의 컴퓨팅 사용량 요금을 자동으로 줄여준다. 따라서 고객은 옵션을 바꾸거나 수정할 필요 없이 유연하게 자신의 필요에 가장 맞고 지속적으로 비용을 절감할 수 있는 컴퓨팅 옵션을 사용할 수 있다.

● 인스턴스 종류

▷ 고속 컴퓨팅

AI 기능에는 GPU를 이용하는 것이 최적이다. GPU를 선택하기 위해서는 고속 컴퓨팅 인스턴스를 이용한다. 고속 컴퓨팅 인스턴스는 하드웨어 액셀레이터를 사용하여 부동소수점 계싼, 그래픽 처리, 데이터 패턴 조합 등의 기능을 CPU에서 실행중인 소프트 웨어보다도 효율적으로 실행한다. 게이밍 처리나 그래픽스 처리, 기계학습의 처리에는 이 인스턴스를 사용하는 것이 좋다.

▷ 범용 인스턴스

밸런스을 잡은 컴퓨팅, 메모리, 네트워크의 리소스를 제공하고 다양한 워크 플로우에 사용할 수 있다. 범용 인스턴스는 웹 서버나 코드 리퍼지터리 등, 인스턴스의 리소스를 같은 비율로 사용하는 어플리케이션에 적합하다.

▷ 컴퓨팅 최적화 인스턴스

고속 퍼포먼스 프로세서의 혜택을 받는 컴퓨팅 바운드 애플리케이션에 이상적이다. 이 패밀리에 속해있는 인스턴스는 배치 러리 워크 로드, 미디어 트랜스 코딩, 고성능 웹 서버, 하이 퍼포먼스 웹 서버, 하이 퍼포먼스 컴퓨팅(HPC), 과학 모니터링, 전용 게임 서버 및 광고 서버 엔진, 기계학습 추론 등의 컴퓨팅 부하가 높은 어플리케이션에 최적된 인스턴스이다.

▷ 메모리 최적화 인스턴스

메모리 내의 커다란 데이터 셋을 처리하는 워크 로드에 대해서 고속화된 퍼포먼스를 실현할 수 있도록 설계되었다.

▷ 스토리지 최적화 인스턴스

스토리지 최적화 인스턴스는 로컬 스토리지의 대규모 데이터 셋에 대해 높은 시퀀셜 읽기 및 쓰기 액세스를 필요로 하는 워크 로드용으로 설계되어 있다. 스토리지 최적화 인스턴스는 수 만 회의 낮은 레이턴시와 랜덤 I/O오퍼레이션/1초(IOPS)를 어플리케이션에 제공할 수 있도록 최적화되어 있다.

● 프록시 서버를 이용한 액세스 제어

프록시 서버는 클라이언트로부터의 요구를 필터링하고 제품의 갱신과 관련하는 요구만을 허가하여 특정 소프트웨어 갱신 이외의 모든 요구를 필터링할 수 있다.

<시나리오 예> VPC의 인스턴스에 인터넷 네트워크가 필요하고, 소프트 웨어의 갱신만에 액세스를 제한할 필요가 있다. 또한 다른 아웃 아웃 바운드 접속을 명시적으로 불허하는 것이 요구되는 경우

→ 제한없이 인터넷에 액세스할 수 없도록하기 위해 EC2 인스턴스를 프라이빗 서브넷에 배치시킬 필요가 있고, 클라이언트 머신으로부터 요구를 필터링하기 위해 블록이 필요로 하므로 이러한 제어에는 프록시 서버를 이용한다.

※ 네트워크 ACL 및 보안 그룹은 URL을 바탕으로 리퀘스트를 필터링하기 위한 것이다. 

 

[Amazon Congnito]

어플리케이션의 인증기능을 구현하는 것이 가능하다. 이때에 MFA를 이용한 다요소인증과 보존 데이터 및 전송 데이터의 암호화가 가능하다. 또한, Google, Facebook, Amazon 등의 소셜 ID 프로퍼티나 SAML에 의한 Microsoft Active Directory 등의 엔터프라이즈 ID 프로바이터를 적용하여 사인인하는 것이 가능하다.

 

[CloudHSM]

● 클라우드 기반의 하드웨어 세큐리티 모듈(HSM)이다. 이 기능을 이용하면 AWS 클라우드에 암호화키를 간단히 생성하여 사용할 수 있다.

● CloudHSM는 FIPS 140-2의 레벨3 인증이 끝난 HSM을 사용하여, 암호화키를 관리할 수 있다.

 

[SES]

●  AWS에서 제공하는 E-메일 기능이다. SES는 어플리케이션을 이용하는 유저에 대해 일괄 메일을 통한 공지 전송등에 사용할 수 있다.

● 디지털 마케팅 담당자 혹은 어플리케이션 개발자가 마케팅, 통지, 트랜잭션에 관한 E-메일을 송신할 수 있도록 설정할 수 있다.

 

[Amazon Athena]

● 표준 SQL식을 사용하여 Amazon S3의 데이터를 간단히 분석할 수 있는 인터랙티브한 쿼리 서비스이다. Amazon S3에서부터 직접 데이터에 대한 쿼리 처리를 할 수 있도록 한다. 그 때에 실행하는 쿼리에 대해만 요금이 발생하며, 각 쿼리에 스캔된 데이터량을 바탕으로 과금된다. 데이터의 압축, 분할, 열 형식으로의 변환을 실행하면, 대폭 비용이 절감할 수 있으면 성능이 향상된다. 데이터처리 비용을 낮출 수 있다.

● Amazon S3의 데이터를 포인트하고, 스키마를 정의하여 표준의 SQL식을 사용하여 쿼리를 개시할 뿐이다. 대부분의 결과는 수 초 이내에 도착한다. 

※ Athena는 데이터 분석용 서비스로 데이터를 저장하거나 검색하는 것은 할 수 없다.

● Athena도 S3 Select와 같이 S3의 데이터에 대해 SQL해석이 가능한 툴이지만, 복잡한 쿼리나 기계학습에 의한 놀리를 실행할 수 있는등, S3 Select보다도 빠른 분석이 필요한 경우에 이용하게 된다.

 

[AWS Server Migration Service(SMS)]

● 온프레미스의 VMware vSphere, Microsoft Hyper V/SCVMM, 혹은 Azure 가상 머신의 AWS 클라우드로의 이동을 자동화한다. AWS SMS은 서버 가상 머신을 클라우드 호스트의 Amazon 머신 이미지 (AMI)으로써 단계적으로 리플리케이트하고 Amazon EC2에 디플로이한다. AMI를 사용하면 클라우드 베이스의 이미지를 간단히 테스트하고 갱신한 후에, 실제 실행 환경에 디플로이할 수 있다.

● 워크플로우를 AWS으로 전환시키기 위해 AWS Server Migration Service를 이용하는 것이 최적의 방빕이다. SMS은 수 천개의 온프레미스 워크 플로우를 기존보다도 더 간단히, 그리고 단시간에 AWS으로 전환시킬 수 있는 에이전트리스 서비스이다. AWS SMS에서는 라이브 서버 볼륨의 증분 레플리케이션의 자동화, 스케줄 설정 및 추적이 가능하므로 대규모 서버의 전환 작업을 간단히 조정할 수 있다.

 

[Amazon SNS]

● 어플리케이션은 "푸시" 매커니즘을 사용하여 여러 개의 서브 스크라이버에 타이밍이 증여힌 메시지를 송신할 수 있다. 따라서 갱신을 정기적으로 확인하거나 풀링할 필요가 없어진다.

SNS는 어플리케이션이나 컨포넌트간에 메시지를 송신, 수신을 반복하는 구조로 이용할 수 있다. SNS는 pup-sub에 대응하므로, SNS토핑에 메시지를 송신(publish)하면 토핑을 구독하고 있는 구독자에 메세지를 일괄저긍로 보낸다.

● SNS는 마이크로 서비스 등의 분리를 가능하게 한다.

● 한번에 송수신되는 대용량 메시지를 처리할 수 없는 경우가 있다. 또한, 데이터가 송신된 순서대로 송신되는 것을 보증하지 못한다.

● 이벤트를 트리거로 이용할 수 있다.

※ SQS는 이벤트를 트리거로 사용하지 않는 경우에 사용한다.

 

[Amazon KMS]

● AWS KMS를 이용해서 보존 데이터를 암호화 할 수 있다. KMS는 AWS의 데이터 베이스난 스토리지 서비스의 모든 것과 통합되어 있어, 암호화를 실행하는 것이 가능하다. 볼륨내의 보존 데이터나 볼륨으로부터 작성된 모든 스냅샷 데이터 보호 전송중(Amazon S3으로의 전송중)을 암호화하는 것이 가능하다. 

● AWS KMS를 이용하여 암호화한 경우에는 AWS KMS키를 복호화하기 위해 권한이 필요하다. 

 

[Amazon Data Lifecycle Manager(Amazon DLM)]

● EBS의 백업인 스냅샷의 작성, 보존, 삭제를 자동화할 수 있다. 정기 백업을 예약하여 귀중한 데이터를 보호한다.

● DLM을 이용하여 다음과 같은 설정이 가능하게 된다.

1) EBS의 정지적인 백업 스케줄을 설정하여 귀중한 데이터를 보호한다.

2) 감시 담당자 혹은 사내의 컨플라이언트가 필요한 백업을 유지한다.

3) 오래된 백업을 삭제하여 스토리지 비용을 절감한다.

 

[Aurora]

● Read replica를 최대 15개 설치하여 읽어들이기 성능을 향상시킬 수 있다. 또한 Read replica를 증강하여 읽어들이기 처리를 병렬-분산처리하면 비용 최적화를 실현할 수 있다.

● Aurora Serverless

Aurora Serverless는 부정규 부하에 대해 자동으로 스케일링할 수 있는 RDB이다. DB인스턴스 클래스의 사이즈를 지정하지 않은채로 데이터 베이스 엔드 포인트를 생성하고, 데이터 베이스 엔드 포인트는 프록시 플리트에 연결된다. 이 플록시 플리트에서는 워크 로드를 라우팅하는 곳의 리소스의 플리트가 Auto Scaling된다. 프록시 플리터를 사용하면 최소와 최대의 Capacity 사양을 바탕으로 Aurora Serverless가 리소스가 자동적 스케일링된다.

Aurora Serverless 는 읽어들이기 처리의 증가를 위해 반드시 사용할 필요는 없다. Aurora 서버리스 DB 클러스터는 어플리케이션의 니즈에 대응하는 Capacity를 자동적으로 실행, 셧다운 및 스케줄업-다운하는 것이 가능한 Aurora DB 클러스터이다. 정기적이지 않은, 단발적인, 혹은 예측 불가능한 워크 플로우에 대해 비용 효율을 좋게 하는 데이터 베이스로써 이용하는 구조이다.

Aurora Serverless에서는 DB인스턴스 클래스의 사이즈를 지정하지 않고 데이터 베이스 엔드포인트를 작성하여 최소와 최대의 Capacity사양을 바탕으로 Aurora Serverless가 리소스를 자동적으로 스케줄하기 때문에, 접속이 도중에 끊기는 경우가 없다. 따라서 처리 부담이 일정하지 않은 케이스에는 Aurora Serverless를 이용하는 것이 좋다.

※ Route 53의 Fail over 설정을 통해 EC2인스턴스나 RDS를 Fail over하는 것이 가능하다만, 이것만으로는 데이터의 동기화를 실현할 수 없으므로 먼저 RDS는 멀티 AZ 구성을 이용하는 것이 기본적인 설정이다. 또한 정해지지 않는 수요에 대한 대응도 필요한 경우에 Aurora서버리스가 최적의 선택이다. 

● RDS 오토 스케일링

데이터 용량이 부족해졌을때에 용량을 자동적으로 스케일링하는 기능이다.

● RDS 프록시

어플리케이션과 RDS 데이터 베이스 간을 중개하는 역할로 기능하는 커낵션 관리용의 RDS 신기능이다.

 

[Amazon Kinesis]

● Amazon Kinesis Data Analytics

스트리밍 데이터를 리얼타임으로 분석할 수 있다. 이것은 IoT등의 스트리밍 데이터를 대상으로 한다.

● Amazon Kinesis Data Stream

Kinesis를 이용하면 데이터의 누락이 없으며 내구성이 있고 데이터를 돡 순으로 스트리밍할 수 있다. Kinesis Data Stream은 일련의 데이터 레코드를 가진 샤드(Shard; 데이터 베이스 샤드는 데이터베이스나 웹 검색 엔진의 수평분할이다)  세트로 각 테이블 레코드에 Kinesis Data Stream을 통해 분할된 시퀀즈 번호가 있으므로, 메시지가 분실되지 않고, 중복되지 않게 도착 그리고 같은 순서대로 전송할 수 있다.

● 센서 데이터를 처리하기 위해 Amazon Kinesis를 이용할 수 있다. Amazon Kinesis Data Streams와 Lamabda를 연계시켜 데이터 처리를 서버리스로 실현할 수 있다. Amazon Kinesis Data Streams가 스트리밍 데이터 처리를 실시하여 Lambda함수가 데이터 변환처리를 한 후,  Amazon Kinesis Data Firehouse가 S3에 데이터를 저장한다. 

● Kinesis Data Firehose

Kinesis Data Firehose를 이용해서 S3에 로그를 축적하고 Athena를 이용하여 로그 분석을 실시할 수 있다. 그리고, 그 데이터 축적전에 변환 처리가 필요하게 된다. Kinesis Data Firehose에 Lambda함수를 설정하여 데이터 변환을 실시할 필요가 있다. Kinesis Data Firehose에서는 데이터 스토어에 로드하기 전에 스트리밍 데이터를 준거하도록 설정할 수 있다.

AWS 매니지먼트 콘솔의 Kinesis Data Firehose 배달 스트림 설정 태그부터, AWS Lambda 함수를 선택한다. 이 함수는 Kinesis Data Firehose에서 자동적으로 모든 입력 데이터 레코드에 적용된다.

Amazon Athena는 인터렉티브한 쿼리 서비스로, Amazon S3내의 데이터를 표준 SQL을 사용해서 간단히 분석할 수 있다. Amazon S3에 있는 데이터를 지정해서 스키마를 정의하고 표준적인 SQL을 사용하여 쿼리의 실행을 시작할 뿐이다. 대부분의 경우 몇 초 이내에 결과가 나온다. 

 

[스토리지 게이트웨이 캐시형 볼륨]

 S3를 프라미어밀 스토리지로 하여 온프레미시 스토리지와의 하이브리드 구성을 구현할 때에 사용한다. 캐시형 볼륨을 사용하여 빈번히 액세스하는 데이터가 로컬의 스토리지 게이트웨이를 통해 유지되면서 프라이머리 데이터 스토리지로써 사용될 Amazon S3에 저장된다.

 한편 스토리지 게이트웨이 보관형 볼륨은 온프레미스 어플리케이션에 의해 AWS 클라우드 스토리지의 심리스한 사용을 가능하게 하는 하이브리드 스토리지 서비스이다. 

 

[ElastiCache] 

● ElastiCache는 완전 매니지드형의 Redis 및 Memcached를 이용하는 인메모리 DB이다. 보급되어 있는 오픈소스 호환의 인메모리 데이터 스토어를 심리스에 디플로이, 운용, 스케일할 수 있는 Web 서비스이다. 

이 서비스는 저속의 디스크 베이스의 데이터 베이스에 완전히 의존하는 것이 아니므로 고속의 관리되는 인메모리 데이터 스토어로부터 정보를 취득할 수 있도록 하는 것으로 Web어플리케이션의 성능을 향상시킨다. 

랭킹이나 추천의 구현하는데에 추천하기 위해 편리한 기능이 있다.

※ 굉장히 고성능이지만, 쓰기 처리에 대해서는 강력한 정합성 모델이나 파일 lock에 대해서는 사용 되지 않는다.

● 고성능 인메모리 DB형의 키-값 스토어인 데이터베이스이다. ElastiCache는 캐시 데이터를 밀리초 아래의 레이턴시로 액세스할 수 있으므로 고속 데이터 처리를 가능하게 한다. 따라서 유저 행동 데이터를 고속도로 처리하는 것에 적합한 DB이다. 행동 데이터 기록에 대해서는 리얼 타임의 랭킹 처리나 아이템 출현 등을 구현할 수 있다.

● Amazon ElastiCache는 인메모리 데이터 스토어를 구축하는 웹 서비스이다. 이 서비스는 고속으로 관리되는 메모리 내 데이터 스토어가 있어 고속으로 데이터를 처리하여 성능을 향상시킬 수 있다. ElastiCache를 RDS와 연계시켜 데이터 처리를 일부 캐시 처리로하여 부담 개선을 실현할 수 있다.

● ElastiCache에 있어서 Redis의 특징

▷ 복잡한 데이터형을 설정할 수 있다.

▷ 인메모리 데이터셋의 정렬 혹은 랭크를 부여하는 것이 가능하다.

▷ 데이터를 Read replica에 리플리케이트할 수 있다.

▷ pub/sub기능을 제공하고 있다.

▷ 자동적으로 fail over가 가능하다.

▷ 키 스토어의 지속성이 필요하다.

▷ 백업와 복원의 기능이 있다.

▷ 여러 개의 데이터 베이스를 지원하고 있다.

● ElastiCache에 있어서 Memcached의 특징

▷ 심플한 데이터형이다.

▷ 여러 개의 코어 혹은 스토리지를 가진 커다란 노드를 실행한다.

▷ 시스템에서의 수요의 증감에 대응하는 노드를 추가 혹은 삭제하는 스케일 아웃 및 스케일인 기능을 이용할 수 있다.

▷ 데이터 베이스 등의 오브젝트를 캐시할 수 있다.

▷ 키 스트어의 지속성은 없다.

▷ 백업과 복원 기능이 없다.

▷ 여러 개의 데이터 베이스를 이용할 수 없다.

 

[Direct Connect]

온프레미스의 데이터 센터등과 전용선으로 연결할 때에 이용한다. 어디까지나 AWS의 VPC와 외부 시설 네트워크 혹은 다른 리전과의 연결에 이용된다.

 

[EBS]

● EBS 프로비저닝 IOPS 볼륨(io1)

레이턴시의 영향이 큰 트랜잭션 워크 플로우용으로 설계된 성능이 노은 SSD 볼륨이다. 가격이 비싸지만 스루풋와 IO성능이 최고 높은 볼륨이다. 비용 최적화보다고 성능이 우선되는 경우에 이 볼륨 타입을 선택한다. 

최대 64000 IOPS 까지 일관된 포퍼먼스를 제공하고 볼륨은 약 최대 1000MB(1초당)의 스루풋을 실현할 수 있도록 설계되어 있다. 

IOPS 볼륨의 사이즈 범위는 4GiB부터 16TiB이다. Nitro 시스템 인스턴스 패밀리에서는 볼륨이 약 100IOPS부터 최대 64000IOPS으로 다른 인스턴스 패밀리에서는 최대 32,000IOPS를 프로비저닝할 수 있다.

프로비저닝된 IOPS와 요구되는 볼륨사이즈(GiB단위)의 최대화는 50:1이다. 예를 들어, 100GiB볼륨은 최대 5,000 IOPS으로 프로비저닝된다. 지원하고 있는 인스턴스 타입에 사이즈가 1,280GiB이상의 볼륨도 있다면 최대 64,000 IOPS(50x1,280GiB = 64,000)까지 프로비저닝할 수 있다.

※ 수백만 개의 IOPS는 실현 불가능하다.

● 스루풋 최적화 HDD

높은 스루풋을 필요하는 액세스 빈도 높은 워크플로우용으로 저렴한 비용의 HDD 볼륨이다. 이것은 높은 스루풋 성능을 대기하면서 동시에 프로비저닝 IOPS SSD보다도 낮은 비용으로 구현할 수 있다. 따라서 스루풋 최적화 HDD는 1000MiB/s의 데이터 스루풋 성능은 불가능하다. 성능이 떨어져도 비용을 최적화하기 위해 선택한다.

● 범용 SSD

폭넓은 트랜잭션 워크 플로에 대응할 수 있는 가격과 퍼포먼스의 밸런스가 적당한 범용 SSD 볼륨이다.

● 콜드 HDD

액세스 빈도가 낮은 워크플로우용으로 설계된 저렴한 비용의 HDD 볼륨이다.

● 인스턴스가 종료되면 EC2는 연결되어 있던 각 EBS 볼륨의 DeleteOnTermination 속성을 사용하여 볼륨을 그대로 둘 것인지, 삭제할 것인지 판단한다. 기본으로는 인스턴스의 루트 볼륨의 DeleteOnTermination 속성이 유효화되어 있어, EC2 인스턴스의 삭제됨과 함께 EBS도 함께 삭제되지만, 다른 볼륨 타입에서는 DeleteOnTermination 속성이 유효화되어 있다. 인스턴스가 정지되어도 루트 볼륨을 유지하고 싶은 경우는 루트 볼륨의 DeleteOnTermination 속성을 비유효화할 필요가 있다. 비유효화함으로써 인스턴스가 삭제된 후에도 데이터를 존속시킬 수 있다.

● EBS의 미러링을 구성하여 여러 개의 EBS 블록간에 데이터를 분산 유지할 수 있다. 따라서 기본적으로는 인스턴스가 삭제되면 몇 개의 볼륨 데이터도 삭제되어버리고 만다.

● EBS의 스냅샷은 EBS의 이용상황과 관계 없이 비동기적으로 작성할 수 있다. 포인트 인타임 스냅샷은 바로 작성되지만, 스냅샷의 상태는 스냅샷이 완료되기 전까지 보류중으로 되고 최초의 스냅샷 작성에는 실행완료까지 몇 시간 걸리는 경우가 있다. 진행중의 스냅샷은 볼륨에의 진행중의 읽어들이기로 인해 영향받지 않는다. 즉 스냅샷이 취득중이래도 EBS 볼륨을 사용할 수 있다.

● EBS는 용도에 따라 볼륨 사이즈나 볼륨 타입을 변경할 수 있다는 장점이 있다.

● 단 하나의 EC2인스턴스의 EBS 볼륨은 인스턴스용의 시스템 드라이브나 데이터 베이스 어플리케이션용의 스토리지 등의 빈번히 갱신할 필요가 있는 데이터의 주요 스토리지로써 사용할 수 있다. 또한, 지속적인 디스크 스캔을 실행하여 스루풋 중시의 어플리케이션에도 사용할 수 있다. 이러한 EBS 볼륨은 EC2인스턴스의 가동기간과 관계없이 유지된다.

● EBS 볼륨은 같은 AZ 안에 있는 EC2인스턴스에만 연계시킬 수 있다. 또한 그 Zone안에서만 자동적으로 복제가 생성되지만 다른 AWS 리전에는 복제되지 않는다.

● EBS볼륨을 EC2인스턴스에 연결시킨 뒤에 EBS를 사용하도록 하기 위해서는 그 볼륨에 파일시스템을 작성할 필요가 있다. 

인스턴스에 Amazon EBS볼륨을 붙인 뒤에 임의의 파일 시스템으로 볼륨을 포맷하여 마운트할 필요가 있다. EBS 볼륨을 사용가능하도록 한 뒤에 다른 볼륨에 액세스하는 것과 같은 방법으로 EBS 볼륨에 액세스 할 수 있다. 이 파일 시스템에 적혀있는 데이터는 모드 EBS 볼륨에 쓰여진다.

※ 볼륨에 IP주소를 할당하거나 세큐리티 그룹, 마운트 타켓을 설정할 필요는 없다. 

● 기본적으로 EBS는 여러 개의 EC2인스턴스에 붙일 수 없는 스토리지 타입이다. 그러나 2020년 2월을 기점으로 Muti-Attach 기능이 추가되었다. Amazon EBS 프로비저닝 IOPS io1 혹은io2 볼륨을 이용하고 잇는 경우에만 Muti-Attach를 유효화하여 하나의 볼륨을 같은 AZ 내의 최대 16개의 AWS Nitro 시스템베이지의 Amazon Elastic Compute Cloud(Amazon EC2) 인스터에 동시에 붙일 수 있다.

Muti-Attach를 사용하면 여러 개의 라이터로부터의 스토리지를 일관성있게 관리하는 어플리케이션의 가용성을 간단히 높일 수 있다. 붙여진 각 인스턴에는 공유 볼륨에 대해 완전한 읽기/쓰기 권한이 있다. 멀티 어태치를 사용하는 어플리케이션은 스토리지의 일관성을 위한 IO 울타리를 제공할 필요가 있다.

 

[SAML(Security Assertion Markup Language)]

● 인터넷 상에 ID나 패스워드 등의 인증 정보를 연동하기 위한 XML 베이스의 사양이다. SAML은 주로 기업 어플리케이션간의 인증에 사용된다. SAML은 Microsoft Active Directory를 사용하고 있으므로, AWS 클라우드로의 API 액세스용으로 SAML베이스의 Federation을 설정할 수 있다. AWS Single Sign-On등의 서비스를 이용하는 것으로, SAML에 의한 인증의 구조를 실현할 수 있다. AWS SSO는 SAML IdP 기능을 AWS Managed Microsoft AD 혹은 AWS SSO 디렉토리에 추가한다. 이러한 방식으로 유저는 AWS 매니지먼트 콘솔 이나 서브파티형 어플리케이션등, SAML을 서포트하는 서비스로의 SSO가 가능하다.

● SAML 페더레이션

IdP를 사용하기 위해서는 IAM의 ID 프로아비더 엔티티를 생성하고, AWS 꼐정과 IdP 간에 신례관계를 확립해야한다. IAM은 OpenID Connect 혹은 SAML 2.0와 호환성이 있는 IdP를 서포트하고 있다. 따라서 SAML 퍼더레이션을 사용해도 일반적인 AWS 보안인증정보를 생성하고, AWS 리소스로의 접근이 가능하도록 할 수있다. 

※ OpenID Connect를 이용하는 경우는 웹 ID 퍼더레이션을 사용한다. 

 

[CloudWatch]

● 데이터베이스 인스턴스의 CPU 사용율을 감시할 수 있지만, 기본으로는 RDS 인스턴스의 각 데이터베이스 프로세스로 인해 소비되는 CPU대역폭과 합계 메모리의 비율을 제공하지 않는다.

● CloudWatch 에이전트는 Amazon EC2 인스턴스와 온프리미스 서버로부터 매트릭스와 로그를 수집하는 기능이다. 

● CloudWatch로그

※ CloudWatch로그에는 어플리케이션의 로그 정보는 취득하고 있지 않다. 

 

[AWS Data Pipeline]

데이터의 이동과 변환을 자동화해주는 서비스이다. AWS Data Pipeline은 데이터 구동형의 워크 플로우를 정의하여, 업무의 정상적 완료를 트리거로 하여 다음 업무를 실행하도록 할 수 있다. AWS Data Pipeline은 DynamoDB에서 이용하는 것도 가능하므로 정기적으로 데이터 취득 업무를 설정할 수도 있다.

 

[AWS Cost Exploerer]

이용하고 있는 Amazon EC2인스턴스 등의 리소스를 최적으로 이용할 수 있는 추천항목을 파악할 수 있다. 이 기능을 통해 계정이나 리전의 상태나 사용되고 있지 않은 인스턴스를 특정하는 것이 가능하다. 추천 항목을 작성하기 위해서는 AWS에서 과거의 EC2 인스턴스의 사용 상황, Amazon CloudWatch 매트릭스, 과거의 예약 이력을 분석하여 비용을 절감할 수 있는 가능성이 있는지를 판단한다.

 

[AWS Budgets]

고객의 예산을 설정하여 비용 혹은 사용률이 예산안이나 예산량을 초과하였을 때 알람을 발신할 수 있는 기능이 준비되어 있다. 이것은 AWS의 이용 비용을 실시간으로 파악하기 위한 모니터링용이다.

※ 비용 최적화를 위한 가시화나 어드바이스를 얻을 수는 없다.

 

[ELB]

● Connection Draining

기존의 접속을 열어둔채 등록 해제 혹은 이상이 있는 인스턴에의 CLB의 리퀘스트 송신을 정지하는 것이 가능하다. 이 기능을 통해 로드 밸런서는 등록해체 혹은 이상이 있는 인스턴스에 대해 실행되고 있는 리퀘스트를 완료하는 트래픽 처리를 실시한다. 

로드 밸런서의 Connection Draining을 유효화하여 인스턴스의 등록해제를 보고하기 전에 로드밸런서가 접속을 유지하는 최대 시간을 지정할 수 있다. 최대 타임 아웃값은 1~3600초 사이로 지정할 수 있다(기본 설정으로는 300초). 최대시간제한에 도달하면 로드밸런서는 등록 해제한 인스턴스로의 접속을 강제적으로 종료한다.

● SSL Termination

SSL Termination이란 ELB에 SSL Termination를 설정하여 모드 밸런서 쪽에 SSL 인증을 실행하도록 하는 기능이다.

● ALB에서는 표준으로 WebSocket 프로토콜 기능에 대응하고 있으므로, HTTP/HTTPS 리스터에서 받은 HTTP/1.1부터 Upgrade로 WebSocket 통신을 개시할 수 있다.

NLB, CLB의 경우,이러한 대응을 하고 있지 않으므로, TCP 리스너를 통유하여 백엔드로 WebSocket의 기능에 대응하도록 실현할 필요가 있다.

● 스티키 세션(Sticky Session)

스티키 세션을 설정하여 ELB가 서버에 리퀘스트를 배분할 때에 Cookie를 확인하여 특정 클라이언트로부터의 리퀘스트를 어느 한 특정 서버에 연속적으로 할당하도록 할 수 있다.

● 프록시 프로토콜

프록시 프로토콜은 ELB를 통해 통신을 하고 있어도 AWS리소스쪽의 IP주소를 확인한다.

● 크로스 존 로드 밸런서

AZ간의 분산을 균등이 실현할 수 있다.

 

[AWS Snowball]

Snowball은 세큐리티를 고려하여 설계된 디바이스를 사용하여 페타바이트 규모의 데이터전송을 가능하게 한다. 이 디바이스를 이용하여 AWS 클라우드 내외의 대용량 데이터를 전송할 수 있다. Snowball을 사용하면 노은 네트워크 비용, 장시간이 걸리는 전송, 그 외 세큐리티에 관련해서 염려되었던 대규모 데이터 전송에 관련된 일반적인 문제를 해결할 수 있다. 데이터를 간단, 신속, 안전히 전송할 수 있어 고속 인터넷에 의한 데이터 전송과 비교하여 비용이 약 5분의 1정도 절약할 수 있다.

● AWS Snowball Edge

통합된 스토리지와 컴퓨팅 기능을 갖춘 100TB의 데이터 전송 디바이스이다. 물리적인 데이터 이동시에 사용한다.

● Snowball Edge Compute Optimized

기계학습, 풀 모션 영상 분석, 분석, 로컬 컴퓨팅 스택등에 관련된 강력한 컴퓨팅 리소스를 제공한다. 이 디바이스는 S3 호환 오브젝트 스토리지 혹은 EBS 호환 블록 볼륨용으로 42TB의 사용가능한 HDD 용량을 제공한다.

● Snowball Edge Storage Optimized

대규모 데이터 이동과 정기적인 전송 워크 플로우, 및 더욱이 높은 용량을 필요로 하는 로컬 컴퓨팅에 적용하고 있다. Snowball Edge Storage Optimized는 블록 볼륨과 Amazon S3 호환 오브젝트 스토리지에 최대 100TB의 HDD 용량을 제공하지만 이용 가능한 볼륨은 80TB정도이다. 따라서 90TB의 데이터를 이동시키기 위해서는 2개가 필요하다. 

● AWS Snowmobile

초대용량의 데이터를 AWS에 이동시키기 위해 사용할 수 있는 엑사바이트 규모의 데이터 전송 서비스이다. 이것은 세미 트랜잭션이 이끄는 14m의 괜찮은 운송 컨테이너로 Snowmobile 1대에 약 100PB까지 전송할 수 있다. 엑사바이트 사이즈의 데이터를 이동할 때에 이동한다. Snowmobile을 사용하면 비디오 라이브러리나 이미지 리퍼지터리 혹은 데이터 센터 전체까지 거대한 양의 데이터를 간단히 클라우드에 이동시킬 수 있다.

AWS Snowball	AWS Snowball Edge	AWS Snowmobile
안전한 디바이스를 사용하여 AWS 클라우드의 내외에 대량의 데이터를 전송하는 페타 바이트 규모의 데이터 전송 서비스이나 현재는 SnowBoll Edge를 사용하는 것을 추천한다.	데이터 이동과 엣지 컴퓨팅의 디바이스. 통합된 스토리지와 컴퓨팅 기능을 갖춘 100TB의 데이터 전송 디바이스이다. 주로 페타바이트 규모의 데이터의 이동에 사용한다. ※ 엑사 바이트 규모의 운송에는 역부족이다.	초대규모 데이터를 AWS에 이동하기 위해 사용할 수 있는 엑사 바이트 규모의 데이터 전송 서비스

 

[API Gateway]

● API Gateway는 완전 관리형 서비스로 API의 작성, 배부, 보존, 감시, 보호가 가능한 서비스이다. AWS Lambda로 실행되는 코드부터 데이터, 비즈니스 로직, 기능에 액세스하기 위한 일종의 "현관"으로써 기능하는 REST API 및 WebSocket API를 생성할 수 있다. HTML에 직접 작성해서 코드를 호출하는 것도 가능하다.

● API Gateway는 Lambda와 연계하여 서버리스 아키텍처를 구축할 때에 빈번히 이용된다.

※ API Gateway는 아예 언어를 사용하지 않고 워크 플로우에 의해 실행되도록 할 수 없다. Lambda함수등에 의한 코딩 처리와 통합할 필요가 있다.

● API Gateway는 트래픽 관리, 인가와 액세스 컨트롤, 모니터링, API 버전 관리 등, 최대 수백만 규모의 동기 API 콜 처리가 가능하다. API Gateway에는 최저 요금이나 초기 비용은 딱히 필요하지 않으며, 송신한 API 콜와 전송 데이터량에 대해 과금이 발생한다.

● API를 통해  HTTP에서 백엔드 서비스로의 접근을 제공한다. API 게이트웨이는 Lamdba와 함께 사용할 수 있느느 서비스로, API 게이트웨이를 Lambda함수와 통합하는 설정을 하는 것으로 HTTP로부터 Lamdba함수에의 접근을 가능하도록 한다.

● API Gateway에서는 응답 캐시기능이 있어 실행 결과를 캐시하는 것이 가능하다. 응답 캐시기능을 이용해 퍼포먼스를 향상시킬 수 있다.

● 기존의 API코드를 변환하여 Lambda 함수와 API Gateway를 사용한 서버리스 어플리케이션에 전환하는 것이 가능하다. Lambda는 인프라 스트럭처에 요금을 지불하지 않고, Lambda함수의 실행 시간에만 요금을 지불하기 때문에 비용을 절약할 수 있다. AWS Lambda함수를 API Gateway와 통합하는 것으로 간단히 API를 생성·관리하는 것이 가능하다. 

API Gateway를 이용하는 것으로 AWS Lambda함수를 HTTPS 경우로 호출하는 것이 가능하다. 그러기 위해서는 Amazon API Gateway를 사용하여 커스텀 REST API와 엔드 포인트를 정의하여 특정 Lamdba함수에 매빙한다.

 

[AWS Step Functions]

● AWS Step Functions는 AWS 의 여러 개의 서비스를 서버리스 워크 플로우에 정리하고 프로세스 처리를 실행하는 어플리케이션을 구축할 수 있다. 워크 플로우는 일련의 스텝으로 구성되어, 어떤 한 스텝의 출력이 다음 스텝으로의 입력이 된다. Step Funtions는 각 스텝이 자동적으로 트리거 및 추적되므로 에러가 발생한 경우는 재실행된다. 따라서 어플리케이션을 의도한 순서대로 실행시킬 수 있다.

● 여러 개의 서비스를 이용하여 서버리스 워크 플로우로 구성한다. 이것은 워크플로우의 실행, 관리에 이용된다.

● Step Functions 버서리스의 오케레이션 서비스

AWS 리소스와 조합한 워크 플로우를 작성하는 서비스이다. 인간에 의한 조작을 필요로 하도록 장시간 실행되는 반자동화된 워크 플로우를 작성할 수 있다. 따라서 이 워크 플로우에 수동 액션을 필요로 하는 몇 개의 작업이 존재할 가능성이 있으며 수동 액션이 처리되지 않으면 작업이 중지된다.

● Step Functions의 표준 워크 플로우는 한 번의 워크 플로우 실행으로 최장 1년간 실행할 수 있다.

● Step Functions는 액티비티 정의가 아닌, 액티비티 상태 머신에 의한 액티비티의 실행 스케줄 등을 설정할 수 있다.  

● 디폴트는 Step Functions 를 재실행한다는 대응은 존재하지 않는다.

 

[웹 ID 퍼더레이션]

웹 ID 퍼더레이션을 사용하는 것으로 커스텀의 사인인 코드를 작성하거라 독자적인 유저 ID를 관리할 필요가 없어진다. 그 대신에 어플리케이션의 유저는 Google 등의 외부 ID 프로바이더를 사용하여 사인인할 수 있다. 인증 토큰을 받으면 그 토큰을 AWS 계정의 리소스를 사용하기 위한 액세스 허가를 가진 IAM 롤에 맵핑해, AWS의 일시적인 세큐리티 인증 정보로 변환하는 것이 가능하다. IdP를 사용하면, 어플리케이션에서 장기적으로 보안인증정보를 가지고 배포할 필요가 없어서, AWS 계정의 안전성의 유지에 도움이 된다.

 

[크로스 어카운트 액세스]

AWS 어카운트의 리소스로의 액세스 허가를 설정하는 방법

 

[IAM]

● SCP와 IAM의 적용 범위와 관계성에 대해서 이해할 필요가 있다. IAM 유저의 권한이 SCP와 IAM의 양쪽에 허용되어 있으면 IAM유저는 권한이 부여된 대상 리소스의 실행이 가능해진다. 즉 2개의 정책에 의해 "명시적으로 허가되고" 또한 "명시적으로 거부되지 않은" 권한이 부여된 경우에만 IAM 유저나 IAM 롤은 그 리소스에 대해 조작이 허용된다.

● AD Connector (AWS Directory Service AC Connector)

Active Directory를 활용하기 위해서는 이 AD Connector을 사용한다.  AD Connector은 IAM와 온프레미스 환경의 AD와 연계하기 위해 사용한다. AD Connector은 IAM쪽의 디렉토리, 리퀘스트를 온프레미스의 Microsoft Active Directory로 그리고 리다이렉트하기 위해 사용하는 디렉터리 게이트웨이이다. 이 기능을 통해 사내의 Active Directory와 IAM를 연계하는 것이 가능하다.

AWS Directory Service로의 액세스에는 AWS에 의해 사용되는 인증정보가 필요하다. 그리고 이러한 인증정보에는 AWS 리소스에 대해 액세스 허가가 필요하다. IAM와 AWS Directory Service를 사용하여 AWS 리소스에 액세스할 수 있는 유저를 제어할 수 있다. AD Connector은 AWS으로의 롤 베이스의 액세스 허가를 바탕으로 AWS 리소스로의 액세스를 실행한다.

이때 기존의 IAM롤을 AWS Directory Service유저 혹은 그룹에 할당하는 것이 가능하다. AWS Directory Service AD Connector를 통해 VPC와 통합하면, Active Directory로부터 유저 혹은 그룹에 IAM롤을 할당하여 ID 퍼더레이션 및 롤 베이스의 액세스 에어를 가능하게 한다.

※ Simple AD

Samba 4 Active Directory Compatible Server를 사용하는 스탠드 얼론의 매니지드형 디렉토리이다. 이것을 사용하여 AWS상에 신규 Active Directory를 구성하는 것이 가능하다. 이것은 연계용이아니다.

● IAM 정책 타입

1) AWS 관리 정책

AWS를 작성 및 관리하기 위한 스탠드 얼론 정책이다. 스탠드 얼론 정책이란 정책명을 포함한 독자적인 Amazon 리소스 네임(ARN)을 붙인 정책이다. AWS 관리자 정책은 일반적인 적용 사례로 액세스 허가를 제공할 수 있도록 설계되어 있어 관리자 권한 정책을 부여한 IAM유저가 IAM 관리 권한을 사용하도록 할 수 있다. 보통 AWS 관리 정책이 기존에 있는 경우에 IAM 정책을 설정할 때, AWS 관리자 정책을 사용하도록 장려하고 있다. 관리자  정책은 AWS 관리 정책으로써 준비되어있기 대문에 이것을 사용하는 것을 우선으로 한다.

2) 인라인 정책

1개의 principal 엔티티(유저, 그룹 혹은 역할)에 포함된 정책이다. 이것은 principal 엔티티 고유의 것으로 principal 엔티티를 생성할 때 혹은 그 이후에 정책을 만들어 principal 엔티티에 적용되도록 할 수 있다. 보통, 인라인 정책이 아닌 관리자 정책을 사용하는 것을 추전하고 있다.

※ IAM 인라인 정책은 유저 관리에 적합하지 않다.

3) 커스텀 관리 정책

커스텀 관리 정책은 유저의 AWS 계정에서 관리할 수 있는 스탠드 얼론 정책이다. 커스텀 관리 정책을 이용해 관리자 권환을 부여하도록 할 수는 있지만, 관리자 권환 정책은 AWS 관리 정책으로써 이미 존재하기 때문에 AWS 관리 정책을 사용하는 것이 옳다.

4) 서드파티의 정책

● IAM Access Analyzer

IAM Access Analyzer는 외부 엔티티와 공유되고 있는 Amazon S3 버켓이나 IAM 역할 등, 조직와 계정의 리소스를 식별한다. 이것은 외부의 제 3자로의 주적절한 액세스 정책이 부여되어 있는 등을 발견하는 것이 가능하다. 또한 IAmazon EventBridge에 의한 AWS IAM Access Analyzer의 모니터링을 실시하면, 각 결과의 생성시에 기존의 결과의 상태를 변경시, 및 결과의 삭제시에 EventBridge 이벤트를 송신한다.

IAM Access Analyzer는 AWS계정의 외부로부터 액세스할 수 있는 리소스를 특정하는 종합적인 분석을 실행한다. 이 분석을 통해 S3의 외부 계정으로부터의 액세스 정보를 분석하고 부정한 계정의 액세스가 있는지를 확인한다.

 

[AWS Certificate Manager(ACM)]

● SSL증명서를 집중관리하기 위한 AWS 서비스이다. ACM은 AWS 서비스와 유저의 내부 접속 리소스로 사용하는 퍼블릭 혹은 프라이베이트의 SSL/TLS 증명서를 작성, 등록, 관리하는 것이 가능하다. SSL/TLS 증명서를 설정하면 SSL인증이 이용된 HTTPS통신에 의해  네트워크 통신이 보호된다. AWS Certificate Manager을 사용하면 SSL/TLS 증명서의 구입, 업로드, 갱신이라는 시간이 걸리는 프로세스를 수동으로 수행할 필요가 없어진다.

※ ACM에서 지원하지 않는 리전에서는 HTTPS 접속 지원을 필요로 할 경우 IAM를 SSL증명서 매지저로써 사용한다. IAM은 모든 리전에 SSL증명서의 디플로이를 지원하고 있지만, AWS에 사용하기에는 외부 프로바이더로부터 SSL 증명서를 취득할 필요가 있다. 

 

[AWS Database Migration Service]

AWS Database Migration Service를 사용하면 온프레미스에 있어 데이터 베이스를 단기간에 안전히 AWS에 이동시킬 수 있다.

 

[AWS Server Migration Service]

온프레미스의 VMware vSphere, Microsoft Hyper-V/SCVMM, 혹은 Azure 가상 머신의 AWS에 이동시키는 툴이다.

 

[Amazon SWF(Amazon Simple Workflow)]

● Amazon SWF도 AWS Step Functions과 동일하게 워크 플로 등의 프로세스를 생성하는 것이 가능하다. 다만 EC2 인스턴스를 이용한 서버 베이스의 기능이므로 서버리스 오케스트레이션은 제공하고 있지 않다.

● 스텝 혹은 연속된 스텝이 있는 백그라운드 작업을 구축, 실행, 스케줄하는 것이 가능한 클라우드 내의 완전 매니지드형의 상태 트랙커 혹은 워크 플로우 시스템이다.

● 클라우드의 워크 플로우 관리 어플리케이션에 여러 개의 머신간에 어플리케이션을 연속시키기 위핸 툴을 개발자에게 제공하고 있다.

 

[Amazon MQ]

Amazon MQ는 Apache ActiveMQ와 매치한 매니지드형의 메시지 브로커 서비스이다. 세계 표준에 의거한 메시징을 사용하고 있는 경우에 그 메시징 기능을 그대로 신속하게 AWS 클라우드에 이동하기 위해서는 이 서비스가 최적의 방법이다. 이것은 세계 표준의 API와 프로토콜을 지원하고 있으므로, 어플리케이션의 메시징 코드를 바꿀 필요없이, 표준 베이스의 메시지 브로커로부터 Amazon MQ로 전환하는 것이 가능하다.

 

[AWS IoT Core]

● AWS IoT Cores는 인터넷에 연결된 디바이스로부터 클라우드 어플리케이션이나 그 외의 디바이스에 간단하고 안전히 통신하기 위한 매니지드형 클라우드 서비스이다. AWS IoT Core를 이용하여 센서 디바이스를 이용한 차량관리 어플리케이션을 간단히 구축하는 것도 가능하다.

● AWS IoT Core는 수십억개의 디바이스와 수천 건의 메시지를 지원하고 있어 그러한 메시지를 AWS 엔드포인트나 다른 디바이스에 확실히 그리고 안전히 처리하여 라우팅한다. AWS IoT Core를 사용하면 어플리케이션이 인터넷에 연결되지않은 경우에도 모든 디바이스를 항상 추적하고 통신할 수 있다.

 

[Amazon EMR]

● Amazon EMR은 매니지드형의 Hadoop 프레임워크를 제공하고 있다. 따라서 Amazon EMR은 EC2인스턴스를 이용하여 구성되기 때문에 Amazon EMR을 구성하는 EC2인스턴스의 오퍼레이팅 시스템 등에  유저는 액세스 가능하게 된다.

● Amazon EMR을 사용하여 Amazon S3나 Amazon EynamoDB등의 다른 AWS 데이터 스토아 혹은 데이터베이스와 연계시켜 대용량의 데이터를 변환하거나 파싱하는 것이 가능하다. 따라서 S3에 있는 대용량의 로그 파일을 처리하여 분석하기에는 최적의 서비스이다. 

● Amazon EMR은 대규모 환경에서 대용량의 데이터를 빠르고 그리고 비용 효율이 좋게 처리할 수 있는 빅 데이터 처리용 플랫폼이다. Apache Spark, Apache Hive, Apache HBase, Apache Flink, Presto 등의 오픈 소스의 쉘과 Amazon EC2의 동적 스케일러빌리티 및 Amazon S3에의한 스케일 조정이 가능한 스토리지를 조합해 신축성이 있는 데이터 처리, 분석 엔진을 제공한다. 페타바이트 규모의 분석은 기존의 온프레미스 클러스터와 비교한다면 더 저렴한 비용으로 실행할 수 있다. 주된 사용 예는 다음과 같다.

▷ 머신러닝

▷ 추출, 변환, 읽어들이기(ETL)

▷ 리얼타임 스트리밍 데이터처리

▷ 인터랙티브 분석

▷ 유전체학

● Amazon EMR의 중심이 되는 요소는 클러스터이다. 클러스터는 EC2인스턴스의 컬렉션이다. 클러스터 내의 각 인스턴스는 노드라고 부른다. 각 노드는 클러스터 내에서 역할이 있어, 노드 타입이라고 부른다. Amazon EMR는 각 노드 타입에 다양한 소프트웨어 요소도 설치해서 ApcheHadoop등의 분산형 어플리케이션에서의 역할을 각 노드에 부여한다. 그리고 클러스트에 노드를 셋업할 때에는 EC2인스턴스의 온디맨드 인스턴스, 스팟 인스턴스, 혹은 리저브드 인스턴스를 이용할 수 있다.

Amazon EMR내의 스팟 인스턴스는 온디맨드의 구입과 비교해서 낮은 비용으로 Amazon EC2 인스턴스 용량을 구입할 수 있는 옵션을 제공한다. Amazon EMR의 클러스터에 대해서 스팟 인스턴스를 이용하면 온디맨드와 비교해서 비용을 절약할 수 있다. 이 EMR의 처리는 단시간에 빈번히 발생하지만, 클러스터 구성 자체는 일시적으로 이용하는 것이 된다. 

 

[AWS 책임 공유모델]

AWS쪽의 보안 책임	유저쪽의 보안 책임
- 설비 - 하드웨어의 물리적 보안 - 네트워크 인프라 - 가상화 인프라구조	- Amazon Machine Images(AMI) - OS - 어플리케이션 - 전송중의 데이터 - 보관시의 데이터 - 데이터 스토어 - 자격 정보 - 정책와 설정

 

[AWS Date Pipeline]

AWS Date Pipeline은 주로 클라우드 베이스의 데이터 워크 플로우 서비스로써 이용된다. 다른 AWS 서비스와 온프레미스 데이터 소스간에 데이터를 처리 및 이동시키기 위해 사용된다.

 

[분산 아키텍처 구성]

AWS와 온프레미스 환경 양쪽 모두 적용가능한 AWS서비스로 구성해야한다. 참고로 분산 아키텍처는 콤포넌트 혹은 레이어를 상호 연결하면서 독립하여 실행할 수 있는 컴퓨팅 구조의 일종이다.   AWS 서비스중에 SQS 및 AWS Step Functions은 AWS에서 분산 아키텍처를 구성하기 위해 사용할 수 있는 서비스이다.

Amazon SQS는 어플리케이션간에 혹은 마이크로 서비스 간에 메시지를 통신할 수 있는 신뢰성이 높으며 스케일 변경 가능한 높은 호스트형의 큐를 제공한다. Amazon SQS를 사용하면 분산 어플리케이션 콤포넌트간에 데이터를 이동하거나 이러한 콤포넌트를 분리할 수 있다.

AWS Step Functions는 분산 어플리케이션 콤퍼넌트간에서 작업의 조정을 간단히하는 웹 서비스이다.

※ API Gateway를 이용하여 온프레미스 서버와 EC2인스턴스에 적용할 수 있는 워크 프로세스를 만들 수 없다. 

 

[AWS X-RAY]

● 유저가 Amazon API로부터의 API리퀘스트를 통해 서비스를 호출한 경우에 AWS X-RAY를 사용한 유저 리퀘스트를 추적 및 분석할 수 있다. API Gateway는 모든 API Gatewat 엔드 포인트 타입(지역, 엣지 최적화, 프라이빗)의 AWS X-Ray 트레이스를 지원하고 있다. 그러므로, X-Ray가 이용가능한 모든 리전에 있어서 Amazon API Gateway에 AWS X-Ray를 사용하여 트레이스 데이터를 수집하는 것도 가능하다. 

● X-RAY SDK for Java

어플리케이션 로그 정보는 X-ray를 에이전트로써 통합 활성화함으로써 취득할 수 있다. X-RAY SDK for Java를 이용해서 수집된 X-RAY 세그먼테이션으로부터 샘플링되어 있지 않은 Amazon CloudWatch 매트릭스를 발행할 수 있다.

● AWS X-RAY는 AWS CloudTrail과 통합하여 유저, 역할 혹은 AWS 서비스에 의한 X-Ray로 실시된 API 액션을 기록할 수 있다. 

 

[AWS Organizations]

● 여러 개의 AWS 계정에 대해 정책을 설정하여 액세스 권한을 관리할 수 있다. AWS Organizations에서는 여러 개의 계정을 모아 그룹을 만들고, 계정 작성을 자동화하여 그러한 그룹에 서비스 컨트롤 정책(SCP)를 적용하는 것도 가능하다.

AWS Organizations를 이용하는 것으로 커스터마이즈 리프트나 수동 프로세스를 필요로 하지 않고 여러 개의 어카운트에 걸쳐 정책을 집중 관리할 수 있다. 또한 이 기능을 통해 여러 개의 AWS 계정에 걸쳐 AWS 서비스의 사용을 일원적으로 제어하는 서비스 컨트롤 정책(SCP)를 만드는 것도 가능하다.

● FullAWSAccess 설정

AWS 어카운트에 기본 설정으로 "FullAWSAccess"가 부여되어 있는 경우에 어떻게 허가형식의 SCP가 기능하는가에 대해서 설명하고자 한다. 기본으로 "FullAWSAccess"가 부여되어 있는 경우는 모든 리소스에 대해 모든 조작이 명시적으로 허가되어 있다는 의미있다. 이것에  화이트리스트형식(특정의 조작의 허가를 부여할 수 있는 정책)으로 특정 리소스에 대해서 허가를 부여해도, "FullAWSAccess"가 부여되어 있으므로 결국 모든 리소스에 대한 허가가 상태가 이어진다.

특정 권한 범위를 부여한 SCP를 신규 설정하고 싶은 경우에 그 SCP를 붙인 뒤, "FullAWSAccess"를 떨어트리면 된다.

 

[AWS Systems Manager]

AWS Systems Manager은 AWS 리소스의 운영관리에 이용하는 통합 관리 툴이다.

※ 유저 관리와 상관없다.

 

[AWS Batch]

주로 AWS에서 수십만의 배치 컴퓨팅 작업 등을 효율적으로 시용되기 위해 이용한다.

 

[ARN(Amazon 리소스 네임)]

AWS 리소스를 고유하게 식별한다. IAM 정책, Amazon Relational Database Service(Amazon RDS) 태그, API 콜 등, AWS 전체에 리소스를 명확히 지정할 필요가 있는 경우가 ARN이 필요하다. ARN은 아래와 같은 형식으로 정의된다.

arn:partition:service:region:account-id:resource-id

 

[Resource ID]

리소스가 만들어지면 각 리소스에 고유한 리소스 ID가 할당된다. 리소스 ID를 사용하여 Amzon EC2콘솔에서 리로스를 쉽게 찾을 수 있다. 커맨드 라인 툴 혹은 Amazon EC2 API를 사용하여 Amazon EC2를 조작하고 있는 경우, 특정 커맨드에는 리소스 ID가 필요하다. 리소스 ID는 리소스네임의 일부를 구성하고 있는 식별자이지만, API를 호출하는 등의 모든 AWS 리소스를 명확히 지정하는 경우는 ARN을 사용하는 편이 좋다.

 

[AWS Tags]

● AWS 리소스를 목적, 소유자, 환경 등 다양한 방법으로 분류하는 것이 가능하다. 동일한 리소스 형태가 많은 경우에 도움이 된다. 리소스에 대해 고유로 설정하는 것은 아니다.

● AWS 리소스의 태그 사용의 좋은 예는 다음과 같다.

▷ 태그에는 보통 표준화된 대문자와 소문자를 구분하는 형식을 사용하고 모든 리소스 타입에 있어서 일관되게 이용한다.

▷ 리소스 액세스 제어, 비용 추적, 자동화, 및 구조의 관리 기능을 지원하기 위한 태그 디맨션을 검토한다. 

▷ 리소스 태그의 관리에 도움이 되는 자동화 툴을 구현한다. Resource Groups Tagging API는 프로그램에 의한 태그의 제어를 실시하고 태그와 리소스의 자동관리, 검색, 필터링이 간단하게 된다.

▷ AWS 리전마다 1개의 API 콜을 사용하여 지원되고 있는 모든 서비스의 태그 데이터에 대한 백업을 간략화한다.

▷ 태그를 너무 많이 사용하면 좋지 않다.

▷ 비지니스 요건의 변화 대응하기 위해 태그를 변경할 때는, 태그 베이스의 액세스 제어, 자동화, 혹은 업스트림 청구 레포트에 관련된 영향을 고려해야한다.

 

[AWS Config]

AWS 리소스의 설정을 평가, 감시, 감찰할 수 있는 서비스이다. Config에서는 AWS 리소스의 설정이 지속적으로 모니터링 혹은 기록되어 원하는 설정에 대해 기록되어 있는 설정의 평가를 자동화할 수 있다.

 

[AWS Shiled]

매니지드형의 DDoS공격에 대응하는 보호 서비스로, AWS에서 실행하고 있는 어플리케이션을 보호한다. 직접적으로 DDoS공격을 회피하기 위해서는 WAF가 아닌 AWS Shiled를 설정하는 것이 우선되어야한다.

 

[리저브드 구입 옵션이 존재하는 서비스]

AWS 서비스 중에 1년 ~3년사이에 일정 기간 이용을 예약하는 것을 전제로 할인된 가격으로 구입 가능한 옵션이 리저브드이다. 리저브드 구입 옵션이 있는 서비스는 다음과 같다.

● EC2 리저브드 인스턴스

● RDS 리저브드 인스턴스

● ElastiCache 리저브드 노드

● DynamoDB 리저브드 캐파시티(Capacity)

● Redshift 리저브 노드

※ EFS 와 S3는 리저브드 구입 옵션이 없다.

 

[AWS Application Discovery Service]

● AWS Application Discovery Service는 온프레미스 서버의 인벤토리와 동작을 검출하기 위해 사용된다. 이 서비스는 AWS로의 전환 계획을 작성할 때에 사용되는 것으로 워크플로우의 전환과 는 관계가 없다.

● AWS Application Discovery Service는 온프레미스 데이터 센터 내의 서버에 에이전트를 인스톨하는 것으로 데이터 센터의 이용 정보를 수집할 수 있는 서비스이다. 이것은 정보를 바탕으로 유저의 전환 프로젝트 계확 작성을 지원한다. 

데이터센터의 전환 계획에는 수 천개의 워크 플로우가 존재하고 많은 경우 그것들이 서로 깊게 의존하고 있다. 서버의 사용률 데이터나 의존 관계의 맵핑은 전환 프로젝트 초기에서 매우 중요한 스텝이다. AWS Application Discovery Service는 서버의 설정 데이터, 사용 상황 데이터, 동작 데이터 등의 수집이 가능하다. 수집된 데이터는 AWS Applicaton Discovery Service의 데이터 스토어에 암호화 혐식으로 보존된다. 이 데이터를 CSV 파일으로써 export하고, AWS에 가동했던 경우의 총 소유비용(TCO)의 견적이나 AWS에의 이동계획에 사용할 수 있다. 검출한 서버를 AWS에 이동하고, AWS에 이동할 때의 진척상황을 추적할 수 있다.

※ AWS System Discovery Service이라는 서비스는 존재하지 않는다.

 

[Amazon Lex]

음성이나 텍스트를 사용하여 임의의 어플리케이션에 대화형 인터페이스를 구축하는 서비스이다. Amazon Lex 는 음성의 텍스트 변환에는 자동 음성 인식(ASR), 텍스트의 의도 인식에는 자연어 이해(NLU)이라는 고도의 심층 학습 기능을 사용할 수 있다. 리얼한 대화를 실현하는 어플리케이션 개발에 용이하다.

 

[Amazon Polly]

Amazon Polly는 문장을 리얼한 음성으로 변화하는 서비스이다. 

 

[Amazon SageMaker]

Amazon SageMaker 은 모든 개발자와 데이터 사이언티스트에게 기계학습 모델을 신속하게 구축, 트레이닝, 디플로이할 수 있는 방법을 제공한다. Amazon SageMaker는 풀 매니지드 서비스로 기계 학습 워크플로우 전체에 대응하고 있다.

 

[Amazon Rekognition]

Amazon Rekognition에서는 이미지 분석과 영상 분석을 어플리케이션에 간단히 추가할 수 있다. Rekognition API에 이미지 혹은 영상을 전달하는 것뿐만으로 이 서비스는 대상물, 인간, 텍스트, 장면, 액티비티에 관련된 부적합한 컨텐츠까지 검출한다.

 

[AWS Managed Microsoft AD]

● AWS Managed Microsoft AD (AWS Directory Service for Microsoft Active Directory)를 이용해서 AWS 클라우드 내에 매지니드 형 Active Directory를 설치할 수 있다. 이것을 이용해서 AWS와 기존의 온프레미스 Microsoft Active Directory간에 신뢰관계를 설정하고 싱글 사인 온(SSO)을 구성하는 것도 가능하다.

● AD Connector을 사용하여 기존의 온프레미스의 Micorosoft Directory와 연계하여 SSO를 실현할 수 있다. AD와 롤에 할당된 IAM 정책을 바탕으로 유저의 AWS 서비스로의 액세스를 제어한다.

 

[AWS Directory Service]

AWS Directory Service는 Amazon Cloud Directory 및 Microsoft Active Directory(AD)를 다른 AWS 서비스와 병용하기 위한 여러 개의 방법을 제공한다.

 

[AWS 암호화 SDK]

언어 고유의 SDK이란 다른 암호화 전용 라이브러리이다. 이 암호화 라이브러리를 사용하여 개발중인 어플리케이션에 대해서 암호화의 좋은 예에 의한 암호화의 구조를 간단히 구현할 수 있다. AWS 암호화 SDK를 이용하는 것으로 암호화의 제약을 초과하지 않도록 리퀘스트 처리의 구조를 구성하여 수정하는 것으로 현재의 에러를 피할 수 있다.

※ IAM 암호화 API 콜, AWS KMS SDK라는 쉘 키트와 존재하지 않는다.

 

[Amazon QuickSight]

Amazon QuickSight는 클라우드형의 BI툴을 제공하는 가시화 툴이다. Amazon QuickSight 는 ML Insights를 포함한 인터랙티브한 대시보드를 간단히 생성하여 공개할 수 있다. 대시보드는 어떠한 디바이스로부터 액세스 가능하며, 어플리케이션, 포탈, 웹 사이트에 전개할 수 있다.

Amazon QuickSight 는 기계학습(ML)와 자연언어기능을 활용하여 데이터를 이용해 깊은 통찰을 얻는데에 도움이 되는 ML Insights 기능이 존재한다. 이 기능은 바로 사용할 수 있는 강력한 기능으로 누구라도 숨겨진 경향과 예외 값을 발견하고 중요한 비즈니스 드라이버를 특정할 수 있으며 기술적인 전문지식이나 ML의 경험이 없어도 강력한 what-if분석과 예측을 할 수 있다.

 

[Amazon WorkSpaces]

Amazon WorkSpaces는 매니지드형으로 안전한 가상 데스크톱 솔루션이다. Amazon WorkSpaces를 사용하면, Windows 혹은 Linux의 데스크톱을 몇 분안에 셋업할 수 있다. 이것을 이용해 빠르게 스케일함으로써 세계에 많은 종업원에 가상 데스크톱을 제공할 수 있다. 가상 데스크톱을 제공함으로써 데이터나 데스크 업 구성을 랩톱에 저장하지 않고 집중관리할 수 있다. 이러한 기능을 통해 개인 PC 분실 등에 의한 데이터 누출을 방지할 수 있다. 

 

[Amazon CloudSearch]

CloudSearch는 AWS 클라우드에 있어서 매니지드형 서비스로써 웹 사이트 혹은 어플리케이션용의 검색 솔루션을 간단히 그리고 비용대비 효율이 좋게 설정, 관리 스케일할 수 있는 서비스이다.