VPC 피어링으로 VPC 간 프라이빗 통신 완벽 가이드

AWS에서 서로 다른 VPC 간에 인터넷을 거치지 않고 프라이빗하게 통신하는 VPC 피어링의 개념부터 실전 구성까지 초급자도 이해할 수 있도록 설명합니다. 동일 리전과 교차 리전 피어링의 차이점, 라우팅 설정, CIDR 중복 문제 해결까지 실무에서 꼭 알아야 할 내용을 다룹니다.

1. VPC 피어링의 개념과 사용 사례

김개발 씨는 스타트업에서 백엔드 개발을 담당하고 있습니다. 어느 날 팀장님이 다가와 말했습니다.

"우리 개발 환경 VPC랑 운영 환경 VPC를 연결해야 하는데, 인터넷 안 거치고 안전하게 연결할 방법 없을까요?" 김개발 씨는 잠시 고민에 빠졌습니다.

VPC 피어링은 두 개의 VPC를 프라이빗 네트워크로 직접 연결하는 기술입니다. 마치 두 집 사이에 비밀 터널을 뚫어 외부에 노출되지 않고 왕래할 수 있게 만드는 것과 같습니다.

이를 통해 인터넷 게이트웨이나 VPN 없이도 VPC 간 안전한 통신이 가능해집니다.

다음 코드를 살펴봅시다.

import boto3

# VPC 피어링 연결 요청 생성
ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# 요청자 VPC에서 피어링 연결 생성
response = ec2.create_vpc_peering_connection(
    VpcId='vpc-11111111',           # 요청자 VPC ID
    PeerVpcId='vpc-22222222',       # 수락자 VPC ID
    PeerOwnerId='123456789012',     # 상대방 AWS 계정 ID (같은 계정이면 생략 가능)
    PeerRegion='ap-northeast-2'     # 피어링 대상 리전
)

peering_id = response['VpcPeeringConnection']['VpcPeeringConnectionId']
print(f"피어링 연결 ID: {peering_id}")

김개발 씨는 입사한 지 6개월 된 주니어 클라우드 엔지니어입니다. 회사는 개발 환경과 운영 환경을 분리하기 위해 각각 별도의 VPC를 사용하고 있었습니다.

그런데 개발 환경에서 운영 환경의 데이터베이스에 접근해야 하는 상황이 생겼습니다. "인터넷으로 연결하면 안 되나요?" 김개발 씨가 물었습니다.

박시니어 씨가 고개를 저었습니다. "그건 보안상 위험해요.

민감한 데이터가 공용 인터넷을 타고 다니면 안 되죠." 그렇다면 VPC 피어링이란 정확히 무엇일까요? 쉽게 비유하자면, VPC 피어링은 마치 두 개의 아파트 단지 사이에 전용 연결 통로를 만드는 것과 같습니다.

평소에는 각 단지가 독립적으로 운영되지만, 이 통로를 통해 주민들이 외부 도로를 거치지 않고 안전하게 오갈 수 있습니다. VPC 피어링도 마찬가지로 두 VPC 사이에 프라이빗 연결을 만들어 AWS 내부 네트워크만 사용합니다.

VPC 피어링이 없던 시절에는 어떻게 했을까요? 개발자들은 VPC 간 통신을 위해 인터넷 게이트웨이를 통하거나, VPN을 구축해야 했습니다.

인터넷을 통한 통신은 보안 위험이 있고, VPN은 설정이 복잡하며 추가 비용이 발생했습니다. 더 큰 문제는 지연 시간이었습니다.

외부 네트워크를 경유하면 응답 속도가 느려질 수밖에 없었습니다. 바로 이런 문제를 해결하기 위해 VPC 피어링이 등장했습니다.

VPC 피어링을 사용하면 AWS 백본 네트워크를 통해 직접 통신합니다. 인터넷을 거치지 않으므로 보안이 강화되고, 지연 시간도 최소화됩니다.

무엇보다 설정이 간단하고 추가 하드웨어나 복잡한 VPN 구성이 필요 없습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

먼저 boto3 클라이언트를 생성하여 EC2 서비스에 연결합니다. create_vpc_peering_connection 메서드는 피어링 연결을 요청하는 핵심 함수입니다.

VpcId는 요청을 보내는 쪽의 VPC, PeerVpcId는 연결하려는 상대방 VPC를 지정합니다. 다른 AWS 계정의 VPC와 연결하려면 PeerOwnerId에 해당 계정 ID를 명시해야 합니다.

실제 현업에서는 어떻게 활용할까요? 가장 흔한 사례는 개발/스테이징/운영 환경 분리입니다.

각 환경을 별도 VPC로 운영하면서 필요할 때만 피어링으로 연결합니다. 또 다른 사례는 마이크로서비스 아키텍처입니다.

서비스별로 VPC를 분리하고 피어링으로 연결하면 보안과 관리 효율성을 모두 확보할 수 있습니다. 대기업에서는 부서별 VPC를 피어링으로 연결하는 경우도 많습니다.

하지만 주의할 점도 있습니다. VPC 피어링은 전이적 연결을 지원하지 않습니다.

A-B 피어링, B-C 피어링이 있다고 해서 A에서 C로 직접 통신할 수 없습니다. A와 C도 별도로 피어링해야 합니다.

이 점을 모르고 설계하면 예상과 다르게 동작해서 당황할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다. "아, 그래서 피어링을 쓰는 거군요!

인터넷 안 거치고 안전하게 연결할 수 있으니까요." VPC 피어링을 이해하면 멀티 VPC 아키텍처를 설계할 때 훨씬 유연하게 대응할 수 있습니다. 여러분도 오늘 배운 내용을 실제 AWS 환경에서 적용해 보세요.

실전 팁

💡 - VPC 피어링은 양방향이지만, 연결 요청과 수락은 별도로 진행해야 합니다

피어링 연결 후 반드시 양쪽 VPC의 라우팅 테이블을 업데이트해야 통신이 가능합니다
같은 계정 내 VPC끼리는 PeerOwnerId를 생략할 수 있습니다

2. 동일 리전 vs 교차 리전 피어링

김개발 씨가 VPC 피어링 개념을 익힌 후, 새로운 과제가 주어졌습니다. "서울 리전이랑 도쿄 리전 VPC도 연결해야 해요." 같은 리전끼리만 연결되는 줄 알았던 김개발 씨는 잠시 당황했습니다.

과연 다른 리전끼리도 피어링이 가능할까요?

VPC 피어링은 동일 리전 피어링과 교차 리전 피어링 두 가지로 나뉩니다. 동일 리전 피어링은 같은 지역 내 VPC를 연결하고, 교차 리전 피어링은 서로 다른 지역의 VPC를 연결합니다.

두 방식 모두 AWS 프라이빗 네트워크를 사용하지만, 특성과 제약사항에 차이가 있습니다.

다음 코드를 살펴봅시다.

import boto3

# 교차 리전 피어링: 서울(요청자) -> 도쿄(수락자)
ec2_seoul = boto3.client('ec2', region_name='ap-northeast-2')

# 교차 리전 피어링 요청 생성
response = ec2_seoul.create_vpc_peering_connection(
    VpcId='vpc-seoul-11111',        # 서울 리전 VPC
    PeerVpcId='vpc-tokyo-22222',    # 도쿄 리전 VPC
    PeerRegion='ap-northeast-1'      # 반드시 피어 리전 명시 필요
)

# 도쿄 리전에서 피어링 수락
ec2_tokyo = boto3.client('ec2', region_name='ap-northeast-1')
ec2_tokyo.accept_vpc_peering_connection(
    VpcPeeringConnectionId=response['VpcPeeringConnection']['VpcPeeringConnectionId']
)

박시니어 씨가 김개발 씨에게 설명을 시작했습니다. "리전이 달라도 피어링이 가능해요.

하지만 몇 가지 다른 점이 있죠." 동일 리전 피어링은 말 그대로 같은 리전 안에서 VPC를 연결하는 것입니다. 서울 리전의 VPC-A와 VPC-B를 연결한다고 생각하면 됩니다.

마치 같은 도시 안에서 두 건물을 전용 통로로 연결하는 것과 같습니다. 거리가 가깝기 때문에 지연 시간이 매우 짧고, 데이터 전송 비용도 저렴합니다.

반면 교차 리전 피어링은 서로 다른 리전의 VPC를 연결합니다. 서울 리전과 도쿄 리전, 또는 서울과 버지니아 리전을 연결할 수 있습니다.

