기업 조직/시스템에 Amazon VPC를 도입하기 위한 【지침】 고려 사항

📅 작성일: 2025/06/14, 수정일: 2025/06/14 ⏱️ 예상 읽기 시간 약 21분 (8,507자)

Amazon VPC는 AWS 클라우드 내에 가상 프라이빗 클라우드를 구축하기 위한 서비스입니다.
VPC를 사용하면 AWS 클라우드 내에서 자체 네트워크를 구성할 수 있습니다.
이 문서에서는 Amazon VPC에 대한 개요를 설명하고 기업 조직/시스템에 대한 도입을 고려할 때 확인해야 할 주요 사항을 소개합니다.

Amazon VPC란 무엇입니까?
VPC 사용 시 주요 고려 사항
1. VPC 내부에서 어떤 리소스를 실행해야 합니까?
VPC 설계 모범 사례

Amazon VPC란 무엇입니까?

Amazon VPC(Virtual Private Cloud)는 AWS 내에서 격리된 프라이빗 네트워크를 생성할 수 있는 서비스입니다.VPC를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 안전하게 실행할 수 있습니다.VPC의 주요 구성 요소에는 서브넷, 라우팅 테이블, 인터넷 게이트웨이 및 NAT 게이트웨이가 포함됩니다.

관련 자료
Amazon VPC란 무엇입니까?- Amazon Virtual Private Cloud

VPC 사용 시 주요 고려 사항

VPC 내부에서 어떤 리소스를 실행해야 합니까?

AWS에 따르면 프라이빗 IP 주소가 있는 VPC 내부에서 시작해야 하는 리소스에는 EC2 인스턴스, RDS 인스턴스 및 ELB(Elastic Load Balancer)가 포함됩니다.
S3 버킷 및 DynamoDB 테이블과 같은 일부 서버리스 리소스는 VPC 내에서 시작할 수 없습니다.그러나 인터넷 게이트웨이나 VPC 엔드포인트를 사용하여 VPC 내에서 이러한 리소스에 계속 액세스할 수 있습니다.
Lambda 함수 및 Glue 작업과 같은 특정 리소스는 VPC 내부 또는 외부에서 시작할 수 있습니다.이러한 리소스를 시작할 위치는 보안 및 애플리케이션 요구 사항에 따라 결정되어야 합니다.
아래 표에는 AWS 서비스, 해당 리소스 유형 및 VPC 배포 지원 여부가 나열되어 있습니다.

AWS 서비스 이름	AWS 리소스 유형 이름	VPC 지원
AWS IAM	사용자	×
〃	그룹	×
〃	역할	×
〃	정책	×
AWS CloudTrail	자취	×
AWS 구성	기록계	×
〃	애그리게이터	×
〃	규칙	×
Amazon GuardDuty	탐지기	×
아마존 루트 53	존	×
〃	기록	×
〃	확인자 끝점	◯
탄력적 로드 밸런싱	로드 밸런서	◯
〃	경청자	×
〃	대상 그룹	×
아마존 EC2	사례	◯
아마존 자동 스케일링	Auto Scaling 그룹	×
아마존 ECS	무리	◯ *작업 정의에서 설정
AWS 람다	기능	◯ (선택 가능)
AWS 글루	직업	◯ (선택 가능)
AWS 디렉터리 서비스	단순 디렉토리	◯
〃	마이크로소프트 AD	◯
아마존 SQS	대기줄	×
아마존 SNS	주제	×
아마존 RDS	사례	◯ *서브넷 그룹에 설정
〃	무리	◯ *서브넷 그룹에 설정
아마존 다이나모드브	테이블	×
아마존 레드시프트	무리	◯
Amazon Redshift 서버리스	작업 그룹	◯
아마존 S3	S3 버킷	×
아마존 FSx	파일 시스템	◯
아마존 ECR	저장소	×
AWS 코드커밋	저장소	×
AWS 코드파이프라인	관로	×
AWS 코드빌드	프로젝트 빌드	◯ (선택 가능)
아마존 아테나	작업 그룹	×
아마존 클라우드워치	계기반	×
〃	로그 그룹	×
〃	측정항목 필터	×
〃	구독 필터	×
〃	경보	×
아마존 이벤트브리지	규칙	×
〃	일정	×
AWS 백업	둥근 천장	×
〃	계획	×
〃	선택	×
AWS 시스템 관리자	매개변수	×
〃	문서	×

<테이블 참고 사항>

