도메인 3(배포·프로비저닝·자동화 18%)과 도메인 4(보안·컴플라이언스 16%)는 얼핏 정반대로 보인다. 하나는 "빠르게 바꾸기", 다른 하나는 "함부로 못 바꾸게 막기". 하지만 두 도메인은 같은 질문의 양면이다 — 변경을 어떻게 안전하게 다룰 것인가. 배포 자동화는 변경을 빠르고 되돌릴 수 있게 만들고, 보안은 그 변경 권한을 최소한으로 가둔다. 빠른 배포 없는 보안은 운영을 마비시키고, 보안 없는 빠른 배포는 사고를 양산한다.
이 글은 두 도메인을 키워드로 훑는 대신, CloudFormation이 왜 "선언적·멱등적"으로 설계됐는지, 배포 정책들이 가용성과 비용 사이에서 어떤 수학적 trade-off를 하는지, Session Manager가 SSH를 대체하는 내부 메커니즘, 그리고 IAM 정책 평가가 어떤 결정 트리를 따르는지를 파고든다.
CloudFormation을 "복습"할 때 Stack·Template·Change Set을 외우지만, 그 밑에 깔린 더 큰 이야기는 선언형(declarative)이 명령형(imperative)을 이긴 역사다. 이 차이를 잡으면 IaC 전체가 한눈에 정리된다.
명령형 프로비저닝은 "이걸 만들고, 다음에 저걸 연결하고, 그 다음 이 설정을 켜라"처럼 절차를 적는다. 초기 자동화 스크립트(bash, 초기 도구들)가 이 방식이었다