The document discusses serverless patterns and architectures using AWS services. It provides examples of using services like AWS Lambda, Amazon S3, Amazon DynamoDB, Amazon API Gateway, AWS Step Functions and Amazon EventBridge to build serverless applications without having to manage servers. Five serverless patterns are described: 1) Using Amazon SES to trigger workflows from email, 2) Orchestrating workflows with AWS Step Functions, 3) Using AWS AppSync for a GraphQL API, 4) Transferring data with AWS Transfer Family, and 5) Event-driven architectures with Amazon EventBridge. The document emphasizes that serverless computing provides scalability and avoids server management overhead.
Deliver events to a service with a scheduled configuration (e.g., a crontab, to activate any planned activity)
Respond to custom events generated by an application (e.g., new payment create an invoice)
To deliver events generated on the AWS infrastructure (e.g., S3 PutObject or Glue job change status to “SUCCEEDED”)
Benefits of functionless integrations
If you use a direct service-to-service integration, you can expect these benefits:
Lower Latency. Lambda can introduce a little latency, through occasional cold starts and also simply by being an extra network hop. By going directly from one AWS service to another, you avoid this.
No Code rot. You own the code for a Lambda function and its dependencies and so it’s on you to update your dependencies when new versions are available. With direct service integrations, AWS takes care of this for you.
Free (in terms of cloud bill). You have to pay for Lambda invocations whereas most, if not all, Lambda-less direct integrations are free (you just pay for the service usage at each end of the integration).
Even higher scalability. Lambda functions are very scalable to begin with, but they are subject to an account-wide soft limit of 1,000 concurrent executions. Once this limit is hit, functions get throttled. So if you have a very high throughput integration, a functionless pattern won’t hit this limit (though the services at each end of the integration will likely have their own limits that you’ll need to heed).
Less IaC code is needed if you don’t have to provision and wire up the Lambda function, e.g. creating a dedicated IAM role for your function. This benefit is arguable based on how much IaC the functionless component requires to set up.
less code to write, test, deploy and run
less functions to maintain
less points of failures
less IAM policies, less permissions to set
less security worry
less lambda concurrency
less monthly spend on lambdas
Amazon API Gateway has a feature that enables customers to create their own API definitions directly in front of an AWS service API.