본문 바로가기
클라우드

AWS VPC 보안 기능 한 번에 이해하기: 클라우드 네트워크를 안전하게 설계하는 방법

by gasbugs 2026. 6. 9.
반응형

클라우드 보안을 이야기할 때 많은 사람이 IAM, 암호화, 로그, 취약점 점검부터 떠올립니다. 물론 모두 중요합니다. 하지만 AWS 환경에서 실제 서비스가 동작하는 기반은 대부분 네트워크입니다.

 

EC2, RDS, EKS, ECS, Lambda 일부 구성, ElastiCache, OpenSearch 같은 서비스는 결국 VPC 안에서 서로 통신하거나 외부와 연결됩니다.

 

그래서 AWS 보안의 출발점은 VPC를 어떻게 설계하느냐에 달려 있습니다.

 

VPC는 단순히 서버를 넣어두는 네트워크 공간이 아닙니다. 어떤 리소스를 외부에 노출할지, 어떤 리소스는 내부에서만 접근하게 할지, 어떤 경로로 인터넷을 나가게 할지, 어떤 트래픽을 기록하고 분석할지, 실수로 열린 경로가 없는지 확인하는 보안 경계입니다.

 

이번 글에서는 AWS VPC 보안을 위해 자주 사용되는 주요 기능들을 실무 관점에서 정리해보겠습니다.

 

1. VPC와 서브넷: 보안 경계의 시작점

VPC는 사용자가 직접 정의하는 논리적인 가상 네트워크입니다. 온프레미스 환경으로 비유하면 회사 내부망을 AWS 안에 만든 것과 비슷합니다.

 

하지만 VPC 하나를 만들었다고 보안이 완성되는 것은 아닙니다. 중요한 것은 VPC 내부를 어떻게 나누느냐입니다.

가장 기본적인 방식은 퍼블릭 서브넷과 프라이빗 서브넷을 분리하는 것입니다.

퍼블릭 서브넷

퍼블릭 서브넷은 인터넷 게이트웨이로 향하는 라우팅이 있는 서브넷입니다.

일반적으로 다음과 같은 리소스가 위치합니다.

  • ALB
  • Bastion Host
  • NAT Gateway
  • 외부에서 직접 접근해야 하는 일부 서비스

프라이빗 서브넷

프라이빗 서브넷은 인터넷에서 직접 접근할 수 없도록 구성하는 서브넷입니다.

일반적으로 다음과 같은 리소스가 위치합니다.

  • 애플리케이션 서버
  • 데이터베이스
  • 내부 API 서버
  • EKS 노드
  • ECS 서비스
  • ElastiCache
  • OpenSearch

보안 관점에서 중요한 원칙은 간단합니다.

외부에 직접 노출해야 하는 리소스만 퍼블릭 서브넷에 두고, 나머지는 가능하면 프라이빗 서브넷에 배치해야 합니다.

 

특히 데이터베이스는 대부분의 경우 퍼블릭 서브넷에 둘 필요가 없습니다.

실무에서 가장 흔한 실수는 “테스트니까 잠깐만 퍼블릭으로 열자”입니다. 문제는 이 설정이 운영까지 그대로 남는 경우가 많다는 점입니다.

 

VPC 보안은 복잡한 보안 장비보다 먼저, 리소스가 놓이는 위치를 올바르게 설계하는 것에서 시작합니다.

2. 라우트 테이블: 트래픽의 이동 경로를 통제하는 기능

VPC 안에서 트래픽이 어디로 이동할지는 라우트 테이블이 결정합니다.

 

서브넷이 아무리 프라이빗처럼 보여도 라우트 테이블에 인터넷 게이트웨이로 향하는 기본 경로가 있다면 외부 통신이 가능한 구조가 됩니다.

 

예를 들어 다음과 같은 라우팅이 있다면 해당 서브넷은 퍼블릭 성격을 갖습니다.

0.0.0.0/0 -> Internet Gateway

 

반대로 프라이빗 서브넷의 일반적인 라우팅은 다음과 같습니다.

0.0.0.0/0 -> NAT Gateway

 

이 경우 프라이빗 서브넷의 인스턴스는 인터넷으로 나갈 수는 있지만, 인터넷에서 해당 인스턴스로 직접 들어올 수는 없습니다.

즉, 패치 다운로드, 패키지 설치, 외부 API 호출은 가능하지만 외부 사용자가 직접 서버에 접속하는 구조는 아닙니다.

 

