테라폼의 HCL은 배우기 어렵다는 인식이 있는 것이 사실이다. 하지만 HCL은 JSON이나 YAML과 같은 선언형 설정 언어일 뿐이며, 리소스의 필드 참조나 리소스 사이의 참조 등을 오히려 JSON이나 YAML보다 더 쉬운 방법으로 정의할 수 있게 해준다. 실제로 HCL로 작성할 수 있는 모든 스크립트는 동등한 JSON 기반 설정 문법(JSON Configuration Syntax)을 사용해 작성할 수 있다. 더 나아가면 HCL은 이론상 당연히 동등한 YAML로도 표현이 가능하다. JSON은 YAML의 부분집합이기 때문이다. / HCL은 그저 JSON과 YAML 설정 파일을 인프라 관리자의 입장에서 조금 더 수월하게 작성하기 위해 만들어진 언어이며, JSON과 동등하다.
--- p.17

모듈 안에 서브 디렉터리로서 모듈을 또 정의하여 사용할 수 있다. 이를 중첩 모듈(nested module)이라고 한다. 일반적으로 컬렉션을 순회하며 반복적으로 리소스를 생성하거나 할 때, 상당히 넓은 범위의 리소스가 매 순회 시마다 만들어져야 할 수도 있다. 이럴 때 단순히 for_each나 for 등을 많은 종류의 리소스에 동시에 사용해서 구현할 수 있는데, 쉽게 예상할 수 있듯이 오류의 소지가 크다. 이럴 때 중첩 모듈로 순회에 따르는 액션을 정의해서 루트 모듈의 가독성을 높이는 방법을 사용해볼 수 있다. 중첩 모듈은 테라폼의 공식 컨벤션상 /modules 서브 디렉터리에 두는 것이 일반적이나 합리적인 이유가 있다면 컨벤션을 따르지 않아도 올바르게 작동한다.
--- p.74

AWS 메타데이터는 실무상 다양한 환경과 프로젝트에서 수시로 사용하는 값이기 때문에 생각보다 자주 호출할 필요가 있다. 예를 들면 모듈 안에서 각 리소스에 계정 정보를 태그로 지정하는 것도 흔히 사용하는 패턴이다. 또한, 현재 참조하고 있는 계정이나 리전에 따라 다른 리소스를 만들기 위해서 분기 처리를 할 수도 있다. / 그러나 이러한 상황마다 AWS 메타데이터의 값을 매번 직접 호출하는 것은 코드 유지 보수 측면에서 효율적이지 않다. 이유를 설명하자면, 우선 AWS 메타데이터의 값에서 아이디는 aws_caller_identity, 앨리어스는 aws_iam_account_alias, 리전 정보는 aws_region라는 서로 다른 데이터 블록을 통해 각각 받아와야 한다. 그런데 메타데이터의 정보가 필요할 때마다 내가 원하는 정보가 어느 데이터 블록에 있는지 확인해야 하는 것은 번거롭다. 또한 이 상태에서 그냥 메타데이터를 다수의 데이터 블록을 호출하는 방법으로 알아내야 한다면, 반복적이고 장황한 코드를 작성하게 되어 가독성과 유지 보수성이 훼손된다.
--- p.105

VPC 모듈과 마찬가지로, 보안 그룹 모듈에서도 다른 리소스에서 참조할 만한 값을 출력 블록으로 설정한다. 이번 모듈에서 새롭게 생성한 리소스는 보안 그룹과 보안 그룹 규칙뿐이다. 보안 그룹 규칙의 식별자를 보안 그룹 모듈 밖에서 직접 사용하는 경우는 거의 없으므로, 출력값으로 설정할 만한 것은 보안 그룹의 아이디뿐이다. / 그러므로 보안 그룹 모듈의 출력 블록으로 모듈에서 생성한 모든 보안 그룹의 아이디를 맵 형식으로 내보내도록 정의하기로 한다. 이를 위해서 보안 그룹을 가리키는 리소스 블록인 aws_security_group.this에 for 표현식을 적용하고, 키와 값을 가리키는 매개변수를 사용해 k =〉 v.id 형태로 맵을 정의한다. 그 결과, 보안 그룹의 이름을 통해 보안 그룹의 아이디를 얻어낼 수 있는 출력 블록이 만들어진다.
--- p.187

널 프로바이더(null provider)는 실제 리소스를 생성하지 않는 가상의 리소스가다. 실제 리소스를 다루지 않는 대신, 템플릿이나 외부 스크립트를 실행하거나 단순한 워크플로를 제어하는 데 사용한다. 예를 들어 테라폼에서 지원하지 않는 API 요청을 전송하거나, 리소스 생성 흐름을 제어하고 싶은 경우에 사용할 수 있다. / 다만 대부분의 경우에는 널 프로바이더 없이도 스크립트 실행이나 리소스 제어가 가능하며, 널 프로바이더를 사용하면 코드를 이해하기 어려워지기 때문에 사용하는 것을 권장하지 않는다. 또한 테라폼 버전 1.4부터는 terraform_data6라는 이름의 같은 역할을 가진 테라폼 기본 리소스 타입이 도입되어 널 프로바이더를 사용할 필요가 사라졌다. 실제로 두 리소스를 비교하면 null_resource의 triggers 속성이 terraform_data에서는 triggers_replace로 바뀐 부분을 제외하면 나머지는 모두 동일하다.
--- p.249

아틀란티스(Atlantis)는 대표적인 테라폼의 협업을 위한 오픈소스 도구다. 테라폼의 코드 변경사항이 리포지터리에 푸시되었을 때, 자동으로 플래닝이나 반영 명령을 수행하는 등의 규칙을 설정할 수 있으며, 일관된 테라폼 실행 환경까지 제공하므로 추천할 만하다. 그렇다고 해서 모든 테라폼 프로젝트에 아틀란티스를 반드시 적용해야 한다는 것은 아니다. 우선 테라폼을 관리하는 팀원이 적을 경우, 아틀란티스로 인해 얻는 이점보다 아틀란티스를 설치하는 데 드는 비용이 더 들어갈 수도 있기 때문이다. 인프라를 다루는 도구이므로 기본적으로 사내망 안에서 설치해야 하기 때문에 서버 비용도 고려해야 하고, 처음 설치하는 사람에겐 파이프라인 구현까지 학습 곡선으로 작용하므로 반드시 필요한지 확인해보고 도입하는 것을 추천한다.