“VPC 지원”은 리소스가 VPC 내에서 시작될 수 있는지 여부를 나타냅니다.
VPC(◯)를 지원하는 AWS 리소스를 사용하는 경우에는 VPC를 사용해야 합니다.
주요 결정 포인트는 VPC 내부에서 “◯(선택 가능)” VPC 지원을 통해 서버리스 리소스를 시작할지 여부입니다.이에 대해서는 아래에서 설명합니다.

보안을 위해 AWS Security Hub에서는 VPC([Lambda.3] 제어) 내에서 Lambda 함수를 실행할 것을 권장합니다.VPC에서 Lambda 함수를 실행하면 아래에 설명된 대로 보안 및 네트워크 제어가 향상될 수 있습니다.

VPC에 리소스를 배포하면 보안과 네트워크 제어가 향상됩니다.
또한 여러 가용 영역에 걸쳐 확장성과 고가용성을 제공합니다.
애플리케이션 요구 사항에 맞게 VPC 배포를 사용자 정의할 수 있습니다.

출처: Lambda Security Hub 제어 - AWS Security Hub

VPC 내부에서 Lambda 함수와 같은 서버리스 리소스를 실행하면 다음과 같은 이점이 있습니다.

보안 그룹 및 네트워크 ACL을 사용하여 Lambda 함수의 아웃바운드 트래픽 제어
VPC 엔드포인트를 사용하여 특정 AWS 계정 또는 리소스에 대한 액세스 제한
VPC 흐름 로그로 Lambda 네트워크 트래픽 모니터링
네트워크 방화벽을 사용하여 Lambda 트래픽 필터링

이러한 조치는 Lambda 기능이 손상된 경우 위험을 줄이는 데 도움이 됩니다.그러나 서버리스 리소스는 직접적인 파일 업로드나 로그인을 허용하지 않기 때문에 일반적으로 EC2 인스턴스보다 위험이 낮습니다.

다음은 VPC 내에서 서버리스 리소스를 시작할지 여부를 결정하는 데 도움이 되는 순서도입니다.

VPC 설계 모범 사례

멤버 계정에서 VPC와 서브넷을 어떻게 구성해야 합니까?

VPC 서브넷의 구조는 라우팅 및 보안 요구 사항을 기반으로 해야 합니다.일반적인 서브넷 유형은 다음과 같습니다.

서브넷 유형	요구 사항	설명
공공의	회사 정책	인터넷 액세스가 필요한 리소스(예: ALB, NAT 게이트웨이)의 경우.
사적인	-	인터넷에서 직접 액세스할 수 없는 리소스(예: EC2 인스턴스)의 경우.NAT GW를 통한 인터넷 액세스.
안전한	회사 정책	엄격한 보안 요구 사항이 있는 리소스(예: 데이터베이스)의 경우.인터넷에 접속할 수 없습니다.
운송	회사 정책	다른 VPC 또는 온프레미스 네트워크에 연결하기 위한 Transit Gateway 연결이 있는 서브넷의 경우.
방화벽	회사 정책	네트워크 방화벽과 같은 프록시의 경우.
(고정 IP)	시스템 요구사항	관리를 위해 고정 IP 주소가 필요한 리소스의 경우.

조직의 정책 및 시스템 요구 사항에 따라 서브넷 유형을 선택하세요.

퍼블릭 서브넷: 인터넷 연결 리소스를 호스팅할 AWS 계정을 결정합니다.정책이 이를 외부 계정에만 유지하는 것이라면 멤버 계정에 퍼블릭 서브넷을 생성하지 마십시오.
보안 서브넷: 엄격한 보안이 필요한 경우 데이터베이스 또는 민감한 리소스에 사용합니다.
방화벽 서브넷: 트래픽을 모니터링하거나 제어해야 하는 경우 네트워크 방화벽과 같은 프록시에 사용합니다.
전송 서브넷: Transit Gateway를 통해 다른 VPC 또는 온프레미스에 연결할 때 사용합니다.정책이 VPC 연결을 중앙에서 관리하는 것인지 확인하세요.
(고정 IP) 서브넷: 관리를 위해 고정 IP가 필요한 리소스에 사용됩니다.

멤버 계정 VPC에 대한 CIDR 블록을 어떻게 선택합니까?

