Oracle Database@AWS 네트워크 구성 가이드

Oracle Database@AWS(ODB@AWS)는 AWS 데이터센터 내에 위치한 Oracle Exadata 인프라에서 Oracle Database를 네티브로 실행할 수 있게 해주는 서비스입니다. Oracle MAA Platinum 인증을 획득하였으며, 애플리케이션-데이터베이스 간 RTT(Round Trip Time) 165μs의 초저지연을 달성하여 미션 크리티컬 워크로드에 적합한 성능을 제공합니다.

그러나 ODB@AWS는 기존 AWS 서비스와는 다른 고유한 네트워크 토폴로지를 가지고 있어, 엔터프라이즈 환경에서의 네트워크 설계 시 특별한 고려가 필요합니다. 특히 금융권과 같이 다수의 VPC를 운영하고, 온프레미스 연결이 필수적이며, 높은 TPS(Transactions Per Second)를 요구하는 환경에서는 더욱 그렇습니다.

본 포스팅에서는 Oracle Database@AWS 도입 시 Transit Gateway(TGW)를 활용한 허브앤스포크 네트워크 아키텍처를 설계하는 방법과, 네트워크 구성 시 반드시 알아야 할 주요 고려사항들을 소개합니다.

Oracle Database@AWS 네트워크의 주요 특성

ODB Network란?

ODB@AWS의 네트워크를 이해하기 위해서는 먼저 ODB Network라는 고유한 구성 요소를 알아야 합니다. ODB Network는 AWS 가용영역(Availability Zone) 내에 OCI(Oracle Cloud Infrastructure) 인프라를 호스트하는 프라이빗 격리 네트워크입니다. Oracle Exadata 인프라와 VM 클러스터가 이 네트워크 내에 존재하며, Amazon VPC의 애플리케이션은 ODB Peering을 통해 데이터베이스 리소스에 프라이빗하게 접근합니다.

주요 네트워크 특성

2026년 주요 업데이트: Multi-VPC ODB 피어링

2026년 2월 19일부터 하나의 ODB Network에서 최대 45개의 ODB 피어링 연결을 지원합니다. 이전에는 하나의 ODB Network에 단일 VPC만 직접 피어링할 수 있었기에 ODB Network와 복수개의 VPC 연결을 위해서는 Transit Gateway가 필수였으나, 이제는 여러 Application VPC에서 동일 ODB Network에 직접 피어링할 수 있습니다.

이 변경으로 인해 복수의 네트워크 아키텍처 설계 시 다음과 같은 선택지를 환경에 맞게 고려하실 수 있습니다:

• 직접 Multi-VPC 피어링: 가장 간단하고 직접적인 연결 → 추가 라우팅 레이어 불필요
• Transit Gateway 허브앤스포크: 중앙 집중식 라우팅, 온프레미스 연결, 방화벽 검사가 필요한 경우

CIDR 설계 시 고려사항

• 클라이언트 서브넷: 최소 /27, Oracle 권장 /24 (향후 확장 고려)
• 백업 서브넷 (Autonomous Database 선택사항): 최소 /28
• CIDR 블록은 AWS VPC 서브넷, OCI VCN, 온프레미스 네트워크와 겹치지 않아야 함
• Exadata X9M 사용 시 100.106.0.0/16 및 100.107.0.0/16 범위는 예약됨
• CIDR 범위는 생성 후 변경할 수 없으므로 사전에 충분한 IP 계획 필요
• Multi-VPC 피어링 시, 피어링된 모든 VPC의 CIDR도 상호 중복되면 안 됨

IP 주소 예약 규칙

ODB Network 내부에서는 다음과 같은 IP 주소가 자동 예약됩니다:

• ODB 서비스용: 6개 IP (AWS 리소스 3개 + OCI 네트워킹 3개)
• VM 클러스터당 SCAN용: 3개 IP
• VM당: 4개 IP
• 백업 서브넷: 서비스용 3개 + VM당 3개

