• ELB : 들어오는 요청을 여러 서버로 분배하고 비정상 서버로는 안 보냄
  • ASG : 트래픽에 따라 서버 개수를 자동으로 늘리고/줄임, 비정상 서버는 교체

ELB

  • 클라이언트 요청을 받아서 Target Group에 등록된 타깃(EC2, IP, Lambda 등)으로 전달
  • 서버 과부하 방지, 장애 격리, 단일 진입점(고정 도메인/증명서) 제공
  • 방법
    • Listener(ex) 443, 80) → 규칙(호스트/경로) → Target Group(헬스체크 포함)으로 라우팅
    • 헬스체크 성공한 타깃에만 트래픽 전달
    • 세션 스티키(쿠키), TLS 종료(인증서 관리), Cross-Zone LB 등 지원

 

ASG

  • 지정한 방법대로 EC2 인스턴스를 원하는 개수(Desired)만큼 유지/증가
  • 트래픽 변동에 맞춘 자동 탄력성셀프-힐링(죽으면 다시 띄움)
  • 방법
    • Min/Max/Desired 용량으로 경계 설정
    • 스케일링 정책 : Target tracking(ex) 평균 CPU 50%), Step, Scheduled
    • 헬스체크: EC2 기본 또는 ELB 헬스체크 연계(비정상 타깃이면 교체)
    • 보강 기능: Lifecycle Hook(부팅/종료 훅), Warm Pool(미리 예열), Instance Refresh(무중단 교체), Mixed/Spot(비용 절감), Capacity Rebalance

 

Client → Route 53 → ELB(ALB/NLB)
                         ↓
                 Target Group ── (헬스체크)
                         ↓
               EC2 인스턴스들 (ASG가 관리)
  • ELB는 요청을 인스턴스에 분배
  • ASG는 비정상 인스턴스 교체/수량 조절로 뒤에서 탄력성 보장
  • ASG의 헬스체크를 ELB 신호로 설정하면 실제 서비스 관점의 건강도를 반영
항목 ELB / ALB ASG
목적 요청 분배/라우팅 인스턴스 수량 유지/자동 확장
헬스체크 전달 여부 결정 교체/종료 여부 결정
트래픽 급증 대응 즉시 분산(있던 용량 내) 인스턴스 추가 생성(약간의 스핀업 시간 필요)
구성 단위 Listener, 규칙, Target Group Launch Template, Min/Max/Desired, 정책
보안/인증서 TLS 종료(ACM), WAF 연계(ALB) 보안그룹/AMI/유형은 템플릿에서 정의

 

 
 

 

  • ALB (L7): HTTP/HTTPS, 경로/호스트 기반 라우팅, WAF 연계, WebSocket/HTTP2/gRPC
  • NLB (L4): 초고성능/초저지연, 고정 IP/Elastic IP, TLS 패스스루/종료. 게임/금융/IoT, TCP/UDP 필요 시
  • GWLB: 서드파티 보안 어플라이언스 체인(방화벽/IDS 등)을 서비스처럼 붙일 때
  • (CLB는 레거시)

 

ASG

  • Target Tracking: “평균 CPU 50% 유지”처럼 목표 지표에 맞춰 자동 증감
  • Step/Simple: 임계치 구간별 단계적 증감
  • Scheduled: “평일 09시에 +3대” 같은 시간표 기반
  • Lifecycle Hook: 시작 시 에이전트 설치, 종료 전 로그 배출 등 커스텀 작업
  • Warm Pool: 사전 예열로 스케일 업 지연 줄이기
  • Instance Refresh: 새 AMI로 점진 교체(rolling).
  • Mixed Instances/Spot: 비용 절감 + 다종 인스턴스로 용량 안정화

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

WAF와 UTM의 차이점  (1) 2025.07.08
AWS LocalZone #2  (1) 2025.07.06
EBS(Elastic Block Store) 란 ?  (0) 2025.07.06
AWS LocalZone #1  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01

📌 WAF을 Private Subnet에 배치하는 이유

 

