ARN

ARN은 특정 패턴을 따르는 문자열이다. 기본 구조는 다음과 같이 다섯 가지 주요 부분으로 구성된다.

resource 부분은 서비스에 따라 가장 복잡한 구조를 가진다. 일반적으로 리소스 유형과 리소스 이름을 구분자(/ 또는 :)로 결합하여 표현한다. 예를 들어, IAM 사용자 ARN은 user/JohnDoe 형식이고, Lambda 함수 ARN은 function:my-function:prod와 같은 형식을 사용할 수 있다. 이 구분자와 추가 한정자(예: Lambda의 Alias 또는 버전)는 각 AWS 서비스의 문서에 정의된 패턴을 따른다.

ARN 문자열의 완전한 형식은 다음과 같다.

arn:partition:service:region:account-id:resource

각 구성 요소는 콜론(:)으로 구분된다. 특정 구성 요소가 적용되지 않는 경우(예: 글로벌 서비스의 region), 해당 필드는 비워두지만 구분자 콜론은 유지한다. 이 표준화된 구조 덕분에 AWS 내부 시스템과 사용자 모두가 문자열을 파싱하여 리소스의 소속 서비스, 계정, 지역 및 정확한 식별자를 일관되게 이해할 수 있다.

각 AWS 서비스는 고유한 리소스 계층 구조와 명명 규칙을 가지며, 이는 ARN 형식에 반영됩니다. 서비스별 ARN 패턴은 일반적으로 서비스 식별자, 리전, 계정 ID, 그리고 서비스 고유의 리소스 경로를 포함합니다. 예를 들어, Amazon S3 버킷의 ARN은 arn:aws:s3:::bucket_name 형식을 따르며, 객체 키를 포함할 경우 arn:aws:s3:::bucket_name/key_name이 됩니다. AWS Lambda 함수의 ARN은 arn:aws:lambda:region:account-id:function:function-name과 같은 구조를 가집니다.

일부 서비스는 특정 리소스 유형에 따라 추가 한정자를 요구합니다. Amazon EC2 인스턴스의 ARN은 arn:aws:ec2:region:account-id:instance/instance-id 패턴을 사용합니다. IAM 사용자, 그룹, 역할의 ARN은 리전 요소를 포함하지 않는 것이 특징입니다. 예를 들어 IAM 역할의 ARN은 arn:aws:iam::account-id:role/role-name 형식입니다. Amazon RDS 데이터베이스 인스턴스의 ARN은 arn:aws:rds:region:account-id:db:db-instance-name과 같이 구성됩니다.

서비스에 따라 리소스 경로 내에 여러 계층이 존재할 수 있습니다. Amazon API Gateway의 ARN은 REST API, 스테이지, 리소스, 메서드 등을 구체적으로 지정할 수 있습니다. 예시: arn:aws:apigateway:region::/restapis/api-id/stages/stage-name. KMS 키의 ARN은 키 ID 또는 별칭을 포함하며, arn:aws:kms:region:account-id:key/key-id 또는 arn:aws:kms:region:account-id:alias/alias-name 형식을 가집니다.

아래 표는 주요 AWS 서비스의 ARN 패턴 예시를 보여줍니다.

이러한 패턴의 차이는 각 서비스의 리소스 모델과 관리 방식에 기인합니다. 정확한 ARN 형식은 서비스의 공식 문서를 참조하는 것이 가장 확실합니다.

IAM 정책에서 ARN은 정책 문서 내에서 허용(Allow) 또는 거부(Deny)할 정확한 대상을 지정하는 데 사용되는 핵심 요소이다. 정책은 주로 "Effect", "Action", "Resource" 필드로 구성되며, Resource 필드에는 하나 이상의 ARN이 명시된다. 이를 통해 특정 AWS 서비스의 특정 작업(예: s3:GetObject)이 적용될 리소스의 범위를 제한할 수 있다. 와일드카드(*)를 사용하여 특정 패턴을 가진 여러 리소스를 한 번에 지정하는 것도 일반적이다.