네트워크 연결 옵션 비교

ODB@AWS는 다양한 네트워크 연결 옵션을 제공합니다. 엔터프라이즈의 환경에 맞게 적합한 옵션을 선택하실 수 있습니다.

엔터프라이즈 AWS 고객의 주요 아키텍처: Transit Gateway 허브앤스포크 구성

배경 및 요구사항

엔터프라이즈 AWS 고객은 주로 다음과 같은 요구사항을 가지고 있습니다:

• 온프레미스(IDC) 연결 필수: 마이그레이션 기간 동안 IDC의 기존 시스템에서 ODB@AWS의 Oracle Database에 접근 필요
• 다수의 VPC 연결: 여러 서비스 VPC에서 Oracle DB에 접근 필요
• 중앙 집중식 라우팅 관리: 기존 TGW 기반 네트워크 인프라 및 GWLB 아웃바운드 통제 영역 활용
• 엔터프라이즈 규제 준수: 네트워크 보안 정책의 일관된 적용
• 고성능: 15,000 TPS 이상의 처리 성능 목표

Multi-VPC 직접 피어링이 가능해졌음에도 불구하고, 대부분의 엔터프라이즈 고객은 온프레미스 연결 요건과 중앙 집중식 네트워크 관리 필요성으로 인해 Transit Gateway 기반 허브앤스포크 아키텍처가 필요할 수 있습니다. 이는 Oracle A-Team과 AWS에서도 엔터프라이즈 환경의 주요 연결 패턴으로 권장하는 구성입니다. (위 ‘네트워크 연결 옵션 비교’를 참고하여 무엇보다 지연시간 및 TGW 데이터 처리 비용 제거가 중요한 워크로드의 경우는 Application VPC와 다이렉트로 ODB Peering을 통해 연결이 필요합니다.)

아키텍처 구성 요소

사용된 CIDR는 이해를 돕기 위한 예시입니다.

핵심 설계 원칙

원칙 1: TGW Attachment의 가용영역 정렬

해당 아키텍처에서 가장 중요한 설계 원칙입니다.

Application VPC의 워크로드는 여러 AZ에 분산될 수 있지만, Transit VPC의 TGW Attachment는 ODB Network가 위치한 AZ에만 생성합니다:

원칙 2: 라우팅 설정 순서 준수

Oracle의 Transit Gateway Connectivity 설정 가이드에서 강조하는 핵심 주의사항입니다 (같은 구성으로 구축하시는 경우, 링크의 블로그를 참고하여 순서대로 구축하시는 것을 권장합니다.)

이 단계(라우팅 설정)는 Transit VPC의 VPC 경로, 특히 TGW 경로가 설정된 후에 수행해야 합니다. Transit VPC에서 Transit Gateway를 가리키는 경로의 일부가 아닌 서브넷에 대해 피어링된 CIDR을 추가하면 ODB가 “실패” 상태가 될 수 있습니다.”

[순서 반드시 준수] Transit VPC에서 TGW 방향의 라우트를 먼저 설정한 후에 ODB Peering의 Peered CIDRs를 추가해야 합니다:

• Step 1: Transit VPC 라우트 테이블에 TGW 방향 라우트 설정 완료
  • 
• Step 2: ODB Peering에서 Peered CIDRs 추가
  • 

원칙 3: Transit VPC의 단일 Transit 서비스 제약

Transit VPC는 단 하나의 Transit Gateway 또는 AWS Cloud WAN과만 연동 가능합니다. 기존에 TGW가 구성된 환경이라면 해당 TGW를 그대로 활용해야 합니다.

VPC 라우팅 구성 상세

ODB Network로의 라우트 설정

피어링된 VPC(Transit VPC)에서 ODB Network로의 라우트는 AWS CLI 또는 AWS 콘솔을 통해서 추가하실 수 있습니다:

