DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

안전한 AWS VPC를 처음부터 구축하는 가이드

계획된 CIDR 범위, 퍼블릭 및 프라이빗 서브넷, 라우트 테이블, NAT, 보안 그룹, 플로우 로그를 사용하여 안전한 AWS VPC를 구축합니다.

안전한 AWS VPC를 처음부터 구축하는 가이드

AWS VPC는 클라우드 리소스에 프라이빗 네트워크 경계를 제공하지만, 기본 형태는 프로덕션 환경에 충분하지 않은 경우가 많습니다. 데이터베이스를 퍼블릭 서브넷에 배치하거나, 중복되는 CIDR 범위를 재사용하거나, 광범위한 보안 그룹 규칙을 열어두면 나중에 해결하기 어려운 문제가 발생할 수 있습니다.

이 가이드는 퍼블릭 서브넷(진입점용), 프라이빗 서브넷(애플리케이션 및 데이터베이스 워크로드용), 라우트 테이블, NAT, 보안 그룹, 기본 모니터링을 사용하여 안전한 AWS VPC를 처음부터 구축하는 방법을 보여줍니다.

핵심 VPC 개념 이해하기

구성 단계에 들어가기 전에 AWS VPC의 기본 개념을 이해하는 것이 중요합니다.

  • VPC (Virtual Private Cloud): AWS 계정 전용 가상 네트워크입니다. AWS Cloud 내에서 논리적으로 격리된 섹션으로, AWS 리소스를 시작할 수 있습니다.
  • 서브넷: VPC 내의 IP 주소 범위입니다. 생성한 서브넷에 AWS 리소스를 시작할 수 있습니다. 서브넷은 VPC CIDR 블록의 하위 집합인 CIDR 블록으로 정의됩니다.
  • 라우트 테이블: 서브넷 또는 게이트웨이에서 네트워크 트래픽이 전달되는 위치를 결정하는 데 사용되는 규칙(라우트) 집합입니다.
  • 인터넷 게이트웨이 (IGW): 퍼블릭 IP 주소와 게이트웨이 경로가 있는 리소스에 대해 인터넷 라우팅 가능 트래픽을 허용하는 VPC 구성 요소입니다.
  • NAT 게이트웨이 (Network Address Translation): 프라이빗 서브넷의 인스턴스가 인터넷에서 시작된 인바운드 연결을 방지하면서 인터넷에 액세스할 수 있도록 하는 고가용성 및 확장 가능한 NAT 서비스입니다.
  • 보안 그룹: 인스턴스에 대한 가상 방화벽 역할을 하여 인바운드 및 아웃바운드 트래픽을 제어합니다. 인스턴스 수준에서 작동합니다.
  • 네트워크 액세스 제어 목록 (NACL): VPC에 대한 선택적 보안 계층으로, 하나 이상의 서브넷에서 들어오고 나가는 트래픽을 제어하는 방화벽 역할을 합니다. 서브넷 수준에서 작동합니다.

단계별 VPC 생성

이제 안전한 VPC 구축을 시작해 보겠습니다.

1. IP 주소 체계 계획

첫 번째이자 가장 중요한 단계는 VPC 및 해당 서브넷의 IP 주소 범위를 계획하는 것입니다. 여기에는 VPC의 CIDR(Classless Inter-Domain Routing) 블록을 선택하는 작업이 포함됩니다.

  • VPC CIDR 블록: 온프레미스 네트워크 또는 VPN이나 Direct Connect를 통해 연결할 수 있는 다른 AWS VPC와 겹치지 않는 프라이빗 IP 주소 범위를 선택합니다. AWS는 RFC 1918 IP 주소 범위(10.0.0.0/8, 172.16.0.0/12 또는 192.168.0.0/16)를 사용할 것을 권장합니다. CIDR 블록은 /16(65,536개의 IP 주소)에서 /28(16개의 IP 주소)까지 가능합니다.

    • 예시: 10.0.0.0/16은 VPC에 넉넉한 주소 공간을 제공합니다.

  • 서브넷 CIDR 블록: VPC의 CIDR 블록을 서브넷의 더 작은 CIDR 블록으로 나눕니다. 각 서브넷의 CIDR 블록이 VPC의 CIDR 블록의 하위 집합이고 다른 서브넷과 겹치지 않는지 확인합니다.

    • 예시 (VPC가 10.0.0.0/16인 경우):
      • 퍼블릭 서브넷 1: 10.0.1.0/24
      • 퍼블릭 서브넷 2: 10.0.2.0/24
      • 프라이빗 서브넷 1: 10.0.10.0/24
      • 프라이빗 서브넷 2: 10.0.11.0/24

