소개

AWS 기초 과정은 AWS에서 효율적으로 작업하기 위해 필요한 핵심 개념에 대한 설명을 제공합니다.

처음 시작할 때 AWS는 매우 복잡해 보일 수 있습니다. 인프라 구축에서 클라우드 네이티브 패러다임은 기존 온프레미스 구축 방식과 근본적으로 다릅니다. 그리고 인프라를 처음으로 구축하는 고객 또는 지난 10년 동안 Linux 커널을 튜닝해 온 고객이든지 간에, 175개 이상의 AWS 서비스 중에서 무엇을 처음으로 선택할지는 아는 것은 어려울 수 있습니다.

AWS 기초 과정은 경험과 관계없이 고객이 AWS를 손쉽게 시작할 수 있도록 설계되었습니다. 이 과정에서는 AWS의 5대 원칙, 클라우드를 고려할 때 사용할 멘탈 모델 및 최종적으로 사용할 서비스에 적용될 주요 개념에 대해 학습할 수 있습니다.

 

구조

AWS 기초 과정은 5가지 모듈로 구성됩니다, 각 모듈은 다음 형식을 따릅니다.

  • 소개: 집중할 원칙에 대한 간략한 설명
  • 멘탈 모델: 각 원칙에서 소개되는 개념의 이해를 돕는 안내 멘탈 모델
  • 개념: 각 원칙의 광범위한 기초 주제를 다루는 주요 개념
  • 결론: 주요 내용의 요약
  • 추가 자료: 추가 링크 및 자료
 

5대 원칙

AWS 기초 과정에서 다루는 5대 원칙은 AWS Well-Architected 프레임워크에서 제공됩니다. Well-Architected 프레임워크는 클라우드에서 확장 가능한 애플리케이션을 구축한 10년 동안의 경험이 집약된 핵심입니다.

5대 원칙을 구성하는 영역은 다음과 같습니다.

  1. 보안
  2. 성능 효율성
  3. 안정성
  4. 운영 우수성
  5. 비용 최적화
 

보안

보안 원칙은 클라우드에서 인프라를 보호하는 방법에 중점을 둡니다. 보안과 규정 준수는 AWS와 고객의 공동 책임입니다. 이러한 공동 책임 모델에서 AWS는 클라우드의 보안에 대한 책임이 있습니다. 여기에는 AWS 클라우드 서비스의 물리적 인프라, 소프트웨어 및 네트워킹 기능이 포함됩니다. 고객은 클라우드에서의 보안에 대한 책임이 있습니다. 여기에는 특정 클라우드 서비스의 구성, 애플리케이션 소프트웨어 및 민감한 데이터 관리가 포함됩니다.

워크로드가 FedRAMP, DoD SRG, ITAR, CJIS 또는 기타 엄격한 규정 준수 요구 사항을 충족해야하거나, CUI (Controlled Unclassified Information)로 분류 된 데이터가 포함 된 경우, AWS GovCloud (미국)섹션을 참조하십시오.

 

멘탈 모델

클라우드에서의 보안을 고려할 때는 제로 트러스트 모델을 도입하는 것이 유용합니다.

이 모델에서 모든 애플리케이션 구성 요소 및 서비스는 별개이며 잠재적으로 악의적인 엔터티로 간주됩니다. 그리고 기반 네트워크 패브릭, 리소스에 액세스하는 모든 에이전트 및 서비스 내부에서 실행되는 소프트웨어가 포함됩니다.

 

개념

