AWS Cloud Practitioner Essentials (Introduction)

클라우드 컴퓨팅

1. 클라이언트–서버 모델 (Client–Server Model)

개념

• 클라이언트(Client): 요청을 보내는 주체 (사용자, 브라우저, 앱)
• 서버(Server): 요청을 처리하고 응답을 반환하는 주체

흐름

Client → Request → Server → Response → Client

AWS 관점

• 서버는 물리 서버가 아닌 가상 서버
• 필요에 따라 생성·확장·삭제 가능

포인트

• 모든 클라우드 아키텍처의 출발점
• EC2, Lambda, API Gateway 등은 전부 이 모델의 확장

---

2. 클라우드는 “단일 서버”가 아니라 “확장된 구조”

현실의 애플리케이션

• 단일 서버 + 단일 요청 ❌
• 다수의 요청, 다수의 사용자, 복잡한 처리 ⭕
• 컴퓨팅·스토리지·네트워크가 분리되어 조합됨

의미

• 클라우드는 기본 개념 위에 복잡한 구조를 단계적으로 쌓는 방식
• 단순한 서버 개념을 이해해야 고급 아키텍처 이해 가능

---

3. 사용한 만큼만 지불 (Pay-As-You-Go)

핵심 개념

• 선불 비용 없음
• 사용한 리소스만 비용 발생
• 사용 안 하면 비용도 0

온프레미스와 차이

필요할 때 즉시 생성, 유휴 자원 없음, 필요할 때 즉시 확장 가능

---

4. 탄력적 프로비저닝 (Elastic Provisioning)

개념

• 리소스를 필요할 때 즉시 생성
• 필요 없어지면 즉시 해제

특징

• 자동화 가능
• 수요 변동에 유연하게 대응
• 사람이 직접 관리할 필요 감소

관점

• Auto Scaling
• 서버리스(Lambda)
• “운영 오버헤드 최소화” 문제의 핵심 배경

---

5. 용량 계획의 패러다임 변화

기존 방식

• 최대 트래픽 예상 → 미리 서버 확보
• 대부분 시간은 낭비

AWS 방식

• 실제 트래픽 기준으로 동적 확장
• 바쁠 때 ↑ / 한가할 때 ↓
• 비용 효율 극대화

---

6. AWS의 정체성

• AWS는
  • 전 세계적으로 가장 널리 사용되는 클라우드
  • 컴퓨팅, 스토리지, 데이터베이스, 네트워크 등 모든 IT 자원을 서비스로 제공
• 목적:
  • 민첩성 향상
  • 비용 절감
  • 빠른 혁신

---

7. 지금 단계에서 반드시 기억할 3문장

1. 클라우드는 클라이언트–서버 모델을 기반으로 한다
2. AWS는 사용한 만큼만 비용을 지불한다
3. 필요한 리소스를 즉시 만들고, 필요 없으면 바로 없앨 수 있다

클라우드는 ‘요청–응답 구조 위에서 리소스를 필요할 때 쓰고, 쓴 만큼만 비용을 내는 시스템’이다.

---

연결 포인트

• “비용을 최소화해야 한다” → Pay-As-You-Go, Serverless
• “트래픽이 예측 불가하다” → Auto Scaling, Elasticity
• “운영 인력이 적다” → 관리형 서비스, 서버리스

---

클라우드 컴퓨팅 & AWS 핵심 개념

1. AWS가 탄생한 배경

문제 상황 (Amazon 내부)

• 사용자 증가 → 서버·스토리지·컴퓨팅 지속적 증설 필요
• 배포·운영 부담 증가
• 확장성과 효율성의 한계 발생

해결

• 내부 IT 문제 해결을 위해
  • 표준화된 도구
  • 자동화 메커니즘
  • 확장 가능한 인프라 방식
    개발

이 내부 솔루션이 외부 기업에도 유용하다는 인식으로 이어짐

---

2. AWS의 시작과 초기 서비스

