Creating resources in custom AWS accounts

This of course is rife with issues, you should never try to create resources in your customers AWS accounts. However, there are times when closer integration may be beneficial:

• Automated VPC peering
• EventBridge direct event sending
• Subscription to your SNS topic

The list may go on. However, you should never:

• Create an IAM role that your account can assume
• Create resource policies that allow access directly to the resource
• Change existing resources, or make assumptions about those resources.

The best solution is NOT. Your product nor tech requires this and it isn’t feasible cross-cloud provider. But perhaps you have a t̶e̶c̶h̶ ̶d̶i̶c̶t̶a̶t̶o̶r tech lead on staff, and you can’t get around this.

The best strategy to do this, is use CloudFormation (CFN). Create a public customer stack template, and give them a special button which will automatically create a stack with all the necessary resources.

• CFN offers quick buttons to make work: CFN setup
• Existing SVG resources for beauty: CFN Button.svg
• And instructions directly from the AWS Blog

As a policy, we never grant access to other company’s the ability to make changes to our AWS account. At best we’ll run CFN policies after carefully vetting them. But that’s the end of the story. It’s possible you might be going about this the wrong way.

You can always get 100% done what you need to, but it won’t always be 100% with CFN. If it is easier you can also include your CFN template:

• Lambda function to deploy and automatically execute
• The function can contain the necessary roles and permissions to get the full job done
• Lambda function can self-delete, when it’s done (isn’t that cool)
• You can even package this in a public docker container to pull in.

In the case you need a management UI to directly control the AWS resources * in your customers account, any of these work, but they are all wrong:

• Create a role in their account which can be assumed by your account. That role should have limited access to the resources it needs.
• Create a service in their account (APIGW, lambda, docker, etc…) and expose that service with a resource policy so that your account can call it. Then embed in that service functionality to change what you need
• Release a package/container customers can deploy and self manage their control over their settings. That package can contain the API, you can host UI that can directly connect to their deployed service. The data your service needs from the account will be exported, but the control over the AWS account happens only internally.