Intro AWS Step Functions is a Serverless orchestration service that helps to build a workflow with various steps that connect different AWS services. These steps are defined in State Machine, which will be implemented in Amazon States Language (ASL).
There are two types of workflows in Step Functions:
Express flow Standard flow Among many differences, Express flow can only run up to five minutes and Standard flow can run up to one year.
Intro In this project, I will discuss how you can build a simple leave apply/approval system using AWS Serverless services.
These are the main functionalities of this implementation.
Apply for a leave Confirmation for leave application. Send notification to the approver regarding new leave request. Send reminder notification to the approver. Send notification upon approval/rejection. And below services/functionalities are in use in this project:
Step functions SDK integrations for SES, DynamoDB Step functions Parallel processing Step functions wait for callback pattern Lambda function URLs DynamoDB streams with filtering AWS CDK with TypeScript as IAC Architecture State Machine How it works Create a leave request CreateLeave Lambda function accepts leave requester’s email, leave approver’s email, leave dates and reason and is responsible to validate and save it to the DyanmoDB table.
NOTE: This post is originally published at dev.to
This post contains a weekend project I worked on to create an alarm when my AWS EC2 servers are down. Tools and technologies used: AWS Lambda, EventBridge, Greengrass, Raspberry Pi, Active Buzzer and LED light (as the alarm), GPIO, etc.
Architecture: How it works: When an EC2 is stopped or terminated, EventBridge will capture the event.
EventBrige will trigger the Lambda function (PublishToIotCloud) which publish a message to IOT cloud with the topic ‘alarm’.
NOTE: This post is originally published at dev.to
Intro Recently, there was a hackathon at my work place, Wonderkind, and with one of my colleagues, I created a intelligent door bell with AWS Serverless services + a raspberry pi.
Whenever someone clicks on the button of the ‘door bell’, it will capture a image and check through a Amazon Rekognition faces collection to see if the faces on the image are already indexed.
Recently, I have created a simple API to retrieve AWS services by it’s regions. And I decide to make it a Serverless Application and now it is generally available to be used by anyone.
AWS SAR :
Github: https://github.com/pubudusj/serverless-aws-services
How it works Once you deploy the application using SAM locally or using SAR, there is a API gateway url in the output section. You can directly access the url, which will output JSON response which is in similar structure as below:
Recently, one of my friend/client came up with the scenario below.
Scenario: There is a lambda function, which calls to a external API and fetch some data. This external API only accepts incoming requests only from pre-configured whitelisted IPs. As per today, AWS doesnt’ support elastic IPs for Lambda. However, there is a simple work around.
Solution: Simple solution is, to create the lambda function within a VPC and make the 3rd party API to be accessible via a NAT gateway.
Lambda by nature is highly scalable. However there ares some limitations you need to consider when there are lot of Lambda functions run simultaneously.
Please note: This will not applicable for all the scenarios, but for a system with a high throughput.
Account Level Concurrent Execution Limit As at now, Lambda has a soft limit of 1000 concurrent executions per region. Which means, at any given moment, sum of lambda executions running belongs to all of your lambda functions in a single region must be less than 1000.