본문 바로가기
Cloud/AWS

[AWS] EC2, ELB, 마이크로서비스와 컨테이너, Lambda_250818

by 에르모사 쩐뉴 2025. 9. 15.

 linux(root), windows(administrator) 지원함. 권한도 지원. 

ec3 인스턴스 type(spec) :

Free-tire

type: t3.micro

t3.medium ->  t3.large

type을 높여가며 조정 가능. 

 

AWS EC2 인스턴스 핵심 요약

1. EC2란?

  • AWS에서 제공하는 가상 서버
  • 컴퓨터 한 대 빌리는 것과 비슷함
  • 인스턴스 타입 = 그 서버의 “사양 모델명”

2. T 시리즈 (t2, t3 …)

👉 저렴하고 범용적인 서버 계열

  • 특징: 버스트 성능(CPU 크레딧)
    • 평소엔 CPU를 조금만 쓰다가
    • 갑자기 부하 걸리면 잠깐 성능 ↑ (크레딧 사용)

3. T2 vs T3 차이

구분  T2  T3
세대 이전 세대 최신 세대
CPU Intel 전용 Intel + AMD (옵션)
CPU 크레딧 고정 모드만 있음 기본 모드 + Unlimited 모드 (자동으로 성능 유지 가능)
성능/가격 구형이라 조금 비싸고 효율↓ 최신이라 가격↓, 성능↑
Free Tier t2.micro (예전) t3.micro (현재 주로 제공)

 

4. 인스턴스 이름 구조

t3.micro 같은 이름은 이렇게 해석해요:

  • t = T 계열 (저렴/범용)
  • 3 = 세대 (버전)
  • micro = 사이즈 (작을수록 싸고 사양 낮음)

 

5. 사이즈별 메모리

타입  vCPU  메모리
nano 2 0.5GB
micro 2 1GB
small 2 2GB
medium 2 4GB
large 2 8GB
xlarge 4 16GB
2xlarge 8 32GB

 

핵심 한 줄 정리

  • T2 = 구형, 제한적 CPU 크레딧
  • T3 = 신형, 더 싸고 성능 좋고 Unlimited 모드 지원
  • t3.micro = Free Tier에서 1년간 무료 제공되는 “작고 저렴한 서버”

토큰 방식으로 메타데이터를 가져온다. 

 

 

 

 

인스턴스 유형 클래스 용도 특징
범용 (General Purpose) T, M 시리즈 웹 서버, 소규모 데이터베이스, 개발 환경 등 다양한 워크로드
- CPU와 메모리가 균형 있게 제공
-T 시리즈: 저렴한 가격, 소규모 워크로드
- M 시리즈: 균형 잡힌 성능, 일반적인 용도
컴퓨팅 최적화 (Compute Optimized) C 시리즈 고성능 웹 서버, 배치 처리, 과학 컴퓨팅, 고성능 컴퓨팅 (HPC)
- CPU를 많이 사용하는 워크로드에 특화
- 메모리 대비 CPU 코어 수가 높음
- 복잡한 연산에 적합
메모리 최적화 (Memory Optimized) R, X, Z 시리즈 대규모 데이터베이스, 빅데이터 분석, 인메모리 캐싱
- 메모리 용량이 매우 중요한 워크로드에 특화
- 대용량 데이터베이스, 데이터 분석에 적합
스토리지 최적화 (Storage Optimized) I, D, H 시리즈 대규모 데이터 웨어하우스, 분산 파일 시스템, NoSQL 데이터베이스
- 로컬 스토리지의 입출력(I/O) 성능이 매우 중요
- 초고속/대용량 스토리지를 제공
가속 컴퓨팅 (Accelerated Computing) P, G, F 시리즈 머신러닝, 고성능 그래픽, 과학 시뮬레이션
- GPU나 FPGA와 같은 하드웨어 가속기 사용
- 연산 성능을 극대화
- AI, 머신러닝, 고성능 그래픽에 주로 사용

1. 온디맨드 인스턴스 (On-Demand Instances)