IAM 정책에서 ARN을 활용하는 주요 패턴은 다음과 같다.

권한 관리를 효과적으로 하기 위해서는 최소 권한 원칙을 준수하는 것이 중요하다. 이는 사용자, 역할, 그룹에 작업 수행에 필요한 최소한의 권한만 부여하는 것을 의미한다. 광범위한 와일드카드(예: *) 사용은 보안 위험을 초래할 수 있으므로, 가능한 한 구체적인 ARN을 사용하여 리소스 범위를 제한해야 한다. 또한, 정책 시뮬레이터나 Access Analyzer와 같은 AWS 도구를 활용하면 ARN 기반 정책의 효과를 사전에 검증할 수 있다.

ARN은 AWS 내에서 리소스를 고유하게 식별하는 동시에, 서로 다른 리소스 간의 관계를 설정하고 참조하는 데 핵심적인 역할을 한다. 예를 들어, 하나의 서비스가 다른 서비스의 리소스를 사용하도록 허용하거나, 이벤트 소스와 대상을 연결할 때 ARN이 참조 지점으로 사용된다. 이는 AWS의 서비스 지향 아키텍처에서 리소스 간의 상호작용을 가능하게 하는 기본 메커니즘이다.

구체적인 사용 예로, AWS Lambda 함수가 특정 Amazon S3 버킷의 객체 생성 이벤트를 처리하도록 설정할 수 있다. 이때 Lambda 함수는 자신의 ARN으로 식별되고, S3 버킷은 버킷 ARN으로 식별된다. S3 서비스는 이벤트 알림 구성 시 대상 Lambda 함수를 지정하기 위해 해당 함수의 ARN을 사용한다. 마찬가지로, Amazon SQS 대기열에 메시지를 보낼 수 있는 권한을 부여하는 IAM 정책에서도 수신자 SQS 대기열의 ARN이 명시된다.

서비스 간 통합에서 ARN의 참조는 다음과 같은 패턴을 보인다.

이러한 참조 구조는 AWS 생태계를 하나의 통합된 플랫폼으로 만든다. 리소스가 물리적 위치나 내부 식별자에 의존하지 않고, 표준화된 ARN을 통해 논리적으로 연결된다. 결과적으로 사용자는 복잡한 인프라 구성 요소들을 선언적이고 유연하게 조합하여 애플리케이션을 구축할 수 있다.

S3 버킷의 ARN은 arn:aws:s3:::bucket_name 형식을 따릅니다. 객체 키를 포함할 경우 arn:aws:s3:::bucket_name/key_name과 같이 표현합니다. S3 ARN은 버킷 정책이나 IAM 정책에서 특정 버킷이나 객체에 대한 접근 권한을 부여하거나 제한하는 데 광범위하게 사용됩니다. 특히 교차 계정 접근이나 세분화된 권한 설정 시 필수적입니다.

IAM 자체의 리소스, 예를 들어 사용자, 그룹, 역할, 정책을 식별하는 데 ARN이 사용됩니다. IAM 사용자 ARN은 arn:aws:iam::account-id:user/user-name 패턴을 갖습니다. IAM 역할 ARN은 신뢰 정책이나 권한 정책에서 해당 역할을 가정할 수 있는 주체를 지정할 때 핵심 요소로 작동합니다. IAM 정책 문서 내에서는 Resource 필드에 ARN을 명시하여 정책이 적용될 대상을 한정합니다.

AWS Lambda 함수의 ARN은 arn:aws:lambda:region:account-id:function:function-name 구조를 가집니다. 별칭이나 특정 버전을 지정하려면 function:function-name:alias_or_version 형식으로 추가합니다. 이 ARN은 Amazon API Gateway의 통합 대상으로 지정하거나, Amazon EventBridge 규칙의 타겟으로 설정하거나, 다른 서비스가 Lambda 함수를 호출할 수 있도록 권한을 부여할 때 필요합니다. Lambda 함수의 실행 역할 정책에서도 자신의 ARN이나 관련 리소스(예: 계층)의 ARN이 참조됩니다.