제로 트러스트의 관점에서 보안은 모든 시스템 수준에 보안 조치를 적용하는 것을 의미합니다. 클라우드에서 제로 트러스트를 적용하여 시스템 보안을 수행하는 것과 관련된 세 가지 주요 개념은 다음과 같습니다.

  1. Identity and Access Management(IAM)
  2. 네트워크 보안
  3. 데이터 암호화

 

  • Identity and Access Management(IAM)

    IAM은 시스템에서 ID 및 액세스를 추적하는 서비스입니다. IAM은 IAM 서비스라는 적절한 이름으로 AWS에서 관리됩니다. 액세스는 AWS 내에서 에이전트에 대한 액세스 경계를 적용하는 IAM 정책을 사용하여 관리됩니다. IAM 정책의 세 가지 기본 구성 요소는 다음과 같습니다.

    • 주체는 권한이 제공되는 대상을 지정합니다.
    • 작업은 수행되는 것을 지정합니다.
    • 리소스는 액세스되는 속성을 지정합니다.

    IAM에 제로 트러스트 모델을 적용하는 것은 최소 권한 원칙을 사용하는 것을 의미합니다. 즉, 모든 에이전트에게는 기능을 수행하기 위해 필요한 최소한의 권한이 부여되어야 합니다.

    IAM 정책은 AWS 주체 또는 AWS 리소스에 적용될 수 있습니다. 주체와 연관된 정책을 ID 기반 정책이라고 합니다. 리소스와 연관된 정책을 리소스 기반 정책이라고 합니다. 일부 서비스(예: S3, KMS, SES)에만 리소스 기반 정책이 적용됨에 유의하십시오.

    주체가 특정 리소스에 대한 작업을 수행할 권한이 있는지의 여부는 주체의 ID 기반 정책이 이를 허용하는지의 여부 및 리소스의 리소스 기반 정책(있는 경우)이 이를 금지하지 않는지의 여부에 따라 다릅니다.

    이것은 IAM 권한 모델을 매우 간소화한 것임에 유의하십시오. 액세스 허용 여부에 영향을 주는 여러 추가적인 정책 유형이 있습니다. 그러한 정책 유형으로는 권한 경계, 조직 서비스 제어 정책, 액세스 제어 목록세션 정책 등이 있습니다. 이러한 추가 정책 유형은 이 과정의 범위를 벗어납니다. 이와 관련한 자세한 내용은 이 모듈의 추가 자료 섹션에서 확인할 수 있습니다.

    요점

    • IAM 정책은 AWS 내에서 엔터티의 액세스 경계를 명시합니다.
    • IAM 정책은 주체, 작업 및 리소스로 구성됩니다.
    • IAM 정책을 사용하여 주체에 최소 권한을 적용할 수 있습니다.
    • IAM에는 ID 기반 및 리소스 기반 등 여러 정책 유형이 있습니다.
    • IAM은 지정된 리스소에 적용할 수 있는 모든 정책 유형에 대한 평가를 기반으로 액세스를 평가합니다.
     

    추가 자료

  • 네트워크 보안

    네트워크 보안에는 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하는 시스템, 구성 또는 프로세스가 포함됩니다. AWS는 네트워크 수준 및 리소스 수준 모두에서 네트워크를 보호하기 위한 매우 다양한 기능을 제공합니다.

    네트워크 보안에 대한 제로 트러스트 접근법에는 네트워크의 모든 레이어(가장 외부 레이어만이 아닌)에 보안 제어를 적용하는 심층적 방어 접근법이 포함됩니다.

    네트워크 수준 보안

    AWS에서 기본 네트워크 수준은 Amazon Virtual Private Cloud(VPC)입니다. VPC는 리소스를 정의 및 프로비저닝할 수 있는 논리적 네트워크입니다.

    VPC를 구성하는 일부 구성 요소는 다음과 같습니다.

    • 서브넷: VPC 내부의 IP 주소 범위
    • 라우팅 테이블: 트래픽이 이동하는 위치를 결정하는 규칙 집합
    • 인터넷 게이트웨이: VPC 내부의 리소스와 인터넷 사이에서 통신을 할 수 있게 해주는 구성 요소

    VPC에서 트래픽을 보호하려면, 리소스를 공용 리소스와 내부 리소스를 나눌 수 있습니다. 공격 표면을 줄이려면, 모든 인터넷 트래픽을 처리하는 Application Load Balancer(ALB) 등과 같은 프록시 서비스를 사용할 수 있습니다. 그러면 서버와 데이터베이스 같은 모든 내부 서비스를 직접 공용 인터넷 액세스를 차단하는 내부 서브넷으로 프로비저닝할 수 있습니다.

    VPC뿐만 아니라, AWS Web Application Firewall(WAF)을 사용하여 네트워크에 대한 트래픽을 추가적으로 제한할 수 있습니다.

    리소스 수준 보안

    개별 AWS 리소스에도 사용자가 구성이 가능한 네트워크 보안 제어를 적용할 수 있습니다. 가장 일반적인 제어는 보안 그룹입니다. 보안 그룹은 리소스로 유입 및 유출되는 트래픽 흐름을 적용하기 위해 사용할 수 있는 가상 방화벽입니다. 보안 그룹을 사용하면 특정 포트 또는 인스턴스에서 신뢰할 수 있는 소스로부터의 트래픽만 허용할 수 있습니다. EC2 인스턴스, RDS 인스턴스 및 Lambda 등의 리소스에 보안 그룹을 연결할 수 있습니다.

    요점

    • 네트워크 보안에는 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하도록 설계된 메커니즘이 포함됩니다.
    • 네트워크 보안에 대한 제로 트러스트 접근법에는 네트워크의 모든 레이어에 심층적인 방어를 구축하는 것이 포함됩니다.
    • VPC 및 WAF를 사용하면 네트워크 수준에 보안 조치를 적용할 수 있습니다.
    • 보안 그룹을 사용하면 리소스 수준에 보안 조치를 적용할 수 있습니다.

    추가 자료

  • 데이터 암호화

    데이터 암호화는 데이터의 암호를 해독하기 위해 필요한 키가 없는 제삼자가 이해할 수 없는 방식으로 정보를 암호화하는 프로세스입니다.

    데이터에 제로 트러스트 모델을 적용하는 것은 모든 곳에 있는 전송 중 및 저장 중 데이터 모두를 암호화하는 것입니다.

    전송 중 암호화

    전송 중 암호화에서는 데이터가 시스템 사이에서 이동할 때 데이터를 암호화합니다. AWS 내의 모든 스토리지 및 데이터베이스 서비스는 전송 중 데이터 암호화를 지원하는 HTTP 엔드포인트를 제공합니다. 또한, AWS는 사용자 서비스에 전송 중 암호화를 적용할 수 있는 네트워크 서비스도 제공합니다. 예를 들어, Application Load Balancer(ALB)를 사용하면 사용자의 엔드포인트에 HTTPS 연결을 적용할 수 있습니다.

    저장 중 암호화

    저장 중 암호화에서는 시스템 내의 데이터를 암호화됩니다. 모든 AWS 스토리지 및 데이터베이스 서비스는 저장 중 암호화를 지원합니다. 이러한 서비스 중 대부분은 암호화가 기본적으로 수행됩니다. 암호화를 위한 추가 비용 및 데이터를 암호화하기 위한 성능 저하가 없습니다.

    대부분의 스토리지 및 데이터베이스 서비스는 Amazon Key Management Service(KMS)와 직접 통합됩니다. 이는 데이터를 암호화하기 위해 고객 관리 키(CMK)를 생성할 수 있도록 해주는 중앙 키 관리 서비스입니다.

    CMK를 사용하면 암호화 이상의 추가 기능이 제공됩니다. 그러한 기능에는 자체 사용자 지정 키 저장소 사용, AWS CloudTrail과 통합하여 암호화된 리소스에 대한 감사 추적 생성 및 자동 키 회전 적용 등이 있습니다.

    요점

    • 암호화는 올바른 키를 가지고 있는 당사자만 정보의 암호를 해독할 수 있는 방식으로 정보를 암호화하는 프로세스입니다.
    • 전송 중 및 저장 중 데이터를 암호화하여 데이터의 보안을 유지할 수 있습니다.
    • AWS의 모든 스토리지 및 데이터베이스 서비스는 전송 중 및 저장 중 암호화를 제공합니다.
    • ALB 등 AWS 네트워킹 서비스를 사용하면 자체 서비스에 전송 중 암호화를 적용할 수 있습니다.
    • CMK를 사용하면 감사 추적 생성, 자체 사용자 지정 키 사용 및 자동 키 회전과 같은 고급 기능을 활용할 수 있습니다.

    추가 자료

    기능

     

    서비스

     

    레퍼런스

     

     

결론

이 모듈에서는 AWS의 보안 주요 사항에 대해 학습했습니다. 제로 트러스트의 멘탈 모델에 대해서도 학습했습니다. 그리고 IAM 및 최소한의 권한 원칙에 대해 학습했습니다. 또한, AWS 네트워크 보안 및 방어 원칙에 대해 심층적으로 학습했습니다. 데이터 암호화와 사용 및 미사용 데이터에 암호화를 적용하는 것에 대해서도 학습했습니다.

 

추가 자료

성능 효율성

성능 효율성 원칙은 클라우드에서 서비스를 효율적이고 확장 가능하도록 실행하는 방법에 중점을 줍니다. 클라우드는 모든 규모의 트래픽을 처리할 수 있는 수단을 제공하는 반면, 이를 위해서는 확장을 염두하고 서비스를 선택 및 구성해야 합니다.

 

멘탈 모델

클라우드에서의 성능 효율성을 고려할 때는 서비스를 애완 동물이 아닌 소라고 생각하는 것이 유용합니다.

온프레미스 모델 방식에서는 서버가 비싸며 수동으로 배포 및 구성해야 하는 경우가 있습니다. 서버가 배송되어 데이터 센터에 물리적으로 연결될 때까지는 몇 주가 걸릴 수 있습니다. 이로 인해 서버는 각각이 고유하고 많은 유지관리가 필요한 애완 동물처럼 취급됩니다. 일부 서버에는 이름이 있는 경우도 있습니다.

클라우드에서 서버는 소처럼 간주됩니다. 서버는 몇 초 내에 자동으로 프로비저닝될 수 있는 상용 리소스입니다. 서비스의 작동에 필수적인 단일 서버는 없습니다.

 

개념