마치 서울에 있는 건물과 도쿄에 있는 건물을 해저 터널로 연결하는 것과 비슷합니다. 당연히 거리가 멀기 때문에 지연 시간이 더 길고, 데이터가 리전을 넘어가므로 전송 비용도 추가됩니다.

그렇다면 교차 리전 피어링은 왜 필요할까요? 글로벌 서비스를 운영한다고 가정해봅시다.

한국 사용자를 위한 서울 리전과 일본 사용자를 위한 도쿄 리전에 각각 서비스를 배포했습니다. 두 리전의 백엔드 시스템이 데이터를 동기화하거나 공유해야 할 때 교차 리전 피어링이 유용합니다.

인터넷을 통해 연결하면 보안 위험과 불안정한 네트워크 품질 문제가 있지만, 교차 리전 피어링은 AWS 글로벌 백본 네트워크를 사용하므로 안정적이고 보안이 강화됩니다. 위의 코드에서 중요한 차이점을 살펴보겠습니다.

교차 리전 피어링에서는 PeerRegion 파라미터가 필수입니다. 동일 리전에서는 생략해도 되지만, 다른 리전 VPC와 연결할 때는 반드시 상대방 리전을 명시해야 합니다.

또한 피어링을 수락할 때는 상대방 리전의 클라이언트를 사용해야 합니다. 서울에서 요청을 보냈다면, 도쿄 리전 클라이언트로 수락해야 합니다.

비용 측면에서의 차이도 중요합니다. 동일 리전 피어링에서 데이터 전송 비용은 일반적인 VPC 내 통신과 비슷합니다.

하지만 교차 리전 피어링은 리전 간 데이터 전송 비용이 적용됩니다. 대용량 데이터를 자주 전송한다면 비용이 상당히 늘어날 수 있으니 미리 계산해보는 것이 좋습니다.

성능 차이는 어느 정도일까요? 동일 리전 피어링의 지연 시간은 보통 1ms 미만입니다.

같은 데이터센터 안에 있다고 생각하면 됩니다. 반면 교차 리전 피어링은 물리적 거리에 따라 다릅니다.

서울-도쿄는 약 30-50ms, 서울-버지니아는 150-200ms 정도의 지연이 발생할 수 있습니다. 김개발 씨가 고개를 끄덕였습니다.

"그러면 우리 경우에는 어떤 걸 써야 하나요?" 박시니어 씨가 답했습니다. "재해 복구용 도쿄 리전 연결은 교차 리전 피어링으로, 같은 서울 리전 내 개발-운영 환경 연결은 동일 리전 피어링으로 가면 되겠네요." 상황에 맞는 피어링 방식을 선택하면 비용과 성능 모두 최적화할 수 있습니다.

실전 팁

💡 - 교차 리전 피어링은 PeerRegion 파라미터가 필수이므로 잊지 마세요

대용량 데이터 전송이 예상되면 교차 리전 데이터 전송 비용을 미리 계산하세요
지연 시간에 민감한 서비스는 동일 리전 내에서 피어링을 구성하는 것이 좋습니다

3. 피어링 연결 생성 및 수락

이론을 충분히 배운 김개발 씨가 드디어 실제로 VPC 피어링을 구성해보려 합니다. "연결 생성하고 수락하면 끝인 거죠?" 박시니어 씨가 웃으며 말했습니다.

"맞아요, 근데 생각보다 헷갈리는 부분이 있어요. 한번 같이 해볼까요?"

VPC 피어링은 요청자와 수락자가 존재하는 양방향 핸드셰이크 과정입니다. 한쪽 VPC에서 연결을 요청하고, 상대방 VPC 소유자가 이를 수락해야만 피어링이 활성화됩니다.

같은 계정 내라도 명시적인 수락 과정이 필요합니다.

다음 코드를 살펴봅시다.

import boto3
import time

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# Step 1: 피어링 연결 요청 (요청자 VPC에서)
peering = ec2.create_vpc_peering_connection(
    VpcId='vpc-requester-111',
    PeerVpcId='vpc-accepter-222'
)
pcx_id = peering['VpcPeeringConnection']['VpcPeeringConnectionId']
print(f"피어링 요청 생성됨: {pcx_id}")

# Step 2: 피어링 연결 수락 (수락자 VPC에서)
# 다른 계정이라면 해당 계정 권한으로 실행
ec2.accept_vpc_peering_connection(
    VpcPeeringConnectionId=pcx_id
)
print(f"피어링 연결 수락됨: {pcx_id}")

# Step 3: 연결 상태 확인
response = ec2.describe_vpc_peering_connections(
    VpcPeeringConnectionIds=[pcx_id]
)
status = response['VpcPeeringConnections'][0]['Status']['Code']
print(f"현재 상태: {status}")  # 'active'면 성공

박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작했습니다. "VPC 피어링은 마치 친구 신청과 비슷해요.

한쪽에서 신청하고, 상대방이 수락해야 친구가 되잖아요." 피어링 연결의 첫 번째 단계는 연결 요청입니다. 요청자 VPC에서 상대방 VPC를 지정하여 피어링 연결을 생성합니다.

이 시점에서 피어링 상태는 pending-acceptance가 됩니다. 상대방이 아직 수락하지 않았다는 의미입니다.

두 번째 단계는 연결 수락입니다. 수락자 VPC 소유자가 피어링 연결 ID를 사용하여 연결을 수락합니다.

같은 AWS 계정 내 VPC끼리 연결하더라도 이 수락 과정은 생략할 수 없습니다. 자동으로 수락되지 않으니 주의하세요.

"잠깐요, 왜 자동 수락이 안 되는 거예요?" 김개발 씨가 의문을 제기했습니다. 보안상의 이유입니다.

만약 자동 수락이 된다면, 누군가 악의적으로 피어링 요청을 보내 네트워크에 침투할 수 있습니다. 명시적인 수락 과정이 있어야 의도하지 않은 연결을 방지할 수 있습니다.

특히 다른 AWS 계정과의 피어링에서 이 보안 메커니즘은 매우 중요합니다. 피어링 연결에는 여러 가지 상태가 있습니다.

initiating-request는 연결 요청이 시작되는 순간의 상태입니다. pending-acceptance는 요청이 생성되었고 상대방의 수락을 기다리는 상태입니다.

피어링 요청은 기본적으로 7일 동안 유효하며, 그 안에 수락하지 않으면 자동으로 만료됩니다. active는 양쪽 모두 연결을 수락하여 피어링이 활성화된 상태입니다.

다른 계정의 VPC와 피어링할 때는 추가 정보가 필요합니다. 상대방의 AWS 계정 ID와 VPC ID를 알아야 합니다.

교차 리전이라면 리전 정보도 필요합니다. 이 정보를 요청할 때 전달하면, 상대방 계정에서 해당 피어링 연결을 확인하고 수락할 수 있습니다.

실무에서 흔히 발생하는 실수를 알려드리겠습니다. 피어링 요청을 생성하고 수락까지 했는데 통신이 안 된다며 당황하는 경우가 많습니다.

이건 라우팅 테이블을 설정하지 않아서 그렇습니다. 피어링 연결을 활성화했다고 해서 바로 통신이 되는 것이 아닙니다.

다음 섹션에서 라우팅 테이블 설정을 자세히 다루겠습니다. 김개발 씨가 코드를 따라 치며 실습했습니다.

"오, 정말 active 상태가 됐어요!" 박시니어 씨가 미소 지었습니다. "좋아요, 이제 라우팅 테이블을 설정해야 진짜 통신이 됩니다."

실전 팁

💡 - 피어링 요청은 7일 내에 수락하지 않으면 자동 만료됩니다

같은 계정 내 VPC라도 수락 과정은 필수입니다
describe_vpc_peering_connections로 상태를 확인하며 진행하세요

4. 라우팅 테이블 양방향 설정

VPC 피어링 연결이 active 상태가 됐지만, 김개발 씨가 ping 테스트를 해보니 응답이 없습니다. "분명히 연결됐는데 왜 안 되는 거죠?" 박시니어 씨가 고개를 끄덕이며 말했습니다.

"피어링은 연결만으로 끝이 아니에요. 라우팅을 설정해줘야 해요."

VPC 피어링 연결이 활성화되어도 라우팅 테이블을 설정하지 않으면 트래픽이 전달되지 않습니다. 양쪽 VPC의 라우팅 테이블에 상대방 CIDR 블록을 목적지로, 피어링 연결을 대상으로 하는 라우트를 추가해야 합니다.

