EC2에 IAM 역할을 연결하고 애플리케이션에서 S3 파일을 열어 봅니다. 파일이 정상적으로 열려도 전환이 끝났다고 판단하기는 이릅니다. 코드나 서비스 설정에 남은 액세스 키로 요청했을 수 있기 때문입니다. 이 글은 같은 AWS 계정의 S3에서 정산 파일을 읽는 Python 애플리케이션을 가정해, 어디를 바꾸고 어떤 결과를 확인해야 하는지 살펴봅니다.
역할을 붙인 뒤 서비스의 키 설정을 분리
EC2는 인스턴스 프로파일을 통해 IAM 역할을 연결합니다. 인스턴스 메타데이터 서비스(IMDS)를 사용할 수 있으면 Boto3는 여기서 역할의 임시 자격 증명을 받아 사용하고 만료 전에 갱신합니다. 새 역할을 만들 때는 EC2 서비스가 역할을 맡도록 신뢰 관계를 구성합니다. AWS EC2 사용 설명서 — EC2용 IAM 역할
먼저 인스턴스에 연결된 역할이 있는지 확인합니다. EC2 한 대에 연결할 수 있는 역할은 하나입니다. 같은 서버에서 여러 서비스가 실행되고 각 프로세스가 IMDS에 접근할 수 있다면 동일한 역할 권한을 사용할 수 있으므로, 권한을 추가하기 전에 함께 실행되는 서비스도 확인합니다.
Boto3는 클라이언트나 세션에 직접 넘긴 키, 환경변수, 공유 자격 증명 파일 등을 인스턴스 메타데이터보다 먼저 확인합니다. aws_access_key_id와 aws_secret_access_key 인자를 제거한 뒤에도 서비스 실행 환경에 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY가 남아 있으면 기존 키를 선택할 수 있습니다. 서비스 유닛의 환경 파일, 배포 설정, 서비스 계정의 ~/.aws/credentials, AWS_PROFILE이 지정한 프로파일까지 실제 실행 환경을 기준으로 확인합니다. AWS SDK for Python — Boto3 자격 증명 탐색 순서
요약 점검 범위는 코드에서 시작해 서비스가 실행될 때 키를 전달받는 경로까지 이어집니다.
기존 키의 권한을 복사하기 전에 S3 호출을 분리
가정한 애플리케이션은 reports/ 아래 정산 파일의 전체 객체 키를 알고 있습니다. 이 경우 읽기에 필요한 s3:GetObject 권한을 arn:aws:s3:::example-report-bucket/reports/*로 제한하는 것부터 검토합니다. example-report-bucket은 예시 이름입니다. Amazon S3 사용 설명서 — 자격 증명 기반 정책 예시
파일명 검색이나 목록 조회가 실제로 필요하면 s3:ListBucket을 버킷 ARN에 별도로 부여하고, s3:prefix 조건을 애플리케이션이 요청하는 접두사에 맞춥니다. 대상 객체가 SSE-KMS로 암호화됐다면 다운로드에 필요한 kms:Decrypt와 해당 KMS 키 정책도 확인합니다. 이 예시의 업무는 파일 읽기이므로 업로드·삭제 권한은 정책에서 제외합니다. Amazon S3 사용 설명서 — SSE-KMS 사용 시 권한
요약 파일 조회 방식이 정해지면 객체 읽기, 목록 조회, 복호화의 권한 범위를 각각 판단할 수 있습니다.
서비스가 사용하는 역할과 파일 읽기를 따로 확인
먼저 테스트 인스턴스에서 역할 연결과 서비스 설정 변경을 적용하고 프로세스를 다시 시작합니다. S3 클라이언트에 키를 직접 넘기는 설정이 제거됐는지 확인합니다. 이어서 그 클라이언트를 만든 Boto3 세션으로 STS GetCallerIdentity를 호출해 Arn을 확인합니다. 기존 IAM 사용자의 ARN이 나오면 키가 주입되는 경로부터 다시 확인합니다. assumed-role이 보이면 예상한 AWS 계정과 역할 이름까지 대조합니다. 터미널에 로그인한 운영자의 AWS CLI는 서비스와 다른 자격 증명을 쓸 수 있습니다. AWS STS API 참조 — GetCallerIdentity
이어서 애플리케이션의 정상 경로로 reports/ 아래의 테스트 파일을 읽습니다. 호출 주체가 맞는데 파일 읽기가 거부되면 요청한 객체 키와 역할의 허용 범위를 대조합니다. 그다음 버킷 정책의 명시적 거부나 SSE-KMS 적용 여부처럼 해당 요청에 영향을 주는 조건을 살핍니다.
요약 역할 ARN은 요청의 주체를 알려 주고, 파일 읽기 결과는 해당 업무를 수행할 수 있는지 보여 줍니다.
기존 키의 사용처를 확인한 뒤 폐기
운영 배포는 먼저 일부 인스턴스에 적용해 같은 두 가지를 확인합니다. 서비스가 정상이라도 이전 키를 공용 배치나 다른 서버가 함께 썼다면 비활성화할 때 다른 작업이 실패할 수 있습니다. 배포 설정과 IAM의 키 마지막 사용 정보 등을 대조하고, 정산처럼 주기가 긴 작업은 실행 주기도 함께 살핍니다. 마지막 사용 정보는 다른 사용처를 확인하는 단서로 활용합니다.
공유 사용처까지 전환했다면 기존 키를 비활성화하고 필요한 작업의 정상 수행을 확인한 뒤 삭제합니다. 키가 저장소나 빌드 산출물에 들어간 적이 있다면 소스에서 지운 뒤에도 과거 사본에 남을 수 있습니다. 유출이 의심되는 키는 일반 전환 일정과 별개로 신속히 비활성화하고 사용 내역을 조사합니다.
결론
전환 완료 기준은 서비스 프로세스에서 확인한 역할 ARN, 필요한 S3 작업의 성공, 기존 키의 폐기입니다. 세 항목을 배포 기록에 남겨 두면 이후 인스턴스 교체나 애플리케이션 재배포 때도 같은 기준으로 확인할 수 있습니다.