가장 기본적인 요금 옵션으로, 인스턴스를 사용한 만큼만 시간당 또는 초당 비용을 지불합니다.

  • 특징: 약정 없이 원하는 때에 인스턴스를 시작하고 중지할 수 있어 최고의 유연성을 제공합니다.
  • 적합한 워크로드: 개발 및 테스트 환경, 예측하기 어려운 트래픽을 가진 애플리케이션 등 장기 계약 없이 유연하게 사용해야 하는 경우.

2. 예약 인스턴스 (Reserved Instances)

1년 또는 3년 약정으로 인스턴스를 예약하여 온디맨드 요금보다 대폭 할인된 가격으로 이용하는 옵션입니다.

  • 특징: 특정 인스턴스 유형과 리전(Region)을 약정하는 대신 큰 폭의 할인을 받습니다. 장기적이고 예측 가능한 워크로드에 가장 비용 효율적입니다.
  • 적합한 워크로드: 24/7 구동되는 웹 서비스, 엔터프라이즈 애플리케이션 등 지속적으로 사용량이 일정한 경우.

3. 스팟 인스턴스 (Spot Instances)

AWS의 남는 컴퓨팅 자원을 경매 방식으로 매우 저렴하게 이용하는 옵션입니다. 온디맨드 요금 대비 70% 이상 할인받을 수 있습니다.

  • 특징: 인스턴스 가격은 시장 수요와 공급에 따라 변동합니다. AWS가 해당 자원이 필요해지면 사용자에게 2분 전에 통보하고 인스턴스를 회수할 수 있습니다.
  • 적합한 워크로드: 시작과 종료에 관계없이 작동할 수 있는 배치 작업, 빅데이터 분석, 분산 컴퓨팅 등 중단에 대한 내성이 있는 작업.

4. Savings Plans

일정 기간 동안 (1년 또는 3년) 매시간 특정 금액의 컴퓨팅 사용량을 약정하여 EC2 온디맨드 요금 대비 최대 72% 할인받는 옵션입니다.

  • 특징: 예약 인스턴스보다 더 높은 유연성을 제공합니다. 인스턴스 유형, 운영 체제, 리전에 관계없이 약정 금액 내에서 할인 혜택이 적용됩니다. 예를 들어, M5 인스턴스에서 C5 인스턴스로 변경해도 할인이 유지됩니다.
  • 적합한 워크로드: 지속적인 컴퓨팅 사용량이 예상되지만, 워크로드의 인스턴스 유형이나 운영 체제가 변경될 수 있는 경우.

예약 인스턴스 (Reserved Instances) 결제 방식

**"Full", "Partial", "None"**은 예약 인스턴스(Reserved Instances)를 구매할 때 선택하는 선불(Upfront) 결제 방식을 의미합니다.

  • All Upfront (Full Upfront):
    • 전액 선불: 1년 또는 3년 약정 기간에 해당하는 요금 전체를 계약 시작 시점에 한 번에 지불합니다.
    • 특징: 가장 큰 할인율을 제공하며, 약정 기간 동안 추가 비용이 발생하지 않습니다.
    • 적합한 경우: 장기적으로 안정적인 비용 지출을 원할 때.
  • Partial Upfront (Partial Upfront):
    • 일부 선불: 계약 시작 시점에 일부 금액을 먼저 지불하고, 나머지 비용은 약정 기간 동안 월 단위로 나눠서 지불합니다.
    • 특징: Full Upfront 다음으로 높은 할인율을 제공하며, 초기 비용 부담을 줄일 수 있습니다.
    • 적합한 경우: 초기 비용을 분산시키면서 할인 혜택을 받고 싶을 때.
  • No Upfront (None Upfront):
    • 선불 없음: 계약 시작 시점에 지불하는 선불금 없이, 약정 기간 동안 매월 정해진 금액을 지불합니다.
    • 특징: 세 가지 중 할인율은 가장 낮지만, 그래도 온디맨드(On-Demand) 요금보다는 저렴하며 초기 비용 부담이 전혀 없습니다.
    • 적합한 경우: 비용을 월별로 관리하면서 온디맨드 요금 이상의 할인을 받고 싶을 때.

