105 lines
10 KiB
Markdown
105 lines
10 KiB
Markdown
---
|
||
title: company-tech-blog / AWS IAM ARN Format — 계층적 리소스 식별자 구조 (case study)
|
||
source_type: company-tech-blog
|
||
url: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html
|
||
archive_url:
|
||
related_branches: [feature-resource-identifier-contract]
|
||
related_projects: [ca-skeleton]
|
||
tags: [company-tech-blog, ca-skeleton, api-design, aws, resource-identifier]
|
||
created: 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
|
||
|
||
- 원본 URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html
|
||
- 아카이브 URL: (미보관)
|
||
- 저자 / 조직: AWS (Amazon Web Services)
|
||
- 발행일: 지속 갱신 (AWS 공식 문서)
|
||
- 마지막 확인일: 2026-05-31
|
||
|
||
## 왜 저장했는지 / 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 / 관련
|
||
|
||
- [[raw/company-tech-blogs/api-versioning-stripe-date-based]] — Stripe typed prefix (`tk_`, `usr_`) 의 flat 2-field 패턴 (ARN 계층 구조의 단순화 대안)
|
||
- [[raw/branch-notes/feature-resource-identifier-contract]] — 이 자료를 인용하는 parent branch
|
||
- (생성 후) [[wiki/concepts/resource-identifier-format]] — ingest 후 canonical 요약 예정
|