WAF를 프라이빗 서브넷에 배치하는 이유는 주로 다음과 같은 보안적인 목적래픽 흐름 상의 설계 목 때문

 

 

  1. 외부로부터 WAF를 직접 접근 불가능하게 하기 위함
    • 보안 장비 자체(WAF)가 외부 인터넷에서 직접적으로 접근되지 않도록 보호할 필요가 있음
    • 인터넷에 직접 노출되면 WAF 자체가 공격의 대상이 될 수 있으므로 반드시 내부(프라이빗) 환경에 배치
  2. 트래픽은 반드시 ALB를 통해서만 들어오도록 제한
    • HTTP/HTTPS 트래픽은 ALB에서 종결되고 이후 검증된 트래픽만이 WAF를 거쳐 내부로 전달
    • ALB는 외부에서 유입되는 트래픽을 첫 번째로 필터링하는 관문, 이후 2차 필터링이 WAF에서 이루어짐 
  3. 이중 보안 구조로 안전성 향상
    • ALB에서 트래픽의 기본적인 보안, 즉 SSL Termination, 로드밸런싱을 수행한 뒤, 다시 한번 WAF에서 정교한 보안 검사(공격 패턴 탐지, OWASP 기반 공격 방지 등)를 수행
      ALB에서 1차 기본 필터링 → WAF에서 2차 정밀 필터링 → 이 2단계가 바로 "이중 보안 구조"입니다.
  4. 보안 및 감사 용이성
    • Private 서브넷 내에 위치시키면 네트워크 ACL, 보안 그룹 등으로 접근을 강력히 통제하고 로그 기록을 명확히 관리할 수 있어 보안 감사가 편리

 

 


📌 WAF와 UTM의 목적과 역할 차이

 

장비 역할 일반적인 배치 위치
WAF
(웹 애플리케이션 방화벽)
HTTP/HTTPS 트래픽에 대한 정밀한 웹 기반 공격 탐지
(OWASP Top10, 웹 공격 패턴 탐지 등)
Private Subnet
(일반적으로 외부 직접 접근 불가 위치)
UTM
(Unified Threat Management)
다양한 프로토콜(TCP 등)을 포함한 범용 트래픽에 대한 보안 검사, 방화벽 정책, 침입 탐지/방지(IDS/IPS) Public Subnet
(인터넷 또는 외부망과 연결된 경로상의 위치)
 

 

 


📌 UTM을 Public Subnet에 배치하는 이유

 

1️⃣ UTM은 원천적으로 외부 접근이 가능해야 함

  • UTM은 다양한 프로토콜의 트래픽을 실시간 검사하기 위한 장비NLB를 통해 유입된 외부 트래픽을 직접 받아 검사 후 내부로 전달해야함
  • UTM 자체가 인터넷 또는 외부망에서 접근 가능해야만 정상적으로 동작하므로 반드시 Public Subnet에 배치해야함

2️⃣ 트래픽의 투명성(Transparent Inspection)

  • UTM은 일반적으로 인라인 구성을 사용하여 사용자와 내부 서버 간의 트래픽을 실시간 검사합니다.
  • UTM을 Private subnet에 배치하면 추가적인 복잡한 라우팅이 필요하고 트래픽 처리 과정이 복잡해져 성능과 지연 문제가 발생

3️⃣ 일반 TCP 트래픽은 ALB에서 처리되지 않습니다.

  • HTTP(S) 트래픽과 달리, 일반 TCP 트래픽(DB 접근 등)은 ALB가 아닌 NLB를 통해 직접 처리됩니다.
  • 따라서 TCP 트래픽을 처리할 보안 장비(UTM)는 외부 트래픽 흐름상 Public subnet 위치가 가장 효율적이고 자연스럽습니다.

4️⃣ 일반적인 AWS 네트워크 보안 설계 가이드라인

  • 실제 AWS 환경 구성에서 TCP 기반의 일반 트래픽 방화벽/보안장비(UTM)는
    보통 Public subnet에서 NLB 뒤에 배치하여 구성하는 것이 AWS의 권장 Best Practice입니다.

 

 

→ 즉 외부 노출을 가정하고 설계된 보안 장비로 인터페이스 수준에서 방화벽 규칙과 네트워크 ACL을 엄격히 적용해 접근을 강력히 제한 필요 

 

 

 

네트워크 장비(방화벽, UTM 등)를 트래픽 흐름상 반드시 통과하도록 배치하는 구성

즉, 장비를 우회하지 않고 반드시 해당 장비를 통과해야만 트래픽이 목적지까지 갈 수 있는 형태

반대 개념은 "아웃오브패스(Out-of-path)" 방식으로, 트래픽이 장비를 직접 거치지 않고 복제된 트래픽을 분석하는 구조

[사용자 PC] 
     ↓
(트래픽 흐름)
     ↓
[방화벽 or UTM] → 공격 탐지/차단 가능
     ↓
(정상 트래픽만 통과)
     ↓
[서버(App/DB 등)]

 

 

 

 

 

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

ELB(Elastic Load Balancer) vs ASG(Auto Scaling Group)  (4) 2025.08.12
AWS LocalZone #2  (1) 2025.07.06
EBS(Elastic Block Store) 란 ?  (0) 2025.07.06
AWS LocalZone #1  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01

🧠 EKS란 무엇인가 ?

