클라우드 컴퓨팅이 주류가 되면서 기업과 개인 사용자는 클라우드 애플리케이션을 구축할 때 네트워크 환경의 보안, 유연성, 확장성에 대한 요구 사항이 더욱 높아졌습니다. 가상 사설 클라우드(VPC)는 이러한 요구를 충족하는 핵심 서비스 중 하나입니다. VPC를 사용하면 사용자는 로컬 데이터 센터에서 기존 네트워크를 구축하고 관리하는 것처럼 AWS 클라우드에서 자체 가상 네트워크를 생성하고 관리할 수 있습니다.
VPC 네트워크 아키텍처에서서브넷 서브넷은 중요한 역할을 합니다. 리소스의 네트워크 경계를 결정할 뿐만 아니라 애플리케이션 시스템의 보안 정책, 가용성 및 외부 통신 방식에도 영향을 미칩니다. 서브넷을 이해하고 올바르게 사용하는 것은 안전하고 효율적인 클라우드 아키텍처를 설계하는 데 중요합니다.
AWS 서브넷이란 무엇인가요?
서브넷 서브넷은 VPC 내의 IP 주소 공간을 더욱 세분화합니다. 서브넷을 사용하면 사용자는 대규모 VPC를 논리적으로 더 작은 여러 네트워크 세그먼트로 나눌 수 있습니다. 다양한 유형의 리소스를 각 서브넷에 배포하고, 차별화된 액세스 제어 정책을 적용할 수 있습니다.
예를 들어, 기업은 VPC를 다음과 같은 서브넷으로 나눌 수 있습니다.
- 공개 서브넷: 인터넷 게이트웨이를 통해 서브넷의 리소스(웹 서버 등)가 인터넷에 직접 액세스할 수 있도록 합니다.
- 개인 서브넷: 서브넷 내부의 리소스(데이터베이스 및 내부 API 서비스 등)는 인터넷에서 직접 액세스할 수 없으며 NAT 게이트웨이 또는 VPN을 통해서만 외부 세계와 통신할 수 있습니다.
이러한 구분 방식은 기존 데이터 센터의 DMZ(비무장지대) 및 내부 네트워크 세그먼트와 같은 개념과 유사하지만, AWS에서 더 유연하고 확장이 쉽습니다.
서브넷의 기본 요소
AWS 서브넷을 생성할 때 고려해야 할 몇 가지 핵심 사항은 다음과 같습니다.
1. CIDR 블록
CIDR(Classless Inter-Domain Routing) 블록은 서브넷의 IP 주소 범위를 정의합니다.
- 각 서브넷에는 CIDR 블록이 할당되어야 하며, 이 블록은 해당 서브넷이 속한 VPC의 CIDR 범위 내에 있어야 합니다.
- 서브넷의 CIDR 크기에 따라 사용 가능한 IP 주소 수가 결정됩니다. 예:
- 10.0.1.0/24 → 256개의 IP 주소를 제공합니다(그 중 251개가 실제로 사용 가능).
- 10.0.1.0/28 → 16개의 IP 주소를 제공합니다(그 중 11개는 실제로 사용 가능).
AWS는 각 서브넷에 5개의 IP 주소를 예약해 두므로(게이트웨이, DNS, 네트워크 관리용), CIDR을 계획할 때 약간의 여유를 두는 것이 좋습니다.
2. 가용성 영역(AZ)
서브넷을 생성할 때는 해당 서브넷이 속하는 가용성 영역을 지정해야 합니다.
- 각 서브넷은 단일 가용성 영역에만 위치할 수 있습니다.
- 고가용성을 달성하려면 일반적으로 동일한 지역의 여러 AZ에 서브넷을 만들고 서브넷에 중복 리소스를 배포해야 합니다.
3. 경로 테이블
서브넷 내 트래픽 전달은 라우팅 테이블에 의해 결정됩니다. 라우팅 규칙을 사용자 지정하면 서브넷 내 리소스가 인터넷, VPC 내의 다른 서브넷 또는 로컬 데이터 센터에 액세스할 수 있는지 여부를 제어할 수 있습니다.
4. 공개 및 개인 서브넷
- 공개 서브넷: 라우팅 테이블에 인터넷 게이트웨이를 가리키는 경로가 있습니다.
- 개인 서브넷: 인터넷 게이트웨이로의 직접적인 경로는 없으며, NAT 게이트웨이나 VPN을 통해서만 외부 접근이 가능합니다.
서브넷 애플리케이션 시나리오
1. 3계층 아키텍처 구축
일반적인 웹 애플리케이션에서는 기능에 따라 서로 다른 서브넷에 배포될 수 있습니다.
- 웹 티어(공개 서브넷): Nginx 및 Apache와 같은 외부 웹 서비스를 배포합니다.
- 애플리케이션 계층(개인 서브넷): 비즈니스 로직 처리와 같은 백엔드 애플리케이션 서비스를 배포합니다.
- 데이터 레이어(개인 서브넷): RDS 및 Redis와 같은 데이터베이스와 캐시를 배포합니다.
이 아키텍처는 서브넷 격리를 통해 보안을 강화하고 데이터베이스와 같은 중요한 리소스가 공용 네트워크에 직접 노출되는 것을 방지합니다.
2. 하이브리드 클라우드 아키텍처
기업은 하이브리드 클라우드를 구축하기 위해 AWS VPC를 온프레미스 데이터 센터와 연결해야 하는 경우가 많습니다. VPC 내에서 서브넷을 적절하게 구분하면 온프레미스와 클라우드 기반 비즈니스를 원활하게 통합할 수 있습니다.
3. 다양한 환경의 분리
개발, 테스트 및 운영 환경에는 엄격한 격리가 필요합니다. 기업은 동일한 VPC 내에 서로 다른 서브넷을 생성하거나 서로 다른 VPC에 서브넷을 설정함으로써 환경 수준의 격리를 달성하고 위험을 줄일 수 있습니다.
4. 고가용성 및 재해 복구
여러 AZ에 동일한 기능을 갖춘 서브넷을 만들고 중복 인스턴스를 배포하면 시스템 가용성과 내결함성을 크게 향상시킬 수 있습니다.
관련 AWS 서비스와 서브넷 결합
서브넷의 진정한 가치는 종종 다른 네트워크 구성 요소와의 협업에 있습니다.
- 인터넷 게이트웨이(IGW)
- 공개 서브넷의 인스턴스는 IGW를 통해 인터넷과 양방향으로 통신할 수 있습니다.
- NAT 게이트웨이/NAT 인스턴스
- 개인 서브넷의 인스턴스가 인터넷에 액세스하도록 허용합니다(예: 소프트웨어 업데이트 다운로드). 하지만 이러한 인스턴스에 대한 활성 외부 액세스는 차단합니다.
- 보안 그룹 및 네트워크 ACL
- 서브넷 수준 보안 제어 종속성 네트워크 ACL인스턴스 수준 보안은 다음에 의해 제공됩니다. 보안 그룹관리. 이 두 가지를 결합하면 세분화된 접근 제어가 가능해집니다.
- VPC 피어링
- 서로 다른 VPC에 있는 서브넷은 피어링 연결을 통해 서로 통신할 수 있으며, 이는 지역 간 배포나 다중 팀 협업에 매우 유용합니다.
- 트랜짓 게이트웨이
- 대규모 기업의 경우 Transit Gateway를 사용하면 여러 VPC의 서브넷을 중앙에서 연결하여 스타 토폴로지를 형성하여 네트워크 관리를 간소화할 수 있습니다.
모범 사례 및 고려 사항
1. 합리적인 CIDR 계획
- 향후 확장 시 충돌을 피하기 위해 미리 IP 주소 범위를 설계하세요.
- 다양한 환경(개발/테스트/프로덕션)에 맞게 서로 다른 CIDR 범위를 예약합니다.
2. 퍼블릭 서브넷과 프라이빗 서브넷 분리
- 공개 서브넷에 데이터베이스나 중요한 시스템을 배치하지 마세요.
- 공개 서브넷은 사용자에게 직접 노출되어야 하는 서비스에만 사용됩니다.
3. 크로스 AZ 배포
- 여러 가용성 영역에 서브넷을 생성하여 고가용성을 개선합니다.
- 데이터베이스와 애플리케이션 서버는 가능한 한 서로 다른 AZ의 개인 서브넷에 배포해야 합니다.
4. 권한 최소화
- 보안 그룹과 네트워크 ACL은 "기본적으로 거부하고 필요한 트래픽만 허용"이라는 원칙을 따라야 합니다.
- NAT 게이트웨이와 IGW의 사용은 엄격하게 모니터링되어야 합니다.
5. 모니터링 및 로깅
- 맞잡다 VPC 흐름 로그 보안 및 네트워크 문제를 해결하는 데 도움이 되도록 서브넷 내 트래픽을 기록합니다.
결론적으로
AWS VPC 서브넷은 클라우드 네트워크 아키텍처의 핵심 구성 요소입니다. 서브넷을 적절하게 분할하고 구성하면 사용자는 다음과 같은 이점을 얻을 수 있습니다.
- 보안을 강화하기 위해 리소스를 유연하게 격리하고 관리합니다.
- 3계층 아키텍처, 하이브리드 클라우드, 지역 간 배포와 같은 복잡한 애플리케이션 시나리오를 지원합니다.
- 공개 및 비공개 서브넷을 나누면 외부 서비스 제공과 중요한 리소스 보호 간의 균형을 이룰 수 있습니다.
- AWS에서 제공하는 게이트웨이, 라우팅 테이블, 보안 그룹, 모니터링 도구의 도움으로 제어가 용이하고 탄력적으로 확장 가능한 네트워크 환경을 구축하세요.
간단히 말해서,서브넷은 단순히 IP 주소를 구분하는 것이 아니라 AWS 클라우드 네트워크의 보안, 가용성 및 아키텍처 설계의 초석이기도 합니다.AWS에서 확장 가능하고 가용성이 높은 시스템을 구축하려는 기업이나 개인에게 서브넷의 원리와 응용 프로그램을 숙지하는 것은 필수적인 단계입니다.
