필터:AWS×

AWS FinOps Agent로 비용 분석 자동화 파이프라인 구축하기

들어가며 AWS를 사용하는 프로젝트에서 비용 관리는 필수적이지만, 매일 콘솔에 접속해서 비용을 확인하고 분석하는 것은 비효율적이다. Farmily 프로젝트를 진행하며 AWS FinOps Agent를 활용해 비용 데이터 수집부터 분석, 리포트 생성, Slack 전송까지 전 과정을 자동화했다. 이 글에서는 FinOps 자동화 파이프라인을 어떻게 구축했는지, 그리고 실제로 어떤 인사이트를 얻을 수 있었는지 공유한다. 1. FinOps 자동화 파이프라인 아키텍처 전체 자동화 흐름은 다음과 같다: AWS 비용 데이터 → FinOps Agent 분석 → HTML 리포트 생성 → Slack 전송 이 흐름을 매일, 매월, 그리고 임계값 초과 시 자동으로 실행하도록 구성했다. 1.1 핵심 구성 요소 FinOps Agent AWS 비용 데이터를 조회하고 분석해서 리포트를 만들어 Slack으로 보내는 AI 에이전트다. 사람이 콘솔에 직접 들어가 확인하던 작업을 완전히 자동화했다. Automations (트리거) 에이전트가 언제 실행될지를 정의하는 자동화 트리거다. 시간 기반(CRON) 2개와 이벤트 기반(COSTANOMALY) 1개, 총 3종으로 구성했다. Memory 리포트 작성 기준을 저장해둔 파일이다. farmilyreportstandards에 다음 항목들이 저장된다: 리포트 11개 섹션 목록 데이터 수집 순서 형식 규칙 (한국어, HTML, 전송 방식) 리포트 (HTML Artifact) 에이전트가 생성하는 결과물이다. AWS Cloudscape 스타일의 인터랙티브 HTML 파일로, Slack에 파일로 첨부되어 전달된다. 2. 자동화 트리거 전략 세 가지 트리거를 통해 상황에 맞는 비용 리포트를 받을 수 있도록 설계했다. 이름 트리거 방식 실행 시점 Farmily Monthly Cost Report CRON 매월 1일 오전 9시 (KST) Daily AWS Cost Report Slack CRON 매일 오전 9시 (KST) Farmily Cost Threshold Slack Alert COSTANOMALY MTD 비용이 $50 단위 초과 시 즉시 2.1 시간 기반 트리거 (CRON) 정해진 시간에 무조건 실행되는 방식이다. EventBridge 스케줄러를 기반으로 하며, UTC 기준이기 때문에 KST(UTC+9)로 변환해서 설정했다. 매일 오전 9시: cron(0 0 ? ) 매월 1일 오전 9시: cron(0 0 1 ? ) 2.2 이벤트 기반 트리거 (COSTANOMALY) 시간과 무관하게 AWS 비용 이상 감지 이벤트가 발생하면 즉시 실행된다. $50 단위 임계값 초과를 감지해 트리거하며, "언제"가 아니라 "무슨 일이 생겼을 때" 동작한다. 예를 들어, 이번 달 누적 비용(MTD)이 $150에서 $200을 넘어가는 순간 자동으로 경고 리포트가 발송된다. 3. 에이전트 실행 흐름 자동화가 트리거되면 다음 단계를 거쳐 리포트가 생성된다. Step 1: 에이전트 실행 트리거가 발생하면 FinOps Agent가 깨어나 Memory에서 리포트 기준(farmilyreportstandards)을 로드한다. Step 2: AWS Cost Explorer API 호출 다음 순서로 비용 데이터를 순차 조회한다: 서비스별 비용 (SERVICE 차원) 리전별 비용 (REGION 차원) USAGETYPE 상세 비용 비용 예측 (Forecast) Step 3: 분석 및 리포트 생성 수집한 데이터를 바탕으로 리포트를 생성한다: 월간: 11개 섹션으로 구성된 종합 HTML 리포트 일간: 핵심 지표 요약 리포트 임계값 초과: 경고 메시지 및 원인 분석 Step 4: Slack 전송 생성된 HTML 파일을 첨부하고 한국어 요약 메시지와 함께 Slack 채널로 전송한다. 4. Memory를 활용한 일관성 유지 자동화 실행 시 에이전트는 이전 대화를 기억하지 못한다. 그래서 "어떤 형식으로 만들어라"는 기준을 Memory 파일에 저장해두면, 매번 실행될 때마다 그 기준을 읽고 동일한 품질의 리포트를 만들 수 있다. 대화에서 기준 확정 → Memory 저장 → 프롬프트에 "Memory 준수" 명시 → 실행 시마다 동일 기준 적용 이를 통해 사람이 직접 지시하지 않아도 자동화가 일관된 품질의 리포트를 생성할 수 있다. 5. 11개 섹션으로 구성된 종합 분석 프롬프트 월간 리포트는 Cloud FinOps 프레임워크를 기반으로 11개 섹션으로 구성된다. 각 섹션은 비용 최적화를 위한 구체적인 인사이트를 제공한다. 섹션 1: 현재 비용 현황 분석 전체 비용 파악 총 누적 비용: 프로젝트 시작부터 현재까지 총 지출 금액 월별 비용 추이: 최근 6개월 월별 지출 그래프 (증가/감소 추세) 일별 평균 비용: 최근 30일 기준 하루 평균 지출 예상 월간 비용: 현재 추세로 이번 달 예상 총액 서비스별 비용 분석 비용 순서대로 모든 AWS 서비스를 나열하고 각 서비스의 총 비용, 전체 비용 대비 비율, 주요 과금 요소, 비용 증가/감소 추세를 분석한다. 특히 EKS, RDS, ALB/NLB, VPC, Lambda, S3, CloudWatch, Route53, Bedrock, ECR 등 주요 서비스를 상세하게 분석한다. 리전별 비용 분석 서울 리전 (apnortheast2): Production 환경 비용 도쿄 리전 (apnortheast1): DR 환경 비용 기타 리전: useast1 (Route53 Health Check 등) 섹션 2: FinOps Big Five 분석 Rightsizing (적정 크기 조정) 컴퓨팅 리소스의 실제 사용률과 프로비저닝을 비교 분석한다. EKS Worker Nodes의 CPU/Memory 평균 사용률, RDS 인스턴스의 CPU/Memory/Connection 사용률, Lambda 함수의 메모리 설정 대비 실제 사용량을 확인한다. 과다 프로비저닝된 리소스는 다운사이징, 부족한 리소스는 업사이징을 제안한다. Scheduling (스케줄링) 상시 운영 중인 리소스를 식별하고 절감 시나리오를 제시한다. DR 환경 Warm Standby를 24/7 운영할지 주간만 운영할지, 개발/테스트 환경을 야간/주말에 중지할 수 있는지, 배치 작업을 스팟 인스턴스로 전환할 수 있는지 검토한다. Pricing Model (요금 모델) 현재 사용 중인 요금 모델을 분석하고 최적화 기회를 제시한다. OnDemand, Reserved Instances, Savings Plans, Spot Instances의 비율을 확인하고, RI/SP 전환 시 절감 효과를 1년/3년 약정으로 비교한다. Storage Tier (스토리지 계층화) S3 스토리지를 분석한다. 버킷별 용량과 접근 빈도를 확인하고, Lifecycle Policy 적용 현황을 점검한다. Standard에서 IA, 그리고 Glacier로 전환할 수 있는 기회를 찾는다. EBS/RDS 스토리지의 경우 gp3와 gp2의 비용을 비교하고, IOPS 프로비저닝 대비 실제 사용량을 확인한다. Monitoring (모니터링 최적화) CloudWatch 비용을 분석한다. 커스텀 지표 개수, 로그 보관 기간, 대시보드/알람 개수를 확인하고 최적 Retention을 제안한다. Container Insights의 필요 여부도 비용 대비 효용성 관점에서 재평가한다. 섹션 3: EKS/Container 비용 심층 분석 Kubernetes 환경의 비용을 Podlevel, Nodelevel, Data Transfer 세 가지 관점에서 분석한다. Podlevel 비용 Namespace별, Deployment별로 비용을 추정한다. farmilyapi, farmilyappai 등의 CPU/Memory Request, Limit, 실제 사용량을 비교하고 Resource Request/Limit 조정을 제안한다. Vertical Pod Autoscaler(VPA) 도입도 검토한다. Nodelevel 비용 서울 Production 환경에서는 Karpenter를 사용하는데, 노드 효율성을 평가하고 인스턴스 타입 믹스(t3, c6i, m6i 등)를 분석한다. Spot과 OnDemand의 비율도 확인한다. 도쿄 DR 환경의 경우 현재 Node Group 1노드(t3.medium)를 24/7 운영 중인데, Fargate Warm Standby로 전환하면 사용 시에만 과금되는 장점이 있다. Data Transfer 비용 인터넷 송신(Transfer Out) 비용과 리전 간 전송 비용을 분석한다. ALB에서 사용자로 가는 트래픽, ECR Pull 트래픽, RDS CrossRegion Replication(서울→도쿄) 등을 확인한다. CloudFront 도입이나 VPC Endpoint를 통한 AWS 서비스 통신으로 Transfer 비용을 절감할 수 있는지 검토한다. 섹션 4: DR 비용 최적화 Farmily는 서울도쿄 간 Warm Standby 전략을 사용 중이다. 현재 DR 전략의 비용을 평가하고 대안을 제시한다. 현재 DR 전략 평가 도쿄 EKS 노드, 도쿄 RDS Replica, 기타 리소스(ALB, 네트워크)의 월 비용을 합산하여 총 DR 비용을 산출한다. 현재 RTO 15분, RPO 1분 목표를 달성하기 위해 Warm Standby가 필요한데, 만약 RTO를 4시간으로 늘릴 수 있다면 Pilot Light로 전환하여 약 70%를 절감할 수 있다. DR 계층별 비용 비교 전략 RTO 월 비용 절감액 비고 Backup & Restore 24시간 $50 $XXX 스냅샷만 Pilot Light 14시간 $200 $XXX RDS만 대기 Warm Standby (현재) 15분 $XXX 1노드 상시 운영 ActiveActive 섹션 5: AI/ML 비용 분석 Bedrock 사용 현황 모델별(Claude, Titan 등) 사용량을 토큰 수로 파악하고, API 호출 빈도를 시간당/일간으로 확인한다. 평균 응답 토큰 수를 Input/Output 비율로 분석한다. 최적화 기회 캐싱 전략으로 반복 질문을 캐싱하거나, Prompt 최적화로 토큰 수를 줄이거나, 저렴한 모델로 전환 가능한 작업을 식별한다. Lambda 함수 비용 farmilyselectphoto, farmilycardrenderer 등의 호출 수와 실행 시간을 분석하고, 메모리 설정 대비 실제 사용량을 확인한다. Provisioned Concurrency의 필요 여부와 메모리 크기 조정을 성능 대비 비용 관점에서 검토한다. 섹션 6: 낭비 요소 탐지 유휴 리소스 Detached 상태의 EBS 볼륨, 미할당 Elastic IP(시간당 과금됨), 오래된 AMI/스냅샷, 빈 S3 버킷, 사용하지 않는 Load Balancer 등을 식별한다. 비정상 패턴 탐지 특정 날짜에 비용이 2배 이상 증가한 구간의 원인을 분석하고, 매주 특정 시간대의 과도한 Lambda 호출 같은 주기적 낭비를 식별한다. 예상보다 높은 Transfer Out은 공격이나 오류 가능성을 의미할 수 있다. 섹션 7: 실행 가능한 권장 사항 각 권장 사항마다 우선순위(High/Medium/Low), 예상 절감액(월간 $), 구현 난이도(쉬움/보통/어려움), 리스크(서비스 영향도), 실행 단계(구체적 작업 목록)를 제공한다. 예시: 권장 사항 1: RDS 인스턴스 다운사이징 우선순위: High 예상 절감: 월 $120 (연 $1,440) 난이도: 쉬움 (10분 작업) 리스크: 낮음 (CPU 사용률 15% → 30%로 증가하지만 여유 충분) 실행 단계: 1. 스냅샷 생성 (백업) 2. db.t3.medium → db.t3.small 변경 3. 1주일 모니터링 4. 성능 이상 없으면 확정 섹션 8: FinOps KPI 제시 비용 효율성 Unit Cost: 사용자 1명당 월 비용 Transaction Cost: API 요청 1만 건당 비용 Cost per Feature: 주요 기능별 비용 배분 최적화 진행도 절감 실현율: (절감 실행액 / 식별된 총 절감 기회) × 100 RI/SP 커버리지: (약정 적용 시간 / 전체 사용 시간) × 100 낭비율: (유휴 리소스 비용 / 총 비용) × 100 목표 설정 낭비율 5% 이하 RI 커버리지 70% 이상 월 비용 증가율 섹션 9: Unit Economics & 비즈니스 가치 비용 대비 가치 CAC(Customer Acquisition Cost), LTV(Lifetime Value), LTV/CAC 비율(3 이상 유지 목표)을 계산한다. 기능별 ROI 각 주요 기능의 비용 대비 비즈니스 기여도를 평가한다. AI 추천 기능은 Bedrock 비용 대비 사용자 참여도 증가로, 실시간 알림은 Lambda + SNS 비용 대비 이탈률 감소로, DR 환경은 Warm Standby 비용 대비 서비스 신뢰도 가치로 측정한다. ROI가 1 미만인 기능은 축소/제거를 검토하고, ROI가 3 이상인 기능은 투자를 확대한다. 섹션 10: 보고서 형식 Executive Summary (경영진용) 총 비용 현황을 1문장으로 요약하고, Top 3 비용 서비스를 각 1줄로 정리한다. 즉시 실행 가능한 절감 방안 Top 3를 총 절감액과 함께 제시한다. Detailed Analysis (실무진용) 서비스별 상세 분석을 표와 그래프로 제공하고, FinOps Big Five 각 항목별 권장 사항을 나열한다. 단계별 실행 계획을 30일/60일/90일로 구분하여 제안한다. Appendix 전체 리소스 목록, 비용 산출 근거, 참고 문서 링크를 첨부한다. 섹션 11: FinOps 운영 프로세스 분석 후 지속적인 운영을 위한 사이클을 제안한다. Inform (알림) 매주 비용 이상 패턴 알림 예산 대비 진행률 Optimize (최적화) 매월 권장 사항 실행 RI/SP 갱신 검토 Operate (운영) 분기별 전체 FinOps 전략 재평가 목표 KPI 조정 6. 리포트 형식을 HTML로 선택한 이유 여러 형식을 비교한 결과, HTML을 선택했다. 형식 특징 텍스트 메시지 간단하지만 표나 차트 표현 불가 PDF 정적이라 인터랙션 없음 HTML 테이블 정렬, 탭 전환, 차트 hover 등 인터랙티브 가능 Slack에 HTML 파일로 첨부하면 팀원들이 다운로드해서 브라우저로 열어볼 수 있다. 데이터를 직접 탐색하면서 필요한 정보를 찾을 수 있다는 점이 큰 장점이다. 7. 실제 리포트 결과 2026년 6월 월간 리포트를 통해 얻은 주요 인사이트다. 비용 현황 6월 총 비용과 전월 대비 증가율 확인 주요 비용 서비스: EKS, RDS, Bedrock 순 즉시 실행 가능한 최적화 기회 1. RDS 다운사이징을 통한 월 절감 2. DR 환경 Pilot Light 전환 검토 3. CloudWatch 로그 보관 기간 조정 FinOps KPI 낭비율, RI 커버리지, 사용자 1명당 월 비용 등의 지표를 대시보드로 확인 8. 임시 리포트 요청 방법 자동화 외에 임시로 리포트가 필요할 때는 에이전트에게 직접 요청하면 된다. "이번 달 리포트 만들어줘" 에이전트가 Memory에서 기준을 읽어 자동화와 동일한 형식으로 만들어준다: "이번 달 리포트 만들어줘" → Memory 로드 → 데이터 수집 → HTML 생성 → Slack 전송 9. 얻은 교훈 성공 요인 Memory를 활용한 일관성 유지 자동화마다 동일한 품질의 리포트를 생성할 수 있었다. 프롬프트 버전 관리도 용이했다. 3가지 트리거 전략 정기 리포트(월간/일간)와 이상 감지를 조합해서 완벽한 커버리지를 확보했다. 비용 급증 시 즉시 대응할 수 있었다. HTML 인터랙티브 리포트 팀원들이 직접 탐색하면서 인사이트를 발견할 수 있었다. 표 정렬, 차트 hover 등의 UX가 큰 도움이 되었다. 마치며 AWS FinOps Agent를 활용한 비용 분석 자동화로 다음과 같은 효과를 얻었다. 먼저 시간을 크게 절감했다. 매일 30분씩 소요되던 비용 확인 작업을 완전히 자동화했다. 인사이트도 향상되었다. 11개 섹션의 체계적 분석을 통해 놓치고 있던 최적화 기회를 발견할 수 있었다. 비용 임계값 초과 시 실시간 알림을 받아 빠르게 대응할 수 있게 되었다. 특히 Cloud FinOps 프레임워크 기반의 체계적인 11개 섹션 분석을 통해 단순 비용 확인을 넘어 실행 가능한 최적화 방안을 도출할 수 있었다. Rightsizing, Scheduling, Pricing Model, Storage Tier, Monitoring 등 FinOps Big Five를 기반으로 한 분석은 놓치기 쉬운 절감 기회를 발견하는 데 큰 도움이 되었다.

