☑️ Keynote

세션명	A modern approach to application migration with Amazon VPC Lattice
세션코드	NET309
발표일자	2025.12.03
강연자	Jamie wenzel, Yecine allouache, Ryan j mcdonough
키워드	1. Amazon VPC Lattice 2. Application Networking (L7 기반 연결) 3. 정책 기반 보안 (IAM + Service Policies) 4. 점진적 현대화 (Monolith → Containers/EKS) 5. Cross-VPC·Cross-Account 통합(Overlapping CIDR/IPv6 포함)
핵심 내용 및 요약	ㆍ네트워크 단순화: VPC·계정·리전 간 복잡한 L3 네트워킹(PrivateLink, VPN, TGW, IP 중복 등)을 Lattice가 L7 서비스 기반으로 자동 연결·해결. . 정책 기반 보안: IAM + Lattice 정책으로 경로·메서드·서비스 단위 접근 제어를 구현해 파트너·온프레미스·인수 기업 간 통신을 안전하게 통합. . 점진적 현대화: 기존 모놀리식/EC2 환경과 신규 컨테이너·EKS 서비스를 동시에 운영하며 트래픽 분할로 무중단 전환 가능. . 확장성과 운영 효율: 리소스 게이트웨이·서비스 네트워크로 사내 서비스·PrivateLink·온프레미스를 일관되게 제공해 대규모 조직에서도 관리 비용 감소 및 개발자 경험 개선.

1. 세션 개요

기존 복잡한 네트워크/애플리케이션 환경을 현대화하기 위해 Amazon VPC Lattice가 어떤 문제를 해결하며, 실제 기업(Goldman Sachs)이 이를 어떻게 적용했는지를 소개했습니다. 주요 목표는 서버·네트워크 아키텍처의 점진적·안전한 현대화입니다.

2. 기존 환경 속 문제점 (Starting Landscape)

현실의 기업 IT 환경에서 나타나는 공통 문제들이 있습니다.

2-1. 복잡한 연결 구조
파트너사는 VPN으로 연결되어 있고, 인수 기업은 양방향 PrivateLink로 연결되어 있으며, 일부 서비스는 IPv6를 요구하고, 온프레미스 메인프레임은 Direct Connect + Transit Gateway로 연결, 백엔드는 모놀리식 EC2 기반 등으로 혼재되어 있습니다. 이로 인해 네트워크가 복잡하고, 서비스 확장·변경 시 운영 부담이 매우 큽니다.

2-2. 마이그레이션 및 변경의 어려움
파트너는 IP 변경, 권한 조정 등 ADD/MOVE/CHANGE 이벤트마다 큰 부담이 되고, PrivateLink 확장성 제약(NLB Listener 최대 50 등)이 있습니다. IPv4 → IPv6 변환(NAT64 등) 모델은 규모가 커지면 병목이 발생하며, 메인 프레임에서 AWS 특정 서비스로만 통신 제한이 필요합니다. On-prem DB에 인수 기업이 접근해야 하지만 Direct Connect를 따로 운영 중입니다.

2-3.애플리케이션 현대화 요구
기존 백엔드를 모놀리식 컨테이너(EKS) 로 재구성해야 하지만 네트워크 구조가 복잡해 전환 과정에서 위험이 증가합니다.

3. Amazon VPC Lattice 개요

VPC Lattice는 L7 기반(Application-level) 서비스 간 연결·보안·관찰성을 제공하는 Application Networking 서비스입니다.

3-1. 주요 특징
• VPC/계정/리전 간 서비스 단위(Service) 연결
• Overlapping CIDR 대응 가능 (서비스 DNS가 link-local ENI로 매핑됨)
• IPv4·IPv6 상호 통신 문제 제거
• IAM 기반 접근 정책
• PrivateLink·TGW·Direct Connect와 공존 가능