초기 타임라인

• 2004: Amazon SQS (메시지 큐)
• 2006:
  • Amazon S3 (스토리지)
  • Amazon EC2 (컴퓨팅)

순서 중요

• 큐 → 스토리지 → 컴퓨팅
• “확장성·비동기·온디맨드” 중심

의미

• AWS는 처음부터 대기업용이 아니라
  • 스타트업
  • 개발자
    중심으로 성장

---

3. 클라우드 컴퓨팅의 공식적 정의

클라우드 컴퓨팅이란 종량제 요금으로 인터넷을 통해 IT 리소스를 온디맨드로 제공하는 것이다

---

4. 온디맨드(On-Demand) IT 리소스

의미

• 필요할 때 즉시 생성
• 필요 없어지면 즉시 제거
• 사전 계획·선구매 불필요

예시 (S3)

• 스토리지 2,000TB 필요
  • 계정 생성 → 즉시 사용
• 필요 없어짐
  • 삭제 → 요금 즉시 중단

리소스 사용 시간 = 비용 발생 시간

---

5. 종량제 요금(Pay-As-You-Go)

핵심 포인트

• 선불 ❌
• 장기 계약 ❌
• 사용한 만큼만 결제 ⭕

“비용 최소화” 문제의 기본 전제

---

6. 데이터 센터 개념 (기초지만 중요)

데이터 센터란?

• 서버들이 모여 있는 시설
• 포함 요소:
  • 전원 이중화
  • 냉각
  • 물리적 보안

과거 방식

• 자체 데이터 센터(On-Prem)
• 공동 배치(Co-location)

AWS 이후

• 기업이 소유하지 않은 데이터 센터 사용
• 인프라 관리 책임 ↓
• 운영 부담 ↓

AWS = 데이터 센터를 서비스로 제공

---

7. 클라우드의 가장 큰 비즈니스 가치

이전

• 인프라 관리에 시간 소모
• 반복 작업 많음
• 확장·축소 느림

클라우드 이후

• 인프라 관리 최소화
• 반복 작업 제거
• 팀이 혁신에 집중 가능

---

8. 인터넷 기반 접근 (Remote Access)

의미

• 위치 무관
• 브라우저로 접근
• 글로벌 사용 가능

---

9. 프로비저닝 & 해제 (Provision / Deprovision)

개념

• 필요 → 즉시 생성
• 불필요 → 즉시 제거
• 부분 단위로 가능

장점

• 계약 ❌
• 영업 절차 ❌
• 클릭/자동화로 처리 ⭕

---

10. 핵심 5문장

1. AWS는 Amazon 내부 IT 문제 해결에서 시작되었다
2. 클라우드는 온디맨드 + 종량제 모델이다
3. 사용한 리소스만 비용을 지불한다
4. 인프라 관리 부담이 줄어든다
5. 팀은 운영이 아니라 비즈니스 혁신에 집중할 수 있다

---

클라우드 배포 유형

클라우드, 온프레미스, 하이브리드 등 다양한 방법으로 클라우드 리소스를 배포할 수 있습니다. 각 유형은 고유한 이점과 고려 사항이 있으며, 이러한 옵션을 살펴보면 풍부한 정보를 토대로 클라우드 전략에 대한 결정을 내리는 데 도움이 됩니다.

클라우드

클라우드 기반 배포 모델의 경우 기존 리소스를 클라우드로 마이그레이션하고, 클라우드 환경 내에서 새로운 애플리케이션을 설계 및 구축할 수 있을 뿐만 아니라, 이 방법들을 모두 조합하여 사용할 수 있는 유연성이 있습니다.
예를 들어 기업은 데이터 리소스를 클라우드로 마이그레이션한 다음, 클라우드에서 전체가 호스팅되는 가상 서버, 데이터베이스, 네트워킹 구성 요소로 이루어진 애플리케이션을 개발할 수 있습니다.

온프레미스

