<aside> 💡 개요 2021년 11월 초까지는 우크라이나, 베트남 개발팀에서 전달해준 AWS 구조를 그대로 사용해왔습니다. default VPC, default Subnet을 활용한 보안을 고려하지 않은 설계였습니다. 개발 속도를 우선시하여왔기 때문에 0.0.0.0/0에 대해서 port를 open하는 경우도 많이 있었습니다.

그러던 와중, 2021.11.04, 2021.11.08에 2회에 걸쳐 RDS의 비밀번호가 변경되는 일이 발생하였습니다. log 파일에서 특정 ip가 의도적으로 RDS의 비밀번호 변경 시도를 했음을 확인하였고, 검색 결과 해당 ip가 인터넷 상에서 여러 번 신고된 ip임을 알게 되었습니다. 이를 계기로 보안 및 비용 절감에 초점을 두어 AWS 구조를 재설계하였습니다.

• 문제가 된 log </aside>

스스로 구축하는 AWS 클라우드 네트워크 - 기본편

새로운 구조도

• 계획

• 완성본

  

아쉬운 점

• 추후 NAT 역할이 커지면 NAT instance로 관리하는 것이 병목 현상을 유발할 수 있다고 하니, 그러한 시점이 되면 NAT instance와 bastion server를 분리하여 NAT instance를 scale up하거나, NAT Gateway를 사용하면 좋을 것 같습니다. (https://junhyeong-jang.tistory.com/5)
• Network ACL을 활용하지 않았습니다. 보안그룹과 라우팅 테이블만으로도 보안 문제를 해결가능하다고 생각했기 때문이지만, 추후 추가되면 좋을 것 같습니다.
• ALB의 target group이 모두 한 EC2로 설정되어 있습니다. 아직은 밸런싱이 필요한 정도의 로드가 없다고 판단했습니다. 추후 트래픽이 늘어나면 target group을 여러 서버로 설정하여 로드 밸런싱하면 좋을 것 같습니다.
• S3와의 연결에 대해 명확히 알지 못합니다. 인터넷으로 빠지고 있다면, 내부에서 트래픽을 관리할 수 있도록 VPC endpoint 등을 이용하게 수정하면 더 좋을 것 같습니다.
• 베스핀 글로벌 측에서는 저희 서비스에 VPC, 계정이 많다는 이유로 Transit gateway를 사용하기를 권고했지만, 네트워크 재구성 당시 내부 판단에 따르면 여러 VPC가 모두 각각에게 연결될 필요가 없었기 때문에 peering 수가 많지 않다고 판단, VPC peering을 활용하였습니다. 추후 VPC의 수가 늘어나 연결이 늘어날 경우 Transit gateway로 변경하는 것이 좋을 것 같습니다.
• 로드밸런서가 front, back, matomo에 대해서 각각 모두 필요한 것인지 리서치가 필요할 것 같습니다. 최초에 하나의 로드밸런서로 경로 기반 라우팅을 통해 각각의 서버로 트래픽을 전송할 계획이었으나, front와 back의 도메인이 같을 때 login과 token 부분에서 알 수 없는 에러가 발생하였습니다. 에러를 해결하지 못해 도메인을 분리하고, 로드밸런서를 분리하여 배치했습니다. 보다 근본적인 문제 원인을 찾아보면 좋을 것 같습니다.
• 로드밸런서 타겟 그룹의 health check 기능을 사용하지 않고 있습니다. health check 시에 사용하는 경로가 열려있지 않는 등의 이유로 Unhealthy로 뜨는 것이 몇 개 있습니다. 즉, Unhealthy 상태라고 해서 현재 에러가 발생한 것은 아닙니다.
• IAM를 개인별로 생성하여 사용하지 않고 있습니다. 네트워크 구조 변경을 원활하게 하기 위해 Root 계정을 사용해왔지만, 이후에는 개발팀 개개인에 대해 IAM를 생성하여 주는 것이 좋을 것 같습니다.
• CloudFront를 기존 세팅 그대로 활용하고 있습니다. 아직 CloudFront에 대한 이해가 명확하지 않아, 수정없이 그대로 활용하고 있습니다. 추가적인 리서치 후에 저희 서비스에 맞지 않는 부분이 있다면 수정해나가면 좋을 것 같습니다.