[{"data":1,"prerenderedAt":89},["ShallowReactive",2],{"content-svc-lambda-guides-governance-1-introduction":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":14,"menu":15,"menuType":82,"isCollapseableMenu":18,"nextDocItem":27,"previousDocItem":83,"contributorPaths":84,"contentName":88,"slug":26,"readingTime":23},"\u003Cp>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\u002For” 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fbuilding-aws-lambda-governance-and-guardrails\u002F\">existing blog article\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>To frame our approach, you learn about governance approaches specific to serverless development in two primary categories, as described in the \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Fcontrols.html\">AWS Control Tower\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Faws.amazon.com\u002Fprescriptive-guidance\u002F\">AWS Prescriptive Guidance\u003C\u002Fa> documentation: \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Fproactive-controls.html\">proactive controls\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Faws-security-controls\u002Fdetective-controls.html\">detective controls\u003C\u002Fa>. 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonCloudWatch\u002Flatest\u002Fmonitoring\u002FLambda-Insights.html\">AWS Lambda Insights\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>Below are a few example controls for Lambda that might be implemented by an organization:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>All Lambda functions must not be publicly accessible\u003C\u002Fli>\n\u003Cli>All Lambda functions must be attached to a VPC\u003C\u002Fli>\n\u003Cli>Lambda functions should not use deprecated runtimes\u003C\u002Fli>\n\u003Cli>Lambda functions must be tagged with a set of required tags\u003C\u002Fli>\n\u003Cli>Lambda layers must not be accessible outside of the Organization\u003C\u002Fli>\n\u003Cli>Lambda functions with an attached security group must have matching tags between the function and security group\u003C\u002Fli>\n\u003Cli>Lambda functions with an attached layer must use an approved version\u003C\u002Fli>\n\u003Cli>Lambda environment variables must be encrypted at rest with a customer managed key\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>AWS Control Tower also has a number of \u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Flambda-rules.html\">managed controls\u003C\u002Fa> that you can use or reference for building your own controls.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F1-introduction-governance-in-depth.png\" alt=\"1-introduction-governance-in-depth\">\u003C\u002Fp>\n\u003Cp>In this guide, we take a look at a few areas and how the depicted services can meet your governance needs.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Developer tooling (local validation): CloudFormation Guard\u003C\u002Fli>\n\u003Cli>Code repository (pre-commit webhook validation): CloudFormation Guard\u003C\u002Fli>\n\u003Cli>Deployment (pipeline validation): CloudFormation Guard, AWS Config, Signer\u003C\u002Fli>\n\u003Cli>Account (resources deployed): Amazon Inspector, AWS Config\u003C\u002Fli>\n\u003Cli>Observability (for governance monitoring): CloudWatch\u003C\u002Fli>\n\u003C\u002Ful>\n",{"title":6,"order":7,"authors":8,"callout":10},"1. Introduction",1,[9],"Heeki Park",{"title":11,"description":12,"link":13},"Watch this video","This reinvent 2023 video covers the topics of this guide in further detail.","https:\u002F\u002Fyoutu.be\u002Fqlz15v-gHFI","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\u002For” 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.\n\nThis 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.\n\nTo 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](https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fcompute\u002Fbuilding-aws-lambda-governance-and-guardrails\u002F) 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.\n\nTo frame our approach, you learn about governance approaches specific to serverless development in two primary categories, as described in the [AWS Control Tower](https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Fcontrols.html) and [AWS Prescriptive Guidance](https:\u002F\u002Faws.amazon.com\u002Fprescriptive-guidance\u002F) documentation: [proactive controls](https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Fproactive-controls.html) and [detective controls](https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Faws-security-controls\u002Fdetective-controls.html). 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.\n\nFor 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.\n\nFor 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](https:\u002F\u002Fdocs.aws.amazon.com\u002FAmazonCloudWatch\u002Flatest\u002Fmonitoring\u002FLambda-Insights.html) 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.\n\nBelow are a few example controls for Lambda that might be implemented by an organization:\n\n* All Lambda functions must not be publicly accessible\n* All Lambda functions must be attached to a VPC\n* Lambda functions should not use deprecated runtimes\n* Lambda functions must be tagged with a set of required tags\n* Lambda layers must not be accessible outside of the Organization\n* Lambda functions with an attached security group must have matching tags between the function and security group\n* Lambda functions with an attached layer must use an approved version\n* Lambda environment variables must be encrypted at rest with a customer managed key\n\nAWS Control Tower also has a number of [managed controls](https:\u002F\u002Fdocs.aws.amazon.com\u002Fcontroltower\u002Flatest\u002Fuserguide\u002Flambda-rules.html) that you can use or reference for building your own controls.\n\nOrganizations 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.\n\n![1-introduction-governance-in-depth](\u002Fassets\u002Fexternal\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002Fassets\u002Fimages\u002F1-introduction-governance-in-depth.png)\n\nIn this guide, we take a look at a few areas and how the depicted services can meet your governance needs.\n\n* Developer tooling (local validation): CloudFormation Guard\n* Code repository (pre-commit webhook validation): CloudFormation Guard\n* Deployment (pipeline validation): CloudFormation Guard, AWS Config, Signer\n* Account (resources deployed): Amazon Inspector, AWS Config\n* Observability (for governance monitoring): CloudWatch\n",[16],{"title":17,"collapsible":18,"isCollapsed":18,"content":19},"Governance in Depth",false,[20,27,36,45,52,60,67,74],{"title":6,"order":7,"authors":21,"callout":22,"time":23,"path":24,"id":25,"link":26},[9],{"title":11,"description":12,"link":13},"5 min","1-introduction","1-introduction.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F1-introduction",{"title":28,"order":29,"authors":30,"time":32,"path":33,"id":34,"link":35},"2. Proactive Controls with AWS CloudFormation Guard",2,[9,31],"Pallavi Srivastava","4 min","2-proactive-guard","2-proactive-guard.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F2-proactive-guard",{"title":37,"order":38,"authors":39,"time":41,"path":42,"id":43,"link":44},"3. Proactive Controls with AWS Config",3,[40],"Debasis Rath","6 min","3-proactive-config","3-proactive-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F3-proactive-config",{"title":46,"order":47,"authors":48,"time":23,"path":49,"id":50,"link":51},"4. Detective Controls with AWS Config",4,[40],"4-detective-config","4-detective-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F4-detective-config",{"title":53,"order":54,"authors":55,"time":56,"path":57,"id":58,"link":59},"5. Code Signing with AWS Signer",5,[9],"3 min","5-code-signing","5-code-signing.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F5-code-signing",{"title":61,"order":62,"authors":63,"time":56,"path":64,"id":65,"link":66},"6. Code Scanning with Amazon Inspector",6,[31],"6-code-scanning","6-code-scanning.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F6-code-scanning",{"title":68,"order":69,"authors":70,"time":41,"path":71,"id":72,"link":73},"7. Observability for Security and Compliance",7,[40],"7-observability","7-observability.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F7-observability",{"title":75,"order":76,"authors":77,"time":78,"path":79,"id":80,"link":81},"8. Discussion of Open Source and other AWS tools",8,[9],"1 min","8-open-source-and-other-tools","8-open-source-and-other-tools.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F8-open-source-and-other-tools","LIST",null,[85,86,87],"content\u002Fcontributors\u002Fheeki-park.json","content\u002Fcontributors\u002Fdebasis-rath.json","content\u002Fcontributors\u002Fpallavi-srivastava.json","Implementing governance in depth for serverless applications",1791196516989]