Crate aws_sdk_appconfig 

AppConfig helps you safely change application behavior in production without redeploying code. Using feature flags and dynamic free-form configurations, you can control how your application runs in real time. This approach reduces risk, accelerates releases, and enables faster responses to issues. You can gradually roll out new features to specific users, monitor their impact, and expand availability with confidence. You can also update block lists, allow lists, throttling limits, and logging levels instantly, allowing you to mitigate issues and fine-tune performance without a deployment.

AppConfig supports a broad spectrum of use cases:

• Feature flags and toggles – Gradually release new capabilities to targeted users, monitor impact, and instantly roll back changes if issues occur.
• Application tuning – Introduce changes safely in production, measure their effects, and refine behavior without redeploying code.
• Allow list or block list – Control access to features or restrict specific users in real time, without modifying application code.
• Centralized configuration storage – Manage configuration data consistently across workloads. AppConfig can deploy configuration from the AppConfig hosted configuration store, Secrets Manager, Systems Manager, Systems Manager Parameter Store, or Amazon S3.

How AppConfig works

This section provides a high-level description of how AppConfig works and how you get started.

1. Identify configuration data to manage in AppConfig

Before creating a configuration profile, identify the configuration data in your code that you want to manage dynamically using AppConfig. Common examples include feature flags, allow and block lists, logging levels, service limits, and throttling rules. These values tend to change frequently and can cause issues if misconfigured. If your configuration data already exists in cloud services such as Systems Manager Parameter Store or Amazon S3, you can use AppConfig to validate, deploy, and manage that data more effectively.

2. Create a configuration profile in AppConfig

A configuration profile defines how AppConfig locates and manages your configuration data. It includes a URI that points to the data source and a profile type. AppConfig supports two profile types - Feature flags – Enable controlled feature releases, gradual rollouts, and testing in production.

• Free-form configurations – Store and retrieve configuration data from external sources and update it without redeploying code. Both profile types help decouple configuration from code, support continuous delivery, and reduce deployment risk. You can also add optional validators to ensure that configuration data is syntactically and semantically correct. During deployment, AppConfig evaluates these validators and automatically rolls back changes if validation fails. Each configuration profile is associated with an application, which acts as a logical container for your configuration resources. For more information about creating a configuration profile, see Creating a configuration profile in AppConfig in the the AppConfig User Guide.

3. Deploy configuration data

When you start a deployment, AppConfig: 1. Retrieves configuration data from the source defined in the configuration profile

1. Validates the data using the configured validators
2. Delivers the validated configuration to AppConfig Agent The delivered configuration becomes the deployed version used by your application. For more information about deploying a configuration, see Deploying feature flags and configuration data in AppConfig.

4. Retrieve configuration data

Your application retrieves configuration data by calling a local endpoint exposed by AppConfig Agent, which caches the deployed configuration. Retrieving data is a metered event. AppConfig Agent supports a variety of use cases, as described in How to use AppConfig Agent to retrieve configuration data. If the agent is not suitable for your use case, your application can retrieve configuration data directly from AppConfig by calling the StartConfigurationSession and GetLatestConfiguration API actions. For more information about retrieving a configuration, see Retrieving feature flags and configuration data in AppConfig.

This reference is intended to be used with the AppConfig User Guide.

Getting Started

Examples are available for many services and operations, check out the usage examples.

The SDK provides one crate per AWS service. You must add Tokio as a dependency within your Rust project to execute asynchronous code. To add aws-sdk-appconfig to your project, add the following to your Cargo.toml file:

[dependencies]
aws-config = { version = "1.1.7", features = ["behavior-version-latest"] }
aws-sdk-appconfig = "1.109.0"
tokio = { version = "1", features = ["full"] }

Then in code, a client can be created with the following:

use aws_sdk_appconfig as appconfig;

#[::tokio::main]
async fn main() -> Result<(), appconfig::Error> {
    let config = aws_config::load_from_env().await;
    let client = aws_sdk_appconfig::Client::new(&config);

    // ... make some calls with the client

    Ok(())
}

See the client documentation for information on what calls can be made, and the inputs and outputs for each of those calls.

Using the SDK

Until the SDK is released, we will be adding information about using the SDK to the Developer Guide. Feel free to suggest additional sections for the guide by opening an issue and describing what you are trying to do.

Getting Help

• GitHub discussions - For ideas, RFCs & general questions
• GitHub issues - For bug reports & feature requests
• Generated Docs (latest version)
• Usage examples

Crate Organization

The entry point for most customers will be Client, which exposes one method for each API offered by Amazon AppConfig. The return value of each of these methods is a “fluent builder”, where the different inputs for that API are added by builder-style function call chaining, followed by calling send() to get a Future that will result in either a successful output or a SdkError.

Some of these API inputs may be structs or enums to provide more complex structured information. These structs and enums live in types. There are some simpler types for representing data such as date times or binary blobs that live in primitives.

All types required to configure a client via the Config struct live in config.

The operation module has a submodule for every API, and in each submodule is the input, output, and error type for that API, as well as builders to construct each of those.

There is a top-level Error type that encompasses all the errors that the client can return. Any other error type can be converted to this Error type via the From trait.

The other modules within this crate are not required for normal usage.

Modules

client

Client for calling Amazon AppConfig.

config

Configuration for Amazon AppConfig.

error

Common errors and error handling utilities.

meta

Information about this crate.

operation

All operations that this crate can perform.

primitives

Primitives such as Blob or DateTime used by other types.

types

Data structures used by operation inputs/outputs.

waiters

Supporting types for waiters.

Structs

Client

Client for Amazon AppConfig

Config

Configuration for a aws_sdk_appconfig service client.

Enums

Error

All possible error types for this service.