i. VPC

📌

VPC(Virtual Private Cloud)는 AWS 클라우드 내에서 사용자 전용의 논리적으로 격리된 가상 네트워크 공간을 의미합니다.

🔗 Amazon VPC란 무엇인가?

---

• 사용자는 VPC라는 가상 네트워크 공간에서 사용할 IP 주소 범위, 서브넷, 라우팅 테이블, 게이트웨이 구성 등 네트워크 환경의 모든 측면을 제어할 수 있습니다.

---

• VPC는 가장 큰 네트워크 경계로 사용지가 정의한 IP 주소 범위(예: 10.0.0.0/16, 192.168.0.0/16:등..)를 가집니다.

  • 사용자는 CIDR (Classless Inter-Domain Routing) 표기법을 통해 유연하게 IP 주소 공간을 할당하고 관리할 수 있습니다. / 뒤의 숫자는 네트워크의 크기를 나타내며, 예를 들어 /16은 약 65,536개(2^16, 실제 사용 가능 IP는 약간 적음)

  • 하이브리드 환경에서 다른 네트워크(예: 온프레미스 등)에서 사용하는 IP 대역과 겹치지 않는 대역(일반적으로 RFC 1918 사설 IP 대역: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)을 신중하게 선택해야 합니다.

    만약 IP 대역이 중복되면 VPC와 온프레미스 간 VPN 또는 Direct Connect 연결 시 라우팅 문제가 발생하여 통신이 불가능해집니다(어떻게든 가능하지만, 구성에 신경을 써야함.)

• VPC는 리전(Region) 내에 생성되며, 여러 가용 영역(Availability Zone, AZ)에 걸쳐 있을 수 있습니다.

  • VPC는 특정 AWS 리전(예: 서울, 도쿄, 버즈니아 북부 등..)에 종속됩니다. VPC 내의 리소스들은 기본적으로 해당 리전 내에 위치하게 되며, 이는 실제 물리적인 지리적 위치와 관련되어 네트워크 지연 시간(Latency) 등에 영향을 미칩니다.

  • Availability Zone은 독립적인 전력, 냉각, 네트워크 인프라를 갖추고 있어, 하나의 Availability Zone에 장애가 발생하더라도, 다른 Availability Zone에 영향을 받지 않도록 설계되어 있습니다. VPC는 다수의 Availability Zone의 집합으로 애플리케이션 구성 시, 해당 구조를 활용하여 내결함성(Fault Tolerance)과 고가용성을 확보할 수 있습니다

    • 예를 들어, 웹 애플리케이션을 구축할 때 로드 밸런서는 여러 AZ에 걸쳐 트래픽을 분산시키고, 웹 서버 인스턴스는 각기 다른 AZ에 위치한 서브넷들에 분산 배치합니다. 만약 하나의 AZ(예: ap-northeast-2a) 전체에 문제가 생겨도, 다른 AZ(ap-northeast-2c, ap-northeast-2d 등)에 있는 인스턴스들이 계속 서비스를 제공할 수 있습니다. VPC는 이러한 분산된 리소스들이 마치 하나의 네트워크에 있는 것처럼 원활하게 통신할 수 있는 기반을 제공합니다.
      

• VPC는 다른 VPC와는 기본적으로 완전히 격리됩니다

  • 사용자가 생성한 VPC는 AWS 계정 내의 다른 VPC는 물론, 다른 AWS 사용자의 VPC와도 네트워크 수준에서 완전히 분리되어 있어 별도의 설정 없이는 서로에게 트래픽을 보낼 수 없습니다.

  • 별도의 AWS 서비스(예: AWS PrivateLink, AWS Transit Gateway, VPC Peering 등)를 사용하여 격리된 VPC 간에 트래픽을 보낼 수 있습니다.

ii. Multi VPC

📌

처음에는 단일 VPC(Virtual Private Cloud)로 시작하는 경우가 많지만, 시스템 규모가 커지고 요구사항이 복잡해짐에 따라 여러 개의 VPC를 생성하여 사용하는 것이 일반적입니다.

• 환경 별(예: 개발, 스테이징, 운영)로 VPC를 분리하여, 각 확경의 독립성을 보장하고, 한 환경에서의 작업이나 장애가 다른 환경에 영향일 미치는 것을 방지할 수 있습니다.

  • 개발자가 실수로 개발용 스크립티에 운영 데이터베이스의 엔드포인트를 참조한 경우, VPC가 분리되어 있다면, 기본적으로 개발 VPC에 운영 VPC로 연결이 불가능하기 때문에, 연결이 실패하여 운영 데이터베이스를 보호할 수 있습니다. 만약 단일 VPC 환경이라면, 보안 그룹 설정에 의존해야 합니다.

  • 스테이징 환경에서 대규모 부하 테스트를 진행할 때, 발생하는 대량의 네트워크 트래픽이 운영 환경에 영향을 주지 않습니다.
    단일 VPC 환경에서 NAT Gateway를 모든 환경이 공유해서 사용하는 경우, 대량의 네트워크 트래픽이 운영 환경에 영향을 미칠 수 있습니다.(NAT Gateway를 나누어 사용)

  • 개발 환경은 운영 환경보다 상대적으로 낮은 보안 수준으로 접근을 제어합니다. 만약 개발 환경의 웹서버가 악성코드에 감염되더라도, 운영 VPC에 있는 내부 시스템이나 데이터베이스로 직접적인 네트워크 연결을 시도할 수 없어 피해 확산을 지연시키거나 막을 수 있습니다.

• 환경 별로 VPC 나누어 사용하는 것을 기본이며, 필요에 따라서 AWS 계정 자체를 나누어 사용하는 것을 권장합니다.

  • AWS 계정을 분할함으로써 더 높은 수준의 격리를 통해 보안을 강화할 수 있습니다. 이는 단일 계정에서 설정을 통해 동일한 수준으로 보안을 강화할 수 있습니다. 하지만 “항상 사람을 실수를 할 수 있다”라는 것을 생각해야합니다.

  • VPC는 주로 네트워크 수준의 격리를 제공합니다. 하지만 계정 자체의 보안 문제(예: 루트 계정 탈취, 강력한 권한을 가진 IAM 사용자의 실수 또는 악의적 행위)는 해당 계정 내의 모든 환경에 영향을 미칠 수 있습니다.계정 자체가 분리되어 있다면, 한 계정의 보안 사고(예: 특정 계정의 Access Key 유출)가 발생하더라도, 다른 계정의 리소스에는 직접적인 위협이 되지 않습니다.

    즉, 장애 격리 범위가 해당 계정으로 제한되어 전체 시스템의 안정성을 높이는 데 유리합니다.
    

  • 단일 계정 내에서 프로젝트 및 환경별로 발생하는 비용을 추적하기 위해서는 리소스 태그(Tag) 설정을 통해 비용을 추적해야 합니다. 이러한 태그를 일관되게 적용하는 것이 중요하며, 특정 서비스에 따라서 완벽한 분리가 어려울 수 있습니다

    각 계정별로 청구서가 발행되므로 비용 분배가 명확합니다. 특정 부서, 프로젝트, 환경(개발/운영)별 비용을 정확히 파악하고 예산을 관리하는 데 매우 효과적입니다