이것은 피어링 구성에서 가장 중요한 단계입니다.

다음 코드를 살펴봅시다.

import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# VPC-A (10.0.0.0/16) <-> VPC-B (10.1.0.0/16) 피어링
pcx_id = 'pcx-0123456789abcdef0'

# VPC-A의 라우팅 테이블에 VPC-B로 가는 경로 추가
ec2.create_route(
    RouteTableId='rtb-aaaaaa',        # VPC-A의 라우팅 테이블
    DestinationCidrBlock='10.1.0.0/16',  # VPC-B의 CIDR
    VpcPeeringConnectionId=pcx_id
)

# VPC-B의 라우팅 테이블에 VPC-A로 가는 경로 추가
ec2.create_route(
    RouteTableId='rtb-bbbbbb',        # VPC-B의 라우팅 테이블
    DestinationCidrBlock='10.0.0.0/16',  # VPC-A의 CIDR
    VpcPeeringConnectionId=pcx_id
)

print("양방향 라우팅 설정 완료")

박시니어 씨가 네트워크 다이어그램을 그리며 설명을 시작했습니다. "VPC 피어링을 도로에 비유하면, 지금은 도로만 깔린 상태예요.

이정표가 없어서 차들이 어디로 가야 할지 모르는 거죠." 라우팅 테이블은 바로 그 이정표 역할을 합니다. 특정 목적지로 가려면 어떤 경로를 통해야 하는지 알려주는 것입니다.

VPC 피어링에서는 상대방 VPC의 IP 대역으로 가려면 피어링 연결을 통하라고 명시해줘야 합니다. 핵심은 양방향 설정입니다.

VPC-A에서 VPC-B로 패킷을 보내려면 VPC-A의 라우팅 테이블에 설정이 필요합니다. 마찬가지로 VPC-B에서 VPC-A로 응답을 보내려면 VPC-B의 라우팅 테이블에도 설정이 필요합니다.

한쪽만 설정하면 요청은 가지만 응답이 돌아오지 못해 통신이 실패합니다. 라우팅 테이블 설정을 구체적으로 살펴보겠습니다.

VPC-A의 CIDR이 10.0.0.0/16이고 VPC-B의 CIDR이 10.1.0.0/16이라고 가정합시다. VPC-A의 라우팅 테이블에는 목적지 10.1.0.0/16으로 가는 트래픽을 피어링 연결(pcx-xxxx)으로 보내는 라우트를 추가합니다.

VPC-B의 라우팅 테이블에는 목적지 10.0.0.0/16으로 가는 트래픽을 같은 피어링 연결로 보내는 라우트를 추가합니다. 여기서 주의할 점이 있습니다.

VPC에는 여러 개의 서브넷이 있고, 각 서브넷은 서로 다른 라우팅 테이블을 사용할 수 있습니다. 피어링 통신이 필요한 모든 서브넷의 라우팅 테이블에 설정을 추가해야 합니다.

메인 라우팅 테이블만 수정하고 끝내면 커스텀 라우팅 테이블을 사용하는 서브넷에서는 피어링 통신이 안 됩니다. 실무에서는 특정 서브넷만 피어링을 사용하도록 구성하기도 합니다.

예를 들어 퍼블릭 서브넷은 인터넷 게이트웨이만 사용하고, 프라이빗 서브넷만 피어링을 통해 다른 VPC와 통신하도록 설정할 수 있습니다. 이렇게 하면 네트워크 세그먼테이션을 유지하면서 필요한 통신만 허용할 수 있습니다.

보안 그룹 설정도 잊지 마세요. 라우팅만 설정해서는 안 됩니다.

EC2 인스턴스나 RDS의 보안 그룹에서 상대방 VPC의 CIDR 블록에서 오는 트래픽을 허용해야 합니다. 피어링된 VPC의 보안 그룹 ID를 직접 참조할 수도 있습니다.

이 기능을 사용하면 IP 대역 대신 보안 그룹 단위로 세밀하게 접근 제어가 가능합니다. 김개발 씨가 라우팅을 설정한 후 다시 ping 테스트를 했습니다.

"드디어 응답이 와요!" 박시니어 씨가 칭찬했습니다. "잘했어요.

라우팅은 피어링에서 가장 중요한 부분이에요. 이걸 놓치면 아무리 연결해도 소용없죠."

실전 팁

💡 - 양쪽 VPC의 라우팅 테이블 모두에 설정해야 양방향 통신이 됩니다

서브넷별로 다른 라우팅 테이블을 사용한다면 모든 관련 테이블을 확인하세요
라우팅 설정 후 보안 그룹에서 상대방 CIDR 허용도 잊지 마세요

5. CIDR 중복 문제 해결

김개발 씨가 새로운 VPC 피어링을 시도하다가 에러를 만났습니다. "overlapping CIDR blocks"라는 메시지가 떴습니다.

"이게 뭐죠? 왜 연결이 안 되는 거예요?" 박시니어 씨가 한숨을 쉬며 말했습니다.

"가장 흔한 문제 중 하나예요. VPC 설계할 때 미리 생각했어야 하는 부분이죠."

CIDR 중복은 VPC 피어링의 가장 큰 제약사항 중 하나입니다. 두 VPC의 IP 대역이 겹치면 라우팅이 모호해져서 피어링이 불가능합니다.

이 문제를 예방하려면 VPC 설계 단계에서 IP 대역을 신중하게 계획해야 합니다.

다음 코드를 살펴봅시다.

# CIDR 중복 확인 스크립트
import boto3
import ipaddress

def check_cidr_overlap(cidr1, cidr2):
    """두 CIDR 블록이 겹치는지 확인"""
    network1 = ipaddress.ip_network(cidr1)
    network2 = ipaddress.ip_network(cidr2)
    return network1.overlaps(network2)

# 피어링하려는 VPC들의 CIDR 확인
ec2 = boto3.client('ec2', region_name='ap-northeast-2')

vpc_a = ec2.describe_vpcs(VpcIds=['vpc-111'])['Vpcs'][0]
vpc_b = ec2.describe_vpcs(VpcIds=['vpc-222'])['Vpcs'][0]

cidr_a = vpc_a['CidrBlock']
cidr_b = vpc_b['CidrBlock']

if check_cidr_overlap(cidr_a, cidr_b):
    print(f"경고: CIDR 중복! {cidr_a} <-> {cidr_b}")
    print("피어링이 불가능합니다. CIDR 재설계가 필요합니다.")
else:
    print(f"OK: CIDR 중복 없음. 피어링 가능합니다.")

박시니어 씨가 화이트보드에 두 개의 VPC를 그렸습니다. 둘 다 10.0.0.0/16이라고 적혀 있었습니다.

"문제가 보이나요?" 김개발 씨가 잠시 생각하다 대답했습니다. "두 VPC가 같은 IP 대역을 쓰고 있네요?" 정확합니다.

CIDR 중복이란 두 VPC의 IP 주소 범위가 전체 또는 일부 겹치는 상황을 말합니다. 왜 중복이 문제가 될까요?

예를 들어 VPC-A와 VPC-B 모두 10.0.0.0/16 대역을 사용한다고 합시다. VPC-A의 인스턴스(10.0.1.5)가 10.0.2.10으로 패킷을 보내려 합니다.

이 IP가 VPC-A 내부 인스턴스인지, 피어링된 VPC-B의 인스턴스인지 구분할 수 없습니다. 라우팅이 모호해지므로 AWS는 아예 이런 피어링을 허용하지 않습니다.

부분 중복도 마찬가지입니다. VPC-A가 10.0.0.0/16이고 VPC-B가 10.0.0.0/24라면 어떨까요?

/24는 /16의 부분 집합입니다. 10.0.0.0~10.0.0.255 범위가 겹칩니다.

이 경우에도 피어링이 불가능합니다. 그렇다면 어떻게 해결할까요?

가장 좋은 방법은 예방입니다. VPC를 생성하기 전에 전체 네트워크 아키텍처를 설계하고, 각 VPC에 겹치지 않는 CIDR을 할당합니다.

많은 조직에서 IP 주소 관리(IPAM) 도구를 사용하여 체계적으로 관리합니다. AWS에서도 VPC IPAM 서비스를 제공합니다.

이미 중복된 VPC가 있다면 어떻게 해야 할까요? 안타깝게도 기존 VPC의 기본 CIDR은 변경할 수 없습니다.

