Assuming the Serverless cli is already installed (here), init a new project with ‘serverless’ and answer the following questions:
% serverless
Serverless: No project detected. Do you want to create a new one? Yes
Serverless: What do you want to make? AWS Node.js
Serverless: What do you want to call this project? lambda-example
Project successfully created in 'lambda-example' folder.
In order to assume a role in another account, the owning account needs to grant a ‘trust relationship’ to those allowed to assume the role. This can be done by referencing an IAM username or role for those in the other account that are allowed to assume this role.
You can do this in the Console using the Trust Relationship tab:
A Policy to grant access to to a specific IAM user looks like:
For Servlerless to deploy into another account, if you attempt a Serverless deploy at this point, you’ll see errors like:
User: arn:aws:sts::ACCOUNT-ID:assumed-role/ServerlessLambdaDeployRole/lambdadeploy is not authorized to perform: cloudformation:CreateStack on resource: arn:aws:cloudformation:us-east-1:TARGET-ACCOUNT-ID:stack/deploy-demo/*
In this case cloudformation:CreateStack is missing from the assumed role. If you incrementally attempt to find what additional permissions you’ll need to deploy, you’ll also need to add:
cloudformation:DescribeStackEvents
cloudformation:DescribeStackResource
cloudformation:ValidateTemplate
cloudformation:UpdateStack
cloudformation:DeleteStack
apigateway:POST
iam:CreateRole
iam:PutRolePolicy
ValidateTemplate appears to throw an error unless the Resource is for a wildcard of ‘*’ and not anything more specific, otherwise you’ll see this error:
Error: The CloudFormation template is invalid: User: arn:aws:sts::ACOUNT-ID:assumed-role/ServerlessLambdaDeployRole/lambdadeploy is not authorized to perform: cloudformation:ValidateTemplate
To grant permissions for ValidateTemplate specify a Resource of “*”
The STS temporary credentials will expire after 1 hour, so if you see this error:
An error occurred (ExpiredToken) when calling the AssumeRole operation: The security token included in the request is expired
then you’ll need to rerun the ‘aws sts assume-role’ command again. If you previously set the session token in AWS_SESSION_TOKEN, you’ll need to set it back to blank (along with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) before you run the command again. When you get the refreshed values, remember to set the env vars with the updated values.
At this point, if you’ve run ‘aws sts assume-role’ and you’ve set the env vars for the returned temp credentials, you’ll be able to run a ‘serverless deploy’ and deploy into the other account where you’ve assumed this new role with the permissions to deploy. This should include permissions for creating a new Lambda and API Gateway, if you’re deploying anything else from your serverless config, you’ll need to add those permissions to the role you’re assuming.
I’m looking for a low cost managed db in the cloud for a small project, so thought I’d take a look at setting up an Aurora Serverless db, as depending on usage (and my usage will be very low) it looks like it’s definitely the cheapest of all AWS RDS options.
From the Console, from RDS, I pressed the ‘Create Database’ button:
If you select Aurora, the Serverless option is way down the page here:
I kept all the defaults, but changes the capacity to the smallest options:
After taking note of generated credentials and pressing the last ‘Create Database’ button, the dialog said it would take a couple of minutes to provision, and it sure did. I wasn’t timing it but it was at least 10 minutes before it was ready. This was probably the longest I’ve every waiting to provision anything on AWS.
Once it was ready, I tried to use the online query editor, but looks like there’s an additional step to create a user:
This option is under Network and Security:
After applying the change with the immediate option, I created a test table: