TransitGateway 멀티어카운트
Update: 2024-07-28
1.Transit Gateway MultiAccount 연결
개요
Transit Gateway MultiAccount 연결은 AWS Transit Gateway를 사용하여 여러 AWS 계정에 걸쳐 있는 VPC(Virtual Private Cloud)를 중앙 집중식으로 관리하고 연결할 수 있는 기능입니다. 이 기능은 복잡한 네트워크 토폴로지를 단순화하고, 다양한 계정의 리소스 간에 효율적인 통신을 가능하게 합니다.
주요 개념
1/ Transit Gateway: AWS Transit Gateway는 여러 VPC, AWS 계정, 및 온프레미스 네트워크를 연결하는 네트워크 허브 역할을 합니다. 중앙 허브를 통해 트래픽을 라우팅하여, 각 네트워크가 독립성을 유지하면서도 통신할 수 있도록 합니다.
2/ MultiAccount: 여러 AWS 계정이 VPC를 소유하고 있을 때, Transit Gateway를 사용하여 이러한 계정의 VPC를 통합된 방식으로 연결하고 관리할 수 있습니다. 이는 큰 조직이나 여러 비즈니스 유닛을 갖춘 기업에서 유용합니다.
3/ Transit Gateway Attachments: 각 VPC나 VPN 연결은 Transit Gateway에 연결되어야 하며, 이를 Attachment라고 부릅니다. MultiAccount 시나리오에서는 각 계정의 VPC가 Transit Gateway에 연결됩니다.
4/ Resource Access Manager (RAM): AWS RAM을 사용하여 다른 계정과 리소스를 안전하게 공유할 수 있습니다. Transit Gateway는 RAM을 통해 여러 계정 간에 공유될 수 있습니다.
구성 요소 및 작동 방식
1/ Centralized Transit Gateway: 한 계정에서 Transit Gateway를 생성하고, 다른 계정의 VPC가 이 Transit Gateway에 연결되도록 구성합니다. 이를 통해 중앙에서 네트워크 정책과 라우팅을 관리할 수 있습니다.
2/ Route Tables: Transit Gateway의 라우트 테이블은 연결된 VPC 간의 트래픽 흐름을 제어합니다. MultiAccount 환경에서는 각 계정의 VPC에서 들어오는 트래픽을 적절한 대상지로 라우팅하기 위해 라우트 테이블을 설정합니다.
3/ Security and Access Control: VPC 간 트래픽이 Transit Gateway를 통해 흐르기 때문에, 보안 그룹 및 네트워크 ACL을 통해 접근 제어를 강화할 수 있습니다. 또한, AWS RAM을 통해 공유된 리소스에 대한 액세스 권한을 세밀하게 관리할 수 있습니다.
MultiAccount 연결의 이점
1/ 중앙 집중식 관리: 네트워크 정책과 라우팅 규칙을 중앙에서 관리하여 운영 복잡성을 줄일 수 있습니다.
2/ 비용 효율성: 다수의 개별 연결을 줄이고, 중앙의 Transit Gateway를 사용하여 네트워크 아키텍처를 단순화함으로써 비용을 절감할 수 있습니다.
3/ 보안 강화: 중앙 허브를 통해 트래픽을 라우팅함으로써 보안 정책을 쉽게 적용하고 모니터링할 수 있습니다.
구현 고려사항
1/ 계정 간 신뢰 관계 설정: 리소스 공유와 보안을 위해 계정 간 신뢰 관계를 설정해야 합니다.
2/ 네트워크 설계: 트래픽 흐름을 최적화하고 보안 요구 사항을 충족하는 네트워크 설계가 필요합니다.
3/ 비용 분석: Transit Gateway의 데이터 처리 및 각 VPC 간 데이터 전송 비용을 고려하여 경제적으로 설계해야 합니다.
이 LAB에서는 빌더스 컴퍼니와 협력사인 서밋 컴퍼니는 상호간에 Transit Gateway Peering을 RAM(Resource Access Manager)를 통해서 간단하게 연결할 수 있는 디자인을 제공하고 있습니다.
서울 리전안에서 2개의 계정간에 협력을 위해 연결하는 과정을 소개합니다.
2. RAM (Resource Access Manager) 소개
AWS Resource Access Manager (RAM)는 AWS 계정 또는 AWS 조직 내에서 AWS 리소스를 쉽고 안전하게 공유 할 수있는 서비스입니다. AWS Transit Gateway, 서브넷, AWS License Manager 구성 및 Amazon Route 53 Resolver 규칙 리소스를 RAM과 공유 할 수 있습니다.
많은 조직은 관리 또는 비용처리에 대한 부분에 대해 상호간의 영향 제한하기 위해 여러 계정을 사용합니다. RAM을 사용하면 여러 계정에 중복 리소스를 만들 필요가 없으므로 소유 한 모든 단일 계정에서 해당 리소스를 관리하는 운영 오버 헤드가 줄어 듭니다. 여러개 계정 환경에서 중앙 집중식으로 리소스를 생성하고 RAM을 사용하여 리소스 공유 생성, 리소스 지정 및 계정 선이라는 세 가지 간단한 단계로 계정간에 해당 리소스를 공유 할 수 있습니다. RAM은 추가 비용없이 사용할 수 있습니다.
주요 기능 및 특징
1/ 리소스 공유: AWS RAM을 사용하면 VPC, 서브넷, Transit Gateway, 라이센스 매니저 설정 등 다양한 리소스를 다른 AWS 계정 또는 AWS 조직 내의 계정과 공유할 수 있습니다.
2/ 중앙 관리: 조직의 중앙 계정에서 리소스를 생성하고 관리할 수 있으며, 필요에 따라 이를 다른 계정에 공유하여 각 계정이 이를 사용하게 할 수 있습니다. 이는 중앙 집중식 네트워크 및 리소스 관리에 도움이 됩니다.
3/ 세밀한 액세스 제어: IAM 역할 및 정책을 사용하여 리소스에 대한 액세스를 세밀하게 제어할 수 있습니다. 이를 통해 각 계정의 사용자 및 서비스가 필요한 리소스에만 접근하도록 제한할 수 있습니다.
4/ 조직과의 통합: AWS Organizations와 통합되어, 조직 단위로 리소스를 공유할 수 있습니다. 이를 통해 여러 계정 간의 리소스 관리가 더욱 쉬워집니다.
5/ 리소스 유형 지원: AWS RAM은 다양한 AWS 리소스를 지원하며, 이를 통해 네트워크 리소스(예: 서브넷, VPC), 보안 리소스(예: AWS License Manager), 데이터 리소스(예: AWS Glue Data Catalog) 등을 공유할 수 있습니다.
사용 사례
1. 중앙 집중식 VPC 관리: 조직의 네트워크 관리를 중앙에서 통제하기 위해, 하나의 계정에서 VPC와 서브넷을 생성하고 이를 여러 계정과 공유할 수 있습니다.
2. 공동 라이선스 관리: AWS License Manager와 통합하여 라이선스를 중앙에서 관리하고, 조직 내의 여러 계정과 라이선스를 공유하여 비용을 절감하고 효율성을 높일 수 있습니다.
3. 데이터 공유: AWS Glue Data Catalog와 통합하여 데이터 자산을 여러 계정과 공유하고, 중앙에서 데이터 거버넌스를 관리할 수 있습니다.
설정 관리 및 보안 접근제어 소개
AWS RAM은 AWS Management Console, AWS CLI, 또는 AWS SDK를 통해 설정하고 관리할 수 있습니다. 공유를 설정할 때는 공유할 리소스와 이를 사용할 수 있는 계정 또는 조직을 지정합니다. 또한, 각 계정은 제공된 리소스를 승인하고 사용할 수 있도록 설정해야 합니다.
리소스에 대한 접근 제어는 AWS IAM 정책을 통해 관리됩니다. 이를 통해 각 리소스에 대한 액세스를 세밀하게 조정할 수 있으며, 권한 있는 사용자만이 리소스에 접근하도록 보장할 수 있습니다.
AWS RAM을 사용하면 여러 계정 간의 리소스 관리가 단순화되고, 비용 절감 및 관리 효율성을 높일 수 있습니다. 이를 통해 복잡한 클라우드 환경에서 중앙 집중식 관리와 협업을 지원할 수 있습니다.
구성 아키텍쳐 소개
TransitGateway 구성하기에서 생성한 빌더스 컴퍼니의 Transit Gateway를 동일한 서울 리전, 다른 어카운트(서밋 컴퍼니) Seoul-VPC-PART VPC에서 사용하려고 하는 목표 구성입니다.
AWS RAM(Resource Access Manager)를 이용하여 빌더스 컴퍼니의 Transit Gateway를 연계해서, 협력사인 서밋 컴퍼니 자원을 사용해 봅니다.
2.서로 다른 계정에서 TGW 연동
Task 1. VPC 구성하기
새로운 계정에 접속 하고, Cloudformation을 통해 기본이 되는 VPC구성을 먼저 구성합니다.
1.사전 준비하기
사전 준비 단계를 새로운 계정에서도 다시 수행합니다.
2.Cloudformation 생성.
서밋 컴퍼니는 서울리전에서 새로운 계정의 Seoul-VPC-PART라는 이름으로 VPC를 생성합니다.
Seoul-VPC-PART 를 Cloudformation 을 기반으로 생성합니다.
Cloud9에서 아래와 같이 수행하여, 배포 합니다.
Seoul-VPC-PART 배포
정상적으로 구성되면 아래와 같이 Cloudformation에서 확인 할 수 있습니다. VPC는 각 3분 내외에 생성됩니다.
서밋 컴퍼니 계의 번호를 복사해 둡니다. RAM 구성시 계정 정보가 필요합니다.
Task 2. RAM 구성하기
이제 다시 빌더스 컴퍼니 계정에서 수행합니다.
빌더스 컴퍼니에서 생성된 TGW를 서밋 컴퍼니에게 제공할 것입니다. 반드시 RAM 구성은 리소스 제공하는 계정에서 실행합니다.
AWS 관리콘솔에서 RAM 을 선택하고, 새로운 윈도우 창을 오픈합니다.
빌더스 계정 - AWS 콘솔 - RAM
Resource Access Manager - 내가 공유: 리소스 공유 에서 "리소스 공유 생성" 을 선택합니다.
아래와 값을 입력합니다.
이름 - "리소스 공유 이름" 을 입력합니다.
리소스 유형 선택 - 전송 게이트웨이 (Transit Gateway)를 선택하고, 생성해 놓은 TGW를 선택합니다.Principal - 외부 계정허용 을 선택합니다. 앞서 새롭게 Seoul-VPC-PART VPC 자원이 생성된 계정의 번호를 입력합니다. (앞서 복사해 둔 서밋 컴퍼니의 계정입니다.)
Step1. 리스스 공유 세부 정보 지정
리소스 공유를 확인하고, 생성한 리소스 공유를 선택합니다.
Step2. 권한을 각 리소스 유형과 연결
Step3. 액세스 할 수 있는 보안 주체 선택 - TransitGateway 자원을 연결할 다른 계정을 입력하고, "추가"를
합니다. 선택한 보안 주체에 해당 계정이 정상적으로 입력되었는 지 확인합니다. Associating 단계로 진행 중인 것을 확인 할 수 있습니다.
공유 리소스가 "Associated" 되었는지 확인합니다. 공유한 프린시펄에서 Associated 단계가 되도록 새로 만든 계정에서 RAM 에서 수락해야 합니다.
이제 공유를 확인하기 위해, 협력사인 서밋 컴퍼니 계정 콘솔로 이동해서 RAM으로 이동합니다.
서밋 컴퍼니 - AWS 계정 - RAM 을 선택합니다.
리소스 공유에 초대 알람이 생성된 것을 확인 할 수 있습니다. 리소스 공유를 선택합니다.
해당 리소스 공유를 선택하면, 리소스 공유 수락을 대기하고 있는 것을 확인 할 수 있습니다. 공유된 리소스 Seoul-TGW 를 선택합니다.
리소스 공유 수락을 선택합니다.
AWS 계정 - VPC - TransitGateway에 빌더스 컴퍼니 계정의 Seoul-TGW가 나타납니다.
Task 3. TGW 연동하기
서밋 컴퍼니 계정에서 Transit Gateway Attachment를 생성하기 위해, VPC - Transit Gateway - Transit Gateway 연결을 선택해서 새로운 Attachment를 생성합니다.
Transit Gateway ID : 공유된 TGW
Attachment name tag : Attachment 이름 (Seoul-TGW-Attach-Seoul-VPC-PART)
VPC ID : 서밋 컴퍼니의 VPC 선택 (Seoul-VPC-PART)
Subnet : TGW ENI가 연결된 서브넷 선택 (Seoul-VPC-TGWSubnetA, Seoul-VPC-TGWSubnetB)
VPC - Transit Gateway - Transit Gateway attachment 연결 에서 정상적으로 구성되었는지 확인합니다 .
빌더스 계정에서 서밋 계정의 TGW 라우팅 테이블 Association을 수행합니다.
TGW와 Routing Table 자원은 모두 빌더스 컴퍼니 계정 소유 입니다. 따라서 Assocation, Routing Table 구성은 빌더스 계정에서 수행합니다.
이제 다시 빌더스 계정으로 이동합니다.
빌더스 계정 - AWS 콘솔 - VPC- Transit Gateway - Transit Gateway 라우팅 테이블에서 "Seoul-TGW-RT-East-To-West" 테이블을 선택합니다. 새롭게 추가된 서밋 컴퍼니 계정의 Transit Gateway Attachment를 선택하고 추가합니다.
AWS 콘솔 - VPC- Transit Gateway - Transit Gateway 라우팅 테이블 - "Seoul-TGW-RT-East-To-West" - Associations Tab 를 선택합니다. 정상적으로 Association 되었는지 확인합니다.
AWS 콘솔 - VPC- Transit Gateway - Transit Gateway 라우팅 테이블 - Propagations(전파) Tab 을 선택하고, 서밋 컴퍼니의 Seoul-VPC-PART 를 propagation(전파) 합니다.
AWS 콘솔 - VPC- Transit Gateway - Transit Gateway 라우팅 테이블 - Propagations(전파) Tab 을 선택하고, 정상적으로 Propagation(전파) 되었는지 확인합니다.
AWS 콘솔 - VPC- Transit Gateway - Transit Gateway 라우팅 테이블 - Route Tab 을 선택고, 정상적으로 Route가 추가되었는지 확인합니다.
서밋 컴퍼니 계정에서 SEOUL-VPC-PRT-Private-10.4.21.101 을 접속합니다.
서밋 계정에도 (신규 계정) Code Server 터미널에서, 아래와 같이 Seoul-VPC-PART-Private-10.4.21.101 인스턴스 id를 조회합니다.
Seoul-VPC-PART-Private-10.4.21.101 인스턴스에 접속합니다.
아래 명령어를 통해 Seoul-VPC-DEV,STG 의 인스턴스로 연결이 가능한지 확인합니다.
이제 Seoul-VPC-PART에서 Seoul-VPC-DEV, Seoul-VPC-STG로 통신을 하기 위해, 10.0.0.0/8의 목적지를 Transit Gateway로 추가합니다.
Seoul-VPC-PART에서 Seoul-VPC-PRD 로도 접근이 가능할 것입니다. 모든 VPC에서 10.0.0.0/8의 목적지를 TGW로 구성했 때문입니다. 보안 강화를 이러한 경우에는 VPC들의 CIDR을 Propagation 하지 않고, Static으로 처리하면 접근 제어가 가능합니다.
이제 Seoul-VPC-PART-Private-10.4.21.101 에서 DEV, STG로 트래픽을 체크를 해보세요. PRD도 확인 해 보세요.
MultiAccount의 같은 리전에서 TGW 연동을 확인해 보았습니다. Propagation과 Static 조합을 통해서 VPC 격리와 보안을 강화하는 여러가지 디자인을 구성해 볼 수 있습니다.
Last updated
