[AWS] 고성능 아키텍처

핵심 AWS 서비스의 성능 최적화

컴퓨트

컴퓨트 서비스의 목적은 워크로드 수요에 맞춰 신속하고 효율적으로 컴퓨트 리소스를 제공하는 것이다.

EC2 인스턴스 타입

ec2 인스턴스 파라미터 명세표

• ECUs: EC2 컴퓨트 유닛, 인스턴스 타입 간 컴퓨트 성능 비교에 유용
• vCPUs: 인스턴스에 할당된 가상 CPUs 수
• Physical Processor: 호스트 서버가 사용하는 프로세서 패밀리(예: Intel Xeon E52676v3)
• Clock Speed: 호스트 서버가 사용하는 클럭 스피드
• Memory: 인스턴스에 할당된 메모리 양
• Instance Storage: 로컬 인스턴스 스토어 볼륨의 크기
• EBS-Optimized Avaliable: 전용 I/O 처리용량에 최적화된 EBS 사용 여부
• Network Performance: 인스턴스의 데이터 전송 속도
• IPv6 Support: IPv6주소 지원 여부
• Processor Architecture: 하드웨어 서버의 32비트 또는 64비트 프로세서 사용 여부
• Intel AES-NI: 하드웨어 호스트의 Advanced Encryption
• Standard-New Instructions(AES-NI): P3,P2,G3,F1
• Intel AVX: 하드웨어 호스트의 그래픽 및 분석 성능 향상을 위한 부동소수점 지시 세트 사용 여부
• Intel Turbo: 하드웨어 호스트의 단기 성능 부스팅 기능 사용 여부

Auto Scaling

하나의 EC2 인스턴스로 워크로드를 처리할 수 없을 때 스케일 아웃만 하면 된다. 스케일아웃, 수평적 스케일링은 애플리케이션 수요에 맞춰 리소스를 추가하는 방식이다.

Auto Scaling은 변화하는 요구 수준에 맞춰 인스턴스를 자동으로 추가, 삭제할 수 있는 도구이다.

서버리스 워크로드

EC2 인스턴스를 사용하지 않고도 Docker와 같은 컨테이너, Lambda등의 서버리스 함수는 거의 즉각적으로 컴퓨트 리소스를 사용할 수 있게 해준다.

ECS와 같은 컨테이너 관리 서비스와 프론트엔드 추상화 서비스인 AWS Fargate는 리소스 활성화율을 극대화하하고, 단일 인스턴스 환경에서도 워크로드 처리를 빠르게 할 수있게 해준다. EKS등 AWS 컨테이너 환경은 스크립트로도 접근이 가능하다.

Lambda는 지속적으로 실행되는 서버를 프로비저닝 할 필요가 없다. Lambda 함수는 네트워크 이벤트에 대응해 (최대 15분) 매우 짧은 시간 실행되며 다른 AWS 서비스와 쉽게 통합할 수 있으며, Amazon API Gateway를 이용해 API 요청 반식으로 워크로드 처리가 가능하다.

 

컴퓨트 서비스별 주요 활용 사례

EC2 인스턴스

• 복잡한 구성으로 장시간 실행되는 웹 어플리케이션
• 심층적인 모니터링 및 트래킹이 요구되는 업무 프로세스

ECS 컨테이너

• 고확장성의 자동화된 애플리케이션
• 리소스에 대한 완전한 통제권이 요구되는 애플리케이션
• 테스트 환경 구성

Lambda 함수

• 백엔드 데이터베이스에서 데이터 인출 작업
• 데이터 스트림 파싱 작업
• 트랜잭션 데이터 처리

스토리지

클라우드 스토리지 및 이를 사용하는 서비스의 성능 최적화 방법

RAID 최적화 RBS 볼륨

RAID(Redundant Array of Independent Disks) 기반의 디스크 관리 기술을 이용해 데이터 스토리지의 성능 및 안정성을 높일 수 있다. RAID는 다수의 드라이브 공간을 하나의 논리 드라이브에 통합하며 드라이브 내 전체 배열 구조에 데이터를 분산 또는 복제한다.

 

RAID 0

데이터 스트라이핑을 통해 데이터를 세분화하고 하나 이상의 디바이스에 저장해 단일 디스크의 접근 제약성을 동시다발적인 작업으로 극복한다.

 

RAID 1

다수의 볼륨에 데이터 복제본을 생성한다. 하나의 디스크가 실패하더라도 피해를 최소화해 안정성을높여준다.

 

