문제
프리티어인 규정님의 AWS 계정으로 ElastiCache 인스턴스를 만들고, 이를 재윤님의 AWS 계정의 EC2와 연결하고자 했는데, ElastiCache는 퍼블릭 접근은 제한이 되어있고, 같은 VPC 또는 VPC peering을 통해 EC2 인스턴스로만 접근해야 한다.
해결
다른 계정이다보니 VPC가 달랐고, 그래서 EC2와 ElastiCache가 같은 리전의 다른 VPC에 있는 경우의 해결책 포스트를 참고하여 VPC peering 으로 해결하고자 함.
AWS 문서 참고
피어링으로 다른 Amazon VPC에 있는 클러스터에 액세스하려면
1.
두 VPC에 겹치는 IP 범위가 없거나 이 VPC를 피어링할 수 없어야 합니다.
2.
3.
라우팅 테이블을 업데이트합니다. 자세한 내용은 VPC 피어링 연결을 위한 라우팅 테이블 업데이트를 참조하세요. 앞에 나온 다이어그램의 예제에 대한 라우팅 테이블은 다음과 같습니다. pcx-a894f1c1이 피어링 연결입니다.
VPC 라우팅 테이블
4.
ElastiCache 클러스터의 보안 그룹을 수정하여 피어링된 VPC의 애플리케이션 보안 그룹에서 들어오는 인바운드 연결을 허용합니다. 자세한 내용은 피어 VPC 보안 그룹 참조를 참조하세요.
그 전에, 글을 읽다보니 아래와 같은 내용이 있었다.
피어링 연결을 통해 클러스터에 액세스하면 데이터 전송 비용이 추가로 발생합니다.
•
가용 영역(AZ) 내에 있는 VPC 피어링 연결을 통한 데이터 전송은 모두 무료
가용 영역 내의 피어링은 무료이고, 같은 리전의 경우에도 서울(ap-northeast-2)는 시간당 0.00 USD, 및 100GB/month의 무료 혜택이 있었기 때문에 이용하기로 했다.
해결 과정
처음에 VPC-B에서 VPC-A로 연결을 시도 했다. VPC-ID와 계정 ID를 잘 입력했지만, CIDR이 같아서 에러가 났다.
그래서 CIDR을 10.0.0.0/24로 재윤님 계정에서 새로운 VPC(VPC-A)를 만들고 재시도 했다.
그랬더니 VPC-A에서는 수락 대기 중이 뜬다.
VPC 피어링 연결 성공하니, VPC 라우팅 테이블에서 피어링된 VPC에 경로를 추가해야 한다고 나온다.
라우팅 테이블에 라우팅 경로를 설정해줄 때는 양측 (VPC-A, VPC-B) 모두 해주어야 한다.
VPC-B의 라우팅 테이블에 라우팅을 VPC-A의 CIDR인 173.31.0.0/16을 설정해두었다.
VPC-A의 라우팅 테이블의 라우팅에도 VPC-B의 CIDR을 넣어주었다.
결론
VPC-A에 생성된 EC2 인스턴스에서 VPC-B에 생성된 ElastiCache에 접근이 되는 것을 확인할 수 있다.
