Select your cookie preferences

We use cookies and similar tools to enhance your experience, provide our services, deliver relevant advertising, and make improvements. Approved third parties also use these tools to help us deliver advertising and provide certain site features.

Implementing governance in depth for serverless applications 1. Introduction 5 min
Heeki Park
Heeki Park Principal Solutions Architect, Serverless Specialist

Customers who build and deploy serverless, cloud-native applications must do so in a manner that both allows for agility and speed to market but also with appropriate governance and guardrails. Depending on your customer requirements, market conditions, and even product lifecycle, you set business level priorities, maybe emphasizing agility and speed to market as the top priority or alternatively emphasizing risk aversion via governance, guardrails, and controls. And realistically, you won’t have an “either/or” situation but an “and” situation where you have to balance both agility and guardrails in your software development lifecycle. So irrespective of where these capabilities fall in your journey, governance capabilities are likely to become an implementation requirement in your processes and toolchains.

This guide provides a practitioner’s view on implementing controls for developing and deploying AWS Lambda functions in your organization, both for the startup and the enterprise. Your organization may already have a pre-existing set of tools in place. We take a modular approach to these controls, so that you can pick and choose the components you actually need.

To help you better understand the types of governance required in deploying and operating serverless applications and how to implement those controls, this guide builds on an existing blog article on serverless governance and provides you with some opinionated and prescriptive approaches to implement those controls for your developers and toolchains. We mainly discuss these capabilities in the context of AWS services but briefly consider alternative open source tools at the end of this guide. While we recognize that security is foundational for a governance approach, we do not cover in-depth detail on security guidance in this document.

To frame our approach, you learn about governance approaches specific to serverless development in two primary categories, as described in the AWS Control Tower and AWS Prescriptive Guidance documentation: proactive controls and detective controls. In short, proactive controls are mechanisms that prevent developers from deploying resources that violate your governance policies, while detective controls are mechanisms that detect, log, and alert on resource deployments or configuration changes that violate your governance policies.

For proactive controls, AWS CloudFormation Guard can be used for enforcing policy on the local developer’s machine and then using that same mechanism in a code repository pre-commit validation webhook and also in deployment toolchains. For example, you might have an organizational policy that requires all Lambda functions to include a set of tags. CloudFormation Guard allows developers to test templates on his or her local machine against organizational policy prior to committing to code repositories instead of waiting for the pipeline to fail due to validation errors. This could potentially reduce developer feedback cycles from minutes down to seconds. Additionally, AWS Config can be used in proactive mode to run validation checks during the deployment process but prior to the provisioning of resources. If a violation is detected, the deployment of that function can be blocked.

For detective controls, AWS Config can subsequently be used for enforcing policy in your AWS environments. For example, you might have an organizational policy that requires all Lambda functions be VPC-enabled so that all traffic is subject to inspection and outbound rules. AWS Config in reactive mode runs detective checks against an AWS environment. This might be for situations where new governance policies have been implemented and now need to be applied against a pre-existing set of resources. For example, you might be implementing a new organization policy that only the latest managed AWS Lambda Insights layer is allowed to be attached to functions. This then reports on all functions where older versions of the Lambda Insights layer are attached and could optionally implement remediations as defined in an AWS Systems Manager Automation document.

Below are a few example controls for Lambda that might be implemented by an organization:

  • All Lambda functions must not be publicly accessible
  • All Lambda functions must be attached to a VPC
  • Lambda functions should not use deprecated runtimes
  • Lambda functions must be tagged with a set of required tags
  • Lambda layers must not be accessible outside of the Organization
  • Lambda functions with an attached security group must have matching tags between the function and security group
  • Lambda functions with an attached layer must use an approved version
  • Lambda environment variables must be encrypted at rest with a customer managed key

AWS Control Tower also has a number of managed controls that you can use or reference for building your own controls.

Organizations are also constantly evolving the portfolio of controls that are deployed in their AWS accounts. This is why governance controls need to be applied throughout the software delivery lifecycle with a governance-in-depth strategy. Below is a visualization of that strategy, implementing controls and policy at each step of the process.

1-introduction-governance-in-depth

In this guide, we take a look at a few areas and how the depicted services can meet your governance needs.

  • Developer tooling (local validation): CloudFormation Guard
  • Code repository (pre-commit webhook validation): CloudFormation Guard
  • Deployment (pipeline validation): CloudFormation Guard, AWS Config, Signer
  • Account (resources deployed): Amazon Inspector, AWS Config
  • Observability (for governance monitoring): CloudWatch