3 ms·

> key rotation you use the new Secrets Manager. True, but that gets very expensive very quickly. We keep all our config for each environment in SSM pretty chea

> key rotation you use the new Secrets Manager. True, but that gets very expensive very quickly. We keep all our config for each environment in SSM pretty cheaply. (we have >1000 config items, most of which aren't and don't need encryption)h We basically treat SSM like Vault from hashicorp 1) We have a linters in the CI pipeline, they help but are not perfect. 2) true, but not where the references are, thats the killer bit. If you have > two people working on a script, and they each put in a !Ref or !GetAtt, its exceptionally difficult to debug. 3) once you have a dependency graph, you know the order in which things come up. You need to generate the graph before you start calling APIs. For example, you have a a property that you've spelt wrong, isn't the right data type, or isn't valid for that type of config. All of those can be evaluated when the dependency graph is generated. However, they are not, they are differed to when the API is called. This gets very tedious if you are using anything ECS/fargate/rds, as the debug loop can be > 3 hours. This can be mitigated if you use uniquely named items, allowing multiple stacks.

scarface74 8y ago
Parameter Store is a bad choice for app configuration. Yeah I use it. But I wouldn’t trust it as an organization standard. There are unknown, unpublished, unchangeable Service limits where it will throttle you. Even when using CF, I have to aggressively use DependsOn to keep multiple calls to the Parameter Store API from being called in parallel. We gave up and used DynamoDB for configuration for non sensitive parameters and created a custom resource to create Config values. Yeah but the Secrets Manager at $0.25/month per secret is expensive. There are linter plug ins for Visual Studio Code and other editors. There is also the new CDK which is suppose to be able to do checks based on the real stars of your environment like whether a specified subnet exists. I haven’t used it yet. For example, you have a a property that you've spelt wrong, isn't the right data type, or isn't valid for that type of config. All of those can be evaluated when the dependency graph is generated. However, they are not, they are differed to when the API is called. Some things CF could be more intelligent about knowing, but for the most part, each service does its own validation when you call the underlying API. Not related to CF but for instance the CloudWatch GetMetricData API has what seems like dozens of generic vslidations. The parameter store only allows certain formats for the keys. How would CF know that you specified an invalid key? Can you imagine how much slower Cf would be if it had to call some type of prevalidare API on each resource before it created it? To get an idea, think of how slow the new drift detection feature is and it is only doing read operations.

scarface74 8y ago

Parameter Store is a bad choice for app configuration. Yeah I use it. But I wouldn’t trust it as an organization standard. There are unknown, unpublished, unchangeable Service limits where it will throttle you. Even when using CF, I have to aggressively use DependsOn to keep multiple calls to the Parameter Store API from being called in parallel. We gave up and used DynamoDB for configuration for non sensitive parameters and created a custom resource to create Config values. Yeah but the Secrets Manager at $0.25/month per secret is expensive. There are linter plug ins for Visual Studio Code and other editors. There is also the new CDK which is suppose to be able to do checks based on the real stars of your environment like whether a specified subnet exists. I haven’t used it yet. For example, you have a a property that you've spelt wrong, isn't the right data type, or isn't valid for that type of config. All of those can be evaluated when the dependency graph is generated. However, they are not, they are differed to when the API is called. Some things CF could be more intelligent about knowing, but for the most part, each service does its own validation when you call the underlying API. Not related to CF but for instance the CloudWatch GetMetricData API has what seems like dozens of generic vslidations. The parameter store only allows certain formats for the keys. How would CF know that you specified an invalid key? Can you imagine how much slower Cf would be if it had to call some type of prevalidare API on each resource before it created it? To get an idea, think of how slow the new drift detection feature is and it is only doing read operations.