AWS TGW를 사용하여 VPC 간 통신하기

오늘의 목표는 AWS Transit Gateway를 활용하여 서로 다른 VPC(네트워크 망)을 연결하고, 보안을 유지하면서 효율적으로 통신할 수 있는 멀티 계정, 멀티 VPC 네트워크 아키텍처를 구축하는 것이었다.

가장 먼저 수업에 필요한 실습용 IAM 계정을 생성했다. 72시간 동안 사용할 수 있는 리소스라고 하여 많이 복습해보려고 한다. 해당 계정은 제어 권한이 다수 포함된 Administrator Access 계정이었다.

여기에 개발용 네트워크망과 운영용 네트워크망 환경을 분리하여 VPC를 생성했다. 논리적으로 격리된 가상 네트워크인 Virture Private Cloud를 생성한 것이다.

앞서 생성한 VPC들과 온프레미스 네트워크를 연결하기 위한 허브의 역할로 Trasit Gateway를 생성한다.

CloudFormation에서 미리 작성된 YAML 파일로 복잡한 네트워크 환경을 자동을 배포해봤고, SSM SessionM Manager에서 CLI로 각 EC2에 접속하여 통신 테스트(ping)을 진행하면 끝이다.

AWS Workshop Studio

실습을 하는 방식은 세 가지가 있다. 먼저 우리가 사용할 워크샵 스튜디오를 이용하는 방식은 팀 코드를 받아서 한정된 시간동안 무한으로 연습해볼 수 있는 방식이다. 다음은 개인 AWS 계정을 사용하는 방식, 마지막으로 Event Engine을 사용하는 방식이 있다. 이벤트 엔진을 사용하는 경우 Team Hash값을 사용하여 콘솔에 접속하는 방식이라고 하는데, 안 해봐서 잘 모르겠다.

먼저 워크샵 스튜디오 실습 환경에서 이벤트를 시작하게 된다. 여기는 해커톤이나 워크샵과 같은 행사에서 실습하기 위한 무상 환경이다.

Get Started 버튼을 누르게 되면 가장 먼저 one-time-password를 통해서 workshop용 계정이 생성되게 된다.

이후에 Event Access code를 입력하라고 한다. 이거는 주최측에서 발급해준 코드를 사용하여 접속하면 된다.

그렇게 되면 내가 참가한 이벤트에 대한 내용이 나오게 되고, 레벨과 유효기간이 나오게 된다. 대강 살펴보면 TGW를 이용한 워큐샵이라고 나온다. 이용약관에 동의해준다.

이제 해당 이벤트 계정에 접근할 수 있는 기간이 알림으로 나오게 되고, 사용 가능한 리전, 워크샵에 대한 정보까지 나오게 된다.

From the basic configuration of the AWS Transit Gateway, you'll learn about multi-account environments and Intra/Inter Peering through hands-on exercises. We'll also look at how to monitor Transit Gateways using the Network Manager.

오늘할 내용에 대한 설명도 나온다. 7개의 랩으로 TGW 기본 구성부터 TGW 모니터링 방식까지 배우게 된다고 한다.

TWG

TWG에 대한 설명으로 시작한다. 간단하게 요약하면 Transit Gateway는 중앙 허브의 역할로 VPC와 온프레미스 네트워크를 연결해주는 역할을 한다. 즉 간편하게 연결하고, 쉽게 제어 및 모니터링을 하고, 보안을 유지하며 멀티캐스트를 유연하게 사용할 수 있다는 장점이 있다.

IAM User 생성하기

open AWS Console(ap-northeast-2)를 통해 콘솔에 접속해준다. 그런 이후 IAM의 User을 눌러 들어가준다. 나는 어제 생성한 계정이 있어서 두 개이지만, 원래는 하나이다. 여기서 create user을 눌러 새롭게 유저를 생성해주겠다.

나는 user1이 있기에 user2를 생성할 것이다. provice user access to the AWS Manager Console을 체크하여 오늘 진행할 VPC부터 TGW를 생성하고 실습하는데 문제가 없도록 권한을 추가한다. user must create a new password~ 옵션을 체크 해제한다. 그 이유는 임시 실습 환경이므로 패스워드 재설정을 하지 않는 것이 편리하기 때문이다. 실제에서는 체크하도록 한다.

그다음 우리가 사용할 권한을 추가하기 위해 attach policies directly를 체크하고, AdministratorAccess AWS managed - job function 권한을 추가해주도록 한다. 다음 단계에서 선택한 내용들을 확인하고 생성해준다.

이때 console sign in url을 복사해놔야지 이따 접속할 때 편하다. 다른 곳에서 찾아서 할 수도 있다.

Assume Role 부여하기

IAM Dashboard에서 EC2의 roles를 생성하여 권한 가지도록 규칙을 생성할 것이다.

AdministratorAccess 권한을 추가한다.

role 이름은 사용자가 알기 쉽게 입력해도 되지만, 일단 실습이기에 메뉴얼대로 진행한다. ec2-role 난 이전에 만들었었기에 1을 붙여줬다.

