클라우드 계정이 다른 개발 / 운영 환경의 CIDR 범위 설정

 

규모에 상관없이일반적으로 하나의 서비스를 이용하게되면 보통 하나의계정에 개발,스테이징, 운영 환경을 구축하는게 일반적입니다. 한눈에볼수도 있고 연동시 편한 장점이 있기 때문입니다. 

하지만 이번에 개발과 운영의 root 계정을 분리하여 운영하게 되었는데 이때  Best practice 네트워크 CIDR 은 서로 다르게 하는것 입니다. 간단히생각했을때 똑같이 구성해도 계정이 다르기 때문에 별문제가 안되어 보이지만 구분해는게 더 이점이 있습니다. 그에대해 이번 포스팅에서 살펴보겠습니다.

 

목차

 

왜 다르게 해야 하나? (step-by-step)

1. VPC 간 연결(피어링/Transit Gateway/VPN/Direct Connect) 대비
   • 나중에 dev ↔ prod, shared-services ↔ prod 같은 동일 조직 내 VPC 간 통신이 필요해지는 경우가 많습니다(모니터링, 배포 파이프라인, 중앙 로그 수집, Bastion, 패키지 프록시 등).
   • CIDR가 겹치면 라우팅 불가(AWS VPC Peering/TGW는 중복 CIDR을 허용하지 않음). 중복을 피하려면 처음부터 다르게 잡아야 합니다.
2. 하이브리드(온프레미스) 연동/멀티클라우드 대비
   • DX/VPN으로 온프레와 연결할 때 온프레 쪽 RFC1918 대역과 겹치면 경로 광고/수용이 막히거나 필터링 규칙이 엉킵니다.
   • 초기에 dev만 연결했다가, 추후 prod도 같은 온프레에 붙여야 할 때 대역이 겹치면 아예 확장 불가 → 대규모 재할당/마이그레이션 필요.
3. EKS/쿠버네티스 보조 CIDR(팟/서비스)와의 충돌 회피
   • Pod CIDR, Service CIDR(예: 100.64.0.0/16, 172.20.0.0/16 등)도 환경별로 분리해야 cross-cluster 통신, 멀티클러스터 게이트웨이, 서비스 디스커버리, eBPF 기반 라우팅 테스트가 수월합니다.
   • Docker 기본 브릿지(172.17.0.0/16 등)와도 충돌 안 나게 설계 필요.
4. 미래 변경 비용 최소화
   • VPC CIDR은 운영 중 변경이 매우 고통스럽습니다(재배치/재아이피/다운타임 위험).
   • 초기에 dev/prod를 명확히 다른 범위로 잡아두면, 나중에 연결/확장/분리/흡수(계정 통합·분할) 시 리스크와 작업량이 급감합니다.
5. 보안/거버넌스와 트러블슈팅 단순화
   • 대역이 분리되어 있으면 네트워크 ACL/SG/라우트 테이블 정책과 로그 분석이 직관적입니다(“10.20/16은 prod”처럼 의미가 담긴 주소 체계).
   • 문제 발생 시 “어느 환경 트래픽인지” IP만으로도 맥락 파악이 쉬움.

참고: IPv6는 AWS가 할당해주는 /56이 전역 유일이어서 중복 이슈가 거의 없습니다. 하지만 현실적으로 IPv4를 여전히 많이 쓰므로 IPv4 대역 설계가 핵심입니다.

---

실무 가이드 (빠르게 적용)

1) 상위 주소계획(예시)

• 조직 전반 슈퍼넷: 10.0.0.0/8 (조직 여건에 맞게 선택)
• 환경별 VPC:
  • dev VPC: 10.10.0.0/16
  • prod VPC: 10.20.0.0/16
  • shared-svc VPC(관제·배포·프록시): 10.30.0.0/16
• EKS 보조 대역(환경별로 다르게):
  • dev: Pod 100.64.0.0/16, Service 172.20.0.0/16
  • prod: Pod 100.65.0.0/16, Service 172.21.0.0/16
• 피하고 싶은 범위:
  • Docker 기본: 172.17.0.0/16
  • 사내 온프레가 이미 쓰는 대역(겹치지 않게)

2) 서브넷 쪼개기(가용영역별)

• /16을 AZ 수에 맞게 /19~/20 등으로 분할(현재·향후 노드 그룹/프라이빗 서브넷 확장 여지 확보).
• NAT 게이트웨이/서브넷 비용 고려해 초기에 적절한 수량만 만들고, 남겨둔 블록으로 증설.

3) Terraform 패턴

• 각 VPC 모듈에 **환경별로 다른 var.vpc_cidr*만 주입합니다(코드는 동일).
• cidrsubnet()로 프라이빗/퍼블릭/DB 서브넷을 일관 분할.

# modules/vpc/variables.tf
variable "vpc_cidr" { type = string }  # 예: dev=10.10.0.0/16, prod=10.20.0.0/16
variable "az_count" { type = number, default = 3 }

# modules/vpc/main.tf (요지)
resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = { Name = "${var.name}-vpc" }
}

# 예: 각 AZ 마다 /20 씩 프라이빗 서브넷 생성
locals {
  private_blocks = [
    cidrsubnet(var.vpc_cidr, 4, 0), # /20
    cidrsubnet(var.vpc_cidr, 4, 1),
    cidrsubnet(var.vpc_cidr, 4, 2),
  ]
}

resource "aws_subnet" "private" {
  count                   = var.az_count
  vpc_id                  = aws_vpc.this.id
  cidr_block              = local.private_blocks[count.index]
  availability_zone       = data.aws_availability_zones.current.names[count.index]
  map_public_ip_on_launch = false
  tags = { Name = "${var.name}-private-${count.index}" }
}

live/dev/.../01.network/dev.tfvars

vpc_cidr = "10.10.0.0/16"

live/prod/.../01.network/prod.tfvars

vpc_cidr = "10.20.0.0/16"

4) 검증 체크리스트

• [ ] 사내 온프레/타 VPC/타 클라우드 사용 대역 수집 → 중복 없게 테이블 확정
• [ ] EKS Pod/Service CIDR도 환경별 절대 중복 금지
• [ ] 도커 기본 브릿지, VPN 클라이언트 대역(예: 10.8.0.0/24)과도 충돌 방지
• [ ] 향후 합병/분사/계정 통합을 가정해서 여유 블록 남겨두기
• [ ] 문서화: “대역 → 의미(환경/용도)” 매핑 표를 레포 루트에 고정

---

결론

• 지금은 dev만 있어도, 나중에 dev↔prod/온프레↔클라우드 연결 가능성은 매우 높습니다.
• 한 번 겹치면 근본적인 해결은 재아이피/재배포라서 비용이 큽니다.
• 그래서 처음부터 환경별로 VPC CIDR(그리고 Pod/Service CIDR)까지 명확히 다르게 잡는 것이 표준 베스트 프랙티스입니다.