VPC 이해하기
VPC는 네트워크 인프라를 구축하는 가장 근본적인 단계이면서 AWS 서비스를 사용 할때 필수적으로 이해 해야하는 항목이므로 제일 처음으로 작성하도록 하겠습니다.
Virtual Private Cloud는 안전하면서도 독립된 환경의 가상 네트워크 서비스를 만들 수 있게 해주는 AWS 서비스입니다. 그리고 보통 각 개발 환경마다 따로 가상 네트워크 망을 구축하여 서비스 배포와 구축 및 적용을 진행하고 있습니다
환경은 다음과 같이 설정 했습니다.
- DEV
- UAT
- PROD.
AWS 에서 VPC를 입력 하여 들어갑니다.
만약 개발 인력도 없고 서비스 배포도 안된 스타트업 환경에서는 VPC 환경이 많다고 생각됩니다. 스타트업에서는 과감히 UAT를 버리고 DEV, PROD에만 집중하고 있으며 배포 임박시에는 PROD에 집중합시다.
VPC를 설정하고 관리하기 위해서는 각종 네트워크 관련 기술에 익숙해지셔야 하는데 다음 주요 키워드들에 대해 설명해 보겠습니다.
기본설정으로 VPC를 생성하게 되면 위와 같이 기본적으로 설정해 주게 되지만 나중에 EC2나 LoadBlancer 등 서비스에 네트워크 속성을 설정할 때 아래 기술들을 이해 하셔야 올바른 AWS 서비스 관리가 가능합니다.
DHCP(Dynamic Host Configuration Protocol) option
기본으로 VPC 생성 시 제공되는 옵션이며 IP를 자동으로 할당해주는 고마운 친구이다. 따로 설정에 고민할 필요가 없습니다.
IPv4 CIDR (Classless Inter-Domain Routing)
CIDR는 서브네팅을을 위한 설정 값이며 서브넷 마스킹을 통해 가상의 내부 IP 주소들을 추가로 만들어 효율적인 IP할당과 IP리소스 소진을 방지하는 기능을 제공합니다. 반대로, 분리 할당 된 IP 주소들이 상위 라우터를 Mapping을 가능하게 supernetting도 가능하게 해줍니다.
Subnet masking을 통해 분리된 네트워크 당 총 몇개의 호스트를 사용 가능하게 하는지 알려줄 수 있으며 보편적으로 Class A, Class B, Class C, Class D, Class E 서브넷 마스크 등급이 있습니다. 이부분은 더 자세히 알려면 검색을 해보는 것을 추천드립니다.
가령 다음과 같이 CIDR이 설정 되어 있다고 봅시다.
기본으로 설정되는 Private Network IP 주소 대역입니다. 기본적으로 내부 IP이기 때문에 인터넷 게이트웨이와 연결되지 않는 한 외부와의 소통이 불가능 합니다.
10.0.0.0/16 설명
- 네트워크 ID가 10.0.0.0 인 IP에 16의 서브넷 마스크 (255.255.0.0)를 적용하는 것은 Class B에 해당 됩니다.
- Class B 네트워크는 사용 가능한 내부 호스트IP의 수는 총 2^16 = 65.536 개의 IP를 할당이 가능해 집니다
- 10.0.0.0의 네트워크 IP에 사용 가능하게 된 내부 IP 범위는 10.0.0.0 ~ 10.0.255.255 입니다.
Availability Zone (VPC subnet)
VPC에서 더 세부적으로 subnet으로 쪼개는 영역이기도 합니다. 지정된 VPC 범위 안에서 또 작게 쪼개어 각 영역에 있는 서비스들이 서로 충돌되지 않게 하며 라우팅 설정을 따로 하지 않는 이상 서로 직접 통신이 불가능하게 되어 보안적으로 안전한 설정입니다.
그래서 EC2 생성하고 보안 설정할 때, VPC를 지정 한 후, Availability Zone 설정도 하라고 하는 이유가 이거입니다.
위에서 VPC CIDR로 10.0.0.0 ~ 10.0.255.255 의 호스트 IP 대역에 대한 subnetting 이 가능합니다. 그렇다면 subnetting은 65.536개 에서 쪼개어 나누어야지 availability zone에서 사용 할 수 있다는 뜻이며 이미 할당 된 subnet이 있으면 해당 영역은 사용이 불가합니다.
매우 중요한 개념인데 subnet 그룹 하나를 만들고 10.0.0.0 ~ 10.0.255.255개로 설정해 버리면 더이상 서브넷을 만들 수 없기 때문입니다. 그렇게 되면 해당 서브넷과 연계된 모든 서비스를 중단 및 삭제하고 subnet을 삭제 후 재 조정하는 방법으로 가야 하기 때문입니다. 아니면 쉬운 방법으로 VPC CIDR를 늘리면 되는데 이는 IP를 관리 해야 할 구역이 늘어난다는 뜻입니다.
따라서 초기 세팅할 때, 미리 인지를 한 상태에서 Availbility Zone의 개수를 미리 생각하고 서브넷 설정 하는것을 추천합니다.
만약 VPC에 네개의 Availability Zone(서브넷)으로 쪼개려면 10.0.0.0/20을 10.0.0.0/16으로 쪼개어 각 subnet 구역을 지정해 주면 각 서비넷 마다 16.384 개의 IP가 할당 되고 범위는 아래와 같습니다.
그러면 위에서 총 4개의 subnet 그룹을 어떻게 private network, public network 으로 분배 설정 할 지 결정합니다.
Private Network & Public Network 란?
Private Network는 내부망, Public Network는 외부망이라고 생각하면 쉬운데 내부망은 말 그대로 인터넷과 단절 된 네트워크 망이고 외부망은 말 그대로 인터넷과 연결 된 네트워크 망이라고 생각하면 됩니다.
따라서 내부망에다가 WAS(Web Application Server)를 설치하면 고객이 접속을 할 수 없겠죠? 그렇기 때문에 Public 네트워크에는 WAS, WAS와 내부적으로 소통하는 백 서비스와 DB는 private network에다가 배치하는 것이 이상적입니다.
그러면 위에서 Availbility Zone들을 각각 두개의 Public Network와 Private Network로 분리하셔도 되고 용도에 따라 변경 해 주시면 되겠습니다. 만약 Fault-Tolerent를 위한 서비스 제공을 하고 싶으면 Availbility Zone을 늘려주시면 되겠습니다.
Route tables
우선 Subnet들이 외부망을 쓸지, 내부망을 쓸지에 대한 판단은 Routing table 설정에 따라 달려 있습니다. Routing Table에서 subnet을 인터넷 게이트웨이에 둘지, 아니면 내부 AWS 서비스 게이트웨이에 연결하지 를 경정합니다. Routing Table은 그저 경로 설정 해주는 역할을 한다고 보면 됩니다.
Network ACL (Access Control Layer)
Security Group 설정과 비슷하게 inbound/outbound 허용 및 비허용 포트와 IP를 설정하는 방화벽이라고 생각하면 됩니다. 기본적으로 다 열려 있으니 보안이 우려된다면 따로 설정해 주셔도 됩니다.
Security Group 설정하기
Security Group은 매우 중요하면서도 AWS에 꼭 필수적인 방화벽 보안 설정 중 하나입니다.
Security Group을 잘못 설정하면 원치않는 트래픽이 발생 할 수 있으며 허가되지 않는 접속가능성이 발생 하기도 합니다. 따라서 Securty Group을 잘 설정 해주셔야 합니다.
무엇보다 귀찮아서 SG를 다른 서비스에도 중복 적용하는 일이 없도록 하셔야 합니다. 나중에 관리하기가 점점 복잡해지며 점점 보안에 구멍이 뚫릴 위험이 있습니다.
KMS 그리고 Secret Manager
KMS (Key Management Service) - 암호화 키 관리 서비스 - 암호키의 생성, 저장, 생명주기관리를 담당. 데이터 암호화 및 복호화를 담당합니다. 따라서 RDS에서 DB 데이터 송수신, AWS IoT 서비스나 Kinesis와 같은 데이터 통신에 적용되어 인터넷을 타야하는 데이터를 자동으로 암호화하고 복호화를 하는것을 담당합니다.
TLS통신을 위한 SSL 적용이 포함됩니다.
Secret Manager 암호키 저장 및 관리
주기가 꽤 긴 로그인용 아이디와 비밀번호에 적용되고 AWS RDS에서 사용되는 대부분의 관리자 아이디와 비밀번호는 여기에 저장되고 주기를 설정하여 비밀번호를 주기적으로 변경이 가능합니다.
이상 AWS 클라우드의 VPC설정과 각종 보안 설정에 대해 설명해 보았습니다. 궁금한 점이 있으시다면 꼭 덧글로 남겨주시길 바랍니다.
'클라우드' 카테고리의 다른 글
| 클라우드 컴퓨팅의 기본 개념 및 모델 (2) | 2025.08.09 |
|---|---|
| 클라우드 서버의 핵심, AWS EC2 설정 및 배포 관리 (feat. 튼튼한 서비스 구축의 첫걸음) (0) | 2025.07.12 |
