Various jobs and functions can be leveraged via AWS’ Lambda functions. That way Serverless components can be turned on. Doing so would open options to reduce a need to get Ec2 instances deployed as it would cause ongoing maintenance such like systems patching, environment configurations, monitoring etc etc.
In the example outlined here there is no Trigger attached which otherwise would invoke the execution of a Lambda function. The focus is to let Lambda access a private Ec2 instance. This may be outlined in a different blog entry.
VPC, Subnets, Gateways
- A VPC with 2 subnets should be available for redundancy reasons
- In case Lambda would need to be able to access public resources (i.e. the Internet) the VPC needs to be configured with an ENI, so a NAT gateway
- Routes need to be created accordingly – verify the default route
- Public subnet: Destination 0.0.0.0/0, Target will be an igw-…
- Private subnet: Destination 0.0.0.0/0, Target will be a nat-… or an eni-…
As common at AWS to let a resource interact with another one it has to be allowed. To make it a bit easier AWS provides a preconfigured role called AWSLambdaVPCAccessExecutionRole which extends the AWSLambdaBasicExecutionRole role. Specifically the ec2:* policies as shown below are necessary to allow a given Lambda function to access an internal Ec2 instance. The logs:* policies will be needed in any case to allow Lambda to function.
Once IAM is set Lambda can be looked into
Via the Console the Lambda menu option will be chosen and a new function will be created. In this case I used latest Python and took an existing role under the permissions graph. This is the role I created in the IAM section above.
Finally network settings need to be set accordingly:
In my case I took one subnet only – AWS allows it but shows a warning. As mentioned earlier a second subnet would be needed to ensure reliability. It would need to be ensured to choose the correct VPC along with a Security Group that allows to let resources connected from within the SG.