작성
·
73
·
수정됨
0
안녕하세요.
Bastion Host 대신 SSM을 사용하여 private subnet, isolated private subnet(no nat)에 있는 EC2 instance에 SSH 대신 연결하기 위해 다음과 같이 코드를 작성했습니다.
그런데 다음과 같은 오류가 발생하였습니다.
동일 AWS Service에 대한 VPC Endpoint가 AZ 당 반드시 하나만 존재하도록 강제하고 있는 것 같습니다.
그래서 현재 vpc 디렉토리 내에 강사님이 구조를 모방하여 module, dev_apnortheast2, stag_apnortheast2, prod_apnortheast2 총 4개의 모듈이 존재하도록 작성했는데,
어떻게 해결할 지 간단하게 생각해봤습니다.
shared_apnortheast2라는 새로운 디렉토리를 만들어서 SSM을 위한 리소스들을 전부 여기에 저장하고, data나 remote_state 같은 블록을 통해 각 모듈에서 가져다 쓰는 것
-> 관리 포인트가 늘어나는 단점 + 다른 환경 끼리 같은 리소스를 써서 헷갈리는 단점, 여기다 전부 만들면 되서 env 마다 충돌 안 나게 할 필요 없는 장점
dev, stag, prod에서 각각 하나의 az에만 SSM을 위한 리소스, VPC Endpoint를 만드는 것
-> 각 모듈 내의 SSM, VPC Endpoint 만들 때 실수로 겹치지 않도록 az를 신경 써줘야 함 + 운 나쁘게 하나의 az가 다운되었는데 그것이 prod 환경의 SSM, VPC Endpoint면 수동 조치 필요 + 환경 별 불일치 발생
3. ssm 자체를 VPC Endpoint가 아닌 다른 방법, 강사님이 언급하신 Transit Gateway 등을 사용하는 것
대략 이 정도로 생각을 해보았습니다.
아직 SSM, VPC Endpoint에 대한 개념이 완전히 정립되지 않아서 제가 생각한 방법 중 절대 사용해서는 안 되는 치명적인 함정이 있는지, 위 방법들 중 실제로 쓰이는 방법이 있는지, 강사님은 어떤 방법을 선호 하시는지가 궁금합니다.
---
앞 부분을 여러 번 돌려보고 직접 작성하면서 진행하느라 굉장히 느리게 진행하고 있는데 확실히 직접 몇 번 만들어 보고 다시 돌려보니 이해도가 늘어나는 것이 느껴집니다.
테라폼을 처음 접했을 때 하위 디렉토리 무시하고 현재 디렉토리 단위로만 모듈이 되는 것과 책 등에서는 어떻게 구조화 하는지를 알려주지 않았는데, 강사님 강의를 통해 조금씩 어떻게 사용하는지 느낌을 잡아갈 수 있었습니다.
(리뷰에 써야하는 내용인데 아직도 앞부분 돌려보고 있어서 다 듣고 다시 쓰겠습니다.ㅋㅋ)
강의 반복해서 듣고 혼자 구조 짜고 실습을 해보니 이 사용자를 어떻게 관리하는지 부분이 상당히 방법이 많고 난해하더라구요.
IAM User, Group, Role, Policy 여기까지는 그래도 엄청 어려운 개념은 없고 테라폼으로 리소스 생성도 가능한데
이거를 수백명 단위라고 생각하면 어떻게 자동으로 생성하고 관리하고 권한을 조절하는지가 상상이 잘 안 되더라구요.
그리고 요즘은 SSH->SSM으로 넘어갔듯 Organization과 SSO(이름이 Identity Center?로 바뀐 것 같습니다.)를 조합해서 사용하는 최신 방식도 많이 사용하고 있다는 것으로 알고 있는데,
테라폼을 처음 접했을 때처럼 이 중에서 어떤 것을 골라서 쓰고, 어떤 것을 안 써야하는지, 어떻게 자동화, 권한 조절을 하는지... 함정은 무엇인지 등이 감이 잘 안오는 상태입니다.
이런 부분을 실전 느낌으로 체계적으로 다루는 강의는 찾기 어려울 것 같아서 후속 강의를 계속 내시게 되면 IAM, Organization, SSO 등의 사용자 리소스 관리 및 자동화, 베스트 프랙티스도 꼭 보고 싶네요.
아 그리고 지금까지 테라폼 구조화 방식을 workspace, module + softlink, terragrunt 3가지 정도를 접했는데
workspace는 강사님과 Terraform 모듈 만드시는 분이 이미 겪어보고 module + softlink 방식이 낫다고 말씀해주셔서 깊게 보지 않았는데, terragrunt는 어떻게 생각하시는지, 어떤 단점이 있는지도 궁금합니다. 아래 예제 레포가 있는데 좀 방대해서 제대로 이해하고 해석하려면 시간이 걸리겠더라구요.
https://github.com/cogini/multi-env-deploy
언제나 강의 잘 듣고 있습니다.
다음 강의들도 기대하겠습니다. 감사합니다.
답변 2
1
안녕하세요~
일단 긴 좋은 질문 너무 감사드립니다.
아마 Endpoint는 동일한 AZ를 선택한게 아닌가 싶습니다.
보통의 Endpoint는 zone당 1개씩 만들고 VPC 마다 만들 수 있습니다. ( VPC 종속적 )
말씀하신대로 IAM 관리가 복잡합니다.
그래서 중급 #2 강의로 미뤄놓은 주제입니다. SSO 영역은 구현하지 않을건데 사실 SSO 보다
AWS IAM 자체를 이해하고, Assume role 이해하면 SSO는 쉽게 구현할 수 있습니다.
대규모 서비스에서 대규모의 사람들이 개발하는 AWS의 유저들을 어떻게 관리할 것인가 있는데,
그룹을 만들고 그룹마다 Level을 만드는 형태로 저는 관리하고 있습니다.
그 이유는 보통 조직에서 팀이 있고, 팀원들의 Lv 가 있기 때문입니다.
최대한 조직을 맵핑을 하는게 좋습니다.
맞습니다! 그게 핵심이고 많은 분들이 잘못된 방향으로 가는 대표적 예 입니다.
테라폼은 AWS or 다양한 SaaS 등을 IaC 하는 도구입니다.
더 중요한 지식은 AWS 등 솔루션들의 지식이 중요하고, 그걸 잘 관리하기 위해 테라폼을 쓰는 것입니다. Python을 제대로 아는 것도 중요하지만, Python으로 무엇을 잘만들지가 더 중요한것처럼요~
0
안녕하세요, 인프런 AI 인턴입니다.
..님, SSM VPC Endpoint 설정을 위한 코드 작성 후 발생한 문제에 대해 답변드리겠습니다.
현재 발생하고 있는 오류는 “VPC Endpoint에 대해 같은 AZ에 여러 서브넷을 지정할 수 없다”는 것입니다. 이 문제를 해결하기 위해 여러 가지 접근 방식을 고려해 보실 수 있습니다.
shared_apnortheast2
)를 만들어 SSM 관련 리소스들을 모두 여기에 저장하고, 필요한 곳에서 data
나 remote_state
블록을 통해 가져다 쓰는 방법입니다.이 접근법은 관리 포인트가 증가하는 단점과 리소스를 공유함으로 인한 혼란이 있을 수 있지만, 각 환경마다 중복 없이 SSM 설정을 관리할 수 있다는 장점이 있습니다.
이 방법은 환경마다 일관성을 유지하기 어려울 수 있으며, 특정 AZ에 장애가 발생했을 때 이를 수동으로 조치해야하는 단점이 있습니다.
이 방법은 직접적인 연결 대신 보다 유연하고 확장 가능한 네트워크 구성을 가능하게 할 수 있습니다.
제안드린 방법들을 통해 문제를 해결해 보실 수 있으며, 추가로 SSM과 VPC Endpoint의 개념을 더 명확히 이해하는 것이 도움이 될 것입니다.
테라폼 구조화와 관련하여 workspace, module+softlink, terragrunt의 차이점과 추천하는 방식을 강의에서 다루었듯이, 테라그런트는 관리가 편리하지만 구조가 복잡해질 수 있습니다. 강사가 추천한 module+softlink 방식이 더 적합할 수 있습니다.
추가적인 도움을 원하시면 아래 링크들을 참조해 보세요:
- Spring Boot AWS Elastic Beanstalk 예제 블로그 포스트
- CloudCaptain과 AWS로 Spring Boot 애플리케이션 배포하기
앞으로도 강의의 내용이 님께 많은 도움이 되기를 바랍니다. 테라폼 및 AWS 관련하여 궁금한 점이 있으면 언제든지 문의해 주세요.
감사합니다.
상세한 답변 감사합니다~
답변을 참고해서 VPC Endpoint 부분만 작게 잘라서 실험해봐야겠네요
테라폼을 공부할수록 테라폼 자체보다는 AWS에 대한 이해도 부족과 어떻게 구조를 가져갈 것인지 감을 잡는 것이 어렵게 느껴지는데 강의를 보면서 경험에 따른 베스트 프랙티스와 실무를 바탕으로 한 구조를 보면서 많이 배우게 되네요.!!