donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
d6dfda64ab42a97de02624a406caafe594db2d8d
llm-wiki/raw/company-tech-blogs/aws-iam-arn-format.md
T

10 KiB
Raw Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created
title source_type url archive_url related_branches related_projects tags created
company-tech-blog / AWS IAM ARN Format — 계층적 리소스 식별자 구조 (case study) company-tech-blog https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html
feature-resource-identifier-contract
ca-skeleton
company-tech-blog
ca-skeleton
api-design
aws
resource-identifier
2026-05-31

AWS IAM ARN Format — 계층적 리소스 식별자 구조 (case study)

Layer: raw/company-tech-blogs/ — AWS 공식 문서이지만 ca-skeleton 의 관점에서는 계층적 식별자 패턴의 극단적 사례(case study) 로 분류. 이 문서가 기술하는 ARN 규격은 AWS 인프라에 특화된 규약이며 일반 REST API 의 normative standard 가 아님.

source_type 결정 근거: AWS docs 는 기술적으로 official-doc 이지만, ca-skeleton ID 정책(D6 prefix, D13 multi-tenancy) 의 맥락에서는 "AWS 가 이 패턴을 어떻게 적용하는가" 라는 사례 증거 로만 활용. 공식 표준이 아닌 단일 벤더의 구현 관례로 취급하므로 company-tech-blog 로 보관. Claim Strength 는 official-vendor-doc 으로 기록하되 Usage Boundaries 에 한계를 명시.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-resource-identifier-contract D6 (prefix 정책) — typed prefix 가 대규모 multi-service 환경에서 어떻게 동작하는지 AWS ARN 의 arn:partition:service:... 계층 prefix 로 증명. D13 (multi-tenancy encoding) — partition / region / account-id 를 ID 자체에 직접 인코딩하는 패턴의 실사례.

출처 / Source

왜 저장했는지 / Why archived

ca-skeleton 의 resource ID 정책은 "ID 가 메타데이터를 얼마나 인코딩해야 하는가" 를 결정해야 한다. AWS ARN 은 partition / service / region / account-id / resource-type / resource-id 를 콜론으로 구분한 6-field 계층 구조로, "typed prefix at scale" (D6) 과 "multi-tenancy scope 를 ID 에 직접 인코딩" (D13) 의 가장 극단적 실사례다. 채택·거부 모두 이 사례를 반증·반례 삼아 논증할 수 있다.

핵심 인용 / Key quotes (verbatim, 5개)

[§ARN format intro] "Amazon Resource Names (ARNs) uniquely identify AWS resources. We require an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls." — line 3, fetched text

[§ARN format — three variants] Three canonical format lines (colon-delimited, 6 fields):

arn:{{partition}}:{{service}}:{{region}}:{{account-id}}:{{resource-id}}
arn:{{partition}}:{{service}}:{{region}}:{{account-id}}:{{resource-type}}/{{resource-id}}
arn:{{partition}}:{{service}}:{{region}}:{{account-id}}:{{resource-type}}:{{resource-id}}

— lines 9–11, fetched text

[§partition field] "The partition in which the resource is located. A partition is a group of AWS Regions. Each AWS account is scoped to one partition." — line 14, fetched text

[§resource-id field] "The resource identifier. This is the name of the resource, the ID of the resource, or a resource path. Some resource identifiers include a parent resource (sub-resource-type/parent-resource/sub-resource) or a qualifier such as a version (resource-type:resource-name:qualifier)." — line 33, fetched text

