AWS 개념 정리

🌱 오늘의 주제  :  AWS 개념 정리

 

 

 

• 도메인 1: 보안 아키텍처 설계(채점 대상 콘텐츠의 30%)
• 도메인 2: 복원력을 갖춘 아키텍처 설계(채점 대상 콘텐츠의 26%)
• 도메인 3: 고성능 아키텍처 설계(채점 대상 콘텐츠의 24%)
• 도메인 4: 비용에 최적화된 아키텍처 설계(채점 대상 콘텐츠의 20%)

 

 

 

Direct Connect

 

🌱 AWS 개념 정리

---

 

• Amazon CloudFront : 고속 콘텐츠 전송 네트워크 (CDN, Content Delivery Network) 서비스이다. 웹 콘텐츠를 빠르게 전송한다. S3의 웹 사이트 호스팅 기능으로 구축한 웹 서버와 조합하여 많이 사용한다.
• AnyCompany의 애플리케이션이 여러 Amazon EC2 인스턴스에서 실행 중이라고 가정하겠습니다. 이러한 인스턴스는 Application Load Balancer에 연결되는 Auto Scaling 그룹에 포함되어 있습니다. 
• 고객이 AnyCompany의 웹 사이트로 이동하여 애플리케이션에서 데이터를 요청합니다.
• Amazon Route 53는 DNS 확인을 사용하여 AnyCompany.com의 IP 주소인 192.0.2.0을 식별합니다. 이 정보는 고객에게 다시 전송됩니다.

고객의 요청은 Amazon CloudFront를 통해 가장 가까운 엣지 로케이션으로 전송됩니다. 

Amazon CloudFront는 수신 패킷을 Amazon EC2 인스턴스로 전송하는 Application Load Balancer에 연결됩니다.

 

 

 

 

 

 

 

• AWS 클라우드로 마이그레이션하는 과정은 기존의 온프레미스 환경 또는 다른 클라우드 환경에서 AWS로 워크로드와 데이터를 이전하는 것을 의미합니다. 이 과정은 신중한 계획과 여러 단계로 구성되며, AWS에서 제공하는 다양한 도구와 서비스들을 활용할 수 있습니다. 마이그레이션 과정은 크게 다음의 단계로 나뉩니다:
  1. 평가 및 계획 (Assess and Plan)
     • 현재 환경 평가: 기존 인프라와 애플리케이션의 구성, 성능, 종속성을 분석합니다.
     • 비즈니스 목표 설정: 마이그레이션의 목적과 목표를 명확히 하고, 이를 기반으로 전략을 수립합니다.
     • 비용 분석: 마이그레이션 비용을 추산하고, 예상되는 절감 효과를 평가합니다.
     • 마이그레이션 계획 수립: 마이그레이션 작업의 우선순위를 정하고, 상세한 실행 계획을 세웁니다.
  2. 준비 (Mobilize)
     • 기술 및 조직 준비: 클라우드 사용을 위한 기술 역량을 개발하고, 관련된 조직 구조와 프로세스를 준비합니다.
     • 보안 및 규정 준수: 보안 요구사항과 규정 준수를 위해 필요한 조치를 준비합니다.
     • 프로젝트 관리: 마이그레이션 프로젝트를 관리하기 위한 팀과 역할을 정의합니다.
  3. 마이그레이션 및 검증 (Migrate and Validate)
     • 데이터 이전: 데이터베이스, 파일 스토리지 등을 AWS로 이전합니다.
     • 애플리케이션 이전: 애플리케이션과 관련 서비스를 AWS로 이전합니다. Lift-and-shift, 리팩터링, 재구축 등 다양한 방법을 사용할 수 있습니다.
     • 검증: 마이그레이션이 제대로 수행되었는지 확인하고, 성능 및 기능 테스트를 수행합니다.
     • 최적화: 마이그레이션 후 시스템의 성능과 비용 효율성을 최적화합니다.
  4. 운영 및 최적화 (Operate and Optimize)
     • 운영 관리:

 

 

 

 

• AWS 글로벌 인프라는 전 세계적으로 분포된 데이터 센터와 네트워크로 구성되어 있어 사용자가 어디서든 AWS 서비스를 안정적이고 신속하게 사용할 수 있도록 지원합니다. AWS 글로벌 인프라의 주요 구성 요소는 다음과 같습니다:

1. 리전(Region)
   • 정의: AWS 리전은 물리적으로 분리된 지리적 지역으로, 각 리전은 완전히 독립된 여러 가용 영역(AZ)으로 구성되어 있습니다.
   • 특징: 각 리전은 자체의 전력, 냉각 및 물리적 보안 등을 갖추고 있어 다른 리전과 독립적으로 운영됩니다.
   • 용도: 특정 지역에 가까운 리전을 선택하여 지연 시간을 최소화하고, 데이터 주권 요구 사항을 충족할 수 있습니다.
2. 가용 영역(Availability Zone, AZ)
   • 정의: 가용 영역은 하나 이상의 데이터 센터로 구성된 리전 내의 고가용성 영역입니다.
   • 특징: 각 AZ는 독립된 전력, 네트워크 및 냉각 시설을 갖추고 있으며, 다른 AZ와는 물리적 거리가 충분히 떨어져 있습니다.
   • 용도: 애플리케이션을 여러 AZ에 분산 배포함으로써 장애 발생 시에도 높은 가용성과 복원력을 유지할 수 있습니다.

 

 

 

 

 

1. 로컬 영역(Local Zone)
   • 정의: 로컬 영역은 특정 지역에 더 가까운 컴퓨팅 자원과 스토리지를 제공하여 지연 시간을 줄이는 데 도움을 주는 인프라입니다.
   • 특징: 로컬 영역은 주요 리전의 확장으로, 사용자에게 저지연 액세스를 제공하여 특정 요구사항을 충족할 수 있습니다.
2. 엣지 로케이션(Edge Location)
   • 정의: 엣지 로케이션은 Amazon CloudFront와 같은 콘텐츠 전송 네트워크(CDN) 서비스와 AWS Global Accelerator를 지원하는 지점입니다.
   • 특징: 전 세계에 분포된 엣지 로케이션을 통해 사용자에게 더 빠른 콘텐츠 전달과 낮은 지연 시간을 제공합니다.
   • 용도: 웹 콘텐츠, 동영상, 애플리케이션 데이터를 전 세계 사용자에게 신속하게 전송할 수 있습니다.
3. 웨이브렝스 존(Wavelength Zone)
   • 정의: 웨이브렝스 존은 통신사의 5G 네트워크와 통합된 AWS 인프라로, 모바일 및 엣지 컴퓨팅 애플리케이션을 지원합니다.
   • 특징: 5G 네트워크를 통해 매우 낮은 지연 시간과 고속 데이터 전송을 제공합니다.
   • 용도: 모바일 애플리케이션, IoT 디바이스, 자율 주행 차량 등 초저지연이 필요한 워크로드를 지원합니다.

AWS 글로벌 인프라는 이러한 다양한 구성 요소를 통해 높은 가용성, 내구성, 확장성을 제공하며, 고객이 전 세계 어디서든 AWS 서비스를 최적의 성능으로 사용할 수 있도록 지원합니다.

 

 

 

 

 

 

• AWS Lambda는 서버리스 컴퓨팅 서비스를 제공하여 인프라 관리 부담을 줄이고, 코드 실행에만 집중할 수 있게 해줍니다. 그러나 AWS Lambda를 사용하는 회사도 여전히 몇 가지 중요한 책임을 지게 됩니다. 이러한 책임은 보안, 코드 관리, 리소스 최적화 등을 포함합니다. 다음은 주요 책임 사항입니다:

1. 코드 작성 및 관리
   • 비즈니스 로직: Lambda 함수에 대한 비즈니스 로직을 작성하고 유지보수합니다.
   • 테스트 및 디버깅: 코드를 테스트하고 디버깅하여 원하는 대로 작동하는지 확인합니다.
   • 버전 관리: 코드 변경 사항을 추적하고, 다양한 버전 간의 차이를 관리합니다.
2. 보안
   • IAM 역할 및 정책: Lambda 함수가 올바른 권한을 가질 수 있도록 IAM 역할 및 정책을 설정하고 관리합니다.
   • 환경 변수: 환경 변수에 저장된 민감한 데이터를 암호화하고 안전하게 관리합니다.
   • 네트워크 보안: 필요한 경우 VPC 설정을 통해 네트워크 접근을 제어합니다.
   • 보안 패치: 사용 중인 라이브러리와 종속성의 보안 업데이트를 주기적으로 확인하고 적용합니다.
3. 리소스 최적화
   • 메모리 및 타임아웃 설정: Lambda 함수의 메모리 크기와 타임아웃 값을 최적화하여 비용을 절감하고 성능을 최적화합니다.
   • 프로비저닝된 동시성: 특정 트래픽 패턴에 대한 프로비저닝된 동시성을 설정하여 성능을 예측 가능하게 유지합니다.
4. 성능 모니터링 및 로깅
   • 모니터링: AWS CloudWatch와 같은 도구를 사용하여 Lambda 함수의 성능을 모니터링합니다.
   • 로깅: Lambda 함수의 로그를 수집하고 분석하여 문제를 진단하고 해결합니다.
   • 경고 설정: 비정상적인 동작이 감지될 경우 경고를 설정하여 신속하게 대응할 수 있도록 합니다.
5. 비용 관리
   • 비용 모니터링: Lambda 함수 사용에 따른 비용을 모니터링하고 분석합니다.
   • 비용 최적화: 불필요한 호출을 줄이고, 비용 효율적인 아키텍처를 설계합니다.
6. 애플리케이션 통합
   • 이벤트 소스 설정: Lambda 함수가 적절한 이벤트 소스와 통합되도록 설정합니다(e.g., S3, DynamoDB, API Gateway).
   • 서비스 간 통신: 다른 AWS 서비스나 외부 서비스와의 통신을 안전하고 효율적으로 설정합니다.
7. 고가용성 및 장애 복구
   • 백업 및 복구: 중요한 상태나 데이터를 저장하는 경우 백업 및 복구 전략을 수립합니다.
   • 리전 분산: 필요 시 여러 리전에 걸쳐 Lambda 함수를 배포하여 장애 복구 능력을 향상시킵니다.

 

 

 

 

• AMI (Amazon Machine Image)란 소프트웨어 구성을 기록한 템플릿이다. 인스턴스(가상 서버)를 생성하기 위한 금형과 같은 것으로 금형을 한 번 만들어 두면 얼마든지 같은 설정의 서버를 생성하는 것이 가능하다. 
  AMI (Amazon Machine Image): 인스턴스의 운영체제, 설정, 애플리케이션이 포함된 황금 템플릿입니다. Auto Scaling 시 이 이미지를 붕어빵 틀처럼 사용하여 똑같은 서버를 찍어냅니다.

 

 

 

• AWS 소프트웨어 개발 키트(SDK)는 개발자가 다양한 프로그래밍 언어를 사용하여 AWS 서비스와 애플리케이션을 쉽게 통합하고 상호 작용할 수 있도록 도와주는 도구 모음입니다. SDK는 AWS 서비스에 대한 API 호출을 간소화하고, 인증, 요청 서명, 오류 처리 등을 자동으로 처리하여 개발자가 생산성을 높이고 코드의 복잡성을 줄일 수 있게 합니다.

 

 

 

 

Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다.

로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 합니다. 즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅됩니다. 그런 다음 요청을 처리할 여러 리소스로 분산됩니다. 예를 들어 Amazon EC2 인스턴스가 여러 개인 경우 Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없습니다. 

Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스이지만 서로 연동하여 Amazon EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공하도록 돕습니다.

 

 

 

• Amazon S3를 사용하는 데이터 레이크는 대규모 데이터를 저장하고 분석하기 위한 아키텍처입니다. 데이터 레이크는 구조화된 데이터, 반구조화된 데이터, 비구조화된 데이터를 원시 상태로 저장하고, 이를 다양한 분석 및 처리 작업에 사용할 수 있게 합니다. Amazon S3의 유연성과 확장성을 활용하면, 데이터 레이크를 효율적으로 구현할 수 있습니다.

 

 

• Amazon EC2 인스턴스의 구매 옵션에는 온디맨드 인스턴스, 예약 인스턴스, 스팟 인스턴스, 그리고 저전력 인스턴스가 있습니다. 각 옵션은 비용 효율성과 유연성 측면에서 다르며, 특정 사용 사례에 따라 적합한 옵션이 결정됩니다. 전자상거래 애플리케이션이 항상 사용 가능해야 하고, 12개월 동안 지속적으로 실행될 예정이라면, 가장 비용 효율적인 옵션은 예약 인스턴스입니다. 그러나, 각 구매 옵션에 대해 간략히 설명하면 다음과 같습니다:

---

 

 

• 비용 할당 태그는 비용 추적 및 분류 목적으로 AWS 리소스에 메타데이터를 할당하기 위해 AWS에서 제공하는 메커니즘입니다. 비용 할당 태그를 리소스에 적용함으로써 회사는 사용자 정의 메타데이터를 연결하여 사업부, 부서, 프로젝트 또는 애플리케이션과 같은 다양한 기준에 따라 리소스를 식별하고 분류할 수 있습니다. 비용 할당 태그를 사용하면 회사는 할당된 태그를 기반으로 AWS 비용을 추적하고 분석할 수 있습니다. 이를 통해 다양한 사업부 또는 기타 관련 분류 간의 비용 분포를 결정할 수 있습니다. 비용 할당 태그는 리소스 사용량 및 지출에 대한 세부적인 가시성을 제공하여 정확한 비용 귀속 및 분석을 가능하게 합니다.

 

 

 

• 서비스 할당량(Service Quotas)란 AWS에서 특정 서비스나 리소스에 대해 고객이 사용할 수 있는 최대 한도를 의미합니다. 이는 AWS가 리소스를 관리하고, 서비스 품질을 보장하며, 각 고객이 인프라를 과도하게 사용하지 않도록 하기 위한 제한입니다. 각 서비스마다 다양한 할당량이 있으며, 기본적으로 제공되는 할당량과 필요에 따라 요청할 수 있는 할당량이 있습니다. 

 

 

 

Amazon Simple Queue Service (Amazon SQS)는 완전 관리형 메시지 대기열 서비스로, 분산 애플리케이션 및 마이크로서비스 간의 메시지 통신을 지원하는 AWS의 서비스입니다. Amazon SQS를 사용하면 애플리케이션 구성 요소 간에 안전하고 견고한 메시지 전송을 보장할 수 있습니다.

 

 

AWS Site-to-Site VPN 연결은 AWS 클라우드와 기업의 온프레미스 네트워크 간의 안전한 프라이빗 네트워크 연결을 제공하는 서비스입니다. 이 연결을 통해 온프레미스 네트워크의 리소스와 AWS 클라우드의 리소스 간에 안전하게 데이터를 전송하고, 확장성 있는 하이브리드 클라우드 아키텍처를 구축할 수 있습니다.  (인터넷을 통해 암호화 터널을 뚫는 방식)

Site-to-Site VPN 연결 구성 요소

1. 가상 프라이빗 게이트웨이 (Virtual Private Gateway, VGW)
   • AWS에서 제공하는 가상의 라우팅 장비로, AWS 네트워크와 VPN 연결을 담당합니다. 이는 AWS VPC(Virtual Private Cloud)와 연결됩니다.
2. 커스터머 게이트웨이 (Customer Gateway, CGW)
   • 기업의 온프레미스 네트워크에 위치한 라우터나 VPN 디바이스를 나타냅니다. 이는 VPN 연결을 AWS 클라우드와 연결합니다.
3. VPN 연결
   • VGW와 CGW 간의 실제 VPN 연결입니다. IPSec 프로토콜을 사용하여 암호화된 터널을 생성하여 데이터를 안전하게 전송합니다.

 

 

┌────────────────────────────────────────────┐
│             On-Premise Network             │
│                                            │
│   ┌────────────────────────────────────┐   │
│   │  Application Servers               │   │
│   │                                    │   │
│   │   ERP / Web / Internal Systems     │   │
│   └────────────────────────────────────┘   │
│                    │                       │
│                    │                       │
│            ┌───────────────┐               │
│            │ Customer      │               │
│            │ Gateway       │
│            │ (VPN Router)  │
│            └───────────────┘
└───────────────│────────────────────────────┘
                │
                │  Encrypted IPSec Tunnel
                │
                │  (Internet)
                │
┌───────────────▼────────────────────────────┐
│                 AWS Cloud                  │
│                                            │
│   ┌────────────────────────────────────┐   │
│   │ Virtual Private Gateway           │   │
│   │ (AWS VPN Gateway)                 │   │
│   └────────────────────────────────────┘   │
│                    │                       │
│                    │                       │
│        ┌─────────────────────────────┐    │
│        │            VPC              │    │
│        │                             │    │
│        │   ┌───────────────┐         │    │
│        │   │ EC2 Instance  │         │    │
│        │   │ Application   │         │    │
│        │   └───────────────┘         │    │
│        │                             │    │
│        │   ┌───────────────┐         │    │
│        │   │ Database      │         │    │
│        │   │ RDS / Others  │         │    │
│        │   └───────────────┘         │    │
│        │                             │    │
│        └─────────────────────────────┘    │
└───────────────────────────────────────────┘

 

 

---

 

 

 

VPC 피어링(VPC Peering)은 AWS(Amazon Web Services)에서 제공하는 서비스로, Virtual Private Cloud(VPC) 간에 안전하고 프라이빗한 네트워크 연결을 설정하는 기술입니다. 이를 통해 하나의 AWS 리전 내에서 서로 다른 VPC 간에 직접 통신할 수 있습니다.

 

• AWS Artifact는 AWS의 보안 및 규정 준수 보고서, 인증서, 기타 관련 문서에 대한 온디맨드 접근을 제공하는 서비스입니다. 이를 통해 AWS 고객은 자신들의 규정 준수 요구사항을 충족하고, AWS 환경에서 운영하는 애플리케이션의 보안 및 규정 준수 상태를 평가할 수 있습니다.

 

 

 

AWS Organizations는 AWS 계정의 중앙 관리 및 관리를 용이하게 하는 서비스로, 특히 대규모 조직에서 여러 AWS 계정을 효과적으로 관리하는 데 중요한 역할을 합니다. 이 서비스를 통해 보안, 거버넌스, 비용 관리, 정책 시행 등을 중앙에서 쉽게 제어할 수 있습니다. 다음은 AWS Organizations의 주요 기능 및 사용 사례입니다.

주요 기능

1. 계정 관리
   • 조직 및 조직 단위(OU): 여러 AWS 계정을 계층 구조로 조직하여 관리할 수 있습니다. 조직 단위(OU)를 사용하여 계정을 논리적으로 그룹화하고, 정책을 일관되게 적용할 수 있습니다.
   • 계정 생성 및 초대: AWS Organizations를 사용하여 새 계정을 쉽게 생성하거나 기존 계정을 조직에 초대할 수 있습니다.
2. 서비스 제어 정책(SCP)
   • 정책 적용: SCP를 통해 조직 내의 특정 서비스나 작업을 허용하거나 금지할 수 있습니다. SCP는 기본적으로 허용된 작업만 수행할 수 있도록 하는 기본 거부 모델을 따릅니다.
   • 정책 계층 구조: SCP는 루트, OU, 계정 수준에서 적용될 수 있으며, 상위 계층에서 더 제한적인 정책이 있을 경우 하위 계층에서 이를 상속받습니다.
   • SCP (Service Control Policy): 조직 내 계정이 사용할 수 있는 최대 권한을 정의합니다. 허용되지 않은 서비스는 루트 사용자라도 사용할 수 없습니다.
3. 통합 결제
   • 단일 결제 방법: 모든 계정의 청구서를 단일 결제 계정으로 통합하여 비용을 관리할 수 있습니다. 이를 통해 비용 할인을 극대화하고 결제를 간소화할 수 있습니다.
4. AWS SSO 통합
   • 단일 로그인: AWS Single Sign-On(SSO)과 통합하여 여러 AWS 계정 및 애플리케이션에 대한 중앙 집중식 액세스 관리와 SSO를 제공할 수 있습니다.

온프레미스 Microsoft AD
        │
   (Trust 관계)
        │
AWS Directory Service
        │
IAM Identity Center
        │
AWS Organizations
 ├── Account A
 ├── Account B
 └── Account C

 

 

5. 리소스 공유

• RAM(리소스 접근 관리자): AWS Organizations와 통합된 RAM을 사용하여 조직 내에서 VPC 서브넷, Route 53 호스팅 영역 등 리소스를 쉽게 공유할 수 있습니다.

 

 

 

 

 

 

AWS 키 관리 서비스(AWS KMS)는 암호화 키의 생성, 관리, 그리고 사용을 중앙 집중적으로 관리할 수 있게 해주는 서비스입니다. AWS KMS는 안전하고 확장 가능한 방식으로 데이터 보호를 강화하며, 다양한 AWS 서비스와 통합되어 있습니다. 다음은 AWS KMS의 주요 기능과 사용 사례입니다.

주요 기능

1. 키 생성 및 관리
   • 고객 관리형 키(CMK): 사용자가 생성하고 관리하는 키로, AWS KMS 콘솔, CLI, 또는 API를 통해 생성할 수 있습니다.
   • AWS 관리형 키: 특정 AWS 서비스가 자동으로 생성하고 관리하는 키로, 사용자가 별도로 관리할 필요가 없습니다.
   • 대칭 키 및 비대칭 키: 대칭 키는 동일한 키로 암호화와 복호화를 수행하며, 비대칭 키는 공개 키로 암호화하고 비밀 키로 복호화하는 방식입니다.
2. 키 정책 및 권한 관리
   • 키 정책: KMS 키에 대한 액세스를 제어하는 정책으로, JSON 형식으로 작성됩니다. 이를 통해 특정 IAM 사용자 또는 역할에게 키 사용 권한을 부여할 수 있습니다.
   • IAM 통합: IAM 정책을 통해 KMS 키에 대한 세부적인 권한을 부여하거나 제한할 수 있습니다.
3. 암호화 및 복호화
   • 데이터 암호화: 데이터를 암호화하고 복호화하는 작업을 수행합니다. KMS는 데이터를 직접 암호화하지 않고, 데이터 암호화 키(DEK)를 생성하고 관리합니다. DEK를 사용하여 데이터를 암호화하고, DEK는 KMS 키로 암호화됩니다.
   • Envelope Encryption: KMS 키로 데이터 암호화 키(DEK)를 암호화하는 방식으로, 더 큰 데이터 세트를 효율적으로 보호합니다.
4. 로깅 및 모니터링
   • AWS CloudTrail 통합: KMS 키 사용에 대한 모든 API 호출이 AWS CloudTrail에 기록되어 보안 감사와 규정 준수를 지원합니다.
   • AWS CloudWatch 통합: 키 사용량 및 메트릭을 모니터링하여 실시간으로 보안 상태를 확인할 수 있습니다.

 

 

**AWS KMS External Key Store (XKS)**입니다.

• 규정 준수: 데이터 암호화에 사용되는 실제 키 재료(Key Material)를 AWS 외부의 온프레미스 HSM이나 키 관리자에 보관할 수 있게 해줍니다.
• 운영 효율성: AWS KMS의 사용 편의성(API 호출, 서비스 통합)을 그대로 유지하면서, 키의 물리적 제어권만 외부로 가져가는 방식이므로 운영 오버헤드가 가장 낮습니다.
• 호환성: 다양한 외부 키 관리 공급업체(Thales, Entrust 등)와 연동을 지원합니다.

KMS External Key Store (XKS): AWS 서비스가 데이터를 암호화해야 할 때, AWS 내부에 키를 두지 않고 외부 네트워크를 통해 온프레미스 키 관리자에게 암호화/복복화 요청을 보내는 방식입니다.

 

 

 

 

Amazon Elastic Transcoder는 AWS에서 제공하는 클라우드 기반의 미디어 파일 트랜스코딩 서비스입니다. 이 서비스는 다양한 디바이스 및 플랫폼에 맞게 비디오 및 오디오 파일을 손쉽게 변환할 수 있도록 설계되었습니다. Elastic Transcoder를 사용하면 대규모 미디어 파일의 형식을 자동으로 변환하여, 여러 종류의 장치에서 최적의 품질로 재생될 수 있도록 할 수 있습니다.

주요 기능

1. 다양한 입력 및 출력 형식 지원:
   • 비디오 및 오디오 파일을 다양한 형식으로 변환할 수 있습니다. 예를 들어, MP4, AVI, MP3, AAC 등의 형식을 지원합니다.
   • 여러 해상도, 비트레이트, 코덱을 지원하여 다양한 출력 옵션을 제공합니다.
2. 미디어 파일 관리:
   • Amazon S3와 통합되어 입력 파일을 S3 버킷에서 가져오고, 변환된 출력 파일을 S3 버킷에 저장합니다.
   • AWS IAM을 사용하여 액세스 제어를 설정할 수 있습니다.
3. 플리팅 기능:
   • 대규모 트랜스코딩 작업을 처리할 수 있도록 트랜스코딩 작업을 여러 개의 작은 작업으로 분할하여 병렬로 처리합니다.
   • 트랜스코딩 속도를 높이고 비용을 절감할 수 있습니다.
4. 미리 설정된 트랜스코딩 프로필:
   • 다양한 디바이스 및 플랫폼에 맞는 미리 설정된 프로필을 제공하여 손쉽게 트랜스코딩 작업을 설정할 수 있습니다.
   • 사용자 정의 프로필을 생성하여 고유한 요구사항을 충족할 수도 있습니다.
5. 워크플로 자동화:
   • Elastic Transcoder는 Amazon SNS와 통합되어 트랜스코딩 작업의 상태를 모니터링하고, 작업 완료 시 알림을 받을 수 있습니다.
   • Lambda 함수와 통합하여 트랜스코딩 완료 후 후속 작업을 자동으로 실행할 수 있습니다.
6. 메타데이터 처리:
   • 트랜스코딩 작업 중에 메타데이터를 보존하고, 필요한 경우 메타데이터를 수정하거나 추가할 수 있습니다.

 

 

 

 

하이브리드 클라우드:

• 퍼블릭 클라우드 + 프라이빗 클라우드: 하이브리드 클라우드는 퍼블릭 클라우드 서비스와 프라이빗 클라우드 서비스, 그리고 온프레미스 인프라를 결합한 IT 환경입니다. 이를 통해 유연성과 확장성을 제공하면서도 보안과 제어를 유지할 수 있습니다.

 

 

 

 

AWS 아웃포스트(AWS Outposts)는 AWS가 제공하는 완전 관리형 서비스로, AWS 인프라, 서비스, API 및 도구를 온프레미스 환경에서 사용할 수 있게 해줍니다. AWS Outposts는 데이터 센터, 공동 배치 공간 또는 온프레미스 시설에서 직접 실행되며, 로컬에서 데이터를 처리해야 하거나 낮은 지연 시간이 요구되는 워크로드를 위해 설계되었습니다. 이를 통해 하이브리드 클라우드 전략을 지원하고, AWS 클라우드와 일관된 운영 경험을 제공합니다.

주요 특징

1. 일관된 하이브리드 경험:
   • 온프레미스 환경에서 AWS 인프라와 서비스를 동일한 방식으로 사용할 수 있습니다. AWS Management Console, CLI 및 SDK를 통해 온프레미스와 클라우드에서 일관된 관리 경험을 제공합니다.
2. 로컬 데이터 처리 및 낮은 지연 시간:
   • 민감한 데이터를 로컬에서 처리하거나 저장해야 하는 경우, Outposts를 통해 데이터를 온프레미스에서 처리하면서도 AWS 서비스의 이점을 누릴 수 있습니다.
   • 지연 시간이 중요한 애플리케이션에 대해 로컬에서 실행되므로 성능을 최적화할 수 있습니다.
3. AWS 서비스의 확장:
   • Amazon EC2, Amazon EBS, Amazon RDS, Amazon ECS, Amazon EKS 등 다양한 AWS 서비스를 Outposts에서 사용할 수 있습니다. 이는 온프레미스 환경에서도 AWS 클라우드의 강력한 기능을 활용할 수 있음을 의미합니다.
4. 완전 관리형 인프라:
   • AWS에서 하드웨어 설치, 소프트웨어 업데이트, 모니터링 및 유지 관리를 수행하므로, 사용자는 인프라 관리에 대한 부담 없이 애플리케이션 개발에 집중할 수 있습니다.

 

AWS Outposts 인터넷 게이트웨이, 가상 사설 게이트웨이, Amazon VPC 전송 게이트웨이, VPC 엔드포인트를 포함하여 지역에서 액세스할 수 있는 VPC 구성 요소를 사용하여 Amazon VPC를 지역에서 Outpost로 확장합니다. AWS Outpost는 리전의 가용 영역에 위치하며 복원력을 위해 사용할 수 있는 해당 가용 영역의 확장본입니다.

다음은 Outpost의 네트워크 구성 요소를 나타낸 다이어그램입니다.

• AWS 리전 A 및 온프레미스 네트워크
• 리전에 여러 서브넷이 있는 VPC
• 온프레미스 네트워크 내의 Outpost
• 로컬 게이트웨이(랙) 또는 로컬 네트워크 인터페이스(서버)를 통해 제공되는 Outpost와 로컬 네트워크 간 연결

 

 

 

 

 

AWS Storage Gateway는 온프레미스 환경에서 클라우드 스토리지를 원활하게 통합할 수 있는 서비스입니다. AWS Storage Gateway는 세 가지 주요 유형의 게이트웨이를 제공합니다:

1. 파일 게이트웨이(File Gateway): 네트워크 파일 시스템(NFS) 또는 서버 메시지 블록(SMB) 프로토콜을 사용하여 온프레미스 애플리케이션에서 Amazon S3에 직접 파일을 저장할 수 있도록 합니다. 파일은 S3 버킷에 객체로 저장되며, 클라우드 내에서 데이터를 효율적으로 사용할 수 있도록 메타데이터가 유지됩니다.
2. 볼륨 게이트웨이(Volume Gateway): iSCSI 프로토콜을 사용하여 온프레미스 블록 스토리지를 AWS 클라우드로 확장할 수 있습니다. 볼륨 게이트웨이는 두 가지 모드를 지원합니다:
   • 캐시된 볼륨(Cached Volumes): 자주 접근하는 데이터는 온프레미스에서 캐싱하고, 모든 데이터는 Amazon S3에 저장하여 저비용의 클라우드 스토리지를 활용합니다.
   • 저장된 볼륨(Stored Volumes): 온프레미스에서 모든 데이터의 완전한 복사본을 저장하고 Amazon S3에 비동기적으로 백업합니다.
3. 테이프 게이트웨이(Tape Gateway): 기존 백업 애플리케이션이 온프레미스에서 클라우드로 이동할 수 있도록 가상 테이프 라이브러리(VTL)를 제공합니다. 이는 Amazon S3와 Amazon Glacier를 사용하여 비용 효율적인 백업 및 아카이빙 솔루션을 제공합니다.

 

 

 

Amazon Polly는 텍스트를 자연스러운 음성으로 변환해주는 텍스트-투-스피치(Text-to-Speech, TTS) 서비스입니다. Amazon Polly를 사용하면 응용 프로그램에 음성 인터페이스를 추가하거나 오디오북, 교육 자료, 뉴스 읽기 등 다양한 용도로 음성을 생성할 수 있습니다.

 

 

 

 

 

 

 

 

 

Amazon Elastic File System (EFS)는 AWS에서 제공하는 완전 관리형 파일 스토리지 서비스로, Elastic Compute Cloud (EC2) 인스턴스와 통합하여 사용됩니다. EFS는 공유 파일 시스템을 제공하여 여러 EC2 인스턴스에서 동시에 액세스할 수 있으며, 자동으로 확장 및 축소되는 스토리지 용량을 통해 유연한 데이터 관리를 지원합니다.  EFS는 VPC 내부 서비스

 

• 동시 공유 액세스: EFS는 수천 개의 EC2 인스턴스가 동시에 연결하여 읽고 쓸 수 있는 공유 파일 시스템(NFS)을 제공합니다.
• 무한 확장성: 저장하는 파일 양에 따라 용량이 자동으로 늘어나고 줄어듭니다. 사용자가 미리 용량을 할당할 필요가 없어 "시간에 따라 증가하는 파일" 요구사항에 완벽히 부합합니다.
• 기본 내구성 및 중복성: EFS는 리전 내의 **여러 가용 영역(Multi-AZ)**에 데이터를 자동으로 복제하여 저장하므로 매우 높은 내구성과 중복성을 기본으로 제공합니다.

 

 

 

 

Amazon Elastic Block Store (EBS)는 Amazon EC2 인스턴스에 사용할 수 있는 고성능 블록 스토리지 서비스입니다. EBS는 다양한 워크로드에 대해 일관된 저지연 성능을 제공하며, 데이터 내구성과 가용성을 보장합니다. 다음은 EBS의 주요 기능과 장점에 대한 설명입니다.  // 동일한 가용 영역 내의 인스턴스 하나에만 연결 가능. 

 

 

                        AWS Storage
                             │
        ┌────────────┬────────────┬────────────┐
        Object        Block         File
        Storage       Storage       Storage
          │             │              │
        S3             EBS            EFS
        │              │              │
     Glacier      Instance Store      FSx

 

⭐ 영역별 설명

---

✅ 1️⃣ Object Storage

👉 파일 단위 저장

 

S3 → 일반 객체 저장 Glacier → 장기 보관 / 아카이브

✔ 무제한 확장
✔ 높은 내구성
✔ 웹/백업/로그

---

✅ 2️⃣ Block Storage

👉 디스크 단위 저장

"컴퓨터 본체(EC2)는 언제든 바꿀 수 있지만, 내 소중한 파일이 담긴 하드디스크(EBS)는 따로 떼어서 안전하게 보관하고 싶을 때 쓰는 것이 바로 EBS입니다!"

EBS는 여러 인스턴스가 동시에 공유해서 읽고 쓰기에 제약이 많습니다.

 

EBS → 영구 디스크 Instance Store → 임시 디스크

✔ DB / OS 저장
✔ 높은 IOPS (Input/Output Operations Per Second)

---

✅ 3️⃣ File Storage

👉 공유 파일 시스템

 

EFS → Linux 공유 파일 FSx → Windows / HPC 특화

✔ 여러 EC2 공유
✔ NAS 개념

 

 

 

특성	Amazon EBS	Amazon EFS	Amazon S3
유형	블록 스토리지 (SSD/HDD)	파일 스토리지 (NFS)	객체 스토리지
확장성	수동 (미리 크기 지정)	자동 (무제한)	자동 (무제한)
공유	인스턴스 1:1 연결 위주	1:N (수천 대 동시 접속)	인터넷 API 접속
가용성	단일 AZ 내 복제	여러 AZ에 걸쳐 복제	여러 AZ에 걸쳐 복제

 

 

 

✅ ⭐ 개념 정리 (시험 핵심)

⭐ 스토리지 유형 비교

서비스용도

S3	객체 스토리지 (대용량, 저비용)
EBS	EC2 디스크
EFS	공유 파일 시스템

 

스토리지 서비스 비교 (SAA 핵심)

서비스	유형	비용	주요 용도
S3	객체 스토리지	매우 낮음	백업, 로그 저장, 정적 파일 호스팅
EBS	블록 스토리지	높음	DB 실행, OS 부트 볼륨
EFS	파일 스토리지	매우 높음	여러 서버 간 파일 공유 (NFS)
Instance Store	임시 스토리지	낮음 (포함됨)	임시 버퍼, 캐시 (휘발성)

 

---

 

 

Amazon Elastic Container Service(Amazon ECS)

Amazon Elastic Container Service(ECS)는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템입니다. 

Amazon ECS는 Docker 컨테이너를 지원합니다. Docker는 애플리케이션을 신속하게 구축, 테스트, 배포할 수 있는 소프트웨어 플랫폼입니다. AWS는 오픈 소스 Docker Community Edition 및 구독 기반 Docker Enterprise Edition의 사용을 지원합니다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있습니다.

 

 

 

 

 

 

Amazon Elastic Kubernetes Service(Amazon EKS)

Amazon Elastic Kubernetes Service(Amazon EKS)는 AWS에서 Kubernetes를 실행하는 데 사용할 수 있는 완전 관리형 서비스입니다. 

Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어입니다. 자원자로 구성된 대규모 커뮤니티에서 Kubernetes를 유지 관리하며, AWS는 Kubernetes 커뮤니티와 적극적으로 협력합니다. Kubernetes 애플리케이션의 새로운 기능이 릴리스되면 Amazon EKS로 관리되는 애플리케이션에 이러한 업데이트를 손쉽게 적용할 수 있습니다.

 

가장 쉽게 비유하자면, **ECS는 'AWS가 만든 맞춤형 컨테이너 도구'**이고, **EKS는 '전 세계 표준인 Kubernetes를 AWS에서 빌려 쓰는 것'**입니다.

---

1. ECS vs EKS 핵심 비교

구분	Amazon ECS (Elastic Container Service)	Amazon EKS (Elastic Kubernetes Service)
개념	AWS 전용 컨테이너 오케스트레이션	오픈 소스 Kubernetes(K8s) 관리형 서비스
학습 난이도	낮음 (AWS 기본 개념만 알면 쉬움)	높음 (K8s 자체를 공부해야 함)
호환성	AWS 환경에 최적화 (타사 이동 어려움)	매우 높음 (온프레미스나 타 클라우드와 호환)
설정 단위	Task Definition (작업 정의)	Pod, Deployment, Service (YAML 파일)
운영 오버헤드	매우 낮음 (AWS가 거의 다 해줌)	중간 (K8s 업데이트 및 복잡한 설정 관리 필요)

 

2. 언제 무엇을 선택해야 할까요? (시험 문제 판단 기준)

✅ Amazon ECS를 선택해야 하는 경우

• "운영 오버헤드 최소화": 관리할 인력이 부족하고 빠르게 배포하고 싶을 때.
• "AWS 서비스와의 강력한 통합": IAM, ALB, CloudWatch 등 AWS 서비스만 주로 사용하는 경우.
• "단순함": 컨테이너화된 앱을 복잡한 설정 없이 실행하고 싶을 때.

✅ Amazon EKS를 선택해야 하는 경우

• "기존 Kubernetes 사용 중": 온프레미스에서 쓰던 K8s 설정(YAML)을 그대로 가져와야 할 때 (코드/배포 방식 변경 불가 조건).
• "표준화 및 유연성": 나중에 구글 클라우드(GCP)나 MS 애저(Azure)로 옮길 가능성이 있을 때.
• "세밀한 제어": 아주 복잡한 네트워킹이나 대규모 마이크로서비스 아키텍처(MSA)를 정밀하게 제어하고 싶을 때.

 

 

🔥 Lambda vs ECS vs Fargate vs EKS (시험 핵심 정리)

서비스                                                    서버 관리                          사용 상황

 

Lambda	없음	이벤트 기반
ECS	선택	AWS 컨테이너
Fargate	없음	서버리스 컨테이너
EKS	있음	Kubernetes 필요

---

 

 

AWS Fargate

AWS Fargate는 컨테이너용 서버리스 컴퓨팅 엔진으로, Amazon ECS와 Amazon EKS에서 작동합니다. 

AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없습니다. AWS Fargate는 자동으로 서버 인프라를 관리합니다. 애플리케이션 혁신과 개발에 더 집중할 수 있으며, 컨테이너를 실행하는 데 필요한 리소스에 대해서만 비용을 지불하면 됩니다.

 

 

 

 

 

AWS Elastic Beanstalk ( 배포 서비스)

AWS Elastic Beanstalk에서는 사용자가 코드 및 구성 설정을 제공하면 Elastic Beanstalk이 다음 작업을 수행하는 데 필요한 리소스를 배포합니다.

사용자가 애플리케이션을 업로드하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 애플리케이션 상태 모니터링에 대한 배포 세부 정보를 자동으로 처리합니다.

• 용량 조정
• 로드 밸런싱
• 자동 조정
• 애플리케이션 상태 모니터링

AWS Elastic Beanstalk는 한마디로 **"애플리케이션을 클라우드에 가장 쉽고 빠르게 배포할 수 있게 도와주는 지휘자(Orchestrator)"**입니다.

개발자가 코드를 작성한 후 서버 설정, 로드 밸런서 구성, 오토 스케일링 설정 등을 일일이 하기엔 너무 복잡하죠? Elastic Beanstalk는 코드만 업로드하면 그 뒤에 필요한 모든 인프라를 자동으로 구축하고 관리해 줍니다.

---

1. 핵심 개념: PaaS (Platform as a Service)

Elastic Beanstalk는 **서비스형 플랫폼(PaaS)**입니다. 사용자는 하부 인프라(EC2, 네트워크 등)를 직접 만지지 않고도 애플리케이션 실행 환경을 제공받습니다.

• 지원 언어: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker 등 대부분의 주요 언어를 지원합니다.
• 자동화 범위: 용량 프로비저닝, 로드 밸런싱, 오토 스케일링, 애플리케이션 상태 모니터링을 자동으로 수행합니다.

 

 

---

 

 

 

 

 

AWS CloudFormation ( 인프라 구조를 만드는 도구)

AWS CloudFormation을 사용하여 인프라를 코드로 취급할 수 있습니다. 즉, AWS Management Console을 사용하여 개별적으로 리소스를 프로비저닝하는 대신 코드 줄을 작성하여 환경을 구축할 수 있습니다.

AWS CloudFormation은 리소스를 안전하고 반복 가능한 방식으로 프로비저닝하므로 수작업을 수행하거나 사용자 지정 스크립트를 작성할 필요 없이 인프라 및 애플리케이션을 빈번히 구축할 수 있습니다. 이 서비스는 스택을 관리할 때 수행해야 할 적절한 작업을 결정하고 오류를 감지하면 변경 사항을 자동으로 롤백합니다.

 

 

 

VPC의 네트워크 트래픽

고객이 AWS 클라우드에서 호스팅되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송됩니다. 패킷은 인터넷이나 네트워크를 통해 전송되는 데이터의 단위입니다. 

패킷은 인터넷 게이트웨이를 통해 VPC로 들어갑니다. 패킷이 서브넷으로 들어가거나 서브넷에서 나오려면 먼저 권한을 확인해야 합니다. 이러한 사용 권한은 패킷을 보낸 사람과 패킷이 서브넷의 리소스와 통신하려는 방법을 나타냅니다.

서브넷의 패킷 권한을 확인하는 VPC 구성 요소는 네트워크 ACL(액세스 제어 목록)입니다.

 

 

네트워크 ACL(액세스 제어 목록 - 가상 방화벽)

네트워크 ACL(액세스 제어 목록)은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.

각 AWS 계정에는 기본 네트워크 ACL이 포함됩니다. VPC를 구성할 때 계정의 기본 네트워크 ACL을 사용하거나 사용자 지정 네트워크 ACL을 생성할 수 있습니다.

계정의 기본 네트워크 ACL은 기본적으로 모든 인바운드 및 아웃바운드 트래픽을 허용하지만 사용자가 자체 규칙을 추가하여 수정할 수 있습니다. 사용자 지정 네트워크 ACL은 사용자가 허용할 트래픽을 지정하는 규칙을 추가할 때까지 모든 인바운드 및 아웃바운드 트래픽을 거부합니다. 또한 모든 네트워크 ACL에는 명시적 거부 규칙이 있습니다. 이 규칙은 패킷이 목록의 다른 모든 규칙과 일치하지 않으면 해당 패킷이 거부되도록 합니다. 

네트워크 ACL은 상태 비저장 패킷 필터링을 수행합니다. 즉, 아무것도 기억하지 않고 각 방향(인바운드 및 아웃바운드)으로 서브넷 경계를 통과하는 패킷만 확인합니다. 

 

 

 

 

보안 그룹

보안 그룹은 Amazon EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽입니다.

기본적으로 보안 그룹은 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용합니다. 사용자 지정 규칙을 추가하여 허용 또는 거부할 트래픽을 구성할 수 있습니다.

보안 그룹은 상태 저장 패킷 필터링을 수행합니다. 즉, 들어오는 패킷에 대한 이전 결정을 기억합니다.

 

 

 

 

 

 

 

 

 

가상 프라이빗 게이트웨이

VPC 내의 비공개 리소스에 액세스하려면 가상 프라이빗 게이트웨이를 사용할 수 있습니다. 

 

 

 

 

 

 

 

AWS Direct Connect

AWS Direct Connect는 데이터 센터와 VPC 간에 비공개 전용 연결을 설정하는 서비스입니다.  

 

 

 

 

 

AWS EFS 

Amazon Elastic File System(Amazon EFS)은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용되는 확장 가능한 파일 시스템입니다. 파일을 추가 또는 제거하면 Amazon EFS가 자동으로 확장하거나 축소됩니다. 애플리케이션을 중단하지 않고 온디맨드로 페타바이트 규모로 확장할 수 있습니다.

Amazon EFS는 리전별 서비스입니다. 이 서비스는 여러 가용 영역에 걸쳐 데이터를 저장합니다. 

 

중복 스토리지를 사용하면 파일 시스템이 위치한 리전의 모든 가용 영역에서 동시에 데이터에 액세스할 수 있습니다. 또한 온프레미스 서버는 AWS Direct Connect를 사용하여 Amazon EFS에 액세스할 수 있습니다.

 

 

 

Amazon Aurora ( 사용하는 만큼만 비용을 지불(Pay-as-you-go))

Amazon Aurora는 엔터프라이즈급 관계형 데이터베이스입니다. 이 데이터베이스는 MySQL 및 PostgreSQL 관계형 데이터베이스와 호환됩니다. 표준 MySQL 데이터베이스보다 최대 5배 빠르며 표준 PostgreSQL 데이터베이스보다 최대 3배 빠릅니다.

Amazon Aurora는 데이터베이스 리소스의 안정성 및 가용성을 유지하면서도 불필요한 입/출력(I/O) 작업을 줄여 데이터베이스 비용을 절감합니다. 

워크로드에 고가용성이 필요한 경우 Amazon Aurora를 고려하십시오. 이 데이터베이스는 6개의 데이터 복사본을 3개의 가용 영역에 복제하고 지속적으로 Amazon S3에 데이터를 백업합니다.

Aurora의 기본 자동 백업 보존 기간은 최대 35일입니다. 5년 이상을 설정하는 것 자체가 기술적으로 불가능합니다.

Amazon RDS/Aurora의 '자동 백업' 기능 자체에는 수년 단위의 수명 주기 정책을 직접 걸 수 있는 기능이 없습니다

 

 

 

 

 

Amazon DynamoDB

Amazon DynamoDB는 키-값 데이터베이스 서비스입니다. 모든 규모에서 한 자릿수 밀리초의 성능을 제공합니다.

 

Amazon DynamoDB는 한마디로 **"아무리 데이터가 많아지고 사용자가 몰려도 100% 지치지 않는 초고속 메모장"**이라고 할 수 있습니다.

일반적인 데이터베이스(MySQL, Oracle 등)와는 결이 다른, AWS의 대표적인 NoSQL 데이터베이스입니다.

 

 

Amazon DynamoDB 글로벌 테이블 (Global Tables)

이 기능은 전 세계 어디서든 읽기뿐만 아니라 '쓰기'도 가능하게 하고 싶을 때 사용하는 NoSQL의 꽃입니다.

• 동작 방식: 여러 리전에 동일한 테이블을 생성하고 이를 하나로 묶습니다. 어느 한 리전에서 데이터를 쓰면, AWS가 마법처럼 다른 모든 리전에 해당 데이터를 복제합니다. (Multi-Region, Multi-Active)
• 핵심 특징:
  • 완전 관리형: 사용자가 복제 로직을 짤 필요가 없습니다.
  • 낮은 지연 시간: 사용자와 가장 가까운 리전에서 읽고 쓸 수 있습니다.
  • 충돌 해결: 마지막에 쓰인 데이터가 승리하는 방식으로 데이터 일관성을 유지합니다.
• 시험 힌트: "전 세계 사용자가 자신의 지역에서 낮은 지연 시간으로 읽기 및 쓰기를 수행해야 함" → 정답: DynamoDB 글로벌 테이블.

---

1. 쉬운 비유: "개인 사물함" vs "도서관"

• 일반 DB (관계형 DB): 거대한 도서관과 같습니다. 책들이 주제별, 저자별로 복잡하게 연결되어 있죠. 원하는 정보를 찾으려면 사서에게 물어보고 여러 서가를 돌아다녀야 합니다(Join 연산). 데이터가 너무 많아지면 찾는 속도가 느려집니다.
• DynamoDB (NoSQL): 거대한 사물함 단지입니다. 각 사물함에는 번호(Primary Key)가 붙어 있고, 그 안에는 내가 넣고 싶은 걸 그냥 넣으면 됩니다. 번호만 알면 1번 사물함이든 100만 번 사물함이든 **찾는 속도가 똑같이 0.001초(Millisecond)**입니다.

---

2. 핵심 특징 (왜 쓰는가?)

① 규모에 상관없는 일관된 성능 (Scalability)

사용자가 10명일 때나 1,000만 명일 때나 응답 속도가 거의 같습니다. 데이터 양이 늘어나면 AWS가 알아서 뒤에서 서버를 늘려주기 때문입니다.

② 서버리스 (Serverless)

서버를 설치하거나 패치할 필요가 없습니다. "용량을 얼마나 쓸지"만 정하거나, 아니면 "쓴 만큼만 내겠다"고 설정하면 끝입니다.

③ 유연한 데이터 구조 (Schema-less)

전통적인 DB는 표(Table)의 칸을 미리 딱딱 맞춰야 하지만, DynamoDB는 사물함마다 넣는 내용물이 달라도 상관없습니다. 1번 칸에는 이름만, 2번 칸에는 이름과 주소, 전화번호를 넣어도 다 받아줍니다.

---

3. 주요 용어 정리

용어	설명	비유
Table (테이블)	데이터가 저장되는 전체 공간	사물함 구역 전체
Item (항목)	저장되는 데이터 한 건	사물함 한 칸의 내용물
Attribute (속성)	데이터의 세부 정보 (이름, 나이 등)	사물함 안의 개별 물건
Partition Key (PK)	데이터를 찾기 위한 고유 번호	사물함 번호 (가장 중요!)

---

4. 언제 쓰면 좋을까?

• 실시간 게임: 전 세계 수백만 명의 유저 스코어와 아이템 정보를 실시간으로 저장하고 읽을 때.
• 쇼핑몰 장바구니: 접속자가 폭주해도 끊김 없이 장바구니 담기가 가능해야 할 때.
• IoT 데이터: 수만 개의 센서가 쉼 없이 보내는 로그를 빠르게 저장할 때.
• 아까 푼 문제처럼: 민감 정보를 제거한 금융 거래 내역을 지연 시간 없이(Low Latency) 검색해야 할 때.

---

### 요약하자면?

DynamoDB는 "복잡한 관계 따지기보다, 무조건 빠르고 절대 안 터지는 저장소가 필요할 때" 쓰는 최고의 도구입니다.

 

 

 

---

 

 

Amazon Redshift

Amazon Redshift는 빅 데이터 분석에 사용할 수 있는 데이터 웨어하우징 서비스입니다. 이 서비스는 여러 원본에서 데이터를 수집하여 데이터 간의 관계 및 추세를 파악하는 데 도움이 되는 기능을 제공합니다.

 

 

 

AWS Database Migration Service(AWS DMS)

AWS Database Migration Service(AWS DMS)는 관계형 데이터베이스, 비관계형 데이터베이스 및 기타 유형의 데이터 저장소를 마이그레이션할 수 있는 서비스입니다.

AWS DMS를 사용하면 원본 데이터베이스와 대상 데이터베이스 간에 데이터를 이동할 수 있습니다. 원본 데이터베이스와 대상 데이터베이스는 유형이 동일할 필요가 없습니다. 마이그레이션하는 동안 원본 데이터베이스가 계속 작동하므로 데이터베이스를 사용하는 애플리케이션의 가동 중지 시간을 줄일 수 있습니다. 

예를 들어 온프레미스에서 Amazon EC2 인스턴스 또는 Amazon RDS에 저장된 MySQL 데이터베이스가 있다고 가정해 보겠습니다. MySQL 데이터베이스가 원본 데이터베이스라고 하겠습니다. AWS DMS를 사용하여 Amazon Aurora 데이터베이스와 같은 대상 데이터베이스로 데이터를 마이그레이션할 수 있습니다.

 

 

 

 

Amazon DocumentDB는 MongoDB 워크로드를 지원하는 문서 데이터베이스 서비스입니다. (MongoDB는 문서 데이터베이스 프로그램입니다.)

 

 

 

 

 

Amazon Neptune은 그래프 데이터베이스 서비스입니다. 

 

Amazon Neptune을 사용하여 추천 엔진, 사기 탐지, 지식 그래프와 같이 고도로 연결된 데이터 세트로 작동하는 애플리케이션을 빌드하고 실행할 수 있습니다. 소셜 미디어의 친구 관계, "누가 무엇을 좋아함"과 같은 복잡한 관계 분석에는 Amazon Neptune과 같은 그래프 데이터베이스가 가장 적합합니다. RDBMS나 NoSQL보다 관계 쿼리 성능이 압도적입니다.

 

Neptune Streams는 Neptune DB에서 발생하는 모든 변경 사항(추가, 수정, 삭제)을 실시간으로 캡처하는 기본 기능입니다.

 

 

 

 

Amazon Quantum Ledger Database(Amazon QLDB)는 원장 데이터베이스 서비스입니다. 

 

Amazon QLDB를 사용하여 애플리케이션 데이터에 발생한 모든 변경 사항의 전체 기록을 검토할 수 있습니다.

 

 

 

 

 

Amazon Managed Blockchain은 오픈 소스 프레임워크를 사용하여 블록체인 네트워크를 생성하고 관리하는 데 사용할 수 있는 서비스입니다. 

 

블록체인은 여러 당사자가 중앙 기관 없이 거래를 실행하고 데이터를 공유할 수 있는 분산형 원장 시스템입니다.

 

 

 

 

 

Amazon ElastiCache는 자주 사용되는 요청의 읽기 시간을 향상시키기 위해 데이터베이스 위에 캐싱 계층을 추가하는 서비스입니다. 

 

이 서비스는 두 가지 데이터 저장소 Redis 및 Memcached를 지원합니다.

 

Amazon ElastiCache는 AWS에서 제공하는 완전 관리형 인메모리(In-Memory) 캐시 서비스입니다.

쉽게 말해, 데이터를 하드디스크(SSD/HDD)가 아닌 **RAM(메모리)**에 저장하여 데이터 읽기 속도를 극도로 높이는 서비스입니다. 데이터베이스(RDS 등)의 부하를 줄이고 애플리케이션의 응답 시간을 밀리초($ms$)에서 마이크로초($\mu s$) 단위로 단축할 때 필수적으로 사용됩니다.

---

1. ElastiCache의 핵심 역할

• DB 부하 감소 (Caching): 자주 조회되는 데이터를 메모리에 미리 올려두어, 반복적인 DB 쿼리를 방지합니다.
• 속도 향상: 디스크 기반 데이터베이스보다 수백 배 빠른 읽기 성능을 제공합니다.
• 세션 관리: 사용자의 로그인 상태나 장바구니 정보 등을 저장하는 '세션 저장소'로 활용됩니다. (Auto Scaling 환경에서 필수)
• 실시간 처리: 실시간 순위표(Leaderboard), 채팅 메시지 전달, 실시간 분석 등에 최적화되어 있습니다.

---

2. 두 가지 엔진 비교 (Redis vs Memcached)

AWS 시험과 실무에서 가장 중요한 부분은 상황에 맞는 엔진을 선택하는 것입니다.

기능	Redis (인기 엔진)	Memcached
데이터 구조	문자열, 리스트, 세트, 해시 등 다양함	단순한 Key-Value (문자열 전용)
고가용성	지원 (Multi-AZ, 자동 복구)	지원 안 함 (노드 장애 시 데이터 유실)
데이터 복제	지원 (Primary - Replica)	지원 안 함
영속성(저장)	디스크에 데이터 백업 가능	메모리에만 존재 (재부팅 시 삭제)
주요 용도	복잡한 데이터, 세션 관리, 랭킹 시스템	단순 캐싱, 대규모 확장성 필요 시

---

3. 작동 아키텍처 (Cache-Aside 패턴)

일반적으로 애플리케이션은 다음과 같은 "옆으로 치워두기(Cache-Aside)" 전략으로 ElastiCache를 사용합니다.

1. 애플리케이션이 데이터를 요청합니다.
2. ElastiCache에 데이터가 있는지 확인합니다 (Cache Hit). 있으면 즉시 반환합니다.
3. 데이터가 없으면 (Cache Miss), **RDS(DB)**에서 데이터를 직접 읽어옵니다.
4. 가져온 데이터를 ElastiCache에 저장하고 사용자에게 응답합니다.

---

4. 주요 특징 및 장점

• 완전 관리형: 하드웨어 설치, 패치, 설정, 백업을 AWS가 자동으로 처리합니다.
• 확장성: 트래픽 증가에 따라 클릭 몇 번으로 노드를 추가하거나 인스턴스 사양을 높일 수 있습니다.
• 보안: VPC 내에 배치하여 네트워크를 격리하고, IAM을 통한 권한 제어 및 전송 중 암호화를 지원합니다.

---

5. AWS SAA 시험 단골 시나리오

문제 상황 키워드	해결책 (정답 공식)
"DB 읽기 부하 감소, 웹 사이트 성능 향상"	ElastiCache 도입
"Auto Scaling 환경의 세션 공유"	ElastiCache for Redis
"실시간 게임 순위표(Leaderboard) 구현"	ElastiCache for Redis (Sorted Sets)
"단순 캐싱이 필요하고 데이터 유실은 상관없음"	ElastiCache for Memcached

 

 

 

---

 

 

Amazon DynamoDB Accelerator(DAX)는 DynamoDB용 인 메모리 캐시입니다. 

 

응답 시간을 한 자릿수 밀리초에서 마이크로초까지 향상시킬 수 있습니다.

DAX는 데이터베이스 읽기 성능을 높이는 '인 메모리 캐시' 솔루션입니다.

 

 

 

 

 

Amazon Simple Storage Service(Amazon S3)

Amazon Simple Storage Service(Amazon S3)는 객체 수준 스토리지를 제공하는 서비스입니다. Amazon S3는 데이터를 버킷에 객체로 저장합니다.

Amazon S3에는 이미지, 동영상, 텍스트 파일 등 모든 유형의 파일을 업로드할 수 있습니다. 예를 들어 Amazon S3를 사용하여 백업 파일, 웹 사이트용 미디어 파일 또는 보관된 문서를 저장할 수 있습니다. Amazon S3는 저장 공간을 무제한으로 제공합니다. Amazon S3에 저장할 수 있는 객체의 최대 파일 크기는 5TB입니다.

Amazon S3에 파일을 업로드할 때 권한을 설정하여 파일에 대한 표시 여부 및 액세스를 제어할 수 있습니다. Amazon S3 버전 관리 기능을 사용하여 시간 경과에 따른 객체 변경 사항을 추적할 수도 있습니다.

 

 

• S3 버킷에서 버전 관리(Versioning)를 활성화합니다.
  • 버전 관리를 켜면 파일이 삭제되더라도 완전히 사라지는 것이 아니라 **'삭제 마커(Delete Marker)'**가 붙은 채 이전 버전이 그대로 보관됩니다. 실수로 파일을 덮어쓰거나 삭제했을 때, 언제든지 이전 상태로 되돌릴 수 있는 가장 기본적인 방어 수단입니다.
• S3 버킷에서 MFA(다요소 인증) 삭제를 활성화합니다.
  • 이 기능을 켜면 버킷의 버전 관리를 중단하거나, 특정 파일 버전을 영구적으로 삭제하려고 할 때 반드시 MFA 기기(OTP 등)의 인증 코드가 필요합니다. 관리자의 계정이 해킹당하거나 실수로 삭제 버튼을 눌러도 추가 인증 없이는 데이터를 완전히 지울 수 없게 만드는 강력한 보안 장치입니다

 

 

 

 

 공동 책임 모델 

 

 

AWS Organizations

회사에 여러 AWS 계정이 있다고 가정해 보겠습니다. AWS Organizations를 사용하여 중앙 위치에서 여러 AWS 계정을 통합하고 관리할 수 있습니다.

조직을 생성하면 AWS Organizations가 조직의 모든 계정에 대한 상위 컨테이너 루트를 자동으로 생성합니다. 

AWS Organizations에서는 서비스 제어 정책(SCP)을 사용하여 조직의 계정에 대한 권한을 중앙에서 제어할 수 있습니다. SCP를 사용하면 각 계정의 사용자 및 역할이 액세스할 수 있는 AWS 서비스, 리소스 및 개별 API 작업을 제한할 수 있습니다.

조직 단위

AWS Organizations에서는 계정을 조직 단위(OU)로 그룹화하여 비슷한 비즈니스 또는 보안 요구 사항이 있는 계정을 손쉽게 관리할 수 있습니다. OU에 정책을 적용하면 OU의 모든 계정이 정책에 지정된 권한을 자동으로 상속합니다.  

개별 계정을 OU로 구성하면 특정 보안 요구 사항이 있는 워크로드 또는 애플리케이션을 보다 간편하게 격리할 수 있습니다. 예를 들어 회사에 특정 규정 요구 사항을 충족하는 AWS 서비스에만 액세스할 수 있는 계정이 있다면, 이러한 계정을 한 OU에 배치할 수 있습니다. 그런 다음 규제 요구 사항을 충족하지 않는 다른 모든 AWS 서비스에 대한 액세스를 차단하는 정책을 해당 OU에 연결할 수 있습니다.

 

 

 

AWS Shield

AWS Shield는 DDoS 공격으로부터 애플리케이션을 보호하는 서비스입니다. AWS Shield는 두 가지 보호 수준인 Standard 및 Advanced를 제공합니다.

 

 

 

 

AWS Key Management Service(AWS KMS)를 사용하면 암호화 키를 사용하여 암호화 작업을 수행할 수 있습니다. 암호화 키는 데이터 잠금(암호화) 및 잠금 해제(암호 해독)에 사용되는 임의의 숫자 문자열입니다. AWS KMS를 사용하여 암호화 키를 생성, 관리 및 사용할 수 있습니다. 또한 광범위한 서비스 및 애플리케이션에서 키 사용을 제어할 수 있습니다.

AWS KMS를 사용하면 키에 필요한 액세스 제어를 특정 수준으로 선택할 수 있습니다. 예를 들어 키를 관리할 수 있는 IAM 사용자 및 역할을 지정할 수 있습니다. 또는 더 이상 사용되지 않도록 일시적으로 키를 비활성화할 수 있습니다. 키는 AWS KMS를 벗어나지 않으며, 사용자가 항상 키를 제어할 수 있습니다.

 

 

 

 

 

AWS WAF (

 

AWS WAF는 웹 애플리케이션으로 들어오는 네트워크 요청을 모니터링할 수 있는 웹 애플리케이션 방화벽입니다. 

AWS WAF는 Amazon CloudFront 및 Application Load Balancer와 함께 작동합니다. 이전 모듈에서 배운 네트워크 액세스 제어 목록을 기억해 보십시오. AWS WAF는 비슷한 방식으로 작동하여 트래픽을 차단하거나 허용합니다. 그러나 AWS 리소스를 보호하기 위해 웹 ACL(액세스 제어 목록)을 사용합니다. 

애플리케이션이 여러 IP 주소에서 악의적인 네트워크 요청을 받고 있다고 가정해 보겠습니다. 이러한 요청이 애플리케이션에 계속 액세스하는 것을 방지해야 하지만 합법적인 사용자는 여전히 애플리케이션에 액세스할 수 있도록 해야 합니다. 지정한 IP 주소에서 나온 요청을 제외한 모든 요청을 허용하도록 웹 ACL을 구성합니다.

AWS WAF는 요청이 들어오면 웹 ACL에서 구성한 규칙 목록을 확인합니다. 요청이 차단된 IP 주소 중 하나에서 나온 것이 아니면 애플리케이션에 대한 액세스가 허용됩니다.   HTTP/HTTPS 요청을 모니터링하여 공격을 차단합니다. 봇 제어(Bot Control) 규칙 세트를 제공합니다.

 

 

🎯 SAA 시험 포인트 요약

상황                                                                                         정답 방향

    

악성 트래픽	WAF
과도한 호출	Usage Plan
비용 폭증	Throttle

 

 

 

 

 

Amazon Inspector는 자동화된 보안 평가를 실행하여 애플리케이션의 보안 및 규정 준수를 개선할 수 있는 서비스입니다. 이 서비스는 Amazon EC2 인스턴스에 대한 오픈 액세스, 취약한 소프트웨어 버전 설치와 같은 보안 모범 사례 위반 및 보안 취약성을 애플리케이션에서 검사합니다. 

Amazon Inspector

커피숍의 개발자들이 새로운 주문 애플리케이션을 개발하고 테스트한다고 가정해 보겠습니다. 이들은 보안 모범 사례에 따라 애플리케이션을 디자인하고 있는지 확인하기를 원합니다. 그러나 개발해야 할 다른 여러 애플리케이션이 있으므로 수동 평가를 수행하는 데 많은 시간을 할애할 수 없습니다. 개발자들은 자동 보안 평가를 수행하기 위해 Amazon Inspector를 사용하기로 결정했습니다.

Amazon Inspector는 자동화된 보안 평가를 실행하여 애플리케이션의 보안 및 규정 준수를 개선할 수 있는 서비스입니다. 이 서비스는 Amazon EC2 인스턴스에 대한 오픈 액세스, 취약한 소프트웨어 버전 설치와 같은 보안 모범 사례 위반 및 보안 취약성을 애플리케이션에서 검사합니다. 

Amazon Inspector는 평가를 수행한 후에 보안 탐지 결과 목록을 제공합니다. 이 목록은 심각도 수준에 따라 우선 순위가 결정되고 각 보안 문제에 대한 자세한 설명 및 권장 해결 방법이 포함됩니다. 그러나 AWS는 제공된 권장 사항으로 모든 잠재적 보안 문제가 해결됨을 보장하지 않습니다. 공동 책임 모델에 따라 고객은 AWS 서비스에서 실행되는 애플리케이션, 프로세스 및 도구의 보안에 대한 책임이 있습니다.

 

 

 

 

Amazon GuardDuty

Amazon GuardDuty는 AWS 인프라 및 리소스에 대한 지능형 위협 탐지 기능을 제공하는 서비스입니다. 이 서비스는 AWS 환경 내의 네트워크 활동 및 계정 동작을 지속적으로 모니터링하여 위협을 식별합니다.

AWS 계정에서 GuardDuty를 활성화하면 GuardDuty가 네트워크 및 계정 활동을 모니터링하기 시작합니다. 추가 보안 소프트웨어를 배포하거나 관리할 필요가 없습니다. 그런 다음 GuardDuty는 VPC Flow Logs 및 DNS 로그를 비롯한 여러 AWS 소스의 데이터를 지속적으로 분석합니다. 

GuardDuty가 위협을 탐지한 경우 AWS Management Console에서 위협에 대한 자세한 탐지 결과를 검토할 수 있습니다. 탐지 결과에는 문제 해결을 위한 권장 단계가 포함됩니다. 또한 GuardDuty 보안 탐지 결과에 대한 응답으로 자동으로 문제 해결 단계를 수행하도록 AWS Lambda 함수를 구성할 수도 있습니다.

 

 

 

 

 

Amazon CloudWatch

Amazon CloudWatch는 다양한 지표를 모니터링 및 관리하고 해당 지표의 데이터를 기반으로 경보 작업을 구성할 수 있는 웹 서비스입니다.

CloudWatch는 지표를 사용하여 리소스의 데이터 포인트를 나타냅니다. AWS 서비스는 지표를 CloudWatch로 전송합니다. 그러면 CloudWatch가 이러한 지표를 사용하여 시간 경과에 따라 성능이 어떻게 변화했는지 보여주는 그래프를 자동으로 생성합니다. 

아마존 CloudWatch CloudWatchAmazon은 개발자, 시스템 운영자, 사이트 신뢰성 엔지니어 (SRE) 및 IT 관리자를 위해 구축된 모니터링 및 관리 서비스입니다. CloudWatch애플리케이션을 모니터링하고, 시스템 전반의 성능 변화를 이해하고 이에 대응하며, 리소스 사용률을 최적화하고, 운영 상태를 통합적으로 파악할 수 있는 데이터와 실행 가능한 통찰력을 제공합니다. 

 

 

CloudWatch Logs: 로그 데이터를 저장하고 모니터링하는 중앙 저장소.

 

VPC Flow Logs: VPC 네트워크 트래픽의 메타데이터를 캡처.

 

CloudTrail Insights

CloudTrail에서 CloudTrail Insights를 활성화할 수도 있습니다. 이 옵션 기능을 사용하면 CloudTrail이 AWS 계정에서 비정상적인 API 활동을 자동으로 감지할 수 있습니다. 

예를 들어 CloudTrail Insights는 최근에 계정에서 평소보다 많은 수의 Amazon EC2 인스턴스가 시작되었음을 감지할 수 있습니다. 그러면 전체 이벤트 세부 정보를 검토하여 다음에 수행해야 할 작업을 결정할 수 있습니다.

 

 

 

 

 

AWS CloudTrail

AWS CloudTrail은 계정에 대한 API 호출을 기록합니다. 기록되는 정보에는 API 호출자 ID, API 호출 시간, API 호출자의 소스 IP 주소 등이 포함됩니다. CloudTrail은 누군가 남긴 이동 경로(또는 작업 로그)의 ‘추적’으로 생각할 수 있습니다.

기억하다시피 API 호출을 사용하여 AWS 리소스를 프로비저닝, 관리 및 구성할 수 있습니다. CloudTrail을 사용하여 애플리케이션 및 리소스에 대한 사용자 활동 및 API 호출의 전체 내역을 볼 수 있습니다. 

이벤트는 일반적으로 API 호출 후 15분 이내에 CloudTrail에서 업데이트됩니다. API 호출이 발생한 날짜 및 시간, 작업을 요청한 사용자, API 호출에 포함된 리소스 유형 등을 지정하여 이벤트를 필터링할 수 있습니다.

 

 

 

 

AWS X-Ray는 분산 애플리케이션을 분석하고 디버그하는 데 도움을 주는 서비스입니다. 이를 통해 개발자는 애플리케이션의 성능 문제와 오류를 파악하고, 애플리케이션의 각 구성 요소가 상호작용하는 방식을 시각화할 수 있습니다.

AWS X-Ray의 주요 기능은 다음과 같습니다:

1. 분산 추적: 애플리케이션의 요청이 여러 서비스와 리소스를 거치는 경로를 추적할 수 있습니다. 이를 통해 애플리케이션의 성능 병목 지점을 파악할 수 있습니다.
2. 서비스 맵: 애플리케이션의 아키텍처를 그래픽으로 표현하여 서비스 간의 상호작용을 시각적으로 이해할 수 있습니다.
3. 성능 분석: 각 서비스 호출에 대한 지연 시간, 오류 비율, 기타 메트릭을 분석하여 성능 문제를 파악할 수 있습니다.
4. 디버깅 및 오류 분석: 오류가 발생한 요청의 전체 경로를 추적하여 문제의 원인을 신속하게 찾을 수 있습니다.
5. 통합: AWS Lambda, Amazon EC2, Amazon ECS, Amazon API Gateway 등 다양한 AWS 서비스와 통합되어 손쉽게 추적 데이터를 수집할 수 있습니다.

AWS X-Ray는 특히 복잡한 마이크로서비스 아키텍처에서 각 서비스 간의 호출 관계를 파악하고, 성능 최적화를 위해 중요한 도구로 사용될 수 있습니다. 이를 통해 개발자는 더 빠르게 문제를 해결하고, 애플리케이션의 전반적인 성능과 안정성을 개선할 수 있습니다.

 

 

 

 

 

AWS Trusted Advisor

AWS Trusted Advisor는 AWS 환경을 검사하고 AWS 모범 사례에 따라 실시간 권장 사항을 제시하는 웹 서비스입니다.

Trusted Advisor는 비용 최적화, 성능, 보안, 내결함성, 서비스 한도라는 5개 범주에서 결과를 AWS 모범 사례와 비교합니다. Trusted Advisor는 각 범주의 검사에 대해 권장 작업 목록을 제공하고 AWS 모범 사례를 자세히 알아볼 수 있는 추가 자료를 제공합니다. 

AWS Trusted Advisor가 제공하는 권장 사항은 배포의 모든 단계에서 유용할 수 있습니다. 예를 들어 새로운 워크플로를 만들고 새로운 애플리케이션을 개발하는 데 AWS Trusted Advisor의 도움을 받을 수 있습니다. 또는 기존 애플리케이션 및 리소스를 지속적으로 개선하는 데 활용할 수 있습니다.

 

 

 

 

 

 

AWS Lambda의 경우 함수 요청 수와 함수 실행 시간을 기준으로 요금이 청구됩니다.

AWS Lambda에서는 매월 무료 요청 1백만 건과 최대 320만 초의 컴퓨팅 시간을 사용할 수 있습니다.

Compute Savings Plan에 가입하면 AWS Lambda 비용을 절감할 수 있습니다. Compute Savings Plan은 1년 또는 3년 기간 동안 일정 사용량을 약정하는 대신 컴퓨팅 비용을 할인합니다. 이는 예약하는 경우 비용 감소의 예입니다. 

 

 

 

 

AWS 요금 적용 방식

실제 사용한 만큼만 지불합니다.

예약하는 경우 비용이 감소합니다.

많이 사용할수록 볼륨 기반 할인으로 비용이 감소합니다.

 

 

 

 

Amazon EC2를 사용하면 인스턴스가 실행되는 동안 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.

일부 워크로드의 경우 스팟 인스턴스를 사용하여 Amazon EC2 비용을 대폭 절감할 수 있습니다. 예를 들어 중단을 견딜 수 있는 배치 처리 작업을 실행한다고 가정해 보겠습니다. 스팟 인스턴스를 사용하면 워크로드의 가용성 요구 사항을 충족하면서 최대 90%의 비용을 절감할 수 있습니다.

Savings Plans 및 예약 인스턴스를 고려하면 Amazon EC2 비용을 추가로 절감할 수 있습니다.

 

 

 

 

 

Amazon S3 요금의 경우 다음 비용 구성 요소를 고려합니다.

• 스토리지 - 사용한 스토리지에 대해서만 요금을 지불합니다. 객체의 크기, 스토리지 클래스, 해당 월에 각 객체를 저장한 기간에 따라 Amazon S3 버킷에 객체를 저장하는 요금이 청구됩니다.
• 요청 및 데이터 검색 - Amazon S3 객체 및 버킷에 수행한 요청에 대해 비용을 지불합니다. 예를 들어 사진 파일을 Amazon S3 버킷에 저장하고 웹 사이트에서 호스팅한다고 가정해 보겠습니다. 방문자가 이러한 사진 파일이 게시된 웹 사이트를 요청할 때마다 비용을 지불해야 하는 요청이 계산됩니다.
• 데이터 전송 - 다른 Amazon S3 버킷 간에 데이터를 전송하거나 Amazon S3에서 동일한 AWS 리전의 다른 서비스로 데이터를 전송하는 데 드는 비용은 없습니다. 하지만 Amazon S3에서 송수신한 데이터에 대해서는 비용을 지불해야 합니다. 다만 다음과 같은 몇 가지 예외가 있습니다. 인터넷에서 Amazon S3로 전송되는 데이터 또는 Amazon CloudFront로 전송되는 데이터에 대해서는 비용이 들지 않습니다. 또한 Amazon S3 버킷과 동일한 AWS 리전에 있는 Amazon EC2 인스턴스로 전송되는 데이터도 비용이 들지 않습니다.
• 관리 및 복제 - 계정의 Amazon S3 버킷에서 활성화한 스토리지 관리 기능에 대해 비용을 지불합니다. 이러한 기능에는 Amazon S3 인벤토리, 분석, 객체 태그 지정이 포함됩니다.

 

 

 

 

AWS Cost Explorer

AWS Cost Explorer는 시간 경과에 따라 AWS 비용 및 사용량을 시각화, 이해, 관리할 수 있는 도구입니다.

AWS Cost Explorer에는 발생 비용 기준 상위 5개 AWS 서비스의 비용 및 사용량에 대한 기본 보고서가 포함되어 있습니다. 사용자 지정 필터 및 그룹을 적용하여 데이터를 분석할 수 있습니다. 예를 들어 시간별로 리소스 사용량을 확인할 수 있습니다.

 

AWS Cost Explorer

 AWS Cost Explorer시간 경과에 따른 비용 및 사용량을 시각화하고, 이해하고, 관리할 수 AWS 있는 easy-to-use 인터페이스가 있습니다. 높은 수준 (예: 전체 계정의 총 비용 및 사용량) 과 매우 구체적인 요청 (예: “" 태그가 지정된 계정 Y 내 m2.2xlarge 비용) 에 대한 비용 및 사용 데이터를 분석하는 사용자 지정 보고서 (차트 및 표 형식 데이터 포함) 를 생성하여 빠르게 시작할 수 있습니다. project: secretProject

 

 

 

 

AWS Budgets 

AWS Budgets비용 또는 사용량이 예산 금액을 초과하거나 초과할 것으로 예상되는 경우 알려주는 사용자 지정 예산을 설정할 수 있습니다. 를 사용하여 RI AWS Budgets 사용률 또는 적용 범위 목표를 설정하고 사용률이 정의된 임계값 아래로 떨어지면 알림을 받을 수도 있습니다. RI 알림은 아마존 EC2, 아마존 RDS, 아마존 Redshift 및 아마존 예약을 지원합니다. ElastiCache예산은 월별, 분기별 또는 연간 수준에서 추적할 수 있으며 시작일과 종료일을 사용자 지정할 수 있습니다. 예산을 추가로 조정하여 AWS 서비스, 연결 계정, 태그 등과 같은 여러 차원과 관련된 비용을 추적할 수 있습니다. 예산 알림은 이메일 및/또는 Amazon Simple Notification Service (Amazon SNS) 주제를 통해 전송할 수 있습니다. AWS Budgets 대시보드 또는 API를 통해 예산을 생성하고 추적할 수 있습니다. AWS Budgets

 

 

 

Developer Support 플랜을 보유한 고객은 다음과 같은 기능에 액세스할 수 있습니다.

• 모범 사례 지침
• 클라이언트 측 진단 도구
• AWS 제품, 기능 및 서비스를 함께 사용하는 방법에 대한 지침으로 구성된 빌딩 블록 아키텍처 지원

예를 들어 회사에서 AWS 서비스를 탐색한다고 가정해 보겠습니다. 여러분은 몇 가지 AWS 서비스에 대해 들었습니다. 그러나 이러한 서비스를 함께 사용하여 회사의 요구 사항을 해결할 수 있는 애플리케이션을 빌드하는 방법은 잘 모르겠습니다. 이 시나리오에서는 Developer Support 플랜에 포함된 빌딩 블록 아키텍처 지원을 통해 특정 서비스 및 기능을 결합할 수 있는 기회를 파악할 수 있습니다.

 

 

 

 

Business Support 플랜을 보유한 고객은 다음과 같은 추가 기능에 액세스할 수 있습니다.

• 특정 요구 사항을 가장 잘 지원할 수 있는 AWS 제품, 기능 및 서비스를 식별하기 위한 사용 사례 지침
• 모든 AWS Trusted Advisor 검사
• 일반적인 운영 체제 및 애플리케이션 스택 구성 요소와 같은 타사 소프트웨어에 대한 제한된 지원

회사가 Business Support 플랜을 보유 중이고 Amazon EC2 인스턴스에 일반적인 타사 운영 체제를 설치하려고 한다고 가정해 보겠습니다. AWS Support에 운영 체제 설치, 구성 및 문제 해결에 대한 지원을 요청할 수 있습니다. 성능 최적화, 사용자 지정 스크립트 사용 또는 보안 문제 해결과 같은 고급 항목의 경우에는 타사 소프트웨어 공급자에게 직접 문의해야 할 수 있습니다.

 

 

 

 

 

 

Enterprise Support 플랜을 보유한 고객은 Basic, Developer 및 Business Support 플랜에 포함된 모든 기능 외에도 다음과 같은 기능에 액세스할 수 있습니다.

• 회사의 특정 사용 사례 및 애플리케이션을 지원하기 위한 컨설팅 관계인 애플리케이션 아키텍처 지침
• 인프라 이벤트 관리 지원: 회사가 사용 사례를 더 잘 이해할 수 있도록 돕는 AWS Support와의 단기 계약입니다. 또한 회사에 아키텍처 및 확장 지침도 제공합니다.
• 기술 계정 관리자

 

 

 

 

 

기술 지원 관리자(TAM)

Enterprise Support 플랜에는 기술 지원 관리자(TAM)에 대한 액세스가 포함됩니다.

회사에 Enterprise Support 플랜이 있는 경우 TAM이 AWS 측 주 연락 창구입니다. 여러분이 애플리케이션을 계획, 배포, 최적화할 때 TAM이 지속적으로 커뮤니케이션하면서 권장 사항, 아키텍처 검토를 제공합니다. 

TAM은 모든 AWS 서비스에 대한 전문 지식을 제공합니다. 통합 접근 방식을 통해 여러 서비스를 함께 효율적으로 사용하는 솔루션을 설계하는 과정을 도울 수 있습니다.

 

 

 

 

 

AWS Marketplace

AWS Marketplace는 Independent Software Vendor(ISV)의 소프트웨어 리스팅 수천 개가 포함된 디지털 카탈로그입니다. AWS Marketplace를 이용하여 AWS에서 실행되는 소프트웨어를 검색하고 평가하고 구매할 수 있습니다. 

AWS Marketplace의 각 리스팅에 대해 요금 옵션, 사용 가능한 지원 및 다른 AWS 고객의 리뷰 등 자세한 정보에 액세스할 수 있습니다.

산업 및 사용 사례별로 소프트웨어 솔루션을 탐색할 수도 있습니다. 예를 들어 회사가 의료 산업에 속해 있다고 가정해 보겠습니다. AWS Marketplace에서 환자 기록을 보호하기 위한 솔루션을 구현하거나 기계 학습 모델을 사용하여 환자의 병력을 분석하고 잠재적 건강 위험을 예측하는 등 소프트웨어가 도움이 되는 사용 사례를 검토할 수 있습니다.

 

AWS Marketplace는 한마디로 **"클라우드용 앱스토어"**라고 생각하시면 됩니다.

개인이 스마트폰에 앱을 설치하듯, 기업이 AWS 환경에서 필요한 소프트웨어를 복잡한 설치 과정 없이 클릭 몇 번으로 바로 구매하고 실행할 수 있는 온라인 상점입니다.

---

1. 주요 특징

• 즉시 사용: OS, 보안 도구, 데이터베이스, ERP 등 수천 개의 소프트웨어가 **AMI(Amazon Machine Image)**나 SaaS, 컨테이너 형태로 미리 구성되어 있습니다.
• 통합 빌링 (Billing): 여러 업체에서 소프트웨어를 사더라도 비용은 매달 나오는 AWS 청구서에 합산되어 나옵니다. 결제 관리가 매우 편하죠.
• 다양한 요금제: 무료 체험(Free Trial)부터 시간당 과금, 월정액, 연간 계약 등 다양한 옵션을 선택할 수 있습니다.

---

2. 왜 Marketplace를 사용하나요?

1. 시간 단축: 직접 서버를 세팅하고 소프트웨어를 설치 및 설정하는 수고를 덜어줍니다.
2. 검증된 보안: AWS가 사전에 보안 검사를 마친 신뢰할 수 있는 벤더(Cisco, Palo Alto, SAP 등)의 제품이 등록되어 있습니다.
3. 최신 버전 유지: 소프트웨어 공급업체가 업데이트를 관리하므로 항상 최신 기능을 사용할 수 있습니다.

 

---

 

 

AWS 요금 계산기

AWS 요금 계산기를 사용하면 AWS 서비스를 탐색하고 AWS 기반 사용 사례에 대한 비용을 추정할 수 있습니다. AWS 비용 추정을 정의된 그룹별로 구성할 수 있습니다. 그룹은 비용 센터별로 비용 추정을 제공하는 등 회사 조직 구성을 반영할 수 있습니다.

 

 

 

AWS 결제 및 비용 관리 대시보드를 사용하여 AWS 청구서를 결제하고, 사용량을 모니터링하고, 비용을 분석 및 제어할 수 있습니다.

• 이번 달 누계 금액을 지난 달과 비교하고 현재 사용량을 기준으로 내달 사용량을 예측합니다.
• 서비스별 월 누계 지출을 확인합니다.
• 서비스별 프리 티어 사용량을 확인합니다.
• Cost Explorer에 액세스하여 예산을 생성합니다.
• Savings Plans를 구매하고 관리합니다.
• AWS 비용 및 사용 보고서를 게시합니다.

 

 

 

통합 결제

이전 모듈에서는 중앙 위치에서 여러 AWS 계정을 관리할 수 있는 서비스인 AWS Organizations에 대해 알아보았습니다. 또한 AWS Organizations는 통합 결제 옵션을 제공합니다. 

AWS Organizations의 통합 결제 기능을 사용하면 조직의 모든 AWS 계정에 대한 단일 청구서를 받을 수 있습니다. 결제를 통합하면 조직에 있는 모든 연결 계정의 결합된 비용을 손쉽게 추적할 수 있습니다. 기본적으로 조직에 허용되는 최대 계정 수는 4개이지만, 필요한 경우 AWS Support에 문의하여 할당량을 늘릴 수 있습니다.

월별 청구서에서 각 계정에서 발생한 항목별 요금을 검토할 수 있습니다. 그러므로 단일 월별 청구서의 편의성은 유지하면서도 조직의 계정에 대한 투명성을 높일 수 있습니다.

통합 결제의 또 다른 이점은 조직의 계정 전체에서 대량 할인 요금, Savings Plans 및 예약 인스턴스를 공유할 수 있다는 것입니다. 예를 들어 한 계정에서 월별 사용량이 부족하여 할인 가격을 적용받지 못할 수 있습니다. 그러나 여러 계정을 결합하는 경우 사용량이 집계되므로 혜택이 조직의 모든 계정에 적용될 수 있습니다.

 

 

 

 

 

 

AWS 예산

AWS 예산에서 예산을 생성하여 서비스 사용, 서비스 비용 및 인스턴스 예약을 계획할 수 있습니다.

AWS 예산에서는 정보가 하루에 세 번 업데이트됩니다. 그러므로 사용량이 예산 금액 또는 AWS 프리 티어 한도에 얼마나 근접한지 정확하게 파악할 수 있습니다.

AWS 예산에서 사용량이 예산 금액을 초과하거나 초과할 것으로 예상되면 알려주는 사용자 지정 알림을 설정할 수도 있습니다.

 

 

 

 

 

AWS Cost Explorer

AWS Cost Explorer는 시간 경과에 따라 AWS 비용 및 사용량을 시각화, 이해, 관리할 수 있는 도구입니다.

AWS Cost Explorer에는 발생 비용 기준 상위 5개 AWS 서비스의 비용 및 사용량에 대한 기본 보고서가 포함되어 있습니다. 사용자 지정 필터 및 그룹을 적용하여 데이터를 분석할 수 있습니다. 예를 들어 시간별로 리소스 사용량을 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

• 예상 AWS 사용량을 기준으로 월말 비용을 검토 - 이 작업은 AWS 예산에서 수행할 수 있습니다.
• AWS 기반 사용 사례에 대한 비용을 추정 - 이 작업은 AWS 요금 계산기에서 수행할 수 있습니다.
• 시간 경과에 따라 AWS 비용 및 사용량을 시각화 및 관리 - 이 작업은 AWS Cost Explorer에서 수행할 수 있습니다.

 

AWS 예산에서 서비스 사용량이 예산 금액을 초과하거나 초과할 것으로 예상되는 경우 알려주는 사용자 지정 알림을 설정할 수 있습니다.

 

예산은 비용 또는 사용량을 기준으로 수립할 수 있습니다. 예를 들어 Amazon EC2에서 100.00 USD의 비용이 발생하거나 AWS Lambda에서 500,000건의 요청이 발생했을 때 알려주는 알림을 설정할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

Cloud Adoption Framework의 6가지 주요 관점

가장 간단하게 볼 때 AWS Cloud Adoption Framework(AWS CAF)는 지침을 6가지 초점 영역(관점)으로 구성합니다. 각 관점은 별개의 책임을 해결합니다. 계획 프로세스는 조직 전체에서 적합한 인물들이 앞으로의 변화에 대비할 수 있도록 도와줍니다.

일반적으로 비즈니스, 인력 및 거버넌스 관점은 비즈니스 기능에 중점을 두지만 플랫폼, 보안 및 운영 관점은 기술 역량에 중점을 둡니다.

 

 

 

 

비즈니스 관점은 IT가 비즈니스 요구 사항을 반영하고 IT 투자가 주요 비즈니스 결과와 연계되도록 보장합니다.

비즈니스 관점을 사용하여 클라우드 채택을 위한 강력한 비즈니스 사례를 설정하고 클라우드 채택 이니셔티브의 우선 순위를 지정합니다. 비즈니스 전략 및 목표가 IT 전략 및 목표에 부합하는지 확인합니다.

비즈니스 관점의 일반적인 역할은 다음과 같습니다. 

• 비즈니스 관리자
• 재무 관리자
• 예산 소유자
• 전략 이해당사자

 

 

 

인력 관점은 클라우드 채택을 성공하기 위한 조직 전반의 변화 관리 전략 개발을 지원합니다.

인력 관점을 사용하여 조직 구조 및 역할, 새로운 기술 및 프로세스 요구 사항을 평가하고 격차를 파악합니다. 이를 통해 교육, 인력 배치 및 조직 변화의 우선 순위를 지정할 수 있습니다.

인력 관점의 일반적인 역할은 다음과 같습니다. 

• 인사 관리
• 인력 배치
• 인력 관리자

 

 

 

거버넌스 관점은 IT 전략이 비즈니스 전략에 부합하도록 조정하는 기술 및 프로세스에 중점을 둡니다. 이를 통해 비즈니스 가치를 극대화하고 위험을 최소화할 수 있습니다.

 

거버넌스 관점을 사용하여 클라우드에서 비즈니스 거버넌스를 보장하는 데 필요한 직원 기술 및 프로세스를 업데이트하는 방법을 이해합니다. 클라우드 투자를 관리하고 측정하여 비즈니스 성과를 평가합니다.

 

거버넌스 관점의 일반적인 역할은 다음과 같습니다. 

• 최고 정보 책임자(CIO)
• 프로그램 관리자
• 엔터프라이즈 아키텍트
• 비즈니스 분석가
• 포트폴리오 관리자

 

보안 관점은 조직이 가시성, 감사 가능성, 제어 및 민첩성에 대한 보안 목표를 충족하도록 보장합니다. 

AWS CAF를 사용하여 조직의 요구 사항에 맞춰 보안 제어의 선택 및 구현을 구성합니다.

보안 관점의 일반적인 역할은 다음과 같습니다. 

• 최고 정보 보안 책임자(CISO)
• IT 보안 관리자
• IT 보안 분석가

 

플랫폼 관점에는 클라우드를 기반으로 새로운 솔루션을 구현하고 온프레미스 워크로드를 클라우드로 마이그레이션하기 위한 원칙과 패턴이 포함됩니다.

다양한 아키텍처 모델을 사용하여 IT 시스템의 구조와 그 관계를 이해하고 전달합니다. 대상 상태 환경의 아키텍처를 자세히 설명합니다.

플랫폼 관점의 일반적인 역할은 다음과 같습니다. 

• 최고 기술 책임자(CTO)
• IT 관리자
• 솔루션스 아키텍트

 

운영 관점은 비즈니스 이해당사자와 합의된 수준까지 IT 워크로드를 구현, 실행, 사용, 운영 및 복구하는 데 도움이 됩니다.

일별, 분기별 및 연간으로 비즈니스를 수행하는 방법을 정의합니다. 비즈니스 운영을 반영하고 지원합니다. AWS CAF는 이러한 이해당사자가 현재 운영 절차를 정의하고 성공적인 클라우드 채택을 구현하는 데 필요한 프로세스 변경 및 교육을 파악할 수 있도록 지원합니다.

운영 관점의 일반적인 역할은 다음과 같습니다. 

• IT 운영 관리자
• IT 지원 관리자

 

 

 

 

 

 

 

6가지 마이그레이션 전략

애플리케이션을 클라우드로 마이그레이션할 때 구현할 수 있는 가장 일반적인 6가지 마이그레이션 전략은 다음과 같습니다.

• 리호스팅(Rehosting)
• 리플랫포밍(Replatforming)
• 리팩터링(Refactoring)/아키텍처 재설계(Re-architecting)
• 재구매(Repurchasing)
• 유지(Retaining)
• 폐기(Retiring)

‘리프트 앤 시프트(lift-and-shift)’라고도 하는 리호스팅에서는 애플리케이션을 변경 없이 이전합니다. 

기업이 마이그레이션을 구현하고 신속하게 확장하여 비즈니스 사례를 충족하기를 원하는 대규모 레거시 마이그레이션의 시나리오에서는 대부분의 애플리케이션이 리호스팅됩니다.  

 

리프트 앤 시프트 및 수정(lift, tinker, and shift)이라고도 하는 리플랫포밍에서는 실질적인 이점을 실현하기 위해 몇 가지 클라우드 최적화를 수행해야 합니다. 최적화는 애플리케이션의 핵심 아키텍처를 변경하지 않고 달성됩니다.

 

리팩터링(아키텍처 재설계라고도 함)에서는 클라우드 네이티브 기능을 사용하여 애플리케이션을 설계하고 개발하는 방식을 재구성합니다. 일반적으로 리팩터링은 비즈니스 요구 사항으로 인해, 다른 방법으로는 기존 환경의 애플리케이션에서 실현하기가 까다로운 기능 추가, 확장 또는 성능 개선의 필요성이 클 때 활용됩니다.

 

재구매에서는 기존 라이선스를 Software-as-a-Service 모델로 전환합니다. 

예를 들어 기업은 고객 관계 관리(CRM) 시스템에서 Salesforce.com으로 마이그레이션하여 재구매 전략을 구현할 수 있습니다.

 

유지에서는 비즈니스에 중요한 애플리케이션을 소스 환경에 유지합니다. 여기에는 마이그레이션하려면 대규모 리팩토링이 필요한 애플리케이션 또는 이후로 연기할 수 있는 워크로드가 포함될 수 있습니다.

 

폐기는 더 이상 필요하지 않은 애플리케이션을 제거하는 프로세스입니다.

 

 

 

 

 

 

 

AWS Snow 패밀리 멤버

AWS Snow 패밀리는 AWS와 고객 간에 최대 엑사바이트 규모의 데이터를 물리적으로 이동할 수 있는 물리적 디바이스 모음입니다. 

AWS Snow 패밀리는 AWS Snowcone, AWS Snowball 및 AWS Snowmobile로 구성되어 있습니다.

 

AWS Snowcone은 작고 견고하며 안전한 엣지 컴퓨팅 및 데이터 전송 디바이스입니다. 

CPU 2개, 4GB 메모리 및 8TB의 가용 스토리지를 갖추고 있습니다.

 

AWS Snowball은 두 가지 유형의 디바이스를 제공합니다.

Snowball Edge: 물리적 하드웨어 장치를 배송받아 데이터를 복사한 뒤 AWS로 다시 보내는 방식. 인터넷 속도가 느리거나 데이터 양이 테라바이트(TB) 이상일 때 유리합니다.

• Snowball Edge Storage Optimized 디바이스는 대규모 데이터 마이그레이션 및 반복 전송 워크플로뿐 아니라 큰 용량이 필요한 로컬 컴퓨팅에 적합합니다. 
  • 스토리지: 블록 볼륨 및 Amazon S3 호환 객체 스토리지를 위한 80TB의 하드 디스크 드라이브(HDD) 용량, 블록 볼륨을 위한 1TB의 SATA 솔리드 스테이트 드라이브(SSD) 용량. 
  • 컴퓨팅: Amazon EC2 sbe1 인스턴스(C5와 동등)를 지원하기 위한 40개의 vCPU와 80GiB의 메모리.
• Snowball Edge Compute Optimized는 기계 학습, 풀 모션 비디오 분석, 분석 및 로컬 컴퓨팅 스택과 같은 사용 사례를 위한 강력한 컴퓨팅 리소스를 제공합니다. 
  • 스토리지: Amazon S3 호환 객체 스토리지 또는 Amazon EBS 호환 블록 볼륨을 위한 42TB의 가용 HDD 용량과 Amazon EBS 호환 블록 볼륨을 위한 7.68TB의 가용 NVMe SSD 용량. 
  • 컴퓨팅: 52개의 vCPU, 208GiB 메모리 및 NVIDIA Tesla V100 GPU 옵션. 디바이스는 C5, M5a, G3 및 P3 인스턴스와 동등한 Amazon EC2 sbe-c 및 sbe-g 인스턴스를 실행합니다.

AWS Snowmobile은 대용량 데이터를 AWS로 이동하는 데 사용하는 엑사바이트 규모의 데이터 전송 서비스입니다. 

 

세미 트레일러 트럭으로 견인되는 45피트 길이의 견고한 운반 컨테이너인 Snowmobile 1대당 최대 100페타바이트의 데이터를 전송할 수 있습니다.

 

 

 

📊 한방 비교표

서비스용량특징시험 키워드

Snowcone	소형	휴대성	IoT / 원격
Snowball Storage	대용량	마이그레이션	네트워크 부족
Snowball Compute	대용량 + 컴퓨팅	Edge 분석	ML
Snowmobile	초대형	트럭	PB 이상

 

---

 

 

 

 

기존의 기계 학습(ML) 개발은 복잡하고, 비용이 많이 들고, 시간이 오래 걸리고, 오류가 발생하기 쉽습니다. AWS는 이 프로세스에서 어려운 작업을 제거하여 ML 모델을 신속하게 빌드, 훈련, 배포하는 데 사용할 수 있는 Amazon SageMaker를 제공합니다.

 

 

 

 

Amazon Lex에서는 애플리케이션에서 사용할 대화형 챗봇을 신속하게 빌드, 테스트 및 배포할 수 있습니다.

 

 

 

 

 

 

 

AWS Well-Architected 프레임워크

AWS Well-Architected 프레임워크는 AWS 클라우드에서 안정적이고 안전하며 효율적이고 비용 효율적인 시스템을 설계하고 운영하는 방법을 이해하는 데 도움이 됩니다. 모범 사례 및 설계 원칙에 따라 아키텍처를 지속적으로 측정하고 개선할 영역을 파악할 수 있습니다.

Well-Architected 프레임워크는 5가지 핵심 요소를 기반으로 합니다.

• 운영 우수성
• 보안성
• 안정성
• 성능 효율성
• 비용 최적화

 

 

운영 우수성은 시스템을 실행 및 모니터링하여 비즈니스 가치를 제공하고 지속적으로 지원 프로세스 및 절차를 개선하는 능력입니다.  

클라우드에서의 운영 우수성을 위한 설계 원칙에는 코드로 작업 수행, 문서에 주석 추가, 실패 예측, 되돌릴 수 있는 소규모 변경을 자주 수행이 포함됩니다.

 

 

 

보안성 핵심 요소는 위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하는 동시에 정보, 시스템, 자산을 보호하는 능력입니다. 

아키텍처의 보안을 고려할 때 다음 모범 사례를 적용합니다.

• 가능한 한 보안 모범 사례를 자동화합니다.
• 모든 계층에 보안을 적용합니다.
• 전송 중/저장 시 데이터를 보호합니다.

 

안정성은 시스템에서 다음을 수행하는 능력입니다.

• 인프라 또는 서비스 중단으로부터 복구
• 컴퓨팅 리소스를 동적으로 확보하여 수요를 충족
• 잘못된 구성 또는 일시적인 네트워크 문제와 같은 중단 완화

안정성에는 복구 절차 테스트, 전체 시스템 가용성을 높이기 위한 수평 확장, 장애 발생 시 자동 복구가 포함됩니다.

 

 

 

성능 효율성은 컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고, 수요 변화와 기술 진화에 따라 이러한 효율성을 유지하는 능력입니다. 

아키텍처 성능 효율성 평가에는 실험 빈도 증가, 서버리스 아키텍처 사용, 몇 분 만에 전 세계 배포가 가능한 시스템 설계 등이 포함됩니다.

 

 

 

비용 최적화는 가장 낮은 가격으로 비즈니스 가치를 제공하도록 시스템을 실행하는 능력입니다.

비용 최적화에는 소비 모델 채택, 비용 분석 및 귀속, 관리형 서비스를 사용하여 소유 비용 절감이 포함됩니다.

 

 

 

 

 

 

클라우드 컴퓨팅의 이점

AWS 클라우드에서 운영하면 온프레미스 또는 하이브리드 환경의 컴퓨팅에 비해 많은 이점이 있습니다. 

이 섹션에서는 클라우드 컴퓨팅의 6가지 이점에 대해 알아봅니다.

• 선행 비용을 가변 비용으로 대체
• 거대한 규모의 경제로 얻는 이점
• 용량 추정 불필요
• 속도 및 민첩성 개선
• 데이터 센터 운영 및 유지 관리에 비용 투자 불필요
• 몇 분 만에 전 세계에 배포

 

 

 

선행 비용에는 컴퓨팅 리소스를 사용하기 전에 투자해야 하는 데이터 센터, 물리적 서버 및 기타 리소스가 포함됩니다.

어떻게 사용할지 결정하기도 전에 데이터 센터와 서버에 대규모로 투자하는 대신, 컴퓨팅 리소스를 사용할 때만 비용을 지불할 수 있습니다.

 

 

클라우드 컴퓨팅을 사용하면 인프라를 소유할 때보다 가변 비용이 낮아집니다.

수많은 고객의 사용량이 클라우드에 누적되므로 AWS와 같은 공급자는 더 높은 규모의 경제를 달성할 수 있습니다. 규모의 경제는 더 저렴한 종량 과금제로 전환됩니다.

 

 

클라우드 컴퓨팅에서는 애플리케이션을 배포하기 전에 필요한 인프라 용량을 예측할 필요가 없습니다.

예를 들어 필요할 때 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 시작하고, 사용한 컴퓨팅 시간에 대해서만 비용을 지불할 수 있습니다. 사용하지 않는 리소스에 비용을 지불하거나 제한된 용량과 씨름하는 대신 필요한 용량에만 액세스하고 수요에 따라 확장 또는 축소할 수 있습니다. 

 

 

 

클라우드 컴퓨팅의 유연성 덕분에 애플리케이션을 더욱 쉽게 개발하고 배포할 수 있습니다.

또한 이 덕분에 개발 팀이 실험과 혁신에 더 많은 시간을 투자할 수 있습니다.

 

 

데이터 센터에서 클라우드 컴퓨팅을 사용하려면 인프라 및 서버 관리에 더 많은 비용과 시간을 소비해야 하는 경우가 많습니다.

클라우드 컴퓨팅의 이점은 이러한 작업에 신경을 덜 쓰고 애플리케이션과 고객에 더 집중할 수 있다는 점입니다.

 

 

AWS 클라우드는 글로벌 입지를 확보하고 있어 전 세계 고객에게 짧은 지연 시간을 제공하면서 애플리케이션을 신속하게 배포할 수 있습니다.

 

 

 

 

 

• Amazon Lex는 음성 및 텍스트를 사용하여 대화형 인터페이스를 빌드할 수 있는 서비스입니다.
• Amazon Textract는 스캔한 문서에서 텍스트 및 데이터를 자동으로 추출하는 기계 학습 서비스입니다.
• Amazon Augmented AI(Amazon A2I)는 콘텐츠 조정, 문서에서 텍스트 추출 등 일반적인 기계 학습 사용 사례에 대한 인적 검토 워크플로를 기본 제공합니다. Amazon A2I를 사용하면 Amazon SageMaker 또는 기타 도구를 기반으로 빌드된 기계 학습 모델을 위한 자체 워크플로를 생성할 수도 있습니다.

• Amazon Aurora는 엔터프라이즈급 관계형 데이터베이스입니다.

 

 

 

 

 

S3 Intelligent-Tiering 스토리지 클래스에서는 Amazon S3가 객체의 액세스 패턴을 모니터링합니다. 사용자가 30일 연속 객체에 액세스하지 않으면 Amazon S3는 자동으로 해당 객체를 자주 사용하지 않는 액세스 계층인 S3 Standard-IA로 이동합니다. 사용자가 자주 사용하지 않는 액세스 계층에 저장된 객체에 액세스하면 Amazon S3는 자동으로 해당 객체를 자주 사용하는 액세스 계층인 S3 Standard로 이동합니다.

 

 

Amazon S3는 저장한 용량만큼만 비용을 지불하며, 관리 오버헤드가 거의 없습니다.

 

 

S3 Standard

• 자주 액세스하는 데이터용으로 설계
• 최소 3개의 가용 영역에 데이터를 저장

S3 Standard는 객체에 대한 고가용성을 제공합니다. 따라서 웹 사이트, 콘텐츠 배포, 데이터 분석 등 광범위한 사용 사례에 적합합니다. S3 Standard는 자주 액세스하지 않는 데이터 및 보관 스토리지를 위한 다른 스토리지 클래스보다 비용이 높습니다.

어떤 데이터든 저장할 수 있고 즉시 꺼낼 수 있는 범용 저장소입니다.

✔ 밀리초 단위 접근

S3 Standard는 즉시 접근 가능 (millisecond latency)

✔ 30일 보관

짧은 기간 → Standard가 가장 적합

✔ 데이터 크기 작음 (300MB/월)

→ 비용 거의 무시 수준

✔ JSON 파일 저장

→ 오브젝트 스토리지에 딱 맞음

 

 

 

 

 

 

S3 Standard-Infrequent Access(S3 Standard-IA)

• 자주 액세스하지 않는 데이터에 이상적
• S3 Standard와 비슷하지만 스토리지 가격은 더 저렴하고 검색 가격은 더 높음

S3 Standard-IA는 자주 액세스하지 않지만 필요에 따라 고가용성이 요구되는 데이터에 이상적입니다. S3 Standard 및 S3 Standard-IA는 모두 최소 3개의 가용 영역에 데이터를 저장합니다. S3 Standard-IA는 S3 Standard와 동일한 수준의 가용성을 제공하지만 스토리지 가격은 더 저렴하고 검색 가격은 더 높습니다.

 

 

 

 

S3 One Zone-Infrequent Access(S3 One Zone-IA)

• 단일 가용 영역에 데이터를 저장
• S3 Standard-IA보다 낮은 스토리지 가격

최소 3개의 가용 영역에 데이터를 저장하는 S3 Standard 및 S3 Standard-IA와 달리, S3 One Zone-IA는 단일 가용 영역에 데이터를 저장합니다. 따라서 다음과 같은 조건이 적용되는 경우 고려할 수 있는 훌륭한 스토리지 클래스입니다

• 스토리지 비용을 절감하려는 경우
• 가용 영역 장애가 발생할 경우 데이터를 손쉽게 재현할 수 있는 경우

 

 

 

S3 Intelligent-Tiering

• 액세스 패턴을 알 수 없거나 자주 변화하는 데이터에 이상적
• 객체당 소량의 월별 모니터링 및 자동화 요금을 부과

S3 Intelligent-Tiering 스토리지 클래스에서는 Amazon S3가 객체의 액세스 패턴을 모니터링합니다. 사용자가 30일 연속 객체에 액세스하지 않으면 Amazon S3는 자동으로 해당 객체를 자주 사용하지 않는 액세스 계층인 S3 Standard-IA로 이동합니다. 사용자가 자주 사용하지 않는 액세스 계층에 저장된 객체에 액세스하면 Amazon S3는 자동으로 해당 객체를 자주 사용하는 액세스 계층인 S3 Standard로 이동합니다.

 

 

 

 

S3 Glacier

• 데이터 보관용으로 설계된 저비용 스토리지
• 객체를 몇 분에서 몇 시간 이내에 검색

S3 Glacier는 데이터 보관에 이상적인 저비용 스토리지 클래스입니다. 예를 들어 이 스토리지 클래스를 사용하여 보관된 고객 레코드나 이전 사진 또는 비디오 파일을 저장할 수 있습니다.

비용은 매우 저렴하지만, 데이터를 꺼내는 데(Retrieval) 수 분에서 수 시간이 걸립니다. 문제의 "밀리초 단위 액세스" 조건을 만족하지 못합니다.

 

 

 

 

 

 

S3 Glacier Deep Archive

• 보관에 이상적인 가장 저렴한 객체 스토리지 클래스
• 객체를 12시간 이내에 검색

Amazon S3 Glacier와 Amazon S3 Glacier Deep Archive 간에 결정할 때 보관된 객체를 얼마나 빨리 검색해야 하는지를 고려해야 합니다. S3 Glacier 스토리지 클래스에 저장된 객체는 몇 분에서 몇 시간 이내에 검색할 수 있습니다. 이에 비해 S3 Glacier Deep Archive 스토리지 클래스에 저장된 객체는 12시간 이내에 검색할 수 있습니다.

 

 

 

 

 

https://tbvjrornfl.tistory.com/186

알기쉬운 Amazon EC2 요금 모델 비교 정리(On-Demand, Spot, Reserved)

 

 

온디맨드 인스턴스는 중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 매우 적합합니다. 선결제 비용이나 최소 약정은 적용되지 않습니다. 인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다.

온디맨드 인스턴스의 사용 사례에는 애플리케이션 개발 및 테스트와 예측할 수 없는 사용 패턴이 있는 애플리케이션 실행이 포함됩니다. 온디맨드 인스턴스는 1년 이상 지속되는 워크로드에는 권장하지 않습니다. 이러한 워크로드는 예약 인스턴스를 사용하면 비용 절감 효과가 더 크기 때문입니다.

 

 

Savings Plans는 Amazon에서 저렴한 가격을 제공하는 유연한 가격 모델입니다.
다음을 약속하는 대가로 EC2, AWS Lambda 및 AWS Fargate 사용
1년 또는 3년 동안 일관된 사용량(시간당 $로 측정)

저축 계획
Savings Plans는 Amazon EC2, AWS에서 저렴한 가격을 제공하는 유연한 가격 모델입니다.
일관된 약속에 대한 대가로 Lambda 및 AWS Fargate 사용
1년 또는 3년 동안의 사용량($/시간으로 측정)입니다. Savings Plans는 융통성이 있습니다.
AWS 컴퓨팅 사용량을 최대 72% 절감할 수 있는 가격 모델입니다. 이것
가격 모델은 Amazon EC2 인스턴스 사용에 대해 더 낮은 가격을 제공합니다.
인스턴스 패밀리, 크기, OS, 테넌시 또는 AWS 리전이며 AWS Fargate에도 적용됩니다.
및 AWS Lambda 사용량.
예측 가능하고 일관된 사용량이 있는 워크로드의 경우 Savings Plans는 다음을 제공할 수 있습니다.
온디맨드 인스턴스에 비해 상당한 비용 절감이 가능합니다. 다음과 같은 경우에 권장됩니다:
• 일관되고 안정된 상태로 사용되는 워크로드
• 다양한 인스턴스 유형과 컴퓨팅 솔루션을 사용하려는 고객
다양한 위치에 걸쳐
• EC2를 사용하기로 금전적 약정을 할 수 있는 고객
3년 임기

 

Amazon EC2 Savings Plans를 사용하면 1년 또는 3년 기간 동안 일정한 컴퓨팅 사용량을 약정하여 컴퓨팅 비용을 절감할 수 있습니다. 이로써 온디맨드 인스턴스 비용 대비 최대 72%의 비용을 절감할 수 있습니다. 약정 사용량까지는 할인된 Savings Plan 요금이 청구됩니다(예: 시간당 10 USD). 약정 이후의 사용량은 일반 온디맨드 인스턴스 요금으로 청구됩니다.

 

 

 

 

 

 

 

스팟 인스턴스는 다음을 요청할 수 있는 Amazon EC2 요금 메커니즘입니다.
사전 약정 없이 시간당 할인된 가격으로 여유 컴퓨팅 용량
요금(주문형 가격에서 최대 90% 할인).

스팟 인스턴스
Amazon EC2 스팟 인스턴스를 사용하면 예비 Amazon EC2 컴퓨팅을 요청할 수 있습니다.
온디맨드 가격에서 최대 90% 할인된 용량을 제공합니다. 스팟 인스턴스는
권장 대상:
• 시작 및 종료 시간이 유연한 애플리케이션
• 매우 낮은 컴퓨팅 가격에서만 실현 가능한 애플리케이션
• 내결함성 및/또는 상태 비저장 워크로드를 보유한 사용자
스팟 인스턴스 가격은 Amazon EC2에 의해 설정되며 이에 따라 점진적으로 조정됩니다.
스팟 인스턴스 용량에 대한 수요와 공급의 장기 추세

• 스팟 인스턴스는 시작 및 종료 시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합합니다. 스팟 인스턴스는 미사용 EC2 컴퓨팅 용량을 활용하며 온디맨드 인스턴스 가격의 최대 90%까지 비용을 절감할 수 있습니다.

 

 

 

예약하시면 최대 75까지 더 큰 할인을 받으실 수 있습니다.
미리 용량에 대한 비용을 지불함으로써 자세한 내용은 다음을 참조하세요.
예약 섹션으로 비용 최적화.

예약 인스턴스
Amazon EC2 예약 인스턴스는 상당한 할인 혜택을 제공합니다(최대 75개)
%)를 온디맨드 인스턴스 가격과 비교합니다. 또한, 예약 시
인스턴스는 특정 가용 영역에 할당되며 용량을 제공합니다.
예약을 통해 인스턴스를 시작할 수 있는 능력에 대한 추가적인 확신을 갖게 됩니다.
당신은 그들이 필요합니다.

 

• 예약 인스턴스는 계정에서 온디맨드 인스턴스를 사용할 때 적용되는 결제 할인 옵션입니다. 표준 예약 및 컨버터블 예약 인스턴스는 1년 또는 3년 약정으로, 정기 예약 인스턴스는 1년 약정으로 구입할 수 있습니다. Savings Plans과 달리 예약 인스턴스는 계약 기간 동안 일정량의 컴퓨팅 사용량을 약정할 필요가 없습니다.

 

 

 

 

 

 

 

 

 

 

 

Amazon Lightsail은 AWS에서 제공하는 간단하고 저렴한 클라우드 컴퓨팅 서비스입니다. Lightsail은 특히 중소기업, 개발자, 그리고 개인 사용자를 대상으로 하며, 간편하게 가상 서버, 스토리지, 데이터베이스 및 네트워크 리소스를 설정하고 관리할 수 있도록 설계되었습니다.

고정 비용 vs 가변 비용

• 고정 비용 (EC2, Lightsail): 사용량과 관계없이 내는 돈. 트래픽이 적을 때 손해.
• 가변 비용 (Lambda, API Gateway): 쓴 만큼만 내는 돈. 트래픽이 적을 때 압도적 유리.

---

 

AWS Transit Gateway

- AWS에서 On-Premises 외부와 연결하기 위해서 (여러 VPC나 네트워크를 중앙에서 연결하는 도구)

추가적인 EC2 인스턴스(VPN 소프트웨어 구동 등)나 설정이 필요하므로 비용이 많이 들고 운영 오버헤드가 큽니다.

 

1. VPN

2. Direct Connect

3. AWS Trasit

Gateway를 사용하면 된다.

 

 

 

 

 

 

 

 

Amazon Rekognition

 Amazon Rekognition을 사용하면 ML 전문 지식이 없어도 사용할 수 있는 검증되고 확장성이 뛰어난 딥 러닝 기술을 사용하여 애플리케이션에 이미지 및 비디오 분석을 쉽게 추가할 수 있습니다. Amazon Rekognition을 사용하면 이미지와 동영상의 객체, 사람, 텍스트, 장면 및 활동을 식별하고 부적절한 콘텐츠를 탐지할 수 있습니다. Amazon Rekognition은 또한 매우 정확한 안면 분석 및 얼굴 검색 기능을 제공하여 다양한 사용자 확인, 인원 수 계산 및 공공 안전 사용 사례를 위해 얼굴을 감지, 분석 및 비교하는 데 사용할 수 있습니다. Amazon Rekognition 사용자 지정 레이블을 사용하면 비즈니스 요구 사항에 맞는 이미지 내 물체와 장면을 식별할 수 있습니다. 예를 들어, 조립 라인의 특정 기계 부품을 분류하거나 비정상 플랜트를 탐지하는 모델을 구축할 수 있습니다. Amazon Rekognition 사용자 지정 레이블은 복잡한 모델 개발 작업을 대신 처리하므로 ML 경험이 필요하지 않습니다. 식별하려는 객체 또는 장면의 이미지만 제공하면 나머지는 서비스에서 처리합니다.

 

 

 

 

 

 

 

Amazon Comprehend 

Amazon Comprehend는 ML 및 자연어 처리 (NLP) 를 사용하여 구조화되지 않은 데이터에서 인사이트와 관계를 발견할 수 있도록 지원합니다. 이 서비스는 텍스트의 언어를 식별하고, 핵심 문구, 장소, 사람, 브랜드 또는 이벤트를 추출하고, 텍스트가 얼마나 긍정적인지 또는 부정적인지 이해하고, 토큰화와 품사를 사용하여 텍스트를 분석하고, 주제별로 텍스트 파일 모음을 자동으로 구성합니다. 또한 Amazon Comprehend의 AutoML 기능을 사용하여 조직의 요구에 맞게 고유하게 조정된 사용자 지정 엔티티 세트 또는 텍스트 분류 모델을 구축할 수 있습니다.구조화되지 않은 텍스트에서 복잡한 의료 정보를 추출하려면 Amazon Comprehend Medical을 사용할 수 있습니다. 이 서비스는 의사 기록, 임상 시험 보고서 및 환자 건강 기록과 같은 다양한 출처에서 의학적 상태, 약물, 복용량, 강도 및 빈도와 같은 의료 정보를 식별할 수 있습니다. 또한 Amazon Comprehend Medical은 추출된 약물과 검사, 치료 및 시술 정보 간의 관계를 식별하여 더 쉽게 분석할 수 있도록 합니다. 예를 들어, 서비스는 구조화되지 않은 임상 기록을 통해 특정 약물과 관련된 특정 복용량, 강도 및 빈도를 식별합니다.

 

 

 

Amazon Textract 

Amazon Textract는 스캔한 문서에서 텍스트와 데이터를 자동으로 추출하는 서비스입니다. Amazon Textract는 단순한 OCR(광학 문자 인식)을 넘어 양식의 필드 콘텐츠와 테이블에 저장된 정보도 식별할 수 있습니다.

 

 

 

Amazon API Gateway 

Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있도록 지원하는 완전관리형 서비스입니다. 에서 몇 번의 클릭만으로 애플리케이션이 백엔드 서비스 (예: Amazon EC2에서 실행되는 워크로드, 실행 중인 코드 또는 웹 애플리케이션) 의 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있도록 하는 “프런트 도어” 역할을 하는 API를 생성할 수 있습니다. AWS Management Console AWS Lambda Amazon API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리를 포함하여 최대 수십만 개의 동시 API 호출을 수락하고 처리하는 데 관련된 모든 작업을 처리합니다.  수백만 개의 동시 호출을 처리할 수 있는 서버리스 서비스입니다.

 

 

 

AWS Cloud Map 

AWS Cloud Map클라우드 리소스 검색 서비스입니다. 를 사용하면 애플리케이션 리소스의 사용자 지정 이름을 정의하여 동적으로 변화하는 이러한 리소스의 업데이트된 위치를 유지할 수 있습니다. AWS Cloud Map이렇게 하면 웹 서비스가 항상 리소스의 가장 많은 up-to-date 위치를 검색하므로 애플리케이션 가용성이 향상됩니다.

 

 

 

AWS App Mesh 

AWS App Mesh실행 중인 마이크로서비스를 쉽게 모니터링하고 제어할 수 있습니다. AWS App Mesh는 마이크로서비스의 통신 방식을 표준화하여 end-to-end 가시성을 제공하고 애플리케이션의 고가용성을 보장하도록 지원합니다.

 

 

 

 

AWS 컨시어지 지원팀은 Amazon Web Services(AWS)에서 제공하는 고급 지원 서비스의 일부입니다. 이 팀은 AWS의 엔터프라이즈 지원 플랜(Enterprise Support Plan)을 구독한 고객에게 제공됩니다. 컨시어지 지원팀은 다음과 같은 주요 역할을 합니다:

1. 계정 및 결제 지원: AWS 사용과 관련된 계정 설정, 결제 문제, 비용 관리 및 최적화에 대한 도움을 제공합니다. 고객이 AWS 리소스를 효율적으로 사용하고 비용을 절감할 수 있도록 지원합니다.
2. 서비스 사용 최적화: 고객이 AWS 서비스를 최적화하여 최대한의 가치를 얻을 수 있도록 조언하고, 적절한 서비스 선택 및 아키텍처 설계를 돕습니다.
3. 맞춤형 지원: 특정 비즈니스 요구 사항에 맞춘 맞춤형 지원을 제공하여 고객이 AWS에서 원하는 목표를 달성할 수 있도록 돕습니다.
4. 중재 및 문제 해결: 기술적 문제를 해결하는 데 도움이 필요한 경우, 적절한 AWS 전문가나 관련 부서와의 중재 역할을 합니다.
5. 교육 및 안내: 고객이 AWS 서비스와 도구를 더 잘 이해하고 활용할 수 있도록 교육 자료와 안내를 제공합니다.

AWS 컨시어지 지원팀은 주로 대규모 기업 고객을 대상으로 하며, 이들이 AWS 환경에서 복잡한 문제를 신속하게 해결하고, 최적의 성과를 달성할 수 있도록 지원하는 것을 목표로 합니다. 이 서비스를 통해 기업은 AWS의 다양한 리소스를 효율적으로 활용하고, 기술적 어려움을 최소화하여 비즈니스 목표를 보다 효과적으로 달성할 수 있습니다.

 

 

 

 

 

AWS Batch 

AWS Batch개발자, 과학자, 엔지니어가 수십만 개의 배치 컴퓨팅 작업을 쉽고 효율적으로 실행할 수 있도록 합니다. AWS AWS Batch 제출된 배치 작업의 볼륨 및 특정 리소스 요구 사항을 기반으로 최적의 양과 유형의 컴퓨팅 리소스 (예: CPU 또는 메모리 최적화 인스턴스) 를 동적으로 프로비저닝합니다. 를 사용하면 AWS Batch작업을 실행하는 데 사용하는 배치 컴퓨팅 소프트웨어나 서버 클러스터를 설치하고 관리할 필요가 없으므로 결과 분석과 문제 해결에 집중할 수 있습니다. AWS Batch Amazon EC2 및 스팟 인스턴스와 같은 다양한 컴퓨팅 서비스 및 기능에 걸쳐 배치 AWS 컴퓨팅 워크로드를 계획, 예약 및 실행합니다.

 

 

 

 

AWS CodeCommit

AWS CodeCommit는 기업이 안전하고 확장성이 뛰어난 프라이빗 Git 리포지토리를 쉽게 호스팅할 수 있게 해주는 완전 관리형 소스 제어 서비스입니다. AWS CodeCommit 자체 소스 제어 시스템을 운영하 거나 인프라 확장에 대해 걱정할 필요가 없습니다. 를 사용하여 AWS CodeCommit 소스 코드에서 바이 너리까지 무엇이든 안전하게 저장할 수 있으며 기존 Git 도구와 원활하게 연동됩니다.

 

 

 

 

Amazon Transcribe

Amazon Transcribe는 고객이 음성을 텍스트로 자동 변환할 수 있게 해주는 자동 음성 인식 (ASR) 서비스입니다. 이 서비스는 WAV 및 MP3와 같은 일반적인 형식으로 저장된 오디오 파일을 모든 단어에 대한 타임스탬프와 함께 트랜스크립션할 수 있으므로 텍스트를 검색하여 원본 소스에서 오디오를 쉽 게 찾을 수 있습니다. 또한 Amazon Transcribe로 라이브 오디오 스트림을 전송하고 실시간으로 자막 스트림을 받을 수 있습니다. Amazon Transcribe는 음량, 음높이 및 말하기 속도의 변화를 포함하여 다 Amazon Textract 77 Amazon Web Services 개요 AWS 백서 양한 음성 및 음향 특성을 처리하도록 설계되었습니다. 오디오 신호의 품질 및 내용 (배경 소음, 겹치는 스피커, 악센트 있는 음성 또는 단일 오디오 파일 내 언어 간 전환 등의 요인을 포함하되 이에 국한되지 않음) 은 서비스 출력의 정확성에 영향을 미칠 수 있습니다. 고객은 음성 기반 고객 서비스 통화의 트랜 스크립션, 오디오/비디오 콘텐츠에 대한 자막 생성, 오디오/비디오 콘텐츠에 대한 (텍스트 기반) 콘텐츠 분석 수행 등 다양한 비즈니스 애플리케이션에 Amazon Transcribe를 사용할 수 있습니다.

 

 

 

 

Amazon Cognito

Amazon Cognito를 사용하면 웹 및 모바일 앱에 사용자 가입, 로그인 및 액세스 제어를 빠르고 쉽게 추가할 수 있습니다. Amazon Cognito를 사용하면 수백만 명의 사용자로 확장할 수 있으며, Apple, Facebook, Twitter 또는 Amazon과 같은 소셜 자격 증명 공급자, SAML 2.0 ID 솔루션 또는 자체 ID 시 스템을 사용하여 로그인할 수 있습니다. 또한 Amazon Cognito를 사용하면 데이터를 사용자 디바이스에 로컬로 저장할 수 있으므로 디바이스 가 오프라인 상태일 때도 애플리케이션이 작동할 수 있습니다. 그런 다음 사용자 디바이스 간에 데이터 를 동기화하여 사용하는 디바이스에 관계없이 앱 경험이 일관되게 유지되도록 할 수 있습니다. Amazon Cognito를 사용하면 사용자 관리, 인증 및 디바이스 간 동기화를 처리하는 솔루션의 구축, 보 안 및 확장에 대해 걱정하는 대신 뛰어난 앱 경험을 만드는 데 집중할 수 있습니다.

 

 

 

 

AWS WAF: SQL 주입 및 크로스 사이트 스크립팅과 같은 일반적인 웹 익스플로잇으로부터 웹 애플리케이션을 보호하는 내장 엔진을 제공합니다.

B. AWS Shield Advanced: AWS에서 실행되는 애플리케이션에 DDoS 보호를 제공합니다. C. Amazon GuardDuty: AWS 계정 및 워크로드에서 악의적인 활동과 무단 동작을 지속적으로 모니터링합니다. D. Amazon Detective: AWS 리소스 내에서 잠재적인 보안 문제 또는 의심스러운 활동의 근본 원인을 분석, 조사 및 식별하는 데 도움이 됩니다.

 

 

 

AWS Glue

AWS Glue고객이 분석을 위해 데이터를 쉽게 준비하고 로드할 수 있도록 하는 완전 관리형 ETL (추출, 변환 및 로드) 서비스입니다.

 

 

 

 

Amazon Athena  (*)

Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화 식 쿼리 서비스입니다. Athena는 서버리스 서비스이므로 관리할 인프라가 없으며 실행한 쿼리에 대해 서만 비용을 지불하면 됩니다.

 

 

AWS DataSync (온프레미스 스토리지 - s3, efsp 간의 데이터 전송)

AWS DataSync는 온프레미스 스토리지와 Amazon S3 또는 Amazon Elastic File System (Amazon EFS) 간의 데이터 이동을 쉽게 자동화할 수 있게 해주는 데이터 전송 서비스입니다.

온프레미스 ↔ AWS'뿐만 아니라 'AWS 서비스 ↔ AWS 서비스' 간의 데이터 이동도 아주 잘 지원합니다.

 

• 운영 오버헤드 최소화: AWS DataSync는 완전 관리형 서비스로, 사용자가 서버를 관리하거나 복사 스크립트를 짤 필요가 없습니다. 설정만으로 대량의 데이터를 안전하고 빠르게 전송합니다.
• 증분 동기화 지원: DataSync는 기본적으로 소스와 대상을 비교하여 변경된 데이터(변경된 파일 또는 새 파일)만 전송하는 기능을 제공합니다.

 

 

 

AWS Global Accelerator

AWS Global Accelerator전 세계 사용자에게 제공하는 애플리케이션의 가용성과 성능을 향상시키는 네트워킹 서비스입니다. 오늘날 공용 인터넷을 통해 전 세계 사용자에게 응용 프로그램을 제공하는 경우 사용자는 여러 공용 네트워크를 통해 응용 프로그램에 연결할 때 일관되지 않은 가용성과 성능에 직면할 수 있습니다. 이 러한 공용 네트워크는 종종 혼잡하며 각 홉은 가용성 및 성능 위험을 초래할 수 있습니다. AWS Global Accelerator 가용성이 높고 정체가 없는 AWS 글로벌 네트워크를 사용하여 사용자의 인터넷 트래픽을 애플리케이션으로 전달하여 사용자 환경의 AWS일관성을 높입니다.

Global Accelerator는 네트워크 성능 최적화에는 좋지만, 콘텐츠 캐싱 기능이 없습니다. 

시험 문제에서 "대기 시간 민감(Latency sensitive)", "UDP/TCP", **"멀티 리전 장애 조치"**라는 단어가 조합되어 나오면 높은 확률로 AWS Global Accelerator가 정답입니다.

Global Accelerator는 변하지 않는 2개의 고정 애니캐스트(Anycast) IP를 제공하므로 캐싱 이슈를 완벽히 해결합니다.

 

 

 

<보안, ID 및 규정 준수>

Amazon Inspector - 자동화된 보안 평가를 실행 , EC2 인스턴스나 컨테이너 이미지의 **소프트웨어 취약점(Patch 미비 등)**이나 의도하지 않은 네트워크 노출을 스캔하는 도구
Amazon GuardDuty - 지능형 위협 탐지 기능, 모니텅링하여 위협을 식별 , 액세스 패턴을 지속적으로 모니터링하고 악성 활동(예: 암호 화폐 채굴, 데이터 유출 시도)을 탐지하는 핵심 서비스
AWS Artifact - 온디맨드 접근(사용량에 따른 지불)을 제공하는 서비스 (보안 및 규정 준수 보고서에 대한)
AWS WAF - 네트워크 요청을 모니터링 할 수 있는 웹 방화벽 / HTTP/HTTPS 요청을 모니터링하여 SQL 주입, XSS 등 일반적인 웹 공격을 차단합니다
AWS Shield - DDoS 공격으로부터 보호
Amazon Detective - 보안 문제 또는 의심스러운 활동의 근본 원인을 분석, 조사 
Amazon Cognito - 웹 및 모바일 앱에 사용자 가입, 로그인 및 액세스 제어를 빠르고 쉽게 추가, 

AWS Firewall Manager: 여러 계정 및 리전의 WAF, Shield Advanced, VPC 보안 그룹 등을 중앙에서 통합 관리하는 서비스입니다. 반드시 AWS Organizations가 활성화되어 있어야 합니다.

AWS Security Hub - GuardDuty를 포함한 여러 보안 서비스의 결과를 수집하여 하나의 통합된 대시보드에 시각화해 줍니다. 문제에서 요구한 "대시보드 표시"에 가장 적합한 조합입니다.

AWS Config: Config는 리소스의 설정 변경 이력을 기록하고 규정 준수 여부를 확인하는 서비스입니다

 

 

 

✅ ⭐ 1️⃣ WAF vs Shield vs Firewall Manager 핵심 비교

서비스역할시험 키워드

AWS WAF	웹 공격 방어	SQL injection, XSS
AWS Shield	DDoS 방어	L3/L4 공격
AWS Firewall Manager	중앙 정책 관리	멀티 계정, 중앙 관리

 

 

 

✅ ⭐ 4️⃣ AWS 보안 아키텍처 그림

                 Internet
                     │
               ┌───────────┐
               │  Shield    │ (DDoS protection)
               └───────────┘
                     │
               ┌───────────┐
               │   WAF      │ (SQLi, XSS)
               └───────────┘
                     │
               ┌───────────┐
               │ API GW / ALB│
               └───────────┘
                     │
                     ▼
                 Backend

 

 

 

 

⭐ 5️⃣ Firewall Manager 중앙 관리 그림

              Firewall Manager
               (Central Policy)
                      │
        ┌───────────────────────────┐
        │       Multi Account        │
        │                            │
        │   WAF Policy → API GW      │
        │   WAF Policy → ALB         │
        │   WAF Policy → CloudFront  │
        └───────────────────────────┘

 

 

 

 

 

AWS Network Firewall

AWS Network Firewall은(는) 모든 Amazon Virtual Private Cloud(VPC)에 필수 네트워크 보호 기능을 손쉽게 배포할 수 있도록 해주는 관리형 서비스입니다. 클릭 몇 번으로 서비스를 설정하고 네트워크 트 래픽에 따라 자동으로 확장되므로 인프라 배포 및 관리에 대해 걱정할 필요가 없습니다. AWS Network Firewall의 유연한 규칙 엔진을 사용하면 악의적인 활동의 확산을 방지하기 위해 아웃바운드 서버 메시 지 블록 (SMB) 요청을 차단하는 등 네트워크 트래픽을 세밀하게 제어할 수 있는 방화벽 규칙을 정의할 수 있습니다. 또한 일반적인 오픈 소스 규칙 형식으로 이미 작성한 규칙을 가져오고 파트너가 제공하 는 관리형 인텔리전스 피드와 통합할 수 있습니다. AWS AWS Network Firewall 와 함께 AWS Firewall Manager 작동하므로 AWS Network Firewall 규칙을 기반으로 정책을 구축한 다음 해당 정책을 VPC와 계정 전체에 중앙에서 적용할 수 있습니다. AWS Network Firewall 일반적인 네트워크 위협으로부터 보호하는 기능을 포함합니다. AWS Network Firewall 스테이트풀 방화벽은 연결 추적 및 프로토콜 식별과 같은 트래픽 흐름의 컨텍스트를 통합하여 VPC가 승인되지 않은 프로토콜을 사용하여 도메인에 액세스하는 것을 방지하는 등의 정책을 적용할 수 있습니다. AWS Network Firewall 침입 방지 시스템 (IPS) 은 능동적 트래픽 흐름 검사를 제공하므로 시그니처 기반 탐지를 사용하여 취약성 악용을 식별하고 차단할 수 있습니다. AWS Network Firewall 또한 알려진 잘못된 UR

 

 

 

 

 

 

Dedicated Hosts란?

Amazon EC2 Dedicated Hosts는 사용자가 AWS의 물리적 서버(호스트)를 전용으로 사용할 수 있도록 해주는 서비스입니다. 일반적인 EC2 인스턴스는 여러 사용자가 공유하는 물리적 서버에서 실행되지만, Dedicated Hosts는 특정 사용자가 해당 서버의 모든 리소스를 독점적으로 사용할 수 있도록 해줍니다.

 

 

주요 사용 사례

1. 기존 라이선스 사용:
   • 이미 보유한 소프트웨어 라이선스를 AWS에서 사용하여 비용을 절감하고, 라이선스 관리 복잡성을 줄입니다.
2. 규제 준수:
   • 금융, 헬스케어, 공공 부문 등 엄격한 규제를 준수해야 하는 환경에서 물리적 서버 제어를 통해 규제 요구사항을 충족합니다.
3. 성능 최적화:
   • 높은 성능이 요구되는 애플리케이션을 위해 전용 리소스를 사용하여 성능을 최적화합니다.
4. 보안 및 데이터 주권:
   • 특정 데이터가 특정 물리적 서버에만 저장되도록 보장하여 보안 및 데이터 주권 요구사항을 충족합니다.

 

 

 

 

 

Amazon Personalize는 개발자가 애플리케이션을 사용하는 고객을 위한 개별화된 권장 사항을 쉽게 생 성할 수 있게 해주는 ML 서비스입니다. ML은 개인화된 제품 및 콘텐츠 추천, 맞춤형 검색 결과, 타겟 마케팅 프로모션을 지원하여 고객 참여 를 개선하는 데 점점 더 많이 사용

 

 

 

 

 

네트워크 액세스 제어 목록(ACL)은 서브넷 수준에서 특정 인바운드 또는 아웃바운드 트래픽을 허용하거나 거부합니다. VPC에 기본 네트워크 ACL을 사용하거나 보안 그룹에 대한 규칙과 유사한 규칙으로 VPC에 대한 사용자 지정 네트워크 ACL을 만들어 VPC에 추가 보안 계층을 추가할 수 있습니다.

네트워크 ACL을 사용하는 데 추가 비용은 없습니다.

다음 다이어그램은 두 개의 서브넷이 있는 VPC를 보여줍니다. 각 서브넷에는 네트워크 ACL이 있습니다. 트래픽이 VPC에 들어오면(예: 피어링된 VPC, VPN 연결 또는 인터넷에서) 라우터는 트래픽을 목적지로 보냅니다. 네트워크 ACL A는 서브넷 1로 향하는 트래픽 중 서브넷 1로 들어갈 수 있는 트래픽과 서브넷 1 외부 위치로 향하는 트래픽 중 서브넷 1을 나갈 수 있는 트래픽을 결정합니다. 마찬가지로 네트워크 ACL B는 서브넷 2로 들어오고 나갈 수 있는 트래픽을 결정합니다.

 

 

✅ ACL (Access Control List)란

👉 리소스 접근 권한 목록

 

 

 

 

 

Amazon Virtual Private Cloud(Amazon VPC)

AWS 서비스를 사용하는 수백만 명의 고객을 상상해 보십시오. 또한 이들 고객이 생성한 Amazon EC2 인스턴스와 같은 수백만 개의 리소스를 상상해 보십시오. 이러한 모든 리소스에 경계가 없으면 네트워크 트래픽이 제한 없이 리소스 간에 흐를 수 있습니다. 

AWS 리소스에 경계를 설정하는 데 사용할 수 있는 네트워킹 서비스가 Amazon Virtual Private Cloud(Amazon VPC)입니다.

Amazon VPC를 사용하여 AWS 클라우드의 격리된 섹션을 프로비저닝할 수 있습니다. 이 격리된 섹션에서는 사용자가 정의한 가상 네트워크에서 리소스를 시작할 수 있습니다. 한 Virtual Private Cloud(VPC) 내에서 여러 서브넷으로 리소스를 구성할 수 있습니다. 서브넷은 리소스(예: Amazon EC2 인스턴스)를 포함할 수 있는 VPC 섹션입니다.

 

 

 

VPN 서비스란?

가상 사설망을 의미하는 VPN은 컴퓨터와 VPN 공급자가 소유한 원격 서버 간에 디지털 연결을 설정하고, 개인 데이터를 암호화하고, IP 주소를 마스킹하고, 인터넷에서 웹 사이트 블록 및 방화벽을 단계별로 실행할 수 있는 지점 간 터널을 만듭니다. 이렇게 하면 온라인 환경이 비공개이고 보호되며 더 안전합니다.

정의상 VPN 연결은 다음과 같습니다.

• 연결 프로세스에 실제 케이블이 없기 때문에 가상.
  
  
• 이 연결을 통해 다른 사용자가 내 데이터 또는 검색 활동을 볼 수 없기 때문에 프라이빗.
  
  
• 컴퓨터와 VPN 서버 등 여러 디바이스가 함께 작동하여 설정된 링크를 유지하므로 네트워크로 연결된.

 

 

---

 

AWS aws:PrincipalOrgID 는
👉 요청을 보낸 IAM 주체(Principal)가 어떤 AWS Organizations에 속해 있는지 확인할 때 쓰는 조건 키(Condition Key) 입니다.

---

✅ 한 줄 요약

같은 AWS Organization에 속한 계정인지 확인하는 보안 조건값

---

🔎 언제 쓰냐면?

보통 S3 버킷 정책, IAM 정책, KMS 정책 같은 **리소스 기반 정책(Resource-based policy)**에서 사용해요.

예를 들어:

“우리 회사 Organization에 속한 계정만 이 S3 버킷에 접근 가능”

이렇게 제한하고 싶을 때 사용합니다.

 

 

 

 

 

---

✅ Amazon EFS란?

Amazon EFS (Elastic File System) 는
👉 AWS에서 여러 서버(EC2)가 동시에 공유해서 사용할 수 있는 파일 저장소 입니다.

---

🔥 한 줄 요약

여러 EC2 인스턴스가 동시에 붙어서 쓰는 공유 네트워크 드라이브

---

📦 쉽게 이해하면

• EBS = 한 서버 전용 외장하드
• S3 = 인터넷 기반 파일 창고
• EFS = 여러 서버가 같이 쓰는 네트워크 드라이브

🎯 실무 예시

웹서버 3대가 있고
사용자가 사진 업로드함

• EBS 쓰면 → 서버마다 파일 따로 저장됨 ❌
• EFS 쓰면 → 모든 서버에서 같은 파일 보임 ✅

 

 

 

---

 

 

Amazon SQS (Simple Queue Service)

✅ 메시지 큐 서비스

• 메시지를 저장해두고
• 소비자가 꺼내서 처리

특징

• Pull 방식
• 버퍼 역할
• 트래픽 급증 완화
• 자동 확장

 

 

---

1️⃣ File Gateway 역할

S3 File Gateway는:

• 온프레미스에 SMB/NFS 인터페이스 제공
• 실제 데이터는 S3에 저장
• 자주 사용하는 데이터는 로컬 캐시에 저장

👉 최근 파일은 빠르게 접근 가능
👉 저장 공간은 사실상 무제한 (S3)

 

 

 

 

---

AWS Secrets Manager는
👉 애플리케이션에서 사용하는 비밀 정보(Secrets)를 안전하게 저장·관리·자동 교체(로테이션)하는 서비스입니다.

     여러 리전과 여러 AZAZ에 걸쳐 작동 / 데이터베이스 자격 증명 등을 관리하는 서비스

---

📌 여기서 말하는 “Secret”이란?

예를 들어:

• 데이터베이스 비밀번호
• API 키
• OAuth 토큰
• SSH 키
• 다른 AWS 서비스 인증 정보

 

 

---

 

 

Amazon RDS(Relational Database Service)는 Amazon Web Services(AWS)에서 제공하는 관리형 관계형 데이터베이스 서비스입니다. RDS는 데이터베이스를 쉽게 설정, 운영, 그리고 확장할 수 있도록 도와주는 서비스로, 복잡한 데이터베이스 관리 작업(예: 하드웨어 프로비저닝, 데이터베이스 설치, 패치 적용, 백업, 복구, 성능 조정 등)을 자동화하여 사용자가 더 쉽게 데이터베이스를 관리할 수 있게 해줍니다.

주요 특징

1. 자동화된 관리
   • 백업, 패치, 복구, 모니터링 등을 자동으로 처리합니다.
   • 장애 발생 시 자동으로 복구하거나, Multi-AZ(다중 가용 영역) 배포로 고가용성을 제공합니다.
2. 확장성
   • 몇 번의 클릭만으로 데이터베이스 인스턴스의 크기(서버 성능)를 증가시키거나 감소시킬 수 있습니다.
   • 읽기 전용 복제본(Read Replica)을 통해 읽기 성능을 확장할 수 있습니다.
   • RDS는 최대 5개(PostgreSQL 기준 등 서비스별 차이 있음)의 읽기 복제본을 생성하여 읽기 처리량을 유연하게 늘릴 수 있습니다.
3. 보안
   • VPC(가상 프라이빗 클라우드), 암호화, IAM(Identity and Access Management) 등 다양한 보안 기능을 제공합니다.
4. 다양한 엔진 지원
   • Amazon RDS는 여러 데이터베이스 엔진을 지원합니다.
     예: MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Aurora 등.
5. 비용 효율성
   • 사용량 기반 과금(온디맨드 또는 예약 인스턴스) 모델로, 필요에 따라 비용을 조정할 수 있습니다.

활용 예시

• 웹/모바일 앱의 백엔드 데이터베이스
• ERP, CRM 등 엔터프라이즈 애플리케이션의 데이터 저장소
• 데이터 분석 및 BI 플랫폼의 데이터베이스

요약

Amazon RDS는 데이터베이스 관리의 복잡함을 줄이고, 높은 가용성과 확장성을 제공하는 AWS의 관리형 데이터베이스 서비스입니다. 개발자와 운영자는 RDS를 활용해 데이터베이스 인프라 관리 부담을 크게 줄일 수 있습니다.

 

RDS Storage Auto Scaling: 데이터베이스가 가득 차기 전에 자동으로 스토리지 크기를 증설하는 기능입니다. 가동 중단 없이 진행됩니다.

 

 

⭐ ① Multi-AZ vs Read Replica vs Aurora Replica 완벽 암기표

구분                               Multi-AZ                          Read Replica                       Aurora Replica

 

목적	고가용성 (HA)	성능 개선 (읽기 분산)	성능 + HA + 초고속 읽기
읽기 가능 여부	❌ 불가능	✅ 가능	✅ 가능
쓰기 가능 여부	Primary만	Primary만	Primary만
장애 대응	자동 failover	❌ failover 아님	자동 failover
복제 방식	동기 복제	비동기 복제	공유 스토리지
성능 향상	❌ 없음	✅ 읽기 성능 개선	✅ 매우 강함
시험 키워드	장애 대비, DR, HA	읽기 분리, 성능 개선	초고성능, MySQL/PostgreSQL 호환

 

 

Multi-AZ

        애플리케이션
              │
              ▼
      ┌─────────────────┐
      │  Primary DB     │
      │     AZ-1        │
      └────────┬────────┘
               │
        동기 복제 (Sync)
               │
               ▼
      ┌─────────────────┐
      │  Standby DB     │
      │     AZ-2        │
      └─────────────────┘

 

RDS Multi-AZ: RDS를 **다중 AZ(Multi-AZ)**로 구성하면 다른 AZ에 예비 복제본(Standby)을 생성합니다. 기본 DB에 문제가 생기면 자동으로 예비 DB로 전환(Failover)되어 가용성이 극대화됩니다.

 

 

 

 

rds Read Replica  

              애플리케이션
                    │
            ┌───────┴────────┐
            ▼                ▼
     ┌─────────────┐  ┌─────────────┐
     │  Primary DB │  │ Read Replica│
     │   (Write)   │  │  (Read)     │
     └──────┬──────┘  └─────────────┘
            │
      비동기 복제
            │
            ▼
      데이터 복사

 

 

 

 

---

AWS Systems Manager는 Amazon Web Services(AWS)에서 제공하는 통합 관리 서비스로, 클라우드와 온프레미스 환경의 인프라스트럭처를 안전하고 효율적으로 운영, 관리, 모니터링할 수 있도록 도와줍니다. Systems Manager는 다양한 관리 도구들을 한 곳에 통합하여, 인스턴스(EC2, 온프레미스 서버 등)의 설정 관리, 패 사 등 여러 작업을 간편하게 수행할 수 있습니다.

 

 

AWS Systems Manager (SSM)

기능	주요 용도	비유
Run Command	즉각적인 명령 실행 (원격 제어)	확성기로 1,000명에게 동시에 "지금 당장 이거 해!"라고 외치는 것
Patch Manager	OS 패치 자동화 및 준수 관리	정기적으로 예방 접종(보안 패치) 스케줄을 관리하는 보건소
Session Manager	SSH 키 없이 안전한 서버 접속	열쇠 없이 지문 인식으로 서버 문을 열고 들어가는 것

---

주요 기능

1. 인스턴스 관리
   • EC2 인스턴스와 온프레미스 서버에 명령을 원격으로 실행(예: 쉘 커맨드, PowerShell).
   • 인벤토리 수집(서버에 설치된 소프트웨어, 패치 상태 등).
2. 패치 관리
   • Windows, Linux OS의 보안 패치 및 업데이트를 자동으로 관리 및 적용.
3. 자동화(Automation)
   • 반복적인 인프라 관리 작업(예: 서버 재시작, 이미지 생성 등)을 자동화하여 운영 효율성 향상.
4. Parameter Store
   • 애플리케이션에서 사용하는 설정값, 비밀번호, API 키 등 민감한 정보를 암호화하여 안전하게 저장·관리.
5. Session Manager
   • SSH 키 없이도 안전하게 EC2 인스턴스에 접속해 명령을 실행할 수 있는 기능.
   • 감사 로그 제공.
6. OpsCenter
   • 운영 이슈(이벤트, 경고 등)를 한 곳에서 모니터링 및 해결할 수 있게 지원.

---

장점

• 중앙 집중화: 여러 리전, 계정의 리소스를 한 곳에서 관리.
• 보안 강화: IAM과 연동하여 접근 권한을 세밀하게 제어, 민감 정보 암호화.
• 운영 자동화: 수작업 감소, 오류 방지.
• 비용 절감: 운영 복잡성 감소로 인한 관리 비용 절감.

---

활용 예시

• 패치 및 소프트웨어 자동 배포
• 서버 구성 변경 자동화
• 운영 환경의 보안 설정 일괄 관리
• 장애 발생 시 빠른 원격 진단 및 조치

---

요약

AWS Systems Manager는 서버 및 클라우드 환경의 운영 효율성과 보안을 높여주는 강력한 관리 도구입니다. 인프라 관리 자동화, 보안 강화, 중앙 집중식 모니터링 및 제어를 통해, 복잡한 IT 환경도 손쉽게 관리할 수 있게 도와줍니다.

 

 

 

---

Amazon QuickSight는 AWS(Amazon Web Services)에서 제공하는 클라우드 기반의 비즈니스 인텔리전스(BI) 서비스입니다.
쉽게 말해, 데이터를 시각화하고, 대시보드와 리포트를 만들며, 조직 내에서 데이터를 공유할 수 있게 해주는 데이터 분석 도구입니다.

 

 

---

Amazon SNS(Simple Notification Service)는 AWS(Amazon Web Services)에서 제공하는 메시지 전달 및 알림 서비스입니다.
SNS를 통해 여러 시스템, 애플리케이션, 사용자에게 즉시 메시지(알림, 이벤트, 경고 등)를 전송할 수 있습니다.

주요 특징

1. 발행-구독(Pub/Sub) 모델

• **발행자(Publisher)**가 메시지를 SNS 토픽(Topic)에 발행하면,
  **구독자(Subscriber)**들이 그 메시지를 받아볼 수 있습니다.
• 다양한 구독 방식 지원: 이메일, SMS, 모바일 푸시, AWS Lambda, HTTP/HTTPS, SQS 등

2. 다양한 메시지 전달 방식

• 이메일: 이메일 알림 전송
• SMS: 핸드폰 문자 메시지 전송
• 모바일 푸시: 앱 푸시 알림(Android/iOS)
• AWS Lambda: 자동 트리거로 서버리스 함수 실행
• SQS: AWS 큐 서비스로 메시지 전달
• HTTP/HTTPS: 웹훅 방식으로 외부 시스템과 연동

 

 

🔥 1️⃣ Amazon SQS

📌 한 줄 정의

메시지를 저장해두는 대기열(Queue)

구조

Producer → SQS → Consumer

핵심 특징

• 메시지 저장(버퍼링)
• 소비자가 천천히 처리 가능
• 메시지 재처리 가능
• DLQ 설정 가능
• 트래픽 급증 완충

언제 쓰냐?

• 트래픽 스파이크 처리
• Lambda 동시성 제어
• DB 보호
• 서비스 디커플링

---

🚀 2️⃣ Amazon SNS

📌 한 줄 정의

메시지를 즉시 여러 곳에 전파(Pub/Sub)

구조

Publisher → SNS → 여러 Subscriber

핵심 특징

• 실시간 알림
• 여러 구독자에게 동시 전송
• Fan-out 구조
• 메시지 저장 목적 아님

언제 쓰냐?

• 푸시 알림
• 이메일/SMS 발송
• 여러 시스템에 동시에 이벤트 전달

---

🎯 핵심 차이 비교표

항목SQSSNS

목적	메시지 저장	메시지 전파
구조	Queue	Pub/Sub
버퍼링	O	X
트래픽 완충	O	X
다중 구독	기본 X	O
DB 보호	O	X
재처리	O	제한적

---

🧠 시험에서 이렇게 나오면 바로 찍어라

✅ "트래픽 급증"

→ SQS

✅ "DB 과부하 방지"

→ SQS

✅ "비동기 처리"

→ SQS

✅ "여러 시스템에 동시에 이벤트 전달"

→ SNS

✅ "푸시 알림"

→ SNS

---

💡 고급 패턴 (자주 출제됨)

SNS → SQS 여러 개 연결 가능

Publisher → SNS → (SQS1, SQS2, Lambda 등)

👉 이걸 Fan-out 패턴이라고 함
👉 확장성과 유연성 최고

---

🔥 시험용 암기 문장

SQS = 저장
SNS = 뿌리기

 

 

 

SNS vs SQS 다시 비교 (유실 방지 관점)

특성	Amazon SNS	Amazon SQS
메커니즘	Push (밀어넣기)	Pull/Polling (당겨오기)
과부하 대응	수신측이 못 받으면 실패 가능성 높음	수신측이 바쁘면 대기열에 보관
용도	알림, 팬아웃(여러 곳에 전달)	디커플링, 부하 분산(Buffering)

 

 

 

AWS 시험 단골 유형 (메시징 서비스 공식)

요구사항 키워드	추천 서비스 조합 (정답 공식)
무조건 순서 보장 (First-In-First-Out)	SQS FIFO 또는 SNS FIFO
처리 속도 극대화 (순서 상관 없음)	SQS 표준 대기열 (Standard Queue)
실시간 스트리밍 / 수천 개 샤드 분석	Amazon Kinesis Data Streams
하나의 메시지를 여러 구독자에게 전달	Amazon SNS (Fan-out)
운영 오버헤드 최소화 + 서버리스	SQS + Lambda

 

 

 

 

⭐ 시험용 핵심 비교표 (⭐ 중요)

구분                                                                    SQS                                SNS                                 Kinesis

               

메시지 저장	✅	❌	✅
전달 방식	Pull	Push	Stream
fan-out	❌	✅	❌
순서 보장	FIFO만	❌	✅
worker queue	⭐⭐⭐	❌	⭐
실시간 분석	❌	❌	⭐⭐⭐
이벤트 브로드캐스트	❌	⭐⭐⭐	❌

---

⭐ 시험에서 바로 판단 공식

👉 SQS 나오는 문장

• loosely coupled
• decoupled
• worker scaling
• retry
• durable storage
• asynchronous processing

👉 무조건 SQS

---

👉 SNS 나오는 문장

• multiple subscribers
• fan-out
• push notification
• alerting
• email/SMS

👉 SNS

---

👉 Kinesis 나오는 문장

• streaming data
• real-time analytics
• high throughput events
• IoT / clickstream

👉 Kinesis

 

 

 

---

Amazon EBS(Amazon Elastic Block Store)는 AWS(Amazon Web Services)에서 제공하는 블록 스토리지 서비스입니다.
쉽게 말해, **EC2와 같은 클라우드 서버에 연결해서 사용하는 “가상 하드디스크”**라고 생각하면 됩니다.

주요 특징

1. 블록 스토리지

• EBS는 파일 단위가 아닌 “블록” 단위로 데이터를 저장
• 데이터베이스, 파일 시스템, 응용 프로그램 등 다양한 워크로드에 적합

2. EC2 인스턴스와 연결

• EC2(클라우드 서버) 인스턴스에 디스크(볼륨) 형태로 연결해서 사용
• EC2 인스턴스가 꺼져도 데이터가 유지됨(비휘발성)

3. 확장성 및 유연성

• 필요에 따라 용량(GB~TB 단위)과 성능(IOPS, 처리량) 조절 가능
• 볼륨을 쉽게 확장, 축소, 백업, 복원 가능

4. 데이터 보호 및 백업

• 스냅샷 기능을 통해, EBS 볼륨 전체를 S3에 백업
• 스냅샷을 이용해 빠르게 복원 가능
• 가용 영역 내에서 자동 복제, 내결함성 제공

 

 

EBS Snapshot Lock은 특정 EBS 스냅샷을 지정된 기간 동안 그 누구도(루트 사용자 포함) 삭제할 수 없게 고정하는 기능입니다.

3. 주요 특징

• 삭제 불가능: 잠금 기간이 만료되기 전까지는 API 호출, CLI, 콘솔을 통한 모든 삭제 시도가 차단됩니다.
• 두 가지 모드:
  1. 거버넌스 모드 (Governance mode): 특정 권한(ec2:LockSnapshot, ec2:UnlockSnapshot)이 있는 사용자만 잠금을 해제하거나 기간을 조정할 수 있습니다. (조금 유연함)
  2. 규정 준수 모드 (Compliance mode): 루트 사용자를 포함해 그 누구도 잠금을 해제하거나 기간을 단축할 수 없습니다. (가장 강력함)
• 쿨오프 기간 (Cool-off period): 규정 준수 모드로 설정한 후 마음이 바뀔 경우를 대

 

 

---

✅ Application Load Balancer (ALB)

한 줄 정의

HTTP/HTTPS 전용, 똑똑한 L7 로드밸런서

특징

• HTTP / HTTPS 전용
• URL 경로 기반 라우팅 가능
  (예: /api → 서버1, /image → 서버2)
• 쿠키 기반 세션 유지
• 마이크로서비스에 최적
• ✔ Health Check 수행
  ✔ unhealthy instance 자동 제거
  ✔ 트래픽 분산

예시

 

example.com/api → 서버 A example.com/login → 서버 B

👉 웹서비스용

---

✅ Network Load Balancer (NLB)

한 줄 정의

TCP/UDP 전용, 매우 빠른 L4 로드밸런서

특징

• TCP / UDP 지원
• 초고속
• 낮은 지연 시간
• 고정 IP 가능
• VoIP, 게임 서버에 적합

예시

• VoIP (UDP)
• 온라인 게임
• 금융 거래 시스템

👉 "속도 + 프로토콜 다양성" 필요할 때

---

🎯 한눈에 비교

항목                                                                                      ALB                                 NLB

        

계층	L7	L4
HTTP/HTTPS	O	O
TCP	X	O
UDP	X	O
경로 기반 라우팅	O	X
속도	빠름	매우 빠름
용도	웹 앱	VoIP, 게임

---

 

NLB vs ALB 상태 확인 (Health Check)

• NLB (Layer 4): 주로 TCP 응답 여부만 확인합니다. "문이 열려 있나?"만 봅니다.
• ALB (Layer 7): HTTP 응답 코드 및 경로를 확인합니다. "문 안에 있는 사람이 제대로 대답을 하나?"까지 확인합니다.

 

🔥 시험 암기 공식

• HTTP + 경로 기반 → ALB
• UDP 나오면 → NLB

✅ 1️⃣ Application Load Balancer (ALB)

👉 L7 (HTTP/HTTPS)

특징
✔ URL 기반 라우팅
✔ 호스트 기반 라우팅
✔ WebSocket
✔ 컨테이너 / 마이크로서비스
✔ WAF 연동

스티키 세션 지원

예

• /api → 서버 A
• /image → 서버 B

👉 시험 공식
웹 애플리케이션 → ALB

---

✅ 2️⃣ Network Load Balancer (NLB)

👉 L4 (TCP/UDP)

특징
✔ 초고성능
✔ 초저지연
✔ 고정 IP 제공
✔ 수백만 RPS 처리

👉 시험 공식
고성능 / TCP / 고정 IP → NLB

---

✅ 3️⃣ Gateway Load Balancer (GWLB)

👉 보안 어플라이언스용 / 타사 가상 방화벽 어플라이언스를 통과하는 트래픽을 관리하기 위한 특수 로드 밸런서

특징
✔ 방화벽 / IDS / IPS 연결
✔ 보안 트래픽 검사
✔ 투명 라우팅

👉 시험 공식
보안 장비 연결 → GWLB

---

2️⃣ AWS Global Accelerator 개념 설명

한 줄 정의

전 세계 사용자 트래픽을 가장 가까운 AWS 리전으로 빠르게 보내주는 서비스

 

---

(Global Accelerator): Global Accelerator는 전 세계 사용자에게 고정 IP를 제공하고 네트워크 경로를 최적화(TCP/UDP 부하 분산)하는 데 강점이 있지만, 콘텐츠 자체를 캐싱하는 기능은 없습니다. 미디어 파일 전송에는 CloudFront가 더 적합합니다.

 

 

AWS 시험 단골 유형 (전 세계 네트워크 최적화 공식)

요구사항 키워드	추천 서비스 (정답 공식)
정적 콘텐츠 캐싱, 비디오 스트리밍	Amazon CloudFront
TCP/UDP 성능 개선, 고정 IP 필요	AWS Global Accelerator
S3 직접 접근 차단 (보안)	CloudFront + OAC (Origin Access Control)
특정 국가 사용자 접속 차단	CloudFront Geo Restriction
엣지에서 가벼운 코드 실행	CloudFront Functions / Lambda@Edge

 

 

 

🌎 왜 필요한가?

예를 들어:

• 서울 사용자
• 미국 사용자
• 유럽 사용자

모두 하나의 글로벌 IP로 접속

Global Accelerator가:

1. 사용자 위치 확인
2. 가장 가까운 AWS 리전으로 연결
3. AWS 글로벌 전용 네트워크 사용
4. 리전 장애 시 자동 다른 리전으로 전환

 

• Anycast IP
• AWS backbone network
• health check
• regional failover

 

---

🚀 특징

• Anycast IP 제공
• 자동 장애 조치
• 초저지연
• L4 기반 (TCP/UDP 가능)
• 게임/VoIP에 매우 적합

---

🎯 Route 53과 차이

구분                                                           Global Accelerator                                 Route 53

                 

방식	Anycast IP	DNS
속도	더 빠름	DNS 기반
자동 Failover	빠름	TTL 영향
UDP 지원	O	O (DNS 레벨)

 

 

 

사용자
   │
Global Accelerator (전 세계 최적 라우팅)
   │
리전별 NLB or ALB
   │
EC2 Auto Scaling 그룹

 

 

 

---

AWS Config란?

AWS 리소스의 설정 상태를 기록하고 평가하는 서비스입니다. 마치 '우리 집(AWS 계정)의 가계부와 점검표' 같은 역할을 합니다.

• 규정 준수(Compliance): 내가 정한 규칙(태그 필수 등)을 지키고 있는지 확인합니다.
• 자동 치료(Remediation): 태그가 없는 리소스가 발견되면 자동으로 태그를 달아버리거나 알림을 보내는 기능까지 연결할 수 있습니다.

 

 

---

AWS의 Amazon Kinesis를 한 문장으로 정의하면, **"엄청나게 밀려오는 데이터를 중간에서 받아내어 차례대로 처리해주는 거대한 컨테이너(수조)"**라고 할 수 있습니다.

서버리스 및 자동 확장: Kinesis Data Firehose는 완전 관리형 서버리스 서비스로, 데이터 양에 따라 자동으로 확장되며 S3로 데이터를 스트리밍하는 데 최적화되어 있습니다.

서버리스(Serverless) 서비스

---

1. 왜 Kinesis가 필요한가요? (비유: 맛집 대기 줄)

유명한 맛집(데이터베이스나 앱)이 있습니다. 평소에는 손님이 적당히 오지만, 갑자기 TV에 방영되어 **수만 명의 손님(데이터)**이 동시에 들이닥친다고 가정해 봅시다.

• Kinesis가 없다면: 가게 문 앞이 아수라장이 되고, 직원은 당황해서 주문을 놓치거나 가게가 마비됩니다. (시스템 다운)
• Kinesis가 있다면: 가게 앞에 번호표 기계와 대기 장소를 만드는 것과 같습니다. 손님들은 일단 번호표를 받고 순서대로 기다립니다. 가게 직원은 자기 속도에 맞춰 한 명씩 정성껏 음식을 내줄 수 있습니다. (안정적인 데이터 처리)

---

2. Kinesis의 핵심 3형제 (가장 많이 쓰이는 서비스)

AWS Kinesis는 목적에 따라 크게 세 가지로 나뉩니다.

① Kinesis Data Streams (데이터 스트림즈)

• 역할: 데이터를 실시간으로 수집하고 보관합니다.
• 특징: 번호표를 받은 손님이 대기실에 머무는 것과 같습니다. 이 데이터는 여러 명의 직원(다른 애플리케이션)이 동시에 가져가서 각자 다른 요리(분석, 저장 등)를 할 수 있습니다.  Kinesis Data Stream은 데이터 보존 기간 등을 직접 관리
• 키워드: 실시간, 다중 소비자, 24시간~최대 1년 보관.

② Kinesis Data Firehose (데이터 파이어호스)

• 역할: 데이터를 받아서 특정 목적지(S3, Redshift 등)로 바로 던져줍니다.
• 특징: 소방 호스(Firehose)처럼 물을 받아서 원하는 곳에 쏟아붓는 느낌입니다. 복잡한 설정 없이 데이터를 저장소로 옮기고 싶을 때 씁니다. 중간에 아주 간단한 데이터 가공(포맷 변경 등)도 가능합니다.
• 키워드: 전송 전용, 설정 간편, 서버리스. 자체적으로 Parquet 또는 ORC 형식으로 변환하는 기능을 내장하고 있습니다. (운영 오버헤드가 매우 낮음)
• 데이터를 S3, Redshift 등으로 전송하는 데 특화. 포맷 변환 기능을 내장하고 있어 매우 편리함 (완전 관리형).

③ Kinesis Video Streams (비디오 스트림즈)

• 역할: CCTV나 스마트폰 카메라의 비디오 데이터를 실시간으로 수집합니다.
• 특징: 영상 데이터를 안전하게 저장하고 분석(얼굴 인식 등)할 수 있게 도와줍니다.
• 키워드: 비디오/오디오 데이터 전용.

4. Kinesis Data Analytics: Firehose에서 데이터를 복사하여 실시간 대시보드나 분석용 쿼리를 처리합니다.

Kinesis Data Analytics를 통해 스트리밍 데이터에 대해 SQL이나 Java/Python으로 실시간 분석을 즉시 수행할 수 있습니다.

 

Kinesis Data Streams vs Firehose 비교

가장 큰 차이는 "직접 요리하느냐(Streams)" 아니면 **"배달만 하느냐(Firehose)"**의 차이입니다.

항목	Kinesis Data Streams (KDS)	Kinesis Data Firehose (KDF)
성격	실시간 데이터 스트리밍 수집 플랫폼	데이터 전달(Delivery) 전용 서비스
실시간성	초 미만 (200ms 이하) - 매우 빠름	근실시간 (최소 60초 지연) - 버퍼링 후 전송
운영 오버헤드	높음 (샤드 수 관리 및 소비자 앱 개발 필요)	낮음 (완전 관리형 서버리스, 자동 확장)
데이터 보관	24시간~365일 보관 가능 (재생 가능)	보관 기능 없음 (목적지로 바로 전송)
주요 용도	복잡한 실시간 분석, 맞춤형 앱 연동	S3, Redshift, Splunk 등으로 데이터 적재

---

3. Kinesis를 쓰는 대표적인 상황

1. 로그 수집: 수천 대의 서버에서 발생하는 로그를 실시간으로 모아서 분석할 때.
2. 금융 거래: 전 세계에서 일어나는 신용카드 결제 내역을 실시간으로 감시하여 이상 거래(FDS)를 탐지할 때.
3. IoT 데이터: 수만 개의 센서(온도, 위치 등)에서 보내는 신호를 한곳으로 모을 때.
4. SNS 분석: 트위터나 인스타그램의 실시간 태그를 분석해 트렌드를 파악할 때.

 

 

 

---

Amazon Macie

항목	상세 내용
주요 기능	S3 내 민감 정보(이름, 신용카드 번호, API 키 등) 자동 식별
동작 방식	완전 관리형 머신러닝 기반 데이터 스캐닝
장점	데이터 거버넌스 자동화, 규정 준수(GDPR 등) 증명 용이

---

### 아주 쉽게 요약하자면?

Macie는 S3라는 거대한 창고에 쌓인 수많은 상자(데이터) 속에서 '개인정보'라는 위험물이 들어있는지 엑스레이를 찍어 감시하는 **"AI 보안 요원"**입니다. 직접 알고리즘을 만드는 고생을 하지 말고, 이 전문 요원을 고용하는 것이 가장 효율적입니다.

이제 PII 탐지라는 단어가 나오면 무조건 Amazon Macie를 떠올리시면 됩니다!

 

 

 

---

Amazon EventBridge는 AWS 서비스 간, 또는 외부 애플리케이션 간의 데이터를 연결해 주는 **"지능형 중앙 우체국"**이라고 생각하면 가장 쉽습니다.

애플리케이션들이 서로 복잡하게 얽히지 않아도(Decoupling), 특정 사건(이벤트)이 발생했을 때 정해진 규칙에 따라 필요한 곳으로 데이터를 전달해 주는 역할을 합니다.

---

1. 핵심 구성 요소 (작동 원리)

EventBridge는 크게 세 단계를 거쳐 동작합니다.

1. 이벤트 소스 (Event Source): "사건"이 발생하는 곳입니다. (예: S3에 파일 업로드됨, EC2 상태가 변함, 혹은 우리가 설정한 '매일 아침 9시'라는 시간)
2. 이벤트 버스 (Event Bus): 이벤트가 돌아다니는 "통로"입니다. 모든 이벤트는 이 버스를 타고 흐릅니다.
3. 규칙 (Rule): "어떤 이벤트를 어디로 보낼지" 결정하는 필터입니다. (예: "S3 파일 업로드 이벤트만 골라서 Lambda로 보내!")
4. 대상 (Target): 이벤트를 받아 처리하는 서비스입니다. (예: Lambda, SNS, SQS, Step Functions 등)

---

2. EventBridge의 3가지 주요 기능

① 서비스 간 이벤트 연결 (Event-Driven)

A라는 서비스에서 일이 생기면 B가 즉시 알 수 있게 해줍니다.

• 예: 고객이 회원 가입을 하면(이벤트), 가입 축하 메메일 발송 함수(Lambda)를 실행함.

② 스케줄링 (Scheduled Events)

리눅스의 cron처럼 정해진 시간에 작업을 실행합니다.

• 예: 매주 일요일 밤 12시에 데이터베이스 백업을 실행함. (이전의 CloudWatch Events 기능이 EventBridge로 통합되었습니다.)

③ SaaS 애플리케이션 통합

AWS 서비스뿐만 아니라 외부 서비스(Zendesk, Shopify, Datadog 등)의 이벤트를 AWS 내부로 가져와 처리할 수 있습니다.

 

 

---

EFS( Amazon Elastic File System )vs FSx for Windows

구분	Amazon EFS	Amazon FSx for Windows
주요 OS	Linux	Windows
프로토콜	NFS (Network File System)	SMB (Server Message Block)
특징	자동 확장, 서버리스 느낌	AD(Active Directory) 통합, 윈도우 기능 완벽 지원
공통점	다중 AZ 지원을 통한 고가용성 확보 가능

 

 

1. Amazon FSx for Windows File Server

• 정의: 완전 관리형 Microsoft Windows 파일 시스템입니다.
• 특징: SMB 프로토콜 지원, Active Directory 통합, Windows NTFS 권한 지원 등 기존 Windows 환경을 클라우드로 그대로 옮기기에 최적화되어 있습니다.

2. Amazon FSx File Gateway

• 역할: 온프레미스에서 클라우드의 FSx for Windows File Server에 저지연으로 접근할 수 있게 해주는 가상 어플라이언스입니다.
• 장점: 자주 사용하는 데이터를 온프레미스에 캐싱하여 네트워크 대역폭을 절약하고 사용자 경험을 개선합니다.

 

온프레미스 서버
   ↓ SMB
FSx File Gateway (로컬 캐시)
   ↓ VPN
FSx Windows File Server (AWS)

 

 

 

🔥 초고속 구분법 (시험 필살기)

요구사항정답

파일 → 객체	S3 File Gateway
Windows 파일 서버 하이브리드	FSx File Gateway
블록 스토리지 하이브리드	Volume Gateway

---

⭐ FSx vs EFS vs S3 File Gateway 비교

서비스타입프로토콜특징

FSx Windows	파일	SMB	Windows NTFS
EFS	파일	NFS	Linux 공유
S3 File Gateway	파일 인터페이스	SMB/NFS	실제 저장 S3
FSx Gateway	파일 인터페이스	SMB	Windows 하이브리드

 

 

 

---

AWS Data Pipeline은 서로 다른 AWS 컴퓨팅 및 스토리지 서비스 간에 데이터를 신뢰성 있게 처리하고 이동할 수 있게 해주는 웹 서비스입니다.

쉽게 비유하자면, 데이터라는 화물을 특정 장소에서 다른 장소로 옮기기 위해 **"언제, 어떤 경로로, 어떤 가공을 거쳐서 보낼지"**를 정의하는 스케줄러 겸 워크플로우 관리자라고 이해하시면 됩니다.

---

1. 핵심 기능 및 특징

• 데이터 이동 및 변환: 온프레미스 데이터 소스나 Amazon S3, RDS, DynamoDB, Redshift 간에 데이터를 복사하고 가공할 수 있습니다.
• 스케줄링: 특정 시간 간격(예: 매일 밤 12시)이나 조건에 따라 작업이 실행되도록 예약합니다.
• 종속성 관리: "A 데이터 처리가 성공하면 B 분석 작업을 시작하라"와 같은 복잡한 작업 순서를 관리합니다.
• 장애 복구: 작업이 실패할 경우 자동으로 재시도(Retry)하거나 관리자에게 알림(SNS)을 보냅니다.

---

2. 주요 구성 요소

1. 데이터 노드 (Data Nodes): 데이터가 저장된 위치입니다. (예: S3 경로, SQL 쿼리 결과)
2. 활동 (Activities): 수행할 작업입니다. (예: Hive 쿼리 실행, Redshift로 복사, 쉘 스크립트 실행)
3. 리소스 (Resources): 작업을 수행할 컴퓨팅 자원입니다. (예: EC2 인스턴스, EMR 클러스터)
4. 스케줄 (Schedules): 작업이 실행될 주기입니다.

---

3. 실제 사용 예시

가장 전형적인 시나리오는 다음과 같습니다.

"매일 정해진 시간에 **RDS(데이터베이스)**의 데이터를 추출하여 S3에 백업하고, **EMR(로그 분석)**을 통해 데이터를 정제한 뒤, 최종 결과를 **Redshift(분석 저장소)**에 로드한다."

이 복잡한 과정을 AWS Data Pipeline이 순서대로 관리해 줍니다.

---

4. Amazon Glue와의 차이점 (중요!)

최근에는 많은 데이터 처리 작업이 AWS Glue로 대체되는 추세입니다. 시험이나 실무에서 헷갈리지 않게 비교해 드릴게요.

구분	AWS Data Pipeline	AWS Glue
성격	워크플로우 오케스트레이션	완전 관리형 서버리스 ETL
인프라	EC2나 EMR을 사용자가 정의	서버리스 (인프라 관리 필요 없음)
특징	복잡한 작업 순서 제어에 강점	데이터 카탈로그 및 자동 스키마 감지
권장 상황	직접 제어하고 싶은 리소스가 있을 때	최신 데이터 레이크/ETL 작업 시

---

요약하자면

Data Pipeline은 **"데이터가 한 곳에서 다른 곳으로 흐르는 파이프라인(배관)을 설계하고 관리하는 도구"**입니다. 하지만 최근 대세는 더 자동화된 AWS Glue라는 점을 참고하시면 좋습니다.

 

 

Amazon Glue는 한마디로 **"데이터를 찾고, 변형하고, 결합해서 사용하기 좋게 옮겨주는 관리형 비서"**입니다. 전문 용어로는 서버리스 데이터 통합(ETL) 서비스라고 부릅니다.

여기서 ETL은 데이터를 다룰 때 가장 중요한 3단계를 의미합니다:

1. Extract (추출): 여기저기 흩어진 데이터(S3, RDS, 온프레미스 DB 등)를 가져오기
2. Transform (변형): 필요한 형식으로 바꾸거나, 깨진 데이터를 수정하거나, 합치기
3. Load (적재): 분석하기 좋게 최종 목적지(Redshift, S3 등)에 저장하기

---

 

🛠️ Amazon Glue의 핵심 구성 요소

Glue가 어떻게 일하는지 알면 이해가 훨씬 빠릅니다.

1. Data Catalog (데이터 도서관)

여러 곳에 흩어진 데이터의 정보를 한곳에 모은 목록입니다. "어느 DB에 어떤 테이블이 있고, 컬럼 이름은 뭐다"라는 메타데이터를 저장합니다.

• Crawler (크롤러): 데이터를 스스로 스캔해서 "아, 이건 이런 구조구나!"라고 파악해 카탈로그에 자동으로 등록해줍니다.

2. ETL Job (작업 실행기)

실제로 데이터를 옮기고 변형하는 엔진입니다.

• 파이썬(Python)이나 스파크(Apache Spark) 코드를 생성해줍니다.
• 서버리스이기 때문에 우리가 서버 사양을 고민할 필요 없이 AWS가 알아서 처리해줍니다.

3. DataBrew (시각적 데이터 준비)

코딩을 못 해도 괜찮습니다. 엑셀처럼 생긴 화면에서 클릭 몇 번으로 데이터를 정제할 수 있게 도와줍니다.

---

💡 왜 Glue를 쓰나요? (주요 사용 사례)

• 데이터 레이크 구축: S3에 쌓인 수만 개의 로그 파일을 분석하기 좋게 하나로 합치고 정리할 때 필수입니다.
• 데이터 웨어하우스 준비: 운영용 DB(RDS)에 있는 데이터를 분석용 DB(Redshift)로 옮길 때, 중간에서 형식을 맞춰줍니다.
• 서버 관리 제로: 직접 EC2에 Spark를 설치해서 돌리는 것보다 운영 오버헤드가 훨씬 적습니다.

---

🔍 아까 문제와 연결하기 (Kinesis vs Glue)

아까 스트리밍 문제에서 Glue가 정답이 아니었던 이유는 무엇일까요?

• Kinesis + Lambda: 물 흐르듯 실시간으로 쏟아지는 데이터를 "즉시" 처리하는 데 특화되어 있습니다.
• Glue: 보통 쌓여있는 대량의 데이터를 "한 번에(Batch)" 혹은 정해진 주기마다 처리하는 데 더 강력합니다. (물론 Glue Streaming도 있지만, 운영 효율 면에서 Kinesis가 더 단순합니다.)

---

💡 한 줄 요약

"여기저기 흩어진 데이터를 자동으로 분류(Catalog)하고, 입맛에 맞게 요리(Transform)해서, 원하는 곳에 배달(Load)해주는 서비스"

 

 

 

 

1. 상태 정보 유지 (State Management)

• 작업 북마크는 ETL 작업의 실행 상태 정보를 유지하는 기능입니다.
• S3의 객체 수정 시간이나 고유 식별자를 추적하여, 이전 실행에서 어디까지 처리했는지를 기록(북마크)해 둡니다.

2. 증분 데이터 처리 (Incremental Processing)

• 북마크가 활성화되면, 다음 번 실행 시 AWS Glue는 북마크 이후에 새롭게 추가된 데이터(Incremental Data)만 식별하여 처리합니다.
• 이를 통해 전체 데이터를 매번 재처리하는 낭비를 방지하고 비용과 시간을 절약할 수 있습니다.

---

🔍 시험 필살 포인트: AWS Glue 성능 및 비용 최적화

• 증분 데이터만 처리하고 싶다 → Job Bookmarks (작업 북마크)
• 데이터 포맷을 변환하여 성능을 높이고 싶다 → Parquet 또는 Avro로 변환
• 중복 데이터를 제거하고 싶다 → FindMatches ML Transform

 

 

 

 

---

 

**Amazon EMR (Elastic MapReduce)**는 방대한 양의 데이터를 처리하고 분석하기 위한 클라우드 빅데이터 플랫폼입니다.

쉽게 설명하자면, 컴퓨터 한 대로 처리하기 힘든 엄청난 양의 데이터(빅데이터)를 **수십, 수백 대의 컴퓨터로 구성된 팀(클러스터)**을 짜서 동시에 나누어 처리하게 만드는 서비스입니다.

EMR은 Hadoop/Spark 클러스터입니다. 클러스터 크기를 정하고, 관리하고, 패치를 해야 하므로 운영 오버헤드가 매우 큽니다.

빅데이터 분석

---

1. 핵심 개념: 분산 처리

EMR은 오픈소스 프레임워크인 Apache Hadoop과 Apache Spark 등을 기반으로 작동합니다.

• 분산 처리: 1,000페이지 분량의 책을 혼자 읽으면 오래 걸리지만, 10명이 100페이지씩 나눠 읽으면 금방 끝나는 것과 같은 원리입니다.
• 클러스터 구조:
  • 마스터 노드: 작업을 지시하고 팀을 관리합니다.
  • 코어/태스크 노드: 실제로 데이터를 처리하고 저장하는 일꾼들입니다.

---

2. 주요 특징

1. 확장성 (Elastic): 데이터 양에 따라 컴퓨터(노드)를 순식간에 늘리거나 줄일 수 있습니다. 작업이 끝나면 클러스터를 바로 삭제해 비용을 절감할 수 있습니다.
2. 저비용: 사용하지 않을 때는 꺼두면 되고, 특히 **스팟 인스턴스(Spot Instances)**를 활용하면 표준 가격보다 최대 90% 저렴하게 빅데이터를 분석할 수 있습니다.
3. 다양한 도구 지원:
   • Spark: 실시간 데이터 처리 및 머신러닝에 매우 빠름.
   • Hive/Presto: SQL 문법으로 빅데이터를 쿼리할 수 있게 해줌.
   • HBase: 대규모 NoSQL 데이터베이스.

---

3. 언제 사용하나요?

• 로그 분석: 수백만 명의 사용자가 남긴 웹사이트 방문 기록 분석.
• 데이터 변환 (ETL): 가공되지 않은 원시 데이터를 분석하기 좋은 형태로 깔끔하게 정리할 때.
• 재무 모델링: 복잡한 알고리즘을 사용해 주가 예측이나 위험 분석을 할 때.
• 유전체 분석: 엄청난 용량의 유전자 지도를 분석할 때.

---

4. EMR vs Redshift (비교)

두 서비스 모두 빅데이터를 다루지만 목적이 다릅니다.

• Amazon EMR: 데이터가 정해진 형태가 없거나(비정형), 복잡한 로직으로 데이터를 **"요리(가공)"**하는 과정에 강점이 있습니다.
• Amazon Redshift: 이미 잘 정리된 데이터를 고속으로 **"조회(쿼리)"**하여 리포트를 뽑아내는 데 최적화되어 있습니다.

---

정리하자면

EMR은 **"수많은 컴퓨터를 한 팀으로 묶어 빅데이터를 빠르게 처리해 주는 대규모 연산 작업반"**이라고 보시면 됩니다.

 

 

 

---

 

 

**AWS Certificate Manager(ACM)**는 웹사이트와 애플리케이션을 안전하게 보호하는 SSL/TLS 인증서를 발급하고 관리하는 서비스입니다. 보안 통신(HTTPS)을 구축할 때 핵심적인 역할을 합니다.

중요한 포인트들을 중심으로 개념을 정리해 드립니다.

---

1. 주요 기능

• 인증서 발급 및 관리: 공인(Public) 및 사설(Private) SSL/TLS 인증서를 무료로 발급받거나 외부에서 가져온 인증서를 보관할 수 있습니다.
• 자동 갱신 (Managed Renewal): ACM에서 발급한 공인 인증서는 만료 전 AWS가 자동으로 갱신해주어 서비스 중단을 방지합니다.
• AWS 서비스와 통합: ALB(Application Load Balancer), CloudFront, API Gateway 등과 클릭 몇 번으로 연동됩니다.

---

2. 인증서 발급/등록 방식 (가장 중요!)

인증서를 어떻게 준비하느냐에 따라 관리 방식이 완전히 달라집니다.

구분	ACM 발급 인증서 (Public)	가져온 인증서 (Imported)
출처	AWS (Amazon이 CA 역할)	외부 업체 (DigiCert, GoDaddy 등)
비용	무료	외부 업체 결제 비용 발생
자동 갱신	지원함 (가장 큰 장점)	지원 안 함 (만료 전 수동 재업로드 필요)
사용 사례	일반적인 모든 AWS 웹 서비스	특정 외부 CA 인증서만 써야 하는 보안 정책 시

 

ACM은 기본적으로 만료 45일 전부터 CloudWatch 이벤트를 발생시키지만, ACM 내부에서 직접 SNS 주제에 사용자 지정 메시지를 게시하는 "규칙 추가" 기능은 존재하지 않습니다.

 

---

 

AWS AI 데이터 분석 서비스 비교

서비스용도핵심 기능시험 키워드

Amazon Textract	문서 OCR	PDF / 이미지에서 텍스트·표·폼 추출	문서 텍스트 추출
Amazon Rekognition	이미지·영상 분석	얼굴 인식, 객체 탐지, 영상 분석	이미지 분석
Amazon Comprehend	일반 NLP	감정 분석, 키워드, 엔터티 추출	텍스트 의미 분석
Amazon Comprehend Medical	의료 NLP / PHI	의료 용어, PHI 탐지	의료 데이터 분석
Amazon Macie	S3 PII 탐지	S3 민감 데이터 자동 탐지	S3 개인정보 보호

 

 

 

---

AWS Direct Connect (DX)

• 온프레미스에서 AWS로 연결되는 전용 네트워크 회선입니다.
• 인터넷을 거치지 않으므로 대역폭이 일관되고 지연 시간이 매우 짧습니다.

AWS Site-to-Site VPN

• 공용 인터넷을 통해 암호화된 터널을 생성합니다.
• 설정이 빠르고 저렴하지만, 인터넷 환경에 따라 지연 시간이 가변적일 수 있습니다.

 

---

Amazon RDS Proxy는 관계형 데이터베이스(RDS)를 위해 구축된 완전 관리형 고가용성 데이터베이스 프록시입니다.

쉽게 말해, 애플리케이션과 데이터베이스 사이에서 "교통 정리" 역할을 하여 애플리케이션의 확장성과 탄력성을 높여주는 서비스입니다.

---

1. 핵심 기능 및 효과

① 커넥션 풀링 (Connection Pooling)

대부분의 관계형 DB는 연결(Connection)마다 메모리와 CPU 자원을 소모합니다. 애플리케이션 인스턴스가 급증하면 DB가 연결을 감당하지 못해 뻗어버릴 수 있는데, RDS Proxy가 이 연결들을 효율적으로 묶어서 관리(Pooling)함으로써 DB의 부담을 획기적으로 줄여줍니다.

② 장애 조치 시간 단축 (Fast Failover)

데이터베이스에 장애가 발생하여 예비(Standby) DB로 전환될 때, 일반적인 경우에는 애플리케이션이 새로운 DB 주소를 찾고 다시 연결하는 데 시간이 걸립니다. 하지만 RDS Proxy를 사용하면 프록시가 알아서 새 DB로 연결을 돌려주기 때문에 장애 조치 시간이 최대 60%까지 단축됩니다.

③ 보안 강화

애플리케이션 코드에 DB 자격 증명(ID/PW)을 직접 저장하는 대신, AWS Secrets Manager와 연동하여 안전하게 관리할 수 있습니다. 또한 IAM 인증을 강제할 수 있어 보안 계층이 하나 더 추가됩니다.

---

2. 언제 사용해야 할까요?

• Serverless 환경: AWS Lambda처럼 짧은 시간에 수많은 인스턴스가 생성되고 사라지는 환경에서는 DB 연결이 폭주하기 쉬운데, 이때 RDS Proxy가 필수적입니다.
• 예측 불가능한 트래픽: Auto Scaling으로 인해 EC2 인스턴스가 갑자기 늘어날 때 DB 연결 오류를 방지하고 싶을 때 사용합니다.
• 고가용성 중시: 위 문제 상황처럼 데이터베이스 장애 시 서비스 중단 시간을 최소화해야 할 때 매우 유용합니다.

 

 

 

---

Amazon DynamoDB는 AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다. 어떤 규모에서도 10밀리초 미만의 지연 시간(Single-digit millisecond)을 보장하는 고성능 데이터베이스로, 서버 관리가 필요 없는 서버리스(Serverless) 서비스의 핵심입니다.

---

1. 핵심 문제 유형 (SAA 시험 단골 주제)

• 성능 최적화: 읽기/쓰기 용량 모드(On-demand vs Provisioned) 선택.
• 고가용성 및 재해 복구: 전역 테이블(Global Tables)과 PITR (Point-In-Time Recovery) (지정 시간 복구).
• 검색 최적화: 로컬 보조 인덱스(LSI)와 글로벌 보조 인덱스(GSI)의 차이.
• 비용 절감: TTL(Time to Live)을 이용한 데이터 자동 삭제.

왜 TTL(Time to Live)이 정답인가?

1. 개발 노력 최소화: 별도의 코드(Lambda)나 서버(EC2)를 운영할 필요 없이, 테이블 설정에서 특정 속성(예: ExpirationTime)을 지정하기만 하면 됩니다.
2. 비용 최소화: DynamoDB TTL에 의해 삭제되는 항목은 쓰기 용량(WCU)을 소비하지 않으며 별도의 비용이 들지 않습니다.
3. 자동화: 데이터가 생성될 때 "현재 시간 + 30일"의 타임스탬프를 넣어두면, 배경에서 DynamoDB가 알아서 유효 기간이 지난 데이터를 삭제합니다.
4. (TTL은 만료 후 며칠 내에 삭제됨).

---

2. 기본 데이터 구조

DynamoDB는 고정된 스키마가 없는 유연한 구조를 가집니다.

• Table (테이블): 데이터의 집합.
• Item (항목): 행(Row)에 해당하며, 속성(Attribute)의 집합입니다.
• Attribute (속성): 열(Column)에 해당하며, 데이터의 최소 단위입니다.
• Primary Key (기본 키): 데이터를 고유하게 식별합니다.
  • Partition Key (PK): 데이터를 어느 파티션(물리적 서버)에 저장할지 결정하는 해시 키입니다.
  • Sort Key (SK): 동일한 PK 내에서 데이터를 정렬하고 검색하는 데 사용됩니다.

---

3. 주요 기능 및 개념

① 읽기/쓰기 용량 모드

• 온디맨드 (On-demand): 트래픽을 예측할 수 없을 때 사용합니다. 사용한 만큼만 비용을 지불합니다.
• 프로비저닝 (Provisioned): 트래픽이 일정할 때 미리 용량(RCU, WCU)을 예약하여 비용을 절감합니다. Auto Scaling이 가능합니다.
• Reserved Capacity): 예약 용량은 24시간/365일 지속적으로 일정 수준 이상의 부하가 발생하는 워크로드에 적합합니다. 일주일에 4시간만 사용하는 이 사례에서는 예약 비용이 실제 사용량보다 훨씬 커지게 됩니다.

② 인덱스 (Index)

기본 키 이외의 속성으로 데이터를 검색해야 할 때 사용합니다.

• LSI (Local Secondary Index): PK는 기존과 같지만 SK만 다른 인덱스입니다. 테이블 생성 시에만 만들 수 있습니다.
• GSI (Global Secondary Index): PK와 SK가 모두 원본과 다를 수 있는 인덱스입니다. 언제든 생성/삭제가 가능하며 가장 많이 사용됩니다.

③ 고가용성과 백업

• Global Tables (전역 테이블): 여러 AWS 리전에 데이터를 실시간으로 복제합니다. (멀티 리전 활성-활성 구성)
• PITR (지정 시간 복구): 최근 35일간의 데이터를 초 단위로 기록하여 데이터 손상 시 특정 시점으로 복원합니다.

④ 성능 향상 도구

• DynamoDB Streams: 테이블의 데이터 변경(추가/수정/삭제) 이벤트를 실시간으로 캡처합니다. (Lambda와 연동하여 실시간 알림이나 트리거 구현)

스트림을 읽고 삭제 요청을 보내는 방식은 쓰기 용량(WCU)을 소모하므로 비용이 발생하며, Lambda 코드 작성 및 관리가 필요합니다. TTL보다 비용과 노력이 더 많이 듭니다.

• DAX (DynamoDB Accelerator): DynamoDB 전용 인메모리 캐시입니다. 읽기 성능을 밀리초($ms$)에서 마이크로초($\mu s$) 단위로 끌어올립니다.

---

4. S3와의 비교 (언제 쓰는가?)

구분	Amazon DynamoDB	Amazon S3
유형	NoSQL 데이터베이스	객체 스토리지
데이터 크기	항목당 최대 400KB	객체당 최대 5TB
주요 용도	세션 상태 저장, 사용자 프로필, 실시간 쇼핑 카트 등 빠른 검색이 필요한 데이터	이미지, 비디오, 로그 파일 등 대용량 정적 파일 저장

 

 

 

---

Public vs Private 서비스 완벽 비교표

기준: VPC 내부 배치 여부

구분                                Private 서비스 (VPC 내부)                                                       Public 서비스 (VPC 외부)

 

컴퓨팅	EC2, ECS, EKS worker	Lambda
DB	RDS, Aurora, ElastiCache	DynamoDB
스토리지	EBS, EFS, FSx	S3, Glacier
네트워크	ALB, NLB, NAT Gateway	Route53
메시징	—	SNS, SQS
분석	—	Athena, Kinesis

 

 

 

---

Gateway Endpoint란?

대표적으로:

• Amazon S3
• Amazon DynamoDB

이 두 서비스에만 사용 가능.

VPC 내부에서 인터넷/NAT 없이 AWS 네트워크를 통해 직접 접근하게 해주는 기능이야.

 

👉 S3/DynamoDB → Gateway Endpoint → 무료 (VPC 내부에서만 유효합니다. )
👉 그 외 대부분 → Interface Endpoint → 유료

Interface VPC Endpoint (AWS PrivateLink): 서비스에 프라이빗 IP 주소를 할당합니다. 온프레미스 및 피어링된 VPC에서 접근할 때 필수적입니다.

 

 

 

 

1️⃣ Endpoint vs NAT vs IGW 그림 (시험 100% 이해)

 

                 🌐 Internet
                     │
                 ┌───────┐
                 │  IGW  │
                 └───────┘
                     │
        ┌────────────────────────┐
        │          VPC           │
        │                        │
        │   Public Subnet        │
        │    ┌────────────┐      │
        │    │ NAT Gateway │───────► Internet
        │    └────────────┘      │
        │          ▲             │
        │          │             │
        │   Private Subnet       │
        │   ┌────────────┐       │
        │   │    EC2      │
        │   └────────────┘       │
        │        │                │
        │        └──────────────► Endpoint → AWS 서비스
        │                         (S3, DynamoDB 등)
        └────────────────────────┘

 

 

⭐ 핵심 차이

구분                              IGW                     NAT Gateway                                        Endpoint

 

목적	인터넷 연결	Private → 인터넷 outbound	AWS 서비스 private 접근
Internet 필요	O	O	❌
Public IP 필요	O	O	❌
보안	낮음	중간	최고
비용	무료	비쌈	Gateway 무료 / Interface 유료
시험 키워드	public web	private outbound	NAT 비용 절감 / 보안

 

 

 

2️⃣ Interface Endpoint 내부 동작 그림 (PrivateLink 구조)

          VPC 내부
 ┌──────────────────────────┐
 │                          │
 │  Private Subnet          │
 │   ┌────────────┐         │
 │   │    EC2      │         │
 │   └──────┬─────┘         │
 │          │                │
 │     Interface Endpoint    │
 │     (ENI 생성됨)          │
 │          │                │
 └──────────┼────────────────┘
            │  AWS Private Network
            ▼
      AWS 서비스 (Lambda, SQS, SNS 등)

 

                    🌐 Internet
                        │
                    ┌────────┐
                    │  IGW   │
                    └────────┘
                        │
        ┌────────────────────────────────┐
        │               VPC              │
        │                                │
        │   🔹 Public Subnet             │
        │   ┌─────────────────────┐      │
        │   │     NAT Gateway      │──────► Internet
        │   └─────────────────────┘      │
        │          ▲                     │
        │          │ (0.0.0.0/0 route)  │
        │                                │
        │   🔹 Private Subnet            │
        │   ┌─────────────────────┐      │
        │   │        EC2           │      │
        │   └─────────────────────┘      │
        │        │         │             │
        │        │         │             │
        │        │         └────────────► Interface Endpoint
        │        │                       (PrivateLink, ENI 생성)
        │        │
        │        └────────────► Gateway Endpoint
        │                        (Route Table 연결)
        │                                │
        │                                ▼
        │                         S3 / DynamoDB
        └────────────────────────────────┘

 

 

 

개념 정리: S3 엔드포인트 선택 가이드

구분	게이트웨이 엔드포인트 (Gateway)	인터페이스 엔드포인트 (Interface)
비용	무료	유료 (시간당 요금 + 데이터 처리량)
설정 방식	라우팅 테이블 업데이트	ENI 생성 및 DNS 활용
보안 그룹	연결 불가	연결 가능 (세밀한 제어)
접근 경로	VPC 내부에서만 가능	온프레미스(Direct Connect 등)에서도 가능

 

AWS 시험 단골 유형 (VPC 엔드포인트 공식)

요구사항 키워드	정답 공식
가장 비용 효율적인 S3 연결	Gateway Endpoint
온프레미스에서 S3로 프라이빗 연결	Interface Endpoint
엔드포인트 자체에 보안 그룹 적용	Interface Endpoint
특정 엔드포인트로만 S3 접근 제한	S3 버킷 정책 내 aws:sourceVpce 조건 사용

 

 

 

---

배스천 호스트 (Bastion Host)

• 프라이빗 네트워크에 있는 리소스에 접근하기 위해 퍼블릭 네트워크에 배치된 특수 목적용 서버입니다. '점프 박스(Jump Box)'라고도 부릅니다.

 

 

 

---

 

 

Amazon API Gateway는 한마디로 **"애플리케이션의 거대한 정문(Front Door)"**입니다.

수많은 클라이언트(스마트폰, 웹 브라우저 등)가 우리 서버에 접근하려고 할 때, 이를 일일이 상대하는 대신 API Gateway가 맨 앞에서 모든 요청을 받아 정리하고 전달하는 역할을 합니다.

 

"API Gateway는 'API 전용 문'이 아니라, 'HTTP로 대화하는 모든 것을 위한 입구'입니다. 외부 API든, 사용자 양식이든, 이미지 파일이든 상관없이 일단 받아서 적절한 담당자(AWS 서비스)에게 연결해줍니다!"

---

1. API Gateway의 핵심 역할

API Gateway는 단순히 요청을 전달만 하는 게 아니라, 정문 보안 요원처럼 여러 가지 중요한 일을 처리합니다.

• 인증 및 권한 부여: "너 우리 회원 맞아?"라고 확인하며 허가된 사용자만 들여보냅니다.
• 트래픽 제어 (Throttling): 초당 요청 수를 제한해서 백엔드 서버가 과부하로 터지는 것을 막습니다.
• 프로토콜 변환: 클라이언트의 HTTP 요청을 받아서 Lambda, SQS, EC2 등 적절한 AWS 서비스가 알아들을 수 있는 방식으로 변환합니다.
• API 버전 관리: v1, v2 처럼 여러 버전의 API를 동시에 운영할 수 있게 해줍니다.
• 모니터링 및 로깅: 누가 언제 어떤 요청을 보냈는지 전부 기록(CloudWatch 연동)합니다.

---

2. 왜 API Gateway를 쓰나요? (장점)

만약 API Gateway가 없다면, 여러분은 서버마다 보안 설정, 트래픽 제한, 모니터링 코드를 일일이 짜 넣어야 합니다. 하지만 API Gateway를 쓰면 다음과 같은 이점이 있습니다.

1. 단일 진입점: 클라이언트는 복잡한 내부 서버 주소를 몰라도 됩니다. 오직 API Gateway 주소 하나만 알면 됩니다.
2. 보안 강화: 백엔드 서비스(Lambda, EC2 등)를 공용 인터넷에 노출하지 않고 숨길 수 있습니다.
3. 서버리스 아키텍처의 핵심: 특히 AWS Lambda와 궁합이 환상적입니다. 서버를 24시간 띄워놓지 않아도 요청이 올 때만 Lambda를 깨워 실행할 수 있습니다.
4. IAM 인증과 HTTPS를 지원

 

 

Client
  │
  ▼
API Gateway
  │
  ├── 인증 검사
  ├── 요청 변환
  ├── Rate limit
  ├── 캐싱
  ▼
Backend (Lambda / EC2 / SQS / Step Functions)

 

 

 

 

---

✅  DataSync vs Storage Gateway vs Snowball (시험 핵심 비교)

서비스                                            용도                                                                       언제 사용

          

AWS DataSync	대용량 파일 온라인 전송	빠른 파일 마이그레이션 / DataSync는 네트워크를 통해 데이터를 전송하는 서비스입니다.
AWS Storage Gateway	하이브리드 스토리지 (캐시/게이트웨이)	온프레미스에서 계속 파일 사용
AWS Snowball	오프라인 물리 디바이스 전송	네트워크 느림 / PB급 데이터

 

 

✅ 온프레미스 → S3 전송 문제 100% 패턴

요구사항정답

파일 마이그레이션	DataSync
파일 공유 유지	Storage Gateway File
블록 스토리지 확장	Storage Gateway Volume
테이프 백업	Storage Gateway Tape
PB급 오프라인	Snowball
DB 마이그레이션	DMS
실시간 스트리밍	Kinesis

 

 

 

⭐ 아키텍처 전체 그림 (시험 100% 이해)

온프레미스 데이터
     │
     ├── 빠른 파일 이동 → DataSync
     │
     ├── 하이브리드 파일 사용 → Storage Gateway
     │
     ├── 네트워크 불가능 → Snowball
     │
     └── DB 이동 → DMS

 

 

 

---

AWS Backup은 AWS 내의 다양한 서비스에 흩어져 있는 데이터를 한곳에서 중앙 집중적으로 관리하고 자동화하는 백업 전용 비서입니다.

이전에는 서비스마다(EC2 따로, RDS 따로, DynamoDB 따로) 백업 설정을 일일이 해야 했지만, AWS Backup을 사용하면 단 하나의 **'백업 정책'**으로 여러 서비스를 한꺼번에 관리할 수 있습니다.

 

 

• 중앙 집중식 관리: AWS Backup은 RDS, EBS, EFS, S3 등 다양한 서비스의 백업을 한곳에서 정책 기반으로 관리할 수 있는 완전 관리형 서비스입니다.
• 유연한 스케줄링: '백업 계획(Backup Plan)'을 통해 매일 백업을 수행하고, 2년(730일) 뒤에 만료되도록 설정하는 것이 가장 깔끔하고 표준적인 방법입니다
• 수명 주기 자동화: AWS Backup 내에서 '콜드 스토리지로 이동(Transition to cold storage)' 옵션과 '보존 기간(Retention period)'을 직접 설정할 수 있어 6개월/7년 요구사항을 완벽히 충족합니다. Cold Storage (콜드 스토리지): 자주 접근하지 않는 백업 데이터를 저렴한 비용으로 저장하는 계층입니다. (DynamoDB 백업의 경우에도 지원됨)

 

---

🛠️ AWS Backup의 핵심 구성 요소

1. 백업 계획 (Backup Plan)

백업의 **'규칙'**을 정하는 곳입니다. 다음과 같은 내용을 설정합니다.

• 백업 빈도: 매일 할 것인가, 매주 할 것인가?
• 백업 시간: 시스템 사용량이 적은 새벽 3시에 할 것인가?
• 보존 기간: 7년 동안 보관할 것인가, 30일 후에 지울 것인가?

2. 백업 볼트 (Backup Vault)

백업본을 저장하는 **'안전한 금고'**입니다.

• 백업 데이터는 이곳에 암호화되어 저장됩니다.
• Vault Lock 기능을 사용하면, 루트 사용자라도 정해진 기간 동안 백업을 절대 삭제할 수 없게 강력하게 보호할 수 있습니다 (랜섬웨어 방어용).

3. 리소스 할당 (Resource Assignment)

어떤 대상을 백업할지 정합니다. 특정 인스턴스 ID를 지정할 수도 있지만, '태그(Tag)' 기반으로 지정하는 것이 가장 효율적입니다.

• 예: Project: Finance라는 태그가 붙은 모든 자원은 자동으로 백업해라!

---

🌟 왜 AWS Backup을 쓰나요? (주요 장점)

• 운영 효율성: 앞서 살펴본 문제처럼 7년 보관 같은 복잡한 요구사항을 클릭 몇 번으로 해결합니다.
• 규정 준수(Compliance): 금융이나 의료 데이터처럼 법적으로 일정 기간 백업을 유지해야 하는 경우, 증거 자료로 제출하기 가장 좋습니다.
• 교차 리전/계정 백업: 원본 데이터가 있는 리전이 아닌 **다른 리전(예: 서울 → 도쿄)**이나 다른 AWS 계정으로 백업본을 복사해둘 수 있어 재난 복구(DR)에 강력합니다.

---

🔍 지원하는 대표 서비스

AWS Backup은 거의 모든 주요 저장소 서비스를 지원합니다.

• 컴퓨팅: EC2 인스턴스 (AMI), AWS Lambda
• 스토리지: Amazon S3, EBS 볼륨, EFS, FSx
• 데이터베이스: RDS, Aurora, DynamoDB, DocumentDB, Neptune
• 온프레미스: AWS Storage Gateway를 통한 온프레미스 데이터

---

💡 요약하자면

"여러 AWS 서비스의 백업 규칙을 한곳에서 정의하고, 자동으로 금고에 넣어 보관하며, 필요할 때 언제든 복구해주는 통합 관리 도구"

 

 

 

네, 맞습니다! AWS Backup은 기본적으로 각 서비스의 '스냅샷(Snapshot)' 기술을 활용하여 중앙에서 관리하는 서비스입니다.

단순히 스냅샷을 찍는 것에 그치지 않고, 여러 서비스에 흩어져 있는 백업 기능을 한곳으로 모아 **정책 기반(Backup Plan)**으로 자동화해 주는 역할을 합니다.

---

1. AWS Backup의 작동 원리

AWS Backup은 스스로 데이터를 저장하는 독립적인 스토리지를 가진 것이 아니라, 대상 서비스(EBS, RDS, S3 등)의 스냅샷 기능을 호출하여 실행합니다.

• 스냅샷 생성: 사용자가 정한 일정(예: 매일 새벽 2시)에 따라 해당 서비스의 API를 호출하여 스냅샷을 찍습니다.
• 복제 및 보관: 생성된 스냅샷은 **Backup Vault(백업 볼트)**라는 논리적 컨테이너에 저장됩니다.
• 생명주기 관리: 설정된 기간(예: 7년)이 지나면 자동으로 스냅샷을 삭제하거나, 비용 절감을 위해 S3 Glacier 같은 저렴한 저장소로 이동시킵니다.

---

2. 왜 그냥 스냅샷을 안 쓰고 AWS Backup을 쓰나요?

각 서비스(RDS 콘솔, EBS 콘솔 등)에서 직접 스냅샷을 예약할 수도 있지만, AWS Backup을 쓰면 다음과 같은 강력한 장점이 있습니다.

기능	개별 서비스 스냅샷	AWS Backup
중앙 집중 관리	서비스별로 따로 설정해야 함	한 곳에서 모든 서비스 관리
교차 리전 복제	수동 또는 복잡한 설정 필요	정책 설정으로 자동 복제
교차 계정 백업	설정이 매우 까다로움	조직(Organizations) 단위로 가능
규정 준수(WORM)	기본적으로 수정/삭제 가능	Vault Lock으로 삭제 원천 봉쇄 가능
통합 리포팅	확인이 어려움	백업 성공/실패 통합 모니터링

---

3. 이전 문제(재해 복구)에서 정답이 아니었던 이유

이전 문제에서 AWS Backup(스냅샷 기반)이 정답이 아니었던 결정적인 이유는 '복구 시간(RTO)' 때문입니다.

1. 스냅샷의 한계: 스냅샷은 '특정 시점'의 기록입니다. 이를 복구하려면 새로운 인스턴스를 생성하고 데이터를 로드하는 과정이 필요한데, 데이터가 크면 이 과정만으로도 30분을 훌쩍 넘길 수 있습니다.
2. Aurora 복제본(정답 A)의 우위: 복제본은 이미 데이터가 로드된 상태로 '대기' 중입니다. 장애 시 클릭 한 번(승격)으로 즉시 메인 DB가 될 수 있어 30분 이내 복구에 훨씬 유리합니다.

---

4. AWS 시험 단골 유형 (AWS Backup 관련)

시험에서 AWS Backup이 정답으로 나올 때는 보통 이런 문구가 포함됩니다.

• "여러 AWS 서비스에 걸쳐 중앙 집중식 백업 정책이 필요함"
• "랜섬웨어 방지를 위해 백업본을 **삭제 불가능(Write Once Read Many)**하게 보관해야 함"
• "규정 준수를 위해 **교차 계정(Cross-account)**으로 백업본을 복사해야 함"

한 줄 요약: AWS Backup은 **스냅샷을 "똑똑하게 관리해 주는 비서"**입니다!

 

 

 

---

 

프로비저닝(Provisioning) 모드는 한마디로 **"내가 사용할 양을 미리 예약하는 방식"**입니다.

식당에 비유하자면, 손님이 몇 명 올지 몰라서 그때그때 주문받는 게 아니라 **"오늘 저녁 7시에 100인분 차려주세요"**라고 미리 예약하는 것과 같습니다.

 

 

1. 어떻게 작동하나요?

프로비저닝 모드에서는 두 가지 값을 우리가 직접 설정해야 합니다.

1. RCU (Read Capacity Units): 초당 얼마나 많은 데이터를 읽을 것인가?
2. WCU (Write Capacity Units): 초당 얼마나 많은 데이터를 쓸 것인가?

만약 RCU를 100으로 설정했다면, 실제 데이터를 하나도 읽지 않더라도 AWS는 100만큼의 능력을 상시 대기시키고 그만큼의 비용을 청구합니다.

---

2. 프로비저닝 모드의 특징

✅ 장점: 비용 예측 가능

• 트래픽이 일정하다면 온디맨드보다 훨씬 저렴합니다.
• 미리 대량의 용량을 예약(Reserved Capacity)하면 추가 할인을 받을 수 있어, 대규모 서비스에서 비용을 아끼기에 가장 좋습니다.

❌ 단점: 유연성 부족

• 설정한 용량을 넘어서는 트래픽이 들어오면 **Throttling(요청 거부)**이 발생합니다.
• 트래픽이 없는 시간에도 예약한 만큼의 비용을 계속 내야 하므로, 사용하지 않는 시간에는 돈이 아까울 수 있습니다.

---

3. 보완책: Auto Scaling (자동 확장)

프로비저닝 모드의 단점을 보완하기 위해 Auto Scaling 기능을 켤 수 있습니다.

• 트래픽이 늘어나면 설정값이 자동으로 올라가고, 줄어들면 내려갑니다.
• 하지만! 앞서 문제에서 보았듯이, 이 확장이 일어나는 데는 몇 분 정도의 시간이 걸립니다. 그래서 "매우 빠르게(Sudden Spikes)" 발생하는 트래픽에는 대응하지 못하고 에러가 날 수 있는 것입니다.

---

💡 온디맨드 vs 프로비저닝, 결정적 차이

구분	온디맨드 (On-demand)	프로비저닝 (Provisioned)
비유	먹은 만큼 계산하는 뷔페	미리 예약한 정식 코스
비용	요청 건당 과금 (비쌈)	시간당 예약 용량 과금 (저렴)
대응	즉각적인 폭발적 트래픽 대응 가능	점진적인 트래픽 변화에 유리
관리	관리할 것 없음 (완전 자동)	RCU/WCU 최적화 관리 필요

---

🔍 시험 공부 팁

• "트래픽이 일정하고 예측 가능하다" → 프로비저닝 모드
• "트래픽을 전혀 모르겠고 갑자기 튄다" → 온디맨드 모드

 

⭐ 시험 암기 공식 (진짜 중요)

상황                                                                                   정답

       

예측 불가 트래픽	On-demand
스파이크 트래픽	On-demand
유휴 시간 많음	On-demand
일정한 트래픽	Provisioned
비용 최저 (안정 트래픽)	Provisioned + Auto Scaling

 

 

 

 

---

"계정 간(Cross-Account) 암호화 리소스 공유" 문제가 나오면 다음 두 단계를 기억하세요!

1. 리소스 공유: AMI의 launchPermission이나 EBS/S3의 정책에 상대 계정 ID 추가.
2. 열쇠 공유: 원본 계정 KMS 키 정책에 상대 계정의 kms:CreateGrant 또는 kms:Decrypt 권한 허용.

 

 

**AWS Key Management Service (AWS KMS)**는 데이터를 암호화하거나 디지털 서명에 사용하는 암호화 키를 생성하고 관리하는 완전 관리형 서비스입니다.

쉽게 말해, 클라우드상의 모든 중요한 데이터(S3 파일, DB 기록 등)를 잠그고 여는 '마스터키'들을 보관하고 통제하는 금고라고 이해하시면 됩니다.

 

 

• AWS KMS (Key Management Service): * 데이터를 암호화하는 데 사용되는 **고객 마스터 키(CMK)**를 쉽게 생성하고 제어할 수 있게 해주는 서비스입니다.
  • 하드웨어 보안 모듈(HSM)을 사용하여 키를 안전하게 보호합니다.
  • CloudTrail과 통합되어 "누가, 언제, 어떤 키를 사용했는지"에 대한 모든 로그를 남깁니다.
• 운영 부담 감소: 사용자가 직접 서버를 띄워 키 관리 소프트웨어를 설치하거나 하드웨어를 관리할 필요가 전혀 없습니다.

 

 

---

1. AWS KMS의 주요 기능

• 키 생성 및 제어: 암호화 키를 직접 생성하고, 누가 언제 어떤 용도로 사용할지 정밀하게 제어할 수 있습니다.
• FIPS 140-2 레벨 3 보안: 키는 하드웨어 보안 모듈(HSM) 내부에 안전하게 보관되어, AWS 직원조차도 여러분의 키를 평문으로 추출할 수 없습니다.
• 통합 서비스 암호화: S3, EBS, RDS, Lambda 등 100개가 넘는 AWS 서비스와 클릭 한 번으로 통합되어 데이터를 암호화합니다.
• 감사(Audit): AWS CloudTrail과 연동되어 "누가, 언제, 어떤 키로 어떤 데이터를 풀었는지" 모든 기록을 남깁니다.

 

 

 

 

---

AWS Config는 한마디로 **"AWS 리소스의 기록보관소이자 규정 준수 감시관"**입니다.

여러분의 AWS 계정에 있는 리소스(EC2, S3, RDS 등)가 어떻게 설정되어 있는지 변경 이력을 기록하고, 그 설정이 회사의 보안 정책이나 규정에 맞는지 자동으로 검사해주는 서비스입니다.

---

🛠️ AWS Config의 3가지 핵심 기능

1. 리소스 인벤토리 및 이력 관리 (Configuration History)

• "누가 어제 보안 그룹의 포트를 열었지?" 같은 질문에 답을 줍니다.
• 리소스의 설정이 시간이 지남에 따라 어떻게 변했는지 타임라인 형태로 보여줍니다.

2. AWS Config 규칙 (Rules)

• **'이상적인 설정 상태'**를 정의하고 실제 리소스가 이를 지키는지 검사합니다.
• 관리형 규칙(Managed Rules): AWS가 미리 만들어둔 규칙 (예: "S3 버킷은 퍼블릭 읽기가 불가능해야 함", "인증서는 30일 이내에 만료되면 안 됨").
• 사용자 지정 규칙(Custom Rules): Lambda를 사용해 우리 회사만의 독특한 규칙을 직접 만듭니다.

3. 지속적 모니터링 및 알림

• 설정이 규칙에서 벗어나는 순간(비준수/Non-compliant), 이를 즉시 감지하여 EventBridge나 SNS를 통해 알람을 보냅니다.

---

🌟 왜 AWS Config를 쓰나요? (주요 이점)

• 보안 및 규정 준수 (Compliance): 금융, 의료 등 규제가 까다로운 산업에서 "우리 시스템은 항상 안전하게 설정되어 있다"는 것을 증명하는 증거 자료로 활용됩니다.
• 장애 조치 및 디버깅: 갑자기 서비스가 안 될 때, 최근에 변경된 설정이 무엇인지 바로 확인하여 원인을 찾을 수 있습니다.
• 자동 수정 (Remediation): 비준수 사항이 발견되면 자동으로 원래대로 돌려놓거나 특정 조치를 취하도록 설정할 수 있습니다. (예: 퍼블릭으로 열린 S3 버킷을 발견 즉시 프라이빗으로 강제 변경)

 

 

 

---

**사용자 지정 오리진(Custom Origin)**이란, Amazon CloudFront가 데이터를 가져오는 원본 서버가 AWS 내부 서비스(S3 등)가 아닌 외부 서버인 경우를 말합니다.

쉽게 말해, CloudFront라는 "배달 서비스"가 물건을 가지러 가는 "창고"가 여러분의 자체 전산실(온프레미스) 서버나 타사 클라우드 서버일 때 이를 '사용자 지정 오리진'이라고 부릅니다.

---

1. 주요 특징

• 어디든 가능: 도메인 이름(DNS)이나 IP 주소로 접근 가능한 서버라면 전 세계 어디에 있든 오리진으로 설정할 수 있습니다.
• 프로토콜 선택: HTTP 또는 HTTPS를 선택하여 원본 서버와 통신할 수 있습니다.
• 유연성: AWS로 완전히 이사 오기 전, 온프레미스 장비를 그대로 활용하면서 전 세계 가속(CDN) 혜택만 받고 싶을 때 유용합니다.

 

 

---

✅ EC2 구매 옵션 전체 비교

옵션                                       가격                                    안정성                       특징                         사용 상황

 

On-Demand	💰 💰 💰 비쌈	⭐⭐⭐⭐⭐	필요할 때 즉시 사용	dev/test, 트래픽 불규칙 / 약정 없음
Reserved Instance (RI)	💰💰 할인 (최대 72%)	⭐⭐⭐⭐⭐	1~3년 약정	항상 실행 프로덕션
Savings Plan	💰💰 할인 (유연함)	⭐⭐⭐⭐⭐	컴퓨팅 사용량 약정	RI보다 유연
Spot Instance	💰 매우 저렴 (최대 90%)	⭐	언제든 중단	배치, ML, 비핵심
Dedicated Host	💰💰💰 비쌈	⭐⭐⭐⭐⭐	물리 서버 단독 사용	라이선스 규정 필요
Dedicated Instance	💰💰💰 비쌈	⭐⭐⭐⭐⭐	물리 하드웨어 격리	규제 환경

 

📊 EC2 구매 옵션 전체 비교 (SAA 시험 핵심)

구매 옵션할인율약정중단 가능사용 상황시험 키워드

온디맨드 (On-Demand)	없음	없음	없음	테스트 / 단기 사용	약정 없음
예약 인스턴스 (Reserved Instances)	최대 ~72%	1년 / 3년	불가	항상 실행되는 서버	Long-term workload
Savings Plans	최대 ~72%	1년 / 3년	불가	유연한 장기 사용	Flexible compute
스팟 인스턴스 (Spot Instances)	최대 ~90%	없음	언제든 종료 가능	Auto Scaling / Batch	가장 저렴
전용 인스턴스 (Dedicated Instances)	없음	없음	없음	규제 / 보안 요구	Single tenant

 

 

📊 Reserved Instances vs Savings Plans (시험 핵심 비교)

항목                                                        Reserved Instances            Savings Plans

 

할인율	최대 72%	최대 72%
약정	1년 / 3년	1년 / 3년
유연성	낮음	높음
인스턴스 변경	제한적	자유로움
서비스	EC2 중심	EC2 / Lambda / Fargate

 

 

✅ 그림으로 이해

가격 (저렴 → 비쌈)

Spot  →  RI/Savings Plan  →  On-Demand  →  Dedicated

안정성 (낮음 → 높음)

Spot  →  On-Demand  →  RI/Savings Plan  →  Dedicated

 

 

AWS 시험 단골 유형 (구매 옵션 공식)

부하 패턴 키워드	추천 구매 옵션 조합
Steady, Predictable (예측 가능, 안정적)	Reserved Instances (RI) / Savings Plans
Spiky, Short-term (급증, 단기)	Spot Instances (비용 절감 시)
New, Unpredictable (예측 불가)	On-Demand (안정성 우선)
Batch, Background Jobs (배치 작업)	Spot Instances
Compliance, Licensing (규정 준수, 라이선스)	Dedicated Host / Instance

 

 

 

 

🔥 시험 핵심 암기표 (진짜 중요)

문제 키워드                                                                      정답

     

항상 실행	RI / Savings Plan
가장 저렴	Spot
중단 가능	Spot
dev/test	On-Demand
라이선스 필요	Dedicated Host
유연한 할인	Savings Plan

 

 

 

 

💎 Savings Plans란?

Savings Plans는 RI와 마찬가지로 1년 또는 3년 약정을 통해 비용을 절감하는 방식이지만, 훨씬 유연합니다.

• RI: "나는 특정 리전의 **특정 인스턴스 타입(예: m5.large)**을 예약할게!" (비교적 깐깐함)
• Savings Plans: "나는 시간당 $10만큼의 컴퓨팅 파워를 무조건 쓸게!" (금액 단위로 약정)

1. 왜 RI보다 좋은가요? (유연성)

Savings Plans 중 가장 인기 있는 Compute Savings Plans를 기준으로 보면 엄청난 장점이 있습니다.

• 인스턴스 패밀리 변경 가능: m5를 쓰다가 더 성능 좋은 m6g로 바꿔도 할인 혜택이 유지됩니다.
• 지역(Region) 무관: 서울 리전에서 쓰다가 도쿄 리전으로 옮겨도 적용됩니다.
• 서비스 간 교차 적용: EC2뿐만 아니라 AWS Lambda, AWS Fargate(컨테이너) 사용량도 이 약정 금액에서 차감됩니다.

---

🔍 RI vs Savings Plans 한눈에 비교

구분	예약 인스턴스 (RI)	Savings Plans (Compute)
약정 방식	특정 리소스 사양 예약	시간당 사용 금액 ($) 약정
유연성	낮음 (패밀리/리전 변경 제한적)	매우 높음 (리전, 인스턴스, OS 무관)
적용 대상	EC2, RDS, ElastiCache 등	EC2, Lambda, Fargate
최근 경향	서비스별 개별 예약 시 사용	전사적 컴퓨팅 비용 절감 시 대세

 

 

 

 

 

 

 

**스팟 인스턴스(Spot Instance)**는 한마디로 **"AWS가 쓰고 남은 빈자리를 아주 싼 값에 빌려 쓰는 땡처리 티켓"**입니다.

AWS는 전 세계에 거대한 데이터 센터를 운영하는데, 모든 서버가 항상 100% 사용되지는 않습니다. 이때 남는 자원을 놀리기 아까우니 최대 90%까지 할인된 가격으로 사용자에게 제공하는 것이 바로 스팟 인스턴스입니다.

---

1. 가장 큰 특징: "언제든 뺏길 수 있다"

가격이 파격적으로 저렴한 대신, 결정적인 조건이 하나 붙습니다.

• 회수 알림: 만약 정가를 내고 쓰겠다는 온디맨드 사용자가 갑자기 늘어나서 남는 자원이 부족해지면, AWS는 스팟 인스턴스 사용자에게 **"2분 뒤에 서버를 회수할게!"**라고 알림을 보낸 뒤 서버를 강제로 종료해버립니다.

---

2. 어떤 상황에 쓰면 좋을까요?

서버가 갑자기 꺼져도 큰 문제가 없는 중단 가능한(Fault-tolerant) 작업에 최적입니다.

• 배치 작업 (Batch Processing): 대량의 데이터를 밤새 분석하는 작업 (중간에 끊겨도 나중에 다시 돌리면 되는 일).
• 이미지/비디오 렌더링: 한 프레임씩 나눠서 작업하므로 끊겨도 리스크가 적음.
• 테스트 환경: 개발자들이 잠깐 성능 테스트를 해볼 때.
• 컨테이너 환경: 쿠버네티스(EKS)처럼 서버 하나가 죽어도 다른 서버가 즉시 업무를 대신 수행할 수 있는 구조.

 

 

 

1. Spot Instance vs Spot Fleet: 뭐가 다른가요?

결론부터 말씀드리면 "스팟 인스턴스는 '단일 상품'이고, 스팟 플릿은 '장바구니 세트'입니다."

• Spot Instance (스팟 인스턴스): 내가 원하는 특정 사양(예: t3.medium)의 남는 서버 한 대를 저렴하게 입찰해서 쓰는 방식입니다.
• Spot Fleet (스팟 플릿): 내가 정한 **예산이나 용량(Target Capacity)**에 맞춰서, 여러 종류의 스팟 인스턴스(예: t3.medium, c5.large, m5.xlarge 등)를 조합해서 한꺼번에 관리해주는 서비스입니다.

💡 시험 포인트: 문제에서 **"비용 효율성"**과 **"확장성"**을 동시에 요구하면, 단순히 인스턴스 하나를 쓰는 것보다 여러 유형을 섞어서 가용성을 높이는 Spot Fleet이나 ASG의 스팟 조합이 정답으로 자주 나옵니다.

 

 

 

---

 

Amazon S3 Object Lock은 데이터를 '한 번 기록하면 절대 수정하거나 삭제할 수 없는(WORM: Write Once, Read Many)' 상태로 만드는 강력한 보안 기능입니다.

주로 금융 기록, 의료 데이터, 법적 증거물처럼 법규상 일정 기간 원본 그대로 보존해야 하는 데이터를 보호할 때 사용합니다.

---

1. 작동 모드 (두 가지 금고 모드)

객체 잠금에는 두 가지 모드가 있는데, "누가 잠금을 풀 수 있는가"의 차이가 핵심입니다.

 

---

2. 주요 개념

• 보존 기간 (Retention Period): 객체가 잠기는 구체적인 기간을 정합니다 (예: 7년). 이 기간이 지나기 전에는 삭제가 불가능합니다.
• 법적 보존 (Legal Hold): 보존 기간과 별개로, 'On'으로 설정하면 기간 제한 없이 무기한 삭제를 방지합니다. 법적 소송 등이 끝날 때까지 데이터를 묶어둬야 할 때 사용하며, 권한이 있다면 언제든 해제할 수 있습니다.

---

3. 필수 조건 (중요!)

S3 Object Lock을 사용하기 위해서는 반드시 다음 두 가지가 충족되어야 합니다.

1. 버전 관리(Versioning) 활성화: 객체의 이전 상태를 추적해야 하므로 필수입니다.
2. 버킷 생성 시 설정: 원칙적으로 버킷을 처음 만들 때 객체 잠금을 활성화해야 합니다. (기존 버킷에 적용하려면 AWS 고객 지원에 문의하거나 복잡한 과정을 거쳐야 합니다.)

---

🔍 시험 문제 필승 공식

• "규제 준수(Regulatory Compliance)" 단어가 나왔다? → Object Lock (Compliance Mode)
• "관리자는 지울 수 있어야 한다" → Object Lock (Governance Mode)
• "기간 상관없이 소송 끝날 때까지" → Legal Hold

---

💡 요약하자면

"데이터에 물리적인 자물쇠를 채우는 것과 같습니다. 특히 '규정 준수 모드'는 열쇠를 아예 바다에 던져버리는 것과 같아서, AWS조차도 정해진 기간 전에는 데이터를 지워줄 수 없습니다."

---

S3 요청자 지불(Requester Pays) 기능은 앞서 다룬 데이터 공유 시나리오에서 가장 경제적인 솔루션 중 하나입니다. 이 기능을 활성화하면, 데이터 전송 및 요청에 대한 비용 책임을 버킷 소유자에서 **데이터를 요청하는 사람(요청자)**에게로 넘길 수 있습니다.

---

1. 비용 부담의 변화

일반적인 S3 버킷과 요청자 지불 버킷의 비용 구조는 다음과 같이 달라집니다.

 

---

2. 작동 방식 및 필수 조건

이 기능을 사용하려면 몇 가지 기술적인 약속이 필요합니다.

1. 버킷 설정: 버킷 소유자가 S3 콘솔이나 API를 통해 Requester Pays 옵션을 활성화해야 합니다.
2. 요청자의 명시적 동의: 데이터를 가져가는 사람은 자신이 비용을 낸다는 것을 알고 있어야 합니다. 따라서 요청 시 헤더에 x-amz-request-payer: requester를 반드시 포함해야 합니다. (이 헤더가 없으면 요청이 거부됩니다.)
3. 익명 접근 불가: 누가 돈을 낼지 식별해야 하므로, 익명(Anonymous) 요청은 허용되지 않습니다. 요청자는 반드시 AWS 자격 증명을 가지고 있어야 합니다.

---

3. 언제 사용하면 좋을까요?

• 대규모 공공 데이터셋 공유: 수 테라바이트의 데이터를 불특정 다수에게 공개할 때, 전송 비용 폭탄을 피하기 위해 사용합니다.
• 비즈니스 파트너 간 데이터 전달: 아까 문제처럼 미국 본사가 데이터를 제공하고, 유럽 지사가 이를 가져갈 때 배송비(전송료)를 가져가는 쪽이 부담하게 할 때 유용합니다.

---

4. 주의사항 (시험 포인트)

• 저장 비용은 여전히 주인 몫: 아무리 요청자 지불을 켜도, 데이터를 버킷에 보관하고 있는 스토리지 비용은 여전히 버킷 소유자가 냅니다.
• 리전 간 전송: 요청자가 자신의 리전(예: 유럽)으로 데이터를 가져가면, 해당 리전 간 전송 단가에 맞춰 요청자에게 비용이 청구됩니다.

---

💡 요약하자면

**"데이터라는 상품은 무료로 줄 수 있지만, 택배비(전송료)와 포장 수고비(API 요청료)는 착불(요청자 지불)로 처리하는 방식"**입니다.

---

S3 **버킷 정책(Bucket Policy)**은 S3 버킷 수준에서 설정하는 리소스 기반 정책입니다. "누가(Principal) 이 버킷에 어떤 작업(Action)을 할 수 있는지"를 JSON 형식으로 정의하여 버킷 자체에 붙여두는 '출입 통제 리스트'라고 이해하면 쉽습니다.

---

🏗️ 버킷 정책의 4가지 핵심 요소

JSON 코드를 볼 때 이 4가지만 기억하면 됩니다.

1. Principal (누가): 권한을 부여받을 대상 (특정 IAM 사용자, AWS 계정, 혹은 전체 공개 등).
2. Action (무엇을): 허용하거나 거부할 작업 (예: s3:GetObject, s3:PutObject).
3. Resource (어디에): 정책이 적용될 대상 (버킷 자체 또는 버킷 안의 객체들).
4. Effect (허용/거부): Allow 또는 Deny.

---

🔒 버킷 정책이 꼭 필요한 3가지 상황

1. 교차 계정 액세스 (Cross-Account Access)

다른 AWS 계정의 사용자에게 내 버킷 접근 권한을 주고 싶을 때 사용합니다. IAM 사용자는 자기 계정의 리소스만 제어할 수 있지만, 버킷 정책은 **"다른 집 사람(다른 계정)"**에게 문을 열어줄 수 있습니다.

2. 특정 조건 제한 (Condition) - 보안의 핵심

단순히 "허용"만 하는 게 아니라, 매우 까다로운 조건을 걸 수 있습니다.

• IP 제한: "우리 회사 사무실 IP(aws:SourceIp)에서 오는 요청만 허용해!"
• VPC 엔드포인트 제한: "인터넷 말고 우리가 만든 '비밀 통로(aws:sourceVpce)로 들어오는 요청만 허용해!"
• 암호화 강제: "데이터를 올릴 때 반드시 암호화(s3:x-amz-server-side-encryption)를 해야만 받아줄 거야!"

3. 퍼블릭 액세스 제공 (Public Access)

웹사이트 정적 호스팅처럼 전 세계 누구나 파일을 볼 수 있게 만들 때 사용합니다. (하지만 기밀 문서 버킷에서는 절대 피해야 할 설정이죠!)

 

 

 

 

---

🔍 시험 필살 포인트: AWS 스토리지 선택 가이드

서비스	주 사용 환경	프로토콜	특징
Amazon EFS	Linux 전용	NFS	서버리스, 자동 확장
Amazon FSx for Windows	Windows 전용	SMB	AD 통합, NTFS 권한 유지
Amazon S3	정적 파일, 백업	HTTP/API	객체 기반, 무제한 용량
Amazon EBS	단일 EC2용 디스크	블록 스토리지	인스턴스에 부착되는 하드디스크

 

 

AWS 시험 단골 유형 (멀티 프로토콜 공유 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"Linux(NFS)와 Windows(SMB) 동시 공유"	Amazon FSx for NetApp ONTAP
"Windows 전용 고성능 공유", "AD 통합"	Amazon FSx for Windows File Server
"Linux 전용 무제한 확장 공유", "NFS"	Amazon EFS
"대규모 병렬 처리", "HPC", "빠른 연산"	Amazon FSx for Lustre

 

 

 

🔍 시험 필살 포인트: FSx의 4가지 형제들

AWS 시험에서 FSx는 뒤에 붙는 이름에 따라 용도가 확실히 갈립니다.

서비스 이름	주용도 (Key Word)	호환 환경
FSx for Windows	Active Directory, SMB, NTFS	Windows
FSx for Lustre	고성능 컴퓨팅(HPC), 머신러닝, S3 연동	Linux (Lustre)
FSx for NetApp ONTAP	온프레미스 NetApp 스토리지 마이그레이션	혼합 환경
FSx for OpenZFS	리눅스 ZFS 파일 시스템 마이그레이션	Linux

 

Amazon FSx for NetApp ONTAP: 넷앱의 ONTAP 기술을 AWS에서 관리형으로 제공하는 서비스입니다. 리눅스와 윈도우가 섞여 있는 환경에서 데이터를 공유할 때 가장 먼저 떠올려야 할 정답 후보입니다.

 

 

 

 

AWS SAA 스토리지 서비스 정리

서비스                                                            스토리지 유형               연결 대상                  프로토콜             주요 사용 사례

                 

Amazon Elastic Block Store	Block Storage	EC2 1대	없음 (Block)	EC2 디스크, 데이터베이스
Amazon Elastic File System	File Storage	여러 EC2	NFS	Linux 파일 공유
Amazon S3	Object Storage	인터넷 / 서비스	HTTP	백업, 데이터 저장, 정적 웹
Amazon FSx for Windows File Server	File Storage	Windows 서버	SMB	Windows 파일 공유
Amazon FSx for NetApp ONTAP	File Storage	Linux + Windows	NFS + SMB	혼합 환경 파일 공유

 

 

주요 특징 비교

특징                                 EBS                         EFS                     S3                        FSx Windows                 FSx ONTAP

        

스토리지 종류	Block	File	Object	File	File
EC2 여러대 공유	❌	✔	✔	✔	✔
Linux 지원	✔	✔	✔	❌	✔
Windows 지원	✔	❌	✔	✔	✔
프로토콜	Block	NFS	HTTP	SMB	NFS + SMB
대표 사용	EC2 디스크	Linux 공유	데이터 저장	Windows 공유	Linux + Windows

---

✅ KMS vs Secrets Manager vs Parameter Store killer 비교

서비스                                                                                        목적                           자동 회전      암호화 연산     시험 키워드

 

AWS Key Management Service	암호화 키 관리	일부	✅	암호화 / 복호화
AWS Secrets Manager	비밀 저장	✅	❌	DB 비밀번호 / 인증서
AWS Systems Manager Parameter Store	설정 값 저장	❌ (기본)	❌	config / 환경변수

 

 

 

---

 

NAT Gateway란 "Network Address Translation Gateway"의 약자로, 주로 클라우드 환경(AWS, Azure, GCP 등)이나 대규모 네트워크에서 사용되는 네트워크 장치 또는 서비스입니다. NAT Gateway의 주요 목적과 기능은 다음과 같습니다:

1. 네트워크 주소 변환 (NAT, Network Address Translation)

• 내부(Private) 네트워크의 IP 주소를 외부(Public) 네트워크의 IP 주소로 변환해줍니다.
• 프라이빗 서브넷의 인스턴스가 인터넷에 연결될 수 있게 해주는 관리형 서비스입니다.
• 내부 서버들이 인터넷에 직접 노출되는 것을 막아 보안을 강화할 수 있습니다.
• NAT 게이트웨이는 내부(프라이빗)에서 외부(인터넷)로 나가는 트래픽은 허용하지만, 외부에서 내부로 직접 들어오는 연결은 거부합니다. 따라서 보안 업데이트 다운로드에 최적입니다.
• NAT 게이트웨이는 AWS에서 관리하는 서비스로, 사용자가 직접 패치를 하거나 성능을 관리할 필요가 없어 NAT 인스턴스보다 운영 오버헤드가 적습니다.

2. 주요 사용 목적

• 보안 강화: 사설 네트워크(예: VPC의 Private Subnet)에 있는 리소스가 인터넷에 직접 노출되지 않으면서, 외부로 트래픽을 보낼 수 있습니다.
• 공용 IP 절약: 여러 내부 서버가 하나의 Public IP로 외부와 통신할 수 있습니다.

 

 

 

 

---

🔍 시험 필살 포인트: "최고의 가용성" 조합

AWS 아키텍처 문제에서 고가용성을 묻는다면 아래 공식이 거의 항상 정답입니다.

1. 컴퓨팅: Auto Scaling 그룹 + 다중 AZ 배포
2. 데이터베이스: Amazon RDS + Multi-AZ 활성화
3. 메시징: Amazon MQ (Active/Standby) 또는 Amazon SQS(자체적으로 고가용성임)

 

 

 

 

---

 

 

Amazon MQ는 클라우드에서 메시지 브로커를 아주 쉽게 설정하고 운영할 수 있게 해주는 관리형 메시지 브로커 서비스입니다.

조금 더 쉽게 설명하자면, 서로 다른 프로그램들이 대화를 나눌 때 사용하는 **'클라우드 우체국'**이라고 생각하시면 됩니다.

---

1. 왜 Amazon MQ를 사용할까요?

가장 큰 이유는 "호환성" 때문입니다.

• 기존 방식 그대로: 많은 기업들이 이미 'ActiveMQ'나 'RabbitMQ' 같은 오픈소스 메시지 브로커를 사용해 시스템을 구축해 두었습니다.
• 코드 수정 최소화: AWS로 이사할 때, 기존에 쓰던 메시징 연결 방식(API나 프로토콜)을 그대로 유지하고 싶을 때 Amazon MQ를 선택합니다. 만약 AWS 전용인 SQS로 바꾼다면 코드를 많이 고쳐야 하지만, Amazon MQ는 그럴 필요가 거의 없습니다.

---

2. 주요 특징

• 관리형 서비스: 서버 설치, 소프트웨어 업데이트, 장애 복구 등을 AWS가 대신 해줍니다. 여러분은 메시지를 보내고 받는 로직에만 집중하면 됩니다.
• 다양한 언어 지원: Java, Python, Ruby, .NET 등 거의 모든 언어에서 연결할 수 있습니다.
• 표준 프로토콜 지원: JMS, AMQP, STOMP, MQTT, WebSocket 같은 업계 표준 방식을 다 지원합니다.

---

3. 고가용성 구조 (활성/대기 브로커)

앞서 풀었던 문제에서 정답이었던 핵심 구조입니다.

• Active(활성): 평소에 모든 메시지를 처리하는 메인 서버입니다.
• Standby(대기): 다른 가용 영역(AZ)에서 조용히 복제 데이터를 받으며 대기합니다.
• 장애 발생 시: 메인 서버가 죽으면, AWS가 자동으로 대기 중이던 서버를 메인으로 승격시킵니다. 사용자는 서버가 바뀐지도 모르게 서비스가 유지됩니다.

---

4. SQS(Amazon Simple Queue Service)와의 차이점

"둘 다 메시지 주고받는 거 아냐?"라고 생각하실 수 있는데, 선택 기준이 명확합니다.

 

---

💡 요약하자면

"Amazon MQ는 예전부터 쓰던 우체국 방식(ActiveMQ 등)을 그대로 유지하면서, 우체국 건물 관리만 AWS에 맡기고 싶을 때 사용하는 서비스입니다."

 

 

 

 

 

 

 

Amazon MQ는 클라우드에서 메시지 브로커를 간편하게 설정하고 운영할 수 있게 해주는 AWS 관리형 메시지 브로커 서비스입니다.

RabbitMQ나 ActiveMQ처럼 기존에 널리 쓰이던 오픈소스 메시지 브로커를 사용자가 직접 서버(EC2)에 설치하지 않고, AWS가 대신 관리해주는 형태입니다.

---

1. 왜 EC2에 직접 설치하지 않고 Amazon MQ를 쓰나요?

구분	EC2에 직접 설치 (Self-Managed)	Amazon MQ (Managed)
설치 및 구성	OS 선택, 런타임 설치, 브로커 설정 직접 수행	클릭 몇 번으로 브로커 생성 완료
고가용성(HA)	복제, 장애 감지, 페일오버 수동 구성	Multi-AZ 배포 옵션으로 자동 구성
패치 및 업데이트	운영 체제 및 소프트웨어 패치 직접 수행	AWS가 자동으로 보안 패치 및 업데이트
호환성	모든 설정 가능	기존 코드 변경 없이 프로토콜 호환 유지

---

2. RabbitMQ 모드의 특징

Amazon MQ는 ActiveMQ와 RabbitMQ 두 가지 엔진을 지원합니다. 그중 RabbitMQ 모드는 다음과 같은 특징이 있습니다.

• 표준 프로토콜 지원: AMQP 0-9-1을 지원하므로, 기존에 사용하던 라이브러리나 코드를 거의 수정하지 않고 그대로 쓸 수 있습니다.
• 고가용성 쿼리: 여러 가용 영역(AZ)에 걸쳐 데이터가 복제되는 **복제 노드(Quorum Queues)**를 사용하여 서버 한 대가 죽어도 메시지 유실 없이 서비스를 유지합니다.
• 모니터링 통합: CloudWatch와 연동되어 메시지 개수, 메모리 사용량 등을 쉽게 감시할 수 있습니다.

---

3. SQS(Simple Queue Service)와 무엇이 다른가요?

SAA 시험에서 가장 헷갈리는 부분입니다. 둘 다 "메시지 대기열"이지만 용도가 다릅니다.

• Amazon SQS: AWS 전용 기술입니다. 확장성이 무제한에 가깝고 관리가 더 쉽지만, 기존 RabbitMQ 코드를 그대로 쓸 수는 없습니다. (새로운 앱 개발에 유리)
• Amazon MQ: 기존에 쓰던 오픈소스 브로커(RabbitMQ 등)가 있고, 코드를 바꾸지 않고 클라우드로 옮기고 싶을 때(Re-platforming) 사용합니다.

 

 

 

---

**Amazon ECS(Elastic Container Service)**는 AWS에서 제공하는 컨테이너 오케스트레이션 서비스입니다. 쉽게 말해, 수많은 컨테이너(도커 이미지)들을 어느 서버에 배치할지, 몇 개를 실행할지, 고장 나면 어떻게 살릴지를 관리하는 '지휘자' 역할을 합니다.

ECS는 컨테이너를 실행하는 방식(데이터 센터의 '바닥'을 무엇으로 쓸 것인가)에 따라 크게 두 가지 종류로 나뉩니다.

---

1. Amazon ECS의 실행 모델 (Launch Types)

① AWS Fargate (서버리스 방식)

• 설명: 서버를 관리할 필요가 없는 서버리스(Serverless) 모델입니다.
• 특징: * EC2 인스턴스를 생성하거나 관리(패치, OS 업데이트 등)하지 않습니다.
  • 컨테이너에 필요한 CPU와 메모리 양만 설정하면 AWS가 알아서 인프라를 할당합니다.
  • 장점: 운영 오버헤드가 가장 적고, 사용한 만큼만 비용을 지불합니다.
  • 용도: 인프라 관리에 신경 쓰고 싶지 않을 때, 트래픽 변화가 심할 때 최적입니다.

② Amazon EC2 (서버 관리 방식)

• 설명: 사용자가 관리하는 EC2 인스턴스 클러스터 위에서 컨테이너를 실행합니다.
• 특징: * 서버의 종류(CPU, RAM, 디스크 등)를 사용자가 직접 선택합니다.
  • 서버의 OS 패치나 보안 설정을 직접 관리해야 합니다.
  • 장점: 인프라에 대한 세밀한 제어가 가능하며, 대규모로 일정하게 사용할 경우 비용이 더 저렴할 수 있습니다.
  • 용도: 특수한 하드웨어 설정이 필요하거나, 기존 EC2 환경을 그대로 활용해야 할 때 씁니다.

---

2. ECS의 주요 구성 요소

ECS를 이해하기 위해서는 아래 4가지 개념을 아는 것이 중요합니다.

• 작업 정의 (Task Definition): 컨테이너의 '설계도'입니다. 어떤 이미지를 쓸지, 메모리는 얼마나 쓸지, 포트는 무엇인지 적어놓은 JSON 파일입니다.
• 작업 (Task): 설계도(Task Definition)대로 실제로 실행된 '컨테이너 인스턴스'입니다.
• 서비스 (Service): 작업(Task)들을 관리하는 '관리자'입니다. 예를 들어 "항상 3개의 작업을 유지해!"라고 명령하면, 하나가 죽었을 때 서비스가 자동으로 새 작업을 하나 더 띄웁니다.
• 클러스터 (Cluster): 작업들이 실행되는 '논리적인 그룹'입니다. Fargate나 EC2 자원들이 이 안에 묶여 있습니다.

---

3. 왜 ECS를 쓰는가? (장점)

1. AWS 서비스와 찰떡궁합: IAM(권한), VPC(네트워크), Load Balancer(트래픽 분산) 등과 완벽하게 통합됩니다.
2. 보안: 컨테이너마다 각각 세밀한 IAM 권한을 부여할 수 있어 보안이 강력합니다.
3. 성능: 수천 개의 컨테이너로 빠르게 확장할 수 있어 대규모 서비스에 유리합니다.

---

💡 요약하자면

"컨테이너를 돌리고 싶은데, 서버 관리가 귀찮으면 Fargate를 선택하고, 내 마음대로 서버를 튜닝하고 싶으면 EC2 방식을 선택하면 됩니다."

 

 

 

---

AWS ParallelCluster는 이름 그대로 **'병렬(Parallel) 컴퓨팅 클러스터'**를 AWS에서 아주 쉽게 만들고 관리할 수 있게 도와주는 오픈소스 클러스터 관리 도구입니다.

쉽게 비유하자면, 일반적인 웹 서버가 '식당'이라면, ParallelCluster는 엄청나게 복잡하고 거대한 계산을 한꺼번에 처리하는 **'슈퍼컴퓨터 연구소'**를 짓는 도구라고 보시면 됩니다.

---

1. 주요 특징 및 개념

• HPC (High Performance Computing): 기상 예측, 자동차 충돌 테스트 시뮬레이션, 신약 개발을 위한 유전자 분석처럼 컴퓨터 한 대로는 수만 년이 걸릴 계산을 수천 대의 컴퓨터에 나눠서 동시에 처리합니다.
• 자동화된 인프라 구축: 텍스트 설정 파일 하나만 있으면, AWS의 다양한 자원(EC2, 스토리지, 네트워크)을 한 번에 조립하여 슈퍼컴퓨터 환경을 완성해 줍니다.
• 유연한 확장성: 계산할 양이 많아지면 서버를 수천 대로 늘렸다가, 계산이 끝나면 자동으로 서버를 다 꺼버려서 비용을 아껴줍니다.

---

2. 구성 요소

1. Head Node (지휘관): 사용자가 접속해서 코드를 짜고 계산 명령을 내리는 서버입니다. 전체 클러스터를 관리합니다.
2. Compute Nodes (일꾼): 실제로 계산을 수행하는 서버들입니다. 평소에는 없다가 일이 생기면 Auto Scaling을 통해 우다다 생겨납니다.
3. Shared Storage (공유 창고): 모든 일꾼 서버가 동시에 읽고 쓸 수 있는 고성능 저장소(Amazon FSx for Lustre, EFS 등)입니다.
4. Scheduler (스케줄러): Slurm 같은 프로그램을 사용하여 어떤 일꾼에게 어떤 일을 시킬지 순서를 정합니다.

 

 

 

 

---

✅ AWS 데이터 마이그레이션 서비스 전체 정리 (시험 필수)

⭐ 파일 / 객체 이동

• AWS DataSync
  👉 파일 시스템 자동 전송 (NFS / SMB)
  AWS DataSync는 파일 시스템(NFS, SMB)이나 S3 간의 파일 이동을 위한 서비스입니다. 데이터베이스 내부의 데이터 동기화와 스키마 변환에는 적합하지 않습니다.

 

 

 

• AWS Transfer Family
  👉 SFTP / FTP 서버 마이그레이션

---

⭐ 대용량 오프라인 이동

• AWS Snowball
  👉 대용량 오프라인 전송
• AWS Snowcone
  👉 소형 Snowball
• AWS Snowmobile
  👉 엑사바이트급 트럭 (시험에 거의 안나옴)

---

⭐ DB 마이그레이션

• AWS Database Migration Service
  👉 DB 복제 + 최소 다운타임

---

⭐ 데이터 변환 / ETL

• AWS Glue
  👉 서버리스 ETL

---

⭐ 애플리케이션 전체 이동

• AWS Application Migration Service
  👉 Lift & Shift

 

 

 

 

---

✅ DataSync vs Snowball 차이 (시험 핵심)

구분AWS                             DataSync                                                           AWS Snowball

전송 방식	네트워크 기반	물리 디바이스 배송
사용 조건	네트워크 대역폭 충분	대역폭 부족 / 오프라인 필요
데이터 크기	중~대용량 (수 TB~수십 TB)	대용량 (수십 TB~PB)
속도	네트워크 속도 의존	물리 배송 → 빠름
증분 동기화	지원 (자동)	기본적으로 1회 마이그레이션
운영 오버헤드	매우 낮음 (관리형)	디바이스 주문·복사 필요
시험 키워드	자동 동기화, NFS/SMB, 지속 전송	대역폭 없음, 오프라인, 물리 이동

 

 

 

---

✅ 1️⃣ Lambda vs ECS vs EC2 그림 비교

 

 

요청 발생
   │
   ▼
선택 기준
   │
   ├── 짧은 이벤트 처리 → Lambda
   │
   ├── 컨테이너 애플리케이션 → ECS / Fargate
   │
   └── OS 직접 제어 필요 → EC2

 

 

 

⭐ 특징

서비스                                                  특징                                                                     언제 사용

  

AWS Lambda	서버리스, 이벤트 기반	API, 이벤트 처리
Amazon ECS	컨테이너 관리	마이크로서비스
Amazon EC2	서버 직접 관리	레거시, OS 제어
AWS Fargate	서버리스 컨테이너	운영 최소화

👉 시험 핵심
⭐ Lambda = 이벤트
⭐ ECS = 컨테이너
⭐ EC2 = 서버 직접 관리

 

 

 

 

 

 

---

 

✅ 2️⃣ Lambda 시험 필수 아키텍처 7개

---

⭐ ① API 서버 패턴

 

 

Client
│
▼
API Gateway
│
▼
Lambda
│
▼
DynamoDB / RDS

 

사용 서비스

• Amazon API Gateway
• Amazon DynamoDB

👉 REST API 서버 대체

---

⭐ ② 파일 처리 패턴

 

 

파일 업로드
│
▼
S3 이벤트
│
▼
Lambda
│
▼
이미지 리사이즈 / 분석

 

사용 서비스

• Amazon S3

👉 시험 매우 자주 출제

---

⭐ ③ 메시지 소비 패턴

 

 

Producer
│
▼
SQS
│
▼
Lambda
│
▼
DB 저장

 

사용 서비스

• Amazon SQS

👉 비동기 처리

---

⭐ ④ 이벤트 스케줄 패턴

 

 

EventBridge 스케줄
│
▼
Lambda 실행
│
▼
배치 작업

 

사용 서비스

• Amazon EventBridge

👉 cron 작업 대체

---

⭐ ⑤ 스트림 처리 패턴

 

 

DynamoDB Streams
│
▼
Lambda
│
▼
실시간 처리

 

👉 데이터 변경 이벤트 처리

---

⭐ ⑥ 워크플로우 패턴

 

 

Step Functions
│
▼
Lambda1 → Lambda2 → Lambda3

 

사용 서비스

• AWS Step Functions

👉 복잡한 비즈니스 흐름

---

⭐ ⑦ 팬아웃 이벤트 패턴

 

 

SNS 이벤트
│
├── Lambda
├── SQS
└── 이메일

 

👉 이벤트 기반 마이크로서비스

 

 

 

 

---

⭐ 서버리스 3대장 조합

• Lambda → 컴퓨팅
• S3 → 파일 저장
• DynamoDB → 메타데이터

 

 

⭐ 문제 푸는 핵심 포인트

문제에 이런 말 나오면

✅ 트래픽 변동 심함
✅ 동시 사용자 증가
✅ 운영 최소화
✅ 자동 확장 필요

👉 Lambda + S3 조합 거의 정답

 

 

 

---

 

• CloudWatch Logs 구독 필터: 로그 그룹의 데이터를 다른 서비스(Lambda, Kinesis, OpenSearch)로 실시간 스트리밍하는 기능입니다.
• Amazon OpenSearch (ES): 로그 분석 및 시각화(Kibana)에 최적화된 엔진입니다.

 

 

 

 

---

AWS Global Backbone은 전 세계에 퍼져 있는 AWS 데이터 센터들을 연결하는 AWS 전용 초고속 광섬유 네트워크망을 말합니다.

쉽게 말해, 우리가 흔히 쓰는 '공용 인터넷(Public Internet)'이라는 일반 도로가 아니라, AWS가 자기네 데이터끼리만 빠르게 주고받으려고 직접 깔아놓은 **'전용 고속도로'**라고 생각하면 됩니다.

---

1. 주요 특징

• 독립된 네트워크: 공용 인터넷망을 거치지 않고 AWS가 소유·관리하는 전용 선로를 통해 데이터가 이동합니다.
• 초고속 & 저지연: 전 세계의 리전(Region)과 에지 로케이션(Edge Location)이 해저 광케이블 등으로 촘촘하게 연결되어 있어 지연 시간(Latency)이 매우 짧습니다.
• 높은 보안성: 데이터가 공용 인터넷 바다로 나가지 않으므로 해킹이나 가로채기 위험이 현저히 낮습니다.
• 안정성: 트래픽이 몰려 인터넷이 느려지는 상황에서도 AWS 전용망은 일정한 성능을 유지합니다.

---

2. 왜 중요한가? (Global Accelerator와의 관계)

이전에 풀었던 문제에서 Global Accelerator가 성능을 높여준 비결이 바로 이 Backbone 덕분입니다.

• 일반적인 인터넷: 사용자가 미국 서버에 접속하면 수많은 통신사 망을 거치며 이리저리 튕겨 다닙니다 (Hop 발생). 이 과정에서 느려지고 불안정해집니다.
• AWS Backbone 이용 시: 사용자의 요청이 집 근처 에지 로케이션에 도착하자마자 바로 **AWS 전용 고속도로(Backbone)**에 올라탑니다. 그 뒤로는 목적지 리전까지 막힘없이 직진합니다.

 

 

 

 

 

---

"한 번 태어난 RDS는 성격(암호화 여부)을 바꿀 수 없습니다. 사진(스냅샷)을 찍어서 포토샵(암호화 복사)을 한 뒤, 그 사진으로 새 사람(새 인스턴스)을 다시 만드는 것이 유일한 방법입니다

Snapshot Copy: 스냅샷을 복사할 때 암호화되지 않은 것을 암호화된 것으로(또는 그 반대로) 바꿀 수 있는 유일한 기회입니다.

 

 

---

 

• SSL Termination (종료): 데이터가 전송되는 경로 중 특정 지점에서 암호화를 풀고 데이터를 확인하는 과정입니다.
• SSL Offloading (오프로딩): 서버가 해야 할 SSL 처리를 로드 밸런서 같은 앞단 장치에 넘겨 서버 부하를 덜어주는 기술입니다.
• Application Load Balancer (ALB): 7계층(응용 계층)에서 동작하며, SSL 인증서를 장착하여 HTTPS 통신을 처리할 수 있습니다.

 

 

---

 

1. AWS Lambda란?

AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있는 서버리스(Serverless) 컴퓨팅 서비스입니다.

• 이벤트 기반: S3에 파일이 업로드되거나, API Gateway에 요청이 들어오는 등 특정 '사건(Event)'이 발생할 때만 코드가 실행됩니다.
• 실행 시간 제한: 한 번 실행될 때 최대 15분까지만 구동 가능합니다. (배치 작업 문제에서 오답으로 자주 나오는 이유)
• 비용 효율: 코드가 실행되는 시간(밀리초 단위)에 대해서만 비용을 지불하며, 실행되지 않을 때는 비용이 0원입니다.
• Stateless(상태 비저장): 코드가 끝나면 모든 데이터가 사라지므로, 영구 저장이 필요하면 S3나 DynamoDB를 연동해야 합니다.
• 확장성 최대화: Lambda는 요청(S3에 파일 도착)이 발생할 때마다 독립적으로 실행되므로, 수천 번의 실행도 별도의 설정 없이 병렬로 처리할 수 있습니다.
• 이벤트 기반 아키텍처: S3에 파일이 업로드되는 순간 Lambda를 즉시 트리거하는 방식은 "매일 수천 번 실행"되는 비정기적 작업에 가장 효율적입니다.
• 최고의 운영 효율성: Lambda 함수 URL은 별도의 API Gateway나 로드 밸런서 설정 없이, 클릭 몇 번으로 Lambda 함수 전용 HTTPS 엔드포인트를 즉시 생성합니다. 구성 요소가 가장 적으므로 관리가 매우 단순합니다.
• IAM 인증 기본 지원: 함수 URL 설정 시 AuthType을 AWS_IAM으로 지정하기만 하면, 별도의 코드 작성 없이 IAM 권한이 있는 사용자만 호출할 수 있도록 보안을 강화할 수 있습니다.

 

💡 정리: 시험에서 'Lambda'가 정답이 되는 경우

만약 문제가 다음과 같이 바뀌었다면 Lambda가 정답이 될 수 있습니다.

1. "기존 애플리케이션을 **현대화(Modernize)**하고 싶다."
2. "비용을 극단적으로 줄이기 위해 이벤트 기반(Event-driven) 아키텍처로 바꾸고 싶다."
3. "서버 관리 오버헤드를 완전히 없애고 싶다 (단, 코드 수정은 감수함)."

---

 

 

1️⃣ EC2 구매 옵션 선택

상황 (문제 키워드)정답

언제든 중단 가능, 상태 비저장, Batch, 비용 중요	Spot Instances ⭐
장기간 일정하게 사용, 예측 가능	Reserved Instances / Savings Plans
갑자기 필요, 예측 불가 트래픽	On-Demand
특정 AZ 용량 확보 필요 (컴플라이언스)	Dedicated Hosts

 

 

1️⃣ EC2 선택 문제 90% 맞추는 판단 흐름도

          ┌───────────────────────────┐
          │      워크로드 유형 확인     │
          └─────────────┬─────────────┘
                        │
                        ▼
        ┌─────────────────────────────┐
        │ 상태 비저장 + Batch 처리?    │
        └───────┬──────────────┬──────┘
                │              │
               Yes            No
                │              │
                ▼              ▼
        ┌─────────────┐   ┌───────────────┐
        │ Spot        │   │ 장기/예측 가능?│
        │ (저비용)    │   └──────┬────────┘
        └─────────────┘          │
                                 ▼
                       ┌───────────────┐
                       │ Reserved/Save │
                       │ Plan          │
                       └───────────────┘

 

 

 

 

---

Amazon EC2 Auto Scaling Group (ASG)

 

• "특정 수치 유지" (Target Value) 문구가 나오면? -> Target Tracking (대상 추적)
• **"시간이나 요일"**에 따라 확장해야 하면? -> Scheduled Scaling (예약된 조정)
• "트래픽이 갑자기 튈 때(Step)" 더 빠르게 대응하려면? -> Step Scaling (단계별 조정)
• **"가장 저렴한 비용"**으로 확장하고 싶다면? -> Spot Instances 조합

 

 

---

🔐 OAI (Origin Access Identity)란?

CloudFront 전용 IAM Principal

즉:

• CloudFront만 S3에 접근 가능
• S3는 Public 차단
• 직접 URL 접근 불가

 

OAI (Origin Access Identity)

항목	설명
목적	S3 버킷을 비공개로 유지하면서 CloudFront만 접근 허용
작동 방식	특수 IAM 엔티티(OAI)를 생성 -> CloudFront에 부여 -> S3 버킷 정책에서 해당 OAI 허용
보안 이점	데이터 유출 방지, 트래픽을 CDN으로 강제하여 비용 및 성능 최적화

 

 

 

 

 

---

 

AWS PrivateLink

특징	설명
비공개성	트래픽이 공인 인터넷을 절대 통과하지 않고 AWS 내부망만 사용합니다.
보안성	IP 주소가 겹치는 VPC 간에도 연결이 가능하며, 특정 포트/서비스만 노출합니다.
구성 방식	서비스 공급자는 VPC Endpoint Service를 만들고, 소비자는 Interface VPC Endpoint를 생성하여 연결합니다.

 

 

 

 

---

 

AWS 시험 단골 유형 (Private Connection)

네트워크 연결 문제에서 다음 키워드 조합을 기억하세요:

1. "전체 VPC 간 연결" + "IP 대역이 겹치지 않음": -> VPC Peering
2. "특정 서비스만" + "IP가 겹쳐도 상관없음" + "최고 보안": -> AWS PrivateLink
3. "온프레미스(사무실)와 비공개 연결": -> Site-to-Site VPN 또는 Direct Connect
4. "S3나 DynamoDB에 비공개 접근": -> Gateway VPC Endpoint

 

 

---

**AWS Database Migration Service (AWS DMS)**는 이름 그대로 데이터베이스를 AWS로 안전하고 신속하게 마이그레이션할 수 있도록 돕는 클라우드 서비스입니다.

단순히 데이터를 한 번 옮기고 끝나는 것이 아니라, 마이그레이션 중에도 원본 데이터베이스가 중단되지 않고 계속 운영될 수 있도록 실시간 동기화를 지원하는 것이 가장 큰 특징입니다.

---

1. AWS DMS의 핵심 기능

• 최소 가동 중지 시간 (Zero Downtime): 데이터를 옮기는 동안에도 서비스는 계속 돌아갑니다. 원본 DB의 변경 사항을 실시간으로 감지하여 타겟 DB에 반영합니다.
• 지속적 복제 (CDC, Change Data Capture): 초기 데이터 복사가 완료된 후에도 소스와 타겟 사이의 동기화를 유지합니다.
• 동종 및 이종 마이그레이션: * 동종: Oracle → Oracle, PostgreSQL → PostgreSQL 등 동일 엔진 간 이동.
  • 이종: Oracle → Aurora, SQL Server → MySQL 등 서로 다른 엔진 간 이동 (이때 AWS SCT 도구가 필요함).

---

2. DMS의 작동 원리 (구성 요소)

DMS가 작동하려면 크게 세 가지 요소가 필요합니다.

1. 복제 인스턴스 (Replication Instance): 데이터를 읽고 전달하는 엔진 역할을 하는 일종의 서버입니다.
2. 엔드포인트 (Endpoints): 데이터의 출발지(Source)와 목적지(Target)에 대한 연결 정보입니다.
3. 복제 작업 (Replication Task): 어떤 데이터를 어떻게 옮길지 정의하는 설정 파일입니다.

 

 

마이그레이션 시나리오별 도구 조합

상황	사용하는 도구
엔진이 같을 때 (예: PG → Aurora PG)	AWS DMS 하나로 충분함
엔진이 다를 때 (예: Oracle → Aurora)	AWS SCT (스키마 변환) + AWS DMS (데이터 이동)
대용량 데이터(TB/PB급) 이동	AWS Snowball Edge + AWS DMS

 

 

 

 

[ 소스 DB (온프레미스) ]          [ AWS DMS 복제 서버 ]          [ 타겟 DB (AWS) ]
       (Source)                      (Engine)                     (Target)
          |                             |                            |
          |------- 1. 데이터 추출 ------>|                            |
          |                             |------- 2. 데이터 전송 ------>|
          |                             |                            |
          |--- 3. 변경분 실시간 복제 --->|------- 4. 실시간 반영 ------>|
          |            (CDC)            |                            |

 

 

시험 문제에서 다음과 같은 표현이 나오면 무조건 DMS를 떠올리세요.

• "Minimal Downtime" (가동 중지 시간 최소화)
• "Ongoing Replication" (지속적인 복제)
• "Source and Target remain in sync" (소스와 대상의 동기화 유지)

 

 

---

 

 

Amazon SageMaker Pipelines는 머신러닝(ML)의 모든 과정을 하나의 자동화된 워크플로우로 연결해주는 서비스입니다.

쉽게 말해, 데이터 준비부터 모델 학습, 검증, 배포까지의 복잡한 단계를 **"공장의 컨베이어 벨트"**처럼 만드는 도구라고 생각하시면 됩니다.

---

1. 왜 SageMaker Pipelines를 쓰나요?

머신러닝은 한 번 코드를 돌리고 끝나는 게 아니라, 새로운 데이터가 들어올 때마다 똑같은 과정을 반복해야 합니다.

• 수동 작업의 문제: 데이터 전처리 → 학습 → 모델 등록 과정을 매번 사람이 직접 하면 실수가 생기고 시간이 오래 걸립니다.
• Pipelines의 해결책: 이 과정을 DAG(Directed Acyclic Graph) 형태의 워크플로우로 정의하여, 데이터가 S3에 들어오는 등의 이벤트가 발생하면 자동으로 전체 공정이 실행되게 합니다.

 

 

 

---

구분상태 없는 (Stateless)상태 있는 (Stateful)비유자판기단골 식당 (이모님 저 왔어요)특징누가 눌러도 똑같은 결과. 과거의 기억이 없음.내 취향, 과거 주문 내역을 기억함.데이터 저장서버 내부에 저장 안 함 (DB나 캐시에 저장).서버 내부(메모리나 디스크)에 데이터 저장.확장성매우 높음. 똑같은 서버 100대 늘려도 무관.어려움. 데이터가 들어있는 특정 서버를 찾아가야 함.예시웹 서버, 이미지 변환 서버.데이터베이스(DB), 게임 서버(실시간 위치 등).

 

 

 

 

 

---

AWS 시험 단골 유형 (이벤트 처리 및 결함 허용 공식)

상황 및 요구사항	추천 서비스 조합 (정답 공식)
비동기 실패 시 데이터 보존	Lambda Destination (On-failure) → SQS
메시지 유실 방지 및 재처리	Dead Letter Queue (DLQ)
컴포넌트 간의 결합도 완화(Decoupling)	Amazon SQS 추가
순서 보장이 필요한 메시징	SQS FIFO Queue
팬아웃(한 알림을 여러 곳에 전달)	Amazon SNS + SQS Fan-out

 

 

 

---

 

• CloudWatch Metric Alarm: 단일 지표(예: CPU)가 임계값을 넘으면 상태가 변경됨.
• CloudWatch Composite Alarm: 여러 Metric Alarm의 상태를 조합함. (예: ALARM(CPU_High) AND ALARM(IOPS_High))
• 장점: 알람 피로도(Alarm Fatigue)를 줄이고, 정말 중요한 시스템 장애 상황에만 집중할 수 있게 함.

 

 

AWS 시험 단골 유형 (CloudWatch 전략 공식)

상황 및 요구사항	추천 서비스/기능 (정답 공식)
여러 조건이 동시에 만족될 때만 알람	복합 경보 (Composite Alarm)
지표의 과거 패턴을 분석해 이상 감지	이상 탐지 (Anomaly Detection)
애플리케이션 로그에서 특정 단어 추출	지표 필터 (Metric Filter)
사용자 경험(URL 응답) 모니터링	CloudWatch Synthetics (Canaries)
서버 내부의 메모리/디스크 상세 수집	CloudWatch Agent 설치

 

 

 

 

---

자동화된 거버넌스 (AWS Control Tower): Control Tower는 Organizations를 기반으로 구축된 서비스로, **가드레일(Guardrails)**이라는 사전 정의된 정책 묶음을 제공합니다. 이를 통해 클릭 몇 번으로 특정 리전 사용 제한 및 인터넷 액세스 차단 설정을 전사적으로 적용할 수 있습니다.

 

 

 

AWS 시험 단골 유형 (거버넌스/제한 공식)

요구사항 키워드	추천 서비스/기능 (정답 공식)
조직 전체 리전/서비스 사용 제한	AWS Organizations + SCP
중앙 집중식 다중 계정 관리 및 설정	AWS Control Tower
정책 위반 사항 실시간 감지 및 기록	AWS Config
인터넷 연결 차단 (인프라 수준)	인터넷 게이트웨이(IGW) 미생성
계정 보안 표준 준수 여부 점검	AWS Security Hub

 

 

 

---

AWS 시험 단골 유형 (스케줄링 자동화 공식)

요구사항 키워드	추천 서비스 조합 (정답 공식)
특정 시간마다 작업 수행 (Cron)	EventBridge + Lambda
인스턴스 비용 절감 (사용 안 할 때)	Instance Stop/Start 자동화
서버 관리 없는 자동화 로직	AWS Lambda
복잡한 워크플로 제어 (A 후 B 실행)	AWS Step Functions

 

 

 

---

AWS 시험 단골 유형 (S3 보안 및 규정 준수 공식)

요구사항 키워드	추천 서비스/기능 (정답 공식)
관리자 포함 절대 삭제/수정 금지	S3 Object Lock (Compliance Mode)
특정 권한자만 삭제 허용(유연한 보호)	S3 Object Lock (Governance Mode)
실수 방지를 위한 삭제 시 인증 요구	MFA Delete
객체의 모든 변경 이력 보존	S3 Versioning
법적 조사 기간 동안 무기한 보호	Legal Hold

 

 

 

 

---

Apache Parquet (파케이)

"한마디로: 분석용 압축 저장 형식"

• 의미: 데이터를 저장할 때 '행(Row)' 단위가 아닌 '열(Column)' 단위로 저장하는 방식입니다. (빅데이터 분석의 표준 포맷)
• 왜 쓰는가? (시험 정답 포인트):
  1. 비용 절감: 열 단위로 압축률이 매우 좋아 저장 용량을 대폭 줄여줍니다.
  2. 속도 향상: Athena로 쿼리를 날릴 때, 전체 데이터를 읽지 않고 필요한 열(Column)만 쏙쏙 골라서 읽기 때문에 속도가 압도적으로 빠릅니다.
• 비유: 1,000페이지 책에서 '주인공 이름'만 찾고 싶을 때, 책 전체를 다 읽는 게 아니라 **'이름 전용 색인'**만 보고 바로 찾아내는 것과 같습니다.

 

 

---

배치 데이터 (Batch Data)

"한마디로: 몰아서 처리하는 데이터"

• 의미: 실시간으로 하나씩 처리하는 게 아니라, 일정 기간 동안 데이터를 모아두었다가 한꺼번에(일괄) 처리하는 데이터입니다.
• 특징:
  • 주기성: 매일 밤 12시, 혹은 매주 일요일처럼 정해진 시간에 작동합니다.
  • 대용량: 대량의 데이터를 한 번에 처리하므로 처리 효율이 좋습니다.
• 반대 개념: 라이브 스트림 데이터(Live Stream - 발생하는 즉시 처리).
• 비유: 편지가 올 때마다 우체통으로 달려가는 게 아니라, 하루 동안 온 편지를 저녁에 한꺼번에 꺼내 보는 것과 같습니다.

 

---

 

 

청사진 (Blueprints)

"한마디로: 자동 설치 가이드"

• 의미: AWS Lake Formation에서 제공하는 기능으로, 데이터 레이크를 구축할 때 필요한 복잡한 과정을 미리 짜여진 틀에 맞춰 자동으로 설정해주는 **'설계도 기반 자동화 도구'**입니다.
• 역할: 데이터 소스(예: MySQL DB)에서 데이터를 어떻게 가져올지, S3 어디에 저장할지, 데이터 형식을 어떻게 바꿀지 일일이 설정할 필요 없이, 청사진을 선택하면 관련 워크플로(Glue 작업 등)를 한꺼번에 만들어줍니다.
• 비유: 가구를 조립할 때 부품 하나하나 깎는 게 아니라, **'이케아 조립 설명서'**를 보고 그대로 따라 하면 완성되는 것과 같습니다.

 

 

---

 

 

AWS Lake Formation은 데이터 레이크를 빠르게 설정해주는 거버넌스 서비스입니다. AWS Glue는 서버리스 ETL 서비스로, 데이터를 크롤링하고 분석에 최적화된 Parquet 형식으로 변환하여 S3에 저장하는 데 가장 적절하며 운영 부담이 적습니다.

 

 

1. AWS Glue (일꾼: 데이터 정리 및 분류)

데이터를 분석하기 좋게 청소하고 분류하는 역할을 합니다.

• 역할: 다양한 소스(S3, DB 등)에서 데이터를 가져와서 변환(ETL)하고, 어떤 데이터가 어디에 있는지 목록을 만듭니다(Data Catalog).
• 핵심 기능: * Crawler: S3에 쌓인 파일을 쓱 훑어서 "이건 이름, 이건 나이네?"라고 표 구조를 자동으로 파악합니다.
  • ETL Job: 지저분한 CSV 파일을 깨끗하고 빠른 Parquet 파일로 변환합니다.

2. AWS Lake Formation (보안관: 중앙 통제 및 보안)

데이터 레이크를 쉽게 구축하고 누가 볼지 결정하는 관리자입니다.

• 역할: Glue, S3, Athena를 한데 묶어 관리합니다. 특히 **"보안"**이 핵심입니다.
• 핵심 기능:
  • 중앙 집중 권한: 원래는 S3 파일마다 권한을 줘야 했지만, 여기서는 "A 팀은 이 테이블의 '전화번호' 열만 빼고 봐!"라고 아주 세밀하게(Column-level) 정할 수 있습니다.
  • Blueprints: 클릭 몇 번으로 데이터 수집 절차를 자동 생성합니다.
  • 중앙 집중식 관리: AWS Lake Formation은 여러 소스(S3, RDS 등)의 데이터를 모아 데이터 레이크를 쉽게 구축하고 관리하게 해주는 서비스입니다.
  • 세분화된 권한 (Granular Permissions): 이 서비스의 가장 큰 장점입니다. 보통 S3는 파일 단위로 권한을 주지만, Lake Formation은 데이터베이스의 테이블, 심지어 특정 열(Column)이나 행(Row) 단위로 누가 볼 수 있는지 설정할 수 있습니다.
• 역할: 데이터 레이크 구축 과정을 자동화하고, 보안을 중앙에서 관리합니다.
• 핵심 기능:
  • 데이터 수집: Glue를 통해 RDS, S3 등에서 데이터를 가져옴.
  • 보안 관리: IAM보다 더 세밀한 데이터 셀 단위(Row/Column Level) 권한 제어 제공.
  • 검색: 데이터 카탈로그를 생성하여 어떤 데이터가 어디 있는지 한눈에 파악.

 

 

3. Amazon Athena (탐사선: 즉석 SQL 쿼리)

S3에 저장된 데이터를 DB처럼 SQL로 조회하는 도구입니다.

• 역할: 서버를 띄울 필요 없이(Serverless), S3에 있는 파일에 대고 바로 SELECT * FROM ... 같은 명령어를 날려 결과를 확인합니다.
• 특징: 사용한 만큼만 돈을 냅니다(스캔한 데이터 양 기준).

 

 

AWS 시험 단골 유형 (데이터 분석 공식)

요구사항 키워드	추천 서비스 조합 (정답 공식)
S3 데이터에 대한 일회성(Ad-hoc) SQL 쿼리	Amazon Athena
데이터 레이크 빠른 구축 및 권한 관리	AWS Lake Formation
서버리스 ETL, 스키마 감지, 카탈로그	AWS Glue
비용 효율적인 분석용 데이터 포맷	Apache Parquet (Columnar)
시각화, 대시보드, KPI	Amazon QuickSight

 

🔟 시험에서 자주 나오는 데이터 분석 서비스 구분

서비스용도

Amazon Athena	S3 SQL 분석
AWS Glue	ETL / Data Catalog
AWS Lake Formation	Data Lake 관리
Amazon Redshift	Data Warehouse

 

4️⃣ 데이터 문제 90% 푸는 결정 트리

아래 순서대로 판단하면 거의 맞음 👇

---

STEP 1: 데이터 어디에 저장?

• 대용량 객체 저장 → S3
• 구조화 DW → Redshift
• 파일 공유 → EFS
• 초고속 임시 → Instance Store

---

STEP 2: 분석 방식?

• S3 직접 SQL → Athena
• 상시 BI + 복잡 분석 → Redshift
• 실시간 스트림 분석 → Kinesis Data Analytics

---

STEP 3: ETL 필요?

• 대규모 변환 → Glue
• 간단 이벤트 처리 → Lambda

---

STEP 4: 운영 최소화 요구?

• 서버리스 조합 선택
  • S3 + Glue + Athena + QuickSight

 

 

데이터 수집
   │
   ▼
S3 (Raw)
   │
   ▼
Glue ETL
   │
   ▼
S3 (Processed, Parquet)
   │
   ▼
Athena (SQL)
   │
   ▼
QuickSight (Dashboard)

 

 

 

 

---

 

• AWS Backup: RDS, Aurora, EBS, EFS 등 다양한 AWS 서비스의 백업을 중앙에서 자동화하고, 수년 단위의 장기 보관 정책을 관리할 수 있는 서비스입니다.
• CloudWatch Logs 내보내기: RDS/Aurora 엔진 로그(에러 로그, 감사 로그 등)를 실시간으로 CloudWatch로 전송하는 기능입니다. 이를 통해 DB가 삭제되어도 로그는 남길 수 있습니다.
• Aurora 자동 백업 vs 스냅샷: 자동 백업은 포인트 인 타임 복구(PITR)용(최대 35일)이며, 장기 보관은 스냅샷이나 AWS Backup을 이용해야 합니다.

 

 

 

---

🏗️ 완전체 아키텍처 그림

        🌍 Internet Users / Botnet
                     ↓
        ┌────────────────────────┐
        │     CloudFront         │
        │  (Global Edge CDN)     │
        └────────────────────────┘
                     ↓
        ┌────────────────────────┐
        │        AWS WAF         │
        │ - Rate-based rule      │
        │ - IP blacklist         │
        │ - Bot control          │
        └────────────────────────┘
                     ↓
        ┌────────────────────────┐
        │     API Gateway        │
        │ - API Key              │
        │ - Usage Plan           │
        │ - Throttling           │
        └────────────────────────┘
                     ↓
        ┌────────────────────────┐
        │        Lambda          │
        └────────────────────────┘

 

 

 

 

🔐 보안 계층 분석 (시험 핵심)

1️⃣ CloudFront

• 엣지에서 캐싱 → Lambda 호출 감소
• AWS Shield Standard 기본 제공
• Origin 숨김
• "정적 콘텐츠 캐싱", "웹 보안(WAF) 연동", **"비용 절감"**이 강조된다면 CloudFront를 먼저 고려하세요.
• 네트워크 경로 최적화 기능을 제공합니다.
• 사용자의 요청이 가장 가까운 **에지 로케이션(Edge Location)**에 도착하자마자 AWS 전용 고속 네트워크망을 타고 리전으로 이동합니다.
• 데이터가 캐싱되지 않는 "동적 요청"이라 할지라도, 공용 인터넷보다 훨씬 빠르게 서버에 도달하고 응답을 받아올 수 있습니다. 이를 Amazon CloudFront Dynamic Content Delivery
• "Accept-Language" 헤더에 따른 동적 캐싱

---

2️⃣ WAF

• IP 차단
• Rate-based rule (예: 5분 동안 1000회 이상 요청 시 차단)
• Geo 차단
• Managed rule

👉 시험에서 “봇넷” 나오면 거의 WAF

---

3️⃣ API Gateway

• Usage Plan
• API Key
• Throttle
• Quota

👉 비용 통제 핵심

---

4️⃣ Lambda

최종 비즈니스 로직만 처리
(보안은 여기서 하면 늦음 ❌)

 

 

---

AWS 시험 단골 유형 (AI/ML 서비스 구분)

AWS 시험에서는 비슷한 이름의 AI 서비스를 섞어놓고 용도에 맞게 고르는 문제가 반드시 나옵니다. 아래 표를 암기하세요!

서비스명	핵심 키워드 (이 단어 보이면 정답)
Amazon Transcribe	음성(Audio) → 텍스트, 화자 인식, 콜센터 기록
Amazon Polly	텍스트 → 음성(Speech), 읽어주기 서비스
Amazon Rekognition	사진/비디오, 얼굴 인식, 부적절한 콘텐츠 탐지
Amazon Textract	문서/PDF/스캔본에서 데이터 추출 (OCR)
Amazon Comprehend	텍스트의 의도/감정 분석, 키워드 추출
Amazon Athena	S3에 있는 파일을 SQL로 바로 검색

 

 

 

 

---

Amazon Redshift는 AWS에서 제공하는 완전 관리형, 페타바이트(PB)급 데이터 웨어하우스(Data Warehouse) 서비스입니다.

쉽게 말해, 기업이 가진 방대한 양의 데이터를 한곳에 모아두고, 복잡한 비즈니스 분석(BI)이나 대규모 통계 쿼리를 아주 빠른 속도로 처리하는 데 특화된 "대형 데이터 전용 분석 엔진"입니다.

---

1. Redshift의 핵심 특징

• OLAP(Online Analytical Processing) 전용: 우리가 흔히 쓰는 MySQL이나 RDS(OLTP)가 "주문 1건 저장, 회원 정보 수정" 같은 트랜잭션에 강하다면, Redshift는 "최근 3년간 전체 매출 합계" 같은 대규모 집계 분석에 최적화되어 있습니다.
• 열 기반 저장(Columnar Storage): 데이터를 행(Row)이 아닌 열(Column) 단위로 저장합니다. 특정 항목(예: 매출액 열)만 읽어오면 되기 때문에 전체 데이터를 뒤질 필요가 없어 속도가 매우 빠릅니다.
• MPP(Massively Parallel Processing): 여러 대의 노드가 데이터를 나누어 동시에 병렬로 처리합니다. 데이터가 많아질수록 노드를 추가하여 성능을 선형적으로 늘릴 수 있습니다.
• 표준 SQL 지원: 개발자들에게 친숙한 PostgreSQL 기반의 SQL을 사용하여 데이터를 조회할 수 있습니다.

---

2. S3 데이터 레이크와의 관계 (Redshift Spectrum)

Redshift의 강력한 기능 중 하나는 Redshift Spectrum입니다.

• 데이터를 굳이 Redshift로 다 옮기지 않아도, S3에 있는 대량의 파일을 직접 SQL로 쿼리할 수 있습니다.
• 자주 쓰는 중요한 데이터는 Redshift 내부에 두고, 가끔 쓰는 방대한 로그 데이터는 S3에 둔 채로 한 번에 조회할 수 있어 비용과 성능을 모두 잡을 수 있습니다.

---

3. Redshift vs RDS vs Athena (비교)

서비스	용도	특징
Amazon RDS	웹 서비스용 DB (OLTP)	빈번한 읽기/쓰기, 트랜잭션 관리
Amazon Redshift	데이터 분석용 (OLAP)	대규모 데이터 집계, 복잡한 통계
Amazon Athena	S3 전용 일회성 분석	서버리스, 설정 없이 S3 파일 즉시 쿼리

 

 

 

 

 

---

Amazon Pinpoint는 한마디로 **"AWS에서 제공하는 기업용 마케팅 커뮤니케이션 플랫폼"**입니다.

단순히 메시지를 발송하는 기능을 넘어, 누구에게(대상 설정), 언제(시간 설정), 어떤 통로로(SMS, 이메일, 푸시 알림) 메시지를 보낼지 설계하고 그 결과를 분석하는 전 과정을 관리합니다.

---

1. Pinpoint의 4가지 핵심 구성 요소

1. 세그먼트(Segments): 메시지를 받을 대상을 나누는 단계입니다. (예: "지난 30일 동안 앱에 접속하지 않은 서울 거주 사용자")
2. 캠페인(Campaigns): 정해진 시간에 특정 메시지를 보내는 일회성 작업입니다.
3. 여정(Journeys): 사용자의 반응에 따라 다음 행동을 결정하는 자동화 시나리오입니다. (예: "이메일을 열어본 사람에게는 쿠폰 SMS를 보내고, 안 열어본 사람에게는 앱 푸시를 다시 보냄")
4. 분석(Analytics): 얼마나 많은 사람이 메시지를 열었는지, 실제 구매로 이어졌는지 통계를 제공합니다.

---

2. SNS(Simple Notification Service)와 무엇이 다른가요?

AWS 시험에서 가장 헷갈리는 부분입니다. 둘 다 SMS를 보낼 수 있기 때문이죠.

• SNS (알림 중심): 시스템 장애 알림이나 일회성 인증번호 발송에 적합합니다. "누가" 보다는 "메시지를 전달하는 행위" 자체에 집중합니다.
• Pinpoint (마케팅 중심): 고객의 행동을 분석하고 맞춤형 메시지를 보내는 데 최적화되어 있습니다. "특정 타겟에게 전략적으로" 접근할 때 사용합니다.

 

 

AWS 시험 단골 유형 (Pinpoint vs SNS)

이 두 서비스는 모두 SMS와 푸시 알림을 지원하기 때문에 헷갈리기 쉽습니다.

비교 항목	Amazon SNS	Amazon Pinpoint
핵심 목적	시스템 간 메시지 전송 (A2A)	고객 마케팅/참여 (A2P)
타겟팅	주제(Topic) 구독 기반	사용자 세그먼트(성별, 나이 등)
여정 관리	없음	자동화된 시나리오(Journeys)
시험 키워드	알림(Notification), 팬아웃(Fan-out)	마케팅(Marketing), 사용자 참여, 여정

 

 

---

AWS S3 암호화 방식 정리 (SAA 시험용)

암호화 방식                                   키관리 주체 자동 키 회전    운영 부담             특징                             시험 키워드

 

SSE-S3	AWS	❌	⭐ 매우 낮음	AWS가 키 완전 관리	least operational overhead
SSE-KMS (AWS managed)	AWS	❌	낮음	KMS 사용하지만 AWS가 키 관리	KMS encryption
SSE-KMS (Customer managed)	고객	✅ 가능	중간	키 접근제어, 감사 가능	key rotation, audit
SSE-C	고객	❌	⭐ 매우 높음	요청마다 키 제공	customer-provided key
Client-side encryption	고객	고객관리	높음	업로드 전에 암호화	encrypt before upload

---

SAA 시험 핵심 공식

문제 키워드정답

최소 운영 오버헤드	SSE-S3
자동 키 회전	SSE-KMS (Customer managed)
키 접근 제어 / 감사	SSE-KMS
고객 키 제공	SSE-C
업로드 전에 암호화	Client-side encryption

 

 

---

 

 IT/클라우드 서비스 (Amazon Redshift)

• Amazon Redshift는 아마존 웹 서비스(AWS)에서 제공하는 클라우드 기반 데이터 웨어하우스(분석용 데이터베이스) 서비스입니다.
• 대용량 데이터 분석, BI(Business Intelligence) 도구와의 연동 등에 많이 사용됩니다.
• 빠른 쿼리 처리와 확장성을 제공하는 것이 특징입니다.

Amazon Redshift는 한마디로 **"초대형 데이터 전용 고속 계산기"**라고 생각하면 쉽습니다.

일반적인 데이터베이스(RDS)가 하나하나의 주문을 처리하는 데 최적화되어 있다면, Redshift는 수백만, 수억 건의 데이터를 한꺼번에 분석하여 "지난 5년간의 매출 추이"나 "지역별 인기 상품 통계"를 뽑아내는 데 특화된 데이터 웨어하우스(Data Warehouse) 서비스입니다.

---

1. Redshift의 핵심 특징 (왜 빠른가?)

• 열 기반 저장 (Columnar Storage): 일반 DB는 한 줄(행)씩 데이터를 읽지만, Redshift는 열(Column) 단위로 읽습니다. 예를 들어 "매출액" 합계만 구할 때 이름, 주소 같은 불필요한 열은 무시하고 매출액 열만 빠르게 읽어 처리합니다.
• 병렬 처리 (MPP, Massively Parallel Processing): 여러 대의 컴퓨터(노드)가 작업을 분산해서 동시에 처리합니다. 데이터가 많아질수록 서버를 늘리면 처리 속도가 그대로 유지됩니다.
• 압축 (Compression): 데이터를 아주 효율적으로 압축해서 저장하므로 디스크 사용량을 줄이고 읽기 속도를 높입니다.

---

2. 주요 기능: Redshift Spectrum

Redshift의 가장 강력한 기능 중 하나입니다. 데이터를 굳이 Redshift 안으로 다 옮기지 않아도, S3에 저장된 방대한 양의 파일(CSV, JSON, Parquet 등)을 SQL로 즉시 쿼리할 수 있게 해줍니다.

• 자주 쓰는 데이터: Redshift 내부(고성능 디스크)에 저장
• 가끔 쓰는 거대한 데이터: S3에 그대로 두고 Spectrum으로 조회

---

3. 다른 서비스와의 비교 (시험 단골!)

구분	Amazon RDS	Amazon Athena	Amazon Redshift
주 목적	일상적인 서비스 운영 (OLTP)	S3 데이터 간편 조회	대규모 데이터 분석 (OLAP)
데이터 양	기가바이트(GB) ~ 테라바이트(TB)	테라바이트(TB) 급	페타바이트(PB) 급 이상
관리 방식	인스턴스 관리 필요	서버리스 (관리 불필요)	클러스터 관리 (최근 서버리스 모드 추가)
속도	복잡한 분석엔 느림	중간 (쿼리당 과금)	매우 빠름 (분석에 최적화)

 

 

---

📊 AWS 메시징 서비스 비교 (SAA 시험용)

서비스구조용도특징시험 키워드

Amazon SQS	Queue	비동기 작업 처리	메시지 저장 후 소비	decouple, queue
Amazon SNS	Pub/Sub	여러 시스템에 알림	fan-out	broadcast, notification
Amazon EventBridge	Event Bus	이벤트 기반 아키텍처	AWS 서비스 이벤트	event routing
Amazon Kinesis	Stream	실시간 데이터 분석	대량 스트리밍	real-time streaming

 

 

 

---

 

 

1. AWS Transfer Family (AWS 전송 서비스)

AWS Transfer Family는 기존에 쓰던 방식(SFTP, FTPS, FTP) 그대로 파일을 AWS S3나 EFS로 직접 업로드/다운로드할 수 있게 해주는 완전 관리형 서비스입니다.

• 왜 쓰나요? 많은 기업이 이미 SFTP를 통해 데이터를 주고받는 자동화 시스템을 가지고 있습니다. 이 시스템의 코드를 고치지 않고 저장소만 온프레미스 서버에서 AWS S3로 바꾸고 싶을 때 사용합니다.
• 특징: 서버를 직접 운영할 필요가 없는 서버리스(Serverless) 형태이며, 매우 안전하고 확장이 쉽습니다. 하지만 시간당 비용이 발생하므로 단순 개인용보다는 기업용 마이그레이션에 주로 쓰입니다.
• 온프레미스 → AWS (데이터 수집): 공용 인터넷이나 Direct Connect를 통해 온프레미스의 클라이언트가 AWS의 SFTP 엔드포인트에 접속하여 데이터를 업로드할 수 있습니다. (마이그레이션 및 정기 보고 데이터 수집용)
• AWS → AWS (보안 및 편의성): AWS 내부에 있는 직원이나 애플리케이션이 복잡한 API 호출이나 S3 콘솔 대신, 익숙한 SFTP 클라이언트를 통해 S3 버킷에 접근하여 데이터를 공유하거나 관리할 수 있습니다.

 

---

. SFTP (Secure File Transfer Protocol)

SFTP는 인터넷을 통해 **파일을 안전하게 전송하기 위한 표준 약속(프로토콜)**입니다.

• S (Secure): 데이터가 전송될 때 암호화됩니다. 옛날 방식인 FTP는 암호화가 안 되어 위험했지만, SFTP는 보안이 강화된 방식입니다.
• 작동 방식: 보통 22번 포트를 사용하며, ID/비밀번호나 SSH 키를 사용해 인증합니다.
• 실무 활용: 아까 배운 AWS Transfer Family가 바로 이 SFTP 연결을 받아주는 입구(Endpoint) 역할을 합니다.

 

---

S3 배치 작업(S3 Batch Operations)이란 AWS(Amazon Web Services)에서 Amazon S3 버킷에 저장된 대량의 객체(파일)들을 대규모로 한 번에 관리, 수정, 처리할 수 있도록 지원하는 서비스입니다. S3에 수십억 개의 객체가 있을 때, 이를 개별적으로 처리하는 것은 매우 비효율적이기 때문에, S3 배치 작업 기능을 사용하면 대량의 객체에 대해 반복적인 작업을 쉽고 빠르게 수행할 수 있습니다.

 

 

---

S3 Inventory는 Amazon S3 버킷에 저장된 수백만, 수천만 개의 객체들을 관리하기 위해 객체 목록과 그 상태(메타데이터)를 리포트 형태로 생성해 주는 기능입니다.

쉽게 말해, 내 창고(S3)에 있는 물건들(객체)의 목록을 매일 아침 엑셀 파일(CSV/Parquet 등)로 정리해서 보고해 주는 **'재고 조사원'**이라고 생각하시면 됩니다.

---

1. 왜 필요한가요?

S3에 객체가 수천 개 정도라면 콘솔에서 보거나 ls 명령어로 확인할 수 있습니다. 하지만 수백만 개 이상의 객체가 있다면:

• 목록을 조회하는 API(ListObjects) 호출 비용이 많이 발생합니다.
• 조회 속도가 매우 느려집니다.
• 어떤 파일이 암호화 안 됐는지, 어떤 파일이 오래됐는지 일일이 확인하기 어렵습니다.

S3 Inventory는 이 문제를 해결하기 위해 목록 조회를 자동화하고 저렴하게 제공합니다.

 

 

 

 

---

재해 복구 (DR)

 

1️⃣ Backup & Restore (가장 저렴)

특징

• 평소에는 백업만 존재
• 장애 발생 시 복원 후 서비스 시작

RTO / RPO

항목값

RTO	몇 시간
RPO	몇 시간

사용 서비스

• AWS Backup
• Amazon S3
• Amazon RDS snapshot

구조

Primary Region

EC2
 │
RDS
 │
Backup → S3

--------------------------

Disaster 발생

S3 Backup
   │
Restore
   │
New EC2 + RDS

 

시험 키워드

저비용
백업만 존재
복원 허용

 

---

2️⃣ Pilot Light

특징

핵심 DB만 항상 실행

RTO / RPO

항목값

RTO	수십분
RPO	낮음

사용 서비스

• Amazon Aurora replica
• Amazon Route 53

구조

Primary Region

ALB
 │
EC2
 │
Aurora Primary
      │
      │ replication
      ▼

Secondary Region

Aurora Replica
(EC2 없음)

 

Secondary Region

Aurora Replica
(EC2 없음)

 

장애 시

EC2 생성
서비스 시작

 

---

3️⃣ Warm Standby (시험 매우 많음)

특징

전체 시스템이 작게 실행

RTO

항목값

RTO

수분

서비스

• Amazon EC2
• Amazon Aurora
• Amazon Route 53

구조

                Route53
               Failover
              /        \
             ▼          ▼

Primary Region      Secondary Region
─────────────       ─────────────

ALB                  ALB
 │                    │
EC2 AutoScaling      Small EC2
 │                    │
Aurora Primary ───► Aurora Replica

 

 

 

 

 

평소

Primary만 사용

 

장애

Secondary Scale Up

 

---

4️⃣ Active-Active (가장 빠름)

특징

두 리전 모두 트래픽 처리

RTO

항목값

RTO

거의 0

서비스

• Amazon Route 53 latency routing
• Amazon DynamoDB Global Tables

구조

           Route53
      Latency Routing
        /        \
       ▼          ▼

Region A       Region B

ALB            ALB
 │              │
EC2            EC2
 │              │
Aurora        Aurora

 

---

5️⃣ Queue Decoupling (SAA 매우 자주 나옴)

특징

서비스 간 데이터 손실 방지

서비스

• Amazon SQS

구조

 

Users
 │
 ▼
API / EC2
 │
 ▼
SQS Queue
 │
 ▼
Worker EC2

장점

Scale 문제 해결
데이터 손실 방지

 

---

6️⃣ Multi-Region Database Replication

특징

DB 복제

서비스

• Amazon Aurora Global Database
• Amazon DynamoDB Global Tables

구조

Primary Region

Aurora Primary
      │
      │ Global Replication
      ▼

Secondary Region

Aurora Global Replica

 

---

⭐ SAA 시험에서 DR 문제 푸는 공식

문제에서 이 키워드만 보면 바로 결정됩니다

키워드정답

저비용	Backup & Restore
핵심 DB만 유지	Pilot Light
30분 RTO	Warm Standby
무중단	Active Active
데이터 손실 방지	SQS
글로벌 DB	Global Database

---

⭐ 유리님이 특히 기억해야 할 것

SAA에서 제일 많이 나오는 DR 조합

Route53 Failover
+ Aurora Replica

 

그리고

SQS
+ AutoScaling

 

 

 

 

 

---

개념 정리: Stateful vs Stateless

• Security Group (Stateful):
  • 요청이 들어오는 것(Inbound)을 허용하면, 그 요청에 대한 응답(Outbound)은 보안 그룹 규칙과 상관없이 자동으로 나갈 수 있습니다.
• Network ACL (Stateless):
  • 들어오는 문과 나가는 문이 완전히 별개입니다. 443으로 손님이 들어왔어도, 나갈 때 사용하는 임시 포트 문을 열어주지 않으면 손님은 갇히게 됩니다.
• 아키텍처 구조 (트래픽 흐름)
  1. 클라이언트 → 서버 (Inbound):
     • NACL: 인바운드 443 허용 (Allow)
     • 보안 그룹: 인바운드 443 허용 (Allow)
  2. 서버 → 클라이언트 (Outbound):
     • 보안 그룹: Stateful하므로 자동 통과.
     • NACL: 아웃바운드 임시 포트(32768-65535) 허용 필요 (E 항목)

 

 

 

 

---

EC2 인스턴스 패밀리 및 모니터링

• M5 (General Purpose): 컴퓨팅, 메모리, 네트워크 리소스가 균형 잡힌 범용 인스턴스.
• R5 (Memory Optimized): 메모리 내 데이터를 처리하는 워크로드를 위해 설계된 인스턴스 (인 메모리 DB, 고성능 분석 등).
• CloudWatch Agent: EC2 인스턴스 내부(OS 레벨)의 지표(메모리 사용량, 디스크 공간 등)와 로그를 수집하기 위해 설치하는 소프트웨어.

 

AWS 시험 단골 유형 (SAA 꿀팁)

• 메모리 지표 관련: "EC2 메모리 사용량을 기본 CloudWatch로 확인한다"는 문구는 무조건 오답입니다. 항상 **CloudWatch 에이전트(또는 커스텀 메트릭)**가 필요합니다.
• 인스턴스 타입 매칭:
  • 인 메모리(In-memory), 고성능 DB → R(RAM) 계열
  • 고성능 컴퓨팅, 머신러닝 학습 → C(Compute) 계열
  • 비디오 렌더링, 그래픽 작업 → G(Graphics/GPU) 계열
  • 범용 웹 서버 → M(Main/General) 계열

 

 

---

상황별 최적의 솔루션 (SAA 시험 대응)

상황 (Scenario)	최적의 솔루션 (Best Practice)	핵심 키워드
제3자(벤더)에게 권한 부여	IAM Role + External ID	Trust Policy, STS:AssumeRole, ExternalID
두 회사 간 리소스 공유	IAM Role을 통한 권한 위임	Cross-account Role
S3 버킷의 데이터를 다른 계정으로 복사	S3 Bucket Policy (리소스 기반)	Bucket Policy, Principal: AWS Account ID
중앙 로깅 계정으로 로그 수집	S3 Bucket Policy 또는 IAM Role	Centralized Logging
조직 전체의 서비스 제어	Service Control Policies (SCPs)	AWS Organizations, Guardrails

 

 

 

 

---

Amazon Route 53 라우팅 정책 비교

라우팅 정책	핵심 목적	사용 사례 (Scenario)
단순 (Simple)	단일 리소스에 연결	특정 도메인에 IP 하나를 연결하는 일반적인 경우
가중치 (Weighted)	트래픽 비율 조정	신규 버전 테스트(Canary), 블루-그린 배포
지연 시간 (Latency)	가장 빠른 응답 제공	전 세계 사용자에게 네트워크 지연이 가장 적은 리전으로 연결
지리적 (Geolocation)	사용자 위치 기준	현지 법률 준수(데이터 규제), 특정 언어 페이지로 안내
지리 근접 (Geoproximity)	리소스 위치 기준 확장	특정 리전의 처리 능력이 높을 때 해당 리전의 범위를 확장(Bias 값 사용)
장애 조치 (Failover)	Active-Passive 구성	메인 서버 장애 시 재해 복구(DR)용 백업 서버로 전환
다중값 응답 (Multivalue)	가용성 및 무작위 분산	DNS 수준의 로드 밸런싱, 상태 확인을 통한 가용 리소스만 응답

 

 

 

---

비용 효율의 끝판왕: Redshift vs Athena

데이터 양이 페타바이트(PB)급일 때, 분석 방식에 따라 비용 차이가 엄청나게 발생합니다.

항목	Amazon Redshift	Amazon Athena
유형	데이터 웨어하우스 (전용 클러스터)	서버리스 대화형 쿼리 서비스
과금 방식	시간당 노드 비용 (사용 안 해도 발생)	스캔한 데이터 용량당 비용 ($5/TB)
데이터 저장	전용 로컬 디스크 (성능 매우 빠름)	S3에 있는 데이터를 그대로 읽음
복잡도	클러스터 관리, 인덱싱 등 튜닝 필요	관리 필요 없음 (쿼리만 던지면 끝)
추천 상황	복잡한 SQL, 빈번한 쿼리, 매우 빠른 성능	가끔 분석, 대규모 데이터 탐색, 저비용

 

 

---

AWS 시험 단골 유형 (DB 확장 및 관리 공식)

상황 키워드	추천 서비스 (정답 공식)
운영 오버헤드 최소화, 가끔 사용하거나 예측 불가능한 부하	Aurora Serverless
표준적인 관계형 DB 관리 서비스가 필요할 때	Amazon RDS (MySQL, PostgreSQL 등)
0.1ms 수준의 극도로 빠른 속도(NoSQL)	Amazon DynamoDB (DAX 포함)
수백 테라바이트 규모의 분석용 데이터 웨어하우스	Amazon Redshift

 

 

 

---

Amazon Aurora Serverless는 데이터베이스의 용량(컴퓨팅 파워)을 직접 관리할 필요 없이, 실제 사용량에 따라 자동으로 확장 및 축소되는 온디맨드 자동 확장 구성입니다.

쉽게 말해, 서버 인스턴스의 크기(t3.medium, r5.large 등)를 정하지 않고, DB가 알아서 "지금 트래픽이 많으니 성능을 높이고, 없으니 낮춰야지"라고 판단하여 작동하는 서비스입니다.

---

1. 주요 특징

• 컴퓨팅 단위 (ACU): 서버 크기 대신 **Aurora Capacity Units (ACU)**라는 단위를 사용합니다. 부하에 따라 최소(예: 0.5 ACU)에서 최대(예: 128 ACU)까지 실시간으로 조절됩니다.
• 자동 시작 및 중단: 데이터베이스에 접속이 아예 없을 때는 컴퓨팅 노드를 **0(중단)**으로 만들 수 있어 비용을 획기적으로 절감할 수 있습니다. 다시 접속 요청이 오면 자동으로 초 단위 내에 살아납니다.
• 서버 관리 불필요: 인스턴스 패치, 용량 산정, 수동 스케일링 작업이 사라져 운영 오버헤드가 매우 낮습니다.
• 분리된 스토리지: 컴퓨팅(CPU/RAM)과 스토리지(데이터 저장소)가 분리되어 있어, 컴퓨팅 사양을 변경해도 데이터에는 영향을 주지 않으며 고가용성을 유지합니다.

---

2. 작동 방식

사용자가 데이터베이스 엔드포인트에 접속하면, Aurora Serverless는 뒤에서 부하를 모니터링하다가 다음과 같이 대응합니다.

1. 트래픽 증가: CPU나 메모리 사용량이 설정치를 넘으면 즉시 더 많은 ACU를 할당합니다.
2. 트래픽 감소: 부하가 낮아지면 비용 최적화를 위해 ACU를 다시 낮춥니다.
3. 애플리케이션 영향 최소화: 용량 변경 시 기존 연결이 끊기지 않도록 "Warm Pool"을 활용하여 매끄럽게 전환합니다.

---

3. Aurora Serverless v1 vs v2

현재는 더 발전된 v2를 주로 사용합니다.

구분	Aurora Serverless v1	Aurora Serverless v2
확장 속도	수십 초 내외 (계단식 확장)	즉각적 (거의 실시간)
확장 단위	용량을 2배씩 늘림 (2, 4, 8...)	미세하게 조절 (0.5 ACU 단위)
기능 지원	기본적인 기능만 지원	Multi-AZ, 읽기 복제본, Global Database 지원
적합한 환경	간헐적이고 예측 불가능한 부하	모든 유형의 워크로드 (운영 환경 포함)

 

 

 

---

AWS 시험 단골 유형 (VPC 연결 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
두 VPC 간의 단순하고 빠른 내부 연결	VPC Peering
수십~백 개 이상의 VPC를 그물망처럼 연결	AWS Transit Gateway
특정 서비스(S3, SQS 등)만 인터넷 없이 연결	VPC Endpoint (Interface/Gateway)
온프레미스와 VPC 간의 전용선 연결	AWS Direct Connect

 

 

 

**VPC 피어링(VPC Peering)**은 서로 다른 두 개의 VPC(Virtual Private Cloud) 간에 트래픽을 라우팅할 수 있도록 지원하는 네트워크 연결 서비스입니다.

쉽게 말해, **"서로 격리된 두 가상 네트워크 사이에 프라이빗한 전용 도로를 뚫는 것"**이라고 이해하면 됩니다.

---

1. VPC 피어링의 핵심 특징

• 프라이빗 통신: 데이터가 공용 인터넷을 거치지 않고 AWS 내부망을 통해 이동합니다. 따라서 보안이 뛰어나고 지연 시간(Latency)이 낮습니다.
• 사설 IP 사용: 두 VPC에 있는 인스턴스들은 마치 같은 네트워크에 있는 것처럼 **사설 IP(Private IP)**를 사용하여 서로 통신할 수 있습니다.
• 리전 및 계정 간 연결: 동일한 리전뿐만 아니라 서로 다른 리전(Inter-Region), 심지어 서로 다른 AWS 계정 간에도 피어링을 맺을 수 있습니다.
• 단일 지점 장애 없음: 별도의 게이트웨이나 물리적 장비가 아닌 AWS 인프라 자체를 활용하므로 대역폭 병목 현상이 발생하지 않습니다.

---

2. 작동 방식 (구성 단계)

VPC 피어링이 성공적으로 작동하려면 아래 3단계가 필요합니다.

1. 피어링 요청 및 승인: 한 VPC가 요청을 보내고, 다른 VPC가 이를 수락해야 합니다.
2. 경로 테이블(Route Table) 업데이트: 각 VPC의 경로 테이블에 상대방 VPC의 IP 대역(CIDR)으로 가는 경로를 추가해야 합니다.
3. 보안 그룹(Security Group) 설정: 상대방 VPC로부터 오는 트래픽을 허용하도록 보안 그룹 규칙을 업데이트해야 합니다.

---

 

 

---

 

 

 

**VPC Flow Logs(VPC 흐름 로그)**는 VPC 네트워크 내에서 송수신되는 모든 IP 트래픽에 대한 정보를 캡처하여 기록하는 기능입니다.

쉽게 말해, **"VPC라는 우리집 네트워크에서 누가, 언제, 어디로, 어떤 포트를 통해 데이터를 보냈는지 기록하는 출입 명부"**라고 이해하시면 됩니다.

---

1. 주요 특징 및 용도

• 트래픽 모니터링: 어떤 IP가 우리 서버에 접속하려고 하는지 실시간으로 파악합니다.
• 네트워크 보안 분석: 특정 포트(예: 22, 3389)로의 비정상적인 접근 시도를 탐지합니다.
• 장애 조치(Troubleshooting): "왜 내 EC2가 통신이 안 되지?"를 확인할 때, 보안 그룹(Security Group)이나 네트워크 ACL에서 트래픽이 **거부(REJECT)**되었는지 확인하는 데 필수적입니다.
• 데이터 보관: 로그 데이터를 Amazon CloudWatch Logs나 Amazon S3에 저장하여 장기간 보관 및 분석할 수 있습니다.

---

2. 로그가 기록하는 핵심 정보

로그 한 줄에는 다음과 같은 중요한 정보들이 포함됩니다.

• 소스/대상 IP 주소: 어디서 보내고 어디서 받는지.
• 소스/대상 포트: 어떤 문(Port)을 사용했는지 (예: HTTP는 80, SSH는 22).
• 프로토콜: TCP, UDP, ICMP 등 어떤 방식으로 통신했는지.
• 패킷 및 바이트 수: 데이터 양이 얼마나 되는지.
• 동작(Action): 보안 규칙에 의해 ACCEPT(허용) 되었는지 REJECT(거부) 되었는지.

 

AWS SAA 시험 단골 유형 (Flow Logs 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"보안 그룹이 트래픽을 허용하는지 거부하는지 확인"	VPC Flow Logs의 Action 필드 확인
"특정 포트 접속 시 운영팀에 알림 전송"	Flow Logs + CloudWatch Metric Filter + SNS
"네트워크 트래픽의 장기 분석 및 SQL 조회"	Flow Logs + Amazon S3 + Amazon Athena
"특정 인스턴스에 도달하는 트래픽만 보고 싶음"	네트워크 인터페이스(ENI) 단위로 Flow Logs 생성

 

 

 

 

 

---

AWS 시험 단골 유형 (계정 보안 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
신규 계정 생성 직후 최우선 보안 조치	루트 MFA 활성화 및 액세스 키 삭제
사용자마다 최소한의 권한만 부여	Least Privilege(최소 권한) 원칙 적용
공통 권한을 가진 여러 사용자 관리	IAM 그룹(Group) 활용
암호 보안 수준 강화 (길이, 특수문자 등)	IAM Password Policy 설정

 

 

---

AWS 시험 단골 유형 (암호화 공식)

요구사항 키워드	추천 서비스 (정답 공식)
S3, EBS, RDS "저장 시(At Rest)" 암호화	AWS KMS
ALB, CloudFront "전송 시(In Transit)" 암호화	AWS ACM (SSL/TLS 인증서)
인증서의 자동 갱신 및 관리	AWS ACM
하드웨어 기반의 강력한 키 저장소(규제 준수)	AWS CloudHSM

 

 

 

 

 

---

 

• AWS SCT (Schema Conversion Tool): 서로 다른 DB 엔진 간의 마이그레이션 시 소스 스키마를 타겟 엔진에 맞게 변환.
• AWS DMS (Database Migration Service): 데이터를 실제로 옮기는 서비스. 가동 중단을 최소화하며 동기화 유지 가능.
• CDC (Change Data Capture): 소스 DB의 트랜잭션 로그를 읽어 실시간으로 변경 사항만 타겟에 반영하는 기술.

 

AWS 시험 단골 유형 (DB 마이그레이션 공식)

상황 키워드	추천 솔루션 (정답 공식)
동종 엔진 마이그레이션 (MySQL ➔ RDS MySQL)	DMS (SCT 필요 없음)
이종 엔진 마이그레이션 (Oracle ➔ Aurora)	DMS + AWS SCT 필수
다운타임(가동 중단) 최소화	DMS의 CDC 기능 활용
대규모 데이터 이동 (테라바이트급 이상)	AWS Snowball Edge + DMS

 

 

 

 

---

 

 

AWS 시험 단골 유형 (비용 관리 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
특정 서비스나 전체 예산 초과 시 알림	AWS Budgets
비용 추세 시각화 및 데이터 분석	AWS Cost Explorer
가장 상세한 시간별 비용 데이터 내보내기	AWS Cost and Usage Reports (CUR)
비용 절감 제안(인스턴스 크기 조정 등) 확인	AWS Trusted Advisor / Cost Explorer

 

 

AWS 시험 단골 유형 (비용 도구 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"비용 시각화", "서비스/태그별 분석 보고서"	AWS Cost Explorer
"가장 상세한 원시 데이터(Raw data) 분석", "SQL 사용"	AWS CUR + Amazon Athena
"특정 금액 초과 시 알림", "예산 통제"	AWS Budgets
"예약 인스턴스(RI) 구매 권장 사항 확인"	AWS Cost Explorer

 

 

---

AWS 시험 단골 유형 (API 노출 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
단일 함수, 가장 간단한 HTTPS 노출	Lambda Function URL
인증, 조절(Throttling), API 버전 관리 필요	Amazon API Gateway
웹 소켓(Websocket) 또는 REST API 대규모 관리	Amazon API Gateway
수천 개의 마이크로서비스를 통합 관리	App Mesh / API Gateway

 

 

AWS Cost Explorer: 과거 12개월간의 비용 데이터를 분석하고 향후 12개월을 예측하는 도구입니다.

 

---

AWS 시험 단골 유형 (DB 가용성 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"리전 내 장애 대비 (고가용성)"	RDS Multi-AZ
"리전 전체 장애 대비 (재해 복구)"	Cross-Region Read Replica
"RTO/RPO를 최소화하는 가장 강력한 글로벌 DB"	Amazon Aurora Global Database
"비용을 아끼며 장기 백업만 필요할 때"	Cross-Region Snapshot Copy

 

 

 

---

AWS 시험 단골 유형 (Route 53 라우팅 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"단순히 하나의 리소스로 연결"	Simple Routing
"상태 확인을 포함한 여러 IP 반환"	Multivalue Answer Routing
"사용자와 가장 가까운 리전 연결"	Latency Routing
"장애 시 대기 중인 서버로 자동 전환(DR)"	Failover Routing (Active-Passive)
"트래픽 비중을 8:2로 나누고 싶음"	Weighted Routing

 

 

 

---

AWS Storage Gateway는 큰 서비스 이름(브랜드 이름)이고, 그 안에 용도에 따라 4가지 종류가 있습니다.

• S3 File Gateway (우리가 푼 문제의 정답): 온프레미스 파일을 Amazon S3의 객체로 저장하고 연결합니다.
• FSx File Gateway: 온프레미스에서 Amazon FSx for Windows File Server에 연결할 때 사용합니다.
• Volume Gateway: 온프레미스 데이터를 iSCSI 기반의 블록 스토리지(디스크) 형태로 클라우드에 백업합니다.
• Tape Gateway: 오래된 물리적 테이프 백업 장치를 클라우드 기반의 가상 테이프로 대체합니다.

 

시험 단골 유형 (스토리지 게이트웨이 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"S3의 파일을 온프레미스에서 NFS/SMB로 액세스"	S3 File Gateway
"온프레미스 서버의 로컬 디스크를 클라우드로 백업"	Volume Gateway
"테이프 백업 장치를 클라우드로 대체"	Tape Gateway
"온프레미스에서 지연 시간 없이 S3 데이터 활용"	S3 File Gateway (로컬 캐시 덕분)

 

 

 

 

 

---

1️⃣ AWS SAA 스토리지 / 하이브리드 서비스 ( AWS+온프레미스, AWS+다른 클라우드 )핵심 7개

서비스핵심 목적

Storage Gateway	온프레미스 ↔ S3 연결
DataSync	데이터 고속 전송
Snowball	오프라인 데이터 이동
FSx	Managed 파일 시스템
EFS	클라우드 NFS
S3 Transfer Acceleration	글로벌 업로드 가속
AWS Backup	백업 관리

---

2️⃣ Storage Gateway (시험 핵심)

온프레미스 ↔ AWS 스토리지 연결

종류 3가지

Gateway용도

File Gateway	파일 → S3
Volume Gateway	Block storage
Tape Gateway	백업

아키텍처

 

On-Prem Server
│
│ NFS / SMB
▼
File Gateway (VM)
│
▼
Amazon S3

 

시험 키워드

On-premise
file application
S3
low latency

 

👉 File Gateway

---

3️⃣ AWS DataSync

 

• 온프레미스와 AWS 간 빠른 파일 전송 서비스
• 기존 NFS 서버와 연동 가능
• 중단 없이 데이터 전송 가능
• 자동 검증, 병렬 전송 → 최소 운영 오버헤드

 

대량 데이터 고속 이동 서비스

예

On-prem → S3
S3 → EFS
EFS → FSx

 

특징

특징설명

자동화	가능
빠른 전송	병렬 처리
스케줄링	가능

아키텍처

 

On-Prem Storage
│
│ DataSync Agent
▼
AWS Storage
(S3 / EFS / FSx)

 

시험 키워드

large data transfer
migration
sync

 

👉 DataSync

---

4️⃣ AWS Snowball

대용량 데이터 물리적 이동

예

100TB
500TB
PB 데이터

 

특징

특징설명

오프라인 전송	인터넷 필요 없음
대용량	매우 빠름

아키텍처

 

Data Center
│
│ Copy Data
▼
Snowball Device
│
│ Shipping
▼
AWS

 

시험 키워드

Petabytes
slow internet
offline transfer

 

👉 Snowball

---

5️⃣ Amazon EFS

클라우드 파일 시스템

특징

특징설명

NFS	지원
Auto scaling	자동
Multi AZ	가능

아키텍처

 

EC2
│
│ NFS
▼
Amazon EFS

 

시험 키워드

shared file system
Linux
multiple EC2

 

---

6️⃣ Amazon FSx

관리형 파일 시스템

종류

FSx 종류용도

 

FSx for Windows	Windows 파일 서버
FSx for Lustre	HPC
FSx for NetApp	기업 스토리지
FSx for OpenZFS	Unix

시험 키워드

Windows file share
SMB

 

👉 FSx for Windows

---

7️⃣ S3 Transfer Acceleration

글로벌 업로드 가속

CloudFront Edge 사용

아키텍처

 

User
│
│ Upload
▼
CloudFront Edge
│
▼
S3 Bucket

 

시험 키워드

global users
faster upload

 

---

8️⃣ AWS Backup

백업 관리 서비스

지원

EBS
RDS
EFS
DynamoDB
FSx

 

특징

Central backup
policy management

 

---

9️⃣ 시험에서 가장 많이 나오는 구분 문제

문제 키워드정답

On-prem file → S3	Storage Gateway File
Data migration	DataSync
PB 데이터 이동	Snowball
Linux 공유 스토리지	EFS
Windows 파일 서버	FSx
글로벌 업로드 가속	Transfer Acceleration
백업 자동화	AWS Backup

---

🔟 SAA 시험 초고속 풀이 공식

이 표 하나면 대부분 풀립니다.

상황서비스

온프레미스 파일 → S3	File Gateway
데이터 마이그레이션	DataSync
인터넷 느림 + PB 데이터	Snowball
EC2 공유 파일	EFS
Windows 파일 서버	FSx
글로벌 업로드 빠르게	Transfer Acceleration

 

 

 

---

AWS 시험 단골 유형 (고가용성 공식)

상황 키워드	추천 솔루션 (정답 공식)
"단일 인스턴스의 SPOF 해결"	ALB + Multi-AZ Auto Scaling Group
"사용자 수요에 따라 자동 확장"	Auto Scaling Group + CloudWatch Alarm
"데이터베이스 관리 부담 완화 및 HA"	Amazon RDS (Multi-AZ) 또는 Amazon Aurora
"서버 장애 시 빠른 복구"	AMI 기반의 인스턴스 자동 교체

 

 

 

---

AWS 시험 단골 유형 (네트워크 트러블슈팅)

상황	해결책 (정답 공식)
인터넷에서 내 서버로 접속이 안 됨	인터넷 게이트웨이(IGW) 확인 & ALB를 퍼블릭 서브넷에 배치
내 서버(프라이빗)가 인터넷에서 업데이트를 못 받음	NAT 게이트웨이(NAT GW)를 퍼블릭 서브넷에 설치
보안 그룹(SG) 설정 문제	ALB 보안 그룹에서 HTTP/HTTPS 허용 & EC2 보안 그룹에서 ALB의 보안 그룹 ID 허용

 

 

 

---

한눈에 비교하는 글로벌 DB 전략

비교 항목	DynamoDB 글로벌 테이블	RDS/Aurora 글로벌 전략
데이터 모델	NoSQL (Key-Value)	관계형 (SQL)
쓰기(Write)	여러 리전에서 가능 (Multi-Master)	보통 1개 리전에서만 가능
주요 목적	전 세계적 초저지연 읽기/쓰기	재해 복구(DR) 및 읽기 성능 확장
복제 기술	서비스 수준 복제	스토리지 또는 DB 로그 수준 복제

 

 

 

---

AWS 시험 단골 유형 (공유 스토리지 선택 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"Linux, NFS 프로토콜, 무제한 확장"	Amazon EFS
"Windows, SMB 프로토콜, AD 통합"	Amazon FSx for Windows
"고성능 컴퓨팅(HPC), 초고속 병렬 처리"	Amazon FSx for Lustre
"온프레미스에서 S3를 네트워크 드라이브처럼"	S3 File Gateway

 

SSD 스토리지: 문제에서 요구하는 6GBps 이상의 높은 처리량과 밀리초 미만의 지연 시간을 달성하려면 속도가 느린 HDD가 아닌 SSD 기반의 영구(Persistent) 스토리지가 필수적입니다.

SSD vs HDD: SSD는 반도체 방식으로 지연 시간이 거의 없으며, HDD는 자기 디스크 회전 방식으로 대용량 저장은 유리하지만 속도는 느립니다.

SSD vs HDD 선택: 성능이 중요하면 SSD, 비용 절감이 중요하면 HDD를 선택해야 합니다. 이 문제처럼 6GBps라는 구체적인 고성능 수치가 나오면 무조건 SSD입니다.

 

 

---

1. CIDR (Classless Inter-Domain Routing) 이란?

쉽게 말해 **"IP 주소의 범위를 지정하는 방식"**입니다. 특정 IP 하나가 아니라, **"여기서부터 여기까지가 내 네트워크 대역이다"**라고 묶어서 표현할 때 사용합니다.

어떻게 읽나요? (슬래시 법칙)

IP 주소 뒤에 /와 숫자가 붙습니다. (예: 10.0.0.0/24)

• 숫자가 작을수록: 포함하는 IP 개수가 많아집니다. (넓은 범위)
• 숫자가 클수록: 포함하는 IP 개수가 적어집니다. (좁은 범위)

시험에 자주 나오는 예시

• 0.0.0.0/0: 모든 IP 주소. 즉, "전 세계 인터넷 전체"를 의미합니다. (가장 넓은 범위)
• 10.0.0.0/16: VPC 전체 대역으로 자주 쓰입니다. (약 65,000개 IP)
• 10.0.1.0/24: 특정 서브넷 대역으로 자주 쓰입니다. (약 250개 IP)
• 192.168.1.50/32: 딱 이 IP 하나만 가리킵니다.

---

 

보안 그룹 규칙 (Security Group Rules) 이란?

EC2 인스턴스 앞에 서 있는 **"가상 방화벽"**입니다. 어떤 트래픽이 서버로 들어올 수 있고(Inbound), 나갈 수 있는지(Outbound)를 결정하는 출입 명단이라고 보시면 됩니다.

핵심 특징 3가지 (시험 필수!)

1. 허용(Allow)만 가능: "이 IP는 막아줘"라는 규칙은 못 만듭니다. 명단에 없으면 기본적으로 차단됩니다.
2. 상태 저장(Stateful): 들어오는 것을 허용했다면, 나가는 규칙이 없어도 나가는 길은 자동으로 열립니다. (매우 중요!)
3. 최소 권한 원칙: 꼭 필요한 포트와 IP만 열어두는 것이 보안의 정석입니다.

규칙의 구성 요소

• 프로토콜/포트: 80(HTTP), 443(HTTPS), 22(SSH) 등
• 소스(Source): 어디서 오는 트래픽인가? (특정 CIDR 혹은 다른 보안 그룹 ID)

 

 

• 동적 확장 대응: IP 주소(CIDR)를 사용하면 서버가 늘어날 때마다 규칙을 수정해야 합니다. 하지만 보안 그룹 ID를 참조하면, 해당 보안 그룹에 속한 인스턴스는 자동으로 권한을 부여받으므로 관리가 매우 유연합니다.
• 정교한 제어: "Web 서브넷의 모든 IP"가 아니라, 오직 "Web 보안 그룹을 가진 인스턴스"만 App 계층에 접속할 수 있게 제한하므로 최소 권한 원칙에 완벽히 부합합니다.
• 보안성: 동일 서브넷 안에 다른 용도의 인스턴스가 있더라도, 보안 그룹 ID가 다르면 접근이 차단됩니다.

 

---

AWS 시험 단골 유형 (보안 그룹 공식)

상황	추천 솔루션 (정답 공식)
"계층 간 통신 제한", "최소 권한"	보안 그룹 ID 참조 (B)
"관리 오버헤드 감소"	보안 그룹 ID 참조 (서버 증설 시 자동 적용)
"외부 인터넷 차단"	프라이빗 서브넷 + 0.0.0.0/0 차단
"상태 저장(Stateful) 방화벽"	Security Group (응답 트래픽 자동 허용)

 

 

 

---

AWS 시험 단골 유형 (S3 보호 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"이전 버전 보관", "실수 삭제 복구"	S3 Versioning (버전 관리)
"영구 삭제 방지", "강력한 보안"	MFA Delete
"특정 기간 삭제 금지", "금융 규정 준수"	S3 Object Lock (WORM 방식)
"다른 지역으로 자동 복사"	CRR (Cross-Region Replication)

 

 

---

Kinesis Agent는 한마디로 **"서버 구석구석을 돌아다니며 로그 파일을 수집해 클라우드로 보내주는 우체부 리눅스 프로그램"**입니다.

---

1. Kinesis Agent의 정체

• 정의: 서버(EC2 또는 온프레미스 서버)에 설치하여 실행하는 자바 기반 소프트웨어 에이전트입니다.
• 역할: 지정된 폴더의 로그 파일(.log)을 실시간으로 감시하다가, 새로운 데이터가 써지면 이를 가로채서 Kinesis Data Streams나 Kinesis Data Firehose로 전송합니다.

---

2. 주요 특징 (시험 단골 포인트)

1. 쉬운 설치: 서버에서 간단한 설치 명령과 JSON 설정 파일만으로 구동됩니다.
2. 신뢰성: 네트워크 장애가 발생해 전송이 끊겨도, 어디까지 보냈는지 기억(Check-pointing)하고 있다가 나중에 이어서 보냅니다.
3. 사전 처리: 데이터를 보내기 전에 간단한 포맷 변환(예: 단일 텍스트를 JSON으로 변환)이나 압축을 수행할 수 있습니다.
4. 리눅스 전용: 기본적으로 Amazon Linux나 RHEL 기반의 시스템에서 작동합니다. (윈도우는 Kinesis용 별도 에이전트가 있음)

 

언제 Kinesis Agent를 정답으로 골라야 하나요? (시험 공식)

요구사항 키워드	추천 솔루션 (정답)
"서버 내부의 특정 로그 파일을 수집해야 함"	Kinesis Agent
"온프레미스(자체 서버)의 데이터를 AWS로 보내야 함"	Kinesis Agent
"데이터 전송 시 체크포인트(이어서 보내기)가 필요함"	Kinesis Agent
"AWS 인프라 이벤트(ASG, EC2 상태 변화) 수집"	EventBridge / CloudWatch

 

 

 

---

 

 

. AD (Active Directory)란?

한마디로 **"회사의 모든 사용자 정보와 자산(컴퓨터, 프린터 등)을 한곳에서 관리하는 거대한 전화번호부이자 출입 통제 센터"**입니다. 마이크로소프트(Microsoft)에서 만든 서비스입니다.

왜 쓸까요? (관리의 편의성)

회사가 커져서 직원이 1,000명이라고 가정해 봅시다.

• AD가 없다면: 직원이 입사할 때마다 1,000명이 사용하는 모든 컴퓨터와 서버에 일일이 계정을 만들어줘야 합니다. 퇴사할 때도 다 지워야 하죠. (노가다!)
• AD가 있다면: AD 서버 한 곳에만 계정을 만들면 됩니다. 직원은 그 계정 하나로 회사의 어떤 컴퓨터든 로그인할 수 있고, 권한이 있는 파일 공유 폴더에 접속할 수 있습니다.

---

2. 핵심 구성 요소 (시험용 키워드)

• 도메인 (Domain): 관리하는 울타리입니다. 보통 company.com 같은 이름을 가집니다.
• 사용자 및 그룹 (Users & Groups): "철수"라는 사용자를 "인사팀"이라는 그룹에 넣어서 한 번에 권한을 줄 수 있습니다.
• 도메인 컨트롤러 (Domain Controller, DC): AD 서비스가 돌아가는 실제 서버입니다. "너 우리 직원 맞니?"라고 물어보고 로그인을 승인해주는 경찰관 역할을 합니다.
• ACL (Access Control List): "인사팀 그룹은 이 폴더를 읽을 수 있다" 같은 권한 명단입니다.

---

3. AWS 시험(SAA)에서의 AD

시험에서는 **"기존 회사(온프레미스)에서 쓰던 AD를 AWS와 어떻게 연결할래?"**라는 관점에서 문제가 나옵니다.

주요 서비스 3가지

1. AWS Managed Microsoft AD: AWS가 직접 관리해주는 진짜 AD입니다. 클라우드에 새로 AD를 만들 때 씁니다.
2. AD Connector: 온프레미스 AD와 AWS 서비스를 이어주는 **"중계기"**입니다. AWS에는 정보를 저장하지 않고, 로그인이 오면 온프레미스 AD에 물어만 봅니다.
3. Simple AD: 기능이 제한된 저가형 AD입니다. (시험에는 잘 안 나옵니다.)

---

4. 실전 적용: 아까 풀었던 FSx 문제와 연결

• 상황: 회사가 company.com이라는 AD를 쓰고 있음.
• 미션: AWS에 있는 **FSx(파일 공유 서버)**를 이 AD에 연결해라.
• 해결: FSx를 AD 도메인에 가입(Join)시킵니다. 그러면 FSx는 이제 company.com의 직원을 알아볼 수 있게 되고, 기존에 설정된 "인사팀 전용 폴더" 권한을 그대로 유지할 수 있습니다.

 

---

 

• CloudFront 캐싱: 글로벌 서비스에서 성능을 높이려면 CloudFront(CDN)가 필수입니다. CloudFront는 헤더 값에 따라 서로 다른 버전의 콘텐츠를 캐시할 수 있으므로, 장치별로 최적화된 파일(이미지 크기 등)을 효율적으로 전달합니다.
• Lambda@Edge 분기: 사용자가 어떤 장치를 쓰는지 알 수 있는 정보는 HTTP 헤더의 **User-Agent**에 담겨 있습니다. Lambda@Edge는 CloudFront의 에지 로케이션에서 실행되는 서버리스 코드로, 요청이 들어올 때 이 헤더를 읽어 "모바일이면 모바일용 경로로, PC면 PC용 경로로" 트래픽을 즉시 리다이렉트하거나 콘텐츠를 변경하여 전송할 수 있습니다.

 

AWS 시험 단골 유형 (콘텐츠 최적화 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"글로벌 고객", "지연 시간 최소화"	Amazon CloudFront
"장치별(User-Agent) 콘텐츠 분기"	Lambda@Edge
"헤더/쿠키 기반 캐싱"	CloudFront Cache Policy
"정적 콘텐츠 저장소"	Amazon S3

 

 

1. CloudFront + Lambda@Edge (사용자 맞춤형 전달)

아까 문제에서 보셨듯이, 전 세계 에지 로케이션(Edge Location)에서 사용자 요청을 가로채서 처리하는 방식입니다.

• 동작 원리: 사용자가 접속하면 가장 가까운 에지 로케이션에서 Lambda@Edge가 실행됩니다.
• 헤더 분석: User-Agent 헤더를 보고 "이 사람은 아이폰이네?", "이 사람은 갤럭시네?"를 판단합니다.
• 콘텐츠 분기: 판단 결과에 따라 아이폰용 고화질 이미지나 안드로이드용 리소스를 골라서 보내줍니다.

---

2. S3 OAC (Origin Access Control) 란?

S3에 웹사이트 콘텐츠를 저장해두고 CloudFront로 뿌릴 때, **"사용자가 S3 주소로 직접 들어오는 것은 막고, 오직 CloudFront를 통해서만 들어오게 하라"**는 요구사항이 시험에 꼭 나옵니다. 이때 정답이 바로 OAC입니다.

왜 OAC를 쓰나요?

1. 보안: S3 버킷을 '퍼블릭(Public)'으로 열어두지 않아도 됩니다. (S3는 꽁꽁 닫아둡니다.)
2. 비용 및 성능: 사용자가 CloudFront 캐시를 거치지 않고 S3에서 바로 다운로드하면 비용이 더 많이 발생할 수 있고 속도도 느립니다.
3. WAF 연동: CloudFront 앞에 AWS WAF(방화벽)를 붙여서 해커의 공격을 막을 수 있는데, 사용자가 S3로 직접 가면 이 방화벽을 우회하게 됩니다. OAC가 이를 방지합니다.

---

3. 3월 시험 필승 암기 공식 (S3 + CloudFront 조합)

시험 문제에 아래 키워드들이 보이면 바로 연결하세요!

요구사항 (키워드)	정답 솔루션
"S3 직접 접근 차단 (Restrict direct access)"	OAC (Origin Access Control)
"국가별/장치별 콘텐츠 차단 또는 분기"	Lambda@Edge 또는 CloudFront Functions
"특정 국가에서만 접속 허용"	CloudFront Geo Restriction
"S3의 정적 콘텐츠를 전 세계에 빠르게"	CloudFront + S3 Origin

 

 

 

 

서비스                                                                    목적                                                Layer.      주요 기능

Amazon CloudFront	콘텐츠 전송	L7	CDN 캐싱
AWS Global Accelerator	네트워크 경로 최적화	L4	Anycast IP
Application Load Balancer	HTTP 라우팅	L7	Host / Path routing

 

 

 

 

 

---

AWS 시험 단골 유형 (VPC 연결 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"두 VPC 연결", "최저 비용", "단순함"	VPC Peering
"수십/수백 개의 VPC 연결", "중앙 집중 관리"	AWS Transit Gateway
"보안 그룹 참조 가능 여부"	VPC Peering (가능), Transit Gateway (최근 가능해짐)
"서로 다른 계정/리전 VPC 연결"	VPC Peering 또는 Transit Gateway

 

 

 

---

이 문제처럼 "가장 안전한(Most Secure)" 혹은 **"베스트 프랙티스"**를 묻는 문제에서 서브넷 배치는 필승 공식이 있습니다.

• 웹 서버/앱 서버/DB: 무조건 Private Subnet에 두는 것이 기본 정답입니다.
• 로드 밸런서(ALB): 외부 사용자의 요청을 받아야 하므로 Public Subnet에 둡니다.
• 보안 그룹(Security Group): "ALB 보안 그룹의 트래픽만 허용하는 EC2 보안 그룹 설정" 같은 내용이 선택지에 있다면 정답 확률이 매우 높습니다.

 

---

 

 

데이터베이스 가속화 전략

서비스	주요 특징	적합한 상황
ElastiCache	인 메모리 캐시 (Redis/Memcached)	반복적인 읽기 쿼리 가속, 세션 관리
RDS Read Replica	읽기 전용 복제본 생성	읽기 요청이 너무 많아 DB 본체의 부하를 나눌 때
DAX	DynamoDB 전용 인 메모리 캐시	DynamoDB의 읽기 성능을 10배 이상 높일 때

 

 

 

 

---

 

RDS 성능 문제에서 다음과 같이 구분하여 정답을 고르세요.

1. "읽기 부하 분산/분석용 쿼리" $\rightarrow$ 읽기 복제본(Read Replica)
2. "밀리초 미만의 빠른 읽기 응답/반복적 조회" $\rightarrow$ ElastiCache
3. "다중 가용 영역(Multi-AZ)" $\rightarrow$ 성능 향상이 아닌 고가용성 및 재해 복구용입니다. (성능 문제 정답으로 고르지 마세요!)

 

---

 

 

1. S3 버킷 정책 (S3 Bucket Policy)

버킷 정책은 **"누가 이 버킷과 객체에 접근할 수 있는가?"**를 정의합니다.

• 주요 역할: 특정 IP 차단, HTTPS 강제(위에서 배운 내용), 특정 IAM 역할에게만 접근 허용 등.
• 시험 포인트: 만약 IAM 사용자에게 권한이 있어도, 버킷 정책에서 Deny를 해버리면 절대 접근할 수 없습니다. (Deny는 항상 Allow보다 우선합니다.)

2. KMS 키 정책 (KMS Key Policy)

KMS는 데이터를 암호화/복호화하는 '열쇠'를 관리합니다. 이 열쇠를 누가 쓸 수 있는지 결정하는 것이 키 정책입니다.

• 기본 원칙: KMS 키는 생성 시 정책을 설정하지 않으면, 루트(Root) 계정 외에는 아무도 쓸 수 없습니다.
• IAM과의 관계: IAM 정책에서 kms:Decrypt 권한을 줬더라도, KMS 키 정책에서 해당 사용자를 허용(Allow)하지 않으면 암호화된 파일을 읽을 수 없습니다. (두 곳 모두에서 허용되어야 합니다.)

---

3. S3 + KMS 결합 시나리오 (복호화 과정)

사용자가 KMS로 암호화된 S3 객체를 다운로드할 때, AWS 내부에서는 다음과 같은 일이 일어납니다.

1. S3 접근 권한 확인: 사용자가 s3:GetObject 권한이 있는지 확인합니다 (IAM 및 버킷 정책).
2. KMS 복호화 권한 확인: S3 객체를 풀기 위해 사용자가 해당 KMS 키에 대해 kms:Decrypt 권한이 있는지 확인합니다 (KMS 키 정책 확인).
3. 최종 승인: 두 권한이 모두 있어야 사용자는 평문 데이터를 볼 수 있습니다.

---

4. 시험에 자주 나오는 '문제 해결' 유형

상황	원인	해결책
S3 읽기 권한은 있는데 "Access Denied"가 뜸	KMS 복호화 권한 부족	사용자의 IAM 정책이나 KMS 키 정책에 kms:Decrypt 추가
다른 계정(Cross-Account)에서 S3 접근 안 됨	키 정책의 신뢰 관계 미설정	KMS 키 정책에서 외부 계정의 ID를 Principal로 허용
관리자가 KMS 키를 제어할 수 없음	키 정책 오류	키 정책에 관리자의 IAM 사용자나 역할을 Key Administrators로 등록

 

 

 

---

S3 보안의 핵심인 **미사용 데이터 암호화(At Rest)**와 **전송 중 데이터 암호화(In Transit)**를 정책으로 강제하는 구체적인 방법과 원리를 정리해 드릴게요.

---

1. 전송 중 암호화 강제 (Encryption in Transit)

데이터가 인터넷을 통해 이동할 때 해커가 중간에서 가로채지 못하도록 HTTPS(SSL/TLS) 연결을 강제하는 설정입니다.

• 메커니즘: S3 버킷 정책에 aws:SecureTransport 조건을 사용합니다.
• 작동 원리: 클라이언트가 http://로 접근하면 aws:SecureTransport 값이 false가 됩니다. 이때 정책에서 이를 거부(Deny)하도록 설정하면 오직 https:// 요청만 허용됩니다.

---

2. 미사용 데이터 암호화 강제 (Encryption at Rest)

데이터가 S3의 물리적 디스크에 저장될 때 암호화된 상태로 기록되도록 보장하는 것입니다.

• 메커니즘 1 (기본 암호화): 버킷 설정에서 Default Encryption을 활성화합니다. 이렇게 하면 사용자가 암호화 옵션을 선택하지 않아도 S3가 알아서 암호화해서 저장합니다.
• 메커니즘 2 (정책 강제): 업로드 요청(PutObject) 헤더에 암호화 옵션(x-amz-server-side-encryption)이 포함되지 않은 경우 요청 자체를 거부(Deny)하도록 설정합니다.

---

3. 실제 적용 예시 (버킷 정책)

시험에서 자주 등장하는 "가장 안전한" 정책 구조는 다음과 같습니다.

JSON

 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::내-버킷-이름/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" } // HTTPS가 아니면 거절
      }
    },
    {
      "Sid": "EnforceEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::내-버킷-이름/*",
      "Condition": {
        "Null": { "s3:x-amz-server-side-encryption": "true" } // 암호화 헤더가 없으면 거절
      }
    }
  ]
}

---

4. SAA 시험 핵심 요약 (이것만 기억하세요!)

구분	전송 중 암호화 (In Transit)	미사용 암호화 (At Rest)
핵심 키워드	HTTPS, TLS, SSL	SSE-S3, SSE-KMS, SSE-C
강제 방법	aws:SecureTransport 조건 사용	Default Encryption 또는 Bucket Policy
시험 포인트	"데이터가 이동 중일 때 보호"	"디스크에 저장될 때 보호"

 

 

 

 

---

 

Auto Scaling 전략 비교

전략 종류	특징	추천 상황
Scheduled Scaling	특정 시간/날짜에 미리 확장	배치 작업, 정기 세일 이벤트
Dynamic Scaling	지표(CPU 등)에 따라 실시간 확장	일반적인 웹 트래픽 대응
Predictive Scaling	과거 데이터를 AI로 분석해 예측 확장	주기적인 패턴이 있는 대규모 트래픽

 

Auto Scaling 정책 비교

• Target Tracking (대상 추적): "평균 CPU를 40%로 유지해줘"라고 설정하면 AWS가 알아서 계산해서 늘리고 줄입니다. 가장 권장되는 방식입니다.
• Scheduled Scaling (예약된 확장): 이벤트나 출근 시간처럼 시간을 미리 알 때 사용합니다.
• Cooldown (휴지 기간): 인스턴스가 추가된 후 시스템이 안정될 때까지 추가 확장을 멈추는 시간입니다. 이 시간이 짧을수록 더 공격적으로(빠르게) 인스턴스를 늘립니다.

 

AWS SAA Auto Scaling 단골 유형 정리

패턴                             문제 키워드                                  정답 스케일링 방식              특징                     사용 서비스

               

CPU 자동 유지	CPU utilization 유지, 자동 성능 유지	Target Tracking Scaling	CPU 목표값 유지	Amazon EC2 Auto Scaling
시간 기반 확장	매일 오전 트래픽, 특정 시간	Scheduled Scaling	시간 기반 자동 확장	Amazon EC2 Auto Scaling
CloudWatch 경보	CPU > 70%, alarm trigger	Step Scaling	단계적 확장	Amazon CloudWatch
트래픽 기반	request count, ALB request	Target Tracking	요청 수 기반 확장	Application Load Balancer
예측 트래픽	historical data, forecast	Predictive Scaling	ML 기반 예측 확장	Amazon EC2 Auto Scaling
인스턴스 시작 느림	startup delay, 빠른 scale out	Warm Pool	미리 준비된 인스턴스	Amazon EC2 Auto Scaling

 

 

---

정말 좋은 질문입니다! 많은 수험생분들이 이 부분에서 헷갈려 하시는데요, "CloudFront = 정적 파일(이미지, JS) 캐싱"이라는 고정관념을 깨는 것이 SAA 시험 합격의 핵심입니다.

왜 동적 웹사이트 문제에서 CloudFront가 정답이 되는지 3가지 핵심 이유로 설명해 드릴게요.

---

1. "가속(Acceleration)"은 캐싱만을 의미하지 않습니다

CloudFront는 단순히 파일을 저장(캐싱)하는 기능 외에 네트워크 경로 최적화 기능을 제공합니다.

• 일반 접속: 사용자의 요청이 복잡한 공용 인터넷망을 거쳐 us-west-1 리전까지 가야 하므로 지연 시간(Latency)이 깁니다.
• CloudFront 사용: 사용자의 요청이 가장 가까운 **에지 로케이션(Edge Location)**에 도착하자마자 AWS 전용 고속 네트워크망을 타고 리전으로 이동합니다.
• 결과: 데이터가 캐싱되지 않는 "동적 요청"이라 할지라도, 공용 인터넷보다 훨씬 빠르게 서버에 도달하고 응답을 받아올 수 있습니다. 이를 Amazon CloudFront Dynamic Content Delivery라고 합니다.

---

2. "Accept-Language" 헤더에 따른 동적 캐싱

문제에서 **"여러 언어를 지원해야 한다"**는 조건이 결정적인 힌트입니다.

• 원래 CloudFront는 URL이 같으면 같은 파일을 줍니다. 하지만 설정을 통해 **"헤더(Header)에 따라 다르게 캐싱해!"**라고 명령할 수 있습니다.
• 예를 들어, www.example.com 요청이 들어왔을 때:
  • Accept-Language: ko 헤더가 있으면 한국어 버전 페이지를 캐싱.
  • Accept-Language: en 헤더가 있으면 영어 버전 페이지를 캐싱.
• 이렇게 하면 **동적인 로직(언어 선택)**이 들어간 페이지도 에지 로케이션에서 캐싱하여 전 세계 사용자에게 빠르게 줄 수 있습니다.

 

 

 

• CloudFront Signed URL: 개별 파일 접근, 쿠키 미지원 클라이언트, RTMP 배포 등에 주로 사용됩니다.
• CloudFront Signed Cookie: 현재 URL 유지 필요 시, 다수의 파일(전체 카테고리 등)에 대한 동시 접근 권한 부여 시 사용됩니다.

CloudFront 콘텐츠 보호 방법

Amazon CloudFront

방법                                                               특징                                                                 사용 상황

 

Signed URL	특정 콘텐츠 보호	파일 다운로드
Signed Cookie	여러 콘텐츠 보호	로그인 사용자
OAI/OAC	S3 직접 접근 차단	기본 보안

 

---

3. 오리진(Origin)의 유연성

CloudFront는 오리진으로 **S3(정적)**와 **ALB/EC2(동적)**를 모두 지원합니다.

• 정적 웹사이트: S3에 index.html 같은 파일을 올려두고 배포.
• 동적 웹사이트: ALB 뒤에 있는 EC2가 실시간으로 HTML을 생성해서 줄 때, 그 앞에 CloudFront를 두어 연결 성능을 최적화하고 자주 바뀌지 않는 동적 결과물은 캐싱까지 수행.

따라서 문제에서 "전 세계 사용자", "지연 시간 감소", **"기존 아키텍처(ALB+EC2) 유지"**라는 키워드가 나오면, 동적 사이트라 할지라도 CloudFront가 가장 강력한 정답 후보가 됩니다.

 

 

---

 

DR (재해 복구) 전략 비교 (RTO 기준)

1. Backup & Restore: 가장 저렴하지만 복구에 수 시간~수일 소요 (가장 높은 RTO).
2. Pilot Light: 핵심 데이터만 복제, 나머지는 꺼둠. 복구에 수십 분 소요.
3. Warm Standby (정답): 최소 사양으로 상시 가동. 복구에 수 분 소요.
4. Multi-Site (Active-Active): 모든 리전 풀 가동. 복구 시간 거의 없음 (0에 수렴)

 

1️⃣ DR 전략 4가지 (시험 핵심 표)

DR                                               전략설명                            RTO                    RPO         비용                 특징

 

Backup & Restore	백업만 저장	매우 느림	높음	가장 저렴	재해 후 복구
Pilot Light	핵심 시스템만 유지	중간	낮음	낮음	DR 시 확장
Warm Standby	축소된 시스템 실행	빠름	매우 낮음	중간	DR 시 scale
Active-Active	모든 리전 활성	매우 빠름	거의 0	가장 비쌈	글로벌 서비스

 

 

2️⃣ DR 전략 구조 그림

① Backup & Restore (가장 저렴)

Primary Region
   │
   │ Backup
   ▼
   S3 Backup Storage

Disaster 발생

S3 Backup
   │
   ▼
New Infrastructure 생성
   │
   ▼
서비스 복구

 

 

 

② Pilot Light

Primary Region
   │
   │ Replication
   ▼
DR Region

Minimal Infrastructure
   │
   ├─ Database
   └─ Storage

Disaster 발생

EC2 / ALB / App 서버 생성

 

 

 

③ Warm Standby ⭐ (시험 매우 중요)

 

Primary Region
Full Production
   │
   │ Replication
   ▼
DR Region
Reduced Environment

ALB
 │
EC2 (Small)
 │
Database Replica

Disaster 발생

Auto Scaling
 → Full capacity

 

 

 

④ Active-Active (가장 빠름)

        Route53
       Latency Routing
         │      │
         ▼      ▼
Primary Region   DR Region
Full Production  Full Production

ALB + EC2 + DB
ALB + EC2 + DB

 

 

 

 

---

기업의 재해 복구(DR) 및 글로벌 서비스를 위한 최강의 무기인 Amazon Aurora Global Database에 대해 완벽하게 정리해 드릴게요.

---

1. Aurora Global Database란?

단일 AWS 리전을 넘어, **전 세계 여러 리전(최대 6개)**에 걸쳐 있는 단일 데이터베이스입니다. 기본 리전(Primary)에서 데이터를 쓰고, 보조 리전(Secondary)들로 데이터를 매우 빠르게 복제합니다.

핵심 수치 (시험에 잘 나옴)

• 복제 지연 시간(Latency): 보통 1초 미만.
• 복구 지연 시간(RTO): 장애 시 보조 리전을 승격시키는 데 1분 미만.
• 성능 영향 없음: 데이터베이스 엔진이 직접 복제를 담당하므로, 애플리케이션의 성능을 깎아먹지 않습니다.

---

2. 작동 원리: 어떻게 그렇게 빠른가요?

일반적인 RDS 복제는 데이터베이스 엔진 수준에서 복제본(Read Replica)을 만드느라 시간이 걸리지만, Aurora Global DB는 **스토리지 계층(Storage Layer)**에서 직접 데이터를 쏴줍니다.

1. Primary 리전: 사용자가 데이터를 씁니다.
2. 전용 인프라: AWS의 전용 고속 네트워크를 통해 보조 리전의 스토리지로 데이터를 전송합니다.
3. Secondary 리전: 데이터가 도착하자마자 읽기 전용으로 사용 가능하며, 필요 시 즉시 쓰기 가능(Primary) 상태로 바꿀 수 있습니다.

---

3. 주요 특징 및 장점

특징	설명	SAA 시험 포인트
고속 복제	리전 간 지연 시간이 1초 미만	낮은 RPO (데이터 손실 최소화)
빠른 승격	보조 리전을 주 리전으로 즉시 전환	낮은 RTO (서비스 중단 최소화)
로컬 읽기	전 세계 사용자가 가까운 리전에서 읽기 가능	글로벌 성능 최적화
쓰기 전달(Write Forwarding)	보조 리전에서 발생한 쓰기 요청을 주 리전으로 전달	애플리케이션 수정 최소화

 

 

 

SAA 시험 단골 함정 피하기!

1. Multi-AZ vs Global DB:
   • Multi-AZ: 한 리전 내의 가용 영역(AZ) 장애 대비 (고가용성).
   • Global DB: 리전 전체의 재해(Disaster) 대비 (재해 복구).
2. 복제 방식:
   • Aurora Global DB는 비동기(Asynchronous) 복제입니다. (아주 빠르긴 하지만 이론상 아주 미세한 데이터 손실 가능성이 있음 -> 그래서 RPO가 0은 아님).
3. 용도 구분:
   • 단순히 "읽기 성능 향상"만 원한다면 일반 Read Replica로 충분할 수 있지만, "최저 RTO/RPO의 DR"이 목표라면 반드시 Global Database여야 합니다.

 

---

 

 

AWS 시험 단골 유형 (SES 공식)

상황	추천 솔루션 (정답 공식)
"사용자에게 마케팅/뉴스레터 이메일 발송"	Amazon SES
"애플리케이션 가입 환영 메일 자동화"	Amazon SES
"수신된 이메일을 분석하거나 S3에 저장"	Amazon SES (Inbound)
"시스템 관리자에게 경고 메시지 전송"	Amazon SNS (이메일 구독)

---

💡 요약하자면

"SES는 이메일 발송 전용 '엔진'입니다. 서버를 직접 관리하는 고통(스팸 처리, 서버 유지) 없이, 코드 한 줄로 전 세계에 이메일을 뿌릴 수 있는 가장 싸고 강력한 도구입니다!"

---

SQL Server 특정 기능 (DQS 등): AWS의 관리형 DB 서비스인 RDS for SQL Server는 많은 기능을 지원하지만, **Data Quality Services(DQS)**와 같은 심층적인 OS 레벨의 기능은 지원하지 않는 경우가 많습니다. 따라서 이러한 특정 기능을 완벽하게 사용하려면 **EC2에 SQL Server를 직접 설치(Self-managed)**해야 합니다.

 

 

 

---

Lambda 함수 자체에 실행 권한을 부여하는 IAM 역할 설정이 선행되어야 하며, 일반적으로 서비스 간 권한 관리는 IAM 역할을 통해 이루어집니다.

 

 

• IAM 역할(Role) 사용: AWS 서비스(Lambda)가 다른 서비스(S3)에 접근할 때는 장기 자격 증명(액세스 키)을 사용하는 대신, 임시 보안 자격 증명을 제공하는 IAM 역할을 사용하는 것이 가장 안전합니다.
• 최소 권한 원칙 (Least Privilege): 특정 버킷에 대해서만 권한을 부여해야 합니다. 모든 버킷에 권한을 주는 것은 보안상 취약점을 만듭니다.
• 내부 리소스 접근: 동일 계정 내의 리소스 접근 시에는 리소스 기반 정책(버킷 정책)보다 자격 증명 기반 정책(IAM 역할)을 Lambda에 부여하는 것이 관리 및 표준화 측면에서 권장됩니다.

 

 

 

📊 AWS SAA IAM / 보안 문제 TOP 8

문제 상황                                                     정답 서비스                           이유                                          시험 키워드

           

Lambda → S3 접근	IAM Role	Access Key 사용 안함	Lambda permission
EC2 → S3 접근	IAM Role	Instance Profile 사용	EC2 access S3
다른 AWS 계정 S3 접근	S3 Bucket Policy	Cross Account Access	Another account
사용자 권한 관리	IAM Policy	사용자 권한 제어	IAM User
임시 권한 필요	IAM Role	Temporary Credentials	STS
애플리케이션 코드에서 AWS 접근	IAM Role	코드에 키 저장 금지	Secure access
특정 IP만 S3 접근	Bucket Policy	조건 기반 접근	Source IP
서비스 간 권한 연결	IAM Role	AWS 서비스 간 인증	Service role

 

 

 

🚀 SAA 시험 핵심 IAM 3가지

시험에서 거의 90% 이 3개입니다

상황정답

AWS 서비스 → AWS 서비스	IAM Role
Cross Account	Resource Policy
사용자 권한	IAM Policy

---

 

**Amazon MSK(Managed Streaming for Apache Kafka)**는 인기 있는 오픈 소스 분산 스트리밍 플랫폼인 Apache Kafka를 AWS에서 쉽게 구축, 운영 및 확장할 수 있게 해주는 완전 관리형 서비스입니다.

---

MSK의 핵심 역할

실시간으로 쏟아지는 방대한 양의 데이터(로그, 클릭 스트림, IoT 센서 데이터 등)를 중간에서 유실 없이 받아내고, 이를 필요한 분석 시스템으로 전달하는 고성능 '데이터 우체국' 역할을 합니다.

---

주요 특징

• 관리의 편의성: 서버 설치, 패치, 고가용성 구성(Multi-AZ) 등을 AWS가 알아서 처리해줍니다.
• 오픈 소스 호환성: 기존에 쓰던 Kafka 도구와 코드를 그대로 가져와서 쓸 수 있습니다.
• 보안 및 통합: AWS IAM을 통한 권한 제어, VPC 내 프라이빗 연결, KMS 암호화 등 AWS 보안 체계와 긴밀하게 연동됩니다.
• 확장성: 데이터 처리량이 늘어나면 클릭 몇 번으로 브로커(Broker)를 추가하거나 스토리지를 확장할 수 있습니다.

---

비교: MSK vs Kinesis Data Streams

두 서비스 모두 실시간 스트리밍을 다루지만 목적에 따라 선택이 달라집니다.

구분	Amazon MSK	Kinesis Data Streams
기반	오픈 소스 (Apache Kafka)	AWS 전용 기술
자유도	설정 및 튜닝 자유도가 매우 높음	관리가 매우 쉬운 서버리스 형태
보유 기간	설정에 따라 장기간 보관 가능	기본 24시간 ~ 최대 365일
추천 상황	기존 Kafka 환경을 옮기거나 세밀한 제어가 필요할 때	빠르고 간단하게 AWS 네이티브 파이프라인을 구축할 때

---

개념 요약 (Concept Summary)

• MSK는 복잡한 Kafka 서버 관리를 AWS에 맡기고, 사용자는 데이터 비즈니스 로직에만 집중하게 해주는 서비스입니다.

 

 

---

 

 

S3 Object Lambda: 데이터의 복사본을 여러 개 만들지 않고도, S3에서 데이터를 읽어올 때 실시간으로 Lambda 함수를 실행하여 데이터를 변환(PII 제거 등)할 수 있습니다.

 

 

SAA 시험에서 S3 관련 문제는 거의 이 6개가 반복됩니다

서비스역할

S3	저장
S3 Lifecycle	자동 이동
S3 Glacier	장기 보관
S3 Object Lambda	데이터 변환
S3 Replication	복제
Athena	S3 SQL

 

 

 

---

Target Tracking Policy: 특정 지표(CPU, 네트워크 등)를 목표 값으로 유지하도록 자동으로 계산하는 정책입니다. (온도조절기 같은 역할)

 

 

---

1. Amazon RDS의 스토리지 확장 (수동적 확장)

RDS(MySQL, PostgreSQL 등)는 일반적인 하드디스크(EBS 볼륨)를 사용하는 방식입니다.

• 작동 방식: 사용자가 설정한 임계값(예: 남은 용량 10% 미만)에 도달하면 AWS가 물리적으로 디스크 용량을 늘려줍니다.
• 제약 사항: 한 번 늘린 디스크 크기는 다시 줄일 수 없습니다(Scale-down 불가). 또한, 디스크를 늘린 후 다음 확장을 하기까지 일정 시간(보통 6시간) 동안 대기해야 하는 제한이 있습니다.
• 비용: 실제로 데이터를 10GB만 써도 디스크를 100GB로 늘려놨다면 100GB만큼의 비용을 계속 내야 합니다.

---

2. Amazon Aurora의 스토리지 확장 (네이티브 자동 확장)

Aurora는 클라우드 환경에 최적화된 전용 스토리지 계층을 사용합니다.

• 작동 방식: 데이터를 쓰면 쓰는 대로 10GB 단위로 자동 확장됩니다. 사용자가 설정을 건드릴 필요조차 없습니다. (최대 128TB까지)
• 특장점: 데이터를 삭제하면 사용하지 않는 공간을 인식하여 비용 청구 규모도 자동으로 줄어듭니다. (공간 회수 가능)
• 성능: 디스크를 물리적으로 교체하거나 늘리는 과정이 없으므로 성능 저하 없이 매끄럽게 확장됩니다.

---

3. 한눈에 비교하기 (RDS vs Aurora)

구분	Amazon RDS	Amazon Aurora ( 사용하는 만큼만 비용을 지불(Pay-as-you-go))
확장 방식	EBS 볼륨 크기를 물리적으로 키움	10GB 세그먼트 단위로 즉시 추가
최대 용량	보통 64TB (엔진마다 다름)	최대 128TB
자동 축소	불가능 (늘리면 끝)	가능 (삭제하면 비용 감소)
관리 부담	자동 확장 설정을 켜야 함	기본적으로 자동 관리됨

 

 

 

---

AWS Step Functions의 **분산 맵(Distributed Map)**은 2022년 말에 출시된 기능으로, 서버리스 환경에서 대규모 병렬 데이터 처리를 가능하게 해주는 핵심 도구입니다.

쉽게 설명하면, 수만 개의 작업을 아주 작은 단위로 쪼개서 수천 개의 Lambda 함수에 동시에 나눠주는 '지휘자' 역할을 합니다.

---

1. 왜 등장했나요? (기존의 한계)

기존에도 Step Functions에는 Map 상태가 있었지만, 두 가지 큰 제약이 있었습니다.

• 병렬성 제한: 한 번에 약 40개 정도의 작업만 동시에 돌릴 수 있었습니다.
• 데이터 크기 제한: 한 번에 주고받는 데이터가 256KB를 넘으면 에러가 났습니다.

분산 맵은 이 벽을 허물고 최대 10,000개의 병렬 실행을 지원하며 S3와 직접 연동됩니다.

---

2. 핵심 특징

1. S3 직접 연동: S3 버킷에 쌓인 수백만 개의 객체(이미지, 로그 등)를 목록화하고 하나씩 읽어오는 과정을 Step Functions가 직접 처리합니다.
2. 엄청난 확장성: 최대 10,000개의 하위 워크플로(Child Workflow)를 동시에 실행할 수 있습니다.
3. 비용 효율성: 대규모 데이터를 처리할 때 별도의 클러스터(Hadoop, Spark 등)를 띄울 필요 없이, 실행한 만큼만 비용을 지불하는 서버리스 방식입니다.
4. 시각화 및 모니터링: 수만 개의 작업 중 어떤 것이 성공하고 실패했는지 콘솔에서 한눈에 확인하고, 실패한 항목만 따로 재시도할 수 있습니다.

---

3. 작동 원리 그림

 

[ 입력 소스: Amazon S3 ]
      │ (수백만 개의 파일/로그)
      ▼
┌────────────────────────────────┐
│   Step Functions (Dist Map)    │ ◀── 지휘자가 작업을 수만 개로 쪼갬
└──────────────┬─────────────────┘
      ┌────────┴────────┐
      ▼        ▼        ▼ 
 ┌────────┐┌────────┐┌────────┐
 │ Lambda ││ Lambda ││ Lambda │ ◀── 최대 10,000개 동시 실행
 └────────┘└────────┘└────────┘
      │        │        │
      ▼        ▼        ▼
[ 결과 저장 또는 다음 단계로 이동 ]

---

4. 언제 사용하나요? (Use Cases)

• 데이터 분석: S3에 저장된 수 테라바이트의 로그 파일 분석.
• 이미지/비디오 처리: 수만 개의 이미지 리사이징이나 비디오 인코딩.
• 배치 처리: 수백만 건의 금융 거래 내역 정산 및 보고서 생성.
• 반구조화 데이터 처리: JSON, CSV 파일의 대규모 변환 및 적재.

 

5. 요약 및 비교

구분	인라인 맵 (기존)	분산 맵 (신규)
최대 병렬성	약 40개	10,000개
입력 데이터	직접 전달 (256KB 제한)	S3에서 직접 읽기 (제한 없음)
주요 용도	간단한 반복 작업	빅데이터 배치 처리

 

 

 

---

 

• 데이터 규모와 전송 수단: 보통 수십 TB까지는 DataSync나 Direct Connect, PB 단위가 넘어가면 Snowball이나 Snowmobile이 정답일 확률이 매우 높습니다.
• Snowball vs Snowmobile: 10PB 정도면 여러 대의 Snowball(보통 대당 80TB 가용)로 처리 가능하며, 수십~백 PB 수준의 극단적인 경우에는 트럭 한 대 분량인 Snowmobile을 고려합니다.

1️⃣ Snowball vs Snowmobile vs DataSync 핵심 비교

서비스데이터 크기방식특징

Snowball	TB ~ PB	물리 장치	데이터 복사 후 배송
Snowmobile	10PB 이상	트럭	엑사바이트 이동
DataSync	TB	네트워크	온라인 전송

 

 

 

---

주요 프로토콜

시험 문제에 나왔던 용어들을 이 '대화 규칙' 관점에서 다시 살펴볼까요?

프로토콜	비유 (대화의 성격)	실제 용도
HTTP / HTTPS	"웹 문서를 보여줘!" 라고 요청하는 규칙	웹사이트 서핑
TCP	"데이터 잘 받았니? 하나라도 빠지면 다시 보내줄게" (꼼꼼함)	파일 전송, 이메일, 웹사이트
UDP	"잘 받았는지 상관없어, 일단 빨리 보낼게!" (신속함)	실시간 스트리밍, 온라인 게임
iSCSI	"네트워크 너머에 있는 하드를 내 컴퓨터 안에 있는 것처럼 쓸게"	스토리지 연결 (볼륨 게이트웨이)
NFS / SMB	"멀리 있는 폴더를 마치 내 컴퓨터 폴더처럼 공유할게"	파일 공유 (파일 게이트웨이)

 

 

 

---

Metadata: 실제 데이터가 아닌, 데이터를 설명하는 데이터(예: 파일 이름, 경로, 생성일). DB에는 이 정보만 남깁니다

 

 

AWS 시험 단골 유형 (대용량 객체 처리 공식)

상황	추천 솔루션 (정답 공식)
"DB 크기가 너무 커짐", "성능 저하"	대용량 파일(BLOB)을 S3로 이동
"S3에 있는 파일을 사용자에게 직접 제공"	S3 Pre-signed URL 사용
"RDS 스토리지 비용 절감"	S3 활용 (가장 저렴한 객체 저장소)
"비정형 데이터, 동영상, 이미지 저장"	Amazon S3

 

 

 

 

---

AWS 시험 단골 유형 (IP 필터링 공식)

상황	추천 솔루션 (정답 공식)
"수천~수만 개의 대규모 IP 주소 차단/허용"	AWS WAF (IP Set)
"특정 국가의 접속만 허용/차단"	AWS WAF (Geo Match Rule)
"VPC 내부 리소스 간의 간단한 IP 제어"	Security Group
"서브넷 전체에 대한 거부(Deny) 규칙 적용"	Network ACL (NACL)

 

 

---

AWS 시험 단골 유형 (Lake Formation 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"데이터 레이크 보안 중앙 관리"	AWS Lake Formation
"특정 열(Column) 또는 행(Row)만 권한 부여"	Lake Formation 데이터 필터 / LF-TBAC
"S3 데이터 권한을 IAM보다 세밀하게 관리"	AWS Lake Formation Permissions
"여러 분석 서비스 간의 일관된 보안 정책"	AWS Lake Formation

 

 

 

---

⭐ AWS Load Balancer 전체 정리 (SAA 시험 핵심)

구분                                                            언제 사용                       특징                          대표 서비스

 

HTTP / HTTPS 웹 서비스	웹 애플리케이션	L7 라우팅	Application Load Balancer
초고성능 TCP / UDP	게임, 금융	L4 고성능	Network Load Balancer
방화벽 / 네트워크 장비	보안 Appliance	트래픽 검사	Gateway Load Balancer

 

 

⭐ SAA 시험 단골 문제 TOP 10

문제 키워드정답이유

HTTP / HTTPS	ALB	L7
Path routing	ALB	URL 기반 라우팅
Host routing	ALB	도메인 라우팅
Microservices	ALB	서비스 분리
Container / Kubernetes	ALB	ECS / EKS
TCP / UDP	NLB	L4
초고성능 / 낮은 지연	NLB	고성능
Static IP 필요	NLB	고정 IP
보안 장비 검사	GWLB	firewall

 

 

---

 

Amazon CloudWatch Container Insights는 EKS, ECS, Fargate와 같은 컨테이너 환경을 위해 특화된 완전 관리형 모니터링 및 관측성(Observability) 서비스입니다.

쉽게 말해, 수많은 컨테이너가 복잡하게 얽혀 돌아가는 환경에서 "어떤 녀석이 CPU를 많이 쓰는지", "어떤 파드(Pod)가 자꾸 재시작되는지"를 한눈에 보여주는 컨테이너 전용 관제 센터라고 이해하시면 됩니다.

---

1. 주요 특징 및 기능

• 자동화된 수집: 클러스터, 노드, 파드, 컨테이너 수준의 성능 지표(CPU, 메모리, 네트워크, 디스크 사용량 등)를 자동으로 수집합니다.
• 통합 대시보드: 별도의 설정 없이도 인프라의 상태를 계층적으로 보여주는 시각화 대시보드를 즉시 제공합니다.
• 로그와 지표의 연결: 특정 시점에 CPU가 튀었다면, 그 당시의 로그를 바로 연결해서 확인할 수 있어 장애 대응 속도가 비약적으로 빨라집니다.
• 진단 정보 제공: 컨테이너 재시작 오류와 같은 상세한 진단 정보를 제공하여 문제의 원인을 신속하게 격리할 수 있도록 돕습니다.

---

2. 작동 원리 (EKS 기준)

Container Insights를 활성화하면 클러스터 내에 두 가지 핵심 구성 요소가 배포됩니다.

• CloudWatch Agent (DaemonSet): 각 노드에서 실행되며 CPU, 메모리 등의 **성능 지표(Metrics)**를 수집합니다.
• Fluent Bit (DaemonSet): 각 컨테이너의 **로그(Logs)**를 수집하여 CloudWatch Logs로 안전하게 전송합니다.

 

 

---

거버넌스(Governance) 모드는 적절한 권한을 가진 관리자가 백업을 삭제하거나 잠금을 해제할 수 있습니다. "어떤 사용자도 삭제해서는 안 된다"는 엄격한 요구사항에는 Compliance 모드가 정답입니다.

 

AWS Backup Vault Lock: 백업 데이터를 임의로 삭제하지 못하게 잠그는 기능입니다.

• Compliance Mode: 잠금 기간이 시작되면 AWS 계정 루트 사용자를 포함해 누구도 삭제하거나 수정할 수 없습니다.
• Governance Mode: 특정 권한이 있는 사용자만 관리 목적으로 수정할 수 있습니다.

 

 

---

**Amazon S3 Cross-Region Replication(CRR)**는 서로 다른 AWS 리전(Region)에 있는 S3 버킷 간에 객체를 자동으로, 비동기식으로 복제하는 기능입니다.

재해 복구(DR) 계획을 세우거나, 전 세계 사용자에게 낮은 지연 시간으로 콘텐츠를 제공해야 할 때 사용하는 필수적인 기능입니다.

---

1. 주요 특징

• 자동 및 비동기: 설정만 해두면 S3가 알아서 백그라운드에서 데이터를 복제합니다. 업로드 즉시 복제되는 것은 아니지만 보통 수 초 내에 완료됩니다.
• 메타데이터 보존: 객체 데이터뿐만 아니라 생성 시간, 버전 ID, 태그, ACL(액세스 제어 목록) 등의 메타데이터도 그대로 복제됩니다.
• 스토리지 클래스 변경: 원본은 Standard지만 복제본은 비용 절감을 위해 S3 Glacier로 저장되도록 설정할 수 있습니다.
• 계정 간 복제: 본인의 계정 내 다른 리전뿐만 아니라, 완전히 다른 AWS 계정의 리전으로도 복제할 수 있어 보안 강화에 유리합니다.

---

2. 필수 요구사항 (시험 단골 질문!)

CRR을 활성화하기 위해 반드시 충족해야 하는 조건들입니다.

1. 버전 관리(Versioning) 활성화: 원본 버킷과 대상 버킷 모두 버전 관리가 켜져 있어야 합니다.
2. IAM 역할(Role): S3가 원본에서 데이터를 읽고 대상 버킷에 쓸 수 있는 권한을 가진 IAM 역할이 필요합니다.
3. 리전의 다름: 이름 그대로 소스 버킷과 대상 버킷의 리전이 서로 달라야 합니다. (같으면 SRR - Same Region Replication)

---

3. 주요 사용 사례 (Use Cases)

• 규정 준수(Compliance): 데이터를 수백 킬로미터 떨어진 곳에 물리적으로 격리하여 저장해야 한다는 법적 요구사항이 있을 때.
• 지연 시간 최소화: 미국 사용자는 미국 리전 버킷에서, 한국 사용자는 한국 리전 버킷에서 사진을 다운로드받게 하여 속도를 높일 때.
• 재해 복구(Disaster Recovery): 한 리전 전체에 장애가 발생하더라도 다른 리전에서 즉시 서비스를 재개할 수 있도록 백업본을 유지할 때.

---

4. CRR vs SRR 비교

구분	Cross-Region Replication (CRR)	Same-Region Replication (SRR)
대상 위치	다른 AWS 리전	동일한 AWS 리전
주요 목적	재해 복구, 지연 시간 감소, 규정 준수	로그 통합, 개발/테스트 환경 동기화
비용	데이터 전송료(Outbound) 발생	데이터 전송료 없음 (무료)

 

 

 

기존에 버킷에 쌓여 있던 수만, 수억 개의 파일을 한 번에 복제하고 싶을 때 사용하는 것이 바로 S3 Batch Replication입니다.

---

1. S3 Batch Replication이란?

S3 복제 구성(CRR 또는 SRR)을 마친 후, 기존 데이터를 처리하기 위해 별도로 실행하는 **작업(Job)**입니다. S3 Batch Operations 기능을 활용하여 대규모 객체를 리전 간 또는 리전 내에서 복제합니다.

2. 핵심 작동 방식

• 작업 생성: S3 콘솔의 '복제(Replication)' 탭에서 기존 객체를 복제할지 묻는 옵션이 나타납니다. 이때 "예, 기존 객체를 복제합니다"를 선택하면 배치 작업이 생성됩니다.
• 매니페스트(Manifest): 복제해야 할 파일들의 목록을 S3가 자동으로 생성하거나 사용자가 CSV 파일로 제공할 수 있습니다.
• 수행: S3가 이 목록을 보고 백그라운드에서 대량으로 파일을 복사하기 시작합니다.

---

3. 일반 복제(CRR/SRR) vs 배치 복제(Batch Replication)

구분	일반 복제 (기본 설정)	배치 복제 (Batch Replication)
대상	설정 이후 업로드되는 새 객체	설정 이전에 이미 존재하던 기존 객체
실행 방식	이벤트 발생 시 자동 실행	사용자가 수동으로 작업(Job) 생성
용도	실시간 데이터 동기화	초기 마이그레이션, 데이터 유실 복구

 

 

 

. 요약 (Concept Summary)

• "새로 들어오는 것만 복제할래?" → S3 Replication (CRR/SRR)
• "기존에 있던 것까지 싹 다 복제할래?" → S3 Batch Replication

 

 

 

---

1. Active Directory (AD) 란?

Active Directory는 마이크로소프트에서 만든 **"중앙 집중식 자격 증명 관리 서비스"**입니다. 대부분의 회사 사무실에서 컴퓨터에 로그인할 때 사용하는 바로 그 시스템입니다.

• 역할: 회사에 있는 모든 사용자(ID), 비밀번호, 컴퓨터, 프린터 같은 자원들을 한곳에서 관리합니다.
• 핵심 기능: * 인증(Authentication): "이 사람이 우리 직원이 맞는가?"를 확인합니다.
  • 권한 부여(Authorization): "이 직원이 인사과 폴더에 접근해도 되는가?"를 결정합니다.
• 비유: 회사의 **'인사팀 명부'**와 같습니다. 신입사원이 들어오면 명부에 이름을 올리고, 퇴사하면 명부에서 지웁니다.

---

2. SAML 2.0 (Security Assertion Markup Language) 이란?

SAML은 서로 다른 서비스끼리 **"이 사람은 내가 확인한 우리 직원이니 믿고 들여보내 줘"**라고 인증 정보를 주고받기 위한 **'약속(프로토콜)'**입니다.

• 역할: 사용자가 여러 사이트에 일일이 로그인할 필요 없이, 한 번의 로그인으로 여러 서비스를 이용하게 해주는 **SSO(Single Sign-On)**를 가능하게 합니다.
• 작동 방식: XML이라는 문서 형식으로 "인증 정보"를 주고받습니다.
• 비유: **'놀이공원 자유이용권'**과 같습니다. 입구(AD)에서 신분증을 보여주고 팔찌(SAML 토큰)를 받으면, 안의 모든 놀이기구(AWS, Slack, Zoom 등)를 탈 때마다 신분증을 다시 보여줄 필요가 없는 것과 같죠.

---

3. AD와 SAML이 AWS에서 만나는 과정

시험 문제에 자주 나오는 시나리오는 이 둘이 합쳐지는 과정입니다.

1. 사용자: 브라우저를 통해 회사 포털에 로그인합니다. (ID 제공업체, IdP)
2. AD (IdP): 사용자가 우리 직원이 맞는지 확인하고, **SAML Assertion(인증 확인 문서)**을 생성합니다.
3. 브라우저: 이 문서를 들고 AWS(서비스 제공업체, SP)로 달려갑니다.
4. AWS: 문서를 읽어보고 "아, 회사의 AD가 보증하는 사람이구나!"라고 판단하여, 미리 설정된 **IAM 역할(Role)**의 권한을 일시적으로 부여합니다.

 

 

핵심 요약 (Concept Summary)

구분	Active Directory (AD)	SAML 2.0
정체	ID와 비번이 저장된 데이터베이스	정보를 전달하는 통신 규약(약속)
용도	사내 컴퓨터/로그인 관리	웹 서비스 간 Single Sign-On (SSO) 구현
AWS 관련	우리 회사 직원을 정의함	직원이 AWS에 로그인하게 연결해 줌

 

 

 

 

---

 

 

Amazon Route 53이란?

Amazon Route 53은 AWS에서 제공하는 가용성과 확장성이 뛰어난 클라우드 DNS(Domain Name System) 웹 서비스입니다. 쉽게 말해, 전 세계 사용자들이 여러분의 웹 애플리케이션에 접속할 수 있도록 "길을 안내하는 똑똑한 표지판"이라고 생각하시면 됩니다.

---

1. 이름의 유래

• Route: 트래픽의 경로를 지정한다는 의미입니다. (미국의 유명한 66번 국도 'Route 66'에서 영감을 받았다고도 합니다.)
• 53: 전 세계 모든 DNS 서비스가 표준적으로 통신할 때 사용하는 포트(Port) 번호 53을 상징합니다.

---

2. Route 53의 3가지 핵심 기능

Route 53은 단순히 주소를 변환하는 것 이상의 역할을 합니다.

1. 도메인 이름 등록 (Domain Registration):
   • yourname.com 같은 도메인 이름을 새로 구매하고 관리할 수 있습니다.
2. DNS 라우팅 (DNS Routing):
   • 사용자가 브라우저에 주소를 치면, 그에 맞는 서버의 IP 주소를 알려줍니다.
3. 상태 확인 (Health Checks):
   • 여러분의 서버가 살아있는지 주기적으로 확인합니다. 만약 서버가 다운되면, 자동으로 트래픽을 정상적인 다른 서버로 돌려버립니다. (장애 조치/Failover)

---

3. 왜 Route 53을 쓰나요? (주요 장점)

• 100% 가용성 보장: AWS 서비스 중 드물게 100% 가용성 SLA를 제공합니다. 전 세계 곳곳에 서버가 퍼져 있어 절대 죽지 않도록 설계되었습니다.
• 똑똑한 라우팅 (Routing Policies):
  • 지연 시간 기반: 사용자와 가장 가까운(빠른) 리전으로 연결.
  • 지리적 위치 기반: 사용자가 접속한 국가에 맞는 콘텐츠 제공.
  • 가중치 기반: 신규 버전 서버로 트래픽의 **10%**만 보내기 테스트 가능.
• AWS 서비스와 찰떡궁합: S3 버킷, CloudFront, 로드 밸런서(ALB) 등과 별칭(Alias) 기능을 통해 아주 쉽게 연결됩니다.

---

4. 요약 (Concept Summary)

특징	내용
정체	완전 관리형 DNS 서비스 (53번 포트 사용)
운영 방식	서버 관리, 패치, 스케일링을 AWS가 전부 대행 (운영 오버헤드 최저)
신뢰도	100% 가용성 설계
비용	호스팅 영역(Zone)당 월 요금 + 쿼리 수에 따른 비용 발생

 

 

 

 

---

 

 

 

Amazon RDS Blue/Green 배포는 데이터베이스를 안전하고 빠르게 업데이트하기 위해 AWS에서 제공하는 완전 관리형 배포 전략입니다.

쉽게 말해, 현재 사용 중인 DB와 똑같은 복제본을 하나 더 만들어서 거기서 미리 업데이트와 테스트를 다 해본 뒤, 문제가 없으면 순식간에 교체하는 방식입니다.

---

1. 핵심 개념: Blue와 Green

• Blue (현재 환경): 실제 사용자들이 접속해서 사용 중인 운영 데이터베이스입니다.
• Green (스테이징 환경): Blue의 복제본입니다. 여기서 엔진 업그레이드, 스키마 변경 등을 수행하고 테스트합니다.

---

2. 작동 프로세스

1. 복제 환경 생성: 클릭 몇 번으로 Blue 환경과 똑같은 구성(인스턴스, 파라미터, 스토리지 등)을 가진 Green 환경을 생성합니다.
2. 동기화: Blue에서 발생하는 변경 사항은 **논리적 복제(Logical Replication)**를 통해 Green으로 실시간 반영됩니다. 즉, 데이터 손실이 없습니다.
3. 변경 및 테스트: Green 환경에서 DB 버전을 올리거나 설정을 바꿔봅니다. 실제 서비스에는 전혀 영향을 주지 않습니다.
4. 전환 (Switchover): 모든 테스트가 끝나면 전환 버튼을 누릅니다. AWS가 자동으로 트래픽을 Green으로 넘기고, 이제 Green이 새로운 Blue(운영 환경)가 됩니다.

---

3. 왜 이걸 쓰나요? (주요 장점)

장점	설명
다운타임 최소화	전환(Switchover) 시 보통 1분 미만의 짧은 시간만 소요됩니다.
위험성 제거	운영 중인 DB(Blue)에 직접 손을 대지 않으므로, 테스트 중 장애가 나도 서비스는 안전합니다.
간편한 롤백	전환 전까지는 Blue가 그대로 살아있으므로, 문제가 발견되면 즉시 작업을 취소할 수 있습니다.
데이터 무손실	복제 기술을 통해 전환 직전까지의 모든 데이터가 Green에 반영됩니다.

 

 

 

---

1. Quantum Ledger Database (QLDB)

• 정의: QLDB는 완전히 관리되는 원장(ledger) 데이터베이스로, 중앙 신뢰 기관이 소유한 투명하고 변경 불가능한 트랜잭션 로그(기록)를 제공합니다.
• 특징: 데이터 변경 이력(트랜잭션 기록)이 영구적으로 보존되고, 모든 변경 사항이 추적 가능합니다.
• 사용 사례: 금융 기록, 공급망, 보험, HR 시스템 등 변경 불가능한 기록이 중요한 분야에서 활용됩니다.

 

---

 

(RDS 성능 개선 공식)

상황	추천 솔루션 (정답 공식)
"읽기 부하가 너무 많아 DB가 느려짐"	Read Replica (읽기 복제본) 추가
"장애 발생 시 중단 없는 서비스(고가용성)"	Multi-AZ 활성화
"단순 키-값 조회의 반복적 쿼리 성능 개선"	ElastiCache (Redis/Memcached) 도입
"데이터베이스 용량이 꽉 차서 확장이 필요"	Storage Auto Scaling 활성화

 

 

 

---

SnapMirror: NetApp의 데이터 복제 기술로, 볼륨 단위의 스냅샷 기반 복제를 수행합니다. 리전 간 DR 구성의 핵심 기술입니다.

 

(FSx 복제 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"NetApp ONTAP 환경의 리전 간 복제/DR"	NetApp SnapMirror
"Windows 파일 공유(SMB) 최적화 스토리지"	Amazon FSx for Windows File Server
"고성능 컴퓨팅(HPC), 초고속 병렬 파일 시스템"	Amazon FSx for Lustre
"온프레미스 NetApp 데이터를 AWS로 마이그레이션"	SnapMirror 또는 AWS DataSync

---

 

 

AWS KMS(Key Management Service)는 보안이 매우 강력한 서비스이기 때문에, 일반적인 다른 서비스들과 달리 **"두 개의 관문"**을 모두 통과해야 합니다. 3월 SAA-C03 시험에서 KMS 권한 문제는 거의 매회 출제되므로, 이 상호작용의 원리를 완벽히 이해하는 것이 합격의 열쇠입니다.

---

1. 문제 유형 (AWS SAA-C03)

도메인 3: 보안 아키텍처 설계 (Design Secure Architectures)

• 데이터 암호화 및 복호화 권한을 제어할 때 **IAM 정책(Identity-based)**과 **KMS 키 정책(Resource-based)**의 결합(Intersection) 논리를 평가합니다.

2. 문제 요구사항

• 상황: 사용자나 서비스(EC2, Lambda 등)가 KMS 키를 사용하여 데이터를 암복호화하려고 함.
• 핵심 질문: 왜 IAM에 권한을 줬는데도 거부되는가? 혹은 두 정책이 어떻게 협력하는가?

3. 정답 (핵심 개념)

KMS 키를 사용하려면 [IAM 정책에서의 허용] AND [KMS 키 정책에서의 허용]이 모두 충족되어야 합니다.

---

4. 이유 (왜 두 곳을 다 봐야 하나?)

AWS의 권한 결정 로직에서 KMS는 독특한 위치를 차지합니다.

1. IAM 정책 (The User's Key): 사용자가 "나는 KMS 키를 쓸 자격이 있다"라고 주장하는 신분증입니다.
2. KMS 키 정책 (The Vault's Permission): KMS 키 자체가 "나는 이 사용자에게 나를 쓸 수 있게 허락한다"라고 명시한 출입 명부입니다.

중요: KMS 키 정책에 Root 계정에 대한 권한 위임 설정("Principal": {"AWS": "arn:aws:iam::111122223333:root"})이 되어 있지 않다면, IAM 정책에서 아무리 FullAccess를 줘도 해당 키를 사용할 수 없습니다.

 

 

 

---

Lambda의 권한 모델은 크게 **"나를 누가 건드리는가(Inbound)"**와 "내가 누구를 건드리는가(Outbound)" 두 가지로 나뉩니다. 이 차이를 명확히 아는 것이 SAA 시험의 핵심입니다.

---

1. 문제 유형 (AWS SAA-C03)

도메인 3: 보안 아키텍처 설계 (Design Secure Architectures)

• 리소스 기반 정책(Resource-based Policy)과 IAM 실행 역할(Execution Role)의 차이점을 이해하고 서비스 간의 트래픽 방향에 따른 올바른 권한 부여 능력을 평가합니다.

2. 문제 요구사항

• 핵심 질문 1: Lambda의 리소스 기반 정책이란 무엇이며 언제 사용하는가?
• 핵심 질문 2: **외부 서비스(External)**를 호출할 때와 호출받을 때의 차이는 무엇인가?

3. 정답 (핵심 개념)

• 리소스 기반 정책 (누가 나를 깨우는가?): 다른 서비스(S3, API Gateway 등)가 내 Lambda를 **실행(Invoke)**할 수 있도록 허용하는 권한입니다.
• IAM 실행 역할 (내가 누구를 부르는가?): 내 Lambda가 다른 서비스(S3 읽기, KMS 복호화, CloudWatch 로그 기록)를 사용하기 위해 입는 신분증입니다.

---

4. Lambda 리소스 기반 정책 (Resource-based Policy) 자세히 보기

이 정책은 Lambda 함수라는 '리소스' 자체에 붙어있는 출입 명부입니다.

• 용도: "S3야, 너 내 Lambda 깨워도 돼", "API Gateway야, 너 내 Lambda 호출해도 돼"라고 허락해 주는 것입니다.
• 특징: IAM 사용자나 역할에 붙이는 것이 아니라, Lambda 함수 객체에 직접 붙입니다.
• 예시: S3 버킷에 파일이 올라왔을 때 Lambda가 자동 실행되려면, Lambda의 리소스 정책에 s3.amazonaws.com이 lambda:InvokeFunction을 할 수 있도록 등록되어야 합니다.

---

5. 외부 서비스 vs 내부 서비스 (호출 방향의 이해)

AWS 시험에서 '외부'라는 표현은 보통 **"내 Lambda의 통제권을 벗어난 다른 서비스"**를 의미합니다. 방향에 따라 필요한 권한이 다릅니다.

A. 나를 호출하는 서비스 (Inbound - 리소스 정책 필요)

Lambda 입장에서 자신을 깨우는 서비스들입니다.

• 종류: API Gateway, S3 Events, Amazon SNS, Alexa 등.
• 필요 권한: Lambda 리소스 기반 정책 (Push Model).

B. 내가 호출하는 서비스 (Outbound - IAM 실행 역할 필요)

Lambda 코드가 실행되면서 데이터를 가져오거나 넘겨줘야 하는 대상입니다.

• 종류: Amazon S3(데이터 읽기/쓰기), Amazon DynamoDB, AWS KMS(복호화), CloudWatch Logs.
• 필요 권한: IAM 실행 역할 (Execution Role).

예외 (Pull Model): SQS나 Kinesis의 경우, Lambda가 내부적으로 해당 서비스를 "폴링(감시)"해서 가져오기 때문에 이때는 리소스 정책이 아니라 IAM 실행 역할에 SQS/Kinesis 읽기 권한이 있어야 합니다.

---

6. 개념 정리

• Push Model: 이벤트 소스(S3, API GW)가 Lambda를 때림 → 리소스 정책 필요.
• Pull Model: Lambda 서비스가 이벤트 소스(SQS, Kinesis)를 읽어옴 → IAM 역할 필요.
• KMS 호출: Lambda가 "이거 복호화해 줘"라고 KMS에게 부탁하는 것이므로 IAM 역할이 필요합니다.

---

7. 그림 (Architecture)

Plaintext

 

┌──────────────────────────────────────────────────────────────────────────┐
│ [ Lambda Permission Model: Two-Way Security ]                            │
│                                                                          │
│  (1) INBOUND: "Who can wake me up?"      (2) OUTBOUND: "What can I do?"  │
│  ┌──────────────┐      ┌──────────────┐      ┌────────────────────────┐  │
│  │ Event Source │      │  AWS Lambda  │      │   Target Service       │  │
│  │ (S3, API GW) │─────▶│ (Function)   │─────▶│ (S3, DynamoDB, KMS)    │  │
│  └──────────────┘      └──────┬───────┘      └────────────────────────┘  │
│           │                   │                         ▲                │
│           │            ┌──────┴──────┐                  │                │
│           └───────────▶│Resource-based│         ┌────────┴──────┐        │
│                        │   Policy    │         │  IAM Execution │        │
│           (Permission) └─────────────┘         │     Role       │        │
│                                                └────────────────┘        │
│                                                   (Identity)             │
└──────────────────────────────────────────────────────────────────────────┘

---

8. AWS 시험 단골 유형 (Lambda 권한 공식)

상황	추천 솔루션 (정답 공식)
"S3가 Lambda를 호출하려고 하는데 권한 오류 발생"	Lambda 리소스 기반 정책에 S3 허용 추가
"Lambda가 CloudWatch에 로그를 못 남김"	Lambda IAM 실행 역할에 CloudWatch 권한 부족
"Lambda가 KMS 암호화된 파일을 열어야 함"	IAM 실행 역할(kms:decrypt) + KMS 키 정책 허용
"API Gateway가 Lambda를 호출할 권한 부여"	aws lambda add-permission (리소스 정책 수정)

 

"누가 나를 부르는지는 '리소스 정책'에 적고, 내가 나가서 누구를 부리는지는 'IAM 역할'에 적습니다. KMS를 호출하는 것은 Lambda가 '나가는' 것이므로 IAM 역할이 필요한 것입니다!"

 

 

---

AWS 시험 단골 유형 (데이터 분석 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"S3 데이터, 가끔 실행하는 SQL 분석, 저렴한 비용"	Amazon Athena
"실시간 대시보드, 로그 검색, 시각화"	Amazon OpenSearch (ELK)
"대규모 복잡한 데이터 분석, 데이터 웨어하우스"	Amazon Redshift
"비정형 데이터의 ETL 처리, Spark/Hadoop 필요"	Amazon EMR

 

 

 

---

AWS 시험 단골 유형 (인증서 관리 공식)

요구사항 키워드	추천 솔루션 (정답 공식)
"여러 하위 도메인을 저렴하고 쉽게 보호"	와일드카드 인증서 (*https://www.google.com/search?q=.domain.com)
"인증서 자동 갱신 및 운영 최소화"	DNS 검증 (DNS Validation)
"ALB 또는 CloudFront에 HTTPS 적용"	ACM 인증서 사용
"내부 애플리케이션 간 보안 통신"	ACM Private CA (개인 인증서)

 

 

---

 

Amazon EBS 볼륨 타입: 비용 및 성능 비교표

분류	볼륨 타입	비용 수준	성능 특징	시험 정답 포인트 (Key Logic)
SSD	gp3	낮음 (가성비 1위)	용량과 별개로 IOPS 설정 가능	가장 비용 효율적인 SSD 선택 시 정답.
SSD	gp2	보통	용량에 비례한 IOPS (1GB=3 IOPS)	gp3보다 비싸고 유연성 낮음 (최근 오답 추세).
SSD	io2 (Block Express)	매우 높음	극강의 IOPS, 99.999% 내구성	비용 상관없이 최고 성능 혹은 내구성 강조 시 정답.
HDD	st1	낮음	높은 처리량 (Throughput, MB/s)	빅데이터, 로그, 데이터 웨어하우스용 저비용 저장소.
HDD	sc1	최저 (최저가)	낮은 액세스 빈도, 낮은 성능	아카이브, 백업 등 성능이 전혀 안 중요할 때 정답.

 

 

 

 

---

AWS RAM: 계정 간 리소스 공유 서비스. 접두사 목록, 서브넷, 라이선스 등을 공유하여 중복 생성을 막고 중앙 관리를 지원함.

 

 

---

AWS 시험 단골 유형 (스케일링 정책 공식)

트래픽 패턴	추천 솔루션 (정답 공식)
"매일 아침 9시 / 블랙 프라이데이 등 날짜 확정"	예약된 크기 조정 (Scheduled Scaling)
"트래픽 급증/급감 예측 불가"	동적 크기 조정 (Target Tracking 등)
"과거 데이터를 기반으로 미리 준비"	예측 크기 조정 (Predictive Scaling)
"인스턴스 개수를 항상 2대로 유지"	ASG 최소 용량(Min Capacity) 설정

 

 

 

---

AWS 시험 단골 유형 (RDS 확장 및 성능 공식)

상황	추천 솔루션 (정답 공식)
"애플리케이션 확장으로 인한 DB 연결 부족"	Amazon RDS Proxy
"읽기 요청이 너무 많아 DB가 느려짐"	Read Replicas (읽기 전용 복제본)
"자주 조회되는 데이터의 속도 향상"	Amazon ElastiCache (Redis/Memcached)
"쓰기 성능 한계 및 복잡한 관리 해결"	Amazon Aurora (Serverless)

 

 

---

자동화 (DLM): **Amazon Data Lifecycle Manager (DLM)**는 EBS 스냅샷의 생성, 보존 및 삭제를 자동화하는 관리형 서비스입니다. "7일간 보관 후 삭제"와 같은 정책을 한 번만 설정하면, 이후로는 사람이 개입하지 않아도 비용을 일정하게 유지해 줍니다.

 

 

---

AWS 시험 단골 유형 (고가용성 공식)

대상 리소스	고가용성 달성 방법 (정답 공식)
컴퓨팅 (EC2)	ALB + Auto Scaling Group (Multi-AZ)
관계형 DB (RDS)	Multi-AZ Deployment (Primary/Standby)
NoSQL DB (DynamoDB)	기본적으로 고가용성 제공 (3개 AZ 복제)
스토리지 (S3)	기본적으로 고가용성 제공 (최소 3개 AZ 복제)

 

 

 

---

AWS Organizations Tag Policies: 조직 내 리소스에 대한 태깅 표준을 정의합니다. 특정 태그가 없거나 값이 일치하지 않는 리소스에 대해 규정 미준수(Non-compliant) 상태를 보고하거나 수정을 요구할 수 있습니다.

 

 

 

---

. AWS 시험 단골 유형

• "DB 암호를 주기적으로 자동 교체해야 한다" → AWS Secrets Manager
• "비용을 아끼면서 단순한 설정값(ID 등)을 저장하고 싶다" → Systems Manager Parameter Store
• "암호가 교체되어도 앱 수정 없이 최신 암호를 쓰고 싶다" → Secrets Manager API 호출

 

 

---

 

AWS 시험 단골 유형

• "트래픽이 예측 불가능하거나 갑자기 튄다(Spiky)" → On-Demand Mode
• "트래픽이 일정하거나 작업량을 미리 알고 있다" → Provisioned Mode
• "24시간 일정한 부하가 1년 이상 지속된다" → Reserved Capacity
• "개발/테스트용으로 가끔만 쓴다" → On-Demand (단, 작업량을 모를 때) / Provisioned (작업량을 알고 수동 조절할 때)

 

유사 서비스 비교

개념	DynamoDB	Amazon EC2	AWS Lambda	Amazon RDS
예측 불가 (쓴 만큼 지불)	On-Demand	On-Demand	기본 모델 (요청당)	Aurora Serverless
예측 가능 (자원 예약)	Provisioned	Capacity Reservations	Provisioned Concurrency	Standard RDS
장기 사용 (할인)	Reserved Capacity	Reserved Instances (RI)	Savings Plans	Reserved Instances

 

 

---

Multi-AZ는 **고가용성(장애 복구)**을 위한 기술입니다.

대기(Standby) 인스턴스는 장애 시 교체용일 뿐, 평상시에는 트래픽을 처리할 수 없습니다. (단, Multi-AZ DB Cluster인 경우는 가능하나 일반 배포에서는 오답입니다.)  -----> 고가용성 (장애 복구)

 

 

**읽기 복제본(Read Replica)**은 주 DB 인스턴스의 복사본을 만들어 읽기 전용 트래픽을 처리합니다. 이를 통해 주 DB의 CPU 및 I/O 부하를 직접적으로 줄일 수 있습니다.   ---->  읽기 성능 향상, 부하 분산

 

(자동 크기 조정): RDS의 '자동 크기 조정'은 주로 스토리지(용량) 부족 시 디스크 크기를 늘리는 기능입니다.

-----> 스토리지 용량 해결

 

중요! 성능(Read Replica) vs 가용성(Multi-AZ)

SAA 시험에서 가장 많이 파놓는 함정이 바로 이 둘을 섞어놓는 것입니다. 반드시 구분해야 합니다.

구분	읽기 복제본 (Read Replica)	다중 AZ (Multi-AZ)
주 목적	성능 향상 (Scalability)	고가용성 (High Availability)
복제 방식	비동기식 (약간의 시차 발생 가능)	동기식 (실시간 복제)
활용	실제 서비스(읽기 트래픽 처리)에 사용	평소엔 대기(Standby), 장애 시에만 사용
연결 방식	별도의 엔드포인트 제공	주 DB와 동일한 엔드포인트 사용 (Failover)

 

 

 

---

AWS 서비스(특히 RDS나 EMR, ElastiCache 등)를 공부하시다 보면 **인스턴스(Instance)**와 **클러스터(Cluster)**라는 용어가 계속 섞여 나와 헷갈리실 수 있습니다.

시험 관점에서 이 둘의 차이를 명확하게 이해하실 수 있도록 그림과 함께 정리해 드립니다.

---

1. 인스턴스 (Instance)

• 정의: 가상 환경에서 실행되는 **단일 컴퓨팅 단위(서버 1대)**입니다.
• 특징: CPU, 메모리(RAM), 네트워크 대역폭이 할당된 독립적인 리소스입니다.
• 비유: 아파트 단지 안의 **'집 한 채'**라고 생각하시면 됩니다.

2. 클러스터 (Cluster)

• 정의: 특정 목적을 위해 서로 연결되어 하나의 시스템처럼 작동하는 인스턴스들의 집합입니다.
• 특징: 고가용성(HA)을 보장하고, 읽기 부하를 분산(Read Replica)하거나 대규모 연산(EMR)을 처리하기 위해 여러 대를 묶은 상태입니다.
• 비유: 여러 집이 모여 있는 **'아파트 단지 전체'**입니다.

---

3. 그림으로 보는 구조적 차이

Plaintext

 

  [ 단일 인스턴스 (Instance) ]           [ 클러스터 (Cluster) ]
  (Single Point of Failure)            (High Availability & Scaling)

      +--------------+                 +-------------------------------+
      |              |                 |           Cluster             |
      |  [Instance]  |                 |  +----------+   +----------+  |
      |   (Server)   |                 |  | Instance |   | Instance |  |
      |              |                 |  | (Primary)| <-> (Replica)|  |
      +--------------+                 |  +----------+   +----------+  |
                                       |  +----------+   +----------+  |
                                       |  | Instance |   | Instance |  |
                                       |  | (Replica)|   | (Replica)|  |
                                       |  +----------+   +----------+  |
                                       +-------------------------------+

---

4. 주요 차이점 비교표

구분	인스턴스 (Instance)	클러스터 (Cluster)
단위	개별 서버 (1대)	서버들의 그룹 (N대)
목적	애플리케이션 실행, DB 구동	고가용성, 부하 분산, 병렬 처리
장애 대응	인스턴스 장애 시 서비스 중단	다른 인스턴스가 즉시 업무 대행 (Failover)
예시	RDS Single-AZ 인스턴스, EC2 1대	Aurora 클러스터, EMR 클러스터

 

 

 

 

---

1. 서비스 유형 비교

• Kinesis Data Streams (KDS): 대량의 데이터를 실시간으로 수집하고 보관하는 '저장소/통로' 역할입니다.
• Kinesis Data Firehose (KDF): 데이터를 특정 목적지(S3, Redshift, OpenSearch 등)로 **'배달'**해주는 전송 서비스입니다.

2. 작동 방식 (Pull vs Push)

• Data Streams (Pull): 데이터를 보관하고 있으면, 소비자(Consumer, 예: Lambda, EC2 애플리케이션)가 직접 데이터를 가져가야(Pull) 합니다.
• Firehose (Push): 설정된 목적지로 데이터를 직접 밀어 넣어줍니다(Push). 개발자가 데이터를 가져가는 코드를 짤 필요가 없습니다.

3. 실시간성 (Latency)

• Data Streams: 0.1초~1초 미만의 지연 시간. 진짜 실시간(Real-time) 분석에 적합합니다.
• Firehose: 60초~900초 (또는 데이터 용량 기준). 데이터를 모아서 한꺼번에 보내는 '버퍼링' 방식이므로 **거의 실시간(Near Real-time)**입니다.

4. 확장성 관리

• Data Streams: **샤드(Shard)**라는 단위를 수동으로 관리해야 합니다. 트래픽이 늘어나면 샤드를 늘려줘야 합니다.
• Firehose: 완전 관리형입니다. 데이터 양에 따라 AWS가 알아서 자동으로 확장합니다. 운영 오버헤드가 거의 없습니다.

5. 데이터 보존 (Retention)

• Data Streams: 데이터를 기본 24시간에서 최대 365일까지 보관할 수 있습니다. (여러 소비자가 같은 데이터를 돌려볼 수 있음)
• Firehose: 데이터를 보관하지 않습니다. 전달이 완료되면 끝납니다. (전달 실패 시 백업용 S3 저장 가능)

6. 요약표

 

특징	Kinesis Data Streams	Kinesis Data Firehose
핵심 역할	데이터 수집 및 실시간 처리 통로	데이터 전송 및 로드 (Delivery)
목적지	사용자 정의 애플리케이션, Lambda 등	S3, Redshift, OpenSearch, Splunk
관리 주체	사용자 (샤드 개수 조절 필요)	AWS (완전 관리형)
운영 비용	샤드 시간당 비용 + 페이로드 비용	전송된 데이터 양에 따른 비용
코드 작성	필요함 (Consumer 코드 작성)	필요 없음 (설정만으로 전송)

 

 

 

 

---

1. 사용자가 KMS에서 키를 만들어 거는 경우 (SSE-KMS)

방금 문제의 정답이었던 방식입니다. 가장 많이 쓰이며 권장되는 방식입니다.

• 방법: 사용자가 KMS 서비스에 가서 키를 직접 만들고, S3 업로드 시 "이 키로 암호화해줘"라고 지정합니다.
• 제어권: 매우 높음. 사용자가 키를 언제든 비활성화하거나, 1년마다 자동으로 바뀌게(순환) 설정할 수 있습니다.

2. 사용자가 직접 만든 키를 S3에 전달만 하는 경우 (SSE-C)

이 방식은 키 자체를 AWS에 저장하고 싶지 않을 때 사용합니다.

• 방법: 사용자가 자기 로컬 환경이나 자체 보안 장비에서 암호화 키를 만듭니다. S3에 파일을 올릴 때 HTTP 헤더에 키를 같이 실어서 보냅니다.
• 특징: S3는 암호화만 해주고 키는 즉시 메모리에서 삭제합니다. 즉, 나중에 파일을 받을 때 사용자가 똑같은 키를 다시 보내지 않으면 AWS도 파일을 열어볼 방법이 없습니다.
• 주의: 키를 잃어버리면 데이터는 영원히 못 찾습니다. (AWS가 키를 안 가지고 있기 때문)

3. 클라이언트 측 암호화 (Client-Side Encryption)

S3에 보내기 전에 내 컴퓨터에서 미리 암호화를 다 끝내는 방식입니다.

• 방법: S3에 올리기 전에 내 서버에서 암호화 라이브러리를 써서 파일을 암호문으로 바꾼 뒤, S3에는 그냥 '검은 봉지'에 담긴 데이터만 올립니다.
• 제어권: 최상. AWS는 이게 데이터인지 이미지인지조차 알 수 없습니다.

---

4. 한눈에 비교하는 S3 암호화 옵션

옵션명	키 관리 주체	암호화 장소	특징
SSE-S3	AWS (S3 전용)	S3 서버	가장 쉽고 무료. 하지만 사용자가 키를 못 만짐. AWS가 키를 완전히 관리
SSE-KMS	사용자 (KMS)	S3 서버	시험 단골 정답. 키 생성/교체/권한 제어 가능.
SSE-C	사용자 (직접)	S3 서버	키를 AWS에 보관하기 싫을 때 사용.
CSE	사용자	사용자 서버	S3로 보내기 전에 이미 암호화 완료.