I have a CloudFormation template that creates my RDS cluster using aurora serverless. I want the cluster to be created with the data API enabled.
The option exists on the web console:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html
But I can't find it on the CloudFormation documentation.
How can I turn this option on from the template?
Set the EnableHttpEndpoint property to true, e.g.:
AWSTemplateFormatVersion: '2010-09-09'
Description: Aurora PostgreSQL Serverless Cluster
Resources:
ServerlessWithDataAPI:
Type: AWS::RDS::DBCluster
Properties:
Engine: aurora-postgresql
EngineMode: serverless
EnableHttpEndpoint: true
ScalingConfiguration:
...
You can enable the Data API from CloudFormation by creating a custom resource backed lambda and enable it using any of the available SDK.
I use boto3 (python), so the lambda would have code similar as below:
import boto3
client = boto3.client('rds')
response = client.modify_db_cluster(
DBClusterIdentifier='string',
EnableHttpEndpoint=True|False
)
Obviously, you need to handle different custom resource request types and return from the lambda with success or failure. But to answer your question, this is the best possible way to set up data API via CloudFormation, for now, IMHO.
For more information about the function (Boto3):
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.modify_db_cluster
Enabling the Data API is currently only possible in the web console. This feature is still in beta so things like CloudFormation support and availability outside of us-east-1 are still pending, and using the Data API in production should be done with caution as it may still change.
Related
I am using cloudformation to provision lambda and RDS on AWS. But I don't know how to add database proxy on lambda. Below screenshot is from lambda console:
Does cloudformation support adding this? I can't see it in lambda and db proxy template.
The exact configuration I use in CloudFormation template is:
MyLambdaFunction:
Type: AWS::Serverless::Function
Properties:
Policies:
- Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- rds-db:connect
Resource:
- <rds_proxy_arn>/*
where <rds_proxy_arn> is the ARN of the proxy but service is rds-db instead of rds and resource type is dbuser instead of db-proxy. For example, if your proxy's ARN is arn:aws:rds:us-east-1:123456789012:db-proxy:prx-0123456789abcdef01 the whole line should be arn:aws:rds-db:us-east-1:123456789012:db-proxy:prx-0123456789abcdef01/*.
After deployed, we can see a new link is added in Database Proxies of the Console.
As per the CloudFormation/Lambda documentation there is no option to specify the DB Proxy for a Lambda.
I don't see an option to add an RDS proxy while creating a Lambda function in the low level HTTP API also. Not sure why.
As per the following Github issue, it seems this is not required to connect lambda to RDS proxy. https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/750
You merely need to provide the new connection details to lambda (e.g. using env variables to make it work)
After talking with AWS support, the screenshot in AWS console to add proxy on lambad is only to grant below IAM permission to lambda. That means it is an optional.
Allow: rds-db:connect
Allow: rds-db:*
Im creating API gateway stage using cloudformation.
ApiDeployment:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId: !Ref ExampleRestApi
StageName: dev
Here is the problem, Whenever I create a new API, I just need to deploy the stage using AWS console. is there any way that I can automate the deploy process so that no further console action is required.
When you define a Deployment resource like this, CloudFormation will create the deployment only on the first run. On the second run it will observe that the resource already exists and the CloudFormation definition did not change, so it won't create another deployment. To work around that, you can add something like a UUID/timestamp placeholder to the resource ID and replace it everytime before doing the CloudFormation update:
ApiDeployment#TIMESTAMP#:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId: !Ref ExampleRestApi
StageName: dev
This way you are still able to see your deployment history in the API Gateway console.
If you don't want to manipulate your template like this, you can also add a Lambda-backed Custom Resource to your CloudFormation stack. Using an AWS SDK, you can have the Lambda function automatically creating new deployments for you when the API was updated.
I've found berenbums response to be mostly correct, but there are a few things I don't like.
The proposed method of creating a resource like ApiDeployment#TIMESTAMP# doesn't keep the deployment history. This makes sense, since the old ApiDeployment#TIMESTAMP# element is being deleted and a new one is being created every time.
Using ApiDeployment#TIMESTAMP# creates a new deployment every time the template is deployed, which might be undesirable if the template is being deployed to create/update other resources.
Also, using ApiDeployment#TIMESTAMP# didn't work well when adding the StageDescription property. A potential solution is to add a static APIGwDeployment resource for the initial deployment (with StageDescription) and ApiDeployment#TIMESTAMP# for the updates.
The fundamental issue though, is that creating a new api gw deployment is not well suited for cloudformation (beyond the initial deployment). I think after the initial deployment, it's better to do an AWS API invocation to update the deployment (see https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-deployments.html).
In my particular case I created a small Ansible module to invoke aws apigateway create-deployment which updates an existing stage in one operation.
Is it possible to specify Point In Time Recovery for an Amazon DynamoDB table created via CloudFormation? I've been looking through the docs and user guide and haven't found anything useful yet.
This is now possible with cloud formation by adding a PointInTimeRecoverySpecification to your cloud formation template.
Example:
Type: 'AWS::DynamoDB::Table'
Properties:
TableName: MyTable
PointInTimeRecoverySpecification:
PointInTimeRecoveryEnabled: true
...
I'm working with AWS API Gateway and AWS Lambda. Often I face this type of error message when attempt to deploy API. The error message says to select a deployment stage. But I still selecting and trying to deploy! but same error occur!
In this API I have multiple resources with multiple methods. Previously I succeed to deploy this same API with the same way. But now I can't deploy it.
Please anyone help me to fix it. For addition: I don't use AWS CLI tool, just use AWS web dashboard.
I talked with customer service center of AWS. The problem was:
In this API there was an unintegrated method. Suppose there are a resource image and I create a POST method for this resource. But I forgot to integrate it to any AWS Lambda Function or HTTP. So the API cannot be deployed.
If the method is unnecessary then delete the method. OR you can integrate it as Mock endpoint. You can change this endpoint anytime.
Note: For this unintegration problem AWS gives this type of wrong error message. They should update their message to save developer's time.
I was getting same error but when creating API using CloudFormation.
It turned out that in my AWS::ApiGateway::Deployment resource, I needed to include DependsOn attribute that "depends" on all my API methods.
For example, when building API with two AWS::ApiGateway::Method resources, AWS::ApiGateway::Deployment needs to depend on both these methods:
MyFirstApiMethod:
Type: AWS::ApiGateway::Method
Properties:
<your properties>
MySecondApiMethod:
Type: AWS::ApiGateway::Method
Properties:
<your properties>
MyDeployment:
Type: AWS::ApiGateway::Deployment
DependsOn: [MyFirstApiMethod, MySecondApiMethod] # <-- REQUIRED
Properties:
RestApiId: !Ref MyRestApi
Without the DependOn attribute on all the API methods, CloudFormation may be
creating them after the deployment resource, resulting in No integration defined for method error.
If you have another resource which is not completed to configuration it will read as well. In short, if you haven't given them a lambda function, the api itself is not allowed to be deployed until you finish the rest.
I encountered the same error with deploying via Terraform. The reason was I defined an IAM role for my API and I didn't include the role resource to triggers when deploying the API. Just make sure all resources that are defined before deploying are included in triggers.
Just integrate Lambda function in every method you created.
Make sure every resource and method is configured properly.
Let's say your api-gateway is hierarchy is like:
/
R1
R2
M1
M2
R3
M3
so every resource(R1,R2,R3) and every method(M1,M2,M3) should be configured properly.
I deployed using CDK with --no-rollback (this should work for any cloudformation though)
In my case, the API was created and I could inspect it in the AWS Console, and only the "AWS::ApiGateway::Deployment" failed to create. It turns out I had a bad value for service attribute (I was using StepFunctions, which was not working)
THEN I see that I have a dangling resouce/method that is broken - so my deployment was failing due to garbage in AWS, not my CDK/template.
I'm trying to use AWS CloudFormation to manage my stack. I've created ApiGateway APIs through the AWS console before and it has worked fine. However, when I try to add an AWS::ApiGateway::RestApi in my CloudFormation stack template it fails to create the stack with the error Resource is not supported in this region.
Why would the result be different between the console and CloudFormation?
Thanks in advance,
Indigo
I already inform AWS CloudFormation team. They should solve this issue shortly. In the meanwhile, please use AWS API Gateway console or SDK to manage your API Gateway resources.
Thanks,
-Ka Hou
As of this writing, it is possible to create a CloudFormation resource of type AWS::ApiGateway::RestApi in the Sydney stack. Just tested that out myself by creating a test template in Syndey region:
Resources:
MyRestApi:
Type: "AWS::ApiGateway::RestApi"
Properties:
Name: "MyRestAPI"
just to add to it, now we have the edge functionality available with AWS, according to which deployment is now not restricted to region specific. With the Edge Functionality you can make your APIs Endpoint to be called from any region after deployed once.
so the CFT for the API to be Region independent can be described as
ApiGatewayRestApi:
Type: 'AWS::ApiGateway::RestApi'
Properties:
Name: !Sub "API Name"
EndpointConfiguration:
Types:
- EDGE
Policy: ''
This will make sure the API Endpoint will be available to all the Regions.