1️⃣ Route53
- AWS의 DNS(Domain Name Service) 서비스
- DNS(네임서버) + port 모니터링(Health Check) + L4(Failover 기능)+ GSLB(라우팅 정책)
- 도메인을 타깃으로 분산 처리 가능(!=로드밸런서)
cf. 라우팅이란 네트워크에서 경로를 찾는 행위를 의미한다.
cf. 네임서버는 ip주소와 도메인네임을 연결해주는 역할을 한다.
👉DNS (Domain Name System)
네트워크 통신을 하기 위해 IP를 찾아가는 과정
도메인네임(aws.amazon.com)을 네트워크 주소(192.168.1.0)으로 변환 (Forwarding DNS)하거나,
그 반대의 역할(Reverse DNS)을 수행하는 분산형 데이터베이스 시스템
- aws.amazon.com (도메인네임) → 192.168.1.0
- 192.168.1.0 ← aws.amazon.com
💡 분산형 데이터베이스 시스템?
DNS는 중앙 집중 시스템이 아닌 분산된 데이터 베이스 형태로 운영된다.
즉, 하나의 중앙 서버가 모든 도메인 정보를 저장하는 게 아니라 전 세계에 분산된 여러 DNS 서버들이 역할늘 나눠 데이터를 저장 후 처리한다.
Root 서버 → TLD 서버(.com, .net 등) → 권한 있는 네임 서버
💡 네트워크에서 클라이언트가 인터넷에 접속할 때 거치는 프로토콜
DHCP(IP주소 할당) → ARP(IP주소에서 MAC주소로 변환) → DNS(도메인에서 IP주소로 변환) → TCP(연결 및 신뢰성 보장) → HTTP/HTTPS(웹 페이지 요청 및 응답)
2️⃣ IP (Internet Protocol)
인터넷에 연결되어 있는 모든 장치를 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소
총 32비트. (IPv4) 255.255.255.255 (11111111.11111111.11111111.11111111)
- 네트워크 ID: 네트워크의 고유 식별자를 가리키는 일련의 숫자
- 호스트 ID: 네트워크상의 호스트 또는 개별 디바이스 식별자를 나타내는 일련의 숫자
- 고정 IP: 컴퓨터에 고정적으로 부여된 IP
- 유동 IP: 변하는 IP
- 공인 IP: ICANN → ISP로부터 할당받아 전역 인터넷에서 사용되는 IP
- 사설 IP: 로컬에서 사용되는 IP
💡 CIDR란?
Classless Inter-Domain Routing(CIDR)
네트워크 ID와 호스트 ID를 구분하기 위한 하나의 표기법.
인터넷상의 데이터 라우팅 효율성을 향상시키는 IP 주소 할당 방법.
예) 192.168.0.0/24 → IP 주소 중 앞 24bit를 네트워크 ID로 mask하고 나머지 bit는 호스트 ID로 활용.
*AWS에서는 /16 ~ /28의 서브넷 마스크 범위만 허용.
*192.168.0.0을 Base IP, /24를 Subnet Mask라 한다.
CIDR 장점
1. IP 주소 낭비 감소
CIDR은 IP 주소에 할당할 네트워크 및 호스트 식별자를 결정할 때 유연성을 제공한다.
CIDR을 사용하면 특정 네트워크에 필요한 수의 IP 주소를 프로비저닝하여 낭비를 줄일 수 있다.
또한 라우팅 테이블 항목이 줄어들고 데이터 패킷 라우팅이 단순화된다.
2. 데이터를 빠르게 전송
CIDR을 사용하면 라우터에서 보다 효율적으로 IP 주소를 여러 서브넷으로 구성할 수 있다.
조직에서 여러 서브넷을 만들고 통합할 수 있어 불필요한 경로를 사용하지 않고도 데이터가 대상 주소에 도달할 수 있다.
3. Virtual Private Cloud 생성
VPC를 사용하면 격리되고 안전한 환경에 워크로드를 프로비저닝할 수 있다.
VPC는 연결된 디바이스 간에 데이터 패킷을 전송할 때 CIDR IP 주소를 사용한다.
4. 슈퍼넷을 유연하게 생성
슈퍼넷은 유사한 네트워크 접두사를 가진 서브넷의 그룹이다.
CIDR을 사용하면 기존 마스킹 아키텍처에서는 불가능했던 슈퍼넷을 유연하게 만들 수 있다.
예를 들어 조직에서는 다음과 같은 표기법을 사용하여 IP 주소를 단일 네트워크 블록으로 결합할 수 있다.
- 192.168.1 /23
- 192.168.0 /23
이 표기법은 255.255.254.0이라는 서브넷 마스크를 IP 주소에 적용합니다.
IP 주소는 처음 23비트를 네트워크 주소로 반환한다.
라우터는 단 하나의 라우팅 테이블 항목으로 서브넷에 있는 디바이스 간의 데이터 패킷을 관리할 수 있다.
3️⃣ AWS 구조
1. Region
- 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치
- AWS의 데이터센터들을 지리적으로 나눈 단위
- 각 AWS 리전은 지리적 영역 내에서 격리되고 최소 3개의 AZ로 구성
2. AZ(Availability Zone)
- 여러 데이터 센터들을 묶은 단위
- AZ 여러개가 모여 리전 구성
3. VPC(Virtual Private Cloud)
VPC 별로 네트워크 구성 가능. 각각의 VPC는 완전히 독립된 하나의 네트워크로 작동.
: 시스템 의존도 ↓ 유지보수 ↑
- 리전당 5개 설계 가능(리전 단위로 생성, 리전을 지정해 생성 가능)
- VPC당 5개의 CIDR 설정 가능
- 사설 IPv4 범위만 할당 가능
- VPC CIDR는 다른 VPC나 네트워크와 범위가 겹치면 안된다.
- 계정을 만들면 Default VPC 생성된다.
4. Subnet
VPC의 IP 주소를 나눠 리소스가 배치되는 물리적인 주소 범위.
IP 네트워크 논리적인 영역을 쪼개서 만든 하위 네트워크망.
- Public Subnet, Private Subnet
- VPC의 IP 범위 안에서 서브넷의 IP 범위를 지정해야 한다.
- VPC가 하나의 리전에 존재하는 것처럼, 서브넷은 하나의 AZ에만 존재한다.
💡Subnetting?
VPC를 쪼개는 것
- IP 주소들을 낭비없이 효율적으로 사용할 수 있다.
- 서로 다른 목적을 가진 서버를 분리된 서브넷에서 관리할 수 있다.
- 서브넷마다 보안그룹과 네트워크 ACL을 설정해 접근을 제한할 수 있어 보안이 강화된다.
- 같은 서브넷 안에서 통신하면 트래픽이 내부에서 처리되므로 성능이 향상된다.
- 서브넷을 여러 AZ에 배포하면 장애 발생 시 서비스 유지.
5. Internet Gateway(IGW)
VPC의 리소스를 인터넷에 연결하도록 허용하는 EC2 인스턴스나 람다 함수
- VPC는 기본적으로 격리된 네트워크 환경이다 → VPC 리소스들은 기본적으로 인터넷 연결 x
- IGW와 Subnet 연결해야 인터넷 연결이 가능하므로 Subnet의 Routing Table을 설정해야 한다.
👉Routing Table
서브넷 혹은 게이트웨이의 네트워크 트래픽이 어디로 전송되어야 될 지에 관한 라우팅 규칙을 포함한 테이블
즉, 트래픽이 어디로 가야하는 지 알려준다.
서브넷에는 각각의 라우트 테이블이 연결되어 있다.
위 그림에서 서브넷 A는 타겟이 Local로 설정되어 있기 때문에 내부 통신만 지원하는 Private Subnet이다.
서브넷 B는 타켓이 Local과 IGW A로 설정되어 있기 때문에 Public Subnet이다.
❗Private Subnet 망 구조를 유지하면서 외부와 조건적으로 데이터 통신을 하는 방법
- 1. NAT Gateway
- 2. Bastion Host
1️⃣ NAT Gateway
- 인터넷 접속이 가능한 public subnet에 NAT Gateway를 설정하고 Private Subnet이 외부 인터넷이 필요할 때 NAT Gateway를 거치도록 라우팅을 추가한다.
- Private Subnet의 AWS 리소스 → Public Subnet의 NAT Gateway → IGW → 외부 연결 가능
- 외부 → Private Subnet으로 연결 X
- 특정 AZ에서 생성되고 Elasic IP를 사용한다.
- 여러 개의 AZ에 생성해 (fault torelance) 강화 가능: 다중 NAT Gateway
2️⃣ Bastion Host
- Public Subnet에 위치해 외부에서 Private Subnet으로의 통신을 도와주는 대리인
- 내부와 외부 네트워크 사이에서 일종의 Gateway 역할을 수행한다.
Bastion Host 설정
1. Bastion Host Security Group
Bastion Host의 보안 그룹은 제한된 CIDR(외부)로부터 Private Subnet으로의 접근을 허용해야 한다.
2. EC2 instance Security Group
private subnet의 instance의 보안 그룹은 Bastion Host의 보안 그룹 또는 Bastion Host의 개인 ip에 대해 SSH 연결을 허용해야 한다.
*SSH: 원격 호스트에 접속하기 위해 사용되는 보안 프로토콜
👉 Security Group(보안 그룹)
- 인스턴스 단위로 적용할 수 있는 네트워크 보안 기술
- 인스턴스 inbound, outbound 트래픽 중 어떤 것을 허용할 지 설정
- 기본적으로 모든 inbound를 차단한다.
👉 NACL(Network ACL)
Subnet을 오고가는 모든 트래픽에 대해 허용하거나 거부하여 트래픽을 제어하는 역할
인스턴스 단위로 적용하는 보안 그룹보다 더 보안이 좋다.
- 서브넷이 생기면 기본 NACL에 연결된다. (Default NACL) → 모든 요청 허용
- 직접 NACL 설정 시 inbound, outbound 요청은 모두 거부된 상태로 설정된다.
- 규칙마다 숫자를(1~32766) 부여해 우선순위를 지정한다.
- 보통 100단위로 설정하고 숫자가 낮을수록 우선순위가 높다.
| Security Group | NACL |
| 인스턴스 단위 | Subnet 단위 |
| Stateful : 한 번 보안 그룹을 거쳤을 때 해당 트래픽이 허용됐었는지, 거부됐었는지 기억하므로 응답 트래픽에 대한 평가 X | Stateless: 트래픽의 허용 여부를 기억하지 않으므로 응답 트래픽이 허용되는지 확인한다. |
| 모든 규칙이 평가되고 허용/거부 여부 결정 | 가장 높은 우선순위를 가진 규칙이 우선 평가되며, 첫 번째 비교로 허용/거부 결정 |
| EC2 인스턴스 하나에 적용되는 보안 | Subnet 안에 있는 모든 EC2 인스턴스에 적용 |
| 허용(Allow) 규칙만 설정 가능 | 허용(Allow), 거부(Deny) 규칙 모두 설정 가능 |
*NACL vs Security Group → Security Groupt가 우선
1️⃣ VPC Peering
Private IPv4/v6 주소를 사용해 두 VPC 간 트래픽을 라우팅할 수 있도록 하여 두 VPC 간 연결을 이루는 서비스
원래 VPC는 서로 독립적이라 별개로 존재하지만 서로 통신할 수 있도록 설정할 수 있다.
VPC를 연결해 마치 하나의 VPC에 있는 것처럼 작동 !
- AWS 네트워크를 통해 연결되므로 안전하다.
- VPC의 CIDR가 서로 겹치면 안된다.
- VPC 피어링 관계는 전이되지 않는다.
- 피어링을 활성화하고 싶다면 VPC 서브넷의 라우팅 테이블도 통신이 가능하도록 업데이트 필요
- 서로 다른 계정, 서로 다른 리전에서도 가능
2️⃣ VPC Endpoint
VPC 내부 리소스가 외부 AWS 서비스와 통신할 때, AWS 내에서 서비스에 바로 연결할 수 있도록 지원하는 서비스
VPC 외부에 위치한 서비스: S3, CloudWatch, Cloudfront, DynamoDB, APU Gateway
이러한 서비스는 따로 Public IP를 가지고 외부에서 접근한다.
VPC 엔드포인트를 VPC 내부에 설정하면 AWS 내에서 바로 연결이 가능하다.
→ Public IP 없이 AWS 내부 네트워크를 이용해 안전하고 효율적으로 리소스간 연결 가능 !
⚒ 핸즈온
1️⃣ VPC 생성
10.0.0.0/16
2️⃣ Public 및 Private 서브넷 생성
ap-northeast-2a, ap-northeast-2c에 각각 public 및 private 서브넷을 생성한다.
- Public Subnet : 10.0.1.0/24, 10.0.2.0/24 → 주소 256개
- Private Subnet : 10.0.3.0/25, 10.0.4.0/25 → 주소 128개
3️⃣ EC2 생성
Public 및 Private 서브넷1에 각각 EC2를 생성한다.
4️⃣ 인터넷 게이트웨이 생성
IGW 생성 후 VPC에 연결한다.
5️⃣ 라우팅 테이블 생성
Public용 라우팅 테이블 생성 후 Private용 라우팅 테이블을 생성한다.
이후 Public용 라우팅 테이블에 Public 서브넷을 삽입한 후 인터넷 게이트웨이를 추가한다.
6️⃣ NAT 게이트웨이 생성
NAT 게이트웨이를 생성한 후 Private Subnet의 라우팅 테이블 수정한다.
라우팅 2에 0.0.0.0/0을 대상으로 생성한 NAT 게이트웨이를 추가한다.
7️⃣ Public EC2(=Bastion Host) 및 Private EC2 인스턴스 생성
8️⃣ Bastion Host를 통해 Private EC2로 접근
Public EC2에 연결하여 Private Ec2로 ping을 날려보면 잘 보내진다.
하지만 ssh를 날리면 불가능 → 키가 없어서 !
mobaXterm을 이용하여 키를 삽입해준다.
chmod 600으로 권한을 부여하고 ssh로 연결하면 Private EC2에 접속 가능.
Private EC2에 접속 후 MySql 설치 후 실습해보기.
아래 파일은 ACC 캡틴이 올려주신 자료이다.
파일 보고 다시 실습해보면 좋을 것 같다.
클컴 이후로 오랜만에 클라우드 공부를 하니 많이 까먹었다..
VPC 관련 개념을 다시 복습할 수 있었고 직접 실습을 해보니 VPC의 구조와 접근 방식이 더 잘 와닿았다.
특히 Bastion Host에 관한 부분은 처음 보는 것 같은데 NAT Gateway와 Private Subnet망 구조를 유지하면서 외부와 조건적으로 데이터 통신을 하는 방법이라는 점은 동일하지만 통신 방향에서 차이가 있다는 점이 흥미로웠다.
*Bastion Host: 외부 → Private Subnet / NAT Gateway: Private Subnet → 외부
이런 차이점을 활용해서 다양한 실습을 해보면 재미있을 것 같다.
참조
https://medium.com/awesome-cloud/aws-vpc-endpoints-overview-intro-getting-started-guide-91ca23b5af8d
https://www.opcito.com/blogs/step-by-step-guide-to-vpc-peering
https://a1010100z.tistory.com/174
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/nat-gateway-scenarios.html
https://jaehyeon48.github.io/network/dns/
'대외 활동 > ACC' 카테고리의 다른 글
| [핸즈온 세션] RDS, DynamoDB (0) | 2025.04.01 |
|---|---|
| [핸즈온 세션] Storage, Amazon S3, CloudFront (0) | 2025.03.30 |