가상화 및 리소스 관리 도구를 사용하여 온프레미스로 리소스를 배포하는 방법은 클라우드 컴퓨팅의 많은 이점을 제공하지 못합니다. 그러나 전용 리소스를 제공하고 지연 시간을 단축할 수 있는 기능이 필요한 경우가 간혹 있습니다.
대부분의 경우 이러한 배포 모델은 리소스 활용도를 높이기 위해 애플리케이션 관리 및 가상화 기술을 사용한다는 점에서 레거시 IT 인프라와 같습니다.

하이브리드

하이브리드 배포의 경우 클라우드 기반 리소스와 온프레미스 인프라가 함께 작동합니다. 이러한 접근 방식은 유지 관리 기본 설정이나 규제 요구 사항으로 인해 레거시 애플리케이션을 온프레미스에 유지해야 하는 상황에 적합합니다.
예를 들어 기업은 고급 데이터 처리 및 분석을 위해 클라우드 서비스를 사용하는 동시에, 규제 대상인 특정한 레거시 애플리케이션을 온프레미스로 유지하도록 선택할 수 있습니다.
멀티 클라우드 배포는 하이브리드 배포로도 간주할 수 있습니다.

Q: 이 단체는 규정 준수를 위해 해당 국가 내에 유지해야 하는 민감한 데이터를 보유하고 있습니다. 그러나 계절별 수요 스파이크를 처리하려면 신속하게 규모를 조정할 수 있는 솔루션도 필요합니다. 규정 준수를 위해 온프레미스 리소스를 유지하고, 동적 스케일링을 위해 클라우드 기반 리소스를 사용하기로 결정합니다. 이 상황에서 설명하는 클라우드 배포방식은?

A: 하이브리드 배포

온프레미스 솔루션은 동적스케일링 요구를 만족하지 못하고, 퍼블릭 클라우드는 초기 비용 감소와 확장성은 띄어나지만 민감 데이터를 해당 국가에 보관하기 위한 규정은 준수하지 못한다. 하이브리드 클라우드 솔루션을 사용하면 민감 데이터는 온프레미스로 유지하고, 동적 스케일링에 클라우드 기반 리소스를 이용할 수 있다.

---

AWS 클라우드의 6가지 핵심 이점

1. 고정 비용을 가변 비용으로 전환
2. 규모의 경제로 비용 절감
3. 용량 추정이 필요 없음
4. 속도와 민첩성 향상
5. 데이터 센터 운영 불필요
6. 몇 분 만에 전 세계 배포

1. 고정 비용 → 가변 비용 (CapEx → OpEx)

핵심 개념

• 온프레미스:
  서버·공간·인력에 선투자(고정 비용) 필요
• AWS:
  사용한 만큼만 지불(가변 비용)

효과

• 초기 투자 부담 없음
• 소규모로 시작 가능
• 비용을 실제 사용량과 연동 가능

---

2. 규모의 경제 (Economies of Scale)

핵심 개념

• Amazon Web Services는 전 세계 데이터 센터를 대규모로 운영
• 하드웨어를 대량 구매 → 단가 하락
• 절감된 비용을 고객에게 환원

효과

• 스타트업도 대기업 수준 인프라 사용 가능
• 고급 기술의 진입 장벽 감소

---

3. 용량 추정 불필요 (No Capacity Guessing)

기존 문제

• 과다 추정 → 비용 낭비
• 과소 추정 → 성능 저하 / 고객 이탈

AWS 방식

• 필요할 때 즉시 프로비저닝
• 실시간 수요에 따라
  • Scale up
  • Scale down

효과

• 낭비 없음
• 성능 안정성 확보

연결

• Auto Scaling
• Elasticity

---

4. 속도 및 민첩성 향상 (Speed & Agility)

핵심 개념

• 리소스 생성/삭제가 분 단위
• 실험 → 실패 → 즉시 제거 가능

효과