Amazon EKS (Elastic Kubernetes Service)는 AWS가 제공하는 완전관리형 Kubernetes 클러스터 서비스

  • Kubernetes = 컨테이너를 자동으로 배포/운영해주는 오케스트레이션 플랫폼
  • EKS = AWS가 Kubernetes 클러스터의 제어 영역을 대신 관리해주는 서비스

 

🧱 EKS 기본 구성요소

Control Plane (마스터 노드) Kubernetes API 서버, 스케줄러, 컨트롤러들이 돌아가는 중앙 뇌 역할로 AWS가 운영
Node Group (워커 노드) 실제 애플리케이션이 배포되는 EC2 인스턴스로 사용자 관리 대상
 

즉, Control Plane은 AWS가 책임지고 Worker Node는 직접 설정하거나 EKS가 자동으로 생성하게 하는 구조 

 

 


 

EKS 기반의 워커노드를 배포

 

✅ AWS 리전: Singapore (ap-southeast-1) - 마스터 노드 

  • AWS Managed VPC 안에서 돌아가고 있음
  • EKS 마스터 노드가 있는 서브넷은 AZ-1, AZ-2, AZ-3에 나뉘어 존재

 

✅ Local Zone: Thailand(Bangkok)(ap-southeast-1-bkk-1a)

  • 워커 노드(Node Group)는 태국 방콕 Local Zone에서 운영
  • 워커 노드는 EKS 마스터와 통신하여 스케줄링 및 배포 명령을 받음
  • EKS 워커는 EC2 기반으로 구성되어 있고 퍼블릭 서브넷 내에 있음
  • 사용자(태국 국내 사용자)는 Network Border Group을 통해 Local Zone을 통해 낮은 레이턴시로 서비스 이용 가능

 

✅ Cross-Account ENI

  • 마스터 노드와 워커 노드가 다른 VPC/Subnet에 있어도 연결되도록 해주는 Elastic Network Interface(ENI) 구성
  • 이는 EKS가 자동으로 생성함

 

 


 

 

 

🟧 시나리오 1: AWS Region ↔ AWS Local Zone

💡 목적

  • 리전의 서비스와 Local Zone의 서비스를 연동하여 저지연성과 고가용성을 동시에 확보
  • 리전은 멀고 빠른 응답이 필요한 서비스가 있을 때 

✅ 구성

  • EKS 마스터 노드 → 리전
  • EKS 워커 노드 → Local Zone

🚀 특징

  • 게임/영상 스트리밍 서비스 같은 실시간 반응이 중요한 서비스
  • 데이터는 리전에 저장하되 처리는 Local Zone에서

 


 

🟧 시나리오 2: AWS Local Zone ↔ AWS Local Zone

💡 목적

  • 한 리전이 아닌 서로 다른 Local Zone 간 이중화 구성
  • 특정 Local Zone에 장애가 발생해도 다른 Local Zone이 백업 역할 수행

✅ 구성

  • 서울 LZ ↔ 부산 LZ
  • 태국 방콕 LZ ↔ 말레이시아 LZ

🚀 특징

  • 리전을 거치지 않고도 Local Zone 간 직접 이중화 가능
  • 지연을 더 줄이거나 지역 기반 장애 대응(Disaster Recovery) 설계 가능

 


 

🟧 시나리오 3: AWS Local Zone ↔ AWS Outposts

💡 목적

  • 고객사 전용 데이터센터(AWS Outposts)와 Local Zone 간 고속 연결 구성
  • 하이브리드로 구성하고 싶을 때 

✅ 구성

  • 금융사 또는 게임사 IDC + 인근 LZ
  • 정부기관이 갖고 있는 사설 IDC ↔ AWS

🚀 특징

  • 보안 또는 규제로 데이터를 IDC에 저장해야만 하는 기관
  • 네트워크 대역, 인프라 관리 주체를 나눌 수 있음

 


 

🟧 시나리오 4: AWS Local Zone ↔ On-Premise 데이터센터

💡 목적

  • 전통적인 고객 IDC와 Local Zone 간 직접 연결
    - 기존에 있던 데이터센터를 그대로 쓰면서 클라우드 일부 활용하고 싶을 때 구성 
  • Outposts가 없거나 도입이 어려운 경우

✅ 구성

  • 제조 공장의 물리 장비 ↔ 인근 Local Zone에 엣지 서버 구성
  • 교육기관, 의료기관의 로컬 센터와 AWS 연동

🚀 특징

  • 고객 IDC → Direct Connect 또는 VPN으로 LZ와 통신
  • 전통 온프레미스 ↔ 클라우드 연동 전략

 


 

 

 

 

AWS 리전에는 글로벌 사용자를 위한 서비스를 배포

로컬존은 해당 지역의 사용자를 위해 낮은 레이턴시로 서비스를 하기 위한 워커로드를 배포

 

