AWS

5대 원칙

1. 보안

클라우드에서 인프라를 보호하는 방법에 중점. (보안과 규정 준수는 AWS와 고객의 공동 책임)

• AWS는 특히 클라우드의 보안에 대한 책임이 있다. (물리적 인프라, 소프트웨어 및 네트워킹 기능)
• 고객은 클라우드에서의 보안에 대한 책임이 있다. (특정 클라우드 서비스의 구성, 애플리케이션 소프트웨어 및 민감한 데이터 관리)
• 🔎 워크로드가 FedRAMP, DoD SRG, ITAR, CJIS 또는 기타 엄격한 규정 준수 요구 사항을 충족해야하거나, CUI(Controlled Uncalssified Information)로 분류된 데이터가 포함 된 경우, AWS GovCloud(미국)섹션을 참조.

멘탈모델

클라우드에서의 보안을 고려할 때는 제로 트러스트 모델을 도입하는 것이 유용하다.
👉🏻 이 모델에서 모든 애플리케이션 구성 요소 및 서비스는 별개이며 잠재적으로 악의적인 Entity로 간주된다. 그리고 기반 네트워크 패브릭, 리소스에 액세스하는 모든 에이전트 및 서비스 내부에서 실행되는 소프트웨어가 포함됨.

개념

제로 트러스트의 관점에서 보안은 모든 시스템 수준에 보안 조치를 적용하는 것을 의미.
클라우드에서 제로 트러스트를 적용하여 시스템 보안을 수행하는 것과 관련된 세 가지 주요 개념은 다음과 같다.
1. Identity and Access Management(IAM) : 시스템에서 ID 및 액세스를 추적하는 서비스.
1. 주체 : 권한이 제공되는 대상을 지정한다.
2. 작업 : 수행되는 것을 지정한다.
3. 리소스 : 액세스되는 속성을 지정한다.
2. 네트워크 보안 : 네트워크 및 네트워크에 액세스할 수 있는 리소스의 액세스 및 사용성을 보호하는 시스템, 구성 또는 프로세스가 포함된다.
네트워크 보안에 대한 제로 트러스트 접근법에는 네트워크의 모든 레이어에 보안 제어를 적용하는 심층적 방어 접근법이 포함된다.
3. 데이터 암호화 : 데이터에 제로 트러스트 모델을 적용하는 것은 모든 곳에 있는 전송 중 및 저장 중 데이터 모두를 암호화 하는것.

2. 성능 효율성

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

개념

서버 관리의 여러 워크로드에 대하여 동일한 유형의 서버를 사용하는 것이 매우 일반적이며 이로 인해 다른 시스템을 주문하고 프로비저닝하는 것이 매우 번거롭다.
그러나, 클라우드에서는 프로비저닝이 빠르고 저렴하며 워크로드와 가장 알치하는 서버 유형을 자유롭게 선택할 수 있고 서비스를 확장하는 것도 편리하다.(모든 서버가 호환되고 빠르게 배포할 수 있으므로, 더 많은 서버를 추가하여 용량을 빠르게 확장할 수 있다.)

1. 셀렉트 : 워크로드에 가장 적합한 서비스를 선택할 수 있는 기능
2. 확장 : 적합한 서비스를 선택하는 것은 시작을 위한 핵심이지만 확장 방법을 선택하는 것은 지속적인 성능에 중요하다
   1. 수직 확장 : 기본 컴퓨팅을 더 큰 규모의 인스턴스 유형으로 업그레이드하는 것이 포함됨.
      클러스터화할 필요가 없어 일반적으로 구현이 편리하다. 단점은 수직 확장에 비해 실행의 상한이 매우 낮다. 도한, 인스턴스 중단으로 인해 서비스를 완전히 사용할 수 없게 될 수 있으므로 단일 장애점이 될 수 있다.
   2. 수평 확장 : 기본 인스턴스의 수 증가가 포함됨.
      수평 확장을 위해서는 서비스 플릿으로 서비스의 경로를 지정하기 위한 프록시 서버가 필요하기 떄문에 구현 측면에서 추가적인 오버헤드가 필요하다. 또한, 라우팅 풀에서 불량 인스턴스를 제거하기 위한 상태 확인을 수행하고 워크로드에 가장 적합한 특정 라우팅 알고리즘도 선택해야한다.
      그 대신, 수직 확장에 비해 서비스의 복원력이 크게 향상되고 확장성이 매우 증가한다.

