Platform Engineering Isn’t Just for Kubernetes—Serverless Needs It Too!
- Anton Aleksandrov
- 3 hours ago
- 8 min read
Platform engineering is often associated with Kubernetes, but the same principles apply to serverless as well. As serverless adoption grows, teams face operational and DevEx challenges that require similar engineering solutions.
In this post, you'll learn how platform engineering principles apply to serverless too—and why they're key to scaling infrastructure, security, and developer experience.
This post was written by Ran Isenberg and Anton Aleksandrov.
Table of Contents
Co-writer Introduction
Anton Aleksandrov is a Principal Solutions Architect for AWS Serverless and Event-Driven architectures, with over two decades of hands-on engineering and architecture experience. He helps major ISV and SaaS customers design highly scalable, innovative, and secure cloud solutions.
AWS re:Invent 2025
This year, I’m thrilled to share the stage with Anton at AWS re:Invent to explore how Serverless and platform engineering go together at scale.
Explore serverless platform engineering through a lens of architectural blueprints: a structured approach that promotes consistency while empowering teams to focus on core business value. Discover what constitutes a practical serverless blueprint, both technically and culturally, and how Agentic AI assistants are revolutionizing platform operations. See how CyberArk reduced new service creation time to production from 5 months to 3 hours.
Don’t forget to favorite session number CSN361!
What is Platform Engineering
Platform engineering is a discipline that helps to streamline software development and deployment practices in large organizations. It accelerates business application delivery by offloading the design of non-business-domain-specific (but still critical) tasks to a dedicated team of experts - the platform engineering team. These are tasks such as account and infrastructure management, observability, compliance, security, governance, maintenance of CI/CD pipelines, tenant isolation, workflow automation, and more.
Without platform engineering, each team building their applications in the cloud would need to solve all of these challenges independently, leading to effort duplication and architectural inconsistencies. This might be OK for a small company, but it quickly becomes unsustainable in a large organization with dozens of teams building hundreds of applications.
Platform engineering practices help to abstract the non-business-domain complexity, allowing application development teams to focus on building applications and delivering business value while enabling teams to have a high degree of flexibility when designing cloud architectures. This results in a faster development cycle, improved reliability, and reduced cognitive load on developers. Ultimately, platform engineering enhances software delivery, leading to better customer experiences and a more competitive edge in the market.
Platform engineering in the Kubernetes world
Today, platform Engineering is commonly synonymous with Kubernetes. Platform engineering blogs, webcasts, and thought leadership articles commonly share experience building developer platforms on Kubernetes.
There’s a good reason for this. Kubernetes is a powerhouse of a product to run your containerized workloads, but it comes with added operational complexity. AWS Services like EKS simplify the infrastructure and control management part, but a steep Kubernetes adoption learning curve still requires learning Kubernetes-specific concepts like deployments, services, horizontal auto-scaling, custom resource definitions, and controllers. None of this is related to business applications. In other words, when using Kubernetes at scale, it is not a platform to build applications, but a platform to build platforms.
In a large organization with thousands of engineers, you do not want to require that everyone has to become a Kubernetes expert. You want to allow your developers to do their best—develop and deliver business value. You want to abstract the complexity of Kubernetes away, and the most common way of doing that is introducing Platform Engineering practices.
What do platform engineers actually do?
Just like software engineers build software, platform engineers build platforms. But what is a platform? And the answer is - it depends. Depends on the requirements, skills, and maturity of both platform engineering and application development teams they cater to. To better understand what platform engineers do, let’s try to explore what kind of artifacts they deliver.
The mission of a platform engineer is to accelerate application development teams by abstracting the non-business-domain complexity. Let’s take a high-level look at a modern application stack.
Starting bottoms up, the platform team streamlines cloud provider account management. They define best practices for provisioning infrastructure and codify them with IaC tools such as Terraform or CDK. They implement governance practices using tools such as Checkov or cdk-nag to ensure cloud resources are not violating any policies even before they’re being deployed to the cloud. They use AWS tools like Control Tower and Service Control Policies to monitor for existing resources that do violate policies. The platform team provisions infrastructure, including compute, storage, and networking layers. For compute specifically, they can provision and manage Kubernetes clusters and set up CI/CD pipelines for application developers. To streamline organizational standards at the application layer, they can create architectural blueprints in form of Helm charts or Crossplane compositions. To maintain blueprints and share them with application development teams, it is common for platform engineers to bootstrap developer portals, using products like Backstage, CNOE, or StackSpot. Application developers use these portals via a self-service interface, and the best part is they can commonly contribute to platform components via code contributions.
Imagine each application development team figuring out this whole stack by themselves. This would be incredibly inefficient and introduce lots of duplications and inconsistencies. With platform engineering, developers can focus on the top layer, while also having flexibility to make changes to lower layers if required via social coding practices.
To put it simply - can application developers examine IaC blueprints or Helm charts and make changes? Yes, they can. Do they have to become IaC and Kubernetes experts in order to build a new microservice? No, they don’t.
The Case For Serverless Platform Engineering Teams
So… What’s different about serverless, you might ask? Well, the thing is - not much! The serverless promise is you can run your applications with no infrastructure management efforts. This is true, if you’re building serverless applications, you’re using a collection of managed services that provide functionality via APIs. Sounds vaguely familiar? Because it is. This is very similar to what the Platform Engineering team does - abstracting the infrastructure complexity with simple self-service constructs. But does it mean you don’t need any platform engineering practices in the serverless world? Not at all. If you look at the layered diagram in the previous section, every single layer of it exists in a serverless world. The teams using serverless encounter very similar challenges, however solution specifics are a bit different.
In the serverless world, you have Lambda functions, EventBridge rules, and other serverless resources. Are they infrastructure resources? Depends who you talk to. Technically, the answer is yes, they are - you manage them via IaC tools. But if you ask application developers, they commonly consider these infrastructure resources to be an integral part of their applications, and they want the flexibility to make frequent resource updates without having to open a ticket for a separate platform team.
Although Serverless follows a completely different architecture, teams using it often encounter similar challenges—they just solve them in a different way.
Let’s discuss some of the challenges teams face in the Serverless domain and their solutions.
Standardizing Infrastructure and Application Configurations
In a serverless world, engineering teams build their solutions using various AWS services (Lambda, DynamoDB, API Gateway, etc.). Every team trying to figure it out alone usually leads to inconsistencies and organizational scaling challenges. Platform engineering can help by creating reusable patterns/blueprints for both infrastructure and application layers, including CI/CD, etc.
One example is to codify architectural patterns into CDK constructs or Terraform templates so they can be reused across R&D teams. These patterns encapsulate security, FinOps, and general Serverless best practices and knowledge. Developers can reuse these patterns in their services and save precious development time.
The best part is that the platform engineering team versioned and maintained these patterns as inner open source, allowing for swift updates.
If you would like to learn more about this pattern, read the AWS.com article “How CyberArk is streamlining serverless governance by codifying architectural blueprints.”
Enforcing Security and Compliance at Scale
Any enterprise-grade cloud application, serverless, not being an exception, must adhere to strict security best practices (such as least privilege IAM, encryption, etc.). Platform engineering can automate governance and policy enforcement using tools like AWS SCPs, Firewall Manager and WAF, cdk-nag, and AWS Service Catalog.
To learn more about serverless governance and governance using the AWS Service Catalog, check out the article “Serverless Governance of Software Deployed with AWS Service Catalog.”
Firewall Manager and Web Application Firewall are tools that platform engineering can leverage to define organization-wide WAF security ACL rules policies. Firewall manager provides visibility into teams’ adoption of your security policies, which helps maintain governance.
Learn more about these services in the blog post “Simplify Security, Governance, and WAF Management with AWS Firewall Manager.”
Managing Observability Across Distributed Services
Serverless applications are inherently distributed, making observability (logs, traces, and metrics) complex. A platform team can provide logging standards, tracing standards, automated instrumentation, alerts, and dashboards for enhanced visibility.
Platform teams can do more than define the tools and best practices for observability; they can also develop internal SDKs for other teams to leverage. Tools include a logger that writes JSON-formatted logs to CloudWatch, a Tracer that leverages AWS X-Ray, and a custom CloudWatch metrics utility that uses EMF-formatted logs to publish metrics.
In other words, platform teams can integrate industry-standard libraries such as Powertools for AWS Lambda into their internal SDK and automate their usage in GitHub template repositories for teams to use.
The AWS Lambda Handler Cookbook (Python) is an open-source GitHub template for a Serverless service that leverages Powertools for AWS Lambda and includes Cloudwatch. It is a prime example of how platform engineering can help the organization solve and automate the observability challenges in the Serverless domain.
Improving Developer Experience and Productivity
Developers need fast feedback loops, local testing, and efficient deployments. Platform teams can offer self-service deployment pipelines, [local] testing environments, and pre-baked managed CI/CD workflows. This is true for either K8s or Serverless. Developers want to start working as quickly as possible on a new project.
An interesting Serverless aws.com case study that was recently published describes how the platform engineering team at CyberArk was able to reduce the time to production for every new Serverless service by 18 weeks by leveraging Serverless automation.
We highly recommend that you check out the “Awesome AWS Serverless Blueprints” GitHub repository—it’s a compilation of many community-backed GitHub templates and Serverless services blueprints that you can either use as is or use as inspiration to create your own automation.
Cost Optimization
While serverless services usually have a pay-per-use model, uncontrolled usage can lead to unexpected costs. To optimize cloud cost, platform engineering can introduce cost monitoring tools, auto-scaling best practices, and automated budget alerts as part of the observability.
For example, teams often configure Lambda function provisioned concurrency to mitigate cold starts. Platform engineering teams can optimize this Lambda configuration and provide a CDK construct that defines dynamic provisioned concurrency—a pattern that changes can increase or decrease the number of pre-warmed functions based on current traffic, thus reducing the overall cost and optimizing the usage.
If you’d like to learn more about this pattern, check out the article “Optimize AWS Lambda with Dynamic Provisioned Concurrency.”
Conclusion
The need for platform engineering extends beyond Kubernetes. By addressing infrastructure, observability, security, DevEx, and cost management, organizations can enable scalable and efficient serverless adoption on AWS.