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
-
Go to our lambda function and choose
Configruation > VPC
-
Choose a VPC, then choose an
AZ
and hence a private subnetFinally 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 chooseOption Value Type
AWS Service Services
com.amazonaws.your-region.logs VPC
Your target VPC Subnet
Your target private subnet Security Group
SG 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
- Arbitrary Name
- Any Public Subnet
- Must be of Public Connectivity Type
- 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.