aws 콘솔 화면

인프런 A.I 가 얘기한것처럼 콘솔은 지속적으로 업데이트 되기 때문에 사라졌습니다.하지만 잘보면 VPC wizard라고 표현되어있지 않지, 만들 수 있습니다.그리고 강의 내용을 충분히 이해 하신다면, 메인화면에 있는 Create VPC로 충분히 해결하실 수 있습니다~

모듈과 .tf 파일 분할에 대해서 의견이 궁금합니다.

인프런 A.I가 거의 저 처럼 대답을 하네요ㅎㅎ 굉장히 공감하는 내용이 많습니다. 아마 많은 회사들이 제가 쓰는 방식보다 질문 주신 방식을 쓰는 회사들이 훨씬 많을겁니다.하지만 저는 제가 쓰는 방식이 훨씬 낫다고 생각합니다. 그 이유는, Terraform에서 제가 항상 강조하는 것은 Readability 입니다.VPC등 여러가지를 module로 관리하면 변경사항이 더 없고. 코드양을 줄여서 Readability가좋아질꺼라 생각하지만 아닙니다. 정확히 얘기하면 아주 간단한 구조의 서비스는 module로 관리하는게 나을 수 도 있지만,한개의 서비스가 VPC 10개 이상을 쓰는 서비스에서는 그냥 단순한 형태로 쓰는게 훨씬 낫습니다. 그 이유는 VPC 등 AWS의 여러 서비스들의 발전속도가 엄청 빠르기 때문입니다.10개의 VPC가 다 똑같이 생겼을거라 보장이 없습니다. 예를들면 비용을 위해서 어떤 VPC는 Zone을1-2개만 쓰고, 어떤 VPC는 Zone을 4개 쓸 수 도 있습니다. Zone을 많이 쓰면 Spot instance 같은 것을 더욱더 비율을 높혀 쓸 수 있기 때문입니다. module 1개로 만들면 결국 모듈 파일에서 분기를 타야됩니다.물론 테라폼은 if 형태를 지원하지만, 읽기가 불편합니다.VPC의 차이점이 1개가되고 2개가 되고, 기능이 반복적으로 나올때마다 분기가 계속 늘어납니다.이건 VPC가 여러 자원들의 집합체라서 복잡도가 늘어날 수 밖에 없습니다. module 의 파라미터가 계속 늘어나고 true and false 가 계속 늘어날겁니다.그래서 VPC는 module이 굉장히 비적합 합니다. 하지만 EC2는 단일 구조이고, 구조상 IF를 타는 경우가 거의 없어서 module로 써도 큰 불편함이 없습니다.제가 단순히 예제코드로 resource로 나누지만 KMS, Codebuild 같이 ec2처럼 단일서비스는 module이 더 나을 수 있습니다. 그런데 여기서 중요하게 생각할 점이 있습니다.제 코드에서 module이 더 낫지만, 그냥 편하게 폴더로 나눠서 쓰는 경우도 있습니다.그 이유는 그냥 처음에 그렇게 만들었고, 변경해봐야 크게 나아지지 않기 때문입니다. 그러니까 module을 사용할때는 module로 사용했을때 훨씬 생산성이 높아야 하는데,module로 사용하나 그냥 copy & paste & update 로 사용하나 큰 속도차이가 없으면,그냥 쓰던대로 쓰는게 낫습니다. 굳이 전체 코드를 리팩토링 할 필요가 없습니다. Terraform은 중요하지만, 중요한 일이 아닙니다. 서로 동료간의 변경점을 정확하게 리뷰하고,정확한 plan 정확한 apply 만 충족하면 됩니다. Terraform code를 리팩토링할 시간에 비즈니스에 도움이 되는 다른 일이 더 중요합니다.가용성을 높히거나 비용을 줄이거나 보안을 강화 그리고 모니터링 하는 일들이 훨씬 더 중요합니다. 제가 2016년에 Hashicorp 에서 삼성전자로 이직해서 대화를 나눈 친구의 이야기가 기억납니다.Hashicorp에서 만든 Best Practice를 쓰지 말라구요. 굳이 그거에 신경쓸 필요 없다고 했습니다.그리고 지금 제가 만든 방식으로 썼었던 친구는 Hashicorp에서 Director 하고 있습니다.ㅎ 우리가 개발을 하다보니 Terraform은 코드가 짧고, module 처럼 즉 함수형처럼 쓰면 효율적이라 생각할 수 있는데, 실제로 리소스를 변경하고, 서로 리뷰를 받고 이 과정이 더 빠른거에 초점을 맞추어야 합니다.실제로 측정해보면 별 차이가 없습니다. 그래서 저는 최대한 단순하게 관리하고 변경이 많은건 그대로 관리하고 충분히 copy & paste 로 해결하는 것이 우수하다고 생각합니다. Terraform 코드를 작성하는게 일의 본질이 아니거든요. 어디는 branch로 관리하고, 어디는 module의 version 까지 관리하는데, 생각해보면 그것보다 중요한 일이 훨씬 많습니다ㅎ 오히려 인프라의 변경가능성을 낮추고, 안정성을 높히는 다른 어떤 일을 하는게 더 중요합니다. 그럼 module의 Best practice는 뭘까 생각해보면 선언형으로 쓰는게 아니라 명령형으로 쓸때 그 진가가 발휘됩니다. https://registry.terraform.io/modules/terraform-aws-modules/atlantis/aws/latest아예 이런식으로 테라폼으로 AWS의 자원관리가 아니라 AWS의 자원들의 집합체로 이루어진, 어떤 도구를 만들때입니다. 이런건 똑같이 몇벌이 생기는게 아니라 지속적으로 하나의 Version을 관리하는게 중요하기 때문입니다. 지금 제 답변과 인프런 AI 답변의 방향이 같습니다. 그리고 Terragrunt 같은 경우 2016년인가 검토하고,당시 Terraform backend 가 없었을 시절에 도입을 고민했습니다만, 역시나 Terraform 친구들을 굳이 복잡하게 쓸 필요가 없기 때문에, 저는 잘 사용하지 않습니다. 가장 중요한건 나의 Performance, 팀의 Performance 입장으로 고민해보는 것이 좋습니다~좋은 답변이 되었으면 합니다. 물론 제 경험은 좀 치우친 경향이 있습니다. 저는 간단한 서비스를 해본 경험이 없습니다.Multi-region, Multi-VPC, 10억 사용자, 100만 TPS, 갑자기 예고 없이 100배 이상 늘어나는 트래픽 등복잡도가 높은 서비스를 해본 경험만 있기 때문입니다. 그런데 아주 간단한 서비스를 만들더라도 굳이 사용 방법을 크게 바꾸지 않을 것 같습니다.그리고 제가 이직을 해서 어떤 곳에서 module 방식을 쓰고 있다면, 굳이 그걸 대규모 개편하지는 않을 것 같습니다. 그냥 이대로 쓰는거랑 리팩토링하는거랑 큰 차이가 없다면 그냥 그대로 쓰고, 다시 말씀드리지만다른 더 중요한 일에 집중을 할 것이기 때문입니다~