IAM 계정 접속하기

아까 저장하라고 했던 URL로 접속해도 되고, AWS Account 아래 주소를 클릭하여 접속해도 된다. user마다 url이 다르지 않을가 생각할 수 있는데, 일단 저 url이 중요한 것이 아니다. 본 계정의 Account ID가 중요한 것이다. 그냥 AWS 콘솔 검색한 다음에 IAM 계정으로 접속을 선택하고 Account ID만 맞춰주면 같은 접속 경로가 되는 것이다. 그리고 user의 id(user01, user02)와 PW를 선택해서 입력해주면 iam 계정에 접속이 되는 것이다. 우측 상단의 사용자명이 맞는지 확인하면 끝이다.

EC2 환경 구성

Cloudformation에 접속하여 Create Stack을 눌러준다. 여기서는 이미 만들어진 yml파일을 기반으로 keypair을 생성하고 업로드하기 위해 EC2구성을 하게 된다. 여기에는 권한 설정(IAM), 최신 운영체제 선택(AL2023), 필수 도구 설치(UserData)까지 한 번에 완료하여 사용자가 즉시 실습할 수 있는 EC2를 자동으로 생성하게 해준다.

upload a template file을 선택하고, Workshop-EC2.yml 파일을 업로드해준다. 해당 파일은

다음으로 넘어가서 이름은 test-ec2로 설정하고, 서브넷은 172.31.0.0/20을 사용해준다. VPC는 디폴트를 사용한다.

다 체크하고 submit하게 되면 다음과 같이 내가 yaml로 설정한 ec2 환경이 생성되는 모습을 볼 수 있다. complete되었다면 넘어가준다.

이번에는 EC2를 들어가 instances에서 내가 생성한 EC2가 running 상태인지 확인해보고 connect를 눌러 접속한다.

session Manager를 통해 커넥트 누른다. 그렇지 않으면 오류가 날 것이다.

웹에서 터미널이 뜨게 되는데, 이제 해당 EC2 인스턴스에서 추후 생성할 개발EC2, 운영EC2를 모두 접속할 것이다. 이를 위해서 ssh-key를 생성해줘야 한다. 가장 먼저 sudo ssh-keygen을 입력하여 key를 생성한다. 가장 처음에 키의 이름을 물어보는데, mykey로 작성하여 나중에 작업할 때 혼선을 막아준다. 다만 나는 이미 어제 같은 이름으로 만들어 업로드를 해놨기 때문에 그런 것이니 이름을 바꿔생성한다(이미지는 그대로) 나머지는 엔터만 쳐주면 생성된다.

이제 생성된 key pair 중 public key를 사용할 리전 계정에 업로드하여 추후 생성한 EC2에 등록해 놓을 것이다. 나는 앞서 말했듯 이름이 겹쳐서 이름을 바꿔서 새롭게 업로드했다. 다만 KeyPair 파라미터를 입력할 때, Seoul-VPC-PRD-Workshop.yml이나 Seoul-VPC-DEV-Workshop.yml 파일을 업로드하고 실행할 때, 화면에 나오는 KeyPair 입력란에 기본값인 mykey 대신 새로 만드신 키 이름(예: mykey-v2)을 선택하거나 직접 입력해줘야 한다.

sudo mv mykey ./mykey.pem
sudo chmod 400 ./mykey.pem
export KeyName=mykey
echo "export KeyName=${KeyName}" | tee -a ~/.bash_profile
source ~/.bash_profile
aws ec2 import-key-pair --key-name "mykey" --public-key-material fileb://mykey.pub --region ap-northeast-2
aws ec2 import-key-pair --key-name "mykey" --public-key-material fileb://mykey.pub --region us-east-1

test EC2에서 다른 EC2에 직접 접근하기 위해 플러그인 설치

sudo curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "session-manager-plugin.rpm"
sudo sudo yum install -y session-manager-plugin.rpm

TGW 구성하기

다시 cloudformation의 stacks로 돌아와서 yml을 첨부하여 Virginia-VPC-PRD, Virginia-VPC-DEV를 생성해준다.

yml 파일 선택하고(나는 리전이 버지니아로 바뀌었기에 이름을 그렇게 한 것이고, 기존 파일은 서울용으로 넣어줘도 무방하지 않다. 이따 보겠지만 오류나서 두 가지 바꿔줘야 한다) 해당 야믈파일에는 가상 네트워크 레이어 (VPC & Subnets), 보안 레이어 (Security Groups), 컴퓨팅 레이어, 소프트웨어 설치 스크립트에 대한 내용들이 포함되어 있다.

이름을 버지니아 vpc로 설정하고, 압서 만든 키 페어를 v2로 하면 된다. 또한 role 이름이 맞는지 확인하고 다음으로 넘어간다. 마찬가지로 DEV도 생성해주면 된다. 하지만 에러가 나는 이유는 yml 파일이 서울 리전에 맞게 되어 있기 때문이다.

