- Coverage by target cloud
- How the backends compare
- On Azure
- Costs
- Service level agreements
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of AppConfig with its adaptation on each backend. A dash means this row is not stated for that backend.Infrastructure-only adaptation
On Azure
How it works
Azure App Configuration replaces AWS AppConfig as the source of your feature flags and dynamic configuration. You change the application to read through the Azure App Configuration SDK, from a Microsoft-managed store in the customer’s subscription, instead of from the AppConfig agent. At deployment, Terraform creates the flags and key-values from your AppConfig configuration document. Each flag keeps its enabled state. AppConfig’s gradual rollout, deployment monitoring and automatic rollback are not recreated; your release process takes them over.
Your application reads flags and values through the App Configuration SDK, from a store Microsoft runs.
Architecture
The deployment creates anazurerm_app_configuration store on the standard SKU in the customer’s subscription, one azurerm_app_configuration_feature for each AppConfig feature flag, and one azurerm_app_configuration_key for each top-level free-form key. Microsoft runs the store’s storage, replication and availability. The flags and values live in the customer’s own store.
The application connects directly to App Configuration with its SDK and the workload’s Azure identity. No Tensor9 component sits in the read path.
Terraform creates the store and its entries; your application then reads the store directly.
Creating flags and configuration keys
AnAWS.AppConfig.FeatureFlags profile has a top-level values map with one entry per flag: an enabled boolean and optional typed attributes. The deployment creates one App Configuration feature flag per entry, with the same enabled state. Typed attributes, multivariate variants, constraints and _deprecation are not kept. The deployment reports a warning naming the affected flags; re-create those values as feature filters or typed keys.
A profile that holds a free-form JSON object becomes key-values in the same store, one per top-level key. App Configuration does not apply AppConfig’s declared types or constraints, so validate new content before you provision it.
Each flag keeps its enabled state; typed attributes are dropped with a warning, and free-form keys become key-values.
Reading at runtime
Your application replaces reads from the AppConfig agent’s local endpoint with the Azure App Configuration SDK. Feature flags use App Configuration’s feature-flag key convention and content type, so the SDK and the Feature Management libraries read each flag’s enabled state and keep flags apart from ordinary key-values. Free-form configuration is read as regular key-values from the same store, and SSM Parameter Store values mapped to App Configuration can share it too. The SDK caches keys and flags and refreshes them on an interval or when a change signal arrives, so reads from the cache make no network request per value. It authenticates with the workload’s Azure identity; no separate credential is needed.Environments
AppConfig scopes configuration by application and environment, so one flag can be on in a test environment and off in production. App Configuration uses labels for this: a key or flag can hold a different value under each label, and the SDK chooses a label when it reads. The deployment creates each flag and key without a label. To serve several environments from one store, add labelled values and have each workload read its own label. The AppConfig application and configuration-profile hierarchy is not recreated, and profile versions and deployment history are not imported. App Configuration keeps its own key-value revision history from the deployment onward. Keep the AppConfig source history in the system that provisions the store.Limitations
- Gradual rollout is not supported. App Configuration serves the current value, with no managed ramp (growth type, growth factor, final bake time). To roll out a change gradually, have the application read a percentage value and change it on a schedule from your release pipeline.
- Monitored deployments and rollback are not supported. There is no deployment object to stop or roll back. A rollback means republishing the prior value, by hand or from your pipeline; the store’s revision history keeps that value available.
- Automatic rollback on a CloudWatch alarm is not supported. App Configuration does not watch a metric. Build a pipeline step that watches the signal and republishes the prior value on a bad reading.
- Validators are not supported. JSON Schema and Lambda validators do not run when a value changes. Run that validation in CI, on the flag content, before it is provisioned.
- Typed flag attributes and variants are not supported. Only each flag’s enabled state is created. Attributes, variants, constraints and
_deprecationare dropped with a deployment warning; re-create them as feature filters or typed keys. - Configuration that is not a JSON object is not supported. A YAML or plain-text profile, or a body that does not parse as a JSON object, creates the store with no flags or keys.
- Environments behave differently: you set up labels yourself. Entries are created without a label, and the AppConfig application and profile hierarchy is flattened into one store.
Other considerations
- Before cutover. Terraform creates flags and key-values from the configuration document. If AppConfig changes during cutover, update the document before applying Terraform.
- Release controls. Plan the replacement gradual rollout, validation and monitoring-driven rollback alongside the SDK change, in the process that provisions the store.
- Operations and ownership. Microsoft runs the store’s storage, replication and availability; there is no server and no Tensor9 component for you to operate. You own the subscription, the store’s SKU and access policy, the SDK cache settings and the identity the workload reads with.
Example monthly charges
This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include. Native or deployment mapping. Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path. Cost estimates describe the selected service resources; operation coverage remains separate.AWS AppConfig · Configuration polls
Feature: AWS AppConfig. Estimated monthly service charges by Configuration polls. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
Curve assumptions
- Monthly operation quantity varies with this steady average rate; stored inventory and other meters retain their defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
- Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month.
- Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
- Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
- Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
- Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
- Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
- Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
- Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
- A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
- This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
- Native/deployment comparison scope: Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path.
- Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
- AppConfig configuration is installed at deployment. Applications read Flagsmith or Azure App Configuration using the target SDK; there is no runtime adapter read path.
- Target read work scales with polls, but deployment writes scale with authored configuration changes, not the number of delivered client updates.
- Managed rollout, validators and alarm rollback do not follow from a lower storage or read price.
- Each Standard configuration store bills USD 1.20/day (36.50 for a 730-hour month) and includes 200,000 requests a day; only overage requests bill. The included 200,000 x 30.4167 days = 6,083,340 requests are one store’s monthly allowance; raise it when storeCount is above one. Each store includes 1 GB of storage. Free (USD 0) and Developer (0.12/day) stores are not selected.
- AWS Price List API, AWSSystemsManager offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSSystemsManager/current/us-east-1/index.json
- Azure Retail Prices API: https://prices.azure.com/api/retail/prices
- Azure App Configuration pricing: https://azure.microsoft.com/en-us/pricing/details/app-configuration/
- Free allowances, committed discounts, credits, taxes and negotiated rates.
- Commercial Tensor9 fees and operations labor unless entered separately.
- Client polling egress, rollout tooling, premium Flagsmith licensing and release-pipeline execution.
- Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
- Unmodeled dependent services, task execution and operations outside the selected workload family.
plan-9119bf81dba22c886cf0a79d83cf91147ac02bb1 / 2026-10-22.planning.2. Curve: workload-1.
Sources: AWS Price List API, AWSSystemsManager offer, Azure Retail Prices API, Azure App Configuration pricing.
AWS AppConfig → Azure App Configuration: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts.
Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD.
Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs.
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied.
Excluded costs and workload features:
- Free allowances, committed discounts, credits, taxes and negotiated rates.
- Commercial Tensor9 fees and operations labor unless entered separately.
- Client polling egress, rollout tooling, premium Flagsmith licensing and release-pipeline execution.
- Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
- Unmodeled dependent services, task execution and operations outside the selected workload family.
- Translated reads: 10,000,000 operations.
- Translated writes: 100 operations.
- Translated resident physical data: 1 GiB-month.
- Native provider operations: 10,000,100 operations.
- Published payload: 0 GiB.
- Delivered payload: 0 GiB.
- Allocated execution CPU: 0 vCPU-hour.
- Allocated execution RAM: 0 GiB-hour.
- Independent resource allocation: 0 resource-hour.
- Independent inventory: 1 resource-month.
- Input tokens: 0 tokens.
- Output tokens: 0 tokens.
- Billable network: 0 GiB.
- Dependent object sink retained data: 0 GiB-month.
- Dependent object sink writes: 0 writes.
- Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
- Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
- Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
- Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
- A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
- This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
- Native/deployment comparison scope: Configuration is seeded during deployment and read through the target’s native SDK. There is no AppConfig request-serving adapter on this path.
- Origin unit prices are cited provider list prices. Retention, amplification, and capacity coefficients are authored planning guesses; they are editable, not measured capacity.
- AppConfig configuration is installed at deployment. Applications read Flagsmith or Azure App Configuration using the target SDK; there is no runtime adapter read path.
- Target read work scales with polls, but deployment writes scale with authored configuration changes, not the number of delivered client updates.
- Managed rollout, validators and alarm rollback do not follow from a lower storage or read price.
- Each Standard configuration store bills USD 1.20/day (36.50 for a 730-hour month) and includes 200,000 requests a day; only overage requests bill. The included 200,000 x 30.4167 days = 6,083,340 requests are one store’s monthly allowance; raise it when storeCount is above one. Each store includes 1 GB of storage. Free (USD 0) and Developer (0.12/day) stores are not selected.
plan-9119bf81dba22c886cf0a79d83cf91147ac02bb1 / 2026-10-22.planning.2. Scenario: planning-example.
Sources: AWS Price List API, AWSSystemsManager offer, Azure Retail Prices API, Azure App Configuration pricing.
Costs
Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications.
Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows.
Cost curves across workload sizes, with every assumption and exclusion: AppConfig costs.