Common FaaS & IaaS Security Concerns
Start course

As more and more organizations are moving towards a serverless or Function as a Service (FaaS) architecture and framework, understanding how this affects security is essential.  There are both pros and cons to implementing a serverless solution from a security perspective. This course will look at both the benefits and the negatives when adopting a FaaS solution and how this affects the safeguarding of your data.  

Most people have a deeper understanding of IaaS security, but some of the secure methods used within IaaS are not required within FaaS and vice versa.  There are also a number of security threats and concerns which affect both FaaS and IaaS architectures which will also be discussed.  
Towards the end of the course, it explains how serverless is impacted by the OWASP (Open Web Application Security Project) top 10 list of vulnerabilities.

Learning Objectives

By the end of this course, you will

  • Understand and be able to distinguish between the pros and cons of serverless security
  • Understand where to focus additional security controls in a FaaS solution
  • Have a general overview of how security differs to that of a typical IaaS solution

Intended Audience

This content in this course would be beneficial to:

  • Engineers who are focused on delivering secure serverless solutions within an enterprise environment
  • Security architects looking to enhance their knowledge of FaaS solutions
  • Developers deploying applications within a serverless environment


As a prerequisite of this course you should have a basic knowledge and awareness of the following:

  • A general understanding of what Serverless means
  • Understand what FaaS and IaaS relates to
  • A basic awareness of different attack vectors, such as DoS
  • AWS Lambda
  • Amazon Cognito
  • Amazon API Gateway
  • Security controls within IAM




Hello and welcome to this lecture where I want to look at some security concerns that are still apparent, regardless if you are using an IaaS or FaaS solution. Serverless does not change every aspect of a deployment. There are still many components that are impacted by the same security measures in a traditional infrastructure as a service department. 

The first point I want to mention is that of encryption. The fact that you are using either IaaS or FaaS has no impact on the sensitivity of your data you are utilizing and creating. So that point remains constant. The underlying architecture of how that data is begin stored and transferred has no impact if someone gains the ability to read the data. Data is either sent in transit or stored at rest. As a result, encryption options and mechanisms should be used to ensure that the data is encrypted in both states. Leaving data open as plain text is a breach waiting to happen, especially if the data contains sensitive and confidential information, such as PII. FaaS solutions do not automatically encrypt all communication channels, neither does it encrypt your data being stored while at rest. These security protection measures need to be architected into your solution. If you protect the data correctly with sufficient encryption, you protect your customers integrity should a breach occur. 

Next I want to mention permissions. I know I briefly touched on permissions earlier, but the fact remains for any solution out there. Managing access control permissions to resources and the level of actions set can be carried out on those resources is so important in the security strategy. Understanding access control and how to configure your permissions to be as granular as feasibly possible can be difficult to achieve, especially when trying to ascertain which API calls are required to carry out specific tasks by function and limiting access to only those called. In many environments, both IaaS and FaaS access controls is often implemented poorly with overly permissive access given to users, groups, and roles. This elevated level of permissions only serve as a greater risk, which unnecessarily exposes your environment. When assigning roles to a functions, be sure to adopt the least privilege rule to only assign permissions needed to carry out that function. 

The next couple of points I want to mention relate to the actual code used to create functions. Third party libraries of code are a security headache. Libraries are very useful to prevent developers from having to write their own code for something that is already been developed and proven to work. However, as this code has been written by someone else, how secure is that code? Has it been written to the best practices and how much can you really trust it? Not to mention the numerous dependencies that are likely to be embedded within those libraries, again these dependencies would have been developed by third parties. Although using these libraries make perfect operational sense from a developer point of view to speed up development, it does however provide a level of security concern for your security team. These libraries make it harder to ensure that code is doing what it is only supposed to do and not add any additional exposure to a application and your data. This makes input and output sanitization key for your deployments. You need to ensure that what is going in and coming out of your coded application is deemed as clean. 

The final point, and quite possible the biggest point I want to mention, is that there is still the fundamental issue of building security within your code that you write. Writing poor code, whether it be in an infrastructure as a service or function as a service environment, is still a big risk factor to your application and environment. Security best practices should be followed at all times when writing your code to minimize risks of exposure. And your code should be written to only perform that function that it needs to perform, nothing more, nothing less. Application level security is still very much a vulnerability in function as a service. Applications are susceptible to malicious activity through a variety of attack vectors, many of which are covered by the OWASP top 10 vulnerabilities list, which is what I should be covering in greater detail in the following lecture. So let's end this lecture and move on to focus on OWASP and service application security.

About the Author
Learning Paths

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.