• 테스트/실험 비용 부담 ↓
• 제품 출시 속도 ↑
• 혁신 시도 가능성 ↑

---

5. 데이터 센터 운영 불필요

기존

• 서버 설치
• 랙 구성
• 전원·냉각·보안 관리
• 유지보수 인력 필요

AWS

• 물리 인프라는 AWS가 관리
• 고객은 애플리케이션에만 집중

효과

• 운영 오버헤드 감소
• 인력·시간을 핵심 비즈니스에 재배치

---

6. 몇 분 만에 글로벌 배포 (Go Global in Minutes)

핵심 개념

• 전 세계 여러 리전에
  애플리케이션 즉시 배포 가능

기존

• 해외 진출 = 현지 데이터 센터 구축
• 수개월~수년 소요

AWS

• 리전 선택 → 배포
• 수 분 내 글로벌 서비스 가능

AWS 클라우드는 비용·확장·속도·운영·글로벌 측면에서 기존 IT 인프라의 한계를 제거한다.

---

AWS 글로벌 인프라 

1. 왜 글로벌 인프라가 필요한가

단일 데이터 센터의 문제

• 정전
• 자연재해
• 네트워크 장애

한 곳에 모든 리소스를 두면, 한 번의 장애로 전체 서비스 중단

그래서 AWS는 고가용성(High Availability) 과 내결함성(Fault Tolerance) 을 전제로 인프라를 설계함.

---

2. 고가용성(High Availability)

정의

• 가동 중지 시간을 최소화
• 장애가 발생해도 서비스 접근 가능 상태 유지

핵심 아이디어

• 한 구성 요소가 실패해도
• 다른 구성 요소가 즉시 대체

---

3. 내결함성(Fault Tolerance)

정의

• 여러 구성 요소가 동시에 실패해도
• 시스템이 계속 동작하도록 설계

고가용성과의 차이

• 고가용성: 장애 발생 시 빠른 대체
• 내결함성: 장애가 발생해도 영향이 거의 없음

Fault Tolerance ⊃ High Availability

---

4. AWS 글로벌 인프라 구조

AWS Global Infrastructure
 └── Region
      └── Availability Zone (AZ)
           └── Data Center

리전은 여러 개의 격리된 데이터 센터가 포함된 전 세계의 물리적 위치입니다. 
가용 영역은 각각 독립적인 전력, 네트워킹, 연결 기능을 갖춘 1개 이상의 개별 데이터 센터로 구성됩니다.

---

5. AWS 리전 (Region)

정의

• 전 세계의 물리적으로 분리된 지리적 위치
• 예:
  • 도쿄
  • 파리
  • 더블린
  • 오하이오
  • 상파울루

특징

• 고객과 가까운 위치 → 낮은 지연 시간
• 리전 간 물리적으로 완전히 분리

포인트

• 리전 장애 = 대규모 장애
• 재해 복구(DR)는 다중 리전 전략

---

6. 가용 영역 (Availability Zone, AZ)

정의

• 하나 이상의 데이터 센터 묶음
• 독립적인 전력, 네트워크, 연결성 보유

구조적 특징

• 한 리전당 최소 3개 이상의 AZ
• AZ끼리는 물리적으로 떨어져 있음
  • 자연재해 동시 영향 방지

핵심 장점

• AZ 하나가 장애 나도
• 다른 AZ에서 서비스 지속 가능

---

7. 데이터 센터 (Data Center)

특징

• 중복 전원
• 중복 네트워크
• 물리적 보안

데이터 센터 단위에서도 이중화 설계

---

8. 고가용성을 달성하는 AWS 설계 원칙

필수 원칙

• 리소스를 여러 AZ에 분산
• 단일 장애 지점(SPOF) 제거

효과

• AZ 하나 중단 → 서비스 지속
• 사용자 영향 최소화

---

9. 다중 리전(Multi-Region) 전략

왜 필요?

• 리전 전체 장애 대비
• 국가/대륙 단위 재해 대응

효과