다중 가용 영역 (Multi-AZ)

Multi-AZ는 "Multiple Availability Zones"의 약자로, 애플리케이션의 고가용성(High Availability) 및 내결함성(Fault Tolerance)을 확보하기 위한 AWS 아키텍처 개념입니다.

  • 가용 영역 (Availability Zone, AZ):
    • AWS 리전(Region) 내에 물리적으로 분리된 하나 이상의 데이터 센터를 말합니다. 각 AZ는 독립된 전력, 냉각, 네트워킹을 갖추고 있어 한 AZ에 문제가 발생해도 다른 AZ에 영향을 주지 않습니다.
  • Multi-AZ 구성:
    • 데이터베이스나 애플리케이션 서버를 두 개 이상의 가용 영역에 분산 배치하여 운영하는 것을 의미합니다.
    • 예를 들어, 하나의 EC2 인스턴스를 서울 리전의 ap-northeast-2a와 ap-northeast-2c 두 개의 AZ에 복제하여 운영하는 방식입니다.
  • 장점:
    • 내결함성: 한 AZ에 자연재해, 전력 문제 등으로 장애가 발생하더라도 다른 AZ에 있는 인스턴스가 서비스를 계속 제공하여 중단 없는 운영이 가능합니다.
    • 고가용성: 예상치 못한 장애 상황에 대비하여 서비스의 가용성을 높입니다.

따라서, "Full/Partial/None"은 예약 인스턴스의 결제 방식을 나타내고, "Multi-AZ"는 클라우드 아키텍처의 설계 방식을 나타내는 용어입니다.

 

1. AMI와 AWS Image Builder: '골든 이미지'의 탄생

강의에서 가장 중요한 부분은 **AMI(Amazon Machine Image)**와 이를 만드는 서비스인 AWS Image Builder에 대한 설명입니다.

  • **AMI (Amazon Machine Image)**란, 쉽게 말해 **OS(운영 체제)가 설치된 서버의 '복사본' 또는 '템플릿'**입니다. 마치 PC에 윈도우나 리눅스 OS를 설치한 후, 그 상태 그대로를 이미지로 저장해 놓는 것과 비슷합니다. 이 AMI를 사용하면 동일한 설정의 서버를 여러 개 빠르게 만들 수 있습니다.
  • AMI의 종류:
    • AWS에서 기본 제공하는 AMI: 리눅스(우분투, 레드햇, 로키 등)나 윈도우와 같은 OS가 미리 설치된 AMI를 말합니다.
    • AWS Marketplace AMI: AWS 마켓플레이스는 다양한 소프트웨어와 애플리케이션이 설치된 AMI를 판매하는 '장터'입니다. AWS가 직접 제공하지 않는 특정 애플리케이션이 필요한 경우, 여기서 구매하여 사용할 수 있습니다.
    • 커스텀(Custom) AMI: 사용자가 직접 만든 AMI입니다. 단순한 복사본을 넘어, Image Builder를 활용해 버그가 없고 안정화된 이미지를 만들 수 있습니다.
  • AWS Image Builder는 이러한 커스텀 AMI를 자동화된 파이프라인으로 안정적이고 쉽게 생성하고 관리할 수 있도록 도와주는 서비스입니다. 특히, 자동으로 테스트를 진행하여 안정성을 확보하고 주기적인 업데이트를 가능하게 합니다.
  • '골든 이미지(Golden Image)':
    • Image Builder를 통해 테스트까지 거쳐 버그가 없고 안정화된 AMI를 골든 이미지라고 부릅니다. 이는 현업에서 매우 중요한 개념으로, "골든 이미지가 어떤 거냐"는 질문은 "안정된 AMI가 뭐냐"는 뜻으로 이해할 수 있습니다.