• CLI를 통한 라우트 추가

  • aws ec2 create-route \
      --route-table-id <route-table-id> \
      --destination-cidr-block 10.200.0.0/24 \
      --odb-network-arn arn:aws:odb:<region>:<aws-account-id>:odb-network/<odb-network-id>

• 콘솔을 통한 라우트 추가
  • 

Transit Gateway 라우트 테이블 설계

Transit VPC 라우트 테이블

DNS 구성: 하이브리드 DNS 아키텍처

배경

ODB@AWS에서 Oracle Database에 접근하려면 Oracle의 SCAN(Single Client Access Name) Listener 주소에 대한 DNS 해석이 필요합니다. ODB Network의 DNS Listener IP는 OCI 측에서 관리되므로, AWS 환경에서 이를 해석하기 위한 하이브리드 DNS 구성이 필수적입니다.

DNS 구성 요소 및 쿼리 흐름

구성 단계별 가이드

아래는 Transit Gateway 기반 허브앤스포크 아키텍처의 구성 단계를 요약하여 정리한 것입니다. 자세한 구현은 해당 링크를 참고하실 수 있습니다.

Step 1: ODB Network 생성

aws odb create-odb-network \
  --display-name "my-prod-odbn" \
  --availability-zone-id "<availability-zone-id>" \
  --client-subnet-cidr "<client-subnet-cidr>" \
  --backup-subnet-cidr "<backup-subnet-cidr>"

Step 2: Transit VPC 및 TGW Attachment 구성

Transit VPC를 생성하고, ODB Network와 동일한 AZ에 TGW Attachment를 생성합니다.

Step 3: Transit VPC 라우트 테이블 설정

Application VPC 및 온프레미스 대역에 대한 TGW 방향 라우트를 설정합니다. 이 단계가 반드시 먼저 완료되어야 합니다.

Step 4: ODB Peering 생성 및 Peered CIDRs 추가

ODB Network와 Transit VPC 간 ODB Peering을 생성하고, Peered CIDRs를 추가합니다.

Step 5: ODB Network 방향 라우트 추가 (CLI)

aws ec2 create-route \
  --route-table-id <route-table-id> \
  --destination-cidr-block <odb-client-subnet-cidr> \
  --odb-network-arn arn:aws:odb:<region>:<aws-account-id>:odb-network/<odb-network-id>

Step 6: DNS Forwarding Rule 설정

Route 53 Resolver Outbound Endpoint를 생성하고, *.oraclevcn.com 도메인에 대한 Forwarding Rule을 OCI DNS Listener IP로 구성합니다.

Step 7: 연결성 검증

마지막으로 아래 명령어를 통해 Application이 있는 서버에서 Oracle DB와의 연결성을 확인합니다.

# DNS 해석 확인
nslookup scan-listener.subnet1.vcn1.oraclevcn.com
# Oracle DB 연결 테스트 (1521 포트)
sqlplus user/password@//scan-listener.subnet1.vcn1.oraclevcn.com:1521/service_name
# 레이턴시 측정 (Placement Group 적용 후)
qperf <odb-vm-ip> tcp_lat

