AWS Public Sector Blog

How public sector security teams can use serverless technologies to improve outcomes

Serverless applications are typically discreet pieces of code that customers can use to manage security-related processes or stitch together multiple Amazon Web Services (AWS) services to solve a larger problem. They allow customers to build and run applications and services without dealing with infrastructure management tasks such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning. Customers can build them for nearly any type of application or backend service, and everything required to run and scale your application with high availability is handled for you. Serverless can help solve government challenges like operating with limited budgets and cybersecurity staffing constraints. The serverless computing model can help mitigate these constraints by shifting the operational burden to Amazon Web Services (AWS) and automating common manual tasks, so your staff can focus more on mission-related activities.

In this blog, I explain the serverless computing model, the Serverless Application Repository (SAR), solution constructs and implementations, why they matter to our government customers, and how they can use them to solve common problems.

When AWS develops services for customers, we start with the customer and work backwards. Personas define the typical roles in an organization that will use the service. There are two primary personas that describe customer usage of AWS services: the builder and the buyer. In this blog, I focus on the government buyer persona who is often the enterprise customer with a large, on-premises footprint that is being migrated to the cloud. This persona often has more regulatory and compliance requirements, and legacy technologies that add complexity, such that the focus is on minimizing risk over decreasing operational overhead or time to value. They typically procure prebuilt solutions that they integrate with other prebuilt solutions to enable their customers and solve business problems.

The cloud changes this paradigm and gives organizations the ability to build and deploy more customized solutions without the traditional heavy lift in time, effort, and operational overhead that a customized solution would require on premises. The serverless model is a particular case in point, where buyer personas can begin the shift to building solutions on AWS from the building blocks provided by AWS services, the SAR, and solution constructs and implementations. When organizations use the building blocks developed by AWS, they reduce their operational overhead, time to value, and risk.

What is the SAR, solution constructs, and solution implementations?

Serverless Application Repository

The SAR is a managed repository for serverless applications, enabling AWS customers to store and share reusable applications, and easily assemble and deploy serverless architectures in new ways. AWS and our customers create code to perform certain tasks, then submit them to the SAR. All applications published by AWS are vetted for license adherence and code quality. Applications published by AWS customers or third parties are validated by AWS for correct use of permissions so the consumers of those apps know which resources can be modified or accessed by an application.

Figure 1: How does SAR work?

Figure 1: How does SAR work?

For example, the lambda-janitor app creates a cron job for deleting old, unused versions of AWS Lambda functions. This is valuable because deleting unused Lambda functions is an important hygiene function that cleans up storage space and reduces costs, and also reduces risk by decreasing the footprint of attack vectors. When you manage your code repositories and remove old and unused code, you remove a potential risk from that code using older code versions or libraries that could include vulnerabilities.   This app can be used by anyone who wants to reduce their risk of code vulnerabilities by removing legacy code from their inventory. AWS Lambda is compliant with FedRAMP moderate and high in AWS GovCloud (US). For the government buyer persona, this makes it easier to get your serverless solution authorized in your environment.

If you need to address more complex challenges, you can stitch together multiple AWS services. An example is the amazon-cloudfront-access-logs-queries app. This is a sample implementation for the concepts described in this blog post “Analyzing your Amazon CloudFront access logs at scale” that uses AWS CloudFormationAmazon AthenaAWS GlueAWS Lambda, and Amazon Simple Storage Service (Amazon S3). There are hundreds of apps in the SAR for you to use. In addition to reducing the operational overhead, many SAR applications reduce the time to value for our government customers because they leverage FedRAMP authorized services, like Amazon API Gateway, Amazon RDS, Amazon CloudFront, AWS CloudFormation, Athena, and Amazon S3. Customers are encouraged to review the AWS Services in Scope by Compliance Program to verify the services used meet their compliance needs.

Solution constructs

Figure 2: Cloudfront API GW solution construct

Figure 2: Cloudfront API GW solution construct

Solutions constructs are similar to the SAR in that they are vetted architecture patterns. The difference is that they are available as an open source extension of the AWS Cloud Development Kit (CDK). The CDK provides high-level components that preconfigure cloud resources with proven defaults, so you can build production ready cloud applications without needing to be an expert in software development.

An example is the aws-cloudfront-apigateway-lambda construct that implements an Amazon CloudFront distribution fronting an Amazon API Gateway Lambda backed REST API.  The construct configures access logging for CloudFront web distributions and enables automatic injection of best practice HTTP security headers in all responses from CloudFront web distributions. It also deploys a regional API endpoint, enables Amazon CloudWatch logging for API Gateway, and configures a least privilege access IAM role for API Gateway. Solution constructs allow you to quickly build a portfolio of AWS vetted and well-architected architectural components that can be aligned with compliance requirements and used by both security teams and app developers.

Solution implementations

AWS solution implementations help you solve common problems and build faster using AWS. All AWS solutions implementations are vetted by AWS solutions architects and are designed to be operationally effective, reliable, secure, and cost efficient. Every AWS solutions implementation comes with detailed architecture, a deployment guide, and instructions for both automated and manual deployment.

Figure 3: AWS WAF automations architecture

Figure 3: AWS WAF automations architecture

An example is the AWS Web Application Firewall (AWS WAF) Security Automations that deploys a set of AWS WAF rules designed to filter common web-based attacks. Users can select from preconfigured protective features that define the rules included in an AWS WAF web access control list (web ACL). This helps security teams because the solution automatically deploys AWS Managed Rules core rule set that protects against exploitation of a wide range of common application vulnerabilities or other unwanted traffic. The solution also includes rules that allow customers to manually insert IP addresses they want to block or allow, enables SQL Injection and XSS, protects from HTTP floods, scanners and probes and bad bots to name a few. AWS WAF is another serverless FedRAMP service that reduces the overhead and time to value for government customers, making it easier to deploy for regulated customers.