RAID 5, RAID6

성능과 안정성 모두를 높이기 위한 옵션이지만 AWS는 IOPS 소모 문제 등의 이유로 사용을 권장하지 않는다.

S3 크로스 리전 복제

S3 Cross-Region Replication(CRR)은 하나의 리전에 있는 버킷 데이터를 자동으로, 비동기적으로 다른 버킷에 복제한다. 복제 규칙에는 복제된 콘텐츠가 전송될 대상 버킷이 명시되어 있어야 하며, 동일 계정의 다른 리전 내 버킷 또는 다른 계정의 버킷을 대상 버킷으로 설정 가능하다.

Amazon S3 Transfer Acceleration

로컬 PC에서 S3 버킷으로 대용량 파일을 자주 전송하는 경우 이 서비스를 이용해 전송 속도를 높일 수 있다. CloudFront 엣지 로케이션을 이용해 데이터를 전송하기에 빠른 전송속도를 체감할 수 있다.

CloudFront와 S3 Origins

S3 버킷을 원본으로 해 비디오 및 이미지 서비스 제공을 대표적으로 사용할 수 있으며, EC2 기반 애플리케이션에서 고객이 요청한 미디어 파일을 제공할 때 CloudFront를 가리키도록 해 병목 현상을 줄이고 별도의 로컬 호스팅 비용 또한 절감할 수 있다.

데이터베이스

직접 데이터베이스를 설치, 운영한다면 저렴한 비용으로 많은 제어 권한을 가질 수 있다. 반면 완전 관리형 서비스인 RDS를 이용하면 다양한 데이터베이스 관리들을 좀 더 쉽게 할 수 있고 기본 설정만 하면 된다.

• 적절한 RDS 인스턴스 타입 선택
• 스키마, 인덱스, 뷰 등 속성을 조절해 데이터베이스 최적화
• 필요에 따라, RDS 인스턴스에 적용할 수 있는 데이터베이스 기능 옵션 그룹 설정
• 필요에 따라, RDS 인스턴스에 적용할 수 있는 데이터베이스 기능 미세 제어용 파라미터 그룹 생성

EC2 인스턴스에 데이터베이스를 설치하면 아래의 다양한 제어 권한을 확보할 수 있게 된다.

일관성, 가용성, 파티션 내구성 : 데이터베이스 어드민은 데이터 변조를 막기 위해 이들 3대 요소 가운데 우선순위를 정해야한다. 한꺼번에 충족하기란 불가능하다.

지연성: 스토리지 볼륨은 IOPS 성능과 SSD 또는 HDD등 아키텍쳐에 따라 다양한 옵션이 존재하며 데이터베이스의 읽기, 쓰기 성능에 상당한 영향을 미친다.

내구성 : 하드어 실패 시 데이터를 보호할 수 있는 방법이다.

확장성: 데이터베이스가 리소스의 자동 확장을 지원하는 유무이다.

비-데이터베이스 호스팅: 데이터는 때로 AWS S3와 같은 비-데이터베이스 환경에서 호스팅 할수도 있다.

네트워크 최적화 및 로드 밸런싱

네트워크 연결 유무, 신속, 안정성이 클라우드 컴퓨팅 워크로드에 중요한 영향을 미친다. Route 53, CloudFront는 네트워킹 정책에 있어 중요한 요소이며, VPC 엔드포인트, AWS Direct Connect 또한 중요한 요소이다.

광대역 EC2 인스턴스 타입 또한 네트워크 성능에 큰 차이를 가져올 수 있으며, 강화 네트워킹 기능이 호환되는 인스턴스를 사용하면 데이터 전송 속도를 높일 수 있다.

중요한 네트워킹 성능 강화 기술에는 로드 밸런싱도 포함된다.

로드 밸런서는 인프라의 맨 앞에 위치해 고객의 콘텐츠에 대한 모든 요구를 분산, 처리해준다. Route 53과 같은 DNS 서버 또는 CloudFront를 사용한다면 이들 서비스는 특정 주소에 대한 요청을 개발 셔버가 아닌 로드 밸런서에 전달하는 역할을 한다.

로드 밸런서는 다양한 운영 업무를 자동화하며 확장성을 겸비한 서비스이므로 트래픽 패턴이 크게 바뀌더라도 이에 자동으로 대응한다.