EC2 인스턴스, EBS 볼륨, 보안 그룹 등의 ARN은 리전과 계정 ID를 명시적으로 포함하는 경우가 많습니다. 일반적인 EC2 인스턴스의 ARN 형식은 arn:aws:ec2:<region>:<account-id>:instance/<instance-id>입니다. VPC, 서브넷, 라우팅 테이블과 같은 네트워킹 리소스도 유사한 패턴을 따르며, 리전 의존성이 강합니다. 일부 글로벌 서비스(예: IAM)와 달리, 대부분의 EC2 리소스 ARN은 특정 리전을 지정해야 정상적으로 동작합니다.

RDS의 ARN 구조는 데이터베이스 엔진 유형(예: MySQL, PostgreSQL)과 무관하게 일관된 패턴을 가집니다. RDS 데이터베이스 인스턴스의 ARN은 arn:aws:rds:<region>:<account-id>:db:<db-instance-identifier> 형식입니다. RDS 클러스터(예: Aurora)의 경우 cluster: 리소스 유형을 사용합니다. RDS 스냅샷, 파라미터 그룹, 옵션 그룹 등의 보조 리소스도 각각 snapshot:, pg:, og:와 같은 고유한 리소스 식별자를 가집니다.

VPC 리소스의 ARN은 다른 서비스와의 통합 시 중요합니다. VPC 자체의 ARN은 arn:aws:ec2:<region>:<account-id>:vpc/<vpc-id>입니다. VPC 피어링 연결, 인터넷 게이트웨이, NAT 게이트웨이 등도 모두 고유한 ARN을 가지며, 이러한 ARN은 IAM 정책에서 네트워크 리소스에 대한 세밀한 접근 제어를 정의하거나, CloudFormation 및 Terraform과 같은 인프라 관리 도구에서 리소스를 참조할 때 사용됩니다. VPC 엔드포인트 서비스와 연결된 리소스 정책에서도 ARN이 주요 식별자로 활용됩니다.

AWS 리소스에 일관된 이름을 부여하는 것은 ARN 관리의 기초가 된다. 명확한 명명 규칙을 수립하면 리소스를 식별하고 소유자를 파악하며, IAM 정책을 작성할 때 복잡성을 줄일 수 있다. 일반적으로 조직명, 환경(예: prod, dev, staging), AWS 리전, 서비스명, 리소스의 목적이나 기능을 조합하여 체계적으로 구성한다.

일관된 명명 규칙을 적용하면 여러 가지 운영상의 이점을 얻을 수 있다. 자동화 스크립트나 인프라스트럭처 코드에서 리소스를 보다 쉽게 필터링하고 참조할 수 있다. 또한, 클라우드포메이션 스택이나 테라폼 모듈을 통해 리소스를 생성할 때 일관된 태깅과 결합하면 비용 추적과 리소스 관리 효율성을 크게 향상시킨다.

효과적인 명명 규칙을 설계할 때는 다음 원칙을 고려하는 것이 좋다.

이러한 규칙은 팀 또는 조직 전체에 문서화되어 공유되고 준수되어야 그 효과를 발휘한다. 규칙을 지키지 않은 리소스는 추후 관리 부담과 보안 위험을 초래할 수 있다[5]. 따라서 AWS Config나 타사 관리 도구를 활용하여 명명 규칙 준수 여부를 지속적으로 모니터링하고 검증하는 절차를 마련하는 것이 바람직하다.

AWS 리소스에 대한 접근을 제어할 때, 최소 권한 원칙을 준수하는 것은 보안 태세를 강화하는 핵심 요소이다. 이 원칙은 사용자, 역할, 애플리케이션이 자신의 작업을 수행하는 데 필요한 최소한의 권한만 부여받아야 한다는 개념이다. ARN은 이 원칙을 실천하는 데 필수적인 도구로, 정책 문서 내에서 특정 리소스를 정밀하게 지정할 수 있게 해준다. 광범위한 와일드카드(*) 사용을 지양하고, 가능한 한 구체적인 ARN을 사용하여 권한 범위를 제한해야 한다[6].