📝 시험 예상 문제: AMI의 역할과 종류(기본 제공, 마켓플레이스, 커스텀)를 묻는 문제가 출제될 수 있습니다. 특히, AWS Image Builder의 역할과 **'골든 이미지'**의 의미를 묻는 문제가 나올 가능성이 높습니다.

2. EC2 보안: 키 페어와 사용자 데이터

EC2 인스턴스에 안전하게 접속하기 위한 방법과 자동화 스크립트에 대한 내용입니다.

  • EC2 로그인 방식:
    • EC2는 ID/패스워드 방식을 지원하지 않습니다. 대신 암호화된 키 페어를 사용합니다.
    • **키 페어(Key Pair)**는 퍼블릭 키와 프라이빗 키로 구성됩니다.
      • 퍼블릭 키: AWS가 관리하고 EC2 인스턴스에 저장됩니다. (은행이 관리하는 OTP와 유사한 개념입니다.)
      • 프라이빗 키: 사용자가 직접 다운로드하여 안전하게 보관해야 합니다. (사용자의 은행 인증서와 유사한 개념입니다.)
    • 이 두 키가 조합되어야만 **SSH(Secure Shell)**를 통해 안전하게 로그인할 수 있습니다.
  • 사용자 데이터(User Data):
    • EC2 인스턴스가 처음 생성될 때 자동으로 실행되도록 설정하는 스크립트입니다.
    • 번거롭게 서버에 접속하여 직접 명령어를 입력할 필요 없이, 인스턴스가 시작됨과 동시에 필요한 설정이나 애플리케이션을 자동으로 설치하고 실행하는 데 사용됩니다.
    • 리눅스 스크립트는 #!/bin/bash와 같은 **Shebang(#!)**으로 시작해야 하고, 윈도우는 <powershell>과 같은 태그를 사용합니다.

3. EC2 인스턴스 메타데이터와 IMDSv2

메타데이터는 EC2 인스턴스에 자동으로 부여되는 정보입니다.

  • 메타데이터(Metadata): 인스턴스가 생성될 때 자동으로 부여되는 정보입니다. 강의에서는 신생아에게 부여되는 정보(출생 시간, 부모님 정보 등)에 비유했습니다.
    • EC2 메타데이터에는 고유한 인스턴스 ID, IP 주소, 도메인, MAC 주소 등이 포함됩니다.
  • IMDS(Instance Metadata Service) 토큰 방식:
    • 과거에는 별도의 인증 없이 메타데이터에 접근할 수 있어 보안에 취약했습니다.
    • **IMDSv2(버전 2)**는 보안을 강화하기 위해 토큰 방식을 도입했습니다. 이제 메타데이터를 요청할 때 먼저 토큰을 발급받아야만 메타데이터 정보를 얻을 수 있습니다. 이는 "정보를 쉽게 던져주지 않고 한 번 더 토큰을 받아오게 하자"는 보안 강화의 일환입니다.

📝 시험 예상 문제: 메타데이터의 정의와 함께, IMDSv2의 토큰 방식이 왜 도입되었고 어떤 보안적 이점이 있는지를 묻는 문제가 나올 수 있습니다.

4. AWS 컴퓨트 옵티마이저 (Compute Optimizer)

  • 컴퓨트 옵티마이저: AWS가 제공하는 기계 학습(Machine Learning) 기반의 서비스입니다.
  • 역할:
    • 사용자의 EC2 인스턴스 사용 데이터를 분석하여, 최적의 EC2 인스턴스 유형을 추천해 줍니다.
    • 이는 사용자의 주관적인 '경험'이 아닌 객관적인 데이터를 기반으로 하므로, 비용 효율적이고 성능이 최적화된 자원 선택을 도와줍니다.
    • 클라우드왓치(CloudWatch)의 데이터를 트레이닝하여 최적의 EC2 인스턴스를 제안해 줍니다.

📝 시험 예상 문제: AWS 컴퓨트 옵티마이저가 제공하는 기능과 그 이점(기계 학습 기반의 최적화 추천, 비용 절감)에 대해 묻는 문제가 나올 수 있습니다.