초기에 만들어진 Classic 버전 EC2 로드 밸런서 타입도 HTTP, HTTPS, TCP워크로드를 처리할 수 있다. 현재 ELB는 두 가지 로드 밸런서 타입을 제공한다. Application Load Balancer(ALB)는 HTTP와 HTTPS 트래픽을 담당하고, Network Load Balancer는 TCP 트래픽을 담당한다. 이들을 지원하는 새 로드 밸런서는 VPC 외부 요소를 타겟으로 지정하고, 컨테이너 애플리케이션을 지원한다.

ALB는 애플리케이션 레이어 또는 OSI 모델 기준 레이어 7에서 작동한다. 레이어 7 프로토콜은 호스트 기반 라우팅 패스 및 패스 기반 라우팅을 허용하므로 사용자는 ALB를 이용해 마이크로서비스 또는 다른 티어 아키텍처의 서비스에 트래픽 전송이 가능하다.

NLB는 레이더 4 즉 트랜스포트 레이어에 해당하며 TCP 포트번호를 기준으로 트래픽을 관리한다. NLB는 고용량 데이터 전송 또는 급증하는 트래픽 대응에 적합하며 Auto Scaling, ECS, CloudFormation등 서비스와 통합해서 사용할 수 있다. NLB는 HTTP또는 HTTPS 프로토콜을 사용하지 않는 내부망 전용 애플리케이션과 AWS VPN 서비스 등에서도 사용할 수 있다.

클라우드 인프라 자동화

가상화의 큰 이점은 리소스를 스크립트화 할 수 있다는 것이다. Amazon 클라우드의 모든 서비스, 객체, 프로세스는 스크립트로 관리할 수 있으며, 코드로서의 인프라, 즉 IaC 환경을 제공한다.

CloudFormation

이를 사용해 인프라 리소스 스택 관리가 가능하다. Cloud Formation 템플릿은 JSON 또는 YAML 포맷의 텍스트 파일이며, 특정 프로젝트 구현에 필요한 AWS 리소스 정의가 가능하다.

템플릿은 다음과 같은 다양한 방법으로 생성할 수 있다.

• 브라우저 기반 드래그앤드롭 인터페이스 사용
• LAMP 웹 서버, WordPress 인스턴스 등의 사전 정의된 샘플 템플릿 활용
• 직접 템플릿 작성 후 업로드

CloudFormation 스택이란 템플릿으로 정의한 리소스 그룹이며, 템플릿을 로딩해 스택을 생성할 수 있다. AWS는 스택 로딩이 성공하면 리포트를 전송하고, 실패하면 변경 사항을 원래 상태로 되돌린다.

다수의 스택 활용하기

필요로 하는 모든 AWS 인프라를 하나의 스택에 정의할 필요는 없으며, 목적에 따라 인프라 요소를 여러 개의 스택으로 나눠 정의할 수 있다. 다수의 스택을 조직화하는 가장 좋은 방식은 리소스 라이프사이클, 관리주체에 따라 스택을 나눠 정의하는 것이다.

상호작용이 필요한 리소스를 여러 개의 스택에 나눠 정의하는 경우, 하나의 스택에서 다른 스택으로 값을 전달하는 기능이 필요하다. 예를들어 Web 스택의 ALB가 제대로 동작하려면 Network 스택에 정의된 VPC의 논리적 ID를 필요로한다.

스택간의 상호작용을 구현하는 방식 중 한 가지가 중첩스택이고 또 다른 방식이 스택 아웃풋 값 내보내기이다.

스택 업데이트하기

스택의 리소스 구성을 변경해야 하는 경우, 리소스 템플릿에서 리소스 구성 내용을 수정하는 것이 가장 바람직하며, 변경 내용의 적용을 위해 직접 업데이트 또는 변경 세트 적용 방식 중 하나를 선택할 수 있다.

직접 업데이트

직접 업데이트 방식이란 수정한 템플릿을 타겟 위치에 바로 업로드하는 것이다. 직접 업데이트시 CloudFormation이 템플릿에 필요한 파라미터의 입력을 요구하는 경우가 있으며, 템플릿에 포함된 변경 사항은 즉시 반영된다.

변경 세트를 이용한 업데이트

변경한 템플릿을 제출한 뒤 변경 세트를 생성하면 CloudFormation은 이번 템플릿을 통해 추가, 삭제, 변경될 리소스 목록을 모두 표시한다. 표시된 목록에서 즉시 변경할 내용의 변경 세트를 실행하면, 즉시 해당 리소스가 추가, 삭제, 변경된다.

