본 콘텐츠는 구름 서포터즈 활동으로 지원을 받아 작성된 교육생의 실제 경험 후기입니다.

이전 게시물에서 프로젝트를 시작했을 때 포스팅을 남겨놓았다.
그때는 기획 수준이었는데, 지금은 그때와는 다른 고민들을 하기 시작했다.
CI/CD 파이프라인 구성이라든지, 자동 배포 전략은 어떻게 할 것인지 등등.
아직은 반 수동 배포인 상황이지만, 앱이 잘 돌아가는 상태로는 만들었다.
일단 이전 게시물과 가장 크게 달라진 점은 인프라 구성도인 것 같다.

기존과 가장 달라진 점

기존엔 bastion 서버를 두어서 private 서브넷에 있는 자원들에 접근하게 했는데,
지금은 SSM 서비스를 이용해 콘솔에 로그인하면 바로 EC2에 접근할 수 있도록 변경했다.
(현재 이 아키텍처도 수정해야 할 부분이 많다는 건 인지하고 있다. 백엔드 EC2를 private에 두어야 한다는 점 등.)
이 아래는 프로젝트 발표 때 사용했던 PPT다.
우리가 고려한 백엔드 엣지케이스라든가, 바뀐 인프라 아키텍처를 확인해볼 수 있다.

백엔드 엣지케이스 고려 및 바뀐 인프라 전략

bastion에서 SSM으로 전환한 이유

프로젝트 발표 중에 가장 첫번째로 받은 질문이 왜 bastion을 두지 않았느냐 인 것 같다.
ssm으로 전환 시 가장 팀원들이랑 많이 얘기했던 부분들이기도 하고.
왜 bastion에서 ssm으로 전환하였냐면 다음과 같은 이유들 때문이다.

• 보안 측면에서 더 유리하다. bastion을 운영하려면 SSH 포트(22번)를 외부에 열어둬야 하는데, 이 자체가 공격 표면이 된다. SSM은 인바운드 포트를 아예 열 필요가 없고, IAM 기반으로 접근을 제어하기 때문에 보안상 더 낫다고 판단했다.
• bastion 서버 자체의 유지비용과 관리 포인트가 줄어든다. bastion도 결국 EC2 인스턴스라 비용이 나가고, 패치나 키 관리 같은 운영 부담도 생긴다. SSM으로 전환하면 그 오버헤드를 없앨 수 있다.
• 접근 이력 추적이 편하다. SSM Session Manager는 세션 로그를 CloudWatch나 S3에 자동으로 남길 수 있어서, 누가 언제 어떤 인스턴스에 접근했는지 감사(audit) 추적이 훨씬 수월하다. bastion 방식에서는 이걸 별도로 구성해야 한다.

다만 bastion을 완전히 버려야 하나에 대해선 아직도 고민 중이다. 지금은 서비스 규모가 작아서 SSM으로도 충분하지만, EC2 수가 늘어나거나 현업 환경처럼 여러 인스턴스를 빠르게 오가며 관리해야 하는 상황이라면 SSH로 직접 붙는 게 더 편할 수 있기 때문이다.