인프라 기본 용어 정리

*필요한 용어들 중 AI로 생성된 설명을 모아둔 것입니다.


1. AWS 환경이란?

AWS (Amazon Web Services)는 클라우드 컴퓨팅 서비스입니다. 서버, 스토리지, 데이터베이스, 네트워크 등을 인터넷을 통해 빌려서 사용하는 구조예요.

즉, 우리가 직접 서버를 사서 관리하는 게 아니라, 필요한 만큼만 빌려서 쓰고, 쓴 만큼 돈을 내는 구조입니다.

---

2. VPC (Virtual Private Cloud)

VPC는 AWS에서 제공하는 논리적으로 격리된 네트워크 공간이에요.

• 하나의 VPC 안에는 여러 개의 서브넷(Subnet) 을 만들 수 있어요.
• 서브넷은 Public Subnet / Private Subnet 으로 나뉘어요.
• VPC 안에서는 서버들끼리 내부 통신 가능.

비유하자면?
AWS 안에 내 전용 데이터센터를 만든다고 생각하면 됩니다.

---

3. Bastion, SSH, RDP의 역할

✅ Bastion Host

• 외부에서 내부의 Private 서버에 접속할 수 있게 중간에서 연결을 중계해주는 서버.
• 보통 Public Subnet에 하나 두고, 내부 Private 서버들에는 직접 접근 못하게 해요.

✅ SSH (Secure Shell)

• 리눅스 서버에 접속할 때 사용하는 프로토콜/도구. 터미널로 접속해 명령어 입력 가능.

✅ RDP (Remote Desktop Protocol)

• 윈도우 서버에 접속할 때 사용하는 원격 데스크톱 접속 프로토콜. GUI 화면을 보여줌.
  => 보통 DB같은거 관리 툴 UI에서 보려고 쓰는 경우가 있음

---

4. Security Group과 Private Subnet

✅ Security Group

• 방화벽 역할을 하는 설정.
• 인바운드(들어오는) / 아웃바운드(나가는) 트래픽을 포트 단위로 허용/차단 가능.

✅ Private Subnet

• 외부 인터넷에서는 직접 접속할 수 없는 서브넷.
• Bastion Host 등을 통해 우회해서 접속하거나, 내부 서비스끼리만 사용.

---

5. 동일한 서버를 2개의 Region에 두는 이유

• Region = 물리적 위치 (서울, 도쿄, 프랑크푸르트 등)
• 동일한 서버를 여러 Region에 두는 이유는:
  • 재해 복구 (DR): 한 지역에 장애 발생해도 다른 지역에서 서비스 유지.
  • 지연 최소화: 사용자와 가까운 지역에서 빠르게 서비스 제공.
  • 법적/데이터 규제 대응: 특정 데이터는 특정 국가에 보관해야 할 때.

---

6. S3 (Simple Storage Service)

• AWS의 파일 저장소 서비스.
• 이미지, 로그파일, 동영상, 백업 등 정적 파일 저장에 최적화.
• 자동으로 중복 저장되고 내구성이 매우 높음 (99.999999999%).

즉, 파일을 업로드하고 URL로 접근할 수 있는 클라우드 디스크 같은 느낌이에요.

---

7. ALB (Application Load Balancer)

• 클라이언트의 요청을 여러 서버로 부하 분산해주는 서비스.
• HTTP/HTTPS 기반에서 요청 경로, 호스트명 기반 라우팅 가능.
• 예:
  • /api → API 서버
  • /admin → 어드민 서버

사용자는 ALB 하나만 보고 요청하면 되고, 실제 처리는 여러 서버가 나눠서 함.

 

8. IGW (Internet Gateway)

정의:
IGW는 AWS VPC 내부의 리소스(EC2 등) 가 인터넷과 통신할 수 있도록 해주는 출입구 역할을 합니다.

🔹 왜 필요하냐면?

VPC 안의 서버는 기본적으로 외부와 차단되어 있어요.
인터넷을 사용하려면 IGW를 통해 나가거나 들어와야 해요.

🔹 작동 원리

1. VPC에 IGW를 붙이고
2. Public Subnet의 라우팅 테이블(Route Table) 에
   • 0.0.0.0/0 → IGW 설정을 추가해야
3. 그때부터 그 서브넷에 있는 EC2가 인터넷에 나가거나 들어올 수 있음.

🔹 그림으로 요약:

[사용자 브라우저]
        ↓ DNS 요청
[Route 53: api.myapp.com → ALB 주소 반환]
        ↓
[ALB: URL 경로 분석 → /v1/user]
        ↓
[적절한 EC2 혹은 Fargate 인스턴스에 요청 전달]

---