라우트 테이블은 보안 그룹이나 Network ACL처럼 “허용/차단 규칙”으로 보이지 않기 때문에 보안 기능처럼 느껴지지 않을 수 있습니다. 하지만 실제로는 VPC 보안에서 매우 중요한 기능입니다.

 

잘못된 라우팅은 내부망을 외부에 노출시킬 수 있습니다.

VPC 보안 점검 시 다음 항목을 반드시 확인해야 합니다.

  • 데이터베이스 서브넷에 Internet Gateway 경로가 있는가?
  • 내부 애플리케이션 서브넷이 불필요하게 인터넷과 직접 연결되어 있는가?
  • NAT Gateway를 통해 나가는 트래픽이 통제되고 있는가?
  • Transit Gateway, VPC Peering, VPN 연결을 통해 예상치 못한 네트워크 경로가 생기지 않았는가?

VPC 보안 점검을 할 때는 보안 그룹만 볼 것이 아니라, 라우트 테이블을 함께 봐야 합니다.

실제 공격 경로는 “허용된 포트”와 “열린 라우팅”이 결합될 때 만들어집니다.

3. 보안 그룹: 리소스 단위의 가상 방화벽

보안 그룹은 VPC 보안에서 가장 많이 사용하는 기능입니다.

EC2, RDS, ALB, ENI, VPC Endpoint 등 여러 리소스에 연결해 인바운드와 아웃바운드 트래픽을 제어합니다.

보안 그룹의 핵심 특징은 상태 저장 방식이라는 점입니다.

 

예를 들어 EC2 인스턴스가 외부로 HTTPS 요청을 보냈다면, 그 응답 트래픽은 인바운드 규칙에 따로 명시하지 않아도 허용됩니다.

반대로 외부에서 EC2로 들어오는 트래픽은 인바운드 규칙에 허용되어 있어야 합니다.

위험한 보안 그룹 예시

다음과 같은 설정은 운영 환경에서 매우 위험합니다.

SSH 22번 포트      0.0.0.0/0 허용
RDP 3389번 포트    0.0.0.0/0 허용
MySQL 3306번 포트  0.0.0.0/0 허용
모든 아웃바운드    0.0.0.0/0 허용

 

테스트 환경에서는 자주 보이는 설정이지만, 운영 환경에서는 매우 위험합니다.

특히 SSH와 RDP를 전체 인터넷에 열어두면 무차별 대입 공격, 취약한 계정 공격, 노출된 키 악용의 대상이 될 수 있습니다.

권장되는 보안 그룹 설계

좋은 방식은 소스 IP 또는 다른 보안 그룹을 기준으로 제한하는 것입니다.

예를 들어 ALB 보안 그룹은 80, 443 포트를 인터넷에 허용할 수 있습니다.

 

하지만 애플리케이션 서버 보안 그룹은 인터넷이 아니라 ALB 보안 그룹에서 오는 트래픽만 허용해야 합니다.

RDS 보안 그룹은 애플리케이션 서버 보안 그룹에서 오는 3306 또는 5432 포트만 허용하면 됩니다.

 

일반적인 흐름은 다음과 같습니다.

사용자 -> ALB -> 애플리케이션 서버 -> 데이터베이스

이때 데이터베이스는 사용자의 IP를 직접 알 필요도 없고, 인터넷에 열릴 필요도 없습니다.

오직 애플리케이션 서버에서 오는 트래픽만 받으면 됩니다.

 

보안 그룹은 단순히 포트를 여는 기능이 아닙니다.

보안 그룹은 애플리케이션 계층 간 신뢰 관계를 네트워크 수준에서 표현하는 기능입니다.

4. Network ACL: 서브넷 단위의 보조 방어선

Network ACL은 서브넷 단위로 동작하는 접근 제어 기능입니다.

보안 그룹이 리소스 단위라면, Network ACL은 서브넷 경계에서 트래픽을 제어합니다.

 

보안 그룹과 Network ACL은 다음과 같은 차이가 있습니다.

 

구분 보안 그룹 Network ACL
적용 단위 리소스 또는 ENI 서브넷
동작 방식 상태 저장 상태 비저장
규칙 유형 허용 규칙 허용 및 거부 규칙
주 사용 목적 리소스 단위 통제 서브넷 단위 보조 통제

 