Route53의 다양한 DNS Routing 정책을 활용하여 글로벌 사용자는 싱가폴 리전을 사용하고
태국내 사용자는 방코내 로컬 리전을 사용하도록 라우팅함

만약 방콕 내 로컬존에 장애가 발생한 경우라면 태국 내 사용자는 Route53 라우팅 정책에 의하여 
싱가폴리전의 서비스를 사용하도록 구성 

 

 

 

 

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

ELB(Elastic Load Balancer) vs ASG(Auto Scaling Group)  (4) 2025.08.12
WAF와 UTM의 차이점  (1) 2025.07.08
EBS(Elastic Block Store) 란 ?  (0) 2025.07.06
AWS LocalZone #1  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01

💾 EBS란 ?

 

  • EC2 인스턴스에 디스크처럼 연결되는 저장소 서비스
  • EC2 인스턴스의 루트 볼륨, 데이터 볼륨으로 사용
  • 종류별로 성능/비용/특성이 다름

 

 

📦 EBS 볼륨의 주요 유형


볼륨 타입 설명 용도 IOPS
gp2 General Purpose SSD (기본형) 범용 사용 기본 3 IOPS/GB
gp3 최신 SSD 타입, 비용 효율 ↑ 범용 + 세밀한 튜닝 가능 최대 16,000 IOPS
io1/io2 고성능 SSD 데이터베이스용 50~64,000 IOPS
st1/sc1 HDD 기반 빅데이터, 로그 저장 등 낮은 IOPS, 대용량
 

 

 

 

🧪 AWS CLI로 EBS 볼륨 수정 이력 조회

 

describe-volumes-modifications 명령어를 사용하여 EBS 볼륨의 최근 수정 이력을 확인할 수 있음

aws ec2 describe-volumes-modifications \
  --volume-ids vol-0abcd1234efgh5678

 

지정한 볼륨의 최근 수정 요청에 대한 정보를 반환

 

 


 

⚠️ 참고 : Local Zone은 gp2만 제공

Local Zone은 리전보다 작은 인프라이기 때문에 제공하는 서비스가 제한적

  • gp2만 지원되고 gp3, io2, st1 등은 지원하지 않음
  • 단, LA(Local Zone – Los Angeles)만 예외적으로 gp3까지 지원
    이유: LA는 Local Zone 중에서도 가장 먼저 도입된 ‘파일럿 지역’으로 일부 리전 수준 서비스가 확장 적용됨

 

🧠 서비스 영향도 

  • 성능 튜닝하려고 gp3을 사용하려 했는데 Local Zone에서는 선택 불가
  • terraform, CloudFormation, Launch Template에서 gp3으로 설정하면 배포 실패
  • 기존 리전 템플릿을 그대로 복사해 Local Zone에서 돌리면 안 됨

 

✅ 대응 방법

  1. Local Zone 배포 시 EBS 타입을 gp2로 강제 지정
  2. 또는, gp3 이상 성능이 필요한 워크로드는 Local Zone이 아닌 리전에 배치
  3. 자동화 템플릿에서는 if 조건 또는 variable override 등으로 AZ에 따라 volume type 분기 처리

 

 

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

WAF와 UTM의 차이점  (1) 2025.07.08
AWS LocalZone #2  (1) 2025.07.06
AWS LocalZone #1  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01
AutoScaling Vs Load Balancing  (0) 2025.03.02

🧠 AWS 인프라 구조

 




Region (리전) AWS의 데이터센터가 위치한 "국가 단위" 혹은 "대도시 단위" 물리적 위치
ex: 서울, 도쿄, 오하이오
Availability Zone
(AZ = 가용영역)
리전 내부의 물리적으로 분리된 데이터센터 그룹, 하나의 리전에 2~6개 AZ 존재
Edge Location CloudFront 등 콘텐츠 캐싱을 위한 위치
Local Zone ← 오늘의 주제 ⭐ 리전과 가까운 도시에 위치한 소규모 AWS 인프라스트럭처
 

 


🚩 Local Zone이란 ?

 

Local Zone은 AWS의 백본에 비해 현저히 작은 존, 일부 컴퓨팅/스토리지 서비스를 주요 리전이 아닌 고객과 더 가까운 특정 도시에서 제공하는 인프라

 

핵심 키워드

  • 지연 시간 감소 (Low latency)
  • 리전 외부의 물리적 확장
  • EC2, EBS, VPC, Load Balancer 등 제공
  • S3, IAM, Route53 등은 여전히 리전에 종속

 

 


 

🏗️ 필요성

 

