Cloudformation:
- consider separate a large stack into small stacks. Use cloudformation stack as resource of another stack.
- Best practice: use an environment variable to add a tag (stage, dev, product, etc.) into the resources' names
- Use tags
VPC: default VPC expose everything to public. Create private VPC to isolate resources. Resource can have private endpoint in private VPC.
Transaction with DynamoDB:
- Lock - kind of complex
- Queue - be careful of worker poll requests - there's also a cost
- Use SQS to queue & trigger Lambda : seems workable, polling is still done, by Lambda service. Request to SQS is then charged.
- Can also use a DynamoDB table with Dynamodb stream as queue, still polling based (Lambda service polls the stream), and the read requests are charged.
- However NOTE SQS is "poll-based event sources that are not stream-based" while DynamoDB is "poll-based event sources that are also stream-based". So the behaviors are different. See https://docs.aws.amazon.com/lambda/latest/dg/concurrent-executions.html
- Lock with Memory Cache (use memory cache as a "small room" to control concurrency. more than cache capability user requests will be blocked out immediately. this "iron flat" spike to dynamodb so throttling can be avoided)
Memory Cache:
- Memcached - simple key/value store
- Redis - more sophisticated
MQTT - push / subscribe messaging, in AWS it's part of IoT Core service and pricing is very reasonable. Allow real-time apps. No polling!!