Jul 22, 2026AWS

Multi-AZ RDS failover 테스트 검증기 (feat.AWS FIS)

MultiAZ RDS failover 테스트 검증기 (feat.AWS FIS) AWS FIS로 운영 DB에 강제 failover를 일으켜, "MultiAZ가 정말 장애를 견디는가"를 숫자로 확인한 기록. 결론부터: DB는 15초 만에 살아났는데, 앱은 15분 동안 못 붙었다. 들어가며 RDS를 MultiAZ로 켜두면 한 가용영역(AZ)이 죽어도 다른 AZ가 받아준다고 한다. 콘솔에서 체크박스 하나 켜는 걸로 "장애 대응 완료"라고 믿기 쉽다. 그런데 정말 그런가? 켜 두는 것과 실제로 견디는 것은 다른 이야기다. 그래서 직접 깨뜨려보기로 했다. AWS FIS(Fault Injection Simulator)로 운영 중인 RDS Primary를 강제로 재부팅시켜 failover를 일으키고, 그 과정을 Grafana로 초 단위로 관측했다. 두 번에 걸쳐 진행했는데, 1차에서 예상 못 한 게 터졌고 2차에서 그 원인을 끝까지 파고들었다. 이 글의 한 문장 요약은 이거다 — DB 가용성과 서비스 가용성은 같은 숫자가 아니다. 0. 먼저 개념부터 본문에 계속 나오는 용어 다섯 개만 잡고 가자. FIS (Fault Injection Simulator) — AWS의 장애 주입 도구. "이 자원에 이런 장애를 일으켜라"를 템플릿으로 정의해 일부러 장애를 내고 시스템 반응을 관측한다. 카오스 엔지니어링의 실행 도구다. MultiAZ Failover — RDS를 두 AZ에 Primary·Standby로 이중화한 구성. Primary가 죽으면 다른 AZ의 Standby가 새 Primary로 승격된다. 평소 동기 복제라 데이터 손실이 없다. RTO (Recovery Time Objective) — 장애부터 복구까지 허용하는 목표 시간. 어느 계층을 기준으로 재느냐(DB냐 앱이냐)에 따라 값이 완전히 달라진다 — 이 글의 핵심. HikariCP (커넥션 풀) — Spring Boot 기본 DB 커넥션 풀. 요청마다 연결을 새로 만들지 않고 미리 만든 연결을 재사용한다. failover로 Primary가 바뀌면 풀에 있던 연결은 옛 Primary를 바라보는 죽은 연결이 된다. 이걸 얼마나 빨리 버리고 새로 만드냐가 앱 복구 속도를 가른다. warm pool — 방금 새 연결로 통째로 갈려서 전부 "신선한" 상태의 풀. 반대는 오래 묵은 연결로 찬 cold pool. (뒤에서 함정으로 다시 등장한다.) 1. 무엇을 테스트했나 구성 내용 대상 DB prodrds · PostgreSQL 18.3 · db.t3.small · MultiAZ = true 앱 계층 ECS · Spring Boot · HikariCP 트래픽 ALB → Target Group → ECS 안전장치 Stop Condition = CloudWatch 5xx 알람 관측 Grafana(AMG) + RDS Recent events 합격 기준은 세 가지로 잡았다. 1. DB RTO Primary(2c)가 재부팅되면 Standby(2a)가 새 Primary로 승격된다. 문제는 오른쪽 — DB는 2a로 옮겨갔는데 앱의 커넥션 풀은 여전히 옛 Primary(2c)를 붙들고 있다. 2. 1차: 일단은 평온했다, 5xx가 터지기 전까진 FIS 액션 aws:rds:rebootdbinstances에 forceFailover=true를 줘서 Primary를 강제로 재부팅했다. "Primary가 갑자기 죽는" 상황을 인위적으로 만든 것이다. 시작 직전 대시보드는 모든 게 정상이었다. DB 커넥션 10개 안정, 5xx 0건, p99 10.7ms. 그림 1. 1차 — 시작 전 정상 기준선. DB 커넥션 10 · 정상 타깃 1 · 앱 5xx 0 · p99 10.7ms · DB CPU 3.99%. 이후 그림과 비교할 'before' 상태. 그림 2. 1차 — 장애 직전 상세. 요청 수·활성 커넥션·ECS 태스크 running 1 · Failover 5xx 누적 0. 아직 모든 지표 정상. 그런데 failover를 건 직후, 5xx가 폭증하기 시작했다. 그림 3. 1차 — 장애 정점. 요청 1.5K 스파이크, Failover 5xx 누적 280건(대부분 앱 target 5xx). DB와 ECS는 멀쩡히 살아있는데(태스크 running 1) 앱이 DB에 못 붙어 5xx가 터졌다. 이 한 장이 'DB 가용 ≠ 서비스 가용'을 그대로 보여준다. 이상했다. DB CPU도, 메모리도, ECS 태스크도 전부 건강했다. 그런데 앱은 5xx를 쏟아냈다. 전환 구간을 들여다보니 DB 커넥션이 10에서 5로 빠지고 p99가 396ms까지 치솟았다. 그림 4. 1차 — 전환 중. DB 커넥션 10→5 감소, 읽기/쓰기 지연 스파이크와 함께 p99가 396ms(p50/p99 패널은 2초까지)로 상승. 앱이 옛 Primary의 죽은 커넥션을 붙들고 새 Primary로 못 옮겨가는 구간. 그리고 한참 뒤에야 앱이 회복됐다. 그림 5. 1차 — 종료 후 회복. DB 커넥션 0→10 복귀, p99가 30초(커넥션 대기 천장)를 찍었다가 5.02ms로 정상화. 5xx 막대는 16:0316:04에 잡힌다. DB는 진작(15:50) 복구됐는데 앱 재연결은 16:05. 체감 RTO ≈ 15분의 끝. 정리하면 1차의 숫자는 이렇게 갈렸다. 지표 값 DB RTO (인프라) 약 1분 — 왜 1차가 실패했나? failover 직후 RDS가 Standby를 다시 동기화(재동기화)하는 시간을 기다리지 않고 곧바로 다시 실행했기 때문이다. 이게 2차에서 검증할 가설이 됐다. 3. 2차: 이번엔 기다렸다, 그리고 회복을 관측했다 2차는 단 하나만 바꿨다 — failover 후 RDS 동기화가 완료될 때까지 기다렸다가 다음 회차를 실행했다. 설정은 한 줄도 안 건드렸다. 그렇게 18:45 / 18:56 / 19:16, 세 번 깨끗하게 때렸다. 구분 1차 2차 실행 방식 동기화 완료 전 곧바로 재실행 동기화 완료까지 대기 후 실행 실행 횟수 2회 3회 결과 실패 — 전환 도중 앱 오류 폭증 정상 — 매 회차 깨끗하게 전환·관측 매 회차 깨끗하게 전환됐다. DB 연결 수 그래프를 보면 failover 시점에 커넥션이 잠깐 푹 꺼졌다가 다시 차오르는 게 그대로 보인다. 그림 6. 2차 1회차(18:45) — p99 2.21ms · DB CPU 5.02% · 정상 타깃 1. DB 연결 30 → failover 시점 일시 감소 → 30 복귀. 동기화 완료를 기다린 뒤 실행하니 깨끗이 전환됐다. 그림 7. 2차 2회차(18:56) — p99 2.39ms · DB CPU 5.41%. 같은 패턴이지만 앱 커넥션 풀 회복이 약 2분으로 빨라졌다. 그림 8. 2차 3회차(19:16) — p99 2.62ms. 읽기/쓰기 지연 스파이크가 짧게 여러 번 났다 회복. 요청 700 스파이크도 잠깐 보인다 — 요청 스레드가 죽은 커넥션을 즉시 일괄 폐기해 앱 회복이 약 20초까지 빨라졌다. DB 자체 복구는 RDS 이벤트 로그로 실측했다. 그림 9. 2차 — RDS Recent events. 18:45·18:56·19:16 세 번 모두 MultiAZ failover started → DB instance restarted → failover completed. DB 자체 복구 15초·전체 3045초의 실측 근거. (위 6/11 23:03·23:07은 정기 백업.) [2차 — RDS MultiAZ failover events] 1회차 18:45:02 started → 18:45:18 restarted → 18:45:31 completed (AZ 2c→2a) 2회차 18:56:17 started → 18:56:32 restarted → 18:57:01 completed (AZ 2a→2c) 3회차 19:16:27 started → 19:16:42 restarted → 19:17:01 completed (AZ 2c→2a) 3회 측정을 표로 모으면 이렇다. 지표 1회차 2회차 3회차 평균 DB 자체 복구 16초 15초 15초 15.3초 전체 완료 30초 45초 35초 36.7초 앱 커넥션 풀 복구 5분 2분 20초 — ECS 태스크 교체 없음 없음 없음 — 여기서 눈에 띄는 줄이 앱 커넥션 풀 복구: 5분 → 2분 → 20초다. 설정은 동일했는데 왜 점점 빨라졌을까? 4. 핵심 분석 — DB는 15초, 앱은 15분, 그 사이 14분의 사각 같은 failover 한 번을 두 계층이 전혀 다른 시간으로 겪었다. 그림으로 보면 이렇다. 시간축 0 15초 15분 │ │ │ DB 계층 ──────● (복구 15초) │ 앱 계층 ──────○━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━● failover ↑ DB는 살아있으나 앱이 못 붙는 구간 ≈ 14분 ↑ 앱 복구 '가용성'을 DB 한 층으로만 재면 저 가운데 14분이 통째로 가려진다. 사용자가 실제로 겪는 시간은 가장 느린 계층, 즉 앱이 결정한다. 왜 앱이 늦게 붙었나 — HikariCP의 죽은 커넥션 failover로 Primary가 바뀌면, 풀 안의 연결들은 전부 옛 Primary를 향하는 죽은 연결이 된다. 문제는 이 죽은 연결을 언제 감지해서 새 연결로 갈아끼우느냐다. 1회차 (5분) — 죽은 커넥션 감지 후, housekeeper 스레드가 10초에 1개씩 검증·폐기했다. 풀 20개를 다 갈아끼우는 데 5분. 로그엔 'Thread starvation or clock leap detected'가 동반됐다. 2회차 (2분) — 같은 패턴이지만, 직전에 한 번 갈린 풀이라 수명 짧은 연결이 섞여 더 빨리 교체됐다. 3회차 (20초) — 요청 스레드가 즉시 감지해 0.5초 안에 풀 전체를 일괄 폐기했다(housekeeper 10초 대기 없이). 단, 직후 새 연결 생성이 몰리며 'request timed out after 30000ms'가 짧게 났다 정상화됐다. 회차가 빨라진 건 '개선'이 아니다 — warm pool 함정 여기가 제일 중요하다. 5분 → 20초는 내가 뭘 고쳐서가 아니다. 한 번 failover를 겪으면 풀이 통째로 새 연결로 갈린다. 그 직후 회차는 "방금 만들어 수명이 거의 0인" 신선한 연결만 남은 상태(warm pool)가 되고, 그 덕에 우연히 빨라진 것뿐이다. 문제는 실제 운영 failover는 며칠몇 주 멀쩡히 돌던 cold pool에서 딱 한 번 터진다는 것. 즉 현실은 늘 '1회차(5분)' 상황이지 2·3회차(빠름)가 아니다. 첫 회차가 5분이나 걸린 직접 원인은 maxLifetime 기본값이 30분이라 housekeeper가 죽은 연결을 천천히 교체했기 때문이다. 참고로 "warm pool"은 EC2 Auto Scaling의 Warm Pools와는 완전히 다른 개념이다. 여기선 "커넥션 풀이 한 번 갈려서 신선해진 상태"를 가리킨다. 5. 판정과 개선 과제 AWS 기대치 대비로 보면 인프라는 전부 통과, 앱만 숙제로 남았다. 지표 결과 AWS 기대치 판정 :: DB 자체 복구 1516초 30초 이내 양호 전체 Failover 완료 3045초 60초 이내 양호 데이터 손실 없음 (동기복제) 무손실 양호 ECS 태스크 생존 전 회차 교체 없음 — 양호 앱 에러 구간 최대 5분 · 체감 15분(1차) — 개선 필요 개선 1순위는 HikariCP 튜닝이다. 조치 기대 효과 :: 1 maxlifetime = 60000 (60초) 커넥션 수명 단축 → failover 시 빠른 교체 2 connectiontimeout = 5000 (5초) 새 연결 실패 시 빠른 에러 반환 3 keepalivetime = 30000 (30초) 주기적 alive 체크 → 죽은 연결 조기 발견 4 validationtimeout = 3000 (3초) validate 빠른 실패 처리 5 ECS min 태스크 2개 이상 1개가 죽어도 다른 태스크가 커버 그 외에 1차에서 도출한 개선들: Deep health check — ALB 헬스체크가 DB 연결까지 점검하게. Healthy=1 맹점을 없애 죽은 경로로 트래픽 보내는 걸 차단. 알람 기준 보강 — Healthy 수가 아니라 5xx·DB 활성 커넥션 수 기준으로. FIS 템플릿에 aws:fis:wait 추가 — reboot는 13초 fireandexit라 정작 장애 구간엔 실험이 끝나 Stop Condition이 무력화된다. wait로 실험 수명을 복구 구간까지 늘려야 한다. 마치며 이 실험의 목적은 "MultiAZ가 장애를 견디는가"를 추측이 아니라 숫자로 확인하는 것이었고, 결과는 두 계층으로 뚜렷이 갈렸다. 검증된 것 — MultiAZ failover 메커니즘 자체는 정상이다. DB 복구 1516초, 데이터 무손실, AZ 자동 전환, ECS 태스크 생존. 인프라 회복력은 합격. 발견한 것 — 서비스 RTO를 좌우하는 건 DB가 아니라 앱이었다. HikariCP가 죽은 연결을 늦게 교체해 1차 체감 복구가 15분, 5xx 280건. 그 와중에 ALB 헬스체크는 DB 단절을 못 봤다. 운영 교훈 — failover 직후 RDS 재동기화가 끝나기 전에 재실행하면 안 된다(1차 실패 원인). 그리고 풀 회복이 빨라 보인 건 warm pool 효과일 뿐, 실제 운영은 늘 '5분' 상황이라 튜닝이 전제다. 가장 크게 남은 한 줄은 이거다. 서비스 가용성은 가장 빠른 계층이 아니라 가장 느린 계층이 결정한다. DB가 15초 만에 살아나도 앱이 14분을 못 붙으면, 사용자에게 그 서비스는 14분간 죽어 있던 것이다. 'MultiAZ를 켜 두는 것'과 '장애를 실제로 견디는 것'의 차이가 바로 여기에 있다. 이게 카오스 엔지니어링을 직접 해보기 전엔 안 보이던 사각지대였다. 체크박스를 켜는 것과, 깨뜨려서 숫자를 보는 것은 정말로 달랐다.

