🔥 Instance Profile: EC2는 IAM을 어떻게 얻는가

EC2를 처음 띄웠을 때, 튜토리얼들은 하나같이 이상한 걸 시켰다. ~/.aws/credentials에 장기 Access Key를 심고, 그걸 인스턴스 초기화 스크립트로 복사하는 식. 얼마 안 가 이게 말이 안 된다는 걸 알았다. 인스턴스가 뚫리면 공격자가 그 장기 키도 함께 가져간다. 교체하려면 모든 인스턴스를 다시 만져야 한다.

그래서 AWS는 Role을 EC2에 '부착'하는 방법을 따로 만들었다. 그 부착 장치의 이름이 Instance Profile이다. 여기서는 EC2가 IAM을 어떻게 받는지만 본다. Role의 원리는 이미 User, Group, Role의 차이에, 임시 자격증명 발급은 Assume Role에서 임시 자격증명이 만들어지는 순간에 있으니 여기서는 반복하지 않는다.

Instance Profile: Role과 EC2 사이의 얇은 어댑터

Instance Profile은 Role 자체가 아니다. Role을 EC2에 꽂을 수 있게 해주는 컨테이너다. 구조만 보면 User↔Group과 닮았다. User가 권한을 직접 들고 다니지 않고 Group을 통해 얻듯이, EC2도 Role을 직접 물지 않고 Instance Profile을 거친다.

다만 제약이 하나 있다. Instance Profile 하나에는 Role이 정확히 한 개만 들어간다. 이 한도는 늘릴 수 없다("This limit of one role per instance profile cannot be increased", verified 2026-04-24). 반대로, 같은 Role을 여러 Instance Profile에 담는 건 가능하다. 개발/스테이징/프로덕션에서 같은 Role을 다른 Profile 이름으로 재사용하는 식의 패턴이 여기서 나온다.

콘솔에서 Role을 만들고 EC2에 "IAM role" 드롭다운으로 붙이면 Profile은 뒤에서 자동으로 생긴다. CLI나 IaC로 하면 Profile을 내가 직접 짜야 한다. CreateInstanceProfile로 그릇을 만들고 AddRoleToInstanceProfile로 Role 하나를 채워 넣는 게 출발점이다. 그 Profile을 EC2에 얹는 방법은 둘이다. 런치 시점이면 RunInstances의 IamInstanceProfile 파라미터에 Profile을 지정하고, 이미 떠 있는 인스턴스에 뒤늦게 붙이는 상황이면 AssociateIamInstanceProfile을 따로 호출한다. 어느 길을 가든 호출자에게는 대상 Role에 대한 iam:PassRole 권한이 필요하다. PassRole이 없으면 "아무 Role이나 EC2에 꽂는" 특권 상승이 가능해지니까, IAM이 일부러 따로 떼어 놓은 관문이다.

EC2 내부에서 자격증명이 도착하는 길

인스턴스 위에 올라타면 link-local 주소 하나가 보인다. 169.254.169.254. 외부에서 라우팅되지 않고, 그 EC2 안에서만 닿는 인스턴스 메타데이터 서비스(IMDS)다. EC2는 이 경로로 Role 자격증명을 받는다.

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>

응답은 임시 자격증명 한 벌을 돌려준다. 3종 구조(Access Key ID·Secret·Session Token)는 User, Group, Role의 차이에서 설명한 그 형태 그대로다. 함께 오는 Expiration 필드가 이 세션의 유통기한이고, AWS SDK들은 만료 5분쯤 전부터 알아서 재요청을 건다. 그래서 내 코드는 자격증명 교체를 직접 돌볼 필요가 없다. 여기까지가 Instance Profile이 자동화하는 부분이다.

IMDSv1과 IMDSv2: 토큰 한 장이 끼어든 이유

원래 IMDS는 단순한 GET 한 번이면 끝이었다(IMDSv1). 문제는 애플리케이션이 SSRF 취약점을 가지면, 외부 공격자가 "이 URL을 서버더러 대신 fetch해 줘"라고 시켜 IMDS에서 자격증명을 그대로 빼낼 수 있다는 점이다. 2019년 Capital One 유출 사건에서도 업계 보고는 유사한 경로를 거론했다. 다만 AWS 공식 문서는 그 경로를 원인으로 분명히 단정하지는 않는다.

IMDSv2는 두 단계로 바꾼다. 먼저 PUT /latest/api/token으로 세션 토큰을 받고(TTL 1–21,600초, 최대 6시간), 실제 메타데이터 요청에 그 토큰을 X-aws-ec2-metadata-token 헤더로 붙인다. AWS가 공식 블로그에서 내세우는 방어 포인트는 두 가지다. 외부에 열린 WAF/리버스 프록시가 대체로 PUT은 막고, IMDSv2는 X-Forwarded-For가 붙은 PUT은 아예 거부한다. "GET만 쓰는 모든 SSRF를 막는다"는 포괄적 방어가 아니라, 열린 프록시 + SSRF라는 흔한 노출 패턴을 좁히는 방어 장치로 읽는 게 맞다.

여기서 자주 발목 잡히는 세부가 PUT 응답의 hop limit이다. 기본값은 1이라서, Docker 컨테이너 안에서 IMDS를 부르면 한 홉이 더 필요해 실패한다. AWS는 imds-support=v2.0으로 등록된 AMI(Amazon Linux 2023 등)는 런치 시 자동으로 hop limit을 2로 맞춰 준다. 그 외에는 인스턴스 메타데이터 옵션에서 수동으로 올려야 한다(최대 64).

2024년 전후의 디폴트 변화

IMDSv1은 "할 수 있다"는 옵션으로 오래 남아 있었는데, 2024-03부터 계정 수준 스위치로 "이 계정에서 시작하는 모든 신규 인스턴스를 IMDSv2-only로"를 한 번에 강제할 수 있게 바뀌었다. AWS는 같은 해 중반부터 새 인스턴스 타입을 IMDSv2-only 기본값으로 내놓기 시작했다. Amazon Linux 2023은 IMDSv1을 끈 상태로 나온다. 최소한 신규 구성은 IMDSv2를 전제로 짜는 게 맞다는 뜻이다.

'관리형'이 감추는 비용, 그리고 언제 쓰지 말아야 하는가

Instance Profile은 Role 교체를 자동화해 주는 대신, IMDS endpoint 자체를 계속 열어 둔다. 그 endpoint를 지키는 책임은 결국 애플리케이션 코드(=SSRF를 안 만드는 것)와 인프라(=hop limit, IMDSv2 강제)로 돌아온다. 자동화가 지운 것처럼 보였던 비용이 관측·보안 쪽으로 이동한 셈이다.

그리고 Instance Profile은 EC2 전용 메커니즘이라는 점도 명확히 해 두는 게 좋다. Lambda는 Execution Role, ECS는 Task Role, EKS Pod은 IRSA(IAM Roles for Service Accounts) 혹은 EKS Pod Identity로 같은 문제를 푼다. "관리형 서비스에 IAM을 붙이고 싶다"는 욕구가 생기면, 먼저 그 서비스가 EC2 기반인지부터 확인하자. EC2 기반이 아니면 Instance Profile은 답이 아니다.

정리

여기서 남은 구간은 Role을 만들고(User, Group, Role의 차이), 임시 자격증명을 발급하고(Assume Role에서 임시 자격증명이 만들어지는 순간), 그 자격증명을 EC2라는 실행 환경에 얹는 단계다. 키를 심지 않고도 API가 통하는 구조는 Instance Profile + IMDS 두 장치 덕분이다. 이 권한 구조를 검증할 때는 IAM Access Analyzer를 쓴다.