상태 비저장 방식이라는 말은 요청과 응답을 별개로 본다는 뜻입니다.

 

예를 들어 인바운드 80번 포트를 허용했더라도, 응답으로 나가는 아웃바운드 트래픽이 허용되어 있지 않으면 통신이 실패할 수 있습니다.

 

Network ACL은 세밀한 애플리케이션 통제보다는 서브넷 단위의 넓은 통제에 적합합니다.

예를 들어 특정 악성 IP 대역을 서브넷 전체에서 차단하거나, 특정 서브넷은 정해진 포트 외에는 통신하지 못하도록 제한하는 식입니다.

 

다만 모든 보안을 Network ACL로 처리하려고 하면 운영이 복잡해질 수 있습니다.

실무에서는 보안 그룹을 주된 통제 수단으로 사용하고, Network ACL은 보조 방어선이나 가드레일로 사용하는 방식이 일반적입니다.

5. Internet Gateway와 NAT Gateway: 인터넷 연결을 안전하게 분리하기

VPC가 인터넷과 통신하려면 Internet Gateway가 필요합니다.

하지만 Internet Gateway가 있다고 해서 모든 리소스가 인터넷에 노출되는 것은 아닙니다.

 

실제 인터넷 접근 여부는 다음 요소에 따라 결정됩니다.

  • 퍼블릭 IP 존재 여부
  • 라우트 테이블
  • 보안 그룹
  • Network ACL
  • Internet Gateway 연결 여부

퍼블릭 서브넷의 리소스는 Internet Gateway를 통해 외부와 직접 통신할 수 있습니다.

반면 프라이빗 서브넷의 리소스는 일반적으로 NAT Gateway를 통해 외부로 나갑니다.

NAT Gateway는 프라이빗 서브넷 리소스가 인터넷으로 나갈 수 있게 해주지만, 외부 인터넷에서 프라이빗 인스턴스로 직접 연결을 시작할 수는 없게 해줍니다.

 

이 구조는 매우 중요합니다.

예를 들어 애플리케이션 서버는 운영체제 업데이트나 외부 API 호출을 위해 인터넷 접속이 필요할 수 있습니다.

하지만 인터넷 사용자가 애플리케이션 서버에 직접 접속할 필요는 없습니다.

 

이때 NAT Gateway를 사용하면 다음 구조를 만들 수 있습니다.

프라이빗 서버 -> NAT Gateway -> Internet Gateway -> 인터넷

 

즉, 나가는 통신은 허용하고 들어오는 직접 연결은 차단하는 구조입니다.

다만 NAT Gateway만으로 완전한 보안이 되는 것은 아닙니다.

 

NAT Gateway는 기본적으로 나가는 트래픽을 세밀하게 검사하거나 도메인별로 차단하는 보안 장비가 아닙니다.

따라서 중요한 환경에서는 다음 기능과 함께 설계하는 것이 좋습니다.

  • AWS Network Firewall
  • 프록시 서버
  • Route 53 Resolver DNS Firewall
  • egress filtering
  • VPC Flow Logs

6. VPC Endpoint와 PrivateLink: AWS 서비스 접근을 사설망으로 처리하기

많은 AWS 서비스는 퍼블릭 엔드포인트를 통해 접근합니다.

 

예를 들어 EC2에서 S3에 접근하거나, ECS에서 ECR 이미지를 가져오거나, 애플리케이션에서 Secrets Manager를 호출하는 상황을 생각해볼 수 있습니다.

 

보안이 중요한 환경에서는 가능하면 인터넷을 거치지 않고 AWS 내부 네트워크 경로로 서비스에 접근하는 것이 좋습니다.

이때 사용하는 기능이 VPC Endpoint입니다.

 

VPC Endpoint는 크게 두 가지 유형으로 나눌 수 있습니다.

Gateway Endpoint

Gateway Endpoint는 대표적으로 다음 서비스에 사용됩니다.

  • Amazon S3
  • Amazon DynamoDB

Gateway Endpoint를 사용하면 별도의 Internet Gateway나 NAT Gateway 없이 VPC 내부에서 S3, DynamoDB로 접근할 수 있습니다.

Interface Endpoint

Interface Endpoint는 AWS PrivateLink 기반으로 동작하며, AWS 서비스에 사설 IP 기반으로 접근할 수 있게 해줍니다.