서버를 소로 생각하는 것은 성능과 관련한 여러 이점이 있습니다. 서버 관리의 “애완 동물 모델”에서는 여러 워크로드에 대하여 동일한 유형의 서버(또는 심지어 동일 서버)를 사용하는 것이 매우 일반적이며, 이로 인해 다른 시스템을 주문하고 프로비저닝하는 것이 매우 번거롭습니다. “소 모델”에서는 프로비저닝이 빠르고 저렴하며 워크로드와 가장 일치하는 서버 유형을 자유롭게 선택할 수 있습니다.

“소 모델”에서는 서비스를 확장하는 것도 편리합니다. 모든 서버가 호환되고 빠르게 배포할 수 있으므로, 더 많은 서버를 추가하여 용량을 빠르게 확장할 수 있습니다.

성능 효율성에서는 다음의 두 가지 개념에 중점을 둡니다.

  1. 셀렉트
  2. 확장
 
  • 셀렉트

    AWS에서의 셀렉트는 워크로드에 가장 적합한 서비스를 선택할 수 있는 기능입니다. AWS는 24개 이상의 범주에서 175개 이상의 서비스를 제공하므로 서비스의 선택폭이 매우 광범위합니다. 선택을 통해 성능을 달성하는 것은 작업에 적합한 도구를 선택할 수 있다는 의미를 갖습니다.

    일반적인 워크로드의 경우 컴퓨팅, 스토리지, 데이터베이스 및 네트워크의 AWS 주요 4개 서비스 범주에서 선택하면 됩니다.

    • 컴퓨팅은 데이터를 처리하는 서비스(예: 가상 머신)입니다.
    • 스토리지는 데이터를 정적으로 저장하는 서비스(예: 객체 저장)입니다.
    • 데이터베이스는 데이터를 구조화하여 저장하는 서비스(예: 관계형 데이터베이스)입니다.
    • 네트워크는 데이터의 이동 방법과 관련한 서비스(예: 콘텐츠 전송 네트워크)입니다.

    이 모듈에서는 첫 3가지 범주에서 올바른 선택을 하는 방법에 대해 알아봅니다. 다양한 네트워킹 옵션 중에서의 선택과 관련한 지침은 추가 자료 섹션을 참조하십시오.

    어느 범주에서 선택하든지 간에, 다음 3가지 사항을 고려해야 합니다.

    1. 서비스 유형
    2. 관리 수준
    3. 구성

    서비스 유형

    범주에서 선택할 때 AWS는 사용할 수 있는 서비스의 유형에 대한 다양한 옵션을 제공합니다. 유형은 각 범주마다 다릅니다.

    컴퓨팅 서비스를 선택할 때는 VM 기반, 컨테이너 기반 또는 서버리스 기반 컴퓨팅 중에서 결정할 수 있습니다.

    • VM 기반 컴퓨팅은 대부분의 사용자에게 가장 익숙한 멘탈 모델이지만, 비용과 유지관리가 더 많이 필요할 수 있습니다.
    • 컨테이너 기반 컴퓨팅을 사용하면 워크로드를 세밀하게 분할하고 빠르게 확장할 수 있지만, 추가적인 구성 및 오케스트레이션 복잡성이 나타날 수 있습니다.
    • 서버리스 기반 컴퓨팅에서는 대부분의 관리 및 확장 복잡성이 사라지지만, 하드 시스템 제한이 있고 새로운 도구 체인 및 프로세스를 도입해야 할 수 있습니다.

    스토리지 서비스를 선택할 때는 파일 스토어, 블록 스토어, 객체 스토어 또는 아카이브 스토어가 필요한지의 여부를 결정해야 합니다.

    • EBS 등의 블록 스토리지는 단일 EC2 인스턴스에서 제공되는 데이터를 유지하는 데 적합합니다.
    • EFS 등의 파일 시스템은 동일 데이터에 다중 클라이언트 액세스를 제공하는 데 적합합니다.
    • S3 등의 객체 스토어는 많은 수의 클라이언트가 액세스해야 하는 데이터의 대규모 Blob에 적합합니다.
    • S3 Glacier 등의 아카이브 스토리지는 자주 액세스하지 않는 라지 데이터에 적합합니다.

    데이터베이스 서비스를 선택할 때는 관계형 데이터베이스, 비관계형 데이터베이스, 데이터 웨어하우스 솔루션 또는 데이터 인덱싱 및 검색 솔루션이 필요한지의 여부를 결정해야 합니다.

    • 관계형 데이터베이스를 사용하면 속성의 조인 및 ACID를 수행할 수 있지만, 성능과 데이터 스토리지의 상한이 적용됩니다.
    • 비관계형 데이터베이스는 스키마가 보다 유연하고 관계형 데이터베이스에 비해 상한이 높지만, 조인 및 전체 ACID 기능이 일반적으로 부족합니다.
    • 데이터 웨어하우스 솔루션을 사용하면 페타바이트 규모의 구조화된 데이터에 빠르게 액세스할 수 있어 라지 분석이 가능합니다.
    • 데이터 인덱싱 및 검색 솔루션을 사용하면 매우 다양한 리소스의 데이터를 인덱싱 및 검색할 수 있습니다.
     

    관리 수준

    서비스 유형을 결정한 후에는 사용할 서비스의 범위를 줄여야 합니다. 일부 경우 AWS는 특정 서비스 유형에서 여러 서비스를 제공하기도 합니다. 동일한 유형의 서비스 중 여러 AWS 서비스 간의 주된 차이점은 관리 정도입니다.

    컴퓨팅 서비스를 사용하며 VM 유형을 결정한 경우에는 EC2, LightsailElastic Beanstalk 중에서 선택해야 합니다. EC2를 사용하면 제어 수준이 가장 높지만 관리 수준은 가장 낮은 반면, Lightsail의 경우 매우 향상된 관리형 경험을 위한 사용자 지정이 가능합니다. Elastic Beanstalk은 EC2와 Lightsail 사이의 관리 수준을 제공하며, 서비스 아키텍처를 위한 독자적인 프레임워크를 제공하지만 구성을 통해 사용자 지정하는 것이 가능합니다.

    스토리지 서비스를 사용하는 경우에는 지정된 유형에 1개의 서비스만 제공되는 경향이 있으므로 서비스를 편리하게 선택할 수 있습니다(예: 객체 저장의 경우 S3, 파일 저장의 경우 EFS).

    데이터베이스 서비스를 사용하며 관계형 유형을 결정한 경우에는 RDSAurora 중에서 선택해야 합니다. RDS는 기본 데이터베이스에 대한 향상된 제어 수준을 제공하며 대부분의 관계형 데이터베이스에서 사용할 수 있습니다. Aurora는 특정 MySQL 및 PostgreSQL 버전에서만 동작하지만, 기본 스토리지에 대한 관리 수준이 향상되고 내장 클러스터가 지원됩니다.

    마지막으로 특정 서비스의 선택은 기본 기술에 대한 지식 및 원하는 관리형 경험의 수준에 따라 달라질 수 있습니다.

     

    구성

    서비스를 선택한 후에는 구성 방법을 결정해야 합니다. 구성은 달성하려는 특정 성능 특성에 따라 달라지며, 성능 특성을 각 서비스 범주마다 다릅니다.

    컴퓨팅 서비스에 대한 성능 특성을 평가할 때는 메모리 및 컴퓨팅 요구 사항을 살펴보는 것이 좋습니다.

    • VM 기반 컴퓨팅을 사용할 때 메모리 및 CPU는 인스턴스 크기(예: t3.small 대 t3.xlarge) 및 인스턴스 패밀리(예: r3.small 대 c5.small)에 의해 영향을 받습니다.
    • 컨테이너 기반 컴퓨팅을 사용할 때는 메모리와 CPU를 개별적으로 설정할 수 있습니다.
    • 서버리스 컴퓨팅을 사용할 때는 메모리만 직접 설정이 가능하며 컴퓨팅의 값(및 기타 시스템 리소스)은 가용 메모리의 양에 따라 선형적으로 증가합니다.

    워크로드에 따라, 인스턴스 스토리지와 같은 특정 리소스의 가용성 및 네트워크 용량 등을 고려해야 하는 추가적인 리소스 제약이 있다는 점에 유의하십시오.

    스토리지 서비스에 대한 성능 특성을 평가할 때는 대기 시간, 처리량 및 IOPS 요구 사항을 고려해야 합니다.

    • 블록 스토리지 서비스를 사용하는 경우
      • 대기 시간은 선택한 볼륨 유형(예: SSD 대 하드 디스크 드라이브)의 영향을 받습니다.
      • 처리량은 대부분 볼륨 유형에서 볼륨 크기에 비례합니다.
      • IOPS는 대부분 볼륨 유형에서 볼륨 크기에 비례합니다.
    • 파일 시스템 서비스를 사용하는 경우
      • 대기 시간 및 IOPS는 선택한 성능 모드의 영향을 받습니다.
      • 처리량은 프로비저닝된 처리량의 사용 여부에 의해 영향을 받습니다.
    • 객체 스토어를 사용하는 경우
      • 대기 시간은 버킷 엔드포인트까지의 지리적 거리에 의해 영향을 받습니다.
      • 처리량은 멀티파트 업로드 등과 같이 처리량에 최적화된 API의 사용 여부에 의해 영향을 받습니다.
      • IOPS는 구성할 수 없습니다.
    • 아카이브 스토어를 사용하는 경우
      • 대기 시간은 버킷 엔드포인트까지의 지리적 거리 및 선택한 검색 방법에 의해 영향을 받습니다.
      • 처리량은 멀티파트 업로드 등과 같이 처리량에 최적화된 API의 사용 여부에 의해 영향을 받습니다.
      • IOPS는 구성할 수 없습니다.

    데이터베이스 서비스의 성능 특성을 평가할 때는 리소스 요구 사항(예: CPU, 메모리, 스토리지 등)을 고려해야 합니다.

    • 관계형 데이터베이스를 사용하는 경우
      • 리소스 기능은 선택한 EC2 인스턴스에 의해 결정됩니다.
    • DynamoDB와 같은 비관계형 데이터베이스를 사용하는 경우
    • Redshift와 같은 데이터 웨어하우스 솔루션을 사용하는 경우
      • 리소스 기능은 선택한 기본 EC2 인스턴스에 의해 결정됩니다.
    • Elasticsearch Service와 같은 인덱싱 솔루션을 사용하는 경우
      • 리소스 기능은 선택한 EC2 인스턴스에 의해 결정됩니다.

     

    요점

    • AWS는 원하는 결과를 달성하기 위한 다양한 서비스와 방식을 제공합니다.
    • AWS에서 워크로드를 구현하기 위해서는 컴퓨팅, 스토리지, 데이터베이스 및 네트워크 범주에서 서비스를 선택해야 합니다.
    • 각 범주 내에서는 사용 사례에 따라 적합한 서비스 유형을 선택할 수 있습니다.
    • 각 유형 내에서는 원하는 관리 수준에 따라 특정 서비스를 선택할 수 있습니다.
    • 각 서비스 내에서는 달성하려는 특정 성능 특성에 따라 특정 구성을 선택할 수 있습니다.
     

    추가 자료

  • 확장

    적합한 서비스를 선택하는 것은 시작을 위한 핵심이지만 확장 방법을 선택하는 것은 지속적인 성능에 중요합니다.

    AWS는 다음의 두 가지 기본 확장 방법을 제공합니다.

    1. 수직 확장
    2. 수평 확장


    수직 확장

    수직 확장에는 기본 컴퓨팅을 더 큰 규모의 인스턴스 유형으로 업그레이드하는 것이 포함됩니다. 예를 들어, t3.small 인스턴스를 실행하는 경우를 가정해 보겠습니다. 이 인스턴스를 수직 확장하려면 t3.large로 업그레이드할 수 있습니다.

    수직 확장을 위해서는 서비스를 클러스터화할 필요가 없으므로 일반적으로 구현이 편리합니다. 단점은 수직 확장에 비해 실행의 상한(컴퓨팅 인스턴스의 최대 크기에 해당)이 매우 낮다는 것입니다. 또한, 인스턴스 중단으로 인해 서비스를 완전히 사용할 수 없게 될 수 있으므로 단일 장애점이 될 수도 있습니다.

     

    수평 확장

    수평 확장에는 기본 인스턴스의 수 증가가 포함됩니다. 예를 들어, t3.small 인스턴스를 실행하는 경우를 가정해 보겠습니다. 이 인스턴스를 수평 확장하려면 두 개의 t3.small 인스턴스를 추가로 프로비저닝해야 합니다.

    수평 확장을 위해서는 구현 측면에서 추가적인 오버헤드가 필요합니다. 왜냐하면 서비스 플릿으로 서비스의 경로를 지정하기 위한 프록시 서버가 필요하기 때문입니다. 또한, 라우팅 풀에서 불량 인스턴스를 제거하기 위한 상태 확인을 수행하고 워크로드에 가장 적합한 특정 라우팅 알고리즘도 선택해야 합니다. 그 대신, 수직 확장에 비해 서비스의 복원력이 크게 향상되고 확장성이 매우 증가합니다.


    요점

    • 수직 확장은 운영이 단순하지만 가용성 위험이 있으며 확장성이 낮습니다.
    • 수평 확장은 오버헤드가 증가하지만 복원력과 확장성이 크게 향상됩니다.
     

    추가 자료