[§Paths in ARNs] "Resource ARNs can include a path. For example, in Amazon S3, the resource identifier is an object name that can include forward slashes (/) to form a path. Similarly, IAM user names and group names can include paths. Only alphanumeric characters and the following characters are allowed in IAM paths: forward slash (/), plus (+), equals (=), comma (,), period (.), at (@), underscore (_), and hyphen (-)." — line 46, fetched text

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리. ca-skeleton 의 적용 결론은 Usage Boundaries 와 parent branch Decision Evidence Map 에서 작성.

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
AWS-ARN-C1 ARN 은 6개 필드(partition:service:region:account-id:resource-type:resource-id)를 콜론으로 구분하여 AWS 전역에서 리소스를 고유하게 식별한다 [§ARN format] arn:{{partition}}:{{service}}:{{region}}:{{account-id}}:{{resource-id}} (lines 9–11) official-vendor-doc AWS 모든 서비스의 리소스 참조 (IAM policy, RDS 태그, API 호출) 일반 REST API 의 resource ID 형식이 동일 구조를 따라야 한다는 것; AWS 외 시스템에서의 적용
AWS-ARN-C2 partition 필드는 AWS 리전 그룹을 나타내며 각 AWS 계정은 정확히 하나의 partition 에 속한다 (aws, aws-cn, aws-us-gov 3종) [§partition] "A partition is a group of AWS Regions. Each AWS account is scoped to one partition." (line 14) official-vendor-doc AWS multi-region / GovCloud 격리 설계 일반 SaaS multi-tenancy 모델에 partition 개념이 동일하게 적용됨; tenant 를 partition 으로 매핑하는 것이 best practice 임
AWS-ARN-C3 resource-type 과 resource-id 사이의 구분자는 슬래시(/) 또는 콜론(:) 두 가지 변형이 서비스별로 다르게 사용된다 [§ARN format] arn:...:{{resource-type}}/{{resource-id}} vs arn:...:{{resource-type}}:{{resource-id}} (lines 10–11) official-vendor-doc 서비스 유형에 따른 ARN 구분자 선택 (S3 경로 슬래시 vs IAM 콜론 등) 신규 API 설계에서 어느 구분자를 선택해야 하는지 규범적 지침; 하나가 다른 하나보다 우월함
AWS-ARN-C4 ARN 의 일부 리소스는 region 또는 account-id 를 생략한다 (S3 버킷 등) [§ARN format intro] "Be aware that the ARNs for some resources omit the Region, the account ID, or both the Region and the account ID." official-vendor-doc S3 처럼 전역 namespace 를 가진 서비스 모든 리소스 ID 가 region/account 를 생략할 수 있음; 생략이 권장됨
AWS-ARN-C5 ARN 의 wildcard(*, ?)는 Resource / NotResource 정책 요소에는 사용 가능하지만 resource-type 세그먼트 내부나 partition 세그먼트에는 사용할 수 없다 [§wildcard limitation] "You cannot use a wildcard in the portion of the ARN that specifics the resource type." (line 63) official-vendor-doc IAM policy 의 권한 범위 지정 일반 URL path pattern 의 wildcard 규칙; ARN wildcard 가 다른 identifier 시스템에도 적용됨

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것

  • AWS-ARN-C1: AWS 규모(수십만 리소스 유형 × 수백 리전 × 수억 계정)에서 6-field 계층 prefix 가 전역 고유성을 보장하며 실전 검증된 패턴임.
  • AWS-ARN-C2: "partition" 개념 — 격리된 계정 그룹을 최상위 ID segment 로 인코딩하면 cross-partition 리소스 참조를 ID 파싱만으로 방지할 수 있음.
  • AWS-ARN-C3: 동일 prefix scheme 내에서도 서비스별로 구분자(/ vs :)가 달라질 수 있으며, 이것이 실제로 AWS 에서 용인됨.
  • AWS-ARN-C4: 일부 필드를 생략 가능하게 하면 전역 리소스(S3)와 계정-리전 지역 리소스를 같은 scheme 으로 표현할 수 있음.
  • AWS-ARN-C5: prefix 계층 일부(resource-type)는 wildcard 를 허용하지 않아야 안전한 policy 매칭이 가능함.

이 자료가 증명하지 않는 것

  • AWS ARN 구조가 일반 REST API resource ID 의 best practice 임. ARN 은 AWS-specific 제약 (IAM policy engine, multi-partition global namespace, 수천 개 서비스 공존) 에 최적화된 설계로, 단일 서비스 또는 단일 테넌트 API 에는 과도하게 복잡함.
  • arn: prefix 자체가 typed prefix 의 표준 형태임. AWS ARN 은 회사가 자사 인프라 전체에 적용한 내부 표준이지 ISO/IETF 표준이 아님.
  • ca-skeleton 이 동일 6-field 구조를 채택해야 함. 이 자료는 "typed prefix + 계층 인코딩" 패턴의 실사례 증거이며 채택 근거가 아님.
  • Stripe-style tk_<random> 또는 flat UUID 보다 계층 prefix 가 모든 시나리오에서 우월함.

ca-skeleton 적용 시 추가 확인이 필요한 것

  • D6 prefix 결정: tk_ / usr_ Stripe-style (2-field flat) vs svc:tenant:resource ARN-style (N-field hierarchical) — ca-skeleton minimalist 정신에서 어느 복잡도가 적절한가.
  • D13 multi-tenancy: tenant ID 를 ID 필드에 인코딩할 경우 WHERE tenant_id = X AND id = Y cross-check 의무가 여전히 필요함 (ARN 도 account-id 가 있다고 해서 cross-account 접근이 자동 차단되지는 않음 — IAM policy 가 별도로 강제).

메모 / Notes

  • ARN 의 가장 중요한 교훈: "ID 가 메타데이터를 인코딩하면 파싱으로 scope 를 알 수 있으나, 동시에 scope 가 변경될 때 ID 가 breaking change 를 유발한다." AWS 는 partition/region/account 를 ARN 에 박아 넣었기 때문에 리전 이전 또는 account 통합 시 ARN 이 변경된다.
  • D13 에 대한 counter-argument 로도 쓸 수 있음: ARN 처럼 account-id 를 인코딩해도 IAM policy 없이는 cross-account 접근이 자동으로 막히지 않는다. ID 인코딩은 UX / debugging 보조이지 보안 경계가 아님.
  • resource-type separator (/ vs :) 의 비일관성은 "ID 스킴을 나중에 확장하면 이런 일이 생긴다" 의 반면교사.
  • 추가로 볼 자료: AWS ARN 의 S3 예시 (arn:aws:s3:::bucket-name/key) — account-id 와 region 이 모두 생략된 전역 주소 체계.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink