I am creating a ReceipRuleSet with troposphere like this :
ReceiptRuleSet(
title="SesRuleset",
RuleSetName="ses-ruleset"
)
However, when I upload the stack with the generated CloudFormation template, the RuleSet appears as inactive in SES.
Does anyone knows if there is a way to set the created RuleSet as active without having to interact with the online console nor the CLI ?
troposphere maintaner here. I don't actually know a ton about SES, but have you included the ReceiptRuleSet in a ReceiptRule? My guess is that if a RuleSet is not used by a Rule, it's probably inactive, since I can't see anything in either cloudformation or the API that would indicate you can set it to "active".
Unfortunately, this doesn't seem to be supported by Cloudformation. I found the following blog post leveraging a lambda doing an API call to activate the RuleSet after creation: https://binx.io/blog/2019/11/25/how-to-set-the-active-receipt-rule-set-in-ses-using-cloudformation/
This seemed one moving piece too many for me, so I'm currently activating the RuleSet through the console.
Related
I want to import a Portfolio that's shared with me but I'm unable to find the associated API action for it. (As I want to do it programmatically)
I'm looking for a translation in both Terraform as well as CFN of the specific API action and I can't seem to find it. Anyone an idea?
Terraform does not have a resource for this yet.
CloudFormation allows you to accept a portfolio share through the following resource:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-servicecatalog-acceptedportfolioshare.html
There are tons of similar questions both on this site and on the web, which leads me to believe there is something really wrong with AWS' documentation due to this causing grief to so many people.
So, I decided to post the most basic example step by step.
First, we create a new function:
It has default "everything", I don't touch a single line of code.
(the red error message is AWS not playing nice with Firefox)
The default code passes the test:
Now I add a trigger:
This gives me the link for the trigger:
I can go to the API endpoint: https://spy3z1jvu8.execute-api.ap-northeast-1.amazonaws.com/default/test
And it works:
Now, the problems will start. I open the API gateway that was created:
and try the default link: https://spy3z1jvu8.execute-api.ap-northeast-1.amazonaws.com
And...
Most of the people having similar questions seem to be having an issue with the gateway expecting some json content, etc, but here is an untouched AWS sample and the gateway link doesn't work.
The troubleshooting steps say to add logging and troubleshoot it that way, but there is nothing of interest in the logs.
What could be the origin of that problem?
What could be the origin of that problem?
You are correct. This is AWS/console fault. Specifically, it provides wrong permissions in the lambda's resource-based permissions for the default route to work. To fix that you have to edit the permissions.
Specifically, go to your function's Resource-based policy (this is different then execution role). You should find one Policy statement there which you have to edit. Then change in Source ARN from something like:
arn:aws:execute-api:ffffff:xxxx:api-id/*/*/function-name
to
arn:aws:execute-api:ffffff:xxxx:api-id/*/*
I'm using an AWS Lambda function to kick off a build in AWS CodeBuild when a Pull Request is created or updated in AWS CodeComimit, which is working well.
However, I'd like to be able to prevent the merging of that Pull Request in to the master branch of the repository, until the latest build for that PR has completed successfully.
Does anyone know if there's a way that can be done in AWS? E.g. so that the Merge button is disabled or not available, like when not enough approvers have been obtained?
I was looking into this myself and from what I understand, it is currently not possible to directly create this rule, but I think it should be doable with a different approach.
Instead of requiring a custom rule that disables merging (which doesn't exist today), you could make it so that the PR requires review from a specific IAM user. With that, you could probably use a fixed "build" user, and fire an automatic approval request for the PR once the build finishes successfully. This will in turn "approve" that rule in the PR and allow it to be merged after the build succeeds.
Since approval can be done via the CLI interface, I'm sure it should also be possible via API. For example, you could use this API to automatically mark any given PR as approved by the calling user, then ensure the service that is calling it is the same user registered in the "build" approval template.
Besides the HTTP WebApi, there are also other ways to call into these CodeCommit actions, like the AWS SDK library (C# example: https://www.nuget.org/packages/AWSSDK.CodeCommit/).
We would like to be able to understand the version of our software that is currently deployed to a particular AWS lambda. What are the best practices for tracking a code commit hash to an AWS lambda? We've looked at AWS tagging and we've also looked at AWS Lambda Aliasing but neither approach seems convenient or user-friendly. Are there other services that AWS provides?
Thanks
Without context and a better understanding of your use case around the commit hash, its difficult to give a directly useful answer, and as other answers have shown, there are many ways you could accomplish this. That being said, the commit hash of particular code is ultimately metadata and AWS has a solution for dealing with resource metadata: tags.
Best practice is to tag your resources with metadata. Almost all, if not all, AWS resources (including Lambda) support tags. As stated in the AWS documentation “tagging allows you to quickly search, filter, and manage resources” and subject to AWS limits your tags can be pretty much any key-value pair you like, including “commit: hash”.
The tagging strategy here would be to assign the commit hash to a tag, “commit” with the value “e63abe27”. You can tag resources manually through the console or you can apply tags as part of your build process.
Once tagged, at a high level, you would then be able to identify which commit is being used by listing the tags for the lambda in question. The CLI command would be something like:
aws lambda list-tags —resource arn:aws:lambda:us-east-1:123456789012:function:myFunction
You can learn more about tags and tagging strategy by reviewing the AWS docs here and you can download the Tagging Best Practice whitepaper here.
One alternative could be to generate a file with the Git SHA as part of your build system that is packaged together with the other files in the build artifact. The following script generates a gitSha.json file in the ${outputDir}:
#!/usr/bin/env bash
gitSha=$(git rev-parse --short HEAD)
printf "{\"gitSha\": \"%s\"}" ${gitSha} > "${outputDir}/git-sha.js"
Consequently, the gitSha.json may look like:
{"gitSha": "5c805638"}
This file can then be accessed either by downloading the package. Alternatively, you can create a function that inspects the file in runtime and returns its value to the caller, writes it to a log, or similar depending on your use case.
This script was implemented using bash and git rev-parse, but you can use any scripting language in combination with a Git library that you are comfortable with.
Best way to version Lambda is to Create Version option and adding these versions into an Alias.
We use this mechanism extensively for mapping a single AWS Lambda into different API gateway endpoints. We use environment variables provided by AWS Lambda to move all configurations outside the Lambda function. In each version of the Lambda, we change these environment variables as required and create a new version. This version can be mapped to an alias, which will help to keep the API gateway or the integration points intact (without any change for the integration)
if using serverless
try in serverless.yml
provider:
versionFunctions: true
and
functions:
MyFunction:
tags:
try serverless plugins, one of them
serverless plugin install --name serverless-version-tracker
it uses git tags as version
you need to manage git tugs then
I'm implementing a workflow with AmazonSWF and one of my activities comes in the form of a lambda function.
Both SWF and Lambda are being run on the London region, where they both work separately. However, my decider after polling for the task, it fails with the cause "LAMBDA_SERVICE_NOT_AVAILABLE_IN_REGION"
I haven't explicitly specified which region I'm working from in code, I assumed it would be the same one that I run the SWF web client in.
Here's the relevant code in my decider:
val attrs = ScheduleLambdaFunctionDecisionAttributes()
.withId("S3ControlWorkflowFunction")
.withName("S3ControlWorkflowFunction")
decisions.add(
Decision()
.withDecisionType(DecisionType.ScheduleLambdaFunction)
.withScheduleLambdaFunctionDecisionAttributes(attrs)
)
My activity worker doesn't do anything at all for the lambda function, but it shouldn't have to right?
I've registered the workflow with my IAM role here:
wf.registerWorkflowType(RegisterWorkflowTypeRequest()
.withDomain(DOMAIN)
.withName(WORKFLOW)
.withVersion(WORKFLOW_VERSION)
.withDefaultChildPolicy(ChildPolicy.TERMINATE)
.withDefaultTaskList(TaskList().withName(TASKLIST))
.withDefaultTaskStartToCloseTimeout("30")
.withDefaultLambdaRole(iamARN.id))
Found the fix.
Turns out calling lambda functions from SWF just isn't supported on region eu-west-2, as well as a few others. However I can't find any reference to this at all in the documentation. Found this forum post which gave me the hint. Migrating all the work I'd done over to eu-west-1 solved the issue. Poor show from Amazon here