하지만 VPC에 보조 CIDR 블록을 추가할 수 있습니다. 새로운 서브넷을 겹치지 않는 보조 CIDR로 만들고, 피어링 통신이 필요한 리소스를 그쪽으로 이전하는 방법이 있습니다.

예를 들어 VPC-A가 10.0.0.0/16이고 VPC-B도 10.0.0.0/16이라면, VPC-B에 보조 CIDR로 10.2.0.0/16을 추가합니다. 그리고 10.2.0.0/16 대역의 서브넷에 있는 리소스와만 피어링 통신을 하면 됩니다.

실무에서 권장하는 CIDR 설계 방식을 알려드리겠습니다. 환경별로 다른 대역을 미리 예약해두세요.

예를 들어 개발 환경은 10.0.0.0/16, 스테이징은 10.1.0.0/16, 운영은 10.2.0.0/16처럼 설계합니다. 리전별로도 구분하면 좋습니다.

서울 리전은 10.0.0.0~~10.15.0.0, 도쿄 리전은 10.16.0.0~~10.31.0.0 같은 식입니다. 김개발 씨가 한숨을 쉬었습니다.

"그러면 이미 만들어진 VPC는 어떻게 하죠?" 박시니어 씨가 위로했습니다. "보조 CIDR 방법도 있고, 정 안 되면 VPC를 새로 만들어서 마이그레이션하는 수밖에 없어요.

그래서 처음 설계가 중요한 거예요."

실전 팁

💡 - VPC 생성 전에 전체 네트워크 CIDR 계획을 세우세요

AWS VPC IPAM을 활용하면 체계적인 IP 관리가 가능합니다
중복이 발생했다면 보조 CIDR 블록 추가를 고려해보세요

6. 피어링 제약사항과 한계

김개발 씨는 VPC 피어링이 만능 해결책인 줄 알았습니다. 하지만 구성을 진행하면서 여러 제약사항을 마주하게 됩니다.

"A에서 B로 갔다가 C로 가면 안 되나요?" 박시니어 씨가 단호하게 말했습니다. "안 돼요.

전이적 라우팅은 지원하지 않아요."

VPC 피어링은 편리하지만 여러 제약사항이 있습니다. 가장 큰 제약은 전이적 라우팅이 불가능하다는 점입니다.

또한 대역폭 제한, DNS 확인 설정, 보안 그룹 참조 제한 등 알아두어야 할 사항들이 있습니다. 이러한 한계를 이해하고 적절한 대안을 선택해야 합니다.

다음 코드를 살펴봅시다.

# VPC 피어링 한계 우회: Transit Gateway 사용 예시
import boto3

ec2 = boto3.client('ec2', region_name='ap-northeast-2')

# Transit Gateway 생성 (전이적 라우팅 필요시)
tgw = ec2.create_transit_gateway(
    Description='Central Hub for VPC connections',
    Options={
        'DefaultRouteTableAssociation': 'enable',
        'DefaultRouteTablePropagation': 'enable',
        'VpnEcmpSupport': 'enable',
        'DnsSupport': 'enable'
    }
)

# 각 VPC를 Transit Gateway에 연결
# 이렇게 하면 A-B-C 간 전이적 통신이 가능
# VPC-A -> TGW -> VPC-B
# VPC-A -> TGW -> VPC-C (A-B, B-C 피어링만으로는 불가능했던 것)

print("Transit Gateway를 사용하면 전이적 라우팅이 가능합니다")

박시니어 씨가 세 개의 원을 그리고 선으로 연결했습니다. "VPC-A와 VPC-B가 피어링되어 있고, VPC-B와 VPC-C도 피어링되어 있다고 해봅시다.

A에서 C로 직접 통신이 될까요?" 김개발 씨가 자신 있게 대답했습니다. "B를 거쳐서 가면 되지 않나요?" 박시니어 씨가 고개를 저었습니다.

"그게 안 돼요. **전이적 라우팅(Transitive Routing)**이 지원되지 않거든요." 전이적 라우팅이 불가능하다는 것은 무슨 의미일까요?

A-B 피어링과 B-C 피어링이 있어도 A에서 B를 경유해서 C로 가는 것이 불가능합니다. A에서 C로 통신하려면 별도로 A-C 피어링을 만들어야 합니다.

VPC가 10개라면 최대 45개의 피어링 연결이 필요할 수 있습니다. 이것은 피어링의 가장 큰 한계입니다.

이 문제를 해결하려면 Transit Gateway를 사용합니다. Transit Gateway는 중앙 허브 역할을 합니다.

모든 VPC를 Transit Gateway에 연결하면 허브를 통해 어느 VPC끼리든 통신이 가능합니다. VPC가 많을수록 피어링보다 Transit Gateway가 관리하기 편합니다.

다만 Transit Gateway는 별도 비용이 발생합니다. 대역폭 제한도 알아두어야 합니다.

VPC 피어링 자체에는 대역폭 제한이 없습니다. 하지만 인스턴스 유형에 따른 네트워크 대역폭 제한은 적용됩니다.

예를 들어 t3.micro는 최대 5Gbps까지만 지원합니다. 피어링은 병목이 아니지만, 인스턴스가 병목이 될 수 있습니다.

DNS 확인도 별도로 설정해야 합니다. 피어링된 VPC의 프라이빗 DNS 이름을 확인하려면 피어링 연결에서 DNS 확인 옵션을 활성화해야 합니다.

기본적으로는 비활성화되어 있습니다. 예를 들어 VPC-B의 RDS 엔드포인트(mydb.xxxxx.ap-northeast-2.rds.amazonaws.com)를 VPC-A에서 해석하려면 이 설정이 필요합니다.

보안 그룹 참조에도 제한이 있습니다. 같은 리전 내 피어링에서는 상대 VPC의 보안 그룹 ID를 직접 참조할 수 있습니다.

하지만 교차 리전 피어링에서는 보안 그룹 ID 참조가 불가능합니다. CIDR 블록으로만 규칙을 설정해야 합니다.

피어링 연결 개수에도 할당량이 있습니다. 기본적으로 VPC당 최대 125개의 피어링 연결이 가능합니다.

필요하면 AWS에 증가 요청을 할 수 있지만, 그 정도로 많은 피어링이 필요하다면 Transit Gateway를 고려하는 것이 좋습니다. 마지막으로 Edge to Edge 라우팅도 불가능합니다.

VPC-A가 인터넷 게이트웨이나 VPN 연결을 가지고 있다고 해서 피어링된 VPC-B가 그것을 통해 외부로 나갈 수 없습니다. 각 VPC는 자체 인터넷 게이트웨이나 NAT를 구성해야 합니다.

김개발 씨가 정리했습니다. "결국 VPC가 3-4개 이상이고 모두 통신해야 한다면 Transit Gateway가 낫겠네요." 박시니어 씨가 끄덕였습니다.

"맞아요. 피어링은 간단한 1:1 연결에 적합하고, 복잡한 네트워크는 Transit Gateway가 더 효율적이에요." VPC 피어링의 한계를 이해하면 올바른 아키텍처 결정을 내릴 수 있습니다.

프로젝트 요구사항에 맞는 네트워킹 솔루션을 선택하세요.

실전 팁

💡 - 3개 이상 VPC를 모두 연결해야 한다면 Transit Gateway를 검토하세요

교차 리전 피어링에서는 보안 그룹 ID 대신 CIDR로 규칙을 설정해야 합니다
DNS 확인 옵션은 피어링 연결 설정에서 명시적으로 활성화해야 합니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#VPC#Peering#Network#PrivateLink#AWS,VPC,Network

VPC 피어링으로 VPC 간 프라이빗 통신 완벽 가이드