대표적으로 다음 서비스에 사용할 수 있습니다.

  • AWS Systems Manager
  • AWS Secrets Manager
  • Amazon ECR
  • Amazon CloudWatch Logs
  • AWS STS
  • AWS KMS
  • Amazon ECS
  • Amazon EKS 관련 일부 서비스

VPC Endpoint의 보안상 장점은 큽니다.

  • 인터넷 경로를 줄일 수 있다.
  • NAT Gateway 의존도를 줄일 수 있다.
  • 엔드포인트 정책으로 접근 가능한 작업을 제한할 수 있다.
  • S3 버킷 정책에서 특정 VPC Endpoint를 통한 요청만 허용할 수 있다.
  • 자격 증명이 외부에서 탈취되더라도 접근 경로를 제한할 수 있다.

예를 들어 다음과 같은 보안 정책을 만들 수 있습니다.

이 S3 버킷은 우리 VPC의 특정 VPC Endpoint를 통해서만 접근 가능하다.

 

이렇게 하면 자격 증명이 탈취되더라도 외부 인터넷에서 바로 S3에 접근하기 어렵게 만들 수 있습니다.

VPC Endpoint는 비용 절감 목적만으로 볼 기능이 아닙니다.

 

실제로는 데이터 유출 경로를 줄이는 강력한 보안 설계 요소입니다.

7. AWS Network Firewall: VPC 단위의 관리형 방화벽

보안 그룹과 Network ACL은 기본적인 네트워크 통제에는 매우 유용하지만, 고급 보안 검사에는 한계가 있습니다.

예를 들어 다음 요구사항이 있다면 AWS Network Firewall을 고려할 수 있습니다.

  • 도메인 기반 필터링
  • 상태 기반 트래픽 검사
  • 침입 탐지 및 방지
  • 중앙 집중형 egress 통제
  • 의심스러운 외부 통신 차단
  • VPC 간 트래픽 검사

AWS Network Firewall은 VPC에 적용할 수 있는 관리형 네트워크 방화벽 서비스입니다.

상태 저장 방화벽 기능과 침입 탐지 및 방지 기능을 제공하며, 인터넷 게이트웨이, NAT Gateway, VPN, Direct Connect 경로 등에서 트래픽을 필터링하는 구조로 사용할 수 있습니다.

실무에서는 특히 아웃바운드 트래픽 통제에 많이 사용됩니다.

 

많은 기업이 인바운드 보안에는 민감하지만, 아웃바운드 보안은 상대적으로 느슨하게 둡니다.

그러나 침해 사고 이후 악성코드가 외부 C2 서버와 통신하거나, 내부 데이터가 외부로 유출되는 방향은 대개 아웃바운드입니다.

 

따라서 중요한 VPC에서는 다음과 같은 정책을 검토해야 합니다.

  • 프라이빗 서브넷의 모든 인터넷 아웃바운드 트래픽을 Network Firewall을 거치게 한다.
  • 허용된 도메인 또는 IP 대역만 외부 통신을 허용한다.
  • 의심스러운 프로토콜이나 비정상 포트를 차단한다.
  • 방화벽 로그를 CloudWatch Logs, S3, Security Lake 등으로 수집한다.

Network Firewall은 단순히 “비싼 방화벽”이 아닙니다.

VPC의 egress 통제와 중앙 보안 정책 적용을 위한 핵심 기능으로 볼 수 있습니다.

8. VPC Flow Logs: 네트워크 흐름을 기록하는 기본 가시성 기능

보안에서 가장 위험한 상태는 “무슨 일이 일어나는지 모르는 상태”입니다.

VPC 안에서 어떤 IP가 어떤 IP로 통신했는지, 어떤 포트가 허용되었는지, 어떤 트래픽이 거부되었는지 알 수 없다면 사고 대응이 매우 어려워집니다.

 

VPC Flow Logs는 VPC, 서브넷, 네트워크 인터페이스 단위로 IP 트래픽 정보를 수집하는 기능입니다.

수집된 로그는 다음 대상으로 보낼 수 있습니다.

  • Amazon CloudWatch Logs
  • Amazon S3
  • Amazon Data Firehose

