In Simple Notification Service (SNS) filtering messages based on the attributes in the message is one of the great features offered by SNS. Message filtering within SNS has many advantages. One key benefit is that you don’t have to set up a separate filtering process or service which will be resource intensive. You can save significant compute resources (hence money) with filtering within SNS, which otherwise should do using ec2 or Lambda.

Without a doubt, security is one of the key aspect to focus in AWS. It is not only authentication is critical, but authorization is a must to consider specially in the production systems where lot of parties (users, resources, services) should be given only the specific permissions in the AWS environment. AWS IAM policies provides great amount of facilities in order to set up granular level of permissions. Tag based permissions are one of the cool feature supported by IAM.

Recently, one of my friend/client came up with the scenario below. Scenario: There is a lambda function, which calls to a external API and fetch some data. This external API only accepts incoming requests only from pre-configured whitelisted IPs. As per today, AWS doesnt’ support elastic IPs for Lambda. However, there is a simple work around. Solution: Simple solution is, to create the lambda function within a VPC and make the 3rd party API to be accessible via a NAT gateway.

IAM Policy version is a useful feature in IAM when try to identify the correct access rights for a particular policy and switch between the changes applied to the policies. Please Note: Policy versions are not available for inline policies. When you update a particular customer manage policy, AWS will not over-write the existing policy. But new version is created and set as the default version. Image: Policy versions listing for a single IAM Policy

Lambda by nature is highly scalable. However there ares some limitations you need to consider when there are lot of Lambda functions run simultaneously. Please note: This will not applicable for all the scenarios, but for a system with a high throughput. Account Level Concurrent Execution Limit As at now, Lambda has a soft limit of 1000 concurrent executions per region. Which means, at any given moment, sum of lambda executions running belongs to all of your lambda functions in a single region must be less than 1000.