EC2 인스턴스를 만들고 나서 가장 자주 받는 질문은 두 가지다. "왜 SSH가 안 붙어요?"와 "왜 코드는 떴는데 80번 포트가 안 열려요?". 둘 다 답은 같다. 네트워크 통제와 부트스트랩 메커니즘을 잘못 이해해서다. SAA는 "어떤 SG를 어디에 둘 것인가"라는 아키텍처 시점에서 묻는다면, DVA는 "그 SG를 SDK·CLI로 어떻게 만들고, User Data 안에서 Secrets Manager를 어떻게 부르고, IMDSv2를 어떻게 강제하는가"까지 묻는다. 같은 보안 그룹이지만 코드 한 줄, ARN 하나의 차이가 시험 정답을 가른다.
오늘은 Security Group의 stateful 메커니즘이 정확히 어떻게 동작하는지, SSH 키 페어 인증의 TLS 핸드셰이크 단계까지 파헤치고, User Data가 cloud-init 위에서 어떤 순서로 돌아가는지를 본다. 개발자가 시험에서 만나는 "왜 권한이 없다는데 SG는 다 열려 있어요?" 같은 디버깅 시나리오는 결국 이 메커니즘을 끝까지 따라가 본 사람만 풀 수 있다.
대부분의 입문서가 "SG는 stateful이라 응답이 자동 허용된다"고 적고 끝낸다. 실제로 무슨 일이 일어나는지 보자. 클라이언트 203.0.113.10:53241이 EC2 10.0.1.5:443으로 TCP SYN을 보낸다