At re:Invent 2018, AWS announced Lambda Layers, bringing Lambda construct closer to that of an AMI. Put simply, layers are dependencies that can be made available to the function at runtime. Currently there can be 5 layers associated with a function. Layers help with isolating common dependencies, as well as keeping the runtime consistent in terms of versions - just like the AMIs do. Layers are immutable, and are versioned. While this post is focused on Python, the concept of layers applies uniformly regardless of the language (although I feel this is more useful for dynamic languages compared to languages like Java, where the whole artifact is packaged as a part of the deployment artifact). The dependencies are zipped up, uploaded as new layer, or a new version of an existing layer. They can be tied to runtimes (via labels) for validation as well.

In this post I’ll walk through creating a Python layer, and associating it with a function. I’ll use the CLI, aws-shell to accomplish this.

My CSAA from 2016 had expired, and I was in Vegas to attend re:Invent 2018. I took this opportunity to recertify the credential. This is a newer version of the exam, which made it exciting, but at the same time there were a lot of services that I had not really used, so had to go through the FAQs and documentation for those, along with the excellent acloud.guru course.

It took me about 4 days of serious prep, and I scored 927/1000. Working with AWS professionally for 6 years helped me in a lot of areas - particularly the well architected framework. Also, I loved my exam experience at re:Invent, compared to the typical exam centers we go to. It was far more relaxing, and I scored quite a bit of swag.

Here are the notes that I took while preparing for the exam.

Slides from my talk at OSCON 2018.

From functions to containers to databases, serverless is a huge paradigm shift. The ability to only pay for what we use and not worry about underlying infrastructure is very tempting to developers and DevOps engineers, and the rate of innovation in this area has been very rapid across all major public cloud providers. Serverless architectures are the natural evolution of microservices design. While Lambda has become synonymous with serverless in AWS, there are several new and upcoming patterns that take serverless architectures to the next level.

Manish Pandit explains how to identify these patterns and put them to use. Using Marqeta’s efforts to move its payments infrastructure to the public cloud as an example, Manish explores the services that Marqeta considered, customized, hacked around, and successfully implemented as a part of this move.

Amazon Cognito is a managed service that provides federated identity, access controls, and user management with multi-factor authentication for web and mobile applications. The service is very rich - any application developer can set up the signup and login process with a few clicks in Amazon Cognito Console by federating with identity providers such as Google, Facebook, Twitter, etc. One of the best features of Cognito is Lambda integration (Triggers), which allows Lambda invocation on events like pre-signup, pre and post authentication, etc.

In this post I will walk through a not so fancy, yet very useful Cognito feature - which is server to server authentication. This is one of the most common scenarios in a microservices world, where services need to talk to other services securely, and using an established standard such as OAuth2. This is also known as client_credentials Grant, or 2-legged OAuth. Amazon Cognito provides a simple and cost effective option to implement it.

Amazon API Gateway is a great way to wrap Lambda functions as microservices exposed over HTTP/S, among many uses. However, any API Gateway endpoint is publically accessible. There are ways to restrict access using IAM and Authorizers, but for simple task of IP whitelisting was always somewhat challenging, if not downright hack-y.

Recently AWS announced Resource Policies for API Gateway, which make IP whitelisting a breeze. This is extremely helpful for a company such as mine, as we deal with a lot of integrations that rely on IP whitelisting as one of the many layers of security. In this post I will walk through setting up IP whitelisting on an API hosted on API Gateway. We will use API Gateway’s built in Mock API feature to create a simple API, and secure it via IP Whitelisting.