9. 도메인 기반 분산 (Route 53 + ALB 등)

🔹 핵심 목적

사용자가 웹사이트 도메인(예: myapp.com) 으로 접속하면,
요청을 적절한 서버(지역/버전/기능별 등) 로 자동 분산하는 기술입니다.

🔹 어떤 서비스가 있냐면:

1. Route 53: AWS의 DNS 서비스
   • 도메인을 IP로 바꿔주고
   • 요청을 여러 리전 또는 ALB로 지능적으로 분산 가능
2. ALB (Application Load Balancer):
   • 요청 URL이나 Host 이름에 따라 서버로 라우팅
   • 예: /admin → Admin 서버, /user → User 서버

---

💡 예시: 도메인 기반 분산 시나리오

🧑‍💻 사용자 요청:

GET https://api.myapp.com/v1/user

🔁 처리 흐름:

[사용자 브라우저]
        ↓ DNS 요청
[Route 53: api.myapp.com → ALB 주소 반환]
        ↓
[ALB: URL 경로 분석 → /v1/user]
        ↓
[적절한 EC2 혹은 Fargate 인스턴스에 요청 전달]

 

---

🧠 요약

개념설명

IGW	VPC와 인터넷 간 트래픽의 관문 (인터넷 출입구)
도메인 기반 분산	도메인/경로에 따라 트래픽을 여러 서버나 리전으로 나눔 (Route 53 + ALB)

 

10.  Fargate

AWS ECS나 EKS에서 실행되는 컨테이너를 자동으로 실행해주는 실행 환경
즉, EC2 없이도 컨테이너를 띄울 수 있게 해주는 서비스입니다.

🔧 Fargate를 사용하면...

• EC2를 직접 구성, 관리, 업데이트 안 해도 됨
• CPU/메모리 등 리소스를 컨테이너 단위로 설정
• 사용한 만큼만 요금 청구됨

---

✅ Fargate vs EC2 차이

항목FargateEC2 (ECS EC2 Launch)

인프라 관리	❌ 없음 (서버리스)	✅ EC2 인스턴스 직접 관리
자동 스케일링	✅ 컨테이너 단위	✅ 인스턴스 + 컨테이너 관리
운영 복잡도	매우 낮음	높음 (보안패치, 용량 모니터링 등)
비용	초 단위 과금 (유연)	고정 비용 기반
커스텀 OS/네트워크	제한적	유연함 (EC2를 마음대로 설정 가능)

 

---

✅ 언제 Fargate를 쓰면 좋을까?

• 빠르게 배포하고 싶을 때 (배포 자동화 + 서버 관리 X)
• EC2 유지 관리 부담을 줄이고 싶을 때
• 짧게 돌았다가 종료되는 잡성 작업 (예: 크론 잡, 배치 작업)
• 마이크로서비스 구조에서 서비스마다 스케일링이 필요할 때

---

✅ 사용 흐름 (ECS 기준)

1. Docker 이미지 빌드 & ECR 푸시
2. ECS 서비스 → Fargate로 실행 설정
3. CPU/메모리 설정 (예: 512MiB / 0.25 vCPU)
4. 실행 시 AWS가 알아서 컨테이너를 띄움

---

✅ 예시 그림

[ Docker 이미지 ]
      ↓ (빌드 후 ECR 푸시)
[ Amazon ECS ]
      ↓
[ Fargate ]
      ↓
[ 자동으로 컨테이너 실행 (서버는 AWS가 관리) ]

 

---

📦 요약 한 줄

Fargate = EC2 없이 ECS 컨테이너만 자동 실행하게 해주는 완전 관리형 플랫폼
→ 컨테이너만 신경쓰면 되고, 서버는 AWS가 알아서 해줌.

 

11. NAT

NAT (Network Address Translation)
: 사설망(Private Subnet)에 있는 서버가 공인 IP 없이 외부 인터넷과 통신할 수 있게 해주는 기술입니다.

즉, 프라이빗 서브넷 안의 EC2가 인터넷에 나가고 싶을 때 필요한 중간 출구!

---

✅ 왜 NAT가 필요할까?

VPC 안에서 Private Subnet 에 있는 서버는 외부 인터넷과 직접 통신이 안 됩니다.
하지만 이 서버도 보안 업데이트나 외부 API 요청을 위해 인터넷에 “요청은 보내야” 하죠?

📦 이때 NAT Gateway / NAT Instance 를 통해 요청은 외부로 보내고,
응답도 NAT를 통해 받도록 구성하는 거예요.

---

✅ 동작 방식 요약

예: Private Subnet에 있는 EC2가 yum update 명령으로 인터넷에서 패키지 설치 시도

