AWS Console 작업 1. Hub 인스턴스 생성: 퍼블릭 서브넷 내에 가상 라우터 역할을 수행할 중계용 EC2를 배치함. 보안그룹 설정 시 백엔드 API 인스턴스에서 오는 요청을 받도록 인바운드 규칙 추가. 보안그룹 인바운드 규칙 설정
2. 소스/대상 확인(Source/Dest. Check) 중지: 인스턴스 네트워킹 설정에서 이 옵션을 반드시 '중지'해야 본인이 최종 목적지가 아닌 외부 패킷(백엔드→로컬DB)을 드랍하지 않고 전달할 수 있음. 중계용 EC2 인스턴스는 소스/대상 확인 설정을 "중지"함
3. VPC 라우팅 테이블(Route Table) 업데이트: 백엔드 API 서버가 속한 서브넷의 이정표를 수정함. 로컬 DB 사설 대역(192.168.x.x)으로 가는 Target을 '중계용 Hub EC2의 인스턴스 ID'로 지정하여 트래픽을 강제로 허브로 밀어넣음. Backend 서버용 라우팅 테이블 (DB 요청은 중계 EC2로)중계용 라우팅 테이블은 기존 public 테이블과 동일
4. 백엔드 API 서버 DB connection 변경 : 백엔드 API 서버가 속한 서브넷의 talescale 을 정지 / DB 커넥션을 시나리오 1의 talescale 10.x IP가 아닌 로컬 사설 IP 192.x 로 .env 파일 변경
Local(Tailscale) 연동 구현 1. 중계 서버(Hub EC2) IP Forwarding 활성화 : 리눅스 커널이 패킷을 가로채서 로컬로 넘겨주도록 허용함. ** 단순히 ip_forward만 켜면 보안 그룹 설정이 완벽해도 패킷이 증발할 수 있음. 리눅스 커널은 들어온 경로와 나가는 경로가 다른 패킷을 비정상으로 보고 차단하기 때문인데, rp_filter 설정을 0으로 바꿔줘야만 중계 서버(Hub EC2)가 패킷을 버리지 않고 정상적으로 로컬 DB까지 전달함 **
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv4.conf.all.rp_filter = 0' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv4.conf.default.rp_filter = 0' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
2. Subnet Router 선언: Hub EC2에서 taliscale 설치 후 "tailscale up --advertise-routes=10.0.0.0/16 --accept-routes" 명령을 실행함. 3. 로컬 PC 사설 대역 광고: 로컬 PC(온프레미스)에서도 자신의 대역을 등록함. "tailscale up --advertise-routes=192.168.0.0/24" 4. Tailscale 관리자 페이지에서 승인 : Admin Console에서 중계용 EC2(10.0.0.0/16)와 로컬 PC(192.168.0.0/24)의 경로를 각각 'Approve' 처리함.
5. 온프레미스 보안 설정: 로컬 PC 방화벽에서 AWS VPC 대역(10.0.0.0/16)에 대한 인바운드(TCP 3306, ICMP)를 허용함. 6. 기술 매핑: 실제 TGW 서비스 대신 Tailscale이 깔린 EC2를 '가상 라우터'로 변신시켜 트래픽을 중계하는 기능을 동일하게 구현함. **설정 미반영 시 해결법: tailscale up 옵션을 변경했는데도 ip route나 관리자 콘솔에 즉시 반영되지 않는다면, tailscale down 후 다시 tailscale up 명령어를 실행하여 세션을 초기화함. **
- AWS 아키텍처 :
- 검증 결과:
통합 라우팅 확인: 복잡한 개별 Peering 없이, 중앙 허브(TGW 역할을 하는 EC2) 설정을 통해 다수의 가상 네트워크 대역에서 단일 로컬 DB에 접근 가능한 통합 라우팅 체계를 확인함.
backend public IP로 db 연결 시 중계서버를 거쳐 응답이 옴
[총평]
이번 기술 검증을 통해, 물리적인 VPN 장비가 없는 로컬 환경에서도 Tailscale과 같은 Mesh VPN을 활용하면 실제 기업의 Site-to-Site VPN이나 Direct Connect 환경을 충분히 시뮬레이션할 수 있음을 확인함.
이어서 Direct Connect(DX) 도 검증! 아키텍처와 공통설정은 앞선 "Site-to-Stie VPN" 과 동일함.
Scenario 2. Direct Connect(DX) 구현 (P2P 경로 최적화 검증)
# Scenario 2을 수행하기 전 check
Direct Connect 방식은 물리적 전용 회선 인입이 필요한 설계 구조이므로, 본 시나리오에서는 AWS 콘솔 절차를 숙지한 후 Tailscale 기반 성능 비교로 기술 검증만 수행함.
- 목적:인터넷 중계 서버(Relay)를 배제하고 온프레미스와 AWS 간 1:1 P2P(Direct) 경로를 수립하여, 물리적 전용선(Direct Connect) 수준의 고성능/저지연 통신 환경을 재현함.
- 검증 가설 :"의도적으로 UDP 통신을 제한한 Relay 모드와 최단 경로인 Direct 모드의 레이턴시(ms) 차이를 비교함으로써, DX가 하이브리드 아키텍처에서 제공하는 '직결성'과 '저지연'의 기술적 타당성을 입증할 수 있을 것이다."
- 검증 항목 :
Relay 환경: tailscale의 relay-only 설정을 통해 중계 서버(DERP)를 경유하는 통신의 지연 시간 측정.
Direct 환경: P2P 수립 후 중계 서버를 거치지 않는 최단 경로의 성능 수치 측정.
성능 격차: 두 모드 간의 지연 시간 차이 및 패킷 안정성 비교.
- 방법:
AWS Console 작업 ** 본 시나리오에서는 AWS 서비스 신규 생성 작업은 없음 ** 1. Direct Connect Connection: 전용선 신청 메뉴(Create Connection)를 통해 물리적 포트 할당 및 LOA-CFA 발급 절차를 분석하고, 이를 Tailscale 가상 인터페이스 설정과 논리적으로 매핑할 수 있도록 숙지함. 2. Private VIF 생성: Virtual Interfaces 메뉴에서 사설 통신용 VIF 생성 절차(BGP ASN, VLAN ID 설정 등)를 숙지함.
Local(Tailscale) 연동 구현 1. Direct 상태 확인 : tailscale status 명령어로 EC2와 로컬 PC 간 P2P 직결 여부 확인 (default가 direct mode)
2. Relay 모드 설정 : UDP 41641 차단
sudo iptables -A OUTPUT -p udp --dport 41641 -j DROP
sudo iptables -A INPUT -p udp --sport 41641 -j DROP
# -> Relay 전환 후 ping 측정 (평균 80~100ms)
3. Direct 복구 : 차단 규칙 제거 후 Tailscale 재기동
sudo iptables -D OUTPUT -p udp --dport 41641 -j DROP
sudo iptables -D INPUT -p udp --sport 41641 -j DROP
sudo tailscale down && sudo tailscale up
# → Direct 재수립 후 ping 측정 (평균 15~20ms)
4. 결과 정리 : Relay는 중계 경유로 지연 증가, Direct는 P2P 직결로 저지연 유지 → 직결 경로 성능 우위 확인
- AWS 아키텍처 : 시나리오 1과 동일
- 검증 결과:
Relay 모드 : 평균 80~100ms, 중계 서버 경유로 지연 증가 및 응답 편차 발생 relay 모드 결과
Direct 모드 : 평균 15~20ms, P2P 직결로 저지연 및 안정적 응답 유지 direct 모드
결론 : Direct 전환 시 약 4~6배 레이턴시 개선 확인 → 직결 경로 확보가 성능에 결정적 영향 미침을 실험적으로 검증
1) 가상 사설망(VPN) 구축: Tailscale 설정 - 실무의 AWS Site-to-Site VPN 역할을 대신할 가상 사설망 구축. - 로컬 PC: Tailscale 설치 및 로그인 후 가상 사설 IP 확인. - AWS EC2: 에이전트 설치 및 노드 등록 실행.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
- 연결 확인: EC2 터미널에서 로컬 PC IP로 통신(ping) 여부 확인.
2) 온프레미스 DB 보안 및 네트워크 개방 - 사설망 경로는 확보되었으나 DB 및 OS 차원의 접근 허용 설정 필요. - MariaDB 설정: bind-address를 0.0.0.0으로 수정하여 외부 접속 허용.
# my.ini 설정
bind-address = 0.0.0.0
- OS 방화벽: Windows/Mac 인바운드 규칙에서 3306/TCP 포트 개방. - DB 사용자 권한: Tailscale 사설 대역(100.x.x.x)에 대한 접속 권한 명시.
CREATE USER 'USERNAME'@'TailscaleIP' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON awslab.* TO 'USERNAME'@'TailscaleIP';
FLUSH PRIVILEGES;
3) 백엔드 어플리케이션 환경 변수 설정 - EC2에 배포된 앱이 사설망 경로를 통해 DB를 인식하도록 엔드포인트 수정.
# tailscale 설치
curl -fsSL https://tailscale.com/install.sh | sh
# 서비스 구동
# 로그인 승인: 터미널에 출력된 https://login.tailscale.com/a/xxxx 링크를 복사하여 브라우저에서 [Connect] 버튼 클릭.
sudo tailscale up
# 사설 IP 할당 여부 및 통신 확인
tailscale ip -4
# 상호 통신 검증: EC2에서 로컬 PC의 Tailscale IP로 핑을 날려 네트워크 터널링 완성 여부 체크.
ping [로컬_PC_Tailscale_IP]
5) AWS EC2 인스턴스에서 Backend API 서비스 기동
- 이후 3가지 하이브리드 시나리오(VPN, DX, TGW) 검증 진행
Scenario 1. Site-to-Site VPN 검증 (보안 터널 및 차단 검증)
# Scenario 1을 수행하기 전 check
* 검증 한계: AWS 콘솔 내 리소스 등록 및 구성 파일 추출까지는 가능하나, 실제 Tunnel: UP(통신 가능) 상태 구현은 불가함.
* 불가 사유: 실제 하이브리드 연결에는 고정 공인 IP와 IPSec 하드웨어 장비가 필수이나, 일반 로컬 환경(유동 IP/NAT)은 이를 충족하지 못함.
* 실무 포인트: 본 시나리오는 실제 장비 연결 전, 클라우드 측의 설정값 생성 및 구성도 설계 역량을 검증하는 데 목적이 있음.
- 목적:인터넷망을 경유하되 IPSec 암호화 터널과 동일한 보안 통로를 생성하여, 외부 접근은 차단하고 내부 통신만 허용하는지 검증함.
- 검증 가설 :"AWS 보안 그룹에서 외부(Anywhere) 접속을 허용하는 인바운드 규칙이 전혀 없더라도, 가상 터널(Tailscale)을 통한 사설 통신은 보안 그룹의 제어 범위를 우회하여 정상 동작할 것이다."
- 검증 항목 :
인바운드 규칙 공백 상태에서 외부 공인 IP를 통한 접속 차단 여부 (Default Deny 확인).
동일 상태에서 Tailscale 사설 대역(100.x.x.x)을 통한 DB 데이터 호출 성공 여부.
- 방법:
AWS Console 작업 1. Customer Gateway(CGW) 생성: [VPC] > [고객 게이트웨이]에서 내 로컬 PC의 공인 IP를 등록하여 온프레미스 접점을 정의함. (현업에선 기업의 VPN 서버 공인 IP를 등록) 2. Virtual Private Gateway(VGW) 생성: [VPC] > [가상 프라이빗 게이트웨이] 생성 후, 현재 사용 중인 VPC에 'Attach' 하여 클라우드 측 종단점을 활성화함. 3. VPN Connection 설정: 위 두 지점을 연결하고 '정적(Static) 라우팅'에 내 로컬 사설 대역을 입력함 공인 IP 가 없는 한 사용은 불가함. 이번 시나리오에서는 작성만 해봄.
Local(Tailscale) 연동 구현 1. 네트워크 통합: 로컬 PC와 EC2에 Tailscale을 설치하여 가상의 단일 사설망으로 묶음. 2. 기술 매핑: 고가의 IPSec VPN 장비 대신, 테일스케일의 기반 기술인 WireGuard 프로토콜을 활용해 소프트웨어적으로 보안 터널을 생성함.
- 구축한 AWS 아키텍처 :
- 검증 결과:
네트워크 격리: EC2 보안 그룹에 3306 포트 규칙이 부재함을 확인. 외부 스캐닝 및 공인 IP 접속 시 타임아웃(Timeout) 발생. 인바운드 규칙 설정 연결불가
사설 경로 유효성: 가상 인터페이스(tailscale0)를 통해 유입되는 트래픽은 SG 필터링 레이어를 거치지 않고 OS 커널로 전달되어, 사설 IP 기반의 DB 연동이 성공함.
EC2 인스턴스에서 tailscale 기동 후 IP 확인 & 온프레미스 DB의 tailscale IP가 있는 설정파일EC2 인스턴스에서 온프레미스 DB 통신 성공
step1. 퍼블릭 서버로 키 복사 - 로컬(내 컴)에 있는 키를 퍼블릭 서버로 복사해야 그 안에서 다시 프라이빗 서버로 들어갈 수 있음
- 파워 쉘 실행 후 아래 script 실행
* 사용자 계정은 os 마다 다름
Ubuntu: ubuntu Amazon Linux 2 / 2023: ec2-user Debian: admin
# 내 컴퓨터 파워쉘에서 실행
scp -i "public-server.pem" "web-pri-server.pem" ec2-user@<퍼블릭_서버_공인IP>:~/
step2. public ec2 접속(AWS UI 또는 파워쉘에 이어서 script 실행) 후 private ec2로 접속
# 1. 퍼블릭 서버 접속
ssh -i "public-server.pem" ec2-user@<퍼블릭_서버_공인IP>
# 파일 권한을 '나만 읽기 가능'으로 변경
chmod 400 <프라이빗_서버_사설IP>
# 2. 퍼블릭 서버 안에서 프라이빗 서버로 접속 (전달받은 키 사용)
ssh -i "web-pri-server.pem" ec2-user@<프라이빗_서버_사설IP>
3. Bastion Host
- 사설망(Private Subnet) 자원 관리를 위한 외부 관문 서버
- 별도 서비스가 아니라 일반적인 EC2 인스턴스를 Bastion Host라는 역할을 보안그룹으로서 부여한 것
=> 보통 사양을 많이 타지 않아 t3.nano나 t3.micro 같은 저렴한 사양을 씀 => 22번 포트를 내 IP에만 열어주고, 다른 서버들로 연결될 수 있는 '입구' 역할을 하도록 설정한 EC2임.
1) 존재 이유 - 사설망(Private Subnet) 내부 인스턴스에 접근하기 위한 단일 진입점. (퍼블릭 서브넷도 SSH 포트를 배스천 호스트에게만 오픈하는 것을 권장)
- 핵심 목적: 모든 서버의 SSH(22번) 포트를 외부에 열지 않고, 오직 배스천 한 대만 관리하여 공격 면적(Attack Surface)을 최소화함.
2) 위치 및 네트워크 구성 - 반드시 퍼블릭 서브넷에 배치하며 공인 IP를 보유해야 함. - 배스천 호스트는 인터넷 게이트웨이(IGW)를 통해 외부 관리자와 통신함.
3) 보안 그룹(Security Group) 설정 정석 - 배스천 호스트 SG: 인바운드 22번(SSH) 포트를 관리자의 특정 공인 IP로만 제한함. (0.0.0.0/0 개방 금지) - 내부 인스턴스 SG: 인바운드 22번(SSH) 포트의 소스를 IP가 아닌 배스천 호스트의 보안 그룹 ID로 설정함.
4) 2026년 최신 보안 트렌드 (중요) - 포트리스(Port-less) 접속: 최근 AWS는 배스천의 22번 포트조차 열지 않는 방식을 권장함. - AWS Systems Manager(SSM) Session Manager: 배스천 호스트 없이, 또는 배스천의 22번 포트를 닫은 상태에서 AWS 내부망을 통해 안전하게 셸 접속을 수행함. (가장 안전한 방식)
5) 요약 - SSH 접속을 배스천으로 단일화하여 관리 다만, 최근에는 배스천의 22번 포트조차 노출하지 않고 IAM 권한으로 접속하는 방식이 공식 권장 사항임.
6) 접속 단계 (2단계 과정)
1차 접속: 내 PC에서 퍼블릭 서브넷에 떠 있는 배스천 호스트(EC2)로 SSH 접속을 수행함. (이때 내 IP만 허용된 상태여야 함) 2차 접속: 배스천 호스트에 접속된 터미널 창 안에서, 다시 ssh [대상 서버 IP] 명령어를 입력해 프라이빗 혹은 퍼블릭 서브넷에 있는 다른 EC2로 들어감.
# !최종 정리! 아래와 같은 아키텍처로 구축 시 순서
VPC 및 IGW:VPC 생성 및 Internet Gateway 연결.
Subnets:가용 영역별 Public Subnet 2개, Private Subnet 2개 생성.
NAT Gateways:Public Subnet A, B 각각에 NAT Gateway 생성 (EIP 필요).
Routing Tables:
Public RT: 0.0.0.0/0 -> IGW (Public A, B 서브넷 연결).
Private RT A: 0.0.0.0/0 -> NAT GW A (Private A 서브넷 연결).
Private RT B: 0.0.0.0/0 -> NAT GW B (Private B 서브넷 연결).
Security Groups:
Bastion SG: 22번 포트 허용 (내 IP만).
Web Server SG: 80/443 포트 허용(ALB로부터), 22번 포트 허용(Bastion SG로부터).
EC2 Instances:* Public Subnet에 Bastion Host 생성.
Private Subnet에 Application Server 생성.
Load Balancer (선택이나 권장):Public Subnet에 ALB 생성 후 서버들과 연결.
AWS 네트워크 계층 구조 - 리전 (Region): 지리적 위치 (예: 서울 리전) - VPC (Virtual Private Cloud): 리전 안에 생성하는 가상 네트워크 - 가용 영역 (Availability Zone, AZ): 리전 안에 떨어져 있는 물리적인 데이터 센터 단지 (보통 리전당 3~4개) - 서브넷 (Subnet): 특정 가용 영역(AZ) 안에 할당하는 IP 주소 범위
1. VPC
- AWS 클라우드 내에서 사용자 전용으로 격리된 가상 네트워크 공간
- VPC를 활용하면 외부에서 직접 접근할 수 없는 독립적인 네트워크 환경을 구성할 수 있어서 보안적으로 안전
- VPC는 할당할 수 있는 여러 개의 IP를 가지고 있음
=> VPC 생성 시 IP 주소의 범위를 CIDR 표기 방식을 통해 설정함
2. VPC 핵심 요소
서브넷 (Subnet): VPC 내부의 IP 주소 범위를 더 작은 단위로 쪼갠 네트워크 외부 인터넷과 연결되는 퍼블릭 서브넷과 보안을 위해 격리된 프라이빗 서브넷으로 구분
라우팅 테이블 (Routing Table): 네트워크 트래픽이 어디로 향해야 하는지 결정하는 이정표
인터넷 게이트웨이 (IGW): VPC 내의 자원들이 외부 인터넷과 통신할 수 있게 해주는 통로
보안 그룹 (Security Group) & NACL: 네트워크에 드나드는 트래픽을 허용하거나 차단하는 가상 방화벽
3. 서비스 흐름 예시
사용자가 웹사이트에 접속하면 인터넷 게이트웨이를 통과 라우팅 테이블의 안내에 따라 퍼블릭 서브넷에 있는 웹 서버 또는 로드밸런서로 연결 로드밸런서가 있다면 대상 그룹을 보고 실제 서버로 연결 대상 그룹 서버는 보안을 위해 프라이빗 서브넷에 숨겨진 서비스(DB 등)와 통신하여 데이터를 가져옴
1. 서브넷
- 하나의 큰 네트워크(VPC 등)를 작은 네크워크 단위로 나눈 것
- VPC는 여러 서브넷으로 나뉘어짐
- 용도에 따라 네트워크를 분리해서 사용 가
2. 퍼블릭 서브넷 / 프라이빗 서브넷
- VPC를 여러개의 서브넷으로 나눌 때 가장 많이 활용하는 방식이 외부에서 접근이 가능한 네트워크(퍼블릭 서브넷)와 외부에서 접근이 불가능한 네트워크(프라이빗 서브넷)로 나누는 방식
- 두 서브넷의 차이 : 인터넷 게이트웨이의 연결 여부
# 헷갈려서 정리 #
1) pub/pri 서브넷을 만들 때 가용영역을 어떻게 나누는가?
- 보통 실무에서는 가용영역에 배포되는 서비스들을 다른 가용영역에 이중화하여 관리함
=> ex. A 가용영역 : pub - web server / pri - api server, db 일 때, B 가용영역에도 동일하게 세팅하여 운영 안정성 보장
2) inbound 와 outbound 규칙은 어떻게 정의되는가?
** 외부 사용자의 요청이 들어왔을 때, AWS 사설 네트워크 망에 접속하기 위해서는 인터넷 게이트웨이가 매핑되어 있어야 함.
=> inbound 설정
** AWS 서비스에서 외부로 응답하기 위해서도 별도 설정이 필요한데, 이것을 수행하는 것이 라우팅 테이블임
=> outbound 설정
3) 서브넷 생성 시 기본으로 할당되는 라우팅 테이블을 사용하지 않고 신규 생성하는 이유?
- pub/pri 서브넷을 생성한 뒤 pub에 igw를 연결하고 나서, 별도의 설정을 위한 라우팅테이블을 별도로 생성하는 것을 추천
=> default로 매핑된 라우팅 테이블은 동일 VPC 요청일 때 local 로 응답하라는 것으로 보통은 건드리지 않고 별도로 라우팅 테이블을 생성하여 관리함. private subnet에 영향을 줄 수 있음.
4) 아래와 같은 라우팅 테이블 설정일 때 우선순위는 어떻게 되는가?
- 10.0.0.5 로 보낼 경우, 라우팅 1로 선택되어 local로 보내짐.
- AWS의 라우팅 테이블 규칙에 따르면, 라우팅 테이블은 목적지 주소가 더 구체적으로 명시된 규칙을 먼저 선택하기 때문