# VPC 피어링으로 VPC 간 프라이빗 통신 완벽 가이드 AWS에서 서로 다른 VPC 간에 인터넷을 거치지 않고 프라이빗하게 통신하는 VPC 피어링의 개념부터 실전 구성까지 초급자도 이해할 수 있도록 설명합니다. 동일 리전과 교차 리전 피어링의 차이점, 라우팅 설정, CIDR 중복 문제 해결까지 실무에서 꼭 알아야 할 내용을 다룹니다. --- ## 목차 1. [VPC_피어링의_개념과_사용_사례](#vpc-피어링의-개념과-사용-사례) 2. [동일_리전_vs_교차_리전_피어링](#동일-리전-vs-교차-리전-피어링) 3. [피어링_연결_생성_및_수락](#피어링-연결-생성-및-수락) 4. [라우팅_테이블_양방향_설정](#라우팅-테이블-양방향-설정) 5. [CIDR_중복_문제_해결](#cidr-중복-문제-해결) 6. [피어링_제약사항과_한계](#피어링-제약사항과-한계) --- ## 1. VPC_피어링의_개념과_사용_사례 김개발 씨는 스타트업에서 백엔드 개발을 담당하고 있습니다. 어느 날 팀장님이 다가와 말했습니다. "우리 개발 환경 VPC랑 운영 환경 VPC를 연결해야 하는데, 인터넷 안 거치고 안전하게 연결할 방법 없을까요?" 김개발 씨는 잠시 고민에 빠졌습니다. **VPC 피어링**은 두 개의 VPC를 프라이빗 네트워크로 직접 연결하는 기술입니다. 마치 두 집 사이에 비밀 터널을 뚫어 외부에 노출되지 않고 왕래할 수 있게 만드는 것과 같습니다. 이를 통해 인터넷 게이트웨이나 VPN 없이도 VPC 간 안전한 통신이 가능해집니다. 다음 코드를 살펴봅시다. ```python import boto3 # VPC 피어링 연결 요청 생성 ec2 = boto3.client('ec2', region_name='ap-northeast-2') # 요청자 VPC에서 피어링 연결 생성 response = ec2.create_vpc_peering_connection( VpcId='vpc-11111111', # 요청자 VPC ID PeerVpcId='vpc-22222222', # 수락자 VPC ID PeerOwnerId='123456789012', # 상대방 AWS 계정 ID (같은 계정이면 생략 가능) PeerRegion='ap-northeast-2' # 피어링 대상 리전 ) peering_id = response['VpcPeeringConnection']['VpcPeeringConnectionId'] print(f"피어링 연결 ID: {peering_id}") ``` 김개발 씨는 입사한 지 6개월 된 주니어 클라우드 엔지니어입니다. 회사는 개발 환경과 운영 환경을 분리하기 위해 각각 별도의 VPC를 사용하고 있었습니다. 그런데 개발 환경에서 운영 환경의 데이터베이스에 접근해야 하는 상황이 생겼습니다. "인터넷으로 연결하면 안 되나요?" 김개발 씨가 물었습니다. 박시니어 씨가 고개를 저었습니다. "그건 보안상 위험해요. 민감한 데이터가 공용 인터넷을 타고 다니면 안 되죠." 그렇다면 **VPC 피어링**이란 정확히 무엇일까요? 쉽게 비유하자면, VPC 피어링은 마치 두 개의 아파트 단지 사이에 전용 연결 통로를 만드는 것과 같습니다. 평소에는 각 단지가 독립적으로 운영되지만, 이 통로를 통해 주민들이 외부 도로를 거치지 않고 안전하게 오갈 수 있습니다. VPC 피어링도 마찬가지로 두 VPC 사이에 **프라이빗 연결**을 만들어 AWS 내부 네트워크만 사용합니다. VPC 피어링이 없던 시절에는 어떻게 했을까요? 개발자들은 VPC 간 통신을 위해 인터넷 게이트웨이를 통하거나, VPN을 구축해야 했습니다. 인터넷을 통한 통신은 보안 위험이 있고, VPN은 설정이 복잡하며 추가 비용이 발생했습니다. 더 큰 문제는 **지연 시간**이었습니다. 외부 네트워크를 경유하면 응답 속도가 느려질 수밖에 없었습니다. 바로 이런 문제를 해결하기 위해 VPC 피어링이 등장했습니다. VPC 피어링을 사용하면 **AWS 백본 네트워크**를 통해 직접 통신합니다. 인터넷을 거치지 않으므로 보안이 강화되고, 지연 시간도 최소화됩니다. 무엇보다 설정이 간단하고 추가 하드웨어나 복잡한 VPN 구성이 필요 없습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 boto3 클라이언트를 생성하여 EC2 서비스에 연결합니다. **create_vpc_peering_connection** 메서드는 피어링 연결을 요청하는 핵심 함수입니다. VpcId는 요청을 보내는 쪽의 VPC, PeerVpcId는 연결하려는 상대방 VPC를 지정합니다. 다른 AWS 계정의 VPC와 연결하려면 PeerOwnerId에 해당 계정 ID를 명시해야 합니다. 실제 현업에서는 어떻게 활용할까요? 가장 흔한 사례는 **개발/스테이징/운영 환경 분리**입니다. 각 환경을 별도 VPC로 운영하면서 필요할 때만 피어링으로 연결합니다. 또 다른 사례는 **마이크로서비스 아키텍처**입니다. 서비스별로 VPC를 분리하고 피어링으로 연결하면 보안과 관리 효율성을 모두 확보할 수 있습니다. 대기업에서는 부서별 VPC를 피어링으로 연결하는 경우도 많습니다. 하지만 주의할 점도 있습니다. VPC 피어링은 **전이적 연결**을 지원하지 않습니다. A-B 피어링, B-C 피어링이 있다고 해서 A에서 C로 직접 통신할 수 없습니다. A와 C도 별도로 피어링해야 합니다. 이 점을 모르고 설계하면 예상과 다르게 동작해서 당황할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다. "아, 그래서 피어링을 쓰는 거군요! 인터넷 안 거치고 안전하게 연결할 수 있으니까요." VPC 피어링을 이해하면 멀티 VPC 아키텍처를 설계할 때 훨씬 유연하게 대응할 수 있습니다. 여러분도 오늘 배운 내용을 실제 AWS 환경에서 적용해 보세요. **실전 팁** 💡 - VPC 피어링은 양방향이지만, 연결 요청과 수락은 별도로 진행해야 합니다 - 피어링 연결 후 반드시 양쪽 VPC의 라우팅 테이블을 업데이트해야 통신이 가능합니다 - 같은 계정 내 VPC끼리는 PeerOwnerId를 생략할 수 있습니다 --- ## 2. 동일_리전_vs_교차_리전_피어링 김개발 씨가 VPC 피어링 개념을 익힌 후, 새로운 과제가 주어졌습니다. "서울 리전이랑 도쿄 리전 VPC도 연결해야 해요." 같은 리전끼리만 연결되는 줄 알았던 김개발 씨는 잠시 당황했습니다. 과연 다른 리전끼리도 피어링이 가능할까요? VPC 피어링은 **동일 리전 피어링**과 **교차 리전 피어링** 두 가지로 나뉩니다. 동일 리전 피어링은 같은 지역 내 VPC를 연결하고, 교차 리전 피어링은 서로 다른 지역의 VPC를 연결합니다. 두 방식 모두 AWS 프라이빗 네트워크를 사용하지만, 특성과 제약사항에 차이가 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # 교차 리전 피어링: 서울(요청자) -> 도쿄(수락자) ec2_seoul = boto3.client('ec2', region_name='ap-northeast-2') # 교차 리전 피어링 요청 생성 response = ec2_seoul.create_vpc_peering_connection( VpcId='vpc-seoul-11111', # 서울 리전 VPC PeerVpcId='vpc-tokyo-22222', # 도쿄 리전 VPC PeerRegion='ap-northeast-1' # 반드시 피어 리전 명시 필요 ) # 도쿄 리전에서 피어링 수락 ec2_tokyo = boto3.client('ec2', region_name='ap-northeast-1') ec2_tokyo.accept_vpc_peering_connection( VpcPeeringConnectionId=response['VpcPeeringConnection']['VpcPeeringConnectionId'] ) ``` 박시니어 씨가 김개발 씨에게 설명을 시작했습니다. "리전이 달라도 피어링이 가능해요. 하지만 몇 가지 다른 점이 있죠." **동일 리전 피어링**은 말 그대로 같은 리전 안에서 VPC를 연결하는 것입니다. 서울 리전의 VPC-A와 VPC-B를 연결한다고 생각하면 됩니다. 마치 같은 도시 안에서 두 건물을 전용 통로로 연결하는 것과 같습니다. 거리가 가깝기 때문에 **지연 시간이 매우 짧고**, 데이터 전송 비용도 저렴합니다. 반면 **교차 리전 피어링**은 서로 다른 리전의 VPC를 연결합니다. 서울 리전과 도쿄 리전, 또는 서울과 버지니아 리전을 연결할 수 있습니다. 마치 서울에 있는 건물과 도쿄에 있는 건물을 해저 터널로 연결하는 것과 비슷합니다. 당연히 거리가 멀기 때문에 **지연 시간이 더 길고**, 데이터가 리전을 넘어가므로 **전송 비용**도 추가됩니다. 그렇다면 교차 리전 피어링은 왜 필요할까요? 글로벌 서비스를 운영한다고 가정해봅시다. 한국 사용자를 위한 서울 리전과 일본 사용자를 위한 도쿄 리전에 각각 서비스를 배포했습니다. 두 리전의 백엔드 시스템이 데이터를 동기화하거나 공유해야 할 때 교차 리전 피어링이 유용합니다. 인터넷을 통해 연결하면 보안 위험과 불안정한 네트워크 품질 문제가 있지만, 교차 리전 피어링은 **AWS 글로벌 백본 네트워크**를 사용하므로 안정적이고 보안이 강화됩니다. 위의 코드에서 중요한 차이점을 살펴보겠습니다. 교차 리전 피어링에서는 **PeerRegion** 파라미터가 필수입니다. 동일 리전에서는 생략해도 되지만, 다른 리전 VPC와 연결할 때는 반드시 상대방 리전을 명시해야 합니다. 또한 피어링을 수락할 때는 **상대방 리전의 클라이언트**를 사용해야 합니다. 서울에서 요청을 보냈다면, 도쿄 리전 클라이언트로 수락해야 합니다. 비용 측면에서의 차이도 중요합니다. 동일 리전 피어링에서 데이터 전송 비용은 일반적인 VPC 내 통신과 비슷합니다. 하지만 교차 리전 피어링은 **리전 간 데이터 전송 비용**이 적용됩니다. 대용량 데이터를 자주 전송한다면 비용이 상당히 늘어날 수 있으니 미리 계산해보는 것이 좋습니다. 성능 차이는 어느 정도일까요? 동일 리전 피어링의 지연 시간은 보통 **1ms 미만**입니다. 같은 데이터센터 안에 있다고 생각하면 됩니다. 반면 교차 리전 피어링은 물리적 거리에 따라 다릅니다. 서울-도쿄는 약 **30-50ms**, 서울-버지니아는 **150-200ms** 정도의 지연이 발생할 수 있습니다. 김개발 씨가 고개를 끄덕였습니다. "그러면 우리 경우에는 어떤 걸 써야 하나요?" 박시니어 씨가 답했습니다. "재해 복구용 도쿄 리전 연결은 교차 리전 피어링으로, 같은 서울 리전 내 개발-운영 환경 연결은 동일 리전 피어링으로 가면 되겠네요." 상황에 맞는 피어링 방식을 선택하면 비용과 성능 모두 최적화할 수 있습니다. **실전 팁** 💡 - 교차 리전 피어링은 PeerRegion 파라미터가 필수이므로 잊지 마세요 - 대용량 데이터 전송이 예상되면 교차 리전 데이터 전송 비용을 미리 계산하세요 - 지연 시간에 민감한 서비스는 동일 리전 내에서 피어링을 구성하는 것이 좋습니다 --- ## 3. 피어링_연결_생성_및_수락 이론을 충분히 배운 김개발 씨가 드디어 실제로 VPC 피어링을 구성해보려 합니다. "연결 생성하고 수락하면 끝인 거죠?" 박시니어 씨가 웃으며 말했습니다. "맞아요, 근데 생각보다 헷갈리는 부분이 있어요. 한번 같이 해볼까요?" VPC 피어링은 **요청자**와 **수락자**가 존재하는 양방향 핸드셰이크 과정입니다. 한쪽 VPC에서 연결을 요청하고, 상대방 VPC 소유자가 이를 수락해야만 피어링이 활성화됩니다. 같은 계정 내라도 명시적인 수락 과정이 필요합니다. 다음 코드를 살펴봅시다. ```python import boto3 import time ec2 = boto3.client('ec2', region_name='ap-northeast-2') # Step 1: 피어링 연결 요청 (요청자 VPC에서) peering = ec2.create_vpc_peering_connection( VpcId='vpc-requester-111', PeerVpcId='vpc-accepter-222' ) pcx_id = peering['VpcPeeringConnection']['VpcPeeringConnectionId'] print(f"피어링 요청 생성됨: {pcx_id}") # Step 2: 피어링 연결 수락 (수락자 VPC에서) # 다른 계정이라면 해당 계정 권한으로 실행 ec2.accept_vpc_peering_connection( VpcPeeringConnectionId=pcx_id ) print(f"피어링 연결 수락됨: {pcx_id}") # Step 3: 연결 상태 확인 response = ec2.describe_vpc_peering_connections( VpcPeeringConnectionIds=[pcx_id] ) status = response['VpcPeeringConnections'][0]['Status']['Code'] print(f"현재 상태: {status}") # 'active'면 성공 ``` 박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작했습니다. "VPC 피어링은 마치 친구 신청과 비슷해요. 한쪽에서 신청하고, 상대방이 수락해야 친구가 되잖아요." 피어링 연결의 첫 번째 단계는 **연결 요청**입니다. 요청자 VPC에서 상대방 VPC를 지정하여 피어링 연결을 생성합니다. 이 시점에서 피어링 상태는 **pending-acceptance**가 됩니다. 상대방이 아직 수락하지 않았다는 의미입니다. 두 번째 단계는 **연결 수락**입니다. 수락자 VPC 소유자가 피어링 연결 ID를 사용하여 연결을 수락합니다. 같은 AWS 계정 내 VPC끼리 연결하더라도 이 수락 과정은 생략할 수 없습니다. 자동으로 수락되지 않으니 주의하세요. "잠깐요, 왜 자동 수락이 안 되는 거예요?" 김개발 씨가 의문을 제기했습니다. 보안상의 이유입니다. 만약 자동 수락이 된다면, 누군가 악의적으로 피어링 요청을 보내 네트워크에 침투할 수 있습니다. 명시적인 수락 과정이 있어야 의도하지 않은 연결을 방지할 수 있습니다. 특히 다른 AWS 계정과의 피어링에서 이 보안 메커니즘은 매우 중요합니다. 피어링 연결에는 여러 가지 **상태**가 있습니다. **initiating-request**는 연결 요청이 시작되는 순간의 상태입니다. **pending-acceptance**는 요청이 생성되었고 상대방의 수락을 기다리는 상태입니다. 피어링 요청은 기본적으로 **7일** 동안 유효하며, 그 안에 수락하지 않으면 자동으로 만료됩니다. **active**는 양쪽 모두 연결을 수락하여 피어링이 활성화된 상태입니다. 다른 계정의 VPC와 피어링할 때는 추가 정보가 필요합니다. 상대방의 **AWS 계정 ID**와 **VPC ID**를 알아야 합니다. 교차 리전이라면 **리전 정보**도 필요합니다. 이 정보를 요청할 때 전달하면, 상대방 계정에서 해당 피어링 연결을 확인하고 수락할 수 있습니다. 실무에서 흔히 발생하는 실수를 알려드리겠습니다. 피어링 요청을 생성하고 수락까지 했는데 통신이 안 된다며 당황하는 경우가 많습니다. 이건 **라우팅 테이블**을 설정하지 않아서 그렇습니다. 피어링 연결을 활성화했다고 해서 바로 통신이 되는 것이 아닙니다. 다음 섹션에서 라우팅 테이블 설정을 자세히 다루겠습니다. 김개발 씨가 코드를 따라 치며 실습했습니다. "오, 정말 active 상태가 됐어요!" 박시니어 씨가 미소 지었습니다. "좋아요, 이제 라우팅 테이블을 설정해야 진짜 통신이 됩니다." **실전 팁** 💡 - 피어링 요청은 7일 내에 수락하지 않으면 자동 만료됩니다 - 같은 계정 내 VPC라도 수락 과정은 필수입니다 - describe_vpc_peering_connections로 상태를 확인하며 진행하세요 --- ## 4. 라우팅_테이블_양방향_설정 VPC 피어링 연결이 active 상태가 됐지만, 김개발 씨가 ping 테스트를 해보니 응답이 없습니다. "분명히 연결됐는데 왜 안 되는 거죠?" 박시니어 씨가 고개를 끄덕이며 말했습니다. "피어링은 연결만으로 끝이 아니에요. 라우팅을 설정해줘야 해요." VPC 피어링 연결이 활성화되어도 **라우팅 테이블**을 설정하지 않으면 트래픽이 전달되지 않습니다. 양쪽 VPC의 라우팅 테이블에 상대방 CIDR 블록을 목적지로, 피어링 연결을 대상으로 하는 라우트를 추가해야 합니다. 이것은 피어링 구성에서 가장 중요한 단계입니다. 다음 코드를 살펴봅시다. ```python import boto3 ec2 = boto3.client('ec2', region_name='ap-northeast-2') # VPC-A (10.0.0.0/16) VPC-B (10.1.0.0/16) 피어링 pcx_id = 'pcx-0123456789abcdef0' # VPC-A의 라우팅 테이블에 VPC-B로 가는 경로 추가 ec2.create_route( RouteTableId='rtb-aaaaaa', # VPC-A의 라우팅 테이블 DestinationCidrBlock='10.1.0.0/16', # VPC-B의 CIDR VpcPeeringConnectionId=pcx_id ) # VPC-B의 라우팅 테이블에 VPC-A로 가는 경로 추가 ec2.create_route( RouteTableId='rtb-bbbbbb', # VPC-B의 라우팅 테이블 DestinationCidrBlock='10.0.0.0/16', # VPC-A의 CIDR VpcPeeringConnectionId=pcx_id ) print("양방향 라우팅 설정 완료") ``` 박시니어 씨가 네트워크 다이어그램을 그리며 설명을 시작했습니다. "VPC 피어링을 도로에 비유하면, 지금은 도로만 깔린 상태예요. 이정표가 없어서 차들이 어디로 가야 할지 모르는 거죠." **라우팅 테이블**은 바로 그 이정표 역할을 합니다. 특정 목적지로 가려면 어떤 경로를 통해야 하는지 알려주는 것입니다. VPC 피어링에서는 상대방 VPC의 IP 대역으로 가려면 피어링 연결을 통하라고 명시해줘야 합니다. 핵심은 **양방향 설정**입니다. VPC-A에서 VPC-B로 패킷을 보내려면 VPC-A의 라우팅 테이블에 설정이 필요합니다. 마찬가지로 VPC-B에서 VPC-A로 응답을 보내려면 VPC-B의 라우팅 테이블에도 설정이 필요합니다. 한쪽만 설정하면 요청은 가지만 응답이 돌아오지 못해 통신이 실패합니다. 라우팅 테이블 설정을 구체적으로 살펴보겠습니다. VPC-A의 CIDR이 10.0.0.0/16이고 VPC-B의 CIDR이 10.1.0.0/16이라고 가정합시다. VPC-A의 라우팅 테이블에는 목적지 10.1.0.0/16으로 가는 트래픽을 피어링 연결(pcx-xxxx)으로 보내는 라우트를 추가합니다. VPC-B의 라우팅 테이블에는 목적지 10.0.0.0/16으로 가는 트래픽을 같은 피어링 연결로 보내는 라우트를 추가합니다. 여기서 주의할 점이 있습니다. VPC에는 여러 개의 **서브넷**이 있고, 각 서브넷은 서로 다른 라우팅 테이블을 사용할 수 있습니다. 피어링 통신이 필요한 모든 서브넷의 라우팅 테이블에 설정을 추가해야 합니다. 메인 라우팅 테이블만 수정하고 끝내면 커스텀 라우팅 테이블을 사용하는 서브넷에서는 피어링 통신이 안 됩니다. 실무에서는 특정 서브넷만 피어링을 사용하도록 구성하기도 합니다. 예를 들어 퍼블릭 서브넷은 인터넷 게이트웨이만 사용하고, 프라이빗 서브넷만 피어링을 통해 다른 VPC와 통신하도록 설정할 수 있습니다. 이렇게 하면 **네트워크 세그먼테이션**을 유지하면서 필요한 통신만 허용할 수 있습니다. 보안 그룹 설정도 잊지 마세요. 라우팅만 설정해서는 안 됩니다. EC2 인스턴스나 RDS의 **보안 그룹**에서 상대방 VPC의 CIDR 블록에서 오는 트래픽을 허용해야 합니다. 피어링된 VPC의 보안 그룹 ID를 직접 참조할 수도 있습니다. 이 기능을 사용하면 IP 대역 대신 보안 그룹 단위로 세밀하게 접근 제어가 가능합니다. 김개발 씨가 라우팅을 설정한 후 다시 ping 테스트를 했습니다. "드디어 응답이 와요!" 박시니어 씨가 칭찬했습니다. "잘했어요. 라우팅은 피어링에서 가장 중요한 부분이에요. 이걸 놓치면 아무리 연결해도 소용없죠." **실전 팁** 💡 - 양쪽 VPC의 라우팅 테이블 모두에 설정해야 양방향 통신이 됩니다 - 서브넷별로 다른 라우팅 테이블을 사용한다면 모든 관련 테이블을 확인하세요 - 라우팅 설정 후 보안 그룹에서 상대방 CIDR 허용도 잊지 마세요 --- ## 5. CIDR_중복_문제_해결 김개발 씨가 새로운 VPC 피어링을 시도하다가 에러를 만났습니다. "overlapping CIDR blocks"라는 메시지가 떴습니다. "이게 뭐죠? 왜 연결이 안 되는 거예요?" 박시니어 씨가 한숨을 쉬며 말했습니다. "가장 흔한 문제 중 하나예요. VPC 설계할 때 미리 생각했어야 하는 부분이죠." **CIDR 중복**은 VPC 피어링의 가장 큰 제약사항 중 하나입니다. 두 VPC의 IP 대역이 겹치면 라우팅이 모호해져서 피어링이 불가능합니다. 이 문제를 예방하려면 VPC 설계 단계에서 IP 대역을 신중하게 계획해야 합니다. 다음 코드를 살펴봅시다. ```python # CIDR 중복 확인 스크립트 import boto3 import ipaddress def check_cidr_overlap(cidr1, cidr2): """두 CIDR 블록이 겹치는지 확인""" network1 = ipaddress.ip_network(cidr1) network2 = ipaddress.ip_network(cidr2) return network1.overlaps(network2) # 피어링하려는 VPC들의 CIDR 확인 ec2 = boto3.client('ec2', region_name='ap-northeast-2') vpc_a = ec2.describe_vpcs(VpcIds=['vpc-111'])['Vpcs'][0] vpc_b = ec2.describe_vpcs(VpcIds=['vpc-222'])['Vpcs'][0] cidr_a = vpc_a['CidrBlock'] cidr_b = vpc_b['CidrBlock'] if check_cidr_overlap(cidr_a, cidr_b): print(f"경고: CIDR 중복! {cidr_a} {cidr_b}") print("피어링이 불가능합니다. CIDR 재설계가 필요합니다.") else: print(f"OK: CIDR 중복 없음. 피어링 가능합니다.") ``` 박시니어 씨가 화이트보드에 두 개의 VPC를 그렸습니다. 둘 다 10.0.0.0/16이라고 적혀 있었습니다. "문제가 보이나요?" 김개발 씨가 잠시 생각하다 대답했습니다. "두 VPC가 같은 IP 대역을 쓰고 있네요?" 정확합니다. **CIDR 중복**이란 두 VPC의 IP 주소 범위가 전체 또는 일부 겹치는 상황을 말합니다. 왜 중복이 문제가 될까요? 예를 들어 VPC-A와 VPC-B 모두 10.0.0.0/16 대역을 사용한다고 합시다. VPC-A의 인스턴스(10.0.1.5)가 10.0.2.10으로 패킷을 보내려 합니다. 이 IP가 VPC-A 내부 인스턴스인지, 피어링된 VPC-B의 인스턴스인지 구분할 수 없습니다. **라우팅이 모호**해지므로 AWS는 아예 이런 피어링을 허용하지 않습니다. 부분 중복도 마찬가지입니다. VPC-A가 10.0.0.0/16이고 VPC-B가 10.0.0.0/24라면 어떨까요? /24는 /16의 부분 집합입니다. 10.0.0.0~10.0.0.255 범위가 겹칩니다. 이 경우에도 피어링이 불가능합니다. 그렇다면 어떻게 해결할까요? 가장 좋은 방법은 **예방**입니다. VPC를 생성하기 전에 전체 네트워크 아키텍처를 설계하고, 각 VPC에 겹치지 않는 CIDR을 할당합니다. 많은 조직에서 **IP 주소 관리(IPAM)** 도구를 사용하여 체계적으로 관리합니다. AWS에서도 VPC IPAM 서비스를 제공합니다. 이미 중복된 VPC가 있다면 어떻게 해야 할까요? 안타깝게도 기존 VPC의 **기본 CIDR은 변경할 수 없습니다**. 하지만 VPC에 **보조 CIDR 블록**을 추가할 수 있습니다. 새로운 서브넷을 겹치지 않는 보조 CIDR로 만들고, 피어링 통신이 필요한 리소스를 그쪽으로 이전하는 방법이 있습니다. 예를 들어 VPC-A가 10.0.0.0/16이고 VPC-B도 10.0.0.0/16이라면, VPC-B에 보조 CIDR로 10.2.0.0/16을 추가합니다. 그리고 10.2.0.0/16 대역의 서브넷에 있는 리소스와만 피어링 통신을 하면 됩니다. 실무에서 권장하는 CIDR 설계 방식을 알려드리겠습니다. 환경별로 다른 대역을 미리 예약해두세요. 예를 들어 개발 환경은 10.0.0.0/16, 스테이징은 10.1.0.0/16, 운영은 10.2.0.0/16처럼 설계합니다. 리전별로도 구분하면 좋습니다. 서울 리전은 10.0.0.0~10.15.0.0, 도쿄 리전은 10.16.0.0~10.31.0.0 같은 식입니다. 김개발 씨가 한숨을 쉬었습니다. "그러면 이미 만들어진 VPC는 어떻게 하죠?" 박시니어 씨가 위로했습니다. "보조 CIDR 방법도 있고, 정 안 되면 VPC를 새로 만들어서 마이그레이션하는 수밖에 없어요. 그래서 처음 설계가 중요한 거예요." **실전 팁** 💡 - VPC 생성 전에 전체 네트워크 CIDR 계획을 세우세요 - AWS VPC IPAM을 활용하면 체계적인 IP 관리가 가능합니다 - 중복이 발생했다면 보조 CIDR 블록 추가를 고려해보세요 --- ## 6. 피어링_제약사항과_한계 김개발 씨는 VPC 피어링이 만능 해결책인 줄 알았습니다. 하지만 구성을 진행하면서 여러 제약사항을 마주하게 됩니다. "A에서 B로 갔다가 C로 가면 안 되나요?" 박시니어 씨가 단호하게 말했습니다. "안 돼요. 전이적 라우팅은 지원하지 않아요." VPC 피어링은 편리하지만 여러 **제약사항**이 있습니다. 가장 큰 제약은 전이적 라우팅이 불가능하다는 점입니다. 또한 대역폭 제한, DNS 확인 설정, 보안 그룹 참조 제한 등 알아두어야 할 사항들이 있습니다. 이러한 한계를 이해하고 적절한 대안을 선택해야 합니다. 다음 코드를 살펴봅시다. ```python # VPC 피어링 한계 우회: Transit Gateway 사용 예시 import boto3 ec2 = boto3.client('ec2', region_name='ap-northeast-2') # Transit Gateway 생성 (전이적 라우팅 필요시) tgw = ec2.create_transit_gateway( Description='Central Hub for VPC connections', Options={ 'DefaultRouteTableAssociation': 'enable', 'DefaultRouteTablePropagation': 'enable', 'VpnEcmpSupport': 'enable', 'DnsSupport': 'enable' } ) # 각 VPC를 Transit Gateway에 연결 # 이렇게 하면 A-B-C 간 전이적 통신이 가능 # VPC-A -> TGW -> VPC-B # VPC-A -> TGW -> VPC-C (A-B, B-C 피어링만으로는 불가능했던 것) print("Transit Gateway를 사용하면 전이적 라우팅이 가능합니다") ``` 박시니어 씨가 세 개의 원을 그리고 선으로 연결했습니다. "VPC-A와 VPC-B가 피어링되어 있고, VPC-B와 VPC-C도 피어링되어 있다고 해봅시다. A에서 C로 직접 통신이 될까요?" 김개발 씨가 자신 있게 대답했습니다. "B를 거쳐서 가면 되지 않나요?" 박시니어 씨가 고개를 저었습니다. "그게 안 돼요. **전이적 라우팅(Transitive Routing)**이 지원되지 않거든요." 전이적 라우팅이 불가능하다는 것은 무슨 의미일까요? A-B 피어링과 B-C 피어링이 있어도 A에서 B를 경유해서 C로 가는 것이 불가능합니다. A에서 C로 통신하려면 별도로 A-C 피어링을 만들어야 합니다. VPC가 10개라면 최대 45개의 피어링 연결이 필요할 수 있습니다. 이것은 피어링의 가장 큰 한계입니다. 이 문제를 해결하려면 **Transit Gateway**를 사용합니다. Transit Gateway는 중앙 허브 역할을 합니다. 모든 VPC를 Transit Gateway에 연결하면 허브를 통해 어느 VPC끼리든 통신이 가능합니다. VPC가 많을수록 피어링보다 Transit Gateway가 관리하기 편합니다. 다만 Transit Gateway는 별도 비용이 발생합니다. 대역폭 제한도 알아두어야 합니다. VPC 피어링 자체에는 **대역폭 제한이 없습니다**. 하지만 인스턴스 유형에 따른 네트워크 대역폭 제한은 적용됩니다. 예를 들어 t3.micro는 최대 5Gbps까지만 지원합니다. 피어링은 병목이 아니지만, 인스턴스가 병목이 될 수 있습니다. **DNS 확인**도 별도로 설정해야 합니다. 피어링된 VPC의 프라이빗 DNS 이름을 확인하려면 피어링 연결에서 DNS 확인 옵션을 활성화해야 합니다. 기본적으로는 비활성화되어 있습니다. 예를 들어 VPC-B의 RDS 엔드포인트(mydb.xxxxx.ap-northeast-2.rds.amazonaws.com)를 VPC-A에서 해석하려면 이 설정이 필요합니다. **보안 그룹 참조**에도 제한이 있습니다. 같은 리전 내 피어링에서는 상대 VPC의 보안 그룹 ID를 직접 참조할 수 있습니다. 하지만 **교차 리전 피어링**에서는 보안 그룹 ID 참조가 불가능합니다. CIDR 블록으로만 규칙을 설정해야 합니다. 피어링 연결 개수에도 **할당량**이 있습니다. 기본적으로 VPC당 최대 125개의 피어링 연결이 가능합니다. 필요하면 AWS에 증가 요청을 할 수 있지만, 그 정도로 많은 피어링이 필요하다면 Transit Gateway를 고려하는 것이 좋습니다. 마지막으로 **Edge to Edge 라우팅**도 불가능합니다. VPC-A가 인터넷 게이트웨이나 VPN 연결을 가지고 있다고 해서 피어링된 VPC-B가 그것을 통해 외부로 나갈 수 없습니다. 각 VPC는 자체 인터넷 게이트웨이나 NAT를 구성해야 합니다. 김개발 씨가 정리했습니다. "결국 VPC가 3-4개 이상이고 모두 통신해야 한다면 Transit Gateway가 낫겠네요." 박시니어 씨가 끄덕였습니다. "맞아요. 피어링은 간단한 1:1 연결에 적합하고, 복잡한 네트워크는 Transit Gateway가 더 효율적이에요." VPC 피어링의 한계를 이해하면 올바른 아키텍처 결정을 내릴 수 있습니다. 프로젝트 요구사항에 맞는 네트워킹 솔루션을 선택하세요. **실전 팁** 💡 - 3개 이상 VPC를 모두 연결해야 한다면 Transit Gateway를 검토하세요 - 교차 리전 피어링에서는 보안 그룹 ID 대신 CIDR로 규칙을 설정해야 합니다 - DNS 확인 옵션은 피어링 연결 설정에서 명시적으로 활성화해야 합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS,VPC,Network

언어: Python

태그: AWS, VPC, Peering, Network, PrivateLink, AWS,VPC,Network

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

VPC 피어링으로 VPC 간 프라이빗 통신 완벽 가이드

목차

1. VPC 피어링의 개념과 사용 사례

2. 동일 리전 vs 교차 리전 피어링

3. 피어링 연결 생성 및 수락

4. 라우팅 테이블 양방향 설정

5. CIDR 중복 문제 해결

6. 피어링 제약사항과 한계

댓글 (0)

함께 보면 좋은 카드 뉴스

대규모 트래픽을 위한 확장 가능한 아키텍처 완벽 가이드

AWS Organizations로 멀티 계정 거버넌스 구축

멀티 리전 아키텍처로 글로벌 서비스 설계

Transit Gateway 피어링으로 글로벌 네트워크 구축

Transit Gateway로 복잡한 네트워크 중앙 집중화 완벽 가이드