강의 자료 질문

제 강의자료는 홈페이지를 제공하고 있습니다.그리고 코드는 모두 github https://github.com/DevopsArtFactory 에서 제공하고 있습니다~여기에 포함되지 않은 어떤 강의자료일까요~?

라우팅 테이블을 public이랑 private를 나눈 이유를 잘 모르겠습니다.

굉장히 중요한 포인트이기 때문에, 강의를 다시 한 번 보시길 권장드립니다.routing table 에 의해서 그 서브넷들이 프라이빗이 되는가 퍼블릭이 되는가 입니다.Routing table rule 에 IGW 가 들어간 것이 public route table 이 되고 이 rule을 따르는 subnet들이 public subnet 이 됩니다.Routing table rule 에 NAT or Not 이 private route table 이 되고 이 rule을 따르는 subnet들이 private subnet 이 됩니다.인터넷을 할 때 자신이 퍼블릭 IP를 소유하지 않고도 인터넷하려면 NAT를,반대의 경우는 public IP를 소유해야합니다. 아래 영상을 한 번 보시길 바랍니다~https://www.youtube.com/watch?v=ZISUSL431bY&t=1409s

sudo yum install -y zsh 명령어 입력 시

일단 Amazon Linux 로 검색하시고 gp3 붙은걸로 한번 해보세요~그리고 아마존 로고 박힌걸루요~

Terraform 코드 동기화

console 로 만든 자원을 테라폼화 하는 것은 import 명령어를 이용해서 하는 방법밖에 없습니다.일단 이름을 맞추어 import를 하고 config를 맞추어서 형성을 맞추는 것입니다.이 방법은 안타깝지만 노가다일 수 밖에 없습니다.검색해보시면 테라폼 import 하는 도구들이 있지만 그 또한 역시, 그 중간 부분을 도와줄뿐입니다~terraform state list 같은 명령어등을 통해서, 수동으로 열심히 맞추어야 합니다~

SSM VPC Endpoint 관련 질문 드립니다

안녕하세요~일단 긴 좋은 질문 너무 감사드립니다.아마 Endpoint는 동일한 AZ를 선택한게 아닌가 싶습니다.보통의 Endpoint는 zone당 1개씩 만들고 VPC 마다 만들 수 있습니다. ( VPC 종속적 )말씀하신대로 IAM 관리가 복잡합니다.그래서 중급 #2 강의로 미뤄놓은 주제입니다. SSO 영역은 구현하지 않을건데 사실 SSO 보다AWS IAM 자체를 이해하고, Assume role 이해하면 SSO는 쉽게 구현할 수 있습니다.대규모 서비스에서 대규모의 사람들이 개발하는 AWS의 유저들을 어떻게 관리할 것인가 있는데,그룹을 만들고 그룹마다 Level을 만드는 형태로 저는 관리하고 있습니다.그 이유는 보통 조직에서 팀이 있고, 팀원들의 Lv 가 있기 때문입니다.최대한 조직을 맵핑을 하는게 좋습니다.

생성한 유저로 로그인한 후, MFA 등을 등록하면 plan이 달라지네요

안녕하세요 송주영입니다.해당 플랜이 나오면 안됩니다. 아마 Accesskey 를 생성하셨는데, 해당 키가 tag에 박힌겁니다~그 tag 가 사라진다는 이야기입니다.해당 정보는 비밀 정보이기 때문에, 해당 플랜처럼 삭제가 되어야 하는게 맞습니다.그런데 왜 태그에 추가가 되었는지는 한 번 확인해보실 필요가 있습니다~이렇게 내가 의도치 않은 값이 들어가는 걸 인지할 수 있기 위해 테라폼을 사용합니다~

iam 권한에 대한 질문

iam 계정을 Administrator 로 만들었다면 모든 권한이 들어가있다고 보면 됩니다.그 iam 계정의 permission을 확인해보세요~

6강 import 존재에 대한 질문

일반적으로 테라폼이 아닌 이미 콘솔로 만들어진 resource를 코드와 매칭해주는게 import 라고 생각하시면 됩니다~ 가져오고나서 이제 옵션을 맞추고 그 이후로는 코드로 관리하는 것입니다~