2. VPC 생성

AWS Management Console에서 VPC 대시보드로 이동하여 새 VPC를 생성합니다.

  1. VPC 대시보드 > VPC > VPC 생성으로 이동합니다.
  2. 이름 태그: VPC에 설명적인 이름을 지정합니다(예: MySecureVPC).
  3. IPv4 CIDR 블록: 계획한 CIDR 블록을 입력합니다(예: 10.0.0.0/16).
  4. IPv6 CIDR 블록: 필요한 경우 IPv6 CIDR 블록을 활성화하도록 선택할 수 있습니다.
  5. 테넌시: 대부분의 사용 사례에서는 기본값이 적합합니다. 전용은 더 높은 비용으로 하드웨어 격리를 제공합니다.
  6. VPC 생성을 클릭합니다.

3. 서브넷 생성

이제 VPC 내에 퍼블릭 및 프라이빗 서브넷을 생성합니다.

  1. VPC 대시보드 > 서브넷 > 서브넷 생성으로 이동합니다.
  2. VPC ID: 방금 생성한 VPC를 선택합니다.
  3. 서브넷 이름: 이름을 제공합니다(예: MyPublicSubnet-AZ1).
  4. 가용 영역: 가용 영역(AZ)을 선택합니다. 고가용성을 위해 여러 AZ에 리소스를 배포하는 것이 가장 좋습니다.
  5. IPv4 CIDR 블록: 이 서브넷의 CIDR 블록을 입력합니다(예: 10.0.1.0/24).
  6. 서브넷 생성을 클릭합니다.

복원력을 위해 계획된 모든 퍼블릭 및 프라이빗 서브넷이 서로 다른 가용 영역에 있도록 이 과정을 반복합니다.

4. 인터넷 게이트웨이(IGW) 생성

퍼블릭 서브넷이 인터넷에 액세스하려면 IGW가 필요합니다.

  1. VPC 대시보드 > 인터넷 게이트웨이 > 인터넷 게이트웨이 생성으로 이동합니다.
  2. 이름 태그: MyVPCInternetGateway.
  3. 인터넷 게이트웨이 생성을 클릭합니다.
  4. 생성 후 IGW를 선택하고 작업을 클릭한 다음 VPC에 연결을 선택합니다. VPC를 선택하고 인터넷 게이트웨이 연결을 클릭합니다.

5. 라우트 테이블 생성

라우트 테이블은 VPC 내에서 트래픽을 전달합니다. 일반적으로 퍼블릭 서브넷용과 프라이빗 서브넷용으로 최소 두 개가 필요합니다.

a. 퍼블릭 라우트 테이블:

  1. VPC 대시보드 > 라우트 테이블 > 라우트 테이블 생성으로 이동합니다.
  2. 이름 태그: MyPublicRouteTable.
  3. VPC: VPC를 선택합니다.
  4. 라우트 테이블 생성을 클릭합니다.
  5. 새로 생성된 MyPublicRouteTable을 선택합니다.
  6. 라우트 탭에서 라우트 편집을 클릭합니다.
  7. 라우트 추가를 클릭합니다.
  8. 대상: 0.0.0.0/0 (모든 IPv4 트래픽).
  9. 대상: 인터넷 게이트웨이를 선택하고 IGW를 선택합니다.
  10. 라우트 저장을 클릭합니다.
  11. 서브넷 연결: 서브넷 연결 탭으로 이동하여 서브넷 연결 편집을 클릭하고 퍼블릭 서브넷을 이 라우트 테이블에 연결합니다.

b. 프라이빗 라우트 테이블 (NAT 게이트웨이 사용):

프라이빗 서브넷의 인스턴스가 인터넷에서 직접 액세스할 수 없으면서도 인터넷에 대한 아웃바운드 연결(예: 소프트웨어 업데이트)을 시작할 수 있도록 하려면 NAT 게이트웨이를 사용합니다.

  1. NAT 게이트웨이 생성:

    • VPC 대시보드 > NAT 게이트웨이 > NAT 게이트웨이 생성으로 이동합니다.
    • 이름: MyNATGateway.
    • 서브넷: 퍼블릭 서브넷 중 하나를 선택합니다.
    • 연결 유형: 퍼블릭.
    • 탄력적 IP 할당 ID: 탄력적 IP 할당을 클릭하여 새 탄력적 IP 주소를 생성하고 할당합니다.
    • NAT 게이트웨이 생성을 클릭합니다.
    • 참고: NAT 게이트웨이는 비용이 발생합니다. 기본 아웃바운드 연결의 경우 NAT 게이트웨이를 위해 퍼블릭 서브넷에 충분한 IP 주소가 있는지 확인하십시오.

  2. 프라이빗 라우트 테이블 생성:

    • VPC 대시보드 > 라우트 테이블 > 라우트 테이블 생성으로 이동합니다.
    • 이름 태그: MyPrivateRouteTable.
    • VPC: VPC를 선택합니다.
    • 라우트 테이블 생성을 클릭합니다.
    • MyPrivateRouteTable을 선택합니다.
    • 라우트 탭에서 라우트 편집을 클릭합니다.
    • 라우트 추가를 클릭합니다.
    • 대상: 0.0.0.0/0.
    • 대상: NAT 게이트웨이를 선택하고 NAT 게이트웨이를 선택합니다.
    • 라우트 저장을 클릭합니다.
    • 서브넷 연결: 서브넷 연결 탭으로 이동하여 서브넷 연결 편집을 클릭하고 프라이빗 서브넷을 이 라우트 테이블에 연결합니다.