결론

이 모듈에서는 AWS의 성능 효율성 원칙에 대해 학습했습니다. 서비스를 애완 동물이 아닌 소의 개념으로 처리하는 멘탈 모델에 대해 알아봤으며, 성능 목표에 따라 적합한 서비스와 구성을 선택하는 방법을 살펴봤습니다. 또한, 서비스 확장 및 수직과 수평 확장 사이의 트레이드오프에 대해서도 학습했습니다.

 

추가 자료

안정성

안정성 원칙은 서비스 및 인프라 중단 시 복원할 수 있는 서비스의 구축 방법에 중점을 둡니다. 성능 효율성과 매우 유사하게, 클라우드는 중단 시 이를 처리할 수 있는 복원력이 있는 서비스를 구축하기 위한 수단을 제공하는 반면, 이를 위해서는 안정성을 염두하고 서비스의 구조를 설계해야 합니다.


멘탈 모델

클라우드에서의 안정성을 고려할 때는 파급 범위를 고려하는 것이 좋습니다. 파급 범위는 시스템 장애 발생 시 지속될 수 있는 최대 영향으로 생각할 수 있습니다. 신뢰할 수 있는 서비스를 구축하려면 개별 구성 요소의 파급 범위를 최소화해야 합니다.

 

개념

파급 범위의 관점에서 고려할 때, 장애 문제는 가능성의 문제가 아니라 시점의 문제입니다. 장애 발생 시 이를 처리하려면 파급 범위를 제한하기 위해 다음과 같은 기법을 사용할 수 있습니다.

  1. 장애 격리
  2. 한도


  • 장애 격리

    장애 격리는 장애 격리 영역으로 구분되는 중복된 독립 구성 요소를 사용하여 문제의 파급 범위를 제한합니다. 장애 격리 영역에는 장애 격리 영역 내 영역에 대한 장애의 영향이 포함됩니다.

    AWS는 다음과 같이 세 가지 수준의 장애 격리 영역을 제공합니다.

    1. 리소스 및 요청
    2. 가용 영역
    3. 리전

     

    리소스 및 요청

    AWS 서비스는 리소스 ID와 같이 지정된 차원의 모든 리소스 및 요청을 분할합니다. 이러한 분할 영역을 이라고 합니다. 셀은 독립적이며 단일 셀 내에 장애를 포함하도록 설계되었습니다. 내부적으로 AWS는 셔플 샤딩과 같은 기법을 사용하여 파급 범위를 제한합니다. 이는 사용자가 요청을 하거나 리소스를 생성할 때마다 투명하게 수행되며 사용자가 추가적으로 작업을 수행하지 않아도 됩니다.


    가용 영역

    AWS 가용 영역(AZ)은 전용 전력, 서비스 및 네트워크 기능이 있는 완전히 독립적인 시설입니다. AZ는 다른 AZ와 지리적으로 분리되어 화재 및 홍수 등의 환경 위험으로 인한 동시 장애가 방지됩니다.

    장애 격리는 여러 AZ에 서비스의 중복 인스턴스를 배포하여 AZ 수준에서 수행됩니다. 이를 통해 한 AZ에서 전력 문제가 발생해도 다른 AZ의 트래픽에는 영향을 주지 않습니다.

    그리고 대기 시간과 관련하여 AZ는 지리적으로 분리되어 있지만 AZ 사이의 네트워크 대기 시간이 최소화되도록 서로 충분히 가까이에 위치합니다. 이를 통해 동기화 데이터 복제와 같은 특정 기능이 AZ 사이에서 수행될 수 있습니다.


    리전

    AWS 리전은 궁극적인 격리를 제공합니다. 각 리전은 완전한 자율 데이터 센터이며 두 개 이상의 AZ로 구성됩니다. 장애 격리는 다른 AWS 리전에 서비스의 중복 사본을 배포하여 리전 수준에서 수행됩니다(이 방식으로 AWS가 자체 서비스를 수행).

    매우 높은 수준의 가용성이 필요하여 여러 리전으로 배포하는 경우를 생각해 보십시오. 여러 리전에서 서비스를 운영하기 위해서는 리전 사이에 공유 인프라가 없기 때문에 커다란 오버헤드가 발생합니다. 여러 리전에 구축할 수 있도록 지원하는 서비스와 기능이 있습니다. 예를 들어, AWS의 확장 가능 DNS 서비스인 Route53을 사용하여 다른 리전 사이에서 트래픽을 라우팅할 수 있습니다. 또한, DynamoDB 글로벌 테이블S3 리전 간 복제 등의 기능을 사용하여 리전 간에 데이터를 복제할 수도 있습니다.


    요점

    • 기본 격리 영역을 사용하면 서비스 또는 인프라 중단의 파급 범위를 제한할 수 있습니다.
    • 리소스 및 요청 수준에서 장애를 격리하려면 모든 AWS 서비스의 설계에서 구현되어야 하며, 이를 위해서는 사용자의 추가 작업이 필요합니다.
    • AZ 수준에서의 장애 격리는 여러 AZ에 서비스를 배포하여 수행될 수 있으며, 이는 최소한의 대기 시간 영향으로 수행될 수 있습니다.
    • 리전 수준에서의 장애 격리는 여러 리전에 서비스를 배포하여 수행될 수 있으며, 이를 위해서는 상당한 운영 오버헤드가 필요합니다.


    추가 자료

  • 한도

    한도는 과도한 부하로부터 서비스를 보호하기 위해 적용될 수 있는 제약입니다. 한도는 외부(예:DDoS 공격) 및 내부(예: 소프트웨어의 잘못된 구성) 문제로 인한 파급 범위를 제한하기 위한 효과적인 수단입니다.

    AWS 서비스에는 리전 및 계정을 기준으로 서비스별 한도가 있습니다. 이러한 한도를 Service Quotas라고도 합니다. AWS 계정에는 특정 리소스, 작업 및 항목에 대한 최대 값이 있습니다.

    다음과 같은 두 가지 유형의 한도가 있습니다.

    • AWS에서 증가를 요청하여 증가할 수 있는 소프트 한도
    • 증가할 수 없는 하드 한도

    각 서비스는 한도가 다릅니다. 한도를 추적하고 증가를 요청하려면 Service Quotas 서비스를 사용할 수 있습니다.

    서비스 중단을 방지하려면 서비스 한도를 모니터링하고 한도에 도달하는 시점을 파악하는 것이 중요합니다. 동시 Lambda 실행과 같은 일부 리소스의 경우 CloudWatch를 통한 추적이 가능합니다. EC2 인스턴스 수와 같은 기타 리소스의 경우 수동으로 또는 스크립트를 통해 추적해야 합니다. AWS Trusted Advisor 서비스를 사용하면 Business Support 또는 Enterprise Support 플랜 이용 시 한도를 추적할 수 있습니다. awslimitchecker 등의 오픈 소스를 사용하면 프로세스를 자동화하는 것도 가능합니다.


    요점

    • 한도는 과도한 부하로부터 서비스를 보호하기 위해 적용될 수 있는 제약입니다.
    • AWS 서비스 한도는 Service Quota 서비스를 사용하여 추적 및 관리가 가능합니다.
    • 증가가 가능한 소프트 한도와 증가할 수 없는 하드 한도가 없습니다.
    • 사용 중인 서비스의 한도를 모니터링하고 그에 따라 플랜의 안도를 늘려 서비스 중단을 방지할 수 있습니다.


    추가 자료