[참고 #1] 아키텍처 선택 가이드

Multi-VPC 직접 피어링 vs Transit Gateway: 언제 어떤 것을 선택할까?

[참고 #2] 구성 전 체크리스트

• ODB Network 가용영역(AZ) 결정 및 확인
• Transit VPC TGW Attachment가 동일 AZ에 위치하는지 확인
• CIDR 범위 충돌 여부 확인 (VPC, ODB, OCI VCN, 온프레미스 — 모든 피어링 대상 포함)
• Transit VPC 라우트 테이블에 TGW 방향 라우트 설정 완료 확인
• ODB Peering에서 Peered CIDRs 추가 (라우트 설정 완료 후)
• ODB Network ARN 확보 (CLI 라우트 설정용)
• Route 53 Forwarding Rule 설정 및 DNS 해석 확인
• Security Group/NSG에서 Oracle 포트(1521) 허용 확인
• (선택) High Performance Networking Placement Group 적용
• Application VPC에서 End-to-End 연결 테스트 완료

[참고 #3] High Performance Networking 활용

2026년 4월부터 ODB@AWS는 High Performance Networking을 지원합니다. 이 기능은 EC2 Placement Group을 활용하여 애플리케이션 인스턴스를 Oracle Exadata 인프라와 물리적으로 가까운 위치에 배치함으로써 일관된 sub-millisecond 네트워크 RTT를 제공합니다.

High Performance Networking(HPN)은 Application VPC의 EC2 Placement Group ↔ ODB Network 간의 초저지연 네트워크 연결을 위해 제공되는 기능입니다. “직접 “ODB 피어링” 구성이 기본 전제입니다. TGW를 통한 허브앤스포크 구성은 네트워크 홉이 추가되므로 목적에 맞지 않습니다.

작동 방식

• ODB Network 생성 시 Placement Group이 자동으로 프로비저닝됨
• EC2 인스턴스 실행 시 해당 Placement Group을 지정하면 최적 위치에 배치
• 추가 비용 없음 (표준 EC2 요금만 적용)

구성 방법

# Step 1: ODB Network의 Placement Group ID 확인
aws odb get-odb-network --odb-network-id <odb-network-id> \
  --query 'odbNetwork.ec2PlacementGroupIds'
# Step 2: EC2 인스턴스 시작 시 Placement Group 지정
aws ec2 run-instances \
  --placement GroupId=pg-0e6faa731d3df801e \
  --instance-type r6i.large \
  --subnet-id <app-subnet-in-same-az> \
  ...

결론

본 포스팅에서는 Oracle Database@AWS 도입 시 Transit Gateway 기반 허브앤스포크 네트워크 아키텍처를 설계하고 구성하는 방법을 소개했습니다.

Oracle Database@AWS의 네트워크는 2026년 들어 빠르게 진화하고 있습니다. Multi-VPC 피어링(최대 45개), High Performance Networking, VPC Lattice 통합 등 다양한 연결 옵션이 추가되면서 아키텍처 선택의 폭이 넓어졌습니다. 그럼에도 불구하고, 온프레미스 하이브리드 연결과 중앙 집중식 네트워크 관리가 필요한 엔터프라이즈 환경에서는 Transit Gateway를 활용한 허브앤스포크 아키텍처가 여전히 핵심 패턴입니다.

네트워크 구성 시 다음의 핵심 사항을 반드시 준수해야 합니다:

• TGW Attachment를 ODB Network와 동일한 가용영역에 생성할 것
• Transit VPC 라우트 설정을 완료한 후에 Peered CIDRs를 추가할 것 (순서 위반 시 “Failed” 상태)
• 하이브리드 DNS 구성을 통해 Oracle SCAN Listener 접근을 보장할 것
• 레이턴시에 민감한 워크로드는 Application VPC에서 직접 ODB Peering을 구성하고, High Performance Networking(Placement Group)을 함께 적용하여 sub-millisecond 레이턴시를 확보할 것

본 가이드가 Oracle Database@AWS 도입을 검토하고 있는 기업 및 조직의 네트워크 아키텍처 설계에 실질적인 도움이 되기를 바랍니다.

참고 자료

• Advanced Connectivity Patterns for ODB@AWS (Oracle A-Team, 2026.06)
• Oracle Database at AWS Networking Update: One ODB Network, Multiple VPC Peers (Oracle A-Team, 2026.03)
• Getting started with the Oracle Database@AWS high performance networking (AWS, 2026.04)
• Oracle Database@AWS network connectivity using Amazon VPC Lattice (AWS, 2025.07)
• Implement network connectivity patterns for Oracle Database@AWS (AWS, 2025.09)
• Configure the DNS resolution for Oracle Database at AWS (Oracle A-Team)
• Oracle DB@AWS TGW 구성 가이드 (Oracle A-Team)
• ODB Network Design (Oracle Docs)
• Topologies for Oracle AI Database@AWS (Oracle Docs)