5. 기타 언급된 내용

  • **VPC (Virtual Private Cloud)**와 서브넷 (Subnet): AWS 클라우드 내 사용자가 정의하는 가상의 네트워크 공간과 그 하위 구역입니다.
  • 컴퓨팅 자원과 요금제: EC2 중심의 요금제에서 람다(Lambda)와 컨테이너 같은 서버리스 환경이 확산됨에 따라 컴퓨트 요금제가 도입되었다고 설명합니다.
  • S3와 VS Code는 각각 파일 저장 서비스와 개발 도구로 언급되었습니다.

 

1. AWS 로드 밸런싱과 자동 확장

강의의 핵심 주제는 **Elastic Load Balancer (ELB)**와 Auto Scaling입니다. 이 두 서비스는 안정적이고 확장 가능한 아키텍처를 구축하는 데 필수적인 요소입니다.

1.1. Elastic Load Balancer (ELB)

ELB는 "Elastic Load Balancer"의 약자로, 여러 서버(주로 EC2 인스턴스)로 들어오는 트래픽을 자동으로 분산하여 안정적으로 처리하는 서비스입니다.

  • ELB의 역할: 고객의 요청을 ELB가 먼저 받은 다음, 그 트래픽을 여러 대의 EC2 인스턴스에 고루 분배하여 한 서버에 부하가 집중되는 것을 막습니다.
  • 단일 접점(Single Point): ELB는 외부 트래픽을 받는 단 하나의 창구 역할을 합니다. 고객은 이 ELB 주소만 알고 있으면 되고, ELB가 내부적으로 여러 서버에 트래픽을 나눠줍니다.
  • 장애 대응: 만약 여러 EC2 중 하나가 다운되더라도, ELB는 해당 인스턴스로 트래픽을 보내지 않고 나머지 정상적인 인스턴스로만 트래픽을 분산시켜 서비스의 내결함성을 높입니다.
  • ELB와 Auto Scaling: ELB는 외부 트래픽을 분산하는 역할을 하고, Auto Scaling과 연동되어 트래픽이 많아지면 EC2 인스턴스 수를 자동으로 늘려 서비스의 가용성을 확보합니다.
  • AWS의 책임: ELB 자체의 장애는 AWS가 책임지기 때문에, 고객은 ELB가 트래픽을 감당하지 못할 경우 AWS에 책임을 물을 수 있습니다.

📝 시험 예상 문제: ELB의 역할, 특히 트래픽 분산과 **단일 접점(Single Point)**을 통해 가용성을 확보하는 개념을 묻는 문제가 나올 수 있습니다.

1.2. Auto Scaling

Auto Scaling은 워크로드의 수요 변화에 맞춰 EC2 인스턴스의 수를 자동으로 조절하는 서비스입니다.

  • 핵심 목적: 사용량이 적을 때는 서버 수를 줄여 비용을 절감하고, 사용량이 많을 때는 서버 수를 늘려 안정적인 서비스를 제공하는 것입니다.
  • 작동 방식:
    1. 동적 조정 (Dynamic Scaling): CPU 사용률, 네트워크 트래픽 등 특정 지표(Metric)에 따라 실시간으로 인스턴스 수를 조절합니다.
    2. 예측 조정 (Predictive Scaling): 과거 데이터를 기반으로 미래의 트래픽을 예측하여 미리 인스턴스 수를 늘려 놓습니다.
  • 오토 스케일링을 위한 3가지 요소:
    1. Launch Template 또는 Launch Configuration: 어떤 인스턴스(T2.micro, T3.micro 등), 어떤 OS(AMI), 어떤 설정을 사용할지 정의합니다.
    2. Auto Scaling Group: 최소(Minimum), 최대(Maximum), 그리고 원하는(Desired) 인스턴스 수를 설정합니다. 이는 오토 스케일링이 운영할 인스턴스 개수의 범위를 정의합니다.
    3. Policy (정책): 어떤 조건에서 인스턴스 수를 늘리거나 줄일지 규칙을 정의합니다. (예: CPU 사용률이 70%를 넘으면 인스턴스를 하나 추가)