IAM 정책을 설계할 때는 리소스 ARN 필드를 최대한 활용하여 권한의 대상을 명확히 해야 한다. 서비스 전체(arn:aws:s3:::*)나 계정 내 모든 리소스(arn:aws:s3:::)에 대한 접근을 허용하는 정책은 심각한 보안 위험을 초래할 수 있다. 대신, 특정 버킷, 특정 람다(Lambda) 함수 버전, 특정 EC2 인스턴스와 같이 작업에 필요한 정확한 리소스를 ARN으로 열거하는 것이 바람직하다. 이 접근 방식은 권한 상승 또는 의도하지 않은 데이터 유출 가능성을 크게 줄인다.

정기적인 IAM 정책 감사와 ARN 검토는 지속적인 보안 관리의 일환이 된다. 사용되지 않는 권한이나 과도하게 넓은 범위의 ARN 지정을 발견하면 즉시 정책을 수정해야 한다. 또한, 조건(Condition) 키와 ARN을 결합하여 추가적인 보안 계층을 적용할 수 있다[7]. 이러한 세분화된 제어는 ARN의 정확한 지정과 함께 작동하여 AWS 환경의 공격 표면을 최소화한다.

잘못된 ARN 형식은 AWS 환경에서 자주 발생하는 오류 원인 중 하나이다. 이러한 오류는 주로 IAM 정책 작성, AWS CLI 명령어 실행, AWS SDK를 통한 API 호출 시에 나타난다.

주요 오류 유형과 원인은 다음과 같다.

이러한 오류를 진단할 때는 먼저 AWS 서비스 문서에서 해당 리소스의 정확한 ARN 형식을 확인하는 것이 중요하다. AWS Management Console에서 리소스의 ARN을 직접 복사하여 참조하는 방법도 유용하다. 또한, IAM 정책 시뮬레이터나 AWS CloudTrail 로그를 활용하면 ARN 관련 권한 문제를 구체적으로 파악할 수 있다. 오류 메시지에 포함된 리소스 식별자를 자세히 검토하면 어느 부분이 틀렸는지 빠르게 찾아낼 수 있다.

ARN을 사용하는 AWS 환경에서 권한 문제는 일반적인 장애 원인 중 하나이다. 권한 문제를 효과적으로 진단하려면 IAM 정책, 리소스 기반 정책, 그리고 ARN 자체의 정확성을 체계적으로 검토해야 한다.

진단은 일반적으로 다음과 같은 단계로 진행된다. 먼저, 발생한 오류 메시지를 확인한다. AWS 서비스는 종종 "Access Denied" 또는 "UnauthorizedOperation"과 같은 명시적인 오류와 함께, 문제의 ARN이나 요청된 작업을 로그에 기록한다. 다음으로, 해당 오류를 유발한 주체(사용자, 역할, 애플리케이션)가 사용 중인 자격 증명을 확인한다. 이 자격 증명에 첨부된 IAM 정책이 의도한 리소스(ARN)와 작업에 대한 허용(Allow) 명령문을 포함하고 있는지 검토해야 한다. 특히 정책의 Resource 필드에 지정된 ARN이 실제 대상 리소스와 정확히 일치하는지, 와일드카드(*) 사용이 적절한지 확인한다.

더 복잡한 경우, 교차 계정 접근이나 서비스 연동 역할을 사용할 때 문제가 발생한다. 예를 들어, 계정 A의 IAM 역할이 계정 B의 S3 버킷에 접근하려면, 역할의 신뢰 정책과 S3 버킷 정책 양쪽 모두에서 올바른 ARN을 사용해 상호 권한을 부여해야 한다. IAM 정책 시뮬레이터는 특정 자격 증명과 ARN 조합에 대해 정책을 시뮬레이션하여 권한 부여 결과를 예측하는 데 유용한 도구이다. 모든 허용 규칙을 통과했음에도 접근이 거부된다면, 상위 수준의 권한 경계나 서비스 제한 정책(SCP)에 의한 명시적 거부를 의심해 봐야 한다.