AWS 서로 다른 계정의 Lightsail간의 사설망 통신
시나리오
- A계정에서 사용하던 IAM 키 하나가 노출되어, 계정이 잠김 (인스턴스 생성 제한 등)
- 키를 새로 생성하고 무결점 배포까지 약 한달의 기간으로 예상
- 특정 서비스 오픈을 위해서 B계정에서 Lightsail 인스턴스를 생성하여 배포
- 프록시 서버를 구축, A계정의 Lightsail 서버, B계정의 Lightsail 서버로의 통신을 위해서 보안유지를 위해 사내망 통신으로 구축해야 하는 상황
문제 발생 (1)
개요
시나리오대로 구축하는 도중 문제가 발생하였습니다.
내용
아래의 그림과 같이 A계정의 Lightsail에서 B계정의 Lightsail로 private ipv4를 이용하여 내부 통신이 필요한 상황인데 같은 계정이 아니라서 통신이 불가 합니다.
결과
(A)의 Lightsail 서버에서 (B)의 Lightsail 서버로의 Private IP를 이용한 ping 실패
(B)의 Lightsail 서버에서 (A)의 Lightsail 서버로의 Private IP를 이용한 ping 실패
문제 해결 (1)
방법 (1) - Transit Gateway
위 방법처럼 A계정에서 Transit Gateway를 생성하고, B계정에 공유를 해줬습니다.
이후 (A,B) 두 계정에서 Transit Gateway 연결을 통하여 연결시켜주었습니다.
여기서 목적은 A계정 Lightsail에서 B계정 Lightsail로의 private ipv4를 이용한 내부 통신 입니다.
Lightsail의 CIDR 범위가 172.26.0.0/16으로 고정되어 있기때문에 변경이 안됩니다.
따라서 CIDR 범위가 겹치기 때문에 통신이 되지 않았습니다.
이를 서브넷이나 라우팅 테이블을 생성하여 통신하는것도 생각 해보았지만, 위 구조를 보면
VPC에 피어링된 Lightsail CIDR인데다가, VPC의 서브넷은 A계정, B계정 주소가 달라야 하기 때문에 서로 허용해주는게 불가능하다 판단하였습니다.
방법 (2) - VPC Peering
VPC 끼리의 Peering 기능도 지원 하길래 연결시켜 보았지만 위와 마찬가지인 VPC에 피어링된 Lightsail 끼리의 통신이 필요한 시점인데, CIDR이 172.26.0.0/16으로 고정되어 변경이 불가하기 때문에 불가능하다 판단하였습니다.
결론
결국 한 계정 내부의 ec2, lightsail은 private ipv4로 통신이 가능하기 때문에,
두개로 나뉘어져진 계정을 하나로 통합하고,
Lightsail로 사용중인 서버를 점차 ec2로 이전하려고 합니다.