Flow Logs를 활용하면 다음과 같은 분석이 가능합니다.

  • 특정 EC2가 외부의 낯선 IP와 통신했는지 확인
  • 보안 그룹 또는 Network ACL에 의해 거부된 트래픽 확인
  • 사용하지 않는 포트가 계속 호출되는지 분석
  • 데이터베이스로 직접 접근하려는 시도가 있는지 확인
  • NAT Gateway를 통해 외부로 나가는 트래픽 흐름 파악
  • 침해 사고 발생 시 공격자의 이동 경로 추적

다만 Flow Logs는 패킷의 전체 내용을 저장하는 기능이 아닙니다.

즉, HTTP 본문이나 파일 내용까지 보여주는 것은 아닙니다.

대신 다음과 같은 흐름 정보를 제공합니다.

  • 출발지 IP
  • 목적지 IP
  • 출발지 포트
  • 목적지 포트
  • 프로토콜
  • 허용 또는 거부 여부
  • 바이트 수
  • 패킷 수
  • 시간 정보

그래서 Flow Logs는 “네트워크 CCTV”라기보다는 “네트워크 출입 기록부”에 가깝습니다.

누가 어디로 이동했는지, 어떤 문으로 나갔는지 기록하는 기능입니다.

 

운영 환경에서는 최소한 중요 VPC 또는 중요 서브넷에는 Flow Logs를 활성화하는 것을 권장합니다.

특히 보안 관점에서는 ACCEPT 로그만 볼 것이 아니라 REJECT 로그도 함께 분석해야 합니다.

거부된 트래픽은 공격 시도, 잘못된 설정, 애플리케이션 장애의 단서가 될 수 있습니다.

9. Traffic Mirroring: 패킷 수준 분석이 필요할 때

VPC Flow Logs가 네트워크 흐름 정보를 제공한다면, Traffic Mirroring은 실제 트래픽 복사본을 보안 분석 장비로 전달하는 기능입니다.

 

예를 들어 특정 EC2 인스턴스의 ENI에서 발생하는 트래픽을 복사해 다음 시스템으로 보낼 수 있습니다.

  • IDS
  • NDR
  • 패킷 분석 시스템
  • 포렌식 장비
  • 보안 관제 장비

Traffic Mirroring은 보안 사고 분석, 침입 탐지, 규정 준수, 네트워크 문제 해결에 유용합니다.

다만 모든 환경에 반드시 필요한 기능은 아닙니다.

 

일반적인 웹 서비스 운영에서는 Flow Logs와 애플리케이션 로그만으로도 충분한 경우가 많습니다.

하지만 다음과 같은 환경에서는 유용할 수 있습니다.

  • 금융권 또는 보안 관제가 중요한 환경
  • 패킷 수준의 침입 탐지가 필요한 환경
  • 제로 트러스트 네트워크 분석을 수행하는 환경
  • 침해 사고 발생 시 특정 서버의 트래픽을 상세 분석해야 하는 환경

주의할 점은 Traffic Mirroring이 트래픽 복사 기능이기 때문에 비용, 성능, 개인정보 보호, 저장 정책을 함께 고려해야 한다는 점입니다.

무작정 모든 트래픽을 복제하기보다는 중요한 구간만 선택적으로 미러링하는 것이 좋습니다.

10. Reachability Analyzer: 실제 연결 가능 경로를 검증하는 기능

VPC 보안 설정은 여러 요소가 함께 작동합니다.

다음 요소들이 결합되기 때문에 사람이 눈으로만 확인하면 놓치는 부분이 생길 수 있습니다.

  • 보안 그룹
  • Network ACL
  • 라우트 테이블
  • NAT Gateway
  • Internet Gateway
  • Transit Gateway
  • Load Balancer
  • Network Firewall
  • VPC Endpoint

Reachability Analyzer는 특정 출발지에서 목적지까지 네트워크적으로 도달 가능한지를 분석하는 도구입니다.

 

예를 들어 다음과 같은 질문을 확인할 수 있습니다.

  • 이 EC2에서 RDS 3306 포트로 접근 가능한가?
  • 인터넷에서 이 ENI까지 도달 가능한가?
  • Bastion Host에서 내부 서버로 SSH 접근이 가능한가?
  • 애플리케이션 서버에서만 RDS로 접근 가능한가?
  • 특정 서브넷에서 외부 인터넷으로 나가는 경로가 존재하는가?

도달 가능하면 경로를 단계별로 보여주고, 도달 불가능하면 어떤 구성 요소에서 막혔는지 확인할 수 있습니다.

실무에서 Reachability Analyzer는 장애 분석에도 좋지만, 보안 검증에도 매우 유용합니다.

