2025/05 21

Auto Scaling 최적화 - 안정성과 비용 효율을 동시에 잡는 법

AWS의 Auto Scaling 기능은 애플리케이션의 가용성을 유지하면서도 리소스를 효율적으로 관리할 수 있는 중요한 도구이다. 하지만 설정을 어떻게 하느냐에 따라 불필요한 인스턴스 생성, 불안정한 성능, 예상치 못한 비용 증가가 발생할 수 있다. Auto Scaling이 너무 자주 작동한다면?Auto Scaling 그룹이 너무 자주 스케일 아웃(인스턴스 증가)과 스케일 인(인스턴스 감소)을 반복하면 다음과 같은 문제가 발생할 수 있다:비용 증가: 인스턴스가 짧은 시간이라도 실행되면 비용이 발생불안정한 서비스: 인스턴스가 충분히 안정화되기도 전에 종료됨의미 없는 반응: 사소한 트래픽 변화에도 과도하게 반응 최적화를 위한 두 가지 핵심 조정 포인트1. 휴지 기간(Cooldown Period) 늘리기역할: ..

AWS 2025.05.15

페이지 전체 로딩이 느려질 때 생각해야 할 원인과 대응 전략

웹사이트를 운영하다 보면 언젠가 이런 문제를 겪게 된다:“사이트 로딩이 너무 느려요.”“방문자가 10초 이상 기다리지 않고 이탈해요.”“트래픽이 몰리면 느려져요.” 이럴 때 대부분의 사람들은 “서버 성능이 부족한가?” 하고 EC2 인스턴스부터 키우려는 경향이 있다.하지만 실무에서는 서버 증설은 마지막 카드일 때가 많다.오히려 먼저 확인해야 할 건 읽기 성능’과 ‘콘텐츠 전달 경로’다. 1. 전체 로딩 속도가 느릴 때, 병목은 어디서 생길까?사용자 입장에서 “느리다”는 건 보통 페이지가 다 뜨기까지 오래 걸린다는 뜻이다.이 과정에서 브라우저는 아래와 같은 리소스들을 요청한다:HTMLCSS, JS이미지, 폰트API 데이터 (자주 읽히는 뉴스, 목록 등)이 중 하나라도 느리면, 전체 페이지 로딩이 지연된다. ..

AWS 2025.05.14

CloudWatch Alarm으로 EC2 인스턴스 자동 복구

EC2 인스턴스는 물리 호스트에 문제가 생기면 running 상태로 표시되더라도 정상적으로 동작하지 않을 수 있다.이런 상황에서 인스턴스를 자동으로 복구할 수 있도록 AWS는 CloudWatch 경보를 통한 Auto Recovery 기능을 제공한다. 🛠️ 자동 복구란?EC2 인스턴스의 상태를 감시하다가 시스템 장애(예: 하드웨어 오류)로 인해 인스턴스가 응답하지 않으면, CloudWatch Alarm이 이를 감지해 자동으로 인스턴스를 정상적인 호스트에서 다시 시작한다. ☑️ 인스턴스를 "다시 시작"하는 것이지, 새로운 인스턴스를 생성하는 것이 아니다. 복구 중 유지되는 것 vs 사라지는 것항목복구 후 유지 여부설명인스턴스 ID✅동일 ID로 복구프라이빗 IP✅내부 통신 문제 없음탄력적 IP (EIP)✅고..

AWS 2025.05.13

로드밸런서(ALB/NLB)를 이해하기 위한 통신 흐름의 기초

ALB와 NLB를 이해하려면 먼저 "요청이 어떻게 전달되는지"부터 알아야 한다. 웹에서 우리가 어떤 요청을 보낼 때, 그 요청은 단순히 “URL을 입력한다”로 끝나지 않는다. 실제로는, HTTP(또는 HTTPS)라는 웹 통신 규칙이 TCP라는 통신 경로 위에서 동작한다. 예를 들어, 사용자가 브라우저에 https://example.com/login을 입력하면, 이 요청은 다음과 같은 흐름으로 전달된다: HTTP 요청 내용 → TCP 연결 → IP 주소와 포트 즉, HTTP는 “어떤 요청을 보내는가”를 담고 있고, TCP는 “그 요청을 어떻게 안정적으로 전달할 것인가”를 담당하는 역할을 한다. ALB와 NLB는 어떤 기준으로 요청을 전달하는가? 이제 본격적으로 ALB와 NLB의 차이를 살펴보자. 두 로..

AWS 2025.05.12

EC2 인스턴스 인터넷 연결 구조

EC2 인스턴스를 인터넷에 연결하거나 외부 요청을 받아야 하는 상황은 매우 흔하다. 이때 자주 마주치는 개념들이 있다: 퍼블릭 서브넷, 인터넷 게이트웨이(IGW), 퍼블릭 IP, 그리고 로드밸런서(ALB/NLB). 이 글에서는 이 네 가지가 어떻게 작동하고, 어떤 구조로 연결되어야 인터넷 통신이 가능한지 정리해보려 한다.1. 퍼블릭 서브넷이란?퍼블릭 서브넷은 VPC 내에서 인터넷과 직접 연결될 수 있는 서브넷이다. 퍼블릭 서브넷이 되기 위한 조건은 다음과 같다:서브넷이 속한 VPC에 인터넷 게이트웨이(IGW) 가 연결되어 있어야 한다.해당 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있어야 한다.이 두 가지가 모두 만족되면, 해당 서브넷은 퍼블릭 서브넷이 된다. 단, 이 안에 있는 EC2..