• 한 리전 장애 → 다른 리전으로 장애 조치(Failover)

---

10. 핵심 문장

1. AWS는 고가용성과 내결함성을 고려해 설계됨
2. 리전은 지리적으로 분리된 위치
3. 각 리전은 최소 3개 이상의 AZ로 구성
4. AZ는 독립된 전력·네트워크를 가짐
5. 리소스를 여러 AZ에 분산하면 가용성이 향상됨

AWS 글로벌 인프라는 리전 → AZ → 데이터 센터 구조로 고가용성과 내결함성을 보장한다.

---

출처: skillbuilder.aws

AWS 공동 책임 모델 (Shared Responsibility Model) 

AWS는 ‘클라우드 자체의 보안’을 책임지고, 고객은 ‘클라우드 내부의 보안’을 책임진다.

---

1. AWS의 책임 (Security OF the Cloud)

AWS가 무조건 책임지는 영역이다.

포함 범위

• 물리적 데이터 센터
• 하드웨어
• 글로벌 인프라
• 네트워킹 장비
• 하이퍼바이저(가상화 계층)

핵심 포인트

• 고객은 물리 서버에 접근 불가
• 고객 간 워크로드는 완전히 격리
• 전원, 냉각, 물리적 보안은 AWS 책임

이 영역은 고객이 선택하거나 설정할 수 없다

---

2. 고객의 책임 (Security IN the Cloud)

고객이 반드시 책임져야 하는 영역이다.

포함 범위

• 데이터
  • 저장 데이터
  • 접근 권한
  • 공개 여부
• 클라이언트 측 암호화
• IAM
  • 사용자
  • 역할
  • 권한 관리
• 애플리케이션 보안
• 운영체제(OS) 패치 (EC2 사용 시)

핵심 포인트

• AWS는 고객 OS에 접근 불가
• 키 관리 책임은 고객
• 데이터 공개 사고의 대부분은 고객 설정 실수

---

3. 공동 책임 영역 (서비스에 따라 달라짐)

서비스에 따라 달라지는 항목

• 서버 측 암호화
• 네트워크 트래픽 보호
• OS 관리 여부
• 방화벽 설정
• 플랫폼 관리

예시

• EC2 → OS는 고객 책임
• Lambda → OS는 AWS 책임
• RDS → DB 엔진은 AWS, 데이터는 고객

관리형 서비스일수록 고객 책임 ↓

---

4. 서비스별 책임 변화

| 서비스 유형            | 고객 책임                 | AWS 책임          |
| ------------------- | ----------------------- | ---------------- |
| EC2 (IaaS)          | OS, 패치, 방화벽, 앱, 데이터 | 하드웨어, 네트워크   |
| RDS (PaaS)          | 데이터, 계정, 접근 제어      | OS, DB 엔진       |
| Lambda (Serverless) | 코드, 데이터, IAM          | OS, 런타임, 서버   |

Serverless일수록 고객 책임은 ‘데이터 + 권한’만 남는다

---

5. 비유

• AWS: 집의 벽, 지붕, 자물쇠 자체
• 고객: 문을 잠그는 행위, 누구에게 열쇠를 줄지 결정

AWS는 문을 대신 잠가주지 않는다.

---

6. 판단 공식

• “이게 물리 인프라/가상화냐?” → AWS 책임
• “이게 데이터/권한/설정/OS냐?” → 고객 책임
• “관리형 서비스냐?” → 고객 책임 ↓

AWS는 클라우드를 안전하게 만들고, 고객은 클라우드를 안전하게 사용한다.

---

클라우드 컴퓨팅이란?(opens in a new tab)	클라우드 컴퓨팅의 기본 사항에 대해 자세히 알아봅니다.
AWS 공동 책임 모델(opens in a new tab)	AWS 공동 책임 모델에 대해 자세히 알아봅니다.
리전 및 가용 영역(opens in a new tab)	전체 AWS 리전 목록을 확인합니다.