운영 환경에서 중요한 변경을 하기 전후로 Reachability Analyzer를 사용하면 네트워크 변경에 따른 보안 영향도를 확인할 수 있습니다.

11. Network Access Analyzer: 의도하지 않은 네트워크 접근 찾기

Reachability Analyzer가 특정 출발지와 목적지 사이의 연결 가능성을 확인하는 도구라면, Network Access Analyzer는 더 넓은 관점에서 의도하지 않은 네트워크 접근 경로를 찾는 기능입니다.

예를 들어 다음과 같은 범위 기반 분석을 수행할 수 있습니다.

  • 인터넷에서 접근 가능한 네트워크 인터페이스가 있는가?
  • 특정 VPC 외부에서 내부 리소스로 접근 가능한 경로가 있는가?
  • 의도하지 않은 VPC Peering 경로가 있는가?
  • 외부 네트워크에서 데이터베이스 계층으로 접근 가능한 경로가 있는가?

사람이 모든 리소스 조합을 하나씩 점검하기 어렵기 때문에, 정적 분석 방식으로 네트워크 경로를 찾아주는 기능은 보안 감사에 매우 유용합니다.

 

특히 여러 계정, 여러 VPC, 여러 서브넷을 운영하는 조직에서는 시간이 지나면서 예외 설정이 쌓입니다.

 

대표적인 예는 다음과 같습니다.

  • 처음에는 테스트용으로 열어둔 포트
  • 임시로 만든 VPC Peering 연결
  • 삭제되지 않은 보안 그룹 규칙
  • 운영 이관 중 남은 퍼블릭 접근 경로
  • 불필요하게 넓은 CIDR 허용
  • 임시 VPN 연결
  • 불필요하게 남은 Transit Gateway 라우팅

이런 설정은 문서에는 남지 않고 실제 환경에만 남는 경우가 많습니다.

Network Access Analyzer는 이런 숨은 접근 경로를 찾는 데 도움이 됩니다.

VPC 보안은 한 번 구성하고 끝나는 작업이 아닙니다.

주기적으로 “지금 우리 네트워크가 의도한 대로만 열려 있는가?”를 검증해야 합니다.

12. DNS 보안과 Route 53 Resolver 기반 통제

네트워크 보안에서 IP와 포트만 보는 것은 부족합니다.

실제 악성코드나 내부 시스템은 도메인 이름을 통해 외부와 통신하는 경우가 많습니다.

따라서 DNS 요청을 통제하고 기록하는 것도 중요합니다.

AWS 환경에서는 다음 기능을 활용할 수 있습니다.

  • Route 53 Resolver Query Logs
  • Route 53 Resolver DNS Firewall
  • Network Firewall
  • 프록시 기반 도메인 통제

예를 들어 내부 EC2가 갑자기 의심스러운 도메인을 조회한다면 악성코드 감염이나 데이터 유출 시도를 의심할 수 있습니다.

또한 사내 정책상 허용되지 않은 도메인으로 나가는 요청을 차단할 수도 있습니다.

 

DNS 보안은 특히 아웃바운드 보안과 관련이 깊습니다.

보안 그룹에서 443 포트를 열어둔 것만으로는 어떤 도메인으로 나가는지 알기 어렵습니다.

Network Firewall, 프록시, DNS Firewall, Resolver Query Logs를 함께 사용하면 외부 통신을 더 잘 이해하고 통제할 수 있습니다.

13. VPC 보안을 위한 실무 설계 예시

보안이 잘 구성된 일반적인 3계층 웹 서비스 구조를 생각해보겠습니다.

퍼블릭 서브넷

퍼블릭 서브넷에는 외부와 직접 연결되어야 하는 리소스만 둡니다.

  • ALB
  • NAT Gateway
  • Bastion Host 또는 Session Manager 대체 구성

프라이빗 애플리케이션 서브넷

프라이빗 애플리케이션 서브넷에는 실제 애플리케이션 워크로드를 배치합니다.

  • EC2
  • ECS Service
  • EKS Worker Node
  • 애플리케이션 서버
  • 내부 API 서버

프라이빗 데이터 서브넷

프라이빗 데이터 서브넷에는 외부에 직접 노출되면 안 되는 데이터 계층을 배치합니다.

  • RDS
  • ElastiCache
  • OpenSearch
  • 내부 전용 데이터 저장소