업데이트 작업 속성

CloudFormation의 리소스 업데이트 방식은 선택한 업데이트 동작 속성에 따라 달라지며 리소스 업데이트 동작 유형은 중단 없는 업데이트, 중단 허용 업데이트, 대체 등 세 가지이다.

중단 없는 업데이트

업데이트 작업 중단, 물리적 ID 변경 없이 일괄적으로 업데이트가 진행된다.

중단 허용 업데이트

다른 리소스의 개입 및 일시적인 중단은 허용하지만 물리적 ID는 변경되지 않는 업데이트 동작이다.

대체

CloudFormation이 아예 새로운 물리적 ID를 지닌 새 리소스를 생성한 뒤 새 리소스에 대한 의존성 리소스를 표시하고 기존 리소스는 삭제한다.

업데이트에서 특정 리소스 제외하기

특정 리소스만 업데이트에서 제외할며녀 스택 생성 시 스택 정책을 생성하면 된다. CLI를 이용해 스택 정책을 변경하거나 기존 스택에 스택 정책을 적용할 수 있으며, 생성된 스택 정책은 삭제할 수 없다.

스택 정책은 리소스 정책 문서와 동일한 형식을 지니며, Effect, Action, Principal, Resource, Condition 등 요소로 구성된다.

CloudFormation은 특정 업데이트 동작이 스택 정책에 위배되는지 여부를 확인하지 않는다. 따라서 스택 업데이트 시 업데이트 성공 여부를 반드시 확인해야한다.

스택 정책 덮어쓰기

직접 업데이트로 스택 정책을 변경하는 경우, 업데이트 작업이 수행되는 동안에만 일시적으로 스택 정책을 덮어쓰기 할 수 있다. 직접 업데이트 수행 시, 기존 스택 정책 중 덮어쓰기할 정책을 선택할 수 있다. 이렇게 하면 CloudFormation이 자동으로 변경된 정책을 적용하며, 업데이트 작업 완료 후, 다시 원래의 스택 정책으로 되돌려놓는다.

서드파티 자동화 솔루션

Bash나 Windows PowerShell을 이용해 인프라 자동화 스크립트를 생성할 수 있으며, 이들 스크립트를 이용해 AWS 계정에 접속하고 리소스 스택을 생성, 수정, 삭제 할 수 있다.

서드파티 환경설정 관리도구를 이용해 리소스 스택의 단순한 정의 생성 차원을 넘어 강화된 환경설정, 버전 관리, 변경 관리 등 복잡한 업무를 수행할 수 있다.

강화된 환경 설정: 환경 설정 목표에 맞춰 리소스를 지속적으로 관리하기 위한 것

버전 관리: 코드 및 소프트웨어 패키지를 최신의 상태로 유지하기 위한 것

AWS OpsWorks: Chef

OpsWorks Chef 버전은 Chef로 스택 또는 레이어를 추가해 클라우드 인프라를 구성한다. 여기서 스택은 EC2 인스턴스 및 관련 리소스 컨테이너를 의미하고 레이어는 스택에 추가되는 부가기능을 정의한 것이다. 스택에는 Node.js 앱서버 레이어 외 로드 밸런서, ECS, RDS 등이 포함될 수 있다.

AWS OpsWorks: Puppet

OpsWorks Puppt Enterprise 버전은 Pupper Master 서버로 EC2 인스턴스를 생성하며, R10K 환경 및 모듈을 설정하고, 원격 코드 저장소 접근 권한을 부여한다. 서버가 실행되고 접근권한으로 로그인하면 Puppet 노드에 애플리케이션을 배포할 수 있다.

인프라 환경설정 검토 및 최적화

고성능 애플리케이션 구현이 목표라면 고성능을 구현하기 위한 기술과 전략에 대한 통찰이 있어야 한다. 이런 통찰은 클라우드 인프라와 리소스의 변경 사항을 모니터링하는방법론에서 나올 수 있다. 모니터링은 다음 네 가지 목표를 지닌다.

• 리소스 환경설정의 변경 사항을 관찰한다.
• AWS 서비스의 변경 사항을 관찰한다.
• 수동적으로 애플리케이션의 성능과 가용성을 모니터링한다.
• 능동적으로 애플리케이션의 성능과 가용성을 검증한다.

AWS Well-Architected Tool

