AWS Infra 구성 예시

개요

1~2 개월 전 AWS Solutions Architect 분으로부터 aws에서 어떠한 방식으로 인프라를 구성해야 하는지에 대해 조언을 들었다.

그때 전달해주신 내용을 기억하는 선에서 정리해보려고 한다. 틀린 내용이 있을 수 있다.

나름의 best practice?

그려주셨던 그림

위 이미지는 당시 설명하며 그려주셨던 그림을 정리한 것이다. 위 그림에서 볼 부분은 아래와 같다고 생각한다.

1. WAS와 DB 같이 민감한 부분들은 private subnet에 넣고 외부에 노출되는 부분을 최소화한다.

    - ec2 등을 public ip를 설정을 기본으로 하지 않고 필요한 부분만 외부에 노출하여 외부로부터 안전하도록 구성한다.

    - 따라서 로컬 개발 환경에서는 VPN 등으로 연결할 필요가 있다.

2. 개발환경과 운영 환경의 VPC도 분리한다.

    - 기억이 맞다면 이 정도로 구분하는 것은 규모가 일정 수준 이상 큰 서비스에서 한다고 들었는데 하나의 VPC 안에서만 나눌 것이라고 생각해서 그런가 새로운 모습으로 보여서 기록한다.

3. 가용 영역을 분리하여 장애를 최소화한다.

    - 당연한 이야기지만 was를 하나의 subnet에 구성해 두면 혹시나 해당 subnet에 문제가 생겼을 경우 서비스에 큰 영향이 생긴다.

    - DB는 multi AZ 등의 설정으로 failover를 할 수 있도록 한다. 

4. vpc 간의 통신을 위해 transit gateway를 사용한다. (부정확할 수 있음)

    - transit gateway를 처음 들었지만 이런 목적으로 그리셨다고 생각이 든다. 해당 설명을 보고 위와 같은 이유로 해당 구성하였다고 생각했다.

    - TGW 혹은 VPC peering을 적용해도 될 듯하다. 참고

느낀 점

해당 그림과 현재 서비스의 인프라 구조를 보면 아주 문제라는 것을 바로 느낄 수 있었다. 예를 들어 하나의 vpc에 모든 인프라 구성 요소들이 들어있다던가 was에 공인 ip 가 설정되어 있는 등의 일들 말이다. 이미 운영 중인 서비스에서는 문제들을 발견해도 즉각적으로 수정하기가 어렵다. 그렇지만 심각성과 수정 가능성 등의 우선순위에 맞춰 고쳐나갈 플랜을 세우고 있다. 애초에 좀 더 고민하고 팀원들 간의 논의와 합의를 했었더라면 어땠을까 싶다.

참고

https://docs.aws.amazon.com/ko_kr/vpc/latest/tgw/transit-gateway-appliance-scenario.html

https://brunch.co.kr/@growthminder/94