Jun 18, 2026AWS

SAA 공부하며 끄적이는 개념들,,

S3 Presigned URL 업로드(대규모 사용자 파일 업로드 적합) 웹 서버/EC2가 파일을 직접 받지 않게 하고 애플리케이션은 업로드 권한이 있는 Presigned URL만 발급 Storage Gateway File Gateway 온프레미스에서 S3를 로컬 파일 서버처럼 사용하게 해주는 서비스 S3 Glacier Deep Archive 이 스토리지 클래스는 규정 준수 요구 사항을 충족하기 위해 데이터세트를 수년 동안 보존하도록 설계되었으며, 백업이나 재해 복구 또는 검색하는데 최대 72시간까지 기다려도 되는 자주 액세스하지 않는 데이터에도 사용할 수 있다. S3 Glacier Instant Retrieve 의료 의미지, 뉴스 미디어, 유전체학 등 즉각적 접근이 필요한 아카이브 데이터에 적합하다. S3 Glacier Flexible Retrieve 즉각적 접근은 필요없지만 백업, 재해복구 등 대용량 데이터 세트를 몇분 12시간 내 검색 무료 제공 S3 Intelligent Tiering 액세스 빈도, 불규칙한 사용 패턴 모를 때 사용 가능, 다양한 액세스 패턴에 적합 S3 Standard 자주 접근하는 범용 스토리지 S3 StandardInfrequent Access(S3 StandardIA) 가끔 Access 하지만 가끔할 때 즉각적 접근 필요 시 적합 S3 One ZoneInfrequent Access 하나의 지역에만 사용 가능한 S3 클래스 단일 AWS 가용 영역에 데이터를 저장하기 때문에 스토리지 클래스에 저장된 데이터는 가용성 영역이 파괴되는 경우 손실 AWS Transfer Family SFTP, FTPS, FTP 및 AS2 프로토콜을 사용하여 Amazon S3, Amazon EFS로 파일을 전송할 수 있게 하는 서비스 AWS FSx 클라우드에서 다양한 파일 시스템을 제공하는 완전 관리형 서비스 사용자는 고성능 파일 시스템을 쉽게 설정, 관리 및 운영할 수 있으며 윈도우 파일서버, Lustre, NetApp ONTAP, OpenZFS와 같은 다양한 파일 시스템 옵션을 선택할 수 있다. 온프레미스 환경과 클라우드 환경을 연결하여 하이브리드 클라우드 스토리지 솔루션 AWS FSx for NetApp OnTAP NetApp의 인기있는 OnTAP 파일 시스템에 구축된 매우 안정적이고 확장 가능하며 성능이 뛰어나고 기능이 풍부한 파일 스토리지를 제공하는 완전관리형 서비스 데이터 센터에 클라우드의 간소성과 유연성을 제공하고 데이터 센터의 모든 엔터프라이즈 기능을 퍼블릭 클라우드에 제공 AWS EC2 배치 그룹 종류 클러스터 배치 그룹 단일 가용 영역 내에 있는 인스턴스의 논리적 그룹(인스턴스는 단일 랙에 격리되지 않음) 파티션 배치 그룹 애플리케이션에 대한 상관 관계가 있는 하드웨어 장애 가능성을 줄이는 데 도움 파티션 배치 그룹을 사용하는 경우 Amazon EC2는 각 그룹을 파티션이라고 하는 논리 세그먼트로 나눈다. 각 랙은 자체 네트워크 및 전원이 있다. 배치 그룹 내 두 파티션이 동일한 랙을 공유하지 않으므로 애플리케이션 내 하드웨어 장애의 영향을 격리 분산형 배치 그룹 각각 고유한 하드웨어에 배치된 인스턴스 그룹 인스턴스가 동일한 장비를 공유할 때 장애가 동시에 발생할 수 있는 위험이 줄어듦 Spot 인스턴스 AWS의 남는 EC2 자원을 매우 싸게 빌려주는 방식(최대 90% 할인) 대신 AWS가 필요하면 갑자기 회수할 수 있음(보통 2분 전 알림 제공) Batch Job 작업에 적합 실패하면 다른 인스턴스가 다시 처리(중단 허용 가능) EC2 Spot Fleet 여러 Spot Intance 요청을 관리하고 지정된 목표 용량을 충족시키기 위해 여러 인스턴스 유형과 가용 영역을 활용하여 비용을 최적화하는 서비스 스팟 인스턴스 풀에서 사용 가능한 인스턴스를 검색하여 목표 용량을 자동으로 채우고 필요에 따라 인스턴스 유형과 가용 영역을 변경하여 비용을 절감하고 애플리케이션의 가용성을 높일 수 있음 DR Options Backup & Restore ($) 느림(시간 단위, Hours) 단순 데이터 백업 Pilot Light ($$) 중간(십분 단위, 약 10분 90분), DB만 동기화 Warm Standby($$$) 빠름(분 단위, 약 5분 15분), DB 동기화 + APP은 낮은 스펙으로 대기 MultiSite($$$$) 아주 빠름(거의 실시간), DB 동기화 + 같은 스펙의 APP 구성 Network AWS Global Accelerator 트래픽 관리를 간소화하고 성능을 최대 60% 개선하는 네트워킹 서비스 AWS Shield와 통합되어 DDoS 공격으로부터 애플리케이션을 보호, 애플리케이션 상태, 사용자 위치 및 고객이 구성하는 정책의 변경에 즉각적으로 대응하여 항상 성능에 기반한 최적의 엔드포인트로 사용자 트래픽을 라우팅 고정/정적 IP 주소 또는 빠른 지역 장애 조치에 필요한 HTTP 사용 사례에 적합 전 세계 사용자가 AWS 애플리케이션에 더 빠르고 안정적으로 접속하도록 AWS 글로벌 네트워크로 우회시켜주는 서비스 ALB, NLB, EC2, Elastic IP 앞에는 붙이나 S3에 직접 접근은 하지 않는다. 항목 CloudFront Global Accelerator 역할 CDN 네트워크 가속 캐싱 O X 정적 콘텐츠 강함 약함 TCP/UDP 최적화 일부 매우 강함 게임/실시간 앱 보통 강함 CloudFront 파일을 가까운 곳에 캐시 Global Accelerator 네트워크 경로 자체를 최적화 VPC Endpoint Endpoint 유형 중 하나 VPC Endpoint를 사용하면 VPC 내부 또는 외부에 있는 AWS 서비스들과 통신할 때 인터넷 통신이 되지 않더라도 Private한 통신 환경을 통해 서비스에 접근 NLB 데이터를 전송하는 지연 시간을 최소화하고 다른 AWS 영역으로 신속하게 페일오버해야 하는 요구 사항을 충족 TCP/UDP 트래픽을 처리하며 네트워크 계층에서의 로드 밸런싱 ALB 주로 HTTP/HTTPS 트래픽을 처리하는 데 사용되며 애플리케이션 계층에서의 로드 밸런싱을 제공 오토 스케일링 그룹을 함께 사용하여 애플리케이션의 트래픽 변화에 따라 자동으로 서버 인스턴스 수를 조정 AWS VPC Lattice 다양한 AWS 서비스와 리소스 간의 연결, 보안, 모니터링을 중앙 집중식으로 관리할 수 있도록 지원하는 완전 관리형 애플리케이션 네트워킹 서비스 VPC Lattice를 사용하면 복잡한 네트워크 구성 없이도 서비스 간 통신을 간소화하고 보안 정책을 일관되게 적용하며 트래픽 흐름을 효율적으로 관리 AWS Elastic Fabric Adapter(EFA) Amzon EC2 인스턴스에 연결하여 고성능 컴퓨팅(HPC) 및 기계 학습(ML) 워크로드를 가속화하는 고급 네트워크 인터페이스 EFA는 노드 간 통신을 향상시켜 클라우드에서 대규모 애플리케이션을 실행할 수 있도록 지원하며, 특히 HPC 및 ML 작업에서 성능 향상을 제공한다 AWS Transit Gateway 여러 VPC와 온프레미스를 중앙 허브로 연결하는 서비스 VPC Peering 단점 해결 암호화 제공x AWS PrivateLink PrivateLink는 AWS 내의 VPC와 서비스를 연결하는 데 사용되지만 온프레미스 데이터 센터를 AWS에 연결하도록 설계되지 않았다. DB & Data AWS RDS 데이터 베이스 인프라 및 업데이트들을 AWS 측에서 관리해주고 데이터베이스의 설치, 운영 그리고 관리 등의 서비스들을 지원하는 AWS 관계형 데이터베이스 RDS Proxy 데이터베이스의 연결 관리를 위한 메모리 및 CPU 오버헤드를 줄이며 성능 개선, 예기치 않은 트래픽 급증 처리 Amazon RDS 유휴 암호화 데이터베이스 인스턴스, 자동 백업, 읽기 전용 복제본, 스냅샷 등 저장된 데이터를 보호 AWS는 기본 스토리지와 백업 데이터를 AES256 암호화 알고리즘을 사용하여 암호화 Amazon RDS Custom 기본 OS 및 DB 환경에 액세스할 필요가 있는 레거시, 사용자 지정, 패키지 애플리케이션을 위한 관리형 데이터베이스 서비스 AWS SCT(Schema Conversion Tool) 소스 데이터베이스의 데이터베이스 스키마를 대상 Amazon RDS 인스턴스와 호환되는 형식으로 자동으로 변환하는 프로젝트 기반 사용자 인터페이스를 제공 Amazon Aurora MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진 (읽기 전용)자동으로 3개의 AZ에 6개의 복제본 생성( DynamoDB 서버리스 기반 KeyValue NoSQL 데이터베이스 용량에 맞게 테이블을 자동으로 조정하므로 별로 관리하지 않아도 성능 유지, 주문형 백업 기능 제공(보관을 위해서 특정 시점 백업 및 복구, 단 35일로 제한) 온디맨드 용량 모드(주문형 모드) 이전에 관찰된 트래픽 수준까지 상승/하락 시 워크로드 즉시 수용 가능. 읽기/쓰기 용량 모드 있음 트래픽에 따라 자동 확장하고 앱에서 읽기/쓰기 요청에 대해서만 비용 지불, 용량 계획 없이 요청 당 지불가격 제공 변동성이 큰 트래픽 프로비저닝 모드 애플리케이션에서 필요한 초당 읽기/쓰기 횟수 미리 지정 AutoScaling 사용하여 변경에 따라 용량 자동 조정 가능. 예측 가능한 트래픽 GSI(Global Secondary Index) 기본 테이블과 다른 파티션 키와 정렬 키를 사용하여 데이터를 조회할 수 있는 인덱스 GSI를 사용하면 기본 테이블의 파티션 키와 정렬된 키와는 다른 기준으로 데이터를 검색할 수 있어 다양한 쿼리 패턴을 지원 빠르지만 자유로운 검색에 약한 DynamoDB의 보완 DynamoDB와 DAX(DynamoDB Accelerator)가 결합되면 한 단계 업그레이드하여 읽기 중심의 워크로드에서 초당 수백만 개의 요청에도 마이크로초의 응답 시간을 지원 + 인메모리 캐시 DynamoDB TTL(Time to Live) 항목별 타임스탬프를 정의하여 더 이상 필요하지 않은 시기를 결졍 지정된 타임스탬프의 날짜 및 시간 직후 DynamoDB는 쓰기 처리량을 소모하지 않고 테이블에서 항목을 삭제 DynamoDB Global Tables MultiRegion, MultiActive 구조 모든 리전에서 읽기, 쓰기 가능 여러 리전에서 데이터를 실시간으로 복제하며 사용자 요청에 빠르게 대응할 수 있음 낮은 지연 시간 보장 AWS PITR(PointinTime Recovery) 특정시점복구 AWS 서비스에서 제공하는 백업 및 복구 기능으로 데이터베이스를 특정 시점으로 복원 Amazon Athena 표준 SQL을 사용해 S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스 Amazon Athena Federated Query 데이터 분석가가 서로 다른 데이터 소스에 저장된 데이터를 단일 SQL 쿼리를 통해 분석할 수 있게 해주는 기능 S3, RDS, DynamoDB 등 다양한 데이터 소스를 마치 하나의 데이터 웨어하우스처럼 쿼리할 수 있도록 함 AWS Kinesis 실시간 스트리밍 데이터를 수집, 분석, 처리하는 서비스 Kinesis Data Streams 수집 & 전송 대규모의 애플리케이션의 로그, IoT 디바이스의 데이터 등 스트리밍 데이터를 실시간으로 수집하는 서비스 수집한 데이터는 다른 AWS 서비스 또는 애플리케이션에서 사용되어 분석처리 기본 보존 시간은 24시간이며 최대 8760시간(365일)까지 연장 Kinesis Data Firehose 실시간 스트리밍 데이터를 안정적으로 받은 후 필요한 경우 변환하여 다른 AWS의 서비스로 전달하는 서비스 Lambda 함수를 호출하여 데이터 변환 후 전송 가능 Kinesis Data Analytics SQL/Apache Flink로 데이터 스트림 분석 Kinesis Video Streams 비디오 스트림 수집, 저장 및 처리 Amazon MSK(Managed Streams for Apache Kafka) Apache Kafka를 사용하여 스트리밍 데이터를 처리하는 애플리케이션을 빌드하고 실행할 수 있는 완전관리형 서비스 Amazon Redshift 클라우드에서 완전히 관리되는 페타바이트급 데이터 웨어하우스 서비스, 지정시간동안 앱 비활성화일 때 분석 서버, 클라이언트 측 암호화 지원 AWS Glue 사용자가 여러 소스의 데이터를 쉽게 검색, 준비, 이동, 통합할 수 있도록 하는 서버리스 데이터 통합 서비스(JDBC 커넥터를 통해 특정 데이터베이스 연결을 지원) Athena에서 쿼리 가능한 Parquet 파일을 쓸 수 있음 AWS Glue DataBrew 코딩 없이 데이터를 정리하고 정규화하여 분석 및 기계 학습(ML)에 적합하게 준비할 수 있도록 도와주는 시각적 데이터 준비 도구 데이터 분석 및 ML 전에 데이터를 쉽게 처리하고 정제할 수 있도록 지원 DataBrew를 사용하면 데이터 준비 시간을 최대 80%까지 단축 AWS Lake Formation S3의 기본 데이터가 있는 데이터베이스, 테이블 및 열과 같은 데이터 카탈로그 리소스에 대한 액세스 권한을 부여하거나 취소 가능 서비스 Amazon AppFlow Salesforce, SAP, Zendesk, Slack 및 ServiceNow 같은 SaaS와 S3/Amazon Redshift 사이 데이터를 안전하게 전송할 수 있는 완전 관리형 통합 서비스 Amazon ElastiCache 더 느린 디스크 기반 데이터베이스에 전적으로 의존하기 보다는 신속한 관리형 인 메모리 시스템에서 정보를 검색할 수 있는 기능을 지원함으로써 웹 애플리케이션의 성능을 향상 + 분산세션 데이터 관리 인터넷 규모의 실시간 애플리케이션을 지원 도입을 위해선 아키텍쳐 변경이 필요 Amazon Neptune AWS에서 제공하는 완전 관리형 그래프 데이터베이스 서비스 고도로 연결된 데이터셋을 효율적으로 저장하고 쿼리할 수 있도록 설계되었으며 주로 소셜 네트워킹, 추천 엔진, 지식 그래프, 생명과학 연구 등의 분야에서 활용 AWS Neptune Streams Amazon Neptune 그래프 데이터베이스의 변경 사항을 실시간으로 캡처하고 처리할 수 있는 기능. 이를 통해 데이터베이스의 변경 사항을 다른 시스템으로 복제하거나 변경 내용을 기반으로 새로운 로직을 트리거하는 등 다양한 작업을 수행 AWS Quantum Ledger Database(Amazon QLDB) 투명하고 변경 불가능하며 암호화 방식으로 검증 가능한 트랜잭션 로그를 제공하는 완전 관리형 원장 데이터베이스 AWS Lustre 고성능 병렬 파일 시스템인 Lustre를 기반으로 하는 Amazon FSx for Lustre 서비스 대규모 컴퓨팅 워크로드에서 높은 처리량과 낮은 지연 시간을 제공하며 AWS 클라우드에서 사용하기 쉽도록 완전 관리형으로 제공. 특히 머신 러닝, 고성능 컴퓨팅(HPC), 미디어 처리 등 데이터 집약적인 작업에 적합 Security AWS Secrets Manager 자격증명 저장 및 관리 서비스 AWS Console이나 AWS CLI(Bastion 호스트처럼)를 통해 EC2 인스턴스에 안전하게 로그인할 수 있는 기능 DB 비밀번호, API Key, 인증 정보 같은 Secret 관리 전용 서비스 AWS Secrets Manager Auto Rotate(자동회전) 보안 암호의 만료 시점을 자동으로 관리하고 주기적으로 암호를 교체하여 보안을 강화하는 기능 Amazon Cognito 웹 및 모바일 앱을 위한 자격 증명 플랫폼 OAuth 2.0 액세스 토큰 및 AWS 보안 인증을 위한 사용자 디렉터리, 인증 서버, 인증 서비스 Amazon GuardDuty 계정보호 서비스 AWS 계정 및 워크로드에서 악의적 활동 모니터링하고 상세 보안 결과 제공 위협 탐지 서비스 Amazon Inspector 취약점 스캔 서비스 Amazon Shield advance 정교한 대규모 DDoS 공격에 대한 보호 및 완화 실시간 가까운 가시성 EC2, ELB, CloudFront, Global Accelerator, Route 53 요금 보호 제공 Amazon Macle 민감한 데이터를 검색, 모니터링 및 보호하는데 도움이 되는 관리형 데이터 보안 서비스 Amazon Firewall Manager 여러 AWS 계정과 리전에서 방화벽 규칙을 중앙에서 관리할 수 있도록 하는 보안 서비스 AWS WAF용 관리형 규칙과 통합되므로 사전에 구성된 WAF 규칙을 애플리케이션에 손쉽게 배포 AWS KMS(Key Management Service) 클라우드 환경에서 데이터를 보호하기 위한 AWS의 암호화 키 관리 서비스 KMS는 암호화 키를 안전하게 생성, 저장, 관리하고 이를 사용하여 AWS 서비스와 애플리케이션에서 데이터를 암호화하거나 복호화할 수 있도록 지원 고객 관리형 키(CMK) 사용자가 생성, 소유, 관리하는 키로 키, 정책, 키 사용 권한 등을 사용자가 직접 설정 AWS 관리형 키 AWS가 관리하는 키로 사용자는 키 정책을 설정할 수 없지만 키 사용 권한을 제어 S3 버킷에 저장된 중요한 데이터를 암호화할 때 사용자는 AWS 관리형 키 대신 CMK를 사용하여 데이터에 대한 통제력을 높일 수 있다. AWS Security Token Service(STS) AWS 리소스에 접근하기 위한 임시 보안 자격 증명을 발급하는 서비스 기존 IAM 사용자나 역할에 대한 접근 권한을 일시적으로 부여하여 특정 작업이나 리소스에 대한 액세스를 제어 SAML 호환성 없이도 기존 LDAP 디렉터리 서비스를 사용하여 AWS Management Console에 사용자를 인증 Monitoring Amazon QuickSight PostgreSQL용 Amazon S3 / RDS 비롯한 다양한 데이터 소스에서 대화형 대시보드 및 보고서 생성하는 데이터 시각화 서비스 AWS CloudTrail 사용자가 활동 및 API 사용 추적하여 감사, 보안 모니터링 및 운영 문제 해결 AWS Config 리소스 구성 사항 변경 추적 규칙 생성으로 EBS 볼륨의 암호화 여부 확인 후 암호화되지 않은 볼륨에 플래그 지정 가능 Amazon Workload Discovery AWS 클라우드 워크로드를 시각화하여 아키텍처 다이어그램으로 자동 생성해주는 솔루션 AWS 환경에서 실행되는 애플리케이션 및 서비스들의 구조를 자동으로 파악하고 시각적으로 보여주는 도구 AWS 비용 및 사용 보고서 쿼리, 리소스 검색, 아키텍처 다이어그램 저장 및 내보내기 등을 수행 AWS XRay 애플리케이션이 처리하는 요청에 대한 데이터를 수집하고 해당 데이터를 보고, 필터링하고, 인사이트를 얻어 문제와 최적화 기회를 식별하는 데 사용할 수 있는 도구를 제공하는 서비스 애플리케이션의 동작에 관한 데이터를 수집/분석하는 서비스 XRay는 특히 트러블슈팅의 목적으로 이용 AWS Step Functions 실시간 진단 및 대시보드를 제공하고 Amazon CloudWatch 및 AWS CloudTrail과 통합되며 전체 상태, 실패한 단계, 입력 및 출력을 비롯한 모든 실행 관련 정보를 기록. 서버리스 서비스 시각적 워크플로우를 사용하여 분산 애플리케이션 및 마이크로 서비스의 구성 요소를 조정하여 애플리케이션을 쉽게 구축할 수 있게 해주는 완전 관리형 서비스 여러 AWS Lambda 함수를 반응형 서버리스 애플리케이션에 결합하고 EC2 인스턴스, 컨테이너 또는 온프레미스 서버에서 실행되는 데이터 및 서비스를 오케스트레이션 가능 AWS Resource Groups Tag Editor 태그를 기반으로 리소스를 관리하고 구성하도록 특별히 설계 AWS Trusted Advisor AWS 환경의 비용, 보안 및 성능을 최적화 AWS Systems Manager 클라우드 및 온프레미스 리소스의 통합 관리를 지원하며 자동화와 효율성을 통해 운영 복잡성을 줄이고 보안을 강화하는데 필수적인 도구 회사는 실행 중인 애플리케이션을 중단하지 않고 IAM 역할이나 사용자를 수동으로 생성하거나 수정하지 않고도 EC2 인스턴스를 패치 기본 호스트 구성 관리 Systems Manager가 EC2 인스턴스를 관리형 인스턴스로 자동 관리할 수 있게 해주는 AWS Systems Manager의 기능 Service Snowball Edge (마이그레이션 장비) 기존 저장소의 대역폭이 충분하지 않을 때 대용량 데이터 세트를 클라우드로 이전하는데 도움(80TB(실사용 72TB)까지 한번에 이동 가능하며 Snowball Edge는 100TB(실사용 83TB)까지 가능) aws가 고용량 저장 장비를 사용자에게 보내고 사용자는 장비에 데이터를 복사해 다시 aws에게 보낸다. aws는 장비에 저장된 데이터를 S3, EBS, Glacier 등으로 저장한다. Amazon Snowcone AWS Snow Family에 속하는 소형, 휴대용 엣지 컴퓨팅 및 데이터 전송 장치 Snowcone은 데이터 수집, 처리, 저장 및 전송을 위해 설계되었으며 특히 네트워크 연결이 제한적이거나 신뢰할 수 없는 환경에서 유용 AWS DataSync 데이터 전송 프로세스의 관리와 고성능 및 보안 데이터 전송에 필요한 인프라를 모두 자동화 endtoend 보안을 제공하여 데이터가 안전하고 온전하며 사용할 준비가 된 상태로 도착하도록 보장 암호화, 데이터 무결성 확인 및 대역폭 최적화도 처리 온프레미스 ↔ AWS 사이에서 데이터를 빠르고 자동으로 옮겨주는 데이터 전송 서비스 전송 가능 대표 대상 S3, EFS, FSx 지원 프로토콜 NFS, SMB, 객체 스토리지 Amazon SQS(Simple Queue Service) 작업 요청 솔루션을 분리하여 대기열에 따라서 인스턴스 수를 확장 및 리소스 추가제공 갑작스러운 작업이 몰려도 추후 처리가능하도록 보관기능 제공 손실위험이 있는 데이터를 잠시 보관하는 용도 Dead Letter Queue 등 다양한 옵션으로 메시지 처리가 실패했을 경우 해당 메시지를 보관했다가 다시 처리할 수 있게끔 하는 기능을 제공 Amazon SNS(Simple Notification Service) 클라우드에서 손쉽게 알림을 설정, 운영 및 전송할 수 있도록 하는 웹 서비스 Amazon SES(Simple Email Service) 기업이 자체 이메일 주소와 도메인을 사용하여 이메일을 보내고 받을 수 있도록 하는 비용 효율적이고 확장 가능한 이메일 서비스 AWS Fargate EC2 인스턴스의 서비스나 클러스터를 관리할 필요없이 컨테이너 실행을 위해 ECS에 사용가능한 기술 컨테이너를 실행하는 데 필요한 컴퓨팅 리소스를 자동으로 할당하고 관리 AWS Fargate Spot Fargate를 이용해 컨테이너를 실행할 때, AW의 유휴 용량을 활용하여 Fargate 정가보다 최대 70% 저렴한 비용으로 컨테이너를 실행할 수 있는 기능 Amazon VPC CNI(Container Network Interface) 플러그인 EKS 클러스터에서 파드에 대한 네트워킹을 담당하는 플러그인. 이 플러그인은 각 노드에 VPC IP 주소를 할당하고 파드들이 서로 통신할 수 있도록 네트워크를 구성하는 역할 AWS App2Container(A2C) 기존 온프레미스 또는 가상 머신에서 실행되는 Java 및 .NET 애플리케이션을 컨테이너화된 애플리케이션으로 전환하여 현대화할 수 있도록 지원하는 명령줄 도구. 이 도구를 사용하면 코드 변경 없이 애플리케이션을 컨테이너 이미지로 변환하여 ECS 또는 EKS와 같은 컨테이너 오케스트레이션 서비스에서 실행 AWS Lightsail 저렴하고 예측 가능한 가격으로 컨테이너와 같은 클라우드 리소스의 간단한 관리를 제공하는 사용하기 쉬운 가상 프라이빗 서버 클랄우드의 문턱을 낮춘 상품, 개인 개발자나 IT 인프라 관리자가 없는 소규모 기업체에 적합한 서비스 AWS Database Migration Service Oracle에서 Oracle로의 동종 마이그레이션은 물론 Oracle 또는 Microsoft SQL Server에서 Amazons Aurora로의 서로 다른 데이터베이스 플랫폼 간의 이기종 마이그레이션을 지원 짧은 지연시간으로 데이터를 지속적 복제 가능 AWS Control Tower Best Practice에 기반한 보안 멀티 계정 환경(Landing Zone이라고 부른다)의 설정을 자동화하는 매니지드 서비스 AWS 환경에 대한 지속적인 가시성을 제공하기 위해 프로비저닝 된 OU 및 계정 수, 활성화 된 가드레일 수 등을 시각화한 대시보드를 제공하여 이를 통해 해당 가드레일에 대해 OU 및 계정의 상태를 확인할 수 있도록 제공 Guardrail 클라우드 리소스 설정 시 보안 규칙에 어긋나지 않도록 클라우드 리소스를 유지시킬 수 있는 기능을 제공 특정 설정 정책 배포 차단 Detective Controls(탐지 제어) AWS Config 규칙을 사용하여 조직의 AWS 계정 및 리소스에서 규정 준수 위반 사항을 지속적으로 모니터링하는 기능 AWS Account Factory AWS Control Tower의 핵심 기능 중 하나로, 새로운 AWS 계정을 손쉽게 만들고 관리할 수 있는 자동화된 프로세스를 제공 AWS Elastic Beanstalk 웹 애플리케이션 및 서비스의 배포 및 조정을 위한 서비스 코드를 업로드 하면 Elastic Beanstalk이 용량 프로비저닝, 로드 밸런싱, 자동 조정부터 시작하여 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리 AWS Amplify 풀스택 애플리케이션 개발을 지원하는 개발 플랫폼 프론트엔드와 백엔드를 쉽게 설정, 개발, 배포를 통합적으로 관리하는 데 유용 Elastic Beanstalk은 백엔드를 쉽게 구성해주지만 Amplify는 프론트엔드, 백엔드, CI/CD를 쉽게 올인원으로 만들도록 도와준다. AWS CloudFormation AWS 리소스를 모델링하고 설정하여 리소스 관리 시간을 줄이로 AWS에서 실행되는 애플리케이션에 더 많은 시간을 사용하도록 해주는 서비스(IaC) AWS Pinpoint 모바일 앱 및 웹 애플리케이션의 마케팅 전략을 강화하고 사용자 경험을 최적화하는 데 도움이 되는 강력한 마케팅 서비스 고객이 특정 키워드가 포함된 메시지를 보낼 때 자동 응답을 생성 약속 확인, 주문 업데이트, 일회용 암호와 같은 다이렉트 메시지를 전송가능 AWS Lambda 서버리스 컴퓨팅 서비스로 서버를 프로비저닝할 필요없이 특정 이벤트에 대한 응답으로 코드를 실행 호출 수와 함수 실행 시간에 따라 요금을 부과 Lambda@Edge를 생성하면 들어오는 요청의 UserAgent 헤더를 검사하고 사용 중인 장치 유형을 확인. 이 정보 기반으로 응답을 사용자 지정하고 적절한 버전의 콘텐츠를 사용자에게 보낼 수 있음 AWS Lambda SnapStart Lambda 함수의 콜드 스타트 성능을 개선하기 위해 제공되는 기능 함수를 처음 실행하거나 유휴 상태에서 재개할 때 발생하는 지연 시간을 줄여준다. SnapStart는 함수의 초기화 단계를 스냅샷으로 찍어 저장하고 이후 호출 시 이 스냅샷을 사용하여 빠르게 함수를 시작한다. AWS Batch 사용자가 AWS에서 배치 작업을 실행할 수 있게 해주는 완전관리형 서비스 다른 언어로 작성된 다양한 유형의 작업을 처리하고 EC2 인스턴스에서 실행 AWS Organizations 여러 AWS 계정을 중앙에서 관리하고 통합할 수 있는 서비스 비용을 절감하며 보안 및 규정 준수를 강화할 수 있는 강력한 도구 Amazon ElastiCache for Redis AWS에서 제공하는 완전 관리형 인메모리 캐싱 서비스로 Redis 데이터베이스를 클라우드에서 쉽게 설정, 관리 및 확장할 수 있도록 지원 고성능과 낮은 지연 시간을 제공하며 애플리케이션의 데이터베이스 레이어를 가속화하고 세션 저장소, 게임 리더보드 등 다양한 용도로 사용 AWS EMR(Elastic MapReduce) 대규모 데이터 처리 및 분석을 위해 제공하는 클라우드 기반 서비스 Apacahe Hadoop, Apache Spark 등 오픈 소스 빅데이터 프레임워크를 사용하여 데이터를 처리하고 분석할 수 있도록 지원 유연하고 확장 가능한 분산 처리 환경을 제공 병렬 데이터 처리 런타임 역할 클러스터에서 실행되는 애플리케이션이 AWS 리소스에 액세스할 수 있도록 권한을 부여하는데 사용 보안 구성에 따라 각 클러스터마다 고유한 식별자를 생성하여 클러스터 내에서 실행되는 애플리케이션이 필요한 리소스에 안전하게 액세스 API Gateway 서버리스 애플리케이션, REST API, WebSocket API를 만들고 관리할 수 있도록 해주는 완전 관리형 서비스 API 개발자가 애플리케이션 백엔드에 안전하게 액세스하고, API를 쉽게 게시, 유지 관리, 모니터링 및 보안할 수 있도록 지원 AWS 엣지 최적화 엔드포인트 클라이언트가 지리적으로 분산되어 있을 때 API 요청의 지연 시간을 줄이기 위해 사용 이 엔드포인트 유형은 AWS 관리형 CloudFront 배포를 사용하여 요청을 가장 가까운 CloudFront 엣지 로케이션으로 라우팅하여 응답 속도를 높여준다 리전 API 엔드포인트 동일 리전의 클라이언트를 위한 서비스 EC2 인스턴스를 실행하는 클라이언트가 동일 리전에서 API를 호출하거나 AP가 수요가 큰 소수의 클라이언트에게 서비스를 제공하기 위한 것이라면 리전 API는 연결 오버헤드를 줄인다 프라이빗 API 엔드포인트 인터페이스 VPC 종단점을 사용해서 Amazon VPC에서만 액세스할 수 있는 API 엔드포인트 AWS AutoScaling Warm Pool 애플리케이션의 확장 속도를 높이고 비용을 절감하기 위해 사전 초기화된 EC2 인스턴스 풀을 유지하는 기능 웜 풀을 사용하면 새 인스턴스를 시작하는 대신 미리 준비된 인스턴스를 사용하여 애플리케이션 수요 증가에 빠르게 대응 AWS Outposts AWS 인프라와 서비스를 고객의 온프레미스 환경, 즉 데이터 센터나 엣지 로케이션에 확장하여 제공하는 완전 관리형 서비스 즉, AWS가 완전한 rack을 만들어 보내주면 고객 사이트에 설치해서 고객이 사용. 그러나 물리적 관리는 AWS 지원 휴지통 보존 규칙 아카이브 스토리지 티어의 아카이빙된 스냅샷에도 적용된다 보존 규칙과 일치하는 아카이빙된 스냅샷을 삭제하면 보존 규칙에 정의된 기간 동안 해당 스냅샷이 휴지통에 보존된다 아카이빙된 스냅샷에 대한 요금으로 청구 Amazon OpenSearch Service AWS 클라우드에서 OpenSearch 클러스터를 쉽고 안전하게 배포, 확장 및 운영할 수 있도록 지원하는 완전 관리형 서비스 OpenSearch는 데이터 검색, 분석, 모니터링 등 다양한 용도로 사용되는 오픈 소스 검색 및 분석 엔진 Amazon MGN(Application Migration Sevice) 온프레미스 또는 다른 클라우드 환경에서 AWS로 서버를 마이그레이션하는데 사용되는 서비스 컷오버 인스턴스(cutover instance) 소스 서버를 AWS 환경으로 완전히 전환하기 위한 최종 단계를 의미 컷오버 인스턴스는 테스트 단계를 거친 후 실제 운영 환경으로 사용될 인스턴스를 의미하며 이 단계에서 소스 서버의 데이터와 애플리케이션이 AWS로 마이그레이션 AWS ParallelCluster AWS에서 고성능 컴퓨핑(HPC) 클러스터를 생성하고 관리할 수 있는 서비스 Boto3 파이썬으로 AWS 서비스를 제어하고 관리하기 위한 공식 SDK 즉, 파이썬 코드를 사용하여 S3, EC2, Lambda 등 다양한 AWS 서비스를 프로그래밍 방식으로 조작하고 관리할 수 있게 해주는 도구 AI/ML Amazon SageMaker 완전 관리형 인프라, 도구 및 워크플로를 사용하여 모든 사용 사례에 대해 기계 학습(ML) 모델을 구축, 훈련 및 배포하는 완전 관리형 서비스

May 20, 2026AWS

서버가 죽지 않도록... ELB와 Auto-Scailing 이해하기 (feat. AWS)

먼저 ELB와 AutoScailing에 대해 알아보자. ELB (Elastic Load Balancing) ELB는 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 자동으로 분산시킨다. 단일 가용 영역 또는 여러 가용 영역에서 다양한 대상에 걸쳐 애플리케이션 트래픽의 부하를 분산하여 애플리케이션의 결함 허용 능력을 높인다. 그 중 ALB(Application Load Balancer)의 특징은 OSI 모델의 7계층(애플리케이션 계층)에서 작동하며 HTTP/HTTPS 프로토콜의 헤더 내용을 기반으로 고급 라우팅 결정을 내릴 수 있다. NLB(Network Load Balancer)는 OSI 모델의 4계층에서 작동하며 초당 수백만 개의 요청을 처리할 수 있는 성능을 제공한다. 또한 가용 여역당 하나의 고정 IP를 가질 수 있다는 큰 특징이 있다. 쉽게 얘기해보면 웹서비스를 운영한다면 ALB를, 게임 서버나 실시간 스트리밍이라면 속도가 생명인 NLB를 사용한다고 볼 수도 있겠다. AutoScailing Amazon EC2 AutoScailing은 애플리케이션의 부하를 처리할 수 있는 정확한 수의 EC2 인스턴스를 유지할 수 있게 도와준다. 지정된 조건에 따라 EC2 인스턴스를 자동으로 시작하거나 종료한다. 이를 통해 수요가 급증할 때는 성능을 유지하고 수요가 적을 때는 비용을 절감한다. 가장 큰 목적은 고가용성(HighAvailability)이다. scale out = 서버의 갯수가 늘어남, scale in = 서버의 갯수가 줄어듬. scale up = 서버의 리소스가 증가, scale down = 서버의 리소스가 감소. AutoScailing의 구성 순서는 아래와 같다. 1. ELB를 생성하면서 빈 타겟그룹을 생성한다. 2. 빈 타겟그룹으로 로드밸런서를 생성한다. 3. AutoScailing 그룹을 만든 후, 위에서 만든 빈 타켓그룹에 넣어준다. 간단한 실습을 통해 개념을 익히고 감각을 익혀보자. Web 서버를 ubuntu 24.04 기반으로 생성하여 AutoScailing을 구성해보자. EC2 인스턴스 개수는 최소 1대 최대 3대 가용 영역 최소 2개 이상(a, c)으로 하는 AutoScailing 가능한 web 서버들을 프라이빗 서브넷에 위치. stress 패키지가 재부팅 시에도 자동으로 부하가 걸리게끔. 외부(노트북의 브라우저)에서 웹페이지가 보이도록. ALB의 Listen Port : 88 Web 서버(인스턴스)를 생성할 때 퍼블릭으로 둔 후 필요한 패키지를 설치하고 인스턴스를 이미지 화 하여 프라이빗 서브넷에 인스턴스를 생성하는 방향으로 진행하였다. 먼저 퍼블릭 서브넷에 인스턴스를 하나 만들어서 nginx, stress(cpu 부하용) 패키지를 설치한 후 이미지화 하여 시작 템플릿을 만든다. bash apt update y && apt install y nginx echo webtem /var/www/html/index.html systemctl enable now nginx stress 패키지 설치 후 cpu에 부하 걸어주기. bash apt install y stress stress c 2 t 1200 t3.micro의 vcpus 갯수가 2개 이상이므로 c 2, t초 20분 동안 2 core cpu에 100% 부하를 준다. bash tee /etc/systemd/system/stress.service bash systemctl daemonreload systemctl enable stress 시스템 반영 후 재부팅 시에도 stress를 주도록 설정한다. 여기까지 했다면 이제 이미지(AMI)를 생성하고 시작 템플릿을 생성해준다. 1\. 로드 밸런서 생성 Internetfacing을 선택하고 2개의 가용 영역을 생성해주는데 퍼블릭 서브넷으로 설정을 해준다. 보안 그룹은 22번과 80번 포트가 열린 보안그룹을 선택한다. 여기서 대상 그룹을 생성해줘야 한다. 대상 그룹 생성 탭에 들어가 빈 타겟 그룹을 생성해준 뒤 돌아와서 생성한 대상 그룹을 선택해 준다. 2\. AutoScailing 그룹 생성 다음으로 AutoScailing 그룹을 생성해줘야 한다. 여기서도 2개의 가용 영역을 생성해주는데 서브넷은 프라이빗 서브넷에 위치시킨다. (EC2 인스턴스가 프라이빗 서브넷에 생성되어야 하므로) 기존의 로드 밸런서에 연결하는 설정을 해주고 위에서 만들었던 로드 밸런서 대상 그룹을 선택해준다. 지금부터가 중요하다. "ELB 상태 확인 켜기"를 체크해주고,  원하는 용량, 최소 용량, 최대 용량을 정의한 뒤 정책 이름을 설정해준다. 목표 CPU 사용률은 70%로 설정한다. 평균 CPU 사용률이 70%를 넘어서면 AutoScailing이 인스턴스를 늘려야겠다라고 판단해 새로운 인스턴스를 생성한다. 여기서 새로운 인스턴스는 기존에 생성된 인스턴스 스펙과 동일하게 생성된다. (아까 만든 시작 템플릿을 바탕으로) 추가로 모니터링 섹션에서 "그룹 지표 수집 활성화"를 체크해주면 CloudWatch에서 지표를 볼 수 있다. 최종적으로 88번 포트로 접속하면 잘 뜨는 것을 확인할 수 있다. 평균 CPU 사용률이 70%가 넘어가면 인스턴스가 최대 3개까지 늘어나도록 설정했다. 필요시 사용률이 줄어들면 인스턴스가 줄어들도록 scale in 정책을 만들 수 있다. 이 부분도 평균 CPU 사용률을 정의해주면 해당 값 이하로 떨어질 경우 AutoScailing이 인스턴스 갯수를 줄인다. CloudWatch 콘솔에 접속해 지표를 보면 CPU 사용률을 확인할 수 있다. (미처 CloudWatch에서 지표 확인 화면을 캡처하지 못해 비슷한 상황인 다른 사용자의 CloudWatch 이미지를 가져왔다.) 경보 알람이 발생하면 AutoScailing이 발생하고 인스턴스가 늘어나고 줄어드는 동작을 진행한다.  AutoScailing 흐름을 보면 이런 흐름이다. 지금까지 구성한 실습을 보면 이러하다. ALB가 퍼블릭 서브넷에 위치하여 외부 손닙을 맞이하는 입구 역할을 하고 EC2는 프라이빗 서브넷에 숨서어 실제 서비스를 제공한다. 외부 사용자는 ALB(88포트)로 들어오고, ALB는 내부망을 통해 EC2(80포트)로 연결을 토스한다. 인스턴스는 공인 IP가 없어도 ALB 덕분에 안전하게 서비스할 수 있다. 시작 템플릿은 서버를 만들 때 필요한 붕어빵 틀이라고 생각하면 편하다 AutoScailing 그룹을 생성하고 scale out(확장), scale in(축소) 정책을 생성해 CPU 부하에 따라서 시작 템플릿을 활용해 서버를 자동으로 생성하고 삭제한다. 이 과정에서 궁금증이 생겼다. "그럼 CPU 사용률이 떨어져 인스턴스가 삭제될 때 해당 인스턴스에 남아있는 사용자는 안 튕기나?" 삭제 결정이 내려진 서버에는 더 이상 새로운 사용자를 보내지 않는다.(배수 상태, Draining) 이미 접속 중인 손님이 볼일을 마칠 때까지 설정된 시간(기본 300초)동안 기다려 준다. 시간이 다 되면 사용자가 남아있더라도 연결을 끊고 서버를 종료한다. (이때 브라우저는 자동으로 다른 살아있는 서버에 재접속을 시도한다.) 그래서 사용자 입장에서는 잠깐의 딜레이가 발생하고 다른 큰 이슈 없이 사용할 수 있게된다. 좋은 인프라륵 구축하는 것도 중요하지만 이 속에서 "사용자가 장애를 느끼지 않게 하는 것"이 가장 큰 핵심인 것 같다. ALB와 AutoScailing의 조합은 단순한 자동화를 넘어 서비스의 연속성을 보장하는 강력한 도구인 것 같다.

May 12, 2026AWS