이 구조에서 보안 흐름은 다음과 같습니다.

사용자
  -> ALB
    -> 애플리케이션 서버
      -> 데이터베이스

 

보안 설계는 다음과 같이 적용할 수 있습니다.

  • 사용자는 ALB의 443 포트로만 접근합니다.
  • ALB는 애플리케이션 서버의 특정 포트로만 접근합니다.
  • 애플리케이션 서버는 데이터베이스의 특정 포트로만 접근합니다.
  • 데이터베이스는 인터넷에 직접 노출되지 않습니다.
  • 프라이빗 서버의 인터넷 아웃바운드는 NAT Gateway 또는 Network Firewall을 통해 통제합니다.
  • S3, DynamoDB, ECR, Secrets Manager, Systems Manager 접근은 가능하면 VPC Endpoint를 사용합니다.
  • VPC Flow Logs로 네트워크 흐름을 기록합니다.
  • Reachability Analyzer와 Network Access Analyzer로 의도하지 않은 경로를 점검합니다.

이 구조의 핵심은 모든 리소스를 강하게 막는 것이 아니라, 필요한 흐름만 명확하게 열어두는 것입니다.

보안은 “전부 차단”이 아닙니다. 서비스가 정상적으로 동작하는 데 필요한 경로만 허용하고, 나머지는 열지 않는 것입니다.

14. 자주 발생하는 VPC 보안 실수

실무에서 자주 보는 VPC 보안 실수는 다음과 같습니다.

1. SSH와 RDP를 0.0.0.0/0으로 열어둔다

가장 흔하고 위험한 설정입니다.

운영 환경에서는 AWS Systems Manager Session Manager를 사용하거나, 제한된 VPN 또는 사내 IP에서만 접근하도록 구성하는 것이 좋습니다.

2. RDS를 퍼블릭으로 만든다

RDS는 대부분 인터넷에 직접 노출될 필요가 없습니다.

애플리케이션 서버에서만 접근하게 구성해야 합니다.

3. 모든 아웃바운드를 무조건 허용한다

기본 보안 그룹 설정 때문에 모든 아웃바운드가 허용된 상태로 운영되는 경우가 많습니다.

하지만 중요 시스템에서는 어디로 나갈 수 있는지도 통제해야 합니다.

4. VPC Flow Logs를 켜지 않는다

사고가 발생한 후에 로그가 없으면 분석이 매우 어렵습니다.

비용을 고려하더라도 중요 구간에는 반드시 로그를 남기는 것이 좋습니다.

5. VPC Endpoint를 사용하지 않아도 된다고 생각한다

S3, DynamoDB, ECR, Secrets Manager 같은 서비스 접근을 인터넷 또는 NAT Gateway에 의존하면 불필요한 외부 경로와 비용이 생길 수 있습니다.

6. 보안 그룹 이름만 보고 안전하다고 판단한다

private-sg, db-sg, secure-sg 같은 이름이 붙어 있어도 실제 규칙이 열려 있으면 위험합니다.

이름이 아니라 실제 인바운드, 아웃바운드 규칙을 봐야 합니다.

15. VPC 보안 점검 체크리스트

운영 환경에서 VPC를 점검할 때는 다음 항목을 확인해보면 좋습니다.

[ ] 퍼블릭 서브넷과 프라이빗 서브넷이 명확히 분리되어 있는가?
[ ] 데이터베이스가 퍼블릭 서브넷에 있지 않은가?
[ ] 라우트 테이블에 불필요한 0.0.0.0/0 경로가 없는가?
[ ] SSH, RDP가 전체 인터넷에 열려 있지 않은가?
[ ] 보안 그룹이 다른 보안 그룹을 참조하도록 설계되어 있는가?
[ ] Network ACL이 의도치 않게 너무 넓게 열려 있거나 너무 강하게 막혀 있지 않은가?
[ ] 프라이빗 리소스의 AWS 서비스 접근에 VPC Endpoint를 사용하고 있는가?
[ ] S3 버킷 정책에서 특정 VPC Endpoint 조건을 사용할 수 있는가?
[ ] VPC Flow Logs가 활성화되어 있는가?
[ ] Flow Logs가 S3 또는 CloudWatch Logs로 적절히 저장되고 있는가?
[ ] Network Firewall 또는 egress filtering이 필요한 환경인가?
[ ] Reachability Analyzer로 주요 경로를 검증했는가?
[ ] Network Access Analyzer로 의도하지 않은 인터넷 노출 경로를 점검했는가?
[ ] Transit Gateway, VPC Peering, VPN 연결로 인해 내부망이 과도하게 연결되어 있지 않은가?
[ ] 보안 그룹과 라우트 테이블 변경 이력이 관리되고 있는가?

