Welcome to part one of our five-part “AWS Well-Architected Framework in Serverless” series. In this article, we’ll give you a short introduction to the AWS Well-Architected Framework and dive deeper into the Security pillar to explain it and some actionable ideas related to it.

Introduction to the Well-Architected Framework

The AWS Well-Architected Framework (WAF) is a collection of whitepapers that outline best practices for building software with AWS infrastructure. The framework is split into one main whitepaper that gives an overview and five more detailed whitepapers, called pillars. These pillars are Operational Excellence (OPS), Security (SEC), Reliability (REL), Performance Efficiency (PERF), and Cost Optimization (COST).

Each pillar contains questions you should be able to answer for your AWS based software. These answers relate to technical or organizational decisions that are not directly related to the features your software provides.

For example, when you build a blog, you want people to write articles and other people to read articles to implement features for these use-cases. But you also want your system to be safe, your servers to handle all the traffic, and have all this for a reasonable price.

You can find out more about how to save money on your Lambdas here.

The answers to these questions are sometimes as simple as using a special AWS service (technical). Sometimes, they require you to implement some kind of process in your company (organizational) because it can’t be automated entirely.

The most crucial pillars are OPS and SEC. They should never be traded in to get more out of the other three pillars. This is because the answers to the OPS questions lead to the foundational setup needed to facilitate the answers to other pillars’ questions with a sane amount of work. And the savings on SEC could lead to breaches that can destroy your company overnight.

The other three pillars REL, PERF, and COST, are a matter of business requirements. Going too cheap may render your system unusable, but going 100% on REL and PERF might be far too expensive to build a sustainable business. Depending on your budget, you have to weigh these pillars against each other to get the optimal solution.

Maybe it’s okay for a customer to wait a bit longer for their results, and you invest more money into long-term data retention. Maybe nobody will use an expensive system that delivers sub-second results, but they will use one that takes a few seconds but is substantially cheaper.

AWS also offers a free Well-Architected tool and hands-on guides that help understand the WAF and answer its questions for your software. This way, you can train WAF principles even without your own software and evaluate architecture ideas you got for the software you want to or already have built.

There are additional, more specialized whitepapers, called lenses. These consolidate the general WAF pillars’ ideas and specify their questions regarding a specific type of software. For example, serverless applications, machine learning, or IoT.

In this article, we will focus on the Serverless Application Lens, which “covers common serverless applications scenarios and identifies key elements to ensure that your workloads are architected according to best practices.” A workload here is a collection of software systems, called components, that deliver business value.

A monolithic software system can be a workload, but a collection of different microservices can also form a workload.

Dashbird WAF Insights Features

Dashbird features a continuous engine for detecting and enforcing Serverless Well-Architected practices. Dashbird is constantly running users’ infrastructure data through its WAF rule engines detecting anomalies and weaknesses within the architecture, and notifying the users of critical errors and/or when improvements should be made.

This allows developers to build and operate complex Well-Architected serverless applications without compromising its reliability over time and also be able to layer on complexity later on.

The AWS Well-Architected Framework Security Pillar

As mentioned above, the SEC pillar is one of the two most important pillars, the other one being the OPS pillar. You shouldn’t trade this pillar in to save money or make a bit faster responses. If a country you operate in requires you to use a minimal amount of security measures for a specific type of data or system, you can’t cut corners.

This doesn’t mean you have to encrypt all your data with a one time pad and mail people hard drives filled with encryption keys. It just means keeping your system at least as safe as required and going over that if you can justify it somehow without getting you and your customers into trouble. After all, a security breach can take down your company in a blink of an eye, so it’s worth staying safe and secure!

The SEC pillar itself is also subdivided into five parts; let’s look into them:

Identity and Access Management

The first part is “identity and access management,” which forms the core of the pillar. It could also be called authentication and authorization. If you want to keep your system safe, you need to know who (identity) is using it and what they are using (access).

Detective Tools

