- 最新
- 最多得票
- 最多評論
Hi,
We have similar perspective in the dev of AWS services: we try to keep customer data in customer account for obvious security / confidentiality. reasons.
In that case, cross-account data access is a possible way to go: you access customer data in customer account from your solution account(s) via cross-account access services offered by many AWS services.
Of course, in that case, the customer has to trust the fact that you will not escape in your account some of the data that you access for the application purpose.
Another way that you can think of are Nitro enclaves aimed (among others) to protect IP of some solution provider when running in an account out of its control: see https://aws.amazon.com/ec2/nitro/nitro-enclaves/. But, this may create too much work because Nitro enclaves work on EC2 instances only . So, you would have to run your Lambdas under the control of something like OpenFaas https://www.openfaas.com/ and encapsulate it in EC2 instead of Step Functions.
Best,
Didier
Usama,
Were you able to work out a solution? We're about embark on a similar 100% serverless approach and it looks like the AMI (although EC2 isn't needed) is the only way to include additional services via CloudFormation. Many thanks in advance; I'll be sure to report back with any findings we discover.
相關內容
AWS 官方已更新 1 年前
Hi Didier, Thanks for your response. Your suggestions are helpful but seems like they may require major application level changes. That is ofcourse the final option. But before going for this option, do you see any possibility of delivering our complete solution (may be using CloudFormation templates) via AWS Marketplace. So that customer can deploy the solution in their account. I know this may contain complications.