다만 나의 경우 리전이 버지니아로 되어 있기에

keypair도 변경해야 한다.

다 잘 생성된 모습을 볼 수 있다.

이제 VPC도 잘 생성되었는지 확인해봐야 한다. VPC로 이동하여 생성이 잘 되었는지 확인한다.

EC2로도 이동하여 잘 생성되었는지 확인한다.

TGW 구성

이제 진짜 TGW를 구성하여 세 인스턴스가 통신할 수 있게 해준다. 다시 CloudFormation으로 와서 파일을 업로드 해준다.

이름은 Virginia-TGW로 해주고 생성해본다. 여기도 마찬가지로 발생하는 문제가 있다.

그 이유는 바로 내가 vpc 이름을 모두 Virginia-VPC~로 변경했기 때문이다. 파일에서도 전부 바꿔준다.

이번에는 잘 생성되는 모습이 나타난다.

이제 VPC - Trasit gateways로 이동하여 잘 연결되서 생성되었는지 확인한다.

attachment가 서브넷과 잘 연결되었는지를 확인한다.

두 vpc가 association되어 있는지 확인한다.

Test EC2 SSM 연결

접속하여 다음 명령어 붙여 넣는다. Private 인스턴스로 시험할 것인데, Cloudformation을 통해 System Manager와 Session Manager를 사용할 수 있도록 자동 배포 구성했다.

aws ec2 describe-instances --query 'Reservations[].Instances[].[Tags[?Key==`Name`] | [0].Value, Placement.AvailabilityZone,InstanceId, InstanceType, ImageId,State.Name, PrivateIpAddress, PublicIpAddress ]' --output table
![](https://velog.velcdn.com/images/songwoo-yu/post/2af94fd1-9438-4b8c-a6cb-614504e896a9/image.png)

ping test

변수에 EC2 ID 입력하고 PRD, DEV 인스턴스의 id를 가져온다.

VA_VPC_PRD_ID=$(aws ec2 describe-instances \
  --region us-east-1 \
  --filters "Name=tag:Name,Values=Virginia-VPC-PRD-Private-10.1.21.101" \
  --query "Reservations[0].Instances[0].InstanceId" \
  --output text)

VA_VPC_DEV_ID=$(aws ec2 describe-instances \
  --region us-east-1 \
  --filters "Name=tag:Name,Values=Virginia-VPC-DEV-Private-10.3.21.101" \
  --query "Reservations[0].Instances[0].InstanceId" \
  --output text)

결과를 확인한다.

echo "Virginia PRD Instance ID: $VA_VPC_PRD_ID"
echo "Virginia DEV Instance ID: $VA_VPC_DEV_ID"

이제 ping test를 해본다. 당연히 안 되어야 한다. Subnet Route Table이 Transit Gateway(TGW)를 바라보도록 설정되지 않았기 때문이다.

# 1. DEV EC2에 SSM으로 접속
aws ssm start-session --target $VA_VPC_DEV_ID --region us-east-1

# 2. 호스트네임 확인 (접속 성공 여부 확인)
hostname

# 3. PRD 환경(10.1.21.101)으로 ping 테스트
ping 10.1.21.101

여기에서 라우팅 테이블을 변경해줘야 한다.

transit gateway로 변경해주고 하나 생성된 그걸로 설정한다.

마찬가지로 PRD의 것도 변경한다.
그런 후에 dev로 접속하여 prd에 ping을 날려보겠다.

# 1. DEV EC2에 SSM으로 접속 (버지니아 ID 변수 사용)
aws ssm start-session --target $VA_VPC_DEV_ID --region us-east-1

# 2. 호스트네임 확인
hostname

# 3. PRD 환경(10.1.21.101)으로 ping 테스트
ping 10.1.21.101

ping이 잘되는 것을 확인할 수 있다. 마찬가지로 PRD로 접속해서 해보려고 한다.

# 1. 현재 DEV EC2 세션 종료
exit

# 2. PRD EC2에 SSM으로 접속 (버지니아 ID 변수 사용)
aws ssm start-session --target $VA_VPC_PRD_ID --region us-east-1

# 3. 호스트네임 확인
hostname

# 4. 결과값 확인 (버지니아 리전 형식)
# ip-10-1-21-101.ec2.internal

# 5. DEV 환경(10.3.21.101)으로 ping 테스트
ping 10.3.21.101

여기도 잘 된다.

정리

VPC Peering vs TGW: 만약 VPC Peering이었다면 두 VPC 사이의 직접적인 연결이 필요했겠지만, Transit Gateway는 중앙 허브 역할을 수행하여 모든 트래픽을 중계한다. Default Route (0.0.0.0/0): 현재 실습에서는 모든 외부 트래픽을 TGW로 돌려놨다. 이는 보안을 위해 모든 트래픽을 중앙(TGW)을 거쳐 검사하거나 통제하려는 멀티 계정 전략의 기초가 된다.