VPC의 CIDR 블록은 해당 IP 주소 범위를 정의합니다.온프레미스 또는 외부 시스템에 연결할 때 CIDR 블록을 신중하게 선택하여 충돌을 피하십시오.이전에 스프레드시트에서 IP 범위를 관리했다면 더 나은 관리를 위해 AWS IPAM(IP 주소 관리자)을 사용하는 것이 좋습니다.
나중에 VPC를 추가하거나 확장할 계획이라면 더 큰 CIDR 블록을 미리 예약하세요.IP 범위가 부족하면 네트워크가 격리된 상태로 유지되도록 시스템을 설계해야 할 수 있습니다(예: VPC-VPC 또는 VPC-온프레미스가 연결되지 않음).

DNS 이름 확인은 어떻게 처리됩니까?

VPC의 AWS 리소스에 대한 이름 확인은 소스와 대상에 따라 다릅니다.다음 시나리오를 고려하십시오.

VPC 내부 리소스
온프레미스 리소스
인터넷 리소스

두 가지 핵심 사항:

VPC의 리소스는 퍼블릭 DNS 이름을 가질 수 있습니다.
외부 DNS 서버와 통합하려면 Route 53 해석기 엔드포인트를 사용하십시오.

1. VPC 리소스의 퍼블릭 DNS 이름

VPC의 리소스는 퍼블릭 DNS 이름을 가질 수 있습니다.인터넷에 액세스할 수 있는 한 이름 확인은 온프레미스 또는 인터넷에서 작동합니다.사용자 지정 DNS에 Route 53 프라이빗 호스팅 영역을 사용하는 경우 해당 이름은 인터넷에서 확인할 수 없습니다.퍼블릭 DNS를 활성화하려면 VPC 설정에서 “DNS 호스트 이름 활성화” 및 “DNS 지원 활성화”를 설정하십시오.

2. 확인자 엔드포인트를 사용하여 외부 DNS 서버와 통합

VPC 외부의 DNS 서버에 연결하려면 Route 53 해석기 엔드포인트를 사용하십시오.이를 통해 VPC 리소스는 외부 서버에 DNS 쿼리를 보낼 수 있습니다.두 가지 유형이 있습니다:

인바운드 엔드포인트: 온프레미스 DNS 서버로부터 DNS 쿼리를 수락합니다(온프레미스에서 VPC 리소스 이름을 확인하기 위해).
아웃바운드 엔드포인트: VPC 리소스에서 온프레미스 DNS 서버로 DNS 쿼리를 보냅니다(VPC에서 온프레미스 리소스 이름을 확인하기 위해).
관련 자료
VPC로 인바운드 DNS 쿼리 전달 - Amazon Route 53
아웃바운드 DNS 쿼리를 네트워크로 전달 - Amazon Route 53

Active Directory를 사용하는 경우 아웃바운드 엔드포인트를 사용하여 AD DNS 서버에 DNS 쿼리를 보낼 수도 있습니다.

확인자 엔드포인트는 엔드포인트별로 요금이 청구됩니다.

ENI당 $0.125/시간

출처: 가격 - Amazon Route 53 |AWS

비싸지는 않지만 VPC 수가 증가하면 비용이 추가될 수 있습니다.여러 계정을 사용하는 경우 확인자 엔드포인트 통합을 고려하세요.

관련자료
다중 계정, 다중 지역 환경을 위한 통합 Amazon Route 53 Resolver 엔드포인트 아키텍처 |DevelopersIO
참고: 위에 링크된 관련 자료는 일본어로 작성되었습니다.

요약: 이름 확인 옵션

아래 표에는 원본 및 대상별 이름 확인 옵션이 요약되어 있습니다.

소스/대상	VPC	온프레미스 리소스	인터넷 리소스
VPC	옵션 1) Amazon Route 53 Resolver 권장 옵션 2) [AD를 사용하는 경우] AWS의 Active Directory DNS 서버	옵션 1) Amazon Route 53 Resolver 1 권장* 옵션 2) 온프레미스 DNS 옵션 3) [AD를 사용하는 경우] AD DNS	옵션 1) Amazon Route 53 Resolver 권장 옵션 2) 온프레미스 DNS 옵션 3) [AD를 사용하는 경우] AD DNS
온프레미스 리소스	옵션 1) 온프레미스 DNS 2 권장* 옵션 2) Amazon Route 53 Resolver 옵션 3) 퍼블릭 DNS 옵션 4) AD	옵션 1) 온프레미스 DNS 2 권장* 옵션 2) Amazon Route 53 Resolver 옵션 3) [AD를 사용하는 경우] AD DNS	옵션 1) 온프레미스 DNS 권장 옵션 2) 퍼블릭 DNS 옵션 3) [AD를 사용하는 경우] AD DNS
인터넷 리소스	옵션 1) 퍼블릭 DNS 옵션 2) Amazon Route 53 퍼블릭 호스팅 영역	옵션 1) 퍼블릭 DNS 옵션 2) Amazon Route 53 퍼블릭 호스팅 영역	-