6. 보안 그룹 구성

보안 그룹은 인스턴스 수준에서 상태 저장 방화벽 역할을 합니다. 사용자가 정의한 규칙에 따라 트래픽을 허용하거나 거부합니다.

  • 모범 사례: 다양한 유형의 리소스(예: 웹 서버, 데이터베이스 서버, 애플리케이션 서버)에 대해 특정 보안 그룹을 생성합니다. 지나치게 허용적인 규칙을 사용하지 마십시오.

예시: 웹 서버 보안 그룹 (WebServerSG)

  1. VPC 대시보드 > 보안 그룹 > 보안 그룹 생성으로 이동합니다.
  2. 보안 그룹 이름: WebServerSG.
  3. 설명: HTTP 및 HTTPS 액세스 허용.
  4. VPC: VPC를 선택합니다.
  5. 인바운드 규칙:
    • 유형: HTTP, 프로토콜: TCP, 포트 범위: 80, 소스: 0.0.0.0/0 (또는 더 구체적인 신뢰할 수 있는 IP 범위).
    • 유형: HTTPS, 프로토콜: TCP, 포트 범위: 443, 소스: 0.0.0.0/0 (또는 더 구체적인 신뢰할 수 있는 IP 범위).
    • (선택 사항) 유형: SSH, 프로토콜: TCP, 포트 범위: 22, 소스: 신뢰할 수 있는 IP 주소/범위 (관리에 중요).
  6. 아웃바운드 규칙: 기본적으로 모든 아웃바운드 트래픽(0.0.0.0/0)을 허용합니다. 필요한 경우 제한할 수 있습니다.
  7. 보안 그룹 생성을 클릭합니다.

예시: 데이터베이스 서버 보안 그룹 (DatabaseSG)

  1. DatabaseSG라는 이름의 새 보안 그룹을 생성합니다.
  2. 인바운드 규칙:
    • 데이터베이스의 기본 포트(예: MySQL의 경우 3306, PostgreSQL의 경우 5432)에서 오직 애플리케이션 서버의 보안 그룹(예: WebServerSG 또는 AppServerSG)에서 오는 트래픽을 허용하는 규칙을 추가합니다.
    • 소스: 사용자 지정을 선택한 다음 애플리케이션 서버 보안 그룹의 ID를 입력합니다.
  3. 아웃바운드 규칙: 일반적으로 모든 아웃바운드 트래픽을 허용합니다.

7. 네트워크 액세스 제어 목록(NACL) 구성

NACL은 서브넷 수준에서 작동하는 상태 비저장 방화벽입니다. 추가 방어 계층 역할을 합니다.

  • 상태 저장 vs. 상태 비저장: 보안 그룹은 상태 저장(인바운드 트래픽을 허용하면 아웃바운드 응답이 자동으로 허용됨)입니다. NACL은 상태 비저장(인바운드 및 아웃바운드 트래픽 모두에 대해 명시적으로 규칙을 정의해야 함)입니다.

  • 모범 사례: 특정 서브넷 수준 액세스 제어가 필요하지 않은 경우 NACL은 종종 기본 구성으로 남겨둡니다. 관리가 복잡할 수 있습니다.

NACL을 사용해야 하는 경우:

  1. VPC 대시보드 > 네트워크 ACL > 네트워크 ACL 생성으로 이동합니다.
  2. 이름 태그: MyNacl.
  3. VPC: VPC를 선택합니다.
  4. 네트워크 ACL 생성을 클릭합니다.
  5. NACL을 선택하고 인바운드 규칙에서 규칙을 추가합니다.
  6. 규칙 번호: NACL은 가장 낮은 번호의 규칙부터 순서대로 규칙을 평가합니다. 향후 규칙 삽입을 위해 100, 200, 300 등과 같은 번호를 사용합니다.
  7. 허용/거부: 트래픽을 허용할지 거부할지 지정합니다.
  8. 프로토콜, 포트 범위, 소스/대상: 트래픽 매개변수를 정의합니다.
  9. 해당 아웃바운드 규칙을 구성하는 것을 잊지 마십시오.
  10. 서브넷 연결 탭으로 이동하여 NACL을 서브넷에 연결합니다.