결론

이 모듈에서는 AWS의 안정성 원칙에 대해 학습했습니다. 파급 범위의 관점에서 멘탈 모델의 고려 사항과 장애 격리 영역을 사용한 파급 범위 제한에 대해서도 알아봤습니다. 또한, 서비스 한도 및 서비스 한도를 늘려 서비스 중단을 방지하는 방법에 대해서도 학습했습니다.

 

추가 자료

운영 우수성

운영 우수성 원칙은 시스템 운영, 향상된 절차 개발 및 통찰력 확보 역량을 지속적으로 향상할 수 있는 방법에 집중합니다.


멘탈 모델

클라우드에서의 운영 우수성을 고려할 때는 자동화의 측면에서 생각하는 것이 유용합니다.

인적 오류는 결함 및 운영 문제의 주된 원인입니다. 운영이 자동화될 수록 인적 오류가 발생할 가능성이 줄어듭니다.

자동화를 통해 오류가 방지될 뿐만 아니라 내부 프로세스가 지속적으로 향상될 수도 있습니다. 자동화는 전체 조직에서 적용될 수 있는 반복 가능한 모범 사례 집합을 향상합니다.


개념

운영 자동화를 고려할 때 현재 대부분 수작업이 필요하며 오류의 파급력이 가장 큰 영역에 집중하기를 원할 수 있습니다. 또한, 운영 활동을 추적, 분석 및 향상하기 위한 프로세스를 적용하기를 원할 수도 있습니다.

