5

I'm considering using AppConfig, but am struggling to understand how configurations would be used in a scenario where the Test and Staging deployments are in different accounts.

Having two completely different AppConfig setups in these two accounts seems counter productive, since it would make it difficult to elevate configurations to the different deployments.

I could alternately have one AppConfig setup, and call it from my application, but that would require cross account access, using a different role I presume, since there is no access to AppConfig using an ARN or resource-based policies.

So how would I access AppConfig across multiple accounts?

Jon Nichols
  • 2,211
  • 1
  • 20
  • 21
  • `https://aws.amazon.com/about-aws/whats-new/2019/11/simplify-application-configuration-with-aws-appconfig/` – Nadeem Taj Oct 07 '21 at 18:23

2 Answers2

0

Stack Sets

Some services do have native multi-account support through the console. But if that fails, you can always use StackSets. If you can manage to package your AppConfig nicely up into a CloudFormation template, you can deploy a set of stacks to an Organizational Unit, which will deploy to all accounts in that OU.

This may or may not fit your use case based on your requirements. The typical use case for this is to enforce compliance and uniformity in these accounts that the VPC setup is consistent, logging is enabled etc. It isn't necessarily to deploy an application into different accounts not to say that this isn't a good idea, it just depends.

CI/CD - Preferred (IMO)

What I believe most people do is have a CI/CD account in AWS, or a separate CI/CD tool outside of AWS, which would have a pipe line (Code Pipline in AWS), which would have each of these accounts as a separate Stage. In your pipelines, you would have environment variables for each account if needed, and make the CLI/API calls to AWS which you are manually doing ATM. IMO this would be the most maintainable approach most of the time for the following reasons:

  • Can easily have differences in the environments, (conditions in CloudFormation are very hard to maintain IMO
  • If there is a problem in one stack your stack set it is not such an issue, as you may have one stack effect others.
  • You generally have more granularity and control than you would with only CloudFormation and StackSets although with a bit of effort you can technically do everything with CloudFormation.

Service Catalog

Another alternative is to use the AWS Service Catalog, with auto update of provisioned products, there is an example of this here. But again this was for a slightly different use case of independent IT teams in an organization consuming IT products available to the company.

Derrops
  • 7,651
  • 5
  • 30
  • 60
  • Could a principal in "consuming account" get IAM permissions to pull config values from a "CI/CD" account's appconfig? or will the principal require credentials in the "CI/CD" account? – RaGe Oct 07 '21 at 16:17
  • I think what might be close to what you are talking about is using s3 as the source for you config, if it's possible to reference a bucket in another account and allow reads using a resource policy great, but otherwise if not then you'll need to use s3 replication to replicate the config to the different accounts or copy the config manually to each bucket, and use stack sets to create the app config in each account. Pretty painful if you ask me but if you definitely want to use AppConfig with multi-accounts you'll have to do something like this. – Derrops Oct 08 '21 at 00:31
-1

App Config should be environment specific and cloud formation could be one of the solution to tackle the complxity of deployement.

Mrigank Kishore Varma
  • 376
  • 1
  • 3
  • 12