The combined capabilities of the SAR, solution constructs, and implementations provide security teams and developers a large and growing portfolio of vetted AWS native and third-party code snippets, service integrations, and full-blown solutions for customers to use as part of their approved products and services lists as they deploy solutions in AWS.

This reduces the time it takes a security team to build standards on AWS, customers don’t need to clone, build, package, or publish source code to AWS before deploying it. Instead, they use pre-built applications and constructs that help reduce time consuming duplicative work, ensure organizational best practices, and improve the time to value. You still need to conduct your standardized security checks for all your code, but this approach can reduce the time to review code and the back and forth that can happen between security and development teams.

The SAR applications and solution implementations are deployed as AWS CloudFormation stacks, which make it easy for customers to manage an application as a single unit. Each resource is tagged with the application’s uniquely identifiable Amazon Resource Name (ARN), which helps locate the resources using the AWS Tag Editor console. You can also use existing AWS and third-party tools to manage each resource separately.

How can security-focused organizations use the SAR to improve outcomes? There are two basic models: single use and solution building. Single use model is where customers can quickly use vetted code and configuration parameters to solve security related application and architecture problems. You only have to configure settings—you don’t have to write code. The solution building model is a little more involved, where customers can deploy solution implementations or stitch multiple SAR apps and solution constructs together to solve larger security use cases in AWS.

Single use

The single use model works for customers who need to add a specific capability to their architecture. For example, perhaps you heard of AWS CISO Steve Schmidt’s top 10 things security teams should focus on and realized you have a gap in your management of secrets for your AWS databases. You can incorporate AWS Secrets Manager secret rotation for single or multiple users of RDS MySQL, PostgreSQL, Oracle, or Amazon Redshift (and other) databases using a common rotation scheme. You can do this by going to the AWS Serverless Application Repository, in the search box, enter text secrets manager single, select the checkbox that says Show apps that create custom IAM roles or resource policies.

There are multi-user apps you can select, however, in this use case, select the single user. Scroll down and select SecretsManagerRDSMySQLRotationSingleUser card. Review the Readme, License, and Permissions tabs. Once you understand the app, select the deploy button.

This will take you to the AWS Lambda service page in your account, where you have greater visibility into the specific template being used, the permissions being set, and the source code URL. For this, the source code is in GitHub. There are a couple items you need to configure in the Application settings section. First, give the function a name.

Figure 4: Secrets Manager RDS MySQL Single User Rotation App

Figure 4: Secrets Manager RDS MySQL Single User Rotation App

When you have filled out the configuration requirements, select deploy. This starts an AWS CloudFormation template that deploys the solution to your account. Select the Deployments tab and then select View stack events to watch the deployment process in the CloudFormation console. The CloudFormation creates a Lambda permission, and AWS IAM role for the Lambda function and the Lambda function itself that manages the secrets rotation. With the single use model, customers can improve their security and reduce the risk of credential theft by deploying serverless capabilities with minimal configuration requirements, and no coding required.

Solution building

The solution building model is about customizing AWS building blocks for your specific use case. In this model, the focus is on stitching AWS services, SAR, solution constructs, and\or implementations together to solve a problem without having to start from scratch.

These are intended for teams who may not be professional developers, but have the skills necessary to understand and modify Lambda functions, CloudFormation templates, and CDK constructs to create multi-service solutions.

Figure 5: CloudWatch log aggregation solution architecture

Figure 5: CloudWatch log aggregation solution architecture

Figure 6: AWS event rule solution construct architecture

Figure 6: AWS event rule solution construct architecture

For example, there are many common design patterns in constructs. Examples include aws-events-rule-step-function or aws-kinesisfirehose-s3-and-kinesisanalytics.

Perhaps you want to deploy a centralized logging implementation, but also need to aggregate your Lambda edge logs and create some custom CloudWatch Event rules to notify your security team when certain behavior is logged in CloudTrail.

Deploy the centralized logging solution implementation, add the lambda-edge-logs-aggregator SAR app, perhaps include the cloudwatch-logs-janitor SAR app. Once your logging solution is built, deploy the aws-events-rule-step-function solution construct and configure the custom event pattern for AWS CloudTrail events to be sent to your Step Functions target.

Figure 7: Automated security incident response architecture

Figure 7: Automated security incident response architecture

Another common example is performing automated security incident response in multiple accounts. Use AWS Services as building blocks to create a serverless architecture that improves incident response times. In Figure 7, this includes AWS serverless services like Amazon GuardDuty for threat detection, AWS Security Hub to aggregate findings, AWS Config to manage actual and desired configuration states of your cloud assets, AWS Systems Manager Automations to simplify common security tasks on AWS resources, and AWS Lambda to build out remediation actions.

Use the aws-events-rule-lambda Solution Construct that will grant least privilege permissions to CloudWatch Events to trigger the Lambda Functions to handle your custom remediation.


In this blog, I discussed the value of the serverless computing model and how public sector customers can use the SAR, solution constructs, and implementations to reduce build times, solve common problems, and be a strategy for transitioning teams from being buyers of technology to builders of cloud solutions. If you’re ready to explore how you can incorporate serverless technologies into your architecture, take a look at the existing solution implementations and constructs in the AWS Solutions Library. Discover ways to automate your security processes in AWS Security Blogs by reviewing solutions like Automated Response and Remediation with AWS Security Hub and “How to get started with security response automation on AWS.” Finally, reach out to your AWS account team for a deep dive on automating security, reducing operational overhead and risk in your AWS accounts.