예제 배포 시나리오

일반적인 웹 애플리케이션을 고려해 보십시오.

  • VPC: 10.0.0.0/16

  • 퍼블릭 서브넷 1 (us-east-1a): 10.0.1.0/24 (MyPublicRouteTable 및 IGW에 연결됨)

  • 퍼블릭 서브넷 2 (us-east-1b): 10.0.2.0/24 (MyPublicRouteTable 및 IGW에 연결됨)

  • 프라이빗 서브넷 1 (us-east-1a): 10.0.10.0/24 (MyPrivateRouteTable 및 NAT 게이트웨이에 연결됨)

  • 프라이빗 서브넷 2 (us-east-1b): 10.0.11.0/24 (MyPrivateRouteTable 및 NAT 게이트웨이에 연결됨)

  • 인터넷 게이트웨이: VPC에 연결됨.

  • NAT 게이트웨이: 탄력적 IP를 사용하여 퍼블릭 서브넷 1에 배포됨.

  • 퍼블릭 라우트 테이블: 0.0.0.0/0을 IGW로 전달합니다. 퍼블릭 서브넷에 연결됨.

  • 프라이빗 라우트 테이블: 0.0.0.0/0을 NAT 게이트웨이로 전달합니다. 프라이빗 서브넷에 연결됨.

  • 로드 밸런서용 보안 그룹 (퍼블릭 서브넷): 0.0.0.0/0의 HTTP/HTTPS를 허용합니다.

  • 웹 서버용 보안 그룹 (프라이빗 서브넷): 로드 밸런서 SG의 HTTP/HTTPS 및 신뢰할 수 있는 IP의 SSH를 허용합니다.

  • 데이터베이스용 보안 그룹 (프라이빗 서브넷): 웹 서버 SG의 MySQL/PostgreSQL을 허용합니다.

중요한 보안 고려 사항

  • 최소 권한 원칙: 보안 그룹 및 NACL에 필요한 권한만 부여합니다. 가능한 한 소스 IP 주소를 제한합니다.
  • 여러 가용 영역 사용: 고가용성 및 재해 복구를 위해 여러 AZ에 서브넷과 리소스를 분산합니다. 이는 다른 AZ에 서브넷을 생성하고 적절한 라우트 테이블에 연결하여 달성됩니다.
  • 정기적으로 보안 그룹 및 NACL 검토: 애플리케이션이 발전함에 따라 보안 규칙도 발전해야 합니다. 정기적으로 감사하고 업데이트합니다.
  • 민감한 리소스에 퍼블릭 서브넷 사용 방지: 데이터베이스, 애플리케이션 서버 및 기타 민감한 리소스는 프라이빗 서브넷에 있어야 합니다. 직접 인터넷 액세스가 필요한 리소스(예: 로드 밸런서 또는 배스천 호스트)만 퍼블릭 서브넷에 있어야 합니다.
  • 배스천 호스트 고려: 프라이빗 서브넷의 인스턴스에 SSH로 연결해야 하는 경우 퍼블릭 서브넷에 강화된 배스천 호스트를 사용하는 것을 고려하십시오. 알려진 IP 주소로 배스천 호스트에 대한 SSH 액세스를 제한합니다.
  • VPC 플로우 로그: VPC 플로우 로그를 활성화하여 VPC의 네트워크 인터페이스로 들어오고 나가는 IP 트래픽에 대한 정보를 캡처합니다. 이는 보안 모니터링 및 문제 해결에 매우 중요합니다.
  • 네트워크 분할: 다른 VPC 및 서브넷을 사용하여 환경(예: 개발, 스테이징, 프로덕션)과 애플리케이션의 다른 계층을 분할합니다.

최종 요점

트래픽 흐름에 따라 VPC를 구축하십시오. 퍼블릭 서브넷은 로드 밸런서, NAT 게이트웨이 또는 엄격하게 제어된 배스천 액세스만 노출해야 하며, 애플리케이션 및 데이터베이스 리소스는 프라이빗 상태를 유지해야 합니다. 시작한 후에는 보안 그룹, 라우트 테이블 및 VPC 플로우 로그를 계속 검토하여 네트워크가 애플리케이션이 실제로 실행되는 방식과 일치하도록 유지하십시오.