1: 아웃바운드 엔드포인트 사용
2: 인바운드 엔드포인트 사용

다양한 옵션이 있지만 고가용성을 위해서는 각 환경 전용 DNS 서버를 사용하세요.VPC 리소스의 경우 Amazon Route 53 Resolver를 사용하십시오.온프레미스 리소스의 경우 온프레미스 DNS 서버를 사용하세요.최소한의 통합을 원하거나 비용을 절감하려면 다른 옵션을 고려하십시오.

VPC 흐름 로그를 어디로 보내야 합니까?

VPC 흐름 로그는 VPC 내의 네트워크 트래픽 정보를 기록합니다.VPC 흐름 로그를 다음 주소로 보낼 수 있습니다.

CloudWatch 로그
S3 버킷
Kinesis Data Firehose

로그 분석 및 모니터링 요구 사항에 따라 대상을 선택하세요.VPC 흐름 로그는 장기 감사에 자주 사용되므로 S3가 일반적으로 선택됩니다.외부 로그 플랫폼이 있는 경우 Kinesis Data Firehose를 사용하여 로그를 전송합니다.실시간 모니터링이나 분석을 위해서는 CloudWatch Logs를 권장합니다.

로그는 VPC를 소유한 계정이나 중앙 로그 집계 계정(로그 아카이브 계정)에 저장할 수 있습니다.조직에 전용 로그 계정이 있는 경우 해당 계정으로 로그를 보내세요.

VPC 엔드포인트를 어떻게 사용해야 합니까?

VPC 엔드포인트를 사용하면 퍼블릭 인터넷을 사용하지 않고도 VPC의 리소스를 AWS 서비스에 직접 연결할 수 있습니다.VPC 엔드포인트 정책을 사용하면 액세스 가능한 AWS 서비스와 리소스를 제어하여 보안을 강화하고 데이터 유출 위험을 줄일 수 있습니다.

퍼블릭 인터넷을 피하기 위해 VPC 엔드포인트를 사용하는 경우도 있지만 항상 필요한 것은 아닙니다.인터넷 게이트웨이를 통한 트래픽은 실제로 AWS의 프라이빗 네트워크에 머물며 퍼블릭 인터넷을 통과하지 않습니다. 따라서 보안을 위해 VPC 엔드포인트가 항상 필요한 것은 아닙니다.

두 인스턴스가 퍼블릭 IP 주소를 사용하여 통신하거나 인스턴스가 퍼블릭 AWS 서비스 엔드포인트와 통신하는 경우 트래픽이 인터넷을 통해 이동합니까?
아니요. 퍼블릭 IP 주소를 사용하는 경우 AWS 호스팅 인스턴스와 서비스 간의 모든 통신은 AWS 프라이빗 네트워크를 사용합니다.
AWS 네트워크에서 시작되어 AWS 네트워크로 향하는 패킷은 AWS 중국 지역을 오가는 트래픽을 제외하고 AWS 글로벌 네트워크에 유지됩니다.

AWS 글로벌 네트워크를 통해 흐르는 모든 데이터는 보안 시설을 떠나기 전에 물리적 계층에서 자동으로 암호화됩니다.VPC 간 지역 피어링 및 TLS 연결과 같은 추가 암호화 계층도 있습니다.

출처: FAQ - Amazon VPC |AWS

VPC 엔드포인트를 사용하는 두 가지 주요 이유는 다음과 같습니다.

VPC 외부(예: 온프레미스) 리소스가 공용 인터넷을 사용하지 않고 AWS 서비스에 직접 연결할 수 있도록 허용하려면
VPC 엔드포인트 정책을 사용하여 액세스할 수 있는 AWS 서비스 및 리소스를 제한하여 보안을 향상하려면

예를 들어 Site-to-Site VPN을 통해 온프레미스에서 AWS 서비스에 액세스하는 경우 VPC 엔드포인트를 사용하면 공용 인터넷을 사용하지 않고도 직접 연결할 수 있습니다.AWS Management Console 또는 S3 액세스와 같은 운영 요구 사항의 경우 VPC 엔드포인트를 사용하면 보안이 향상될 수 있습니다.그러나 개발 중에 많은 엔드포인트를 사용하면 비용이 증가할 수 있습니다.

