AWS Lambda is an extremely useful tool, for use both inside and outside the AWS platform. When working inside the platform developers need to be aware of a few different techniques which make AWS even more useful.
The VPC, or virtual private cloud, is your secure zone created inside your AWS account. The VPC represents a secure boundary for your assets, between other VPCs you have created, other AWS accounts, and the wider world. Assets inside the VPC can communicate with each other and AWS services according to rules you create in the network access control list (NACL) and security groups (SG). The setup of NACL and SG rules is fundamental to the secure use of VPCs and AWS itself.
Correctly configured, a VPC cannot allow unintended network ingress or egress. This “Great Divide” is great for security but can give developers new considerations working with AWS or other services.
The Lambda service allows developers to create functions as a service that can be run in any context in the AWS environment. Code is authored and stored in the service, developers can trigger the lambdas from the CLI tool, using cloud native event triggers, from applications running in the account, or even expose the lambda to the outside world using the AWS API Gateway. A fun fact about Lambda is you can configure the service to run with no VPC, as such your Lambda has access to the internet, and can access external services such as APIs etc, OR you can configure the Lambda to run inside your VPC and even specify which subnets. If you run your Lambdas in a VPC they lose access to the internet and cannot be reached from outside the VPC/subnet context.
We recently took one of our software products and converted it to run as a SAAS offering. We needed to add all the contextual items around SAAS as layers to the software stack running the tool. The simplified description of those items is:
- Subscription / Payment gateway
- Online User creation application supporting Admin user, users organised by company
- A data store and Lambdas to manage subscription levels, subscription status which supplies licence files to the application
- An API gateway to pipe push events to the Lambda systems
Significant work went into keeping the application servers protected from anything other than direct use by users running analyses. Having API services directly connecting to those machines is not an option. Lambda was chosen as the work of confirming licenses prior to forwarding newly logged in sessions would be intermittent, likewise external events coming in from the paygate were intermittent and mainly relevant to the user system supplying authenticated sessions.
With our main deployment secured inside the VPC and our user and license system running serverless in Lambda via API Gateway we needed a way to actually supply the license to the application from outside the VPC. Our solution involves using the API Gateway Lambda to invoke, via the AWS Lambda SDK, the Push license Lambda inside the SAAS VPC context. This is possible as we can send a payload to the VPC resident Lambda with all the context it needs to target the current application server by its internal IP address and hand over the license. The Lambda is running in a container and as such needs to have matching access to the subnets and security groups that are applied to the application servers and database.
Our arrangement allows us to limit DDOS against the application to the AWS API Gateway. The Gateway can be rate limited and is secured with authentication credentials provided by the payment processor. Likewise the user authentication application is rate limited for human only interaction which further protects the license processing system from abuse.
The SAAS is running entirely inside the VPC and is therefore immune to external nuisance attacks.
This post has shown one of many possible avenues for dealing with security for SAAS applications running within a private network. VPC configuration allows developers to control access and connectivity to applications and prevent external attacks. Adding AWS API Gateway, Lambdas and serverless user authentication gives developers flexibility in dealing with improved isolation of application components.