3. 안정성

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

멘탈 모델

파급 범위를 고려해라
👉🏻 파급 범위는 시스템 장애 발생 시 지속될 수 잇는 최대 영향으로 생각할 수 있다. 신뢰할 수 있는 서비스를 구축하려면 개별 구성 요소의 파급 범위를 최소화해야 한다.

개념

파급 범위의 관점에서 고려할 떄, 장애 문제는 가능성의 문제가 아니라 시점의 문제임.

• 장애 발생 시 파급 범위를 제한하기 위한 기법
  • 장애 격리 : 장애 격리 영역으로 구분되는 중복된 독립 구성 요소를 사용하여 문제의 파급 범위를 제한함.
    장애 격리 영역에는 장애 격리 영역 내 영역에 대한 장애의 영향이 포함된다.
  • 한도 : 과도한 부하로부터 서비스를 보호하기 위해 적용될 수 있는 제약.
    한도는 외부 및 내부 문제로 인한 파급 범위를 제한하기 위한 효과적인 수단이다.

4. 운영 우수성

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

멘탈 모델

자동화 측면에서 생각해라.
인적 오류는 결함 및 운영 문제의 주된 원인이다. 운영이 자동화될 수록 인적 오류가 발생할 가능성이 줄어든다.
자동화를 통해 오류가 방지될 뿐만 아니라 내부 프로세스가 지속적으로 향상될 수도 있다. 자동화는 전체 조직에서 적용될 수 있는 반복 가능한 모범 사례집합을 향상한다.

개념

• 운영 우수성에서 중점을 두는 두 가지 개념

1. 코드형 인프라스트럭처(Infrastructure as code) : 시스템에서 읽을 수 있는 구성 파일을 통해 인프라를 관리하는 프로세스.
   1. 사용자는 서비스를 수동으로 프로비저닝하는 대신, 원하는 리소스를 설명하는 템플릿을 생성할 수 있다. (IaC 플랫폼이 사용자를 대신해 리소스의 프로비저닝 및 구성을 처리)
   2. IaC는 인프라를 프로비저닝하기 위한 선언적이고 자동화된 방식을 제공함
2. 관찰 기능 : 시스템의 내부 상태를 측정하는 프로세스. 👉🏻 일반적으로 원하는 최종 상태로 최적화하기 위해 수행된다.
   1. 컬렉션 : 시스템의 상태를 평가하기 위해 필요한 모든 지표를 수집하는 프로세스.
   2. 분석 : 수집한 지표 분석을 위해 AWS가 제공하는 여러 DB 및 분석 솔루션 중에서 하나를 사용할 수 있다.
   3. 작업 : 분석 이후에 이를 사용하여 특정 결과 또는 프로세스를 달성함

5. 비용 최적화

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

멘탈 모델

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

개념

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

• 사용량에 따라 변경되는 비용 최적화 프로세스

1. 사용량에 따라 지불 : 사용하는 용량에 대해서만 지불하는 '사용량에 따라 지불' 모델을 제공함
   1. 바용을 최적화하기 위한 방법
      1. 올바른 크기 조정
      2. 서버리스
      3. 예약
      4. 스팟 인스턴스 : EC2 스팟 인스턴스를 사용하면 온디멘드 요금에 비해 최대 90% 할인된 비용으로 미사용 EC2 용량을 활용하여 인스턴스를 실행할 수 있다.
2. 비용 최적화 수명 주기 : 시간 경과에 따른 클라우드 비용을 향상하는 연속 프로세스