VPC 엔드포인트 정책을 사용하면 특정 AWS 서비스 또는 리소스에 대한 액세스를 제한할 수 있습니다.예를 들어 다음 정책은 조직 내의 리소스에 대한 액세스만 허용하여 데이터가 외부 계정으로 전송되는 것을 방지합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRequestsByOrgsIdentitiesToOrgsResources",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "my-org-id",
                    "aws:ResourceOrgID": "my-org-id"
                }
            }
        },
        {
            "Sid": "AllowRequestsByAWSServicePrincipals",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:PrincipalIsAWSService": "true"
                }
            }
        }
    ]
}

모든 AWS 서비스에 대해 VPC 엔드포인트를 설정하면 비용과 운영 오버헤드가 증가할 수 있습니다.최소한 아래와 같이 데이터 유출 위험이 높은 데이터베이스 및 스토리지 서비스에 대해 VPC 엔드포인트를 구성하십시오.

AWS 서비스 이름	데이터 유출/가져오기 위험이 높은 IAM 작업의 예
아마존 S3(com.amazonaws.region.s3)	s3:PutObject, s3:GetObject
아마존 다이나모DB(com.amazonaws.region.dynamodb)	dynamodb:PutItem, dynamodb:GetItem
아마존 SQS(com.amazonaws.region.sqs)	sqs:메시지 보내기
아마존 SNS(com.amazonaws.region.sns)	sns:게시
Amazon RDS 데이터 API(com.amazonaws.region.rds-data)	rds-data:ExecuteStatement, rds-data:BatchExecuteStatement
Amazon Redshift 데이터 API(com.amazonaws.region.redshift-data)	redshift-데이터:ExecuteStatement, redshift-데이터:BatchExecuteStatement
Amazon Kinesis 데이터 스트림(com.amazonaws.region.kinesis)	키네시스:PutRecord, 키네시스:GetRecords
Amazon Kinesis Data Firehose(com.amazonaws.region.firehose)	Firehose:PutRecord, Firehose:PutRecordBatch

VPC 리소스는 누가 관리하나요?

VPC 리소스에 대한 책임은 조직의 운영 규칙 및 보안 정책에 따라 정의되어야 합니다.일반적인 역할은 다음과 같습니다.

네트워크 관리자 : VPC, 보안 그룹, 네트워크 ACL을 설계하고 구성합니다.때로는 AWS 계정과 보안 서비스를 관리하는 플랫폼 관리자가 이를 처리하는 경우도 있습니다.
보안 관리자 : VPC 보안 정책을 설정하고, VPC 흐름 로그를 모니터링하며, 보안 사고를 처리합니다.
운영 직원 : VPC 리소스를 운영, 모니터링 및 문제 해결합니다.
개발자 : VPC 리소스를 사용하는 애플리케이션을 개발하고 배포합니다.

이러한 역할은 조직의 규모와 구조에 따라 달라질 수 있습니다.때로는 개발자가 모든 것을 처리하기도 합니다.다른 경우에는 네트워크 관리자가 VPC를 설계하고 구축하는 반면 개발자는 애플리케이션에 집중합니다.다음은 네트워크 관리자가 VPC를 설계하고 구축할 때 역할 할당의 예입니다.

VPC 리소스 유형	설계	짓다	작업	모니터링	보안
VPC	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
서브넷	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
경로 테이블	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
인터넷 게이트웨이	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
NAT 게이트웨이	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
VPC 엔드포인트	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
보안 그룹	개발자	개발자	운영 직원	운영 직원	보안 관리자
네트워크 ACL	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
VPC 흐름 로그	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
VPC 해석기	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
VPC 피어링	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자
환승 게이트웨이	네트워크 관리자	네트워크 관리자	운영 직원	운영 직원	보안 관리자

보안 그룹은 시스템별 요구 사항을 충족하기 위해 개발자가 설계하고 구축하는 경우가 많습니다.일부 조직에서는 네트워크 관리자가 보안 그룹을 처리하지만 이로 인해 개발 속도가 느려질 수 있습니다.개발을 빠르게 진행하려면 일반적으로 개발자가 보안 그룹을 직접 설계하고 구축하는 것이 가장 좋습니다.