운영 우수성에서는 다음의 두 가지 개념에 중점을 둡니다.

  1. 코드형 인프라스트럭처
  2. 관찰 기능


  • 코드형 인프라스트럭처

    Infrastructure as code(IaC)는 시스템에서 읽을 수 있는 구성 파일을 통해 인프라를 관리하는 프로세스입니다. IaC는 인프라를 자동화할 수 있는 토대입니다.

    사용자는 서비스를 수동으로 프로비저닝하는 대신, 원하는 리소스를 설명하는 템플릿을 생성할 수 있습니다. 그러면 IaC 플랫폼이 사용자를 대신하여 리소르의 프로비저닝 및 구성을 처리합니다.

    IaC는 인프라를 프로비저닝하기 위한 선언적이고 자동화된 방식을 제공합니다. 이를 통해 사용자는 코드에서와 마찬가지로 인프라에 동일한 도구(예: git) 및 프로세스(예: 코드 검토)를 적용할 수 있습니다.

    AWS 기반 IaC는 일반적으로 CloudFormation 서비스를 사용하여 구현됩니다. CloudFormation을 위해서는 JSON 또는 YAML을 사용하여 리소스를 선언해야 합니다. 이러한 구성 언어를 선호하지 않는 경우, AWS는 JavaScript, Python 및 Java 등의 네이티브 프로그래밍 언어를 사용하여 CloudFormation 템플릿을 작성할 수 있는 Cloud Development Kit(CDK)도 제공합니다.

     

    요점

    • IaC는 시스템이 읽을 수 있는 구성 파일을 통해 인프라를 관리하는 프로세스입니다.
    • IaC는 인프라를 프로비저닝하기 위한 선언적이고 자동화된 방식입니다.
    • 코드와 마찬가지로 동일한 도구와 프로세스를 인프라에 적용할 수 있습니다.
    • CloudFormation 및 CDK와 같은 서비스를 사용하여 AWS에서 IaC를 구현할 수 있습니다.
     

    추가 자료

  • 관찰 기능

    관찰 기능은 시스템의 내부 상태를 측정하는 프로세스입니다. 이러한 측정은 일반적으로 원하는 최종 상태로 최적화하기 위해 수행됩니다.

    운영 우수성과 관련하여 측정하지 않은 사항을 향상할 수는 없습니다. 견고한 관찰 기능의 토대를 구축하면 자동화의 영향을 추적하고 이를 지속적으로 향상할 수 있습니다.

    관찰 기능을 구현하기 위해서는 다음 단계를 따릅니다.

    1. 컬렉션
    2. 분석
    3. 작업


    컬렉션

    컬렉션은 시스템의 상태를 평가하기 위해 필요한 모든 지표를 수집하는 프로세스입니다.

    이러한 지표는 다음 범주에 해당할 수 있습니다.

    • 인프라 수준 지표
      • 이러한 지표는 AWS 서비스에 의해 자동으로 내보내지며 CloudWatch 서비스에 의해 수집됩니다.
      • 일부 서비스는 CloudWatch Logs를 통해 활성화 및 수집이 가능한 구조화된 로그를 내보내기도 합니다.
    • 애플리케이션 수준 지표
      • 이러한 지표는 소프트웨어에 의해 생성되며 CloudWatch 사용자 지정 지표에 의해 수집될 수 있습니다.
      • 소프트웨어 로그는 CloudWatch Logs를 사용하여 저장되거나 S3로 업로드될 수 있습니다.
    • 계정 수준 지표
      • 이러한 지표는 AWS 계정에 의해 기록되며 CloudTrail 서비스에 의해 수집될 수 있습니다.


    분석

    수집한 지표를 분석하려면 AWS가 제공하는 여러 데이터베이스 및 분석 솔루션 중에서 하나를 사용할 수 있습니다.

    적합한 솔루션의 선택은 사용 사례에 따라 달라질 수 있습니다.

    • CloudWatch Logs에 저장된 로그를 분석하려면, CloudWatch 로그 데이터를 대화식으로 검색 및 분석할 수 있는 서비스인 CloudWatch Logs Insight를 사용할 수 있습니다.
    • S3에 저장된 로그를 분석하려면, 서버리스 쿼리 서비스인 Athena를 사용할 수 있습니다.
    • 구조 데이터를 분석하려면, 관리되는 관계형 데이터베이스 서비스인 RDS를 사용할 수 있습니다.
    • 대량의 구조화된 데이터를 분석하려면, 페타바이트 규모의 관리형 데이터 웨어하우스 서비스인 RedShift를 사용할 수 있습니다.
    • 로그 기반 데이터를 분석하려면, 인기 있는 오픈 소스 분석 엔진인 Elasticsearch의 관리형 버전인 Elasticsearch Service를 사용할 수 있습니다.

     

    작업

    지표를 수집 및 분석한 후에는 이를 사용하여 특정 결과 또는 프로세스를 달성할 수 있습니다.

    그러한 결과 및 프로세스의 예는 다음과 같습니다.

    • 모니터링 및 경보
      • CloudWatch Alarms을 사용하면 시스템에서 특정 지표에 대한 안전 임계치가 위반된 경우 경보를 제공할 수 있습니다.
      • 이러한 경보는 수동 또는 자동화된 완화 작업을 트리거할 수 있습니다.
    • 대시보드
      • Cloudwatch 대시보드를 사용하여 지표 대시보드를 생성할 수 있습니다.
      • 이러한 대시보드를 사용하면 시간 경과에 따라 서비스 성능을 추적 및 향상할 수 있습니다.
    • 데이터 중심의 의사 결정
      • 성능 및 비즈니스 KPI를 추적하여 데이터 중심의 의사 결정을 할 수 있습니다.

     

    요점

    • 관찰 기능은 원하는 최종 상태를 달성하기 위해 시스템의 내부 상태를 측정하는 프로세스입니다.
    • 관찰 기능은 지표 수집, 분석 및 작업으로 구성됩니다.
    • 지표는 서비스, 애플리케이션 및 계정 수준에서 수집할 수 있습니다.
    • 지표는 CloudWatch Log Insight, Athena, Elasticsearch Service, RDS 및 Redshift 등의 서비스를 통해 분석할 수 있습니다.
    • 성능 및 비즈니스 KPI를 추적하고 경보 및 대시보드를 모니터링하여 지표와 관련한 작업을 수행할 수 있습니다.

     

    추가 자료