✅ 기존 리전 기반 한계

  • 한국에서 서울 리전 외에 빠른 AWS 서비스를 쓰기 어려움
  • 게임, 실시간 미디어 처리, AR/VR, 엣지 컴퓨팅 등은 지연에 민감
  • 특히 미국 내 대도시에서는 오하이오, 버지니아까지 갔다 오면 50~100ms 이상 지연

 

💡 그래서 등장한 것이...

AWS 서비스를 내 도시 가까이에서 쓸 수 있다면?
➝ 바로 Local Zone

 

 

 


 

📍 Local Zone의 실제 배치 위치

 

✅ 대표적인 도시들 (2025 기준)

  • 미국: 로스앤젤레스, 시카고, 마이애미 등 15개 이상 도시
  • 해외: 뭄바이, 코펜하겐, 헬싱키, 하노이, 방콕, 베이징 인근 등 지속 확장 중
  • 대한민국은 아직 미도입 

 

🧩 Local Zone에서 가능한 서비스 

컴퓨팅 EC2 (특정 인스턴스 타입), ECS, EKS
스토리지 EBS(LA를 제외하고는 gp2볼륨만 제공),
FSx
네트워크 VPC, ENI, NAT GW, Load Balancer
기타 CloudWatch, IAM (리전 연동), SSM 등 일부

※ S3, RDS, Lambda, CloudFormation 등은 로컬존 내 직접 사용 불가 → 리전 호출 필요

 


🛰️ 구성 방식 (리전과의 관계)

 

Local Zone은 완전히 독립된 리전이 아님

  • AWS에서 말하길 "An extension of an AWS Region"
  • 즉, Local Zone은 항상 소속 리전 존재
    us-west-2 (오레곤)의 Local Zone: us-west-2-lax-1a 와 같은 형식 

 


 

📌 특징

  • VPC를 리전과 공유함
  • Local Zone 리소스는 서브넷 단위로 분리해 구성
  • 리전 리소스 ↔ 로컬존 리소스는 VPC 내부 통신 가능

 

 


 

 

✅ 추천 사용 사례

  • 🎮 게임 서버 : FPS, MOBA 같은 지연 민감형
  • 🎥 실시간 스트리밍/편집
  • 🏥 의료 영상 처리 : AI 분석 전 로컬 처리 필요
  • 🏙️ 스마트 팩토리 / 로컬 AI 인프라
  • 📍 법적 이유로 로컬 데이터 처리 필수인 경우

 


 

 

🧰 비용과 설정

  • Local Zone 사용 시 리전과는 별도로 EC2 가격 책정이 존재
  • 서브넷 생성 시 Local Zone 전용 AZ ID 선택 필요
  • opt-in 설정을 통해 Local Zone을 계정에서 활성화해야 사용 가능

EC2 - [영역] - Local Zones 에서 비활성을 활성으로 변경해줘야 리전VPC를 로컬존으로 확장 가능

 

 

 


 

🏁 결론

AWS Local Zone은 리전 수준의 AWS 서비스 일부를 고객 가까운 도시에 배치하여 저지연 고성능 처리를 가능하게 하는 하이브리드 클라우드 솔루션

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