📝 시험 예상 문제: 오토 스케일링의 목적(비용 절감, 가용성)과 오토 스케일링 그룹의 3가지 핵심 요소(템플릿, 그룹, 정책)를 묻는 문제가 자주 출제됩니다.

2. 마이크로서비스와 컨테이너

강의는 현대적인 애플리케이션 아키텍처인 마이크로서비스와 이를 구현하는 컨테이너 개념을 소개합니다.

2.1. 모놀리식 vs. 마이크로서비스

  • 모놀리식(Monolithic):
    • 모든 서비스 구성 요소(프론트엔드, 백엔드, 데이터베이스 등)가 하나의 거대한 서버 안에 통합되어 있는 구조입니다.
    • 장점: 개발 및 배포가 간단합니다.
    • 단점: 한 부분에 장애가 발생하면 전체 서비스가 중단되는 치명적인 문제가 발생합니다.
  • 마이크로서비스(Microservices):
    • 각 서비스 구성 요소를 독립적인 작은 단위로 분리하고, 이들이 API를 통해 서로 통신하는 구조입니다.
    • 장점: 특정 서비스에 장애가 발생해도 전체 시스템에 영향을 주지 않아 안정성이 높습니다. 각 서비스를 독립적으로 개발하고 배포할 수 있어 개발 속도가 빠릅니다.

2.2. 컨테이너

컨테이너는 마이크로서비스를 구현하기 위한 기술로, 가상 서버(EC2)의 자원 낭비 문제를 해결합니다.

  • 가상 머신(VM)의 한계: 하나의 가상 서버(EC2)에 하나의 애플리케이션만 올릴 수 있어 자원 활용도가 낮았습니다.
  • 컨테이너의 장점: 하나의 서버(OS) 위에 여러 개의 애플리케이션을 격리된 컨테이너 형태로 실행할 수 있습니다. 이를 통해 자원을 효율적으로 사용하고 배포 과정을 간소화할 수 있습니다.
  • AWS 컨테이너 서비스:
    • ECS (Elastic Container Service): AWS가 자체적으로 제공하는 도커(Docker) 컨테이너 오케스트레이션 서비스입니다.
    • EKS (Elastic Kubernetes Service): 오픈소스 컨테이너 오케스트레이션 도구인 쿠버네티스(Kubernetes)를 AWS에서 관리해 주는 서비스입니다.
    • 오케스트레이션 서비스의 역할  
      서비스 설명
      Amazon ECS
      (Elastic Container Service)      		 AWS에서 자체적으로 개발한 컨테이너 오케스트레이션 서비스입니다. AWS 환경에 최적화되어 있으며 설정이 비교적 간단합니다.
      Amazon EKS
      (Elastic Kubernetes Service)      		 업계 표준인 Kubernetes를 AWS에서 관리형으로 제공하는 서비스입니다. 복잡한 워크로드 관리나 하이브리드 환경 구성에 유연하지만, 학습 곡선이 더 높을 수 있습니다.
    • 요구사항 오케스트레이션 서비스의 역할 (ECS/EKS)
      수요에 따라 자동 확장/축소 자동 스케일링(Auto Scaling) 기능을 통해 CPU 사용률, 네트워크 트래픽 등 지정된 지표에 따라 실행 중인 컨테이너 인스턴스 수를 자동으로 조절합니다.
      트래픽 기반 시작/중지 서비스(Service) 개념을 사용하여 컨테이너가 항상 필요한 수량만큼 실행되도록 보장하고, 트래픽이 없을 때는 리소스를 줄입니다.
      시스템 상태 모니터링 컨테이너의 상태를 지속적으로 확인하여 비정상적으로 종료되거나 응답하지 않는 컨테이너를 감지하고, 자동으로 새 컨테이너로 교체하여 안정성을 유지합니다.
    • 오케스트레이션 서비스는 컨테이너를 대규모로 운영할 때 필요한 모든 복잡한 관리 작업을 자동화하는 사령탑입니다. 이 서비스가 없으면 수백 개의 컨테이너를 수동으로 관리해야 합니다.