Well-Architected Tool은 현재 사용중인 AWS 리소스의 효율성 또는 적합성을 정기적으로 점검하기 위한 좋은 도구이며, 활용 중인 각종 리소스를 워크로드를 기준으로 정의한 뒤 하나 이상의 Well-Architected Framework 또는 Serverless Application과 같은 렌즈 또는 평가 기준을 적용할 수 있다.

Well-Architected Tool은 Well-Architected Framework의 6대 기준인 보안성, 내구성, 성능효율성, 비용최적화, 운영우수성, 지속성 등을 기준으로 점수를 제시한다.

로드 테스트

실행중인 인프라에 대한 능동적 모니터링의 대표적인 방법 중 하나이다.

로드 테스트는 통제된 환경에서 인프라에 워크로드를 추가해 나갈 떄 리소스와 서버가 로드 또는 테스트에 어떻게 반응하는지 확인하는 시뮬레이션 테스트이다.

대부분의 로드 테스트는 상용 환경을 유사하게 구현한 테스트 환경에서 시행하는 것이 일반적이다. CloudFront와 같은 오케스트레이션 도구 또는 ECS와 같은 서비스를 이용해 이 환경을 신속하게 구현 가능하다.

단 로드 테스트를 수행하면서 인프라에 대한 공격, 해킹 테스트에 앞서 AWS에 명시적인 허락을 구해야한다.

로드 테스트 결과는 CloudWatch를 활성화해 실시간으로 파악할 수 있다.

시각화

테스트 결과들은 여러가지 방식으로 이해하기 쉽게 제공되어야 한다. 일부 AWS 서비스는 자체 시각화 도구를 지니고 있으며 EC2 인스턴스 콘솔의 경우 Monitoring 탭을 통해 십여 가지 이상의 성능 지표를 데이터 차트 형식으로 제공한다.

CLoudWatch 대시 보드가 데이터 시각화의 이점을 확실히 할 수 있다.

데이터 작업 최적화

데이터를 효율적으로 전송하는 일은 애플리케이션 성공 전략에서 빠질 수 없는 부분이다.

캐싱

애플리케이션이 특정 객체를 반복적으로 자주 요청한다면, 서버 내 시스템 메모리에 사본을 두거나, 캐싱 전용 데이터베이스에 사본 데이터를 저장한 뒤 매우 빠른 속도로 제공할 수 있다. 캐싱 기법을 사용하면 특정 객체에 대한 요청 시 원본 대신 좀 더 빠르게 대응할 수 있는 캐싱 사본을 제공하게 된다. 캐싱 사본은 최대 보존시간이 경과하기 전까지 시스템에 유지된다.

Amazon ElasticCache

ElasticCache 클러스터는 하나 이상의 노드로 구성된다. 여기서 노드는 EC2인스턴스 타입으로부터 생성된 컴퓨트 인스턴스이며 데이터를 처리하고 제공하는 일을 담당한다.

ElasticCache 클러스터는 Memcached 엔진 또는 Redis 엔진을 이용해 생성할 수 있다.

ElasticCache 클러스터 실행 후 ElasticCache 대시보드에서 클러스터의 엔드포인트를 가져온 뒤 이 엔드포인트를 이용해 애플리케이션을 클러스터와 연결할 수 있다.

ElasticCache를 사용하지 않고도 캐싱 기능을 사용하고 싶으면 EC2 인스턴스에서 Varnish와 같은 리버스 프록시를 실행하면 된다.

기타 캐싱 솔루션

애플리케이션 레벨에서의 캐싱 외에 데이터베이스에서 캐싱과 유사한 기법을 사용해 성능을 높일 수 있다.

DB에서 읽기 사본을 추가해 트래픽을 우회시켜 원본 데이터베이스의 부담을 줄이고 원본과 사본 모두의 반응 속도를 향상시킬 수 있다.

읽기 사본의 또 다른 장점은 원본을 제공하는 기본 데이터베이스 실패 시 읽기 사본을 기본 데이터베이스로 승격시킬 수 있다는 것이다.

또 다른 캐싱 기술로 CloudFront를 들 수 있다 CloudFront 배포는 클라이언트 인근 엣지 로케이션의 S3에 저장된 미디어 객체의 사본을 생성한 뒤 전세계 사용자에게 매우 빠른 속도로 미디어 콘텐츠를 제공할 수 있는 서비스이다.

데이터 파티셔닝/샤딩

