Introduction to AWS AppConfig

Subscribe Send me a message home page tags


#AWS  #AppConfig 

Introduction

In this post, we provide an overview of the AWS AppConfig service. We will discuss the fundamental concepts of AppConfig, demonstrate how to retrieve configuration data in Java, and explain the pricing model of this service.

Related Readings

Basic Concepts

AppConfig has the following concepts:

An AWS account can host multiple applications, and each application requires its own configurations. A configuration consists a set of adjustable parameters or "knobs" that we can customize. Therefore, we end up with a structure resembling the following:

{
    "config-of-feature1": {
        {"flag-1":{"enabled":false}},
    },

    "config-of-feature2": {
        {"flag-A":{"enabled":false}},
        {"flag-B":{"enabled"true}},
    },
}

It's often the case that we want to toggle a feature. AppConfig has a concept called Feature Flag, which basically set a default enabled attribute for the flag used in the configuration.

If we go to the AWS Console and select the AppConfig service, we will see the following dashboard. The landing page shows a list of applications.

appconfig-application.png

If we click the application, it will show the (feature) configurations defined for this application:

appconfig-config-definition.png

If we click the configuration, the page will show the attributes. For example, the figure below shows that the configuration WriteOperationConfig consists of a flag called allowWritesToAws. (We can have multiple flags in a configuration.)

It is important to observe that this page includes an attribute called Configuration Profile ID, which serves as an identifier for the configuration. Rather than using the configuration name (which, in this instance, is WriteOperationConfig), we use the profile ID to specify the configuration when invoking the AppConfig APIs.

appconfig-config-details.png

AppConfig also allows us to define multiple environments that will host/accept the configurations. For example, we can define testing and prod environments for the application and make the production code pull the configuration data from the prod environment.

appconfig-environment.png

Fetch Data Using Java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
AWSAppConfigData client = AWSAppConfigDataClient.builder()
        .withCredentials(new ProfileCredentialsProvider("YourAWSConfigProfile"))
        .build();

final String env = "Environment";
final String applicationName = "YourApplicationName";
final String profileId = "ProfileIdOfConfiguration";

StartConfigurationSessionResult sessionResult = client.startConfigurationSession(
        (new StartConfigurationSessionRequest())
                .withApplicationIdentifier(applicationName)
                .withEnvironmentIdentifier(env)
                .withConfigurationProfileIdentifier(profileId)
                .withRequiredMinimumPollIntervalInSeconds(300)
);

GetLatestConfigurationResult requestResult = client.getLatestConfiguration(
        (new GetLatestConfigurationRequest())
                .withConfigurationToken(sessionResult.getInitialConfigurationToken())
);

// Print the configuration data
Charset charset = Charset.forName("UTF-8");
String configData = charset.decode(requestResult.getConfiguration()).toString();
System.out.println("Configuration data:");
System.out.println(configData);
If we want to check the configuraiton value periodically, we should use the token provided by the GetLatestConfigurationResult (i.e. requestResult.getNextPollConfigurationToken()) in the subsequent requests instead of the initialConfigurationToken in the sessionResult. The initialConfigurationToken will trigger AWS to send a configuration object, because it's the first request and AWS needs to send a configuration object to the client. Sending a configuration object is much more expensive than checking if there is a new value for the configuration.

Pricing

The pricing information of AppConfig is provided on the AWS Systems Manager pricing page. Users are charged based on the configuration requests via API calls and the number of configuration received.

It is not clearly defined what is meant by configuration received. However, according to the example provided in the document, the requester only receives a configuration object when there is an updated configuration. Unfortunately, this is only an educated guess and we cannot even verify this because there is no metrics on configuration received.

----- END -----

If you have questions about this post, you could find me on Discord.
Send me a message Subscribe to blog updates

Want some fun stuff?

/static/shopping_demo.png