AWS 2025.05.11

VPC 내 서브넷의 인터넷 연결 방식

VPC 내의 서브넷에 관한 인터넷 액세스를 정의하는 방법에 대해 알아보자. 인터넷에 액세스할 수 있는 공용 서브넷에 EC2 인스턴스가 있으며, 인터넷 게이트웨이를 생성해야 한다. 인터넷 게이트웨이는 VPC 인스턴스가 인터넷에 바로 연결될 수 있게 한다. VPC는 인터넷 게이트웨이를 가지고, 공용 서브넷은 인터넷에 액세스하는 인터넷 게이트웨이에 관한 라우트를 가지게 된다. 즉 1. 인터넷 게이트웨이와 2. 인터넷 게이트웨이로의 라우트가 있으면, 서브넷이 공용 서브넷이 되어 외부 인터넷과 연결될 수 있는 상태가 되는 것이다. 프라이빗 서브넷의 인스턴스는 기본적으로 인터넷에서 액세스할 수 없지만, 필요한 경우 인터넷 액세스 권한을 부여할 수 있다. 예를 들어 운영 체제를 업데이트하거나 파일을 다운로드..

AWS 2025.05.10

API Gateway 캐싱 구조 정리

API Gateway는 AWS의 완전관리형 서비스로, HTTP 요청을 받아 Lambda, EC2 등으로 전달하는 API 엔트리포인트 역할을 한다.이 중 캐싱 기능을 활성화하면, 자주 호출되는 API 응답을 임시 저장하여 백엔드 호출 없이 빠른 응답이 가능해지고, 비용 절감 및 성능 향상된다. # CloudFront와 캐시API Gateway의 캐싱은 AWS 내부적으로 CloudFront 기술을 기반으로 한다.CloudFront는 AWS의 글로벌 CDN으로, 콘텐츠를 전 세계에 분산된 서버에 캐싱해 빠르게 제공할 수 있도록 한다.하지만, API Gateway의 캐싱은 단순 CDN과는 조금 다르다. 📍 AWS의 세 가지 물리적 위치위치설명리전 (Region)Lambda, Aurora 등 주요 리소스가 있는..

AWS 2025.05.09

AWS VPC 구조와 구성요소 이해하기

# VPC VPC는 가상 사설 클라우드로, 사설 네트워크를 통해 EC2 인스턴스에 리소스를 배포하는 등의 작업이 가능한 공간이다. VPC 는 특정 리전과 연결되어 있어서, AWS에 여러 리전이 있으면 여러 VPC를 갖게 된다. 위 이미지처럼 생성한 VPC 내에는 서브넷이 존재한다. 서브넷은 네트워크를 구분하는 역할을 하고, 가용영역과 연결되어 있다. AZ A가 있을 때, 해당 가용영역에는 공용 서브넷과 브라이빗 서브넷이 존재한다. 공용 서브넷은 인터넷과 직접 연결되어 있어, 인터넷으로 액세스할 수 있다. 프라이빗 서브넷은 인터넷을 통해 액세스할 수 없는 서브넷으로, 인터넷 연결이 필요할 때에는 공용 서브넷을 통해야 한다. 인터넷으로 액세스, 그리고 서브넷 간의 액세스를 정의해서 리소스와 통신할 때..

AWS 2025.05.08

AWS IP 주소 개념 정리 (IPv4, Elastic IP, IPv6)

# AWS의 IP 주소## IPv4 프로토콜 IPv4는 Internet Protocol version 4의 약자로 43억 개의 주소를 가지고 있다. 그중에서도 퍼블릭 IPv4는 인터넷에서 사용할 수 있는 IP 주소로, 이를 통해 IP가 무엇이든 어디에서나 공개적으로 접근할 수 있다. EC2 인스턴스를 생성하면 퍼블릭 IPv4를 얻을 수 있다. 인스턴스를 중지하면 IPv4가 해제되고, 인스턴스를 다시 시작할 때 새로운 퍼블린 IPv4를 얻게 된다. 프라이빗 IPv4는 예를 들어 192.168.1.1과 같은 형식을 갖는다. 퍼블릭과 달리, 내부 AWS VPC와 같은 사설 네트워크에서만 사용할 수 있는 IP 이다. 프라이빗 IPv4로 공개적으로 접근하는 것은 불가능하기 때문에, 웹 브라우저에서 시도하더라도..

AWS 2025.05.07

AWS Health 대시보드란? 서비스 기록부터 개인 계정 모니터링까지

# AWS Health 대시보드 대시보드는 크게 서비스 기록과 계정, 두 부분으로 나뉜다. 서비스 기록 부분은 아래와 같이 모든 리전과 서비스 상태가 표시된다. 위와 같은 정보들을 포함한 대시보드를 보고, 서비스가 어떻게 작동했는지, 어떤 문제가 있었는지 리전별로 추적할 수 있다. 매일의 기록을 볼 수도 있고, RSS 피드가 있어서 구독할 수도 있다. 해당 서비스는 이전에 AWS Service Health 대시보드라고 불렸다는 점도 알아두면 좋을듯하다. # 사용자 계정의 AWS Health 대시보드 예전에는 AWS Personal Health 대시보드라고 불리던 서비스로, 현재는 계정 Health 대시보드라는 이름을 사용한다. 사용자에게 직접적인 영향을 미치는 이벤트가 AWS에서 발생할 때..

AWS 2025.05.06