* 목차
[1] 네트워킹 기본 사항
[2] Amazon VPC
[3] VPC 네트워킹 - 개념
[4] VPC 보안
[5] Amazon Route 53
[6] Amazon CloudFront
[1] 네트워킹 기본 사항
☑️ 네트워크
- 네트워크는 서브넷으로 구성됨
- 서브넷1과 서브넷2는 분리되어있으며 서로 통신하기위해서는 라우터가 필요함
☑️ IP주소
| 192. | 0. | 2. | 0 |
| 11000000 | 00000000 | 00000010 | 00000000 |
- 총 32비트로 구성됨 (8비트/8비트/8비트/8비트)
- 총 4개로 분할
☑️IPv4 및 IPv6 주소
- IPv4 주소(32비트): 192.0.2.0
- IPv6 주소(128비트): 2600:1f18:22ba:8c00:ba86:a05e:a5ba:00FF (=무한에 가까운)
☑️ Classless Inter-Domain Routing (CIDR)
- /24가 포함된 주소
- 24비트로 고정
| 네트워크 식별자(라우팅 접두사) | 호스트식별자 | ||
| 192.0.2 | .0 | /24 | |
| 1100000 00000000 00000010 | 00000000 ~ 11111111 | ||
| 고정 | 유동적 | 고정된 비트수를 알려줌 | |
☑️ Open Systems Interconnection(OSI) 모델
- 기본 상식으로 알아두기
| 계층 | 번호 | 기능 | 대표 프로토콜/주소 |
| 애플리케이션 | 7 | 사용자가 네트워크에 접근할 수 있는 창구 역할 | HTTP(S), FTP, DHCP, LDAP |
| 프레젠테이션 | 6 | 애플리케이션 계층이 데이터를 읽을 수 있도록 보장, 암호화 | ASCII, ICA, SSL |
| 세션 | 5 | 순서에 따른 데이터 교환 지원 | NetBIOS, RPC |
| 전송 | 4 | 호스트 간 통신을 지원하는 프로토콜 제공 | TCP, UDP |
| 네트워크 | 3 | 라우팅 및 패킷 전달(라우터) | IP, ICMP |
| 데이터 링크 | 2 | MAC 주소 기반의 근거리 통신 (스위치) 동일한 LAN 네트워크 (허브 및 스위치)에서 데이터 전송 |
MAC, ARP |
| 물리 | 1 | 0과 1의 신호를 실제 전기적/광학적 형태로 전송 물리적 미디어를 통한 원시 비트스트림 전송 및 수신 |
케이블, 전기 신호, 비트 |
[2] Amazon VPC
☑️ Amazon VPC
- 논리적으로 격리된 영역을 프로비저닝 할 수 있음
- 다수의 서브넷 생성 가능
- IP 주소 범위 선택
- 라우팅 테이블 및 네트워크 게이트웨이 구성할 수 있음
- 다계층 보안 설정 가능
- VPC에 대한 네트워크 구성을 사용자 지정할 수 있도록 지원
☑️ VPC 및 서브넷
- VPC:
- VPC는 리전 단위로 설정 가능, 리전 내 VPC 설정, 단일 리전
- 다른 VPC와는 논리적으로 격리됨
- 고객 AWS 계정 전용
- 단일 AWS 리전에 속하며 여러 가용 영역에 걸쳐 구현될 수 있음
- 서브넷:
- VPC를 분할하는 IP 주소의 범위
- 단일 가용 영역에 속함
- 퍼블릭 또는 프라이빗으로 분류됨(퍼블릭:외부 VPC와 통신 가능, 프라이빗: 외부 VPC와 통신 불가능)
☑️ IP 주소 지정
- VPC를 생성할 때 IPv4 CIDR 블록 (프라이빗 IPv4 주소 범위)에 VPC 할당
- VPC를 생성한 후에는 주소 범위를 변경할 수 없음
- 가장 큰 IPv4 CIDR 블록 크기는 /16
- 가장 작은 IPv4 CIDR 블록 크기는 /28
- IPv6도 지원(다른 블록 크기 제한 적용)
- 서브넷의 CIDR 블록은 중첩될 수 없음
| x.x.x.x/16 또는 65,536개 주소(최대) = 가장 큰 블록 |
| x.x.x.x/28 또는 16개 주소(최소) = 가장 작은 블록, 32-28=4, 4비트 |
☑️ 예약된 IP 주소
예: IPv4 CIDR 블록이 10.0.0.0/16인 VPC에 총 65,536개의 IP 주소가 있습니다. 이 VPC에는 동일한 크기의 서브넷이 4개 구성되어 있습니다. 각 서브넷에 251개의 IP 주소만 사용할 수 있습니다.
- VPC내 4개의 서브넷
- VPC는 /16, 각각의 서브넷은 /24
☑️ 퍼블릭 IP 주소 유형
| 퍼블릭 IPv4 주소 | 탄력적 IP 주소 |
| 탄력적 IP 주소를 통해 수동으로 할당 | AWS 계정과 연결됨 |
| 서브넷 수준에서 퍼블릭 IP 주소 자동 할당 설정을 통해 자동으로 할당 | 언제든지 할당하고 다시 매핑할 수 있음 |
| 외부와 통신 가능, 동적으로 | 고정 IP, 추가 요금이 적용될 수 있음 |
☑️ 탄력적 네트워크 인터페이스
- 탄력적 네트워크 인터페이스는 다음을 지원하는 가상 네트워크 인터페이스
- 인스턴스에 연결할 수 있음
- 인스턴스에서 분리하고 다른 인스턴스에 연결하여 네트워크 트래픽 리디렉션
- 추가적인 네트워크, ip를 여러개 할당받고 싶을 때 사용함
- 새 인스턴스에 다시 연결될 때 속성이 그대로 적용, 인스턴스를 변경해도 네트워크 설정 유지
- VPC의 각 인스턴스마다 기본 네트워크 인터페이스가 있어서 VPC의 IPv4 주소 범위에 속하는 프라이빗 IPv4 주소가 이 인터페이스에 할당
☑️ 라우팅 테이블 및 경로
- 라우팅 테이블에는 서브넷에서 네트워크 트래픽을 보내도록 구성할 수 있는 규칙(또는 경로) 세트가 포함되어 있음
- 각 경로는 대상 위치와 대상을 지정합니다.
- 기본적으로 모든 라우팅 테이블에는 VPC 내부 통신을 위한 로컬 경로가 포함되어 있습니다.
- 각 서브넷은 라우팅 테이블(최대 1개)과 연결되어야 합니다.
- 기본 라우팅 테이블에서 대상위치 명시함
☑️ 정리
-🌍 리전
└─ 📦 VPC (가상 네트워크)
├─ 📶 서브넷 1 (가용영역 A)
│ └─ EC2 인스턴스
├─ 📶 서브넷 2 (가용영역 B)
│ └─ EC2 인스턴스
├─ 📋 라우팅 테이블
└─ 📐 CIDR 블록
-📦 VPC (10.0.0.0/16)
│
├── 📶 Subnet A (10.0.1.0/24, AZ-a)
│ └─ 퍼블릭 서브넷
│ └─ EC2 인스턴스 + 퍼블릭 IP
│
├── 📶 Subnet B (10.0.2.0/24, AZ-b)
│ └─ 프라이빗 서브넷
│ └─ EC2 인스턴스 (인터넷 못 씀)
│
└── 📋 Routing Table
├─ 10.0.0.0/16 → local (삭제 불가)
└─ 0.0.0.0/0 → Internet Gateway (퍼블릭 통신 허용)
- 리전
- 한 리전 안에 여러개의 VPC 생성 가능
- VPC는 여러 리전에 걸쳐 있을 수 없음
📍 서울 리전 (ap-northeast-2)
├─ VPC-1 (10.0.0.0/16)
├─ VPC-2 (192.168.0.0/16)
└─ VPC-3 (172.31.0.0/16)
📍 도쿄 리전 (ap-northeast-1)
└─ VPC-1 (10.1.0.0/16) ← 서울 리전과 완전 별개
| VPC (Virtual Private Cloud) | AWS 내 내 전용 가상 네트워크 공간 → **IP 주소 대역(CIDR)**을 갖고, 서브넷을 나눌 수 있음 |
| 서브넷 (Subnet) | VPC 안의 작은 네트워크 조각 → 하나의 가용 영역(AZ)에만 속할 수 있음 → 퍼블릭/프라이빗으로 구분 퍼블릭 서브넷: 인터넷과 직접 통신 가능, 직접 인터넷 연결 가능 프라이빗 서브넷: 인터넷과 직접 통신 불가능, 직접 인터넷 연결 불가능 |
| 가용 영역 (AZ) | 하나의 리전안에 있는 물리적 데이터센터 → 고가용성 위해 여러 AZ 활용 |
| CIDR 블록 | VPC나 서브넷의 IP 주소 범위 정의 방식 예: 10.0.0.0/16 → IP 총 65,536개 |
| 라우팅 테이블 | 어떤 서브넷의 트래픽이 어디로 가야 할지 정하는 표 → 로컬 통신 경로는 기본 제공됨 |
| 라우터 | 라우팅 테이블을 따라 실제로 트래픽을 전달하는 장치 (추상적 존재) |
| 퍼블릭 IP / 탄력적 IP | 퍼블릭 IP: 인터넷에서 접근 가능한 IP 탄력적 IP: 고정 IP, 인스턴스에 붙였다 떼었다 가능 |
| NAT Gateway |
프라이빗 서브넷에 있는 인스턴스가 인터넷으로 나갈 수 있게 해주는 우회 출구 (외부에서는 못 들어옴) |
| 인스턴스 | AWS에서 빌려 쓰는 가상 컴퓨터 EC2 인스턴스 = AWS의 컴퓨터 한 대 |
[3] VPC 네트워킹
☑️ 인터넷 게이트웨이
- 퍼블렛 서브넷에서 외부VPC에 연결하고 싶을때 퍼블릿 서브넷 라우팅 테이블을 설정해야함
- igw-id: 외부 인터넷 주소, 인터넷 게이트웨이 주소
- 퍼블릭 서브넷이 외부와 연결하려면 인터넷 게이트웨이가 필요함
☑️ Network Address Translation(NAT) 게이트웨이
- NAT: 주소를 변환해주는 역할
- 프라이빗 서브넷: 내부에서만 통신 가능함, 인터넷 연결이 필요할 경우(패키지 업데이트 등) NAT 필요함
- 프라이빗 서브넷 인터넷 접근 시
↓
프라이빗 서브넷 트래픽이 NAT 게이트웨이로
↓
NAT 게이트웨이는 퍼블릭 서브넷에 있으므로 igw-id로 트래픽이 넘어감
↓
인터넷 게이트웨이 (IGW)
↓
인터넷
☑️정리
퍼블릭 서브넷프라이빗 서브넷
| 퍼블릭 서브넷 | 프라이빗 서브넷 |
| 인터넷 게이트웨이 (IGW) | NAT 게이트웨이 |
| 퍼블릭 IP 있음 | 퍼블릭 IP 없음 |
| 외부 인터넷에서 직접 접근 가능 | 외부에서는 접근 불가능 |
| 인터넷으로 나가려면 IGW만 있으면 됨 | 퍼블릭 IP가 없기 때문에, NAT를 통해 우회해서 나가야 함 |
| NAT는 프라이빗 서브넷 → 인터넷 (아웃바운드) 만 가능, 인바운드 불가능 |
☑️ VPC 공유
- 한 조직 안에 aws 계정이 여러개 있을 경우 공유할 수 있음
☑️ VPC 피어링
- 서로 다른 두 개의 VPC를 직접 연결해서 마치 하나의 네트워크처럼 서로 통신할 수 있게 만드는 것
- 고객 AWS 계정의 VPC를 AWS 계정 간 또는 AWS 리전 간에 연결할 수 있음
- VPC A와 VPC B 서로 연결시킴
- IP 공간은 중복될 수 없음 (두 VPC가 같은 IP 대역 쓰면 안됨)
- 전이적 피어링은 지원되지 않음 ( A–B, B–C 연결되어 있어도 A → C 직접 통신은 안 됨, 직접 연결 필요함)
- 동일한 두 VPC 간에는 하나의 피어링 리소스만 설정할 수 있음( A와 B는 피어링을 딱 한 번만 할 수 있음)
☑️ AWS Site-to-Site VPN
- 기업의 온프레미스(자체 데이터센터)와 AWS VPC를 안전하게 연결하는 방법
- AWS와 회사 내부망을 VPN으로 연결해서 마치 하나의 내부망처럼 안전하게 통신하게 해주는 구조
- 인터넷 대신 암호화된 터널로 연결되니까 안전함
- 백엔드 DB, 내부 서비스 등 민감한 데이터도 보낼 수 있음
회사 내부 컴퓨터 (192.168.10.0/24)
↓ 암호화된 터널 (VPN)
고객 게이트웨이 → 인터넷 → 가상 게이트웨이(VGW)
↓
AWS VPC 내부 서버 (예: 프라이빗 서브넷 EC2)
| VPC: 10.0.0.0/16 | AWS에서 만든 네트워크 (내 전용 가상 네트워크) |
| 퍼블릭 서브넷: 10.1.0.0/24 | 외부 인터넷과 직접 통신 가능한 서브넷 |
| 프라이빗 서브넷: 10.0.2.0/24 | 외부와 직접 연결 안 됨 (보안용 서버 위치) |
| 가상 게이트웨이 (VGW) | AWS 쪽 VPN 출입구 (VPN 연결 지점) |
| 고객 게이트웨이 | 회사 내부 네트워크 쪽 VPN 출입구 |
| VPN 연결 | 인터넷을 통해 양쪽 네트워크를 암호화하여 연결 |
| 192.168.10.0/24 | 회사 내부 네트워크 주소 범위 |
☑️ AWS Direct Connect
- 회사 내부 네트워크(데이터 센터)와 AWS VPC를 전용선으로 연결하는 서비스
- 인터넷을 거치지 않고 전용 회선으로 AWS와 연결
- 지연 시간 민감한 금융 서비스
☑️ VPC 엔드포인트
- VPC 안에서 인터넷 없이 AWS 서비스(S3, DynamoDB 등)에 직접 접속할 수 있게 해주는 연결 통로
- VPC 엔드포인트를 쓰면 인터넷 게이트웨이 없이도 S3에 사설망처럼 직접 연결 가능함
항목인터페이스 엔드포인트게이트웨이 엔드포인트
항목인터페이스 엔드포인트게이트웨이 엔드포인트
| 인터페이스 엔드포인트 | 게이트웨이 엔드포인트 | |
| 사용 서비스 | 대부분의 AWS 서비스 (SSM, CloudWatch 등) | 오직 Amazon S3, DynamoDB |
| 연결 방식 | ENI(탄력적 네트워크 인터페이스) 생성 | 라우팅 테이블에 직접 경로 추가 |
☑️ AWS Transit Gateway
- AWS 네트워크 구조를 단순화시키기 위한 AWS Transit Gateway
- 예전에는 VPC끼리 줄줄이 연결했지만 이제는 Transit Gateway를 중심으로 다 붙이면 깔끔하게 통신 가능
| 이전 방식 | Transit Gateway 방식 |
| VPC끼리 연결할 때 각각 직접 피어링함 → 복잡하게 얽힘 | Transit Gateway = 네트워크 허브 (중앙 연결소) |
| 고객사 내부와 VPN을 만들면 VPC마다 따로 연결해야 함 | 모든 VPC, VPN, Direct Connect를 한 곳에 모아서 연결 |
| Direct Connect도 특정 VPC에만 붙임 → 다른 VPC들과 따로 연결 필요 | 각 VPC는 오직 Transit Gateway만 연결하면 끝 |
| Transit Gateway가 중앙에서 라우팅을 통제해줌 |
☑️정리
VPC (10.0.0.0/16)
├─ 퍼블릭 서브넷 (10.0.1.0/24)
│ ├─ EC2 (퍼블릭 IP 있음)
│ └─ NAT 게이트웨이
│
├─ 프라이빗 서브넷 (10.0.2.0/24)
│ └─ EC2 (프라이빗 IP만 있음)
│ └─ ENI (탄력적 네트워크 인터페이스)- 라우팅 테이블
① VPC 내부 통신은 local 경로
② 외부 인터넷 트래픽은 igw-id(인터넷 게이트웨이)로 보낸다는 뜻
| 대상위치 | 대상 | 의미 | 규칙 |
| 10.0.0.0/16 | 로컬 | VPC 내부끼리 통신, VPC 내부 통신 | 대상 위치: 10.0.0.0/16 → 대상: local |
| 0.0.0.0/0 | igw-id | 퍼블릭 서브넷이 인터넷 나가는 경로 0.0.0.0/0은 모든 외부 주소 인터넷으로 나가는 트래픽은 IGW로 보내라 |
대상 위치: 0.0.0.0/0 → 대상: igw-id |
[EC2 인스턴스] → (라우팅 테이블 확인)
├── 목적지가 VPC 내부 IP (10.0.2.15 등) → local
└── 목적지가 외부 인터넷 (8.8.8.8 등) → igw-id (인터넷 게이트웨이로)
[4] VPC 보안
☑️ 보안 그룹
- 어떤 트래픽이 들어오고(인바운드), 나갈 수 있는지(아웃바운드)를 정해주는 접근 제어 규칙
- 보안 그룹은 인스턴스(서버) 수준에서 작동, 인스턴스에 붙는 방화벽임
ㄴ 보안 그룹은 VPC 전체나 서브넷 전체가 아니라 각 EC2 인스턴스에 직접 적용됨
- 인바운드 아웃바운드마다 규칙 정할 수 있다
- 인바운드 트래픽 다 거부해서 가장 강력한 보안
- 기본 보안 그룹은 모든 인바운드 트래픽(들어오는 트래픽)을 거부하고 모든 아웃바운드 트래픽(나가는 트래픽)을 허용
- 보안 그룹은 스테이트풀(응답 트래픽은 자동으로 허용)
┌─────────────┐
│ EC2 인스턴스 │ ← 인바운드: ❌ 기본 차단
└─────────────┘ → 아웃바운드: ✅ 기본 허용
↑↓ 응답은 스테이트풀이라 자동 허용
☑️ 사용자 지정 보안 그룹
- 명시한 대로 트래픽 허용됨
- 허용만 가능, 차단/거부 규칙은 지정할 수 없음
- 모든 규칙은 트래픽 허용을 결정하기 전에 평가 (트래픽이 들어오기 전에 보안 그룹 규칙을 먼저 검사해서 판단함)
☑️ 네트워크 액세스 제어 목록(네트워크 ACL)
- 네트워크 ACL은 서브넷 수준에서 작동
- 허용, 거부 둘 다 설정 가능
- 스테이트리스 (응답도 따로 허용해줘야 함, 요청을 허용한다고 해서 응답까지 자동으로 허용되지는 않음)
- 규칙은 번호 순서대로 평가됨(숫자가 작을수록 우선 순위가 높음)
☑️보안그룹 vs 네트워크 ACL 비교
| 보안그룹 | 네트워크 ACL | |
| 적용 범위 | 인스턴스 수준 (EC2에 직접 적용) | 서브넷 수준 (서브넷 전체에 적용) |
| 지원 규칙 | 허용만 가능 | 허용, 거부 모두 가능 |
| 상태 | 스테이트풀 → 요청 허용되면 응답은 자동 허용 |
스테이트리스 → 응답도 따로 허용 규칙 필요 |
| 규칙 평가 순서 | 모든 규칙을 한꺼번에 평가 | 규칙을 번호순으로 위에서부터 평가, 일치하는 첫 번째 규칙이 적용됨 |
| 기본 설정 | 인바운드: ❌ 차단 아웃바운드: ✅ 허용 |
기본 NACL: 인바운드/아웃바운드 모두 허용 사용자 정의 NACL: 둘 다 ❌ 차단 |
| 설정 위치 | EC2 인스턴스에 직접 연결 | 서브넷에 연결 (그 서브넷에 있는 모든 EC2에 적용됨) |
[5] Amazon Route 53
☑️ Amazon Route 53
- DNS란 사람이 읽을 수 있는 주소명, 이를 ip주소로 변환해주는 서비스
- 가용성과 확장성이 우수한 도메인 이름 시스템(DNS) 웹 서비스
[6] Amazon CloudFront
☑️ 콘텐츠 전송 네트워크(CDN)
- 전 세계에 분산된 캐싱 서버 시스템
- 자주 요청되는 파일(정적 콘텐츠)의 사본을 캐싱
- 가까운 캐시 엣지 또는 상호 접속 위치(POP)에서 요청된 콘텐츠의 로컬 사본 전송
- 동적 콘텐츠 전송 가속화
- 애플리케이션 성능 및 확장성 개선
☑️ Amazon CloudFront
- 빠르고 안전한 글로벌 CDN 서비스
- 사용자가 어디에 있든 웹사이트·영상·이미지 같은 콘텐츠를 빠르고 안정적으로 제공해주는 시스템
- 엣지 로케이션 및 리전별 엣지 캐시의 글로 벌 네트워크
- 셀프 서비스 모델
- 종량제 요금
- 이점
- 빠른 속도와 글로벌한 규모, 엣지 보안, 고도로 프로그래밍 가능, AWS와 완벽하게 통합, 비용 효율성
☑️ Amazon CloudFront 인프라
| 🔵 파란 | 엣지 로케이션 | 전 세계 여러 곳에 있는 CloudFront의 작은 캐시 서버 → 사용자 가까이에서 즉시 콘텐츠 제공 |
| 🟣 보라 | 여러 엣지 로케이션 | 한 지역에 엣지 로케이션이 여러 개 있을 때 표시 |
| 🟠 | 리전별 엣지 캐시 | 엣지 로케이션보다 큰 중간 캐시 서버 → 사용률 낮은 콘텐츠를 엣지까지 덜 자주 전송하게 해줌 (속도+비용 최적화) |
💡핵심사항
1. VPC는 AWS 클라우드의 논리적으로 격리된 섹션
2. VPC는 한 리전에 속하며 CIDR블록을 필요로 함
3. VPC는 서브넷으로 다시 나뉨, 서브넷은 하나의 가용 영역에 속하며 CIDR 블록을 필요로함
'클라우드컴퓨팅' 카테고리의 다른 글
| [4] AWS 클라우드 보안 (0) | 2025.04.11 |
|---|---|
| [3] AWS 글로벌 인프라 개요 (1) | 2025.04.11 |
| [2] 클라우드의 경제성 및 결제 (2) | 2025.04.11 |
| [1] 클라우드 개념 (2) | 2025.04.11 |