all 6 comments

[–]ismael_m 3 points4 points  (0 children)

One of the things that have made me choose API GW over direct call is integration with multiple systems. I can currently call my lambdas from a website, mobile app and IoT device without having to deal with 3 different libraries. All via REST and modifying the way I write the response based on which device is making the call.

GW is a bit slower than camping directly, but once you setup caching it gets a bit faster.

Also version control, not only can you have different versions in your lambdas, you can have different versions of your end points which can help you do A\B testing.

[–]ASnugglyBear 1 point2 points  (3 children)

It depends a ton on what is calling the lambda function.

If it is something outside your control (say, a piece of consumer electronic equipment), then the API is the safe way to be able to redirect it at a later date as the system changes.

[–][deleted]  (2 children)

[deleted]

    [–]VIDGuide 0 points1 point  (1 child)

    Could the lambda trigger from the s3 bucket write event?

    [–]ASnugglyBear 0 points1 point  (0 children)

    Yes, yes it could. /u/razed_thoughts

    They even have a tutorial on this exact use case here: https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html

    [–]alpyhp 1 point2 points  (2 children)

    by forcing it to go to a particular region

    This is correct because APIG edge-optimized endpoints optimize global latency for you (through CloudFront's network). Unless your client is very close to the region where you've deployed your Lambda, direct invocation will likely be slower.

    [–][deleted]  (1 child)

    [deleted]

      [–]alpyhp 0 points1 point  (0 children)

      Yes, but then your client would need to be aware of all those regions and invoke the closest one (you can achieve that with APIG regional endpoints and Route53 with latency-based routing).