반응형
1️⃣ VM(가상 머신, Virtual Machine)
- 정의: 실제 물리 서버가 아니라, 클라우드 안에서 가상으로 만들어진 컴퓨터
- 용도:
- 프로그램 실행
- 서버 역할 (예: 웹 서버, DB 서버)
- 테스트용 환경
- 지금 만든 vm-private은
- 비공개 IP로 Google Cloud 서비스와 안전하게 연결 테스트
- SSH 접속 + 간단한 애플리케이션 테스트용
즉, “클라우드 안에서 내 컴퓨터처럼 쓸 수 있는 가상 서버”예요.
2️⃣ VPC 네트워크(Virtual Private Cloud)
- 정의: 클라우드 안의 내부 전용 네트워크
- 역할:
- VM, Cloud SQL 같은 리소스끼리 안전하게 연결
- 인터넷과 분리 가능 → 외부 노출 최소화
- 지금 만든 vpc-private는
- 비공개 통신용 전용 네트워크
- 외부 IP 없이도 Google 서비스와 통신 가능
3️⃣ 서브넷(Subnetwork)
- 정의: VPC 안에서 작은 구역/범위로 나눈 IP 주소 블록
- 역할:
- VM에 내부 IP를 할당
- 리전별 리소스 관리
- 지금 만든 subnet-private은
- 10.240.0.0/24 범위의 내부 IP 할당
- vm-private이 이 서브넷의 IP(10.240.0.2)를 받음 → 비공개 IP
쉽게 그림으로 보면
VPC 네트워크(vpc-private)
└─ 서브넷(subnet-private)
└─ VM(vm-private) → 내부 IP: 10.240.0.2- 외부와 통신할 필요 없으면 외부 IP 제거 → 완전 비공개
- Cloud SQL 같은 서비스와 연결할 때 인터넷을 거치지 않고 VPC 안에서 안전하게 통신 가능
였지만! 25.9/2 지금에 와서 위 내용과 달라진 점을 추가로 작성한다!
위에 정리한 구조에서는 VM(vm-private) 이 외부 IP 없이 VPC 내부에서만 동작했기 때문에,
- Cloud SQL (프로젝트용 공유 DB) 같은 GCP 내부 리소스랑은 잘 연결되지만
- 가비아에서 산 외부 도메인(booktalk-server.shop)이 VM을 못 찾아오는 상태였죠.
📌 지금 상황
- HTTPS 접속을 위해 외부에서 VM으로 들어올 수 있는 IP(External IP) 를 열고,
- 가비아 도메인의 A레코드를 그 외부 IP로 매핑한 거예요.
즉, 구조가 이렇게 달라진 거죠:
이전 (완전 private)
VPC 네트워크 (vpc-private)
└─ 서브넷 (subnet-private, 10.240.0.0/24)
└─ VM (vm-private, 내부 IP만 있음: 10.240.0.2)현재 (도메인 연결 가능)
VPC 네트워크 (vpc-private)
└─ 서브넷 (subnet-private, 10.240.0.0/24)
└─ VM (vm-private)
├─ 내부 IP: 10.240.0.2
└─ 외부 IP: 35.xxx.xxx.xxx (가비아 도메인 A레코드 연결됨)💡 정리하면
- VPC / 서브넷 구조 자체는 그대로 유지
- 차이점은 VM에 외부 IP를 부여했느냐 아니냐
- 외부 IP를 줬기 때문에 가비아 도메인과 연결이 가능했고, 그 위에 Nginx + Certbot으로 HTTPS 세팅한 거예요.
👉 그래서 보안적으로는
- 꼭 필요한 포트(80, 443)만 열고
- SSH 같은 건 Cloud IAP나 방화벽 규칙으로 제한하는 게 안전합니다.