RDS 데이터베이스에 대한 트래픽은 지속적으로 증가하는 경향이 있다. 이 경우 수직적 확장은 적용하기 어려운 경우가 많으며 파티셔닝, 샤딩을 이용한 수평적 확장 기법으로 데이터베이스의 응답 속도를 눈에 띄게 높일 수 있다. 이 기법은 읽기 사본보다는 복잡한 방법이지만 애플리케이션 레이어에 파티셔닝을 위한 환경설정 요소를 추가함으로써 클라이언트의 요청을 잘 처리할 수 있다.

 

Amazon DynamoDB Streams Kinesis Adapter를 이용해 실시간으로 데이터를 전송하고 DynamoDB 데이터베이스에 있는 데이터 레코드에 입력된 데이터를 실시간으로 처리할 수 있다. Kinesis는 데이터 레코드 조직화에 샤드를 사용한다. 하나의 샤드에는 메타데이터가 포함되어 있으며 하나의 샤드가 처리용량 한계에 다다르면 관련 워크로드를 다수의 샤드에 분산시킨다.

데이터 압축

네트워크 대역폭에 한계가 있고 정기적으로 전송하는 데이터의 크기 또한 쉽게 줄일 수 없을 때 몇가지 선택안이 있다. 전송 데이터의 크기 줄이기, 네트워크 한계 우회이다.

데이터 크기 줄이기는 압축을 사용하면 된다. 데이터 전송 전에 데이터를 압축해 네트워크로 보내면 된다. 압축 작업은 애플리케이션에서 진행할수도 있지만 AWS 서비스 내에서 압축 작업이 진행되기도 한다. 예를 들어 CloudFront의 경우 클라이언트 요청 시 파일을 전송할 때 자동으로 파일을 압축하도록 설정할 수 있으며 이를 통해 다운로드 시간을 줄일 수 있다.

네트워크 한계 우회는 Amazon의 snowball을 이용해 스토리지 전용 장비로 큰 데이터를 전송할 수 있다.

정리

• EC2 인스턴스의 성능과 가용성은 적절한 인스턴스 타입의 선택 여부고 Auto Scaling을 이용한 적절한 수의 인스턴스 프로비저닝을 통해 유지될 수 있다. 컴퓨트 워크로드는 Lambda 등 서버리스 모델 또는 ECS, EKS등 컨테이너 모델을 통해 좀 더 효과적으로 전달될 수 있다.
• EBS 볼륨 기반 데이터에 대한 접근성 및 데이터의 안전성은 RAID 배열 설정을 통해 강화할 수 있다. S3 크로스 리전 복제 및 S3 전송 가속 기능은 S3 데이터에 대한 접근성을 높여줄 수 있다.
• RDS의 스키마, 인덱스, 뷰, 옵션 그룹, 파라미터 그룹을 적절하게 설정함으로써 데이터베이스의 성능을 높일 수 있다. 직접 EC2 인스턴스에 설치한 데이터베이스의 경우 볼륨 클래스와 IOPS 레벨에 따라 성능이 크게 달라질 수 있다. 데이터의 내구성은 복제를 통해 높일 수 있고, 확장성은 수동 환경설정을 통해 관리할 수 있다.
• 로드 밸런서는 요청에 응답해 모든 백엔드 리소스에 로드를 분산시킨다. 이를 통해 헬스 체크를 자동화할 수 있고, 리소스를 최적으로 이용할 수 있는 라우팅 정책을 요청하며, 최선의 사용자 경험을 제공한다.
• AWS CloudFormation이나 AWS OpsWorks의 Chef 및 Puppet을 이용해 스크립트 기반으로 리소스를 프로비저닝하고, 복합적인 리소스 스택을 간단하게 생성할 수 있다. 이들 도구를 이용해 테스트 환경, 상용화 준비 환경, 상용화 환경을 신속하게 배포, 관리할 수 있다.
• CloudWatch, CloudTrail, AWS COnfig 등의 서비스를 이용해 리소스의 성능 및 상태를 모니터링 할 수 있다. 어드민 도구에 로드 테스트 및 보고서 시각화 도구를 포함시켜 관리의 효율성을 높일 수 있으며 CloudWatch 대시보드에서 관련 정보를 통합적으로 확인할 수 있다.
• 데이터 복제 등 캐싱 기법을 이용해 데이터 응답 속도를 높일 수 있고, 파티셔닝 및 샤딩 등의 기법을 이용해서 데이터 처리 성능을 높일 수 있으며, 데이터 압축을 통해 대량의 데이터를 신송하게 전송할 수 있다.