11 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AWS AppConfig — feature flag + dynamic configuration 공식 문서 | official-doc | https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
AWS AppConfig — feature flag + dynamic configuration
Layer:
raw/official-docs/— AWS Systems Manager AppConfig User Guide "What is AWS AppConfig?" 페이지 (verbatim 발췌).
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-env-driven-runtime-configuration | 대안 3 (AWS managed feature flag + auto-rollback) 의 비용/이득 비교. branch 결정 "env-startup flag 1차 + runtime flag optional + registry row 필수" 와의 대조 자료 |
| raw/branch-notes/feature-secrets-config-source-contract | AppConfig 가 Secrets Manager / Parameter Store / S3 등 외부 store 와 통합하는 점 — secret source-of-truth 분리 결정 비교 |
| raw/branch-notes/feature-rate-limit-idempotency-contract | throttling limit 의 runtime 조정 use case (AppConfig 가 명시적으로 지원) |
컨텍스트 / 왜 저장했는지
ca-tmpl feature-env-driven-runtime-configuration branch 의 대안 3. branch 는 "feature flag 기본값 = env-startup flag, runtime/canary flag 는 optional + registry row 필수" 로 결정. AWS AppConfig 는 같은 문제 영역에 대해 managed deployment strategy + validator + automatic rollback 을 제공. branch 결정의 비용/이득 비교 자료.
출처 / Source
- 원본 URL: https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html
- 아카이브 URL: (미수집)
- 저자 / 조직: AWS (Systems Manager 산하 서비스)
- 발행일: GA, 지속 업데이트
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§What is AWS AppConfig?] "AWS AppConfig feature flags and dynamic configurations help software builders quickly and securely adjust application behavior in production environments without full code deployments."
[§What is AWS AppConfig? — paragraph 2] "With feature flags, you can gradually release new capabilities to users and measure the impact of those changes before fully deploying the new capabilities to all users. With operational flags and dynamic configurations, you can update block lists, allow lists, throttling limits, logging verbosity, and perform other operational tuning to quickly respond to issues in production environments."
[§Benefits overview — Avoid unintended changes / Validators] "Validators: A validator ensures that your configuration data is syntactically and semantically correct before deploying the changes to production environments."
[§Benefits overview — Deployment strategies] "Deployment strategies: A deployment strategy enables you to slowly release changes to production environments over minutes or hours."
[§Benefits overview — Monitoring and automatic rollback] "Monitoring and automatic rollback: AWS AppConfig integrates with Amazon CloudWatch to monitor changes to your applications. If your application becomes unhealthy because of a bad configuration change and that change triggers an alarm in CloudWatch, AWS AppConfig automatically rolls back the change to minimize impact on your application users."
[§How AWS AppConfig works — step 4] "To retrieve the data, your application makes an HTTP call to the localhost server where AWS AppConfig Agent has cached a local copy of your deployed configuration data. Retrieving data is a metered event."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| AWS-APPCONFIG-C1 | AppConfig 는 feature flag + dynamic configuration 을 통해 full code deployment 없이 production application behavior 를 조정할 수 있게 함 | [§What is AWS AppConfig?] "AWS AppConfig feature flags and dynamic configurations help software builders quickly and securely adjust application behavior in production environments without full code deployments." | official-vendor-doc |
AWS 환경에서 AppConfig 사용 | "code deployment 보다 빠르다" 의 정량적 지연 시간은 본 인용 범위 밖 |
| AWS-APPCONFIG-C2 | feature flag 는 gradual rollout + 영향 측정을 지원. operational flag/dynamic config 는 block list / allow list / throttling limit / logging verbosity 등 운영 튜닝에 사용 | [§What is AWS AppConfig? — paragraph 2] "With feature flags, you can gradually release new capabilities to users and measure the impact of those changes before fully deploying the new capabilities to all users. With operational flags and dynamic configurations, you can update block lists, allow lists, throttling limits, logging verbosity, and perform other operational tuning to quickly respond to issues in production environments." | official-vendor-doc |
feature flag / operational flag use case | "측정" 의 구체적 metric 이나 dashboarding 방법은 본 인용 범위 밖 |
| AWS-APPCONFIG-C3 | Validator 는 production 배포 전에 configuration data 가 syntactic + semantic 으로 올바른지 보장 | [§Benefits overview — Validators] "Validators: A validator ensures that your configuration data is syntactically and semantically correct before deploying the changes to production environments." | official-vendor-doc |
AppConfig validator 설정 (JSON Schema / Lambda) | validator 가 정확히 어떤 형식 (JSON Schema/Lambda) 을 지원하는지는 별도 페이지 참조 필요 |
| AWS-APPCONFIG-C4 | Deployment strategy 는 production 변경을 수 분~수 시간에 걸쳐 점진적 release 가능하게 함 | [§Benefits overview — Deployment strategies] "Deployment strategies: A deployment strategy enables you to slowly release changes to production environments over minutes or hours." | official-vendor-doc |
AppConfig deployment 정의 | 구체적 strategy 종류 (Linear / Exponential / Canary 등) 와 default 값은 본 인용 범위 밖 |
| AWS-APPCONFIG-C5 | AppConfig 는 CloudWatch 와 통합되어 application 변화를 모니터링. bad configuration change 가 CloudWatch alarm 을 trigger 하면 자동 rollback | [§Benefits overview — Monitoring and automatic rollback] "AWS AppConfig integrates with Amazon CloudWatch to monitor changes to your applications. If your application becomes unhealthy because of a bad configuration change and that change triggers an alarm in CloudWatch, AWS AppConfig automatically rolls back the change to minimize impact on your application users." | official-vendor-doc |
CloudWatch alarm 이 정의된 AppConfig deployment | "unhealthy" 판정 기준은 alarm 정의에 따라 다르며 본 인용은 default 동작을 명시 안 함 |
| AWS-APPCONFIG-C6 | 데이터 retrieval 은 AppConfig Agent (localhost) 가 cached copy 를 제공. retrieval 은 metered event | [§How AWS AppConfig works — step 4] "To retrieve the data, your application makes an HTTP call to the localhost server where AWS AppConfig Agent has cached a local copy of your deployed configuration data. Retrieving data is a metered event." | official-vendor-doc |
AppConfig Agent sidecar 사용 시 | Agent 없이 직접 API 호출 (StartConfigurationSession/GetLatestConfiguration) 의 비용 차이는 본 인용 범위 밖 (별도 Pricing 섹션 참조) |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
AWS-APPCONFIG-C1~C6: AppConfig 의 4대 safety feature (validator / deployment strategy / monitoring / auto-rollback) + Agent retrieval 모델의 공식 정의
- 이 자료가 증명하지 않는 것:
- 공식 best practice 로서 "feature flag = AppConfig 가 정답": 본 인용은 AppConfig 의 capability 를 설명할 뿐, 다른 도구 (LaunchDarkly, Unleash, env-only) 대비 우위는 다루지 않음
- 실제 latency / availability SLA (별도 AWS SLA 페이지)
- ca-tmpl 의 "env-startup flag 1차" 결정이 틀렸다는 근거 — 본 자료는 대안의 capability 만 보여줌
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- AppConfig Agent 의 caching latency vs polling 부담
- Secrets Manager / Parameter Store 와의 권한 분리 governance
- cost (configuration retrieval per-call billing) 의 ca-tmpl 규모에서의 실제 비용 추산
- company tech blog 사례를 "AWS 공식 best practice" 로 일반화 금지 — 본 raw 는 AWS 공식 user guide capability 만 다룸. 실제 운영 사례는 별도 case study 가 필요
메모 / Notes (내 프로젝트 해석 — PRESERVED)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- 적용 시나리오: AWS 환경에 이미 ECS/EKS/Lambda 를 운영 중이고, feature flag rollout 을 CloudWatch alarm 과 자동 연동하고 싶을 때. block list / allow list / throttling limit 의 runtime 조정.
- 장점:
- Managed: 별도 인프라 운영 없음.
- validator (JSON Schema / Lambda) → branch 가 강조한 "invalid env startup fail-fast" 의 server-side 등가물.
- CloudWatch 알람 기반 자동 rollback — branch 가 명시하지 않은 보완 기능.
- deployment strategy (예: 10%/10min → 50%/30min → 100%) → canary 표준화.
- 단점:
- AWS 종속. multi-cloud / on-prem 부적용.
- cost: configuration retrieval per-call billing.
- latency: AppConfig Agent (sidecar / cache) 필요. 직접 API 호출 시 polling 부담.
- secret 과의 통합은 별도 (Secrets Manager / Parameter Store) 이므로 source-of-truth 분리 학습 필요.
- ca-tmpl 결정과의 차이:
- ca-tmpl: env-startup flag 1차,
APP_FEATURE_*env + env-keys.yaml registry, runtime flag 는owner_branch강제. - AppConfig: managed runtime flag. 다만 branch 의 "registry owner / rollout/rollback rule 강제" 는 AppConfig 자체로는 강제되지 않음 → 별도 governance 레이어 필요.
- ca-tmpl: env-startup flag 1차,
- 채택 시점 후보: AWS-only 배포 + feature flag 종류가 30+ 로 증가 + canary rollback automation 이 SLO 에 들어갈 때.
- 신뢰도:
official-vendor-doc등급. AWS 공식 user guide.
Related / 관련
- 같은 주제 다른 raw:
- (LaunchDarkly / Unleash / Spring Cloud Config 별도 raw — 미작성)
- 인용하는 branch:
- 같은 그룹 대안 raw:
- raw/official-docs/config-spring-cloud-kubernetes-configmap-reload (대안 2 — k8s ConfigMap auto-reload)
- 적용 contract:
- raw/project-notes/ca-skeleton-operational-contract (Env-driven runtime configuration 그룹)
- 인용하는 wiki: (미작성)