3-2. 구성 요소
• Service: 애플리케이션을 노출하는 논리 그룹
• Resource / Resource Configuration: DB, DNS 이름, IP 등을 서비스로 노출
• Service Network: 서비스들이 연결되는 공간
• Provider / Consumer 모델
• Service Network Endpoint: 온프레미스·EC2 등에서 Lattice 서비스로 진입하는 엔드포인트

4. Lattice를 활용한 단계적 현대화 전략 (Step-by-Step Modernization)

4-1. 파트너 VPN 개선
• 기존 VPN 유지 → Lattice Service Network 추가
• 파트너 서비스와 Front Door 서비스 간에는 IAM 기반 토큰 정책으로 인증
• 기존 Firewall 역할을 Lattice 정책이 대체
• 변경 위험 없이 점진적 도입 가능

4-2. 정책 계층 구조
• Service Network Policy: 조직 단위 coarse-grained 제어
• Service Policy: HTTP method·경로별 fine-grained 제어
• 리소스가 네트워크 전체에 노출될 때, 서비스 정책과 조합해 권한 제어

4-3. 인수 기업(Overlapping IP)의 복잡성 제거
• Lattice는 DNS가 link-local(169.254.x.x) ENI로 매핑되므로 CIDR 중복 문제를 완전히 해소
• 기존 양방향 PrivateLink 구조를 Lattice로 통합
• 정책 기반으로 상호 통신 제어

4-4. IPv6 통신 단순화
• 기존 NAT64/Private NAT Gateway 등 제거
• IPv4 ↔ IPv6도 DNS/Lattice 레벨에서 자동 처리
• 별도 변환 장비 없이 Lattice 서비스로 간단히 연결

4-5. 온프레미스(Mainframe) 연결 현대화 (Hybrid)
• Direct Connect / TGW는 유지
• VPC 내부에 Service Network Endpoint 배치하여 Lattice로 유입
• 메인프레임은 백엔드 서비스에만 접근하도록 정책 제어
• 네트워크 hop을 최소화한 단일 제어 포인트 확보

4-6. 모놀리식 → 컨테이너(EKS) 현대화
• 기존 백엔드를 유지한 채 새로운 VPC/EKS 생성 가능
• Lattice에서 트래픽 비율(예: 60/40 등) 로 점진적 전환
• 무중단 업그레이드 가능
• 네트워크 설정을 반복적으로 바꿀 필요 없음

4-7. 인수 기업의 온프레미스 DB 접근 문제 해결
• Resource Gateway + Resource Configuration 사용
• 온프레미스 DB를 서비스처럼 Lattice에 노출
• 인수 기업은 Direct Connect를 공유하면서도 → DB외 다른 리소스는 접근 불가 (정책으로 제한)
• 별도 Direct Connect 연결 제거 가능

5. 최종 현대화 아키텍처의 모습

모든 서비스(파트너, 인수기업, 백엔드, IPv6, 하이브리드)가 Lattice Service Network를 통해 통신 네트워크 복잡성 제거, 보안·정책·관찰성을 중앙 집중화, 애플리케이션 현대화를 지속적으로 수행할 수 있는 구조 확보했습니다.

6. Goldman Sachs 실제 사례 (FastTrack 플랫폼)

6-1. 기존 Shared VPC 모델의 한계
• IP 고갈(CIDR 고정)
• Inoisy neighbor
• IEndpoint 정책이 계정마다 달라져 관리 난이도↑
• IVPC 자체 변경이 ‘one-way door’라 마이그레이션 비용 큼

6-2. Lattice 도입 후 변화
• 각 애플리케이션 계정이 자신만의 VPC 사용
• 공통 서비스(SDLC, HR, ID 등)는 Resource Configuration + Shared Service Network로 제공
• PrivateLink와 Lattice를 조합하여 → 1:N 서비스 공유 구조를 단순화
• 서비스 네트워크만 연결하면 → 개발자가 VPC를 새로 만들었을 때도 자동으로 필요한 서비스 접근 가능
• 강력한 격리 + 단순한 개발자 경험 + 네트워크 확장성 확보