📝 시험 예상 문제: 모놀리식과 마이크로서비스의 차이점, 컨테이너를 사용하는 이유, 그리고 ECS와 EKS의 역할을 묻는 문제가 나올 수 있습니다.

3. 서버리스와 AWS Lambda

**서버리스(Serverless)**는 개발자가 서버를 직접 관리하지 않고 코드만 올리면 되는 컴퓨팅 모델입니다.

  • 서버리스의 의미: "서버가 없다"는 뜻이 아니라, **"개발자(사용자)가 관리할 서버가 없다"**는 뜻입니다. 서버 관리는 모두 AWS가 담당합니다.
  • AWS Lambda:
    • 대표적인 서버리스 서비스로, 코드를 실행할 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행합니다.
    • 이벤트 기반(Event-Driven): 특정 **이벤트(Trigger)**가 발생할 때만 코드가 실행됩니다. (예: S3에 파일이 업로드될 때, DynamoDB에 데이터가 추가될 때 등)
    • 비용 효율성: 코드가 실행된 시간에 대해서만 비용을 지불하므로, 사용하지 않을 때는 비용이 발생하지 않습니다.
    • 제약 사항: Lambda는 최대 15분 안에 실행을 완료해야 하는 제약이 있습니다.
  • 작동 방식:
    1. 개발자가 람다에 코드를 업로드합니다.
    2. S3, SQS, Kinesis 등 **이벤트 소스(Event Source)**에서 이벤트가 발생합니다.
    3. 이벤트에 의해 람다 코드가 **트리거(Trigger)**되어 실행됩니다.

AWS Lambda에서의 책임 분담

서버리스(Serverless)는 고객이 서버 관리에 대한 책임을 지지 않는다는 의미일 뿐, 모든 것을 AWS가 관리한다는 뜻은 아닙니다.

책임 주체 관리 항목 설명
고객 (Customer) ✅ 애플리케이션 코드
(Application Code)		 코드를 작성하고, 버그를 수정하며, 코드가 필요로 하는 라이브러리 및 종속성을 관리해야 합니다.
✅ 데이터 및 보안 코드 내의 데이터 보안, 접근 권한 설정, 함수를 실행하는 IAM 역할 구성 등을 관리합니다.
AWS ✅ 서버, OS, 런타임 환경 물리적 서버, 네트워킹, 운영 체제(OS) 패치, Lambda 함수의 런타임 환경(Node.js, Python 등) 및 그 밖의 인프라를 전적으로 관리합니다.
✅ 자동 확장 및 내구성 트래픽 증가에 따른 함수 인스턴스의 자동 확장(Auto Scaling)과 가용성을 보장합니다.
 

따라서 고객은 인프라 걱정 없이 오직 비즈니스 로직이 담긴 애플리케이션 코드 작성 및 배포에만 집중할 수 있습니다.

📝 시험 예상 문제: 서버리스의 개념과 람다의 특징(이벤트 기반, 관리형 서비스), 그리고 람다의 실행 시간 제약에 대한 문제가 출제될 수 있습니다.

 

실습

https://in-chul-shin.gitbook.io/korea-it-academy/korea-it-academy/lab/aws-08-11-09-03/undefined-1/lab-2/ec2-linux

'Cloud > AWS' 카테고리의 다른 글

[AWS] 데이터베이스 (DynamoDB, RDS)_250825  (0) 2025.09.25
[AWS] VPC와 네트워크 기초, 데이터베이스_250825  (0) 2025.09.25
[AWS] VPC EndPoint_250829  (0) 2025.09.01
AWS 8/20 문제풀이  (0) 2025.08.22
AWS 자격증 구조  (0) 2023.06.23

관련글

티스토리툴바