AWS LocalZone #2  (1) 2025.07.06
EBS(Elastic Block Store) 란 ?  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01
AutoScaling Vs Load Balancing  (0) 2025.03.02
[AWS#21] CDN 서비스  (0) 2025.02.13

🔰 1. AWS Global Backbone란?

 

 

 

전 세계 AWS 리전(Region), 가용 영역(Availability Zone), 엣지 로케이션(Edge Location), Direct Connect 위치 등을 연결하는 전용 고속 네트워크 인프라

 

이 백본망은 AWS 고객이 사용하는 서비스들이 빠르고 안전하게 통신할 수 있도록 돕는 핵심 인프라로 특히 다음과 같은 목적에 사용

  • 리전 간 데이터 전송
  • 글로벌 콘텐츠 전송 가속
  • 기업의 온프레미스 ↔ 클라우드 연결 (Direct Connect)
  • 사용자와 가까운 위치에서 응답 처리 (CloudFront, WAF 등)

 


🧱 2. 주요 구성요소 설명

 

📍 리전 (Regions) 및 가용 영역

  • 현재 25개 리전80개 이상의 가용 영역을 운영
  • 각 리전은 서로 독립적이며 최소 2개 이상의 AZ(Availability Zone)로 구성
  • 리전 간은 AWS 백본망으로 연결되어 있으며 다중화된 연결로 고가용성을 보장

 

🌐 Edge Network Location (220개)

  • 사용자의 위치에 더 가까운 곳에서 콘텐츠를 제공하는 엣지 로케이션
  • Amazon CloudFront, AWS Global Accelerator, Route 53 등 엣지 서비스가 동작

 

📡 Direct Connect Location (108개)

  • 기업이 자사의 온프레미스 데이터센터와 AWS 간을 전용 회선으로 연결하는 지점
  • 한국에는 2개 지점: 가산(Gasan), 평촌(Pyeongchon)

 


⚙️ 3. 기술적 특징

 

⚡ 100Gbps 이상 고속 연결

  • 리전 간 연결은 이중화 및 고속(100Gbps+) 링크로 구성되어 서비스 안정성을 확보

 

🔐 암호화와 보안

  • 백본 내 모든 트래픽은 기본적으로 암호화
  • AWS 자체 네트워크를 통해 전달되므로 외부 인터넷보다 훨씬 안전

 

🌍 중국CIC 제외 (중요) 

  • 중국 리전은 글로벌 백본과 독립적으로 운영
  • ICP 라이선스 및 로컬 ISP 통제에 따른 분리 구조

 


🧠 4. 고급 개념 및 활용 사례

 

① AWS Transit Gateway 및 VPC Peering과의 연결

  • 여러 리전의 VPC를 Transit Gateway 또는 Peering을 통해 연결 시 AWS Global Backbone을 활용
  • 서울 ↔ 도쿄 간 고속 연결 구성 시 글로벌 백본망 이용

 

② CloudFront 콘텐츠 전송

  • 콘텐츠를 전 세계에 빠르게 배포할 수 있도록 엣지 로케이션과 백본을 통해 연결
  • Origin 서버가 미국이라도, 한국 사용자는 서울 엣지 로케이션을 통해 빠르게 접속 가능

 

Hybrid 환경의 Direct Connect 활용

  • 대기업 고객은 전용선으로 AWS와 연결해 지연 시간을 줄이고 보안성을 확보
  • 백본망을 통해 다른 리전으로 빠르게 연계 가능

 

 


🌍 CloudFront + AWS Global Accelerator 연계

 

✅ 개념 요약

목적 콘텐츠 전송(CDN) TCP/UDP 애플리케이션 가속
프로토콜 HTTP/HTTPS 모든 TCP/UDP
대상 정적/동적 웹 콘텐츠 애플리케이션(웹, 게임 등)
경로 엣지 → CloudFront POP 전 세계 AWS 백본망(Global Backbone)
 

🧩 연계 시 장점

CloudFront는 콘텐츠 전달에 최적화된

반면 Global Accelerator는 사용자 ↔ 애플리케이션 간 경로를 단축하여 전반적인 응답 속도 및 안정성을 개선

  • 사용자의 요청은 가장 가까운 AWS 글로벌 가속기 엔드포인트로 진입
  • 이후에는 AWS 백본망을 통해 CloudFront 및 오리진 서버까지 빠르게 전달
  • 지리적으로 멀거나 대륙 간 요청에서도 빠른 처리 가능

한국 사용자가 미국 오리진 콘텐츠 요청 → 한국 엣지 POP + Global Accelerator → 백본망 통해 미국 CloudFront 오리진까지 빠른 경로 확보

 

 

📖 백본망(Backbone Network)이란?

 

✅ 정의

여러 개의 로컬 네트워크(Local Network) 지점 네트워크(Branch Network) 또는 데이터센터 간을 연결하는 고속 중심 네트워크
즉, 각 분산된 네트워크를 고속으로 연결하는 '중추적인 데이터 고속도로' 역할

 

✅ 특징

고속성 일반 네트워크보다 높은 대역폭과 낮은 지연
중앙집중형 or 계층형 구성 지역망 → 본사망 → 데이터센터망 식으로 구조화
이중화 및 장애 대비 장애 발생 시 자동 우회 경로로 전환 가능
보안 사설망 또는 전용회선 사용으로 높은 보안성 확보
 

📌 각 지역 사무실에서 본사 데이터센터로 연결되는 연결망, 여러 IDC 간 데이터 복제/전송 등

 

 
  [AWS 리전]
       |
   [DX 전용회선] ←→ 백본망 (100Gbps 다중화)
       |
[여의도 DC (IDC1)]  
   /     |       \
부산   대구     평택 (전용선 또는 MPLS)

✅ 구성 요소별 설명


여의도 IDC (메인) 각 사업장 시스템의 중심 데이터 허브
전용망 (전국망) 부산, 대구, 기흥 등은 자체 광망/전용회선 또는 MPLS 회선으로 백본에 연결
L2/L3 스위치 + SD-WAN 트래픽 제어, 장애 시 우회 라우팅, 서비스 분리 (예: ERP vs CCTV vs VoIP)
DX 또는 VPN AWS 등 클라우드 리전과의 연결은 DX 또는 고가용 VPN 구성 사용
보안 관제 (SOC) 전 구간 암호화 및 침입탐지/트래픽 분석 수행
 

✅ 실질적 효과

  • 지연시간 최소화: 수도권 ↔ 부산 지사 간 5~15ms 수준 유지
  • 보안 통신: 민감 데이터 (의료, 금융 등)도 자체 백본 통해 안전하게 전송
  • 통합관제/운영: 트래픽 흐름 실시간 모니터링, 장애시 자동 전환 (예: NMS, SDN)

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

EBS(Elastic Block Store) 란 ?  (0) 2025.07.06
AWS LocalZone #1  (0) 2025.07.06
AutoScaling Vs Load Balancing  (0) 2025.03.02
[AWS#21] CDN 서비스  (0) 2025.02.13
[AWS#20] Route53  (0) 2025.02.13

둘 다 시스템의 성능과 가용성을 유지하는데 중요한 역할을 수행하지만 목적과 기능이 다름.

 

 

  1. 오토스케일링 (Auto Scaling) = 확장  
    • 목적: 트래픽의 변화에 맞춰 자동으로 인스턴스의 수를 조정하는 것.
    • 기능:
      • 트래픽이 증가하면 새로운 인스턴스를 자동으로 추가하고,
      • 트래픽이 감소하면 인스턴스를 자동으로 종료하여 비용을 절감.
    • 적용 대상: EC2 인스턴스와 같은 자원을 자동으로 확장하거나 축소.
    • 장점: 시스템의 성능을 최적화하고, 비용 효율적으로 리소스를 관리할 수 있음.
  2. 로드 밸런싱 (Load Balancing) = 분배 
    • 목적: 들어오는 트래픽을 여러 인스턴스에 균등하게 분배하는 것.
    • 기능:
      • 여러 서버 또는 인스턴스에 트래픽을 효율적으로 분배하여, 개별 서버의 과부하를 방지하고 서비스 가용성을 높임.
    • 적용 대상: 웹 서버, 애플리케이션 서버 등 다수의 서버에 트래픽을 분산.
    • 장점: 시스템의 고가용성성능 최적화

      .

결론

  • 오토스케일링은 시스템의 크기를 자동으로 조정하는 반면,
  • 로드 밸런싱은 트래픽을 여러 인스턴스에 분배하여 서버의 과부하를 방지하고 고가용성을 유지합니다.

 

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

AWS LocalZone #1  (0) 2025.07.06
AWS Global Backbone 이란 ?  (1) 2025.07.01
[AWS#21] CDN 서비스  (0) 2025.02.13
[AWS#20] Route53  (0) 2025.02.13
[AWS#19] CloudFront  (1) 2025.02.13

 

 

 

 

 

 

 

# 일반적인 도메인으로 요청할 시 

대한민국 -> 상파울루로 요청

 

 

 

 

 

# CloudFront 로 요청할 시

대한민국 -> 엣지서버로 요청

 

 

 

 

 

 

 


 

# 인증서 발급

(인증서는 버지니아 북부에 발급해야함, 그래야 CF랑 연결할 수 있음)

[인증서] - [인증서 요청]

 

- 잠시 기다리면 됨

 

 

 

 

 

# CloudFront 

 

https://d2j9rz5iobax0i.cloudfront.net

 

 

위의 도메인으로 접속하는 것이 아닌 cdn.hyeing.shop 으로 접속하기 위해서 레코드 생성

 

 

 

 


# 테스트

 

 

 

 

 

 

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

AWS Global Backbone 이란 ?  (1) 2025.07.01
AutoScaling Vs Load Balancing  (0) 2025.03.02
[AWS#20] Route53  (0) 2025.02.13
[AWS#19] CloudFront  (1) 2025.02.13
[AWS#18] WAF  (0) 2025.02.13

 

# 사전 준비

 

 

 

 

ns-634.awsdns-15.net                      205.251.194.122
ns-1282.awsdns-32.org                    205.251.197.2
ns-1754.awsdns-27.co.uk                 205.251.198.218
ns-393.awsdns-49.com                     205.251.193.137

 

 

 

 

# 가비아에 가서 네임서버 등록

 

 


 

 

 

MyWeb1            52.78.133.243       10.0.1.101
MyWeb2            43.203.26.58         10.0.2.101

 

MyALB            MyALB-1102736887.ap-northeast-2.elb.amazonaws.com
                        http://MyALB-1102736887.ap-northeast-2.elb.amazonaws.com



 

 

# ALB 로 접속하여 정상적으로 분산처리 되는지 확인

 

 

 

# Route53 

원래 기존 ALB 의 도메인은 http://MyALB-1102736887.ap-northeast-2.elb.amazonaws.com 이지만,

www.hyeing.shop  으로 사용하겠다라고 정의 

 

 

- 이렇게 해당 도메인으로 접근 가능

 

 

 

 


# 장애 조치 라우팅

 

 


평상시 트래픽 

 

 

 

 

장애 시 같은 도메인으로 아래와 같이 접속 가능

 

 

 

 


 

[상태 검사] - 생성

 

 

로드밸런서에서도 대상그룹이 정상적으로 살아있는지 확인하기 위해 헬스 체크함

http 요청보내고 응답 받으면 정상

 

 

 

[호스팅 영역] - [레코드 생성]

호스트는 돈주고 사는것이 아닌 원하는 것으로 입력 가능

 

 

# 테스트 

 

MyWeb1번이 응답

 

 


 

 

 

 

MyWeb1번 장애 시 MyWeb1번 응답

 

 

장애가 복구되면 다시 MyWeb1로 트래픽이 복구됨.

 

 

 

 

 

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

AutoScaling Vs Load Balancing  (0) 2025.03.02
[AWS#21] CDN 서비스  (0) 2025.02.13
[AWS#19] CloudFront  (1) 2025.02.13
[AWS#18] WAF  (0) 2025.02.13
[AWS#17] 보안 그룹 & NACL  (0) 2025.02.12


대한민국                          브라질

                   ----------->

                     요청

 

거리가 멀수록 느려짐

사용자 많아질수록 트래픽 양이 증가하기 때문에 느려짐

 

 

엣지 서버로 요청을 보내게 함

엣지 서버가 받아서 브라질로 요청

브라질에서 엣지 서버로 정보를 보냄

 

엣지 서버에 잠시 저장 (캐싱)

대한민국에게 엣지 서버가 응답

 

첫번째는 속도가 조금 느림

두번째로 똑같이 요청한다고 한다면

엣지 서버에는 저장이 되어 있으므로 바로 응답을 보냄

 

CDN 서비스라고 함 = CloudFront 

 

 

 

 

aws 는 cloudfront 서비스를 제공하기 위해 리전마다 엣지 서버를 둠

 

 


 

# 서울리전에 EC2 생성

 

 

yum -y install httpd
echo "<h1>MyWeb1 Test Page</h1>" > /var/www/html/index.html
systemctl enable --now httpd
tail -f /var/log/httpd/access_log

- EC2 인스턴스에 SSH로 접근하여 명령어 수행

 

 

 

* 내 PC -> EC2인스턴스로 직접 접속 

 

 

 


 

 

# CloudFront 

 

 

 

해당 EC2 인스턴스를 엣지서버를 통해 접근할 수 있는 도메인 생성

https://d1mee513xfn8a0.cloudfront.net

 

 

 

- 위의 도메인으로 접속 시도시 처음에 한번 접속 로그를 남김
   이후에 접속 시도시에 접속 로그가 남지 않음.

 

즉, PC -> 엣지 서버로 요청 | 엣지 서버 -> EC2서버로 요청

EC2 -> 엣지로 응답 | 엣지 서버 -> PC로 응답

이후에 PC 가 요청시에는 엣지 서버가 바로 바로 응답해줌

 

 

index 파일 수정 후 

 

EC2 서버로 직접 접근 

 

 

CloudFront 로 접근 

변경된 index로 응답을 하지 않음

 

엣지 서버에는 아까 요청해서 받아온 인덱스 파일로 기록 되어 있음
엣지 서버에 캐싱된 내용은 전 인덱스 파일이므로

동적 데이터 파일 같은 경우에는 바로 바로 반영이 안됨.
바로 반영하기 위해서는 무효화를 생성해야함.

 

 

 

 

 

설정하면 변경된 인덱스를 적용해줌 

 

인덱스 파일이 변경될 때마다 무효화를 해줘야함
- AWS 람다를 이용하여 이벤트가 발생할 경우 자동으로 무효화 하도록 하는 방법 수행
- SDK를 이용하여 무효화가 자동으로 될 수 있는 코드를 만들어서 적용해도됨 

 

 

 

 


# S3 에 CloudFront 연결

 

미국 S3 

100G 파일이 존재한다고 한다면

 

 

- 버킷 이름은 중복되게 사용할 수 없음.

 

- S3 에 공유할 파일 업로드 

 

 


 

 

 

# 배포 생성

 

 

https://d2qcqeol5ie8c4.cloudfront.net

 

 

 

 

 

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

[AWS#21] CDN 서비스  (0) 2025.02.13
[AWS#20] Route53  (0) 2025.02.13
[AWS#18] WAF  (0) 2025.02.13
[AWS#17] 보안 그룹 & NACL  (0) 2025.02.12
[AWS#16] VPC Flow Log  (0) 2025.02.11

+ Recent posts