0%
December 19, 2024

Architecture for Private Lamdba functions called via another lambda function

aws

docker

lambda

Overview

Strategy

Resource to be protected

Place our protected resourced (target lambda function) behind internal load balancer.

Endow lambda functions with security group

Place our public-facing lambda functions into private subnet so that:

  • the lambda function can be endowed with an ENI (Elastic Network Interface)
  • that ENI can carry a security group (SG) so that now lambda function can carry an SG.

Calling protected resourcess
Public facing lambdas

Since our protected lambda function stay behind internal load balancer, suppose that the load balancer has an DNS name:

  • my-internal-loadbalancer

then inside of private subneted lambda function , calling is as simple as calling

  • Make a request to http://my-internal-loadbalancer:<port-number>/suitable/route
  • Allow SG to access port port-number

here we assume that our lambda function is acting like a web server.

Public facing ECS services

For ECS since by default each service already has an SG, by allowing this SG to access port-number, we get access to protected resource easily.

How to Connect a Lambda Function to a VPC and then a private subnet

VPC configuration in Lambda Functions Console
  1. Go to our lambda function and choose Configruation > VPC

  2. Choose a VPC, then choose an AZ and hence a private subnet

    Finally Choose an SG and congradulation! Our lambda has an SG now!

Caveat of connecting lambdas to a VPC/subnet
Outbound Traffics are Lost
  • By default each lambda function cannot make any request from inside when they are connected to a VPC (due to security reason).
Connect Lambda Functions to Public or Private Subnet?
  • It makes no difference using public or private subnet to place our lambda functions.
Cloudwatch log Becomes Unavailable
  • Cloudwatch log endpoint connection is also lost in this scenario. For logging purpose, one should always add VPC endpoints to this private subnet.

    upon clicking create endpoint, we will need to choose

    OptionValue
    TypeAWS Service
    Servicescom.amazonaws.your-region.logs
    VPCYour target VPC
    SubnetYour target private subnet
    Security GroupSG in this context means the group of resources that is available to this endpoint, not related to any security inbound or outbound rules

Create Necessary Resources

Create subnets and what are the available CIDR blocks?

By default the following are available CIDR blocks:

172.30.0.0/20 (0-15)   ← existing
172.30.16.0/20 (16-31) ← existing
172.30.32.0/20 (32-47) ← existing
172.30.48.0/20 (48-63) ← you can use this
172.30.64.0/20 (64-79) ← or this

For example 172.30.64.0/24 will be a good choice, which means that any resource created in this subnet has a flexible choices of private addresses.

If we want to further divide 172.30.64.0/24 ( choices) into 16 pieces, we can use:

├── Subnet 1: 172.30.64.0/28 (first 16 IPs)
├── Subnet 2: 172.30.64.16/28 (next 16 IPs)
├── Subnet 3: 172.30.64.32/28 (next 16 IPs)
├── ...
├── Subnet 16: 172.30.64.240/28 (final 16 IPs)
Set up NAT gateway
Create an NAT Gateway

  1. Arbitrary Name
  2. Any Public Subnet
  3. Must be of Public Connectivity Type
  4. Must have an Elastic IP (which we have at most 5 for each region)
Associate to a subnet by creating route tables

First create a route table:

Next view the detail of the route table, edit it and add 0.0.0.0/0 <- nat-xxxx.

Finally associate all private subnets for which we wish to apply the route table:

Setup private subnet and internal load balancers
Subnets and Route Table

By default the creation of load-balancer requires at least two private subnets in two separate AZ's

Next our private subnets need outwards traffic, create a route table for this purpose:

and of course we add outwards traffic rules

for the new private subsets:

Internal load balancer

Choose Internal Type with IPv4 addresses:

Then choose two of the private subnets:

Choose a new identity (SG) for our internal load balancer:

And finally add the listeners and target groups:

Internet-facing load balancers

Same as the previous one, but we need to:

  • Add our internet-facing load balancer at public subnets and,
  • For listeners at any port with HTTPS we need to asscoiate it a certificate.
VPC endpoints (for cloudwatch)

Go to VPC > Endpoints, then create our VPC endpoints with appropriate service name:

For Cloudwatch we need com.amazonaws.<region-name>.logs.

Other possible service endpoints that require an endpoint in private subnet:

  • Cloudwatch Monitoring
  • S3 Gateway Endpoint (Free)
  • DynamoDB Gateway Endpoint (Free)

For a more comprehensive list of available AWS services integrated with AWS PrivateLink (i.e., accessible via VPC endpoints in private subnet):

Remark. In our case if we want to get access to our internal load-balancer, no endpoint is needed.