I was wondering if it is possible to create a Resource in my CloudFormation file to create a VPC Endpoint for SQS. I was able to do this for SQS and DynamoDB, but I believe it is because they were Gateway endpoints.
For now I have defined my SQS resource as:
SQSEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal: '*'
Action:
- 'sqs:*'
Resource:
- '*'
ServiceName: !Join
- ''
- - com.amazonaws.
- !Ref 'AWS::Region'
- .sqs
SubnetIds:
- !Ref PrivateSubnet
- !Ref PublicSubnet
VpcId: !Ref 'VPC'
VpcEndpointType: Interface
Though, when I try to create the stack I get the error:
It seems like it is possible from reading this blog post from AWS. Though I can't find any examples or documentation. Any ideas?
So to sum it all up:
SQSEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
ServiceName: !Join
- ''
- - com.amazonaws.
- !Ref 'AWS::Region'
- .sqs
SubnetIds:
- !Ref PrivateSubnet
VpcId: !Ref 'VPC'
VpcEndpointType: Interface
SecurityGroupIds:
- !Ref PrivateSubnetInstanceSG # has to allow traffic from your VPC
PrivateDnsEnabled: true
Background
I figured it out, for DynamoDB and S3, which use Gateway Endpoints, the PolicyDocument property has to be defined. For all other services, This doesn't need to be defined. So for SQS first I thought all that is needed is:
SQSEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
ServiceName: !Join
- ''
- - com.amazonaws.
- !Ref 'AWS::Region'
- .sqs
SubnetIds:
- !Ref PrivateSubnet
- !Ref PublicSubnet
VpcId: !Ref 'VPC'
VpcEndpointType: Interface
But that still wasn't working, even though the interface endpoint was setup, I had to:
set the PrivateDnsEnabled property to true so that you can use the AWS CLI as the AWS CLI uses the public endpoint, and setting the PrivateDnsEnabled allows the private endpoint to automatically be mapped to the public one
set the SecurityGroupsIds to have a security group that allows Inbound traffic from your VPC. If this instance set, the default security group is used and it only allows inbound traffic from sources that have the default security group, meaning that SQS won't be able to send traffic back to your instance
Related
This is basically the same issue as in this question, but the answers there didn't get me to a solution.
My configuration is: 1 VPC, 1 subnet, 1 security group. My Lambda runs in the VPC/subnet/security group and tries to add a message to an SQS queue, but gets a timeout. I've double-checked the permissions granted to the lambda, the policy on the VPC Endpoint, the policy on the SQS queue, opened the rules on the Security Group, ensured the Network ACLs are open.
I successfully went through this tutorial, which sets up VPC/etc+EC2 with cloudformation, then demonstrates sending a message to SQS from EC2.
To reproduce my problem, I started with the cloudformation from that tutorial and added the following to it:
the VPC Endpoint (rather than creating it through console like in the tutorial)
a Lambda (plus IAM role+policy) in the same VPC that tries to send a message to the SQS queue
The resulting cloudformation template is below.
I can reproduce the problem like this:
Create the cloudformation template (see below) (note that I had to make one small change to the template in the tutorial to get it to work in us-west-2).
SSH to the EC2 and run the command to send an SQS message (see step 5 from the tutorial). This succeeds.
In the console, go to the Lambda, paste the URL of the SQS queue into the code, deploy, and run the lambda. It times out.
In the console, edit the Lambda configuration to set VPC=None, then rerun the lambda. It succeeds.
So the SQS queue is accessible by the lambda outside the VPC, and by EC2 inside the VPC/subnet/sg, but not the lambda inside the VPC/subnet/sg.
Any idea what could be missing?
Cloudformation (from tutorial + my additions):
# Copied from this tutorial: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html
AWSTemplateFormatVersion: 2010-09-09
Description: CloudFormation Template for SQS VPC Endpoints Tutorial
Parameters:
KeyName:
Description: Name of an existing EC2 KeyPair to enable SSH access to the instance
Type: 'AWS::EC2::KeyPair::KeyName'
ConstraintDescription: must be the name of an existing EC2 KeyPair.
SSHLocation:
Description: The IP address range that can be used to SSH to the EC2 instance
Type: String
MinLength: '9'
MaxLength: '18'
Default: 0.0.0.0/0
AllowedPattern: '(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})'
ConstraintDescription: must be a valid IP CIDR range of the form x.x.x.x/x.
Conditions:
IsT3Supported: !Equals [!Ref 'AWS::Region', eu-north-1]
Mappings:
RegionMap:
us-east-1:
AMI: ami-428aa838
us-east-2:
AMI: ami-710e2414
us-west-1:
AMI: ami-4a787a2a
us-west-2:
AMI: ami-7f43f307
ap-northeast-1:
AMI: ami-c2680fa4
ap-northeast-2:
AMI: ami-3e04a450
ap-southeast-1:
AMI: ami-4f89f533
ap-southeast-2:
AMI: ami-38708c5a
ap-south-1:
AMI: ami-3b2f7954
ca-central-1:
AMI: ami-7549cc11
eu-central-1:
AMI: ami-1b2bb774
eu-west-1:
AMI: ami-db1688a2
eu-west-2:
AMI: ami-6d263d09
eu-north-1:
AMI: ami-87fe70f9
eu-west-3:
AMI: ami-5ce55321
sa-east-1:
AMI: ami-f1337e9d
Resources:
VPC:
Type: 'AWS::EC2::VPC'
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsSupport: 'true'
EnableDnsHostnames: 'true'
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-VPC
Subnet:
Type: 'AWS::EC2::Subnet'
Properties:
VpcId: !Ref VPC
# I had to add (uncomment) this line to avoid using us-west-2d, which doesn't support the instance type
# AvailabilityZone: us-west-2a
CidrBlock: 10.0.0.0/24
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-Subnet
InternetGateway:
Type: 'AWS::EC2::InternetGateway'
Properties:
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-InternetGateway
VPCGatewayAttachment:
Type: 'AWS::EC2::VPCGatewayAttachment'
Properties:
VpcId: !Ref VPC
InternetGatewayId: !Ref InternetGateway
RouteTable:
Type: 'AWS::EC2::RouteTable'
Properties:
VpcId: !Ref VPC
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-RouteTable
SubnetRouteTableAssociation:
Type: 'AWS::EC2::SubnetRouteTableAssociation'
Properties:
RouteTableId: !Ref RouteTable
SubnetId: !Ref Subnet
InternetGatewayRoute:
Type: 'AWS::EC2::Route'
Properties:
RouteTableId: !Ref RouteTable
GatewayId: !Ref InternetGateway
DestinationCidrBlock: 0.0.0.0/0
SecurityGroup:
Type: 'AWS::EC2::SecurityGroup'
Properties:
GroupName: SQS VPCE Tutorial Security Group
GroupDescription: Security group for SQS VPC endpoint tutorial
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: '-1'
CidrIp: 10.0.0.0/16
- IpProtocol: tcp
FromPort: '22'
ToPort: '22'
CidrIp: !Ref SSHLocation
SecurityGroupEgress:
- IpProtocol: '-1'
CidrIp: 10.0.0.0/16
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-SecurityGroup
EC2Instance:
Type: 'AWS::EC2::Instance'
Properties:
KeyName: !Ref KeyName
InstanceType: !If [IsT3Supported, t3.micro, t2.micro]
ImageId: !FindInMap
- RegionMap
- !Ref 'AWS::Region'
- AMI
NetworkInterfaces:
- AssociatePublicIpAddress: 'true'
DeviceIndex: '0'
GroupSet:
- !Ref SecurityGroup
SubnetId: !Ref Subnet
IamInstanceProfile: !Ref EC2InstanceProfile
Tags:
- Key: Name
Value: SQS-VPCE-Tutorial-EC2Instance
EC2InstanceProfile:
Type: 'AWS::IAM::InstanceProfile'
Properties:
Roles:
- !Ref EC2InstanceRole
InstanceProfileName: !Sub 'EC2InstanceProfile-${AWS::Region}'
EC2InstanceRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !Sub 'SQS-VPCE-Tutorial-EC2InstanceRole-${AWS::Region}'
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service: ec2.amazonaws.com
Action: 'sts:AssumeRole'
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/AmazonSQSFullAccess'
CFQueue:
Type: 'AWS::SQS::Queue'
Properties:
VisibilityTimeout: 60
# Stuff I added starting here:
VPCEndpointForSQS:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
VpcEndpointType: 'Interface'
PolicyDocument:
Statement:
- Action: '*'
Effect: Allow
Resource: '*'
Principal: '*'
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.sqs'
VpcId: !Ref VPC
SubnetIds:
- !Ref Subnet
PrivateDnsEnabled: true
SecurityGroupIds:
- !Ref SecurityGroup
LambdaRole:
Type: 'AWS::IAM::Role'
Properties:
RoleName: !Sub 'SQS-VPCE-Tutorial-LambdaRole-${AWS::Region}'
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/AmazonSQSFullAccess'
- 'arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole'
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
Action:
- 'sts:AssumeRole'
LambdaPolicy:
Type: 'AWS::IAM::Policy'
Properties:
PolicyName: !Sub 'SQS-VPCE-Tutorial-LambdaPolicy-${AWS::Region}'
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'logs:CreateLogGroup'
Resource: '*'
- Effect: Allow
Action:
- logs:CreateLogStream
- logs:PutLogEvents
Resource: '*'
Roles:
- !Ref LambdaRole
LambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
FunctionName: 'SQS-VPCE-Tutorial-Lambda'
Role: !GetAtt LambdaRole.Arn
Runtime: 'python3.9'
Handler: 'index.lambda_handler'
Timeout: 20
VpcConfig:
SecurityGroupIds:
- !Ref SecurityGroup
SubnetIds:
- !Ref Subnet
Code:
ZipFile: |
import json
import boto3
from botocore.exceptions import ClientError
sqs = boto3.resource('sqs')
queue = sqs.Queue('<INSERT SQS QUEUE URL HERE>')
def lambda_handler(event, context):
print("before")
queue.send_message(MessageBody='Hello from Amazon SQS.')
print("after")
Of course, as soon as I posted this, I found this answer, that there is a bug in boto3 that prevents it from using VPC Endpoint for SQS by default. I tried the solution there and is solved the problem!
Aws dynamoDb only supports Gateway endpoint but I am getting error while deployment saying:
Subnet IDs are only supported for Interface and GatewayLoadBalancer type VPC Endpoints. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameter)
Is this a issue with subnet?
VpcEndpointSubnetIds:
Type: "List<AWS::EC2::Subnet::Id>"
Description: Select the subnet to associate with the VPC endpoint
Default: 'subnet-039c1ac2c0925fe94,subnet-0e9267fe210b042da'
VPCEndpointGateway:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref VpcId
ServiceName: !Ref dynamoDbEndPointServiceName
VpcEndpointType: Gateway
PrivateDnsEnabled: true
SubnetIds:
-
!Ref VpcEndpointSubnetIds
SecurityGroupIds:
-
!Ref cacheSecurityGroup
When crating VPCEndpoints the SubnetIds property is only supported by Interface and Gateway Load Balancer VPC endpoint types, for Gateway type you do not need this property, so you need to remove it:
VPCEndpointGateway:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref VpcId
ServiceName: !Ref dynamoDbEndPointServiceName
VpcEndpointType: Gateway
PrivateDnsEnabled: true
SecurityGroupIds:
- !Ref cacheSecurityGroup
For more information check the AWS::EC2::VPCEndpoint doc
I'm currently trying to deploy an application onto AWS ECS via CloudFormation templates. A docker image is stored in AWS ECR and deployed into an ECS Service fronted by an Application Load Balancer.
My service starts, and my load balancer is created, but the tasks inside of the ECS service repeatedly fail with the error:
Task failed ELB health checks in (target-group arn:aws:elasticloadbalancing:us-east-1:...
I've checked my security groups - the ECS Service Security Group includes the Load Balancer Security Group, and the Load Balancer is successfully created.
I've manually tried pulling my image on ECR and running it - no issues there. What am I missing? My template is below.
Resources:
ECSRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Effect: Allow
Principal:
Service: [ecs.amazonaws.com]
Action: ['sts:AssumeRole']
Path: /
Policies:
- PolicyName: ecs-service
PolicyDocument:
Statement:
- Effect: Allow
Action:
# Rules which allow ECS to attach network interfaces to instances
# on your behalf in order for awsvpc networking mode to work right
- 'ec2:AttachNetworkInterface'
- 'ec2:CreateNetworkInterface'
- 'ec2:CreateNetworkInterfacePermission'
- 'ec2:DeleteNetworkInterface'
- 'ec2:DeleteNetworkInterfacePermission'
- 'ec2:Describe*'
- 'ec2:DetachNetworkInterface'
# Rules which allow ECS to update load balancers on your behalf
# with the information sabout how to send traffic to your containers
- 'elasticloadbalancing:DeregisterInstancesFromLoadBalancer'
- 'elasticloadbalancing:DeregisterTargets'
- 'elasticloadbalancing:Describe*'
- 'elasticloadbalancing:RegisterInstancesWithLoadBalancer'
- 'elasticloadbalancing:RegisterTargets'
Resource: '*'
# This is a role which is used by the ECS tasks themselves.
ECSTaskExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Effect: Allow
Principal:
Service: [ecs-tasks.amazonaws.com]
Action: ['sts:AssumeRole']
Path: /
Policies:
- PolicyName: AmazonECSTaskExecutionRolePolicy
PolicyDocument:
Statement:
- Effect: Allow
Action:
# Allow the ECS Tasks to download images from ECR
- 'ecr:GetAuthorizationToken'
- 'ecr:BatchCheckLayerAvailability'
- 'ecr:GetDownloadUrlForLayer'
- 'ecr:BatchGetImage'
# Allow the ECS tasks to upload logs to CloudWatch
- 'logs:CreateLogStream'
- 'logs:PutLogEvents'
Resource: '*'
TaskDef:
Type: AWS::ECS::TaskDefinition
Properties:
Cpu: 4096
Memory: 30720
ContainerDefinitions:
- Image: !Ref ECRImageUrl
Name: !Sub "${ProjectName}-ecsContainer"
PortMappings:
- ContainerPort: 4000
HostPort: 4000
Protocol: tcp
Family: !Sub "${ProjectName}-taskDef"
ExecutionRoleArn: !Ref ECSTaskExecutionRole
RequiresCompatibilities:
- FARGATE
NetworkMode: awsvpc
Cluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: !Sub "${ProjectName}-ECSCluster"
Service:
Type: AWS::ECS::Service
DependsOn:
- LoadBalancerListener
Properties:
Cluster: !Ref Cluster
DesiredCount: 2
LaunchType: FARGATE
ServiceName: !Sub "${ProjectName}-ECSService"
TaskDefinition: !Ref TaskDef
NetworkConfiguration:
AwsvpcConfiguration:
SecurityGroups:
- !Ref FargateContainerSecurityGroup
AssignPublicIp: ENABLED
Subnets: !Split [',', {'Fn::ImportValue': !Sub '${VPCStackName}-PublicSubnets'}]
LoadBalancers:
- ContainerName: !Sub "${ProjectName}-ecsContainer"
ContainerPort: 4000
TargetGroupArn: !Ref TargetGroup
FargateContainerSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Access to the Fargate containers
VpcId:
Fn::ImportValue:
!Sub '${VPCStackName}-VPC'
EcsSecurityGroupIngressFromPublicALB:
Type: AWS::EC2::SecurityGroupIngress
Properties:
Description: Ingress from the public ALB
GroupId: !Ref 'FargateContainerSecurityGroup'
IpProtocol: -1
SourceSecurityGroupId: !Ref 'PublicLoadBalancerSG'
EcsSecurityGroupIngressFromSelf:
Type: AWS::EC2::SecurityGroupIngress
Properties:
Description: Ingress from other containers in the same security group
GroupId: !Ref 'FargateContainerSecurityGroup'
IpProtocol: -1
SourceSecurityGroupId: !Ref 'FargateContainerSecurityGroup'
PublicLoadBalancerSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Access to the public facing load balancer
VpcId:
Fn::ImportValue:
!Sub '${VPCStackName}-VPC'
SecurityGroupIngress:
- CidrIp: 0.0.0.0/0
IpProtocol: -1
ACMCertificate:
Type: AWS::CertificateManager::Certificate
Properties:
DomainName: !Sub ${ProjectName}.${DomainName}
ValidationMethod: DNS
TargetGroup:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
DependsOn:
- LoadBalancer
Properties:
TargetType: ip
Name: !Sub "${ProjectName}-ECSService"
Port: 4000
Protocol: HTTP
VpcId:
Fn::ImportValue:
!Sub '${VPCStackName}-VPC'
LoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Properties:
Scheme: internet-facing
Subnets: !Split [',', {'Fn::ImportValue': !Sub '${VPCStackName}-PublicSubnets'}]
SecurityGroups:
- !Ref PublicLoadBalancerSG
LoadBalancerListener:
Type: AWS::ElasticLoadBalancingV2::Listener
DependsOn:
- LoadBalancer
Properties:
DefaultActions:
- TargetGroupArn: !Ref TargetGroup
Type: 'forward'
LoadBalancerArn: !Ref LoadBalancer
Port: 443
Protocol: HTTP
It turns out that my security groups were not permissive enough. Traffic coming in from a Network Load Balancer is seen as coming from its original source, so if your NLB is open to all traffic, so should your Fargate containers. This fixed my issue:
FargateContainerSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Access to the Fargate containers
VpcId:
Fn::ImportValue:
!Sub '${VPCStackName}-VPC'
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: !Ref ApplicationPort
ToPort: !Ref ApplicationPort
CidrIp: 0.0.0.0/0
Health check feature automatically calls / at port 80 and expect 200 status code in response. Its available in EC2->target groups -> your ecs target group. You have to ensure you port is 4000 and in health check adjust default path and response status code.
Additionally you can always try connecting to your ec2 instance using public ip or DNS on port 4000 that you are using and see if that works.
If ec2 instance not working at port 4000 troubleshoot the docker deployment. There is something wrong with talks definition or parameters.
If it's working something wrong with target group trlargets or health check configuration.
Hope this helps.
After much pain and suffering, I found out that the ALB itself needs to associated with the security group (SG) that allows traffic on the ports that get dynamically allocated by ECS. You should have an SG defined automatically that defines those port ranges. Associate this SG with your ALB and your health checks will start passing (assuming everything else is hooked up correctly).
In addition, ensure that your task definition has network mode set to "bridge" & that the "hostPort" value is set to 0 -- this indicates to ECS to dynamically allocate a port on the underlying EC2 instance and map it to your container port.
I am starting an ECS task with Fargate and the container ends up in a STOPPED state after being in PENDING for a few minutes. The Status gives the following error message:
CannotPullContainerError: context canceled
I am using PrivateLink to allow the ECS host to talk to the ECR registry without having to go via the public Internet and this is how it is configured (Serverless syntax augmenting CloudFormation):
Properties:
PrivateDnsEnabled: true
ServiceName: com.amazonaws.ap-southeast-2.ecr.dkr
SubnetIds:
- { Ref: frontendSubnet1 }
- { Ref: frontendSubnet2 }
VpcEndpointType: Interface
VpcId: { Ref: frontendVpc }
Any ideas as to what is causing the error?
did you also add an S3 endpoint?
Here is a working snippet of my template, I was able to solve the issue with the aws support:
EcrDkrEndpoint:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
PrivateDnsEnabled: true
SecurityGroupIds: [!Ref 'FargateContainerSecurityGroup']
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ecr.dkr'
SubnetIds: [!Ref 'PrivateSubnetOne', !Ref 'PrivateSubnetTwo']
VpcEndpointType: Interface
VpcId: !Ref 'VPC'
For S3 you need to know that a route table is necessary - normally you would like to use the same as for the internet gateway, containing the route 0.0.0.0/0
S3Endpoint:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3'
VpcEndpointType: Gateway
VpcId: !Ref 'VPC'
RouteTableIds: [!Ref 'PrivateRouteTable']
Without an endpoint for cloudwatch you will get another failure, it is necessary too:
CloudWatchEndpoint:
Type: 'AWS::EC2::VPCEndpoint'
Properties:
PrivateDnsEnabled: true
SecurityGroupIds: [!Ref 'FargateContainerSecurityGroup']
ServiceName: !Sub 'com.amazonaws.${AWS::Region}.logs'
SubnetIds: [!Ref 'PrivateSubnetOne', !Ref 'PrivateSubnetTwo']
VpcEndpointType: Interface
VpcId: !Ref 'VPC'
EDIT: private route table:
PrivateRoute:
Type: AWS::EC2::Route
DependsOn: InternetGatewayAttachement
Properties:
RouteTableId: !Ref 'PublicRouteTable'
DestinationCidrBlock: '0.0.0.0/0'
GatewayId: !Ref 'InternetGateway'
I found I needed not only vpc endpoints for s3, aws logs and the two ecr endpoints as detailed in #graphik_ 's answer but I also needed to ensure that the security groups on the endpoints allowed ingress access to HTTPS from the security group on the Farscape containers.
The security group on the Farscape containers need egress access via HTTPS to the vpce endpoint security group and also to the pl-7ba54012 IP group which is s3.
This and the route to pl-7ba54012 in the route table seems to be the whole picture.
There are Policies on the vpce too, which I left as the default "All Access" but you could harden these up to only allow access from the Role running the Fargate containers.
I've got a CloudFormation Lambda Backed Custom Resource ,
Lambda function in public subnets but when I check the cloudWatch logs shown it below
Log-Message#1
Starting new HTTPS connection (1): cloudformation-custom-resource-response-eucentral1.s3.eu-central-1.amazonaws.com
Log-Message#2
Task timed out after 30.03 seconds
How I can handle this problem , my cloudformation is shown as below .
Resources:
HelloWorld: #Custom Resource
Type: Custom::HelloWorld
Properties:
ServiceToken:
Fn::GetAtt:
- TestFunction #Reference to Function to be run
- Arn #ARN of the function to be run
Input1:
Ref: Message
TestFunction: #Lambda Function
Type: AWS::Lambda::Function
Properties:
Code:
S3Bucket:
Ref: S3Bucket
S3Key:
Ref: S3Key
Handler:
Fn::Join:
- ''
- - Ref: ModuleName
- ".lambda_handler"
Role:
Fn::GetAtt:
- LambdaExecutionRole
- Arn
VpcConfig:
SecurityGroupIds:
- !Ref SecurityGroup
SubnetIds:
- Fn::Select: [ 0, !Ref PublicSubnet1 ]
- Fn::Select: [ 0, !Ref PublicSubnet2 ]
Runtime: python2.7
Timeout: '30'
LambdaExecutionRole: #IAM Role for Custom Resource
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- lambda.amazonaws.com
Action:
- sts:AssumeRole
Path: "/"
Policies:
- PolicyName: root
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
Resource: arn:aws:logs:*:*:*
- Effect: Allow
Action:
- ec2:CreateNetworkInterface
- ec2:DescribeNetworkInterfaces
- ec2:DeleteNetworkInterface
Resource: "*"
SecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupName: "sec_group_name"
GroupDescription: "SSH traffic in, all traffic out."
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
SecurityGroupEgress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
My subnets routing table associated with InternetGateway, but it giving CloudFormationResponse object error , How I can solve this connection problem .
Help ! Thanks :))
I am guessing your public subnet does not have a NAT gateway or NAT instance attached to it (InternetGateway alone is not enogh). As per AWS, this is required. If your functions does not need general internet access but access to AWS resources, you should consider VPC Endpoints. They are cheaper, but not sure if available for all resources.