1. EC2 → 인터넷 요청
2. 라우팅 테이블을 통해 NAT Gateway로 전달
3. NAT Gateway가 EC2 대신 요청 전송
4. 외부 서버가 응답
5. NAT Gateway가 응답을 EC2에 전달

---

✅ NAT 종류

타입설명특징

NAT Gateway	AWS에서 제공하는 관리형 서비스	✅ 자동 확장, 안정성 높음, 유료
NAT Instance	EC2 인스턴스로 직접 NAT 구성	✅ 저렴하지만 관리 부담 있음 (추천 ❌)

 

실무에서는 거의 NAT Gateway만 사용합니다.

---

✅ 구성 예시

[VPC]
 ├── Public Subnet (NAT Gateway 존재)
 │     └── NAT Gateway (공인 IP 있음)
 └── Private Subnet (EC2 존재)
       └── EC2 → NAT → 인터넷 접근 가능 (단, 외부에서 들어오는 건 불가)

---

✅ NAT의 핵심 역할 요약

항목설명

보안 강화	외부에서 직접 접근할 수 없게 하면서도, 내부 서버는 외부로 나갈 수 있음
인터넷 요청 가능	Private Subnet에 있는 서버가 yum, apt, docker pull, 외부 API 등 사용 가능
IP 마스킹	사설 IP → NAT가 가진 공인 IP로 바꿔서 외부에 노출함

 

---

✅ 실무 팁

• NAT Gateway는 퍼블릭 서브넷에 있어야 함
• Private Subnet의 라우팅 테이블에 0.0.0.0/0 → NAT Gateway 가 있어야 함
• AZ 별로 하나씩 두면 고가용성(HA) 구성 가능

---

📌 정리 한 줄 요약

NAT = 내부(Private Subnet) 서버가 공인 IP 없이도 외부로 나가게 해주는 통로!

---

 

12. VPC 피어링(VPC Peering)

VPC Peering은 말 그대로 두 개의 VPC 간에 트래픽을 직접 주고받을 수 있도록 연결하는 것입니다.

서로 다른 네트워크 대역의 VPC 간에 사설 IP 기반으로 직접 통신할 수 있게 만들어주는 AWS 기능이에요.

---

🔧 왜 필요할까?

• 회사 내에서 서비스별로 VPC를 나누는 경우:
  • 예: metaverse-vpc와 ecosystem-vpc
    👉 이 둘이 서로 API 호출, DB 접근, 데이터 교환을 해야 함
• 그런데 기본적으로 VPC는 서로 완전히 격리된 네트워크라 통신이 불가능함.
• 이럴 때 VPC 피어링을 설정하면, 두 VPC가 마치 하나의 네트워크처럼 통신 가능!

---

✅ 예시 시나리오

[ VPC-A (10.0.0.0/16) ]            [ VPC-B (10.1.0.0/16) ]
        EC2-A -------------------> EC2-B
           ↖       VPC 피어링       ↙

• EC2-A → EC2-B 접속 (예: API, DB 접속)
• 서로 다른 VPC지만 사설 IP로 직접 통신 가능

---

✅ VPC Peering의 구성요소

항목설명

Peering Connection	연결 자체 (A VPC ↔ B VPC)
라우팅 테이블 설정	두 VPC 모두의 라우팅 테이블에 피어링 경로 추가 필요
보안 그룹	서로 통신하려면 보안 그룹에도 해당 IP 대역 허용 필요

 

❗ 단순히 피어링 연결만 한다고 끝이 아닙니다.
반드시 라우팅 테이블 + 보안 그룹 설정도 같이 해야 접속됩니다.

---

✅ 실무 기준 체크리스트

체크포인트설명

피어링 연결 상태	Active 상태인지
라우팅 테이블	10.1.0.0/16 → peering-xxx 이런 경로가 양쪽 VPC에 있는지
보안 그룹	대상 VPC의 사설 IP 대역을 Inbound로 허용했는지
겹치는 CIDR 없음	서로 다른 CIDR이어야 피어링 가능 (중복 불가)

 

---

❌ VPC 피어링이 안 되는 경우 예시

• 라우팅 테이블 누락
• 보안 그룹에서 상대 VPC 대역 차단
• CIDR 중복
• Cross-region인데 지원되지 않는 리소스를 쓰는 경우 (ex: 일부 AWS 서비스)

---

✅ 요약

VPC 피어링 = AWS 내 두 VPC를 직접 연결해서 사설 IP로 통신하게 해주는 기능
✅ 같은 계정, 다른 계정, 같은 리전, 다른 리전 모두 가능
❗ 연결 후에도 반드시 라우팅 + 보안그룹 설정이 필요