최종 결과, 토폴로지 개선

 

저희 조에서 만들어낸 최종 토폴로지입니다.

 

통신이 어떻게 흘러가는지 한번 볼까요?

 

1. 외부에서 도메인 주소로 접근

ACM으로 https로 접근 (http로 접근해도 https로 re-direction)

Route 53으로 Egress VPC (이름을 잘못 설정했는데 더욱 정확히는 Bastion VPC)로 이동

 

2. Internet gateway, Elastic Load Balancer

public subnet의 bastion server(ec2)로 통신 이동, private subnet으로 통신 이동 후 AWS transit gateway로 통신 전달

 

3. AWS transit gateway

transit gateway는 web server가 있는 web VPC로 통신 전달

 

4. Web VPC

Load Balancer를 사용해서 private subnet으로 이동, 해당 서브넷 내부에 있는 web server(ec2)가 사용자에게 보이게 됨

 

5. api gateway

web에서 api요청이 발생할 경우 외부의 Amazon API Gateway를 호출하게 되고,

API gateway는 DB VPC에 있는 AWS Lambda 호출

 

6. AWS Lambda

람다는 함수를 실행하여 api요청에 맞는 동작 수행, DB에 CRUD 실행

 

위와 같은 흐름으로 진행됩니다. 그러나 위 토폴로지는 아주 효율적인 토폴로지는 아닌데요, 굳이 필요없는 부분이 있기 때문입니다.

 

개선사항

transit gateway에서 DB VPC를 연결해줄 필요가 없습니다.

web VPC에서 api를 호출할 때도 transit gateway를 사용하지 않으며, VPC 외부에 존재하는 API gateway가 직접 DB VPC까지 요청을 전달합니다. 따라서 transit gateway는 사용되지 않습니다.

 

더불어서, transit gateway로 DB VPC에 연결해둘 경우 Egress VPC에 있는 Bastion server가 해킹당할 경우 transit gateway를 통해 DB로까지 접근이 가능하다는 보안상의 단점이 있습니다.

따라서 DB에는 transit gateway를 연결하지 않는 것이 좋습니다.

 

 

개선사항을 반영한 토폴로지는 위와 같습니다.

transit gateway를 지우고, Egress VPC와 Web VPC는 VPC Peering으로 설정했습니다.

이렇게 설정하면 VPC Peering으로 DB로 접속하지 못하기때문에 DB가 한층 더 안전해졌다고 할 수 있습니다.

 

만약 어떤 이유에서건 VPC가 Egress와 Web을 넘어서 3개 이상 만들 예정이신 경우, VPC Peering이 아닌 transit gateway를 사용하는 것이 더욱 편리합니다.

 

VPC Peering은 1:1 단방향 연결입니다.

즉, A / B라는 두 개의 VPC가 있을 때

A -> B

B -> A

이렇게 두 번의 VPC Peering을 해주어야 하지만

 

A / B / C 세 개의 VPC가 있을 때

A -> B

A -> C

B -> A

B -> C

C -> A

C -> B

이렇게 여섯 번의 연결을 진행해야 합니다.

 

VPC가 더 많아지면 연결해야 할 횟수는 더더욱 많아지겠죠.

유지보수에도 어려움이 있습니다.

 

따라서 transit gateway를 통해 중앙집중형식으로 관리하는 것이 더욱 간편합니다.

 

DB를 VPC 외부에 두고싶은 경우

 

이런 식으로 구성할 수 있습니다. 여기서는 Amazon CloudFront까지 사용한다는걸 전제했지만,

어쨌든 Amazon DynamoDB를 사용해 DB를 VPC 외부에 두고,

만약 DynamoDB에 global table까지 사용한다면 DB데이터의 고가용성까지 보장할 수 있습니다.

 

DB VPC를 별도로 관리해야 할 필요도 없기때문에 더욱 간편하다고 볼 수 있겠습니다만,

보안을 조금 더 신경쓰신다면 DB VPC를 별도로 두셔도 괜찮다고 생각합니다.