3 ms·

yes, I can resolve SSM variables into plain text, however key rotation requires re-deploy. (unless I'm missing something here) However the new feature where yo

yes, I can resolve SSM variables into plain text, however key rotation requires re-deploy. (unless I'm missing something here) However the new feature where you just dump in the SSM name in the environment variable and it unencrypts at execution is not supported in CF yet. It was the same ECS/fargate/batch task creation for a long time. As for the CF Console, its the same data in the CLI or on the web, the data comes from the same point. 1) it lazy evaluates, so it gets 90% of the way through a deploy only to find that there is a spelling mistake. That is inexcusable. 2) yes you can download the template via S3, but if you have a circular dependency, it won't tell you the line numbers. It won't even tell you the occurrences that are causing it to be over constrained. 3) It won't tell you the order in which your stuff will come up.

scarface74 8y ago
For automatic key rotation you use the new Secrets Manager. 1) there are cloud formation linters. 2) It will tell you the resource name 3) it creates a dependency graph. It only knows when things come up based on when the underlying API call returns. How else would it know until execution time?
- KaiserPro 8y ago
  > 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

For automatic key rotation you use the new Secrets Manager. 1) there are cloud formation linters. 2) It will tell you the resource name 3) it creates a dependency graph. It only knows when things come up based on when the underlying API call returns. How else would it know until execution time?

KaiserPro 8y ago
> 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.