The second part is “detective controls.” If you want to protect your system, you need a way to monitor that security was breached; otherwise, you don’t know it’s safe.

Infrastructure Protection

The third part is “infrastructure protection,” which is about protecting networks and compute resources. In terms of serverless, most of this is done by AWS because the services you use don’t expose networks or servers directly. You still need to use the right access permissions, but you usually don’t need to think about kernel patches or TCP inspection.

Data Protection

Then there is “data protection.” You don’t want your data or the data of your users to get stolen. The most important step in protecting your data is to classify your data by security needs because encrypting everything as strong as possible is prohibitively expensive.

Incident Response

Last but not least, there is “incident response.” After you did everything to protect your system, things can still go wrong, and often your whole reputation is staked on how “you anticipate, respond to, and recover from incident[s].”

Dashbird Well-Architected Insights: Security

In the serverless world, security is more often overlooked and underrated by engineering teams, as opposed to traditional architectures. Dashbird’s WAF insights for security currently include detecting abandoned resources to reduce the available attack surface and finding unencrypted DynamoDB tables.

SAL Questions of the Security Pillar

The SAL asks three questions about the security of your serverless applications. Let’s look at how these can be answered.

SEC 1: How do you control access to your Serverless API?

You can build serverless APIs on AWS either with Amazon API Gateway for HTTP, WebSockets, and REST APIs or with AWS AppSync for GraphQL APIs.

To authorize internal (that means inside AWS and inside your account) services, you can use IAM roles. For internal users, IAM users are the solution.

If you need your customers or “end users” to access your APIs, you need Amazon Cognito User Pools. They help with sing ups and logins and even integrate with social providers to make the well known “Facebook Login” possible.

If you have to integrate with external services and know the IP ranges they are hosted on, you can configure resource policies. If you don’t know the IP ranges, you should use temporary credentials to give access.

Finally, API Gateway Lambda authorizers allow you to implement any custom authentication workflow you may need; this is especially helpful when integrating with legacy auth services.

SEC 2: How are you managing the security boundaries of your Serverless Application?

The security principle of least privilege also holds in serverless systems. Don’t give everyone execution rights to your Lambda functions and only give minimal permissions to every Lambda function. Also, don’t reuse IAM permissions between multiple Lambda functions and forget to remove permissions again when they become obsolete.

Your CI/CD pipeline should also include a vulnerability scan that checks your code and all of its dependencies for security issues right before you deploy it.

API Gateway and AppSync connections are encrypted in transit by default, but you should keep in mind that the URL might not be, so don’t put private information into the path or query string. The AWS API services also support selective access logs. They should be configured in a way that they don’t log sensitive data.

Encryption at rest should be enabled for DynamoDB and S3 if sensitive data is stored.

SEC 3: How do you implement Application Security in your workload?

You should always validate and sanitize all data from the outside and scan your code for vulnerabilities like you would with non-serverless systems, nothing special here.

And don’t forget to store the credentials to third-party APIs in the AWS Secrets Manager, so they’re always encrypted at rest.

Summary

The WAF and the SAL are an exciting collection of whitepapers to read when building serverless applications. Not only when you design these systems but also after you release them to production. It’s a dense material, and often some things get clearer after you build your application. It would help if you also looked into Well-Architected Tool, which is a bit more interactive in questioning you about your system, which can also help because sometimes we like to skip things we feel uncomfortable with.

This article talked a bit more about the SEC pillar and what it’s all about. Authenticate your users and services, encrypt private data, and respond accordingly when anything was breached. Always keep the principle of least privilege in mind when you set permissions; this goes for everything, not just your public-facing API Gateway. Security has to be applied on all layers of your architecture; if your front door breaks, you don’t want attackers to storm right down to the database.

Keep your eyes peeled for Part 2, where we’ll be deep-diving into the Operational Excellence pillar.

You can find out more about building complex, Well-Architected serverless architectures in our recent webinar with Tim Robinson (AWS):