결론

이 모듈에서는 운영 우수성의 주요 사항에 대해 학습했습니다. 그리고 운영을 자동화로 간주하는 멘탈 모델과 IaC 및 IaC를 통해 현재 코드에서 사용하는 동일한 도구 및 프로세스를 사용하여 서비스를 자동으로 프로비저닝하는 방법에 대해서도 학습했습니다. 또한, 관찰 기능과 운영 활동을 지속적으로 향상하기 위해 지표를 수집, 분석 및 처리하는 방법에 대해서도 학습했습니다.

 

추가 자료

비용 최적화

비용 최적화 원칙은 비용을 최소화하는 동시에 비즈니스 결과를 달성할 수 있도록 지원합니다.


멘탈 모델

클라우드에서의 비용 최적화를 고려할 때는 자본 지출(CapEx) 대신 운영 비용(OpEx)의 측면에서 클라우드 비용을 고려하는 것이 유용합니다. 운영 비용은 지속적인 종량 과금제 모델이지만 자본 지출은 일회성 구매 모델입니다.

온프레미스 데이터 센터에서 기존의 IT 비용은 대부분 자본 지출이었습니다. 그러므로 사용 여부와 관계없이 선불로 모든 용량에 대한 비용을 지불합니다. 신규 서버를 구입하는 것은 여러 당사자의 승인이 포함된 장기 프로세스입니다. 왜냐하면 자본 지출 비용이 크고 실수를 하면 많은 비용이 소요되기 때문입니다. 구입한 후에도 실제 서버가 도착하기까지는 몇 주가 소요될 수 있습니다.

AWS에서는 운영 비용 방식을 이용할 수 있습니다. 사용하는 용량에 대한 비용을 계속해서 지불하면 됩니다. 신규 서버 프로비저닝을 위해서는 긴 승인 프로세스가 필요하지 않으며 엔지니어링을 통해 실시간으로 완료될 수 있습니다. 왜냐하면 운영 비용은 훨씬 저렴하며 요구 사항이 변경되는 경우 되돌릴 수 있기 때문입니다. 사용량만큼만 지불하면 되므로 모든 초과 용량을 편리하게 중지 및 종료할 수 있습니다. 서비스를 사용하려면 몇 분 내로 프로비저닝이 완료됩니다.


개념

자본 지출 모델에서 운영 비용 모델로 이동하는 것은 인프라 비용 지출 방식을 근본적으로 바꾸는 것입니다. 대규모의 선불 고정 비용 대신, 소규모의 가변 비용을 지속적으로 지불하게 됩니다.

이러한 사용량에 따라 지불하는 모델로 인해 비용 최적화 프로세스가 다음과 같이 변경됩니다.

  1. 사용량에 따라 지불
  2. 비용 최적화 수명 주기


  • 사용량에 따라 지불

    AWS 서비스는 사용하는 용량에 대해서만 지불하는 사용량에 따라 지불 모델을 제공합니다. 사용량에 따라 지불할 때 클라우드 비용을 최적화하기 위한 일반적인 네 가지 방법은 다음과 같습니다.

    1. 올바른 크기 조정
    2. 서버리스
    3. 예약
    4. 스팟 인스턴스


    올바른 크기 조정

    올바른 크기 조정은 서비스 프로비저닝과 워크로드 구성을 일치시키는 것을 의미합니다. EC2 기반 서비스의 경우, 이는 올바른 인스턴스 크기와 패밀리는 선택하는 것을 의미합니다. 컴퓨팅 리소스가 대부분 유휴 상태인 경우 더 적은 EC2 인스턴스를 사용하는 것을 고려할 수 있습니다. 워크로드에서 대량의 특정 시스템 리소스가 필요한 경우에는 해당 리소스에 최적화된 인스턴스 패밀리로 전환하는 것을 고려할 수 있습니다.

    이러한 프로세스를 지원하기 위해서는 AWS Compute Optimizer를 사용하여 과거 시스템 지표에 따라 최적의 EC2 크기에 대한 추천을 받을 수 있습니다.


    서버리스

    Lambda와 같은 서버리스 기술을 사용하는 경우에는 사용한 만큼만 비용을 지불하게 됩니다. Lambda가 실행되지 않으면 비용이 부과되지 않습니다. 서버리스는 사용량에 따라 지불하는 모델의 가장 좋은 예입니다. 사용 사례에서 허용되는 경우에는 서버리스를 선택하는 것이 서비스 구축을 위한 가장 비용 대비 효율적인 방식입니다.


    예약

    예약 요청은 상당한 할인을 받고 특정 용량에 대한 금액을 지불하는 것을 의미합니다. EC2의 경우, 예약을 요청하면 컴퓨팅 용량에 대해 최대 72% 할인을 받을 수 있습니다.

    컴퓨팅 용량을 예약하려면, Savings Plans를 사용할 수 있습니다. 1~3년의 기간 동안 특정 컴퓨팅 용량을 사용하도록 계약을 체결하면 EC2, Fargate 및 Lambda 모두에 대한 할인을 받을 수 있습니다.

    EC2뿐만 아니라 RDS, DynamoDB 및 CloudFront 등 기타 서비스에 대해서도 예약을 요청할 수 있습니다.


    스팟 인스턴스

    EC2 스팟 인스턴스를 사용하면 온디맨드 요금에 비해 최대 90% 할인된 비용으로 미사용 EC2 용량을 활용하여 인스턴스를 실행할 수 있습니다. 이를 통해 내결함성 워크로드에 커다란 할인이 제공됩니다.

    스팟 인스턴스를 사용할 때의 트레이드오프는 EC2가 언제든 용량을 회수할 수 있다는 것입니다. 회수되는 경우 애플리케이션에는 2분 종료 통지가 제공됩니다.


    요점

    • AWS 서비스는 사용량에 따라 과금되므로 사용하는 용량에 대한 비용이 청구됩니다.
    • 올바른 크기의 인스턴스를 사용하면 워크로드와 일치하지 않는 서비스에 대한 비용을 절감할 수 있습니다.
    • 서버리스 기술을 사용하여 고객이 서비스를 이용할 때만 비용을 지불할 수 있습니다.
    • 예약을 사용하면 선불 계약의 대가로 할인이 제공됩니다.
    • 스팟 인스턴스를 사용하면 내결함성 워크로드 실행에 대한 할인을 받을 수 있습니다.


    추가 자료

  • 비용 최적화 수명 주기

    비용 최적화 수명 주기는 시간 경과에 따른 클라우드 비용을 향상하는 연속 프로세스입니다.

    여기에는 다음의 세 워크플로가 포함됩니다.

    1. 검토
    2. 추적
    3. 최적화


    검토

    클라우드 비용을 최적화하기 전, 우선 비용이 어디에서 발생하는 지를 파악해야 합니다.

    AWS Cost Explorer를 사용하면 시간 경과에 따른 클라우드 비용을 시각화 및 검토할 수 있습니다. 서비스 및 범주 등 다양한 패싯에 대한 비용을 분석할 수 있습니다. Cost Explorer를 사용하면 높은 수준의 개요뿐만 아니라 청구서에 대한 자세한 보고서를 받아 볼 수 있습니다.

    보다 자세한 데이터가 필요한 경우에는 AWS 비용 및 사용 보고서를 통해 시간별 품목을 확인할 수 있습니다.


    추적

    전체 클라우드 비용에 대한 개략적인 정보를 확인한 후에는 관심이 있는 차원을 그룹화할 수 있습니다. 이 작업은 비용 할당 태그를 사용하여 수행할 수 있습니다. 추적할 각 태그에 대하여 이 기능을 켜야 합니다.

    태그 범주의 일반적인 예는 다음과 같습니다.

    • 애플리케이션 ID - 비용 변경 사항 및 프로젝트 종료 시 끄기를 편리하게 추적할 수 있도록 특정 애플리케이션과 관련이 있는 리소스를 식별합니다.
    • 자동 옵트인/옵트아웃 - 시작, 중지 또는 크기 조정 인스턴스 등 자동화된 활동에 리소스가 포함되어야 하는지를 나타냅니다.
    • 비용 센터/비즈니스 단위 - 일반적으로 비용 할당 및 추적을 위해 리소스와 연결된 비용 센터 또는 비즈니스 단위를 식별합니다.
    • 소유자 - 리소스의 책임자를 식별합니다. 일반적으로는 기술 소유자입니다. 필요한 경우에는 별도의 비즈니스 소유자 태그를 추가할 수 있습니다. 소유자는 이메일 주소로 지정할 수 있습니다. 이메일 주소를 사용하면 필요한 경우(예: 리소스가 탄력성 또는 올바른 크기 조정의 후보인 경우) 기술 및 비즈니스 소유자 모두에게 자동화된 알림을 제공할 수 있습니다.

    태그뿐만 아니라 AWS 예산을 사용하여 예산 목표를 생성할 수도 있습니다. 예산을 사용하면 관심이 있는 차원 모두에서 비용을 모니터링할 수 있습니다. 예산은 적용한 필터에 따라 현재 AWS 비용에 대한 예측을 추적 및 생성합니다.


    최적화

    비용을 검토 및 추적한 후에는 최적화할 수 있습니다. 비용 최적화는 사용량에 따라 지불에서 설명된 기술을 구현하는 것이 포함됩니다. 이러한 최적화는 주로 포괄적인 예산 목표의 일환으로 수행됩니다.

    최적화 목표의 예는 다음과 같습니다.

    • 비용 Savings Plan에서 보장되는 EC2 인스턴스의 비율 - 80~90%의 범위를 목표로 해야 합니다.
    • 유휴 리소스의 비율 - 유휴 및 정확한 비율의 정의는 비즈니스에 따라 다를 수 있습니다.


    요점

    • 비용 최적화 수명 주기는 연속 프로세스로 시간 경과에 따른 클라우드 비용을 향상합니다.
    • 비용 최적화 수명 주기는 비용 검토, 추적 및 최적화로 구성됩니다.
    • 비용 검토에서는 비용을 파악하기 위해 Cost Explorer와 비용 및 사용 보고서와 같은 도구를 사용할 수 있습니다.
    • 비용 추적에서는 비즈니스와 관련이 있는 차원에서 데이터를 필터링하기 위해 비용 할당 태그 및 예산을 사용할 수 있습니다.
    • 비용 최적화에서는 포괄적인 예산 목표의 일환으로 이전 섹션에서 설명된 기술을 사용할 수 있습니다.


    추가 자료