이 체크리스트를 보면 알 수 있듯이 VPC 보안은 단일 기능 하나로 완성되지 않습니다.

여러 기능을 조합해 계층적으로 구성해야 합니다.

16. VPC 보안을 한 장으로 정리하면

VPC 보안 기능을 역할별로 정리하면 다음과 같습니다.

 

영역 주요 기능 보안 목적
네트워크 분리 VPC, Subnet 퍼블릭/프라이빗 영역 분리
경로 통제 Route Table 트래픽 이동 경로 제어
리소스 방화벽 Security Group 인스턴스, DB, ALB 단위 접근 제어
서브넷 방화벽 Network ACL 서브넷 단위 허용/차단
인터넷 연결 Internet Gateway, NAT Gateway 외부 연결 구조 분리
사설 AWS 서비스 연결 VPC Endpoint, PrivateLink 인터넷을 거치지 않는 AWS 서비스 접근
고급 방화벽 AWS Network Firewall 아웃바운드 통제, IDS/IPS, 도메인 필터링
흐름 로그 VPC Flow Logs 네트워크 통신 기록
패킷 분석 Traffic Mirroring 패킷 수준 보안 분석
경로 검증 Reachability Analyzer 특정 경로 도달 가능 여부 검증
노출 분석 Network Access Analyzer 의도하지 않은 접근 경로 탐지
DNS 보안 Route 53 Resolver Query Logs, DNS Firewall 도메인 기반 통신 기록 및 차단

마무리: VPC 보안은 “구조 설계”다

AWS VPC 보안은 단순히 방화벽 규칙을 작성하는 작업이 아닙니다.

네트워크 구조를 설계하는 작업입니다.

퍼블릭과 프라이빗을 나누고, 라우팅을 통제하고, 보안 그룹으로 리소스 간 통신을 제한하고, Network ACL로 서브넷 단위의 보조 방어선을 만들고, VPC Endpoint로 인터넷 경로를 줄이고, Network Firewall로 고급 트래픽 통제를 수행하고, Flow Logs와 Traffic Mirroring으로 가시성을 확보하고, Reachability Analyzer와 Network Access Analyzer로 의도하지 않은 경로를 검증해야 합니다.

좋은 VPC 보안 설계는 복잡해 보이지만 원칙은 단순합니다.

  • 외부에 노출할 것은 최소화한다.
  • 내부 통신도 필요한 대상끼리만 허용한다.
  • 인터넷으로 나가는 경로도 통제한다.
  • 모든 중요한 트래픽 흐름은 기록한다.
  • 설정이 의도한 대로 동작하는지 주기적으로 검증한다.

클라우드에서는 클릭 몇 번으로 네트워크가 열립니다.

그래서 보안 사고도 클릭 몇 번으로 시작될 수 있습니다.

반대로 말하면, VPC 보안 기능들을 제대로 이해하고 조합하면 많은 사고를 사전에 막을 수 있습니다.

AWS 보안의 첫 번째 방어선은 IAM만이 아닙니다.

안전하게 설계된 VPC도 매우 강력한 첫 번째 방어선입니다.

참고자료

반응형
저작자표시 비영리 변경금지 (새창열림)

'클라우드' 카테고리의 다른 글

AWS 태그 설계 가이드: 비용, 보안, 운영을 연결하는 가장 기본적인 거버넌스  (1) 2026.06.10
EC2 Image Builder 이해하기: 골든 AMI를 자동으로 만들고 관리하는 AWS 서비스  (1) 2026.06.09
S3 Intelligent-Tiering은 왜 많이 선택될까?  (0) 2026.06.09
📊 "예측"하지 말고 "관측"하라 — 클라우드 비용 관리는 예산이 아니라 신호처리다 FinOps  (0) 2026.05.09
💸 개발자는 만들고 떠나지만, 청구서는 부서장에게 간다 — 실무에서 리소스 삭제가 예산 관리의 핵심인 이유  (0) 2026.05.09

관련글

티스토리툴바