There are multiple reasons why we're not doing this.

• If we manage other config values as infra-as-code, then we will have to update our task definition every time there's a new configuration to be added or every time we want to modify existing values, which mean running our terraform code.

• Having configuration in consul gives us the to modify config values on consul first just restart our service on AWS ECS to consider the new config values.

• Also at this point we do not manage secrets in secrets manager (not sure if it's possible) through infra-as-code. We manually add, update values since secrets generally do not change frequently. So adding all the config values manually was not a viable option for us.

Sunil Kumar

1. Wouldn't you need to update code anyways when there are new values?
2. Not sure I see the distinction between the two; if its in code and you manually change in consul, you could just do the same with Param Store. But even if a config value results in a restart, its still a fully automated and auditable change.
3. Yes, you can define the secret, but manually add in the value as a side process. If the secret needed (or would benefit) regular rotation then you can enable it.

Pete As I had mentioned earlier we currently manually add each of the secrets into SM. Adding all the configurations like this was not realistic since we generally have lot of config data for each service.

Also this can be error prone because of the interface AWS currently has to add secrets (my opinion)