결론

이 모듈에서는 비용 최적화의 주요 사항에 대해 학습했습니다. 클라우드 비용에 운영 비용 중심 모델을 적용하는 것에 대해 학습했습니다. 그리고 올바른 크기 조정, 서버리스, 예약 및 스팟 인스턴스 등 비용 최적화 기법에 대해서도 학습했습니다. 또한, Cost Explorer, 태그 및 예산과 같은 서비스를 사용한 예산의 검토, 추적 및 최적화에 대해서도 학습했습니다.

 

추가 자료

AWS GovCloud(미국)

이 섹션은 워크로드가 FedRAMP, DoD SRG, ITAR, CJIS 또는 기타 엄격한 규정 준수 요구 사항을 충족해야하거나, Controlled Unclassified Information (CUI)로 분류 된 데이터를 포함하는 사용자를 위한 것입니다.

AWS GovCloud (미국)는 연방, 주, 지방 차원의 항공 우주, 방위 제조, 법 집행, 의료, 금융 서비스, 에너지 및 기타 엄격하게 규제되는 산업의 미국 상업 조직에서 미국 정부 기관의 특정 규정 준수 및 규제 요구 사항을 해결하도록 돕습니다. 클라우드에서 민감한 데이터와 규제 된 워크로드를 호스팅하도록 설계된 AWS GovCloud (미국) 리전은 미국내에서 미국 시민이 운영하는 격리된 AWS 리전입니다.

AWS GovCloud (미국)는 정부 고객과 파트너에게 FedRAMP High 기준 the DOJ’s Criminal Justice Information Systems (CJIS) Security Policy; U.S.을 준수하는 보안 클라우드 솔루션을 설계 할 수 있는 유연성을 제공합니다. 국제 무기 거래 규정 (ITAR); 수출 관리 규정 (EAR); 영향 레벨 2, 4, 5에 대한 국방부 (DoD) 클라우드 컴퓨팅 보안 요구 사항 안내서 (SRG); FIPS 140-2; IRS-1075; 및 다른 준수 체제.

AWS GovCloud (미국) 리전은 고객이 CUI (Controlled Unclassified Information), PII (Personally Identifiable Information), 민감한 환자 의료 기록 및 재무 데이터에서 법 집행 데이터, 수출 통제 데이터 및 기타 형태의 CUI에 이르기까지 모든 고객이 규정 준수 문제를 해결할 수 있도록 모든 단계에서 클라우드 여정을 도와줍니다.

 

추가 자료

축하합니다!

AWS 기초 과정을 이수하셨습니다. 이 과정에서 학습한 사항은 다음과 같습니다.

  • AWS Well-Architected 프레임워크의 5대 원칙이 무엇입니까?
  • 5대 원칙에 대한 클라우드 네이티브적인 사고 방식을 나타내는 중요 멘탈 모델
  • 각 5대 원칙의 주요 개념

지금까지 클라우드에서의 보안, 성능 효율성, 안정성, 운영 우수성 및 비용에 최적화된 서비스를 구축하기 위한 기초에 대해 학습했습니다. 아직은 알아야 할 사항을 표면적으로만 살펴봤지만, 나머지 AWS 여정을 시작하기 위한 견고한 토대를 갖추게 되었습니다. 이제 AWS 기초 과정을 완료했으므로 학습한 내용을 적용하여 우수한 AWS 기반 서비스를 구축하는 방법에 대해 알아보겠습니다.