# The aws-samples serverless pattern library is a directory listing as a catalogue > aws-samples/serverless-patterns collects small infrastructure-as-code examples showing how one AWS service integrates with another, each in its own subdirectory with its own instructions and maintained by the AWS Serverless Developer Advocacy team. It is a reference shelf, not a library, and deploying anything in it can cost money. **aws-samples/serverless-patterns** — Serverless patterns. Learn more at the website: https://serverlessland.com/patterns. - Repository: https://github.com/aws-samples/serverless-patterns - Website: https://serverlessland.com - Stars: 1,832 · Forks: 1,057 - Language: Python - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/aws-samples-serverless-patterns ## Each folder is one integration, and each folder stands alone The repository is a catalogue of serverless integration examples written as infrastructure as code. The README describes the intent plainly: patterns showing how to integrate services using IaC, to help you develop your own projects quickly. The organisation is one directory per pattern, named for what it connects. The top level shows the shape of the collection immediately: `alb-lambda-cdk/`, `alb-lambda-terraform/`, `alb-lambda-serverless/`, `alb-lambda-rust/`, `alb-lambda-pulumi-cs/`, `alb-lambda-pulumi-go/`, `alb-lambda-pulumi-js/`, `alb-lambda-pulumi-ts/`, `alb-lambda-pulumi-yaml/`, `alb-path-based-route-lambda-cdk/`, `alb-path-based-route-lambda-tf/`. Further along the same axis sit `api-gateway-cors-whitelist-cdk/`, `api-gateway-cors-proxy/`, `apigw-caching-sam/`, `apigw-canary-deployment-cdk/`, `apigw-canary-deployment-cdk-java/`, `apigw-data-validation/`, `apigw-data-validation-tf/` and `apigw-client-certificate/`. Two things follow immediately from that naming. First, the same integration appears in several forms, including CDK, Terraform, SAM, Pulumi variants and a serverless variant. If your team standardises on one IaC tool, the choice is already made for you by which folder you open. Second, Java appears as a first-class citizen in a repository whose primary language is Python, visible in entries such as `activemq-lambda-sam-java/` and `alb-ecs-java-sam/`. Messaging and queues form the other dense cluster: `activemq-lambda/`, `activemq-private-lambda-java-sam/`, `amazonmq-rabbitmq-msg-replication/`, `api-sqs-lambda-python/`, `APIGateway-SQS-ReceiveMessages/`. Amazon MQ and RabbitMQ replication next to API Gateway to SQS to Lambda shows the intent: the interesting parts are the joins between services, not the services themselves. ## Getting one pattern running takes a clone and the SAM CLI The deployment instructions are short because the per-pattern instructions live inside each subdirectory, which the README states explicitly. The global steps are account setup, tooling, and a clone. You need an AWS account, Git, and the AWS Serverless Application Model CLI installed locally. Then clone the repository: ```bash git clone https://github.com/aws-samples/serverless-patterns ``` and open the directory for the pattern you want, where its own installation and usage instructions are. What is notable is the tooling asymmetry. The SAM CLI is the single named prerequisite for the whole repository, yet the pattern folders span CDK, Terraform and Pulumi. The README does not install or describe any of those three, which means a CDK-based pattern such as `alb-lambda-cdk/` carries its own tool requirements that a reader only discovers by opening that folder. Treat the top-level instructions as the common denominator, not a complete environment. There is also an `_pattern-model/` directory and a `_scripts/` directory at the top level, which suggests some structure is captured as data and validated by scripts. That is an inference from the names: the contents of those directories are not described in the README. ## Deploying a pattern costs money, and the README says so before anything else The third paragraph of the README is a cost warning rather than a feature list. It notes that the application uses various AWS services, that costs apply after Free Tier usage, points at the AWS pricing page, states that you are responsible for any AWS costs incurred, and adds that no warranty is implied in the example. That is worth taking literally rather than as boilerplate. A pattern is a set of live AWS resources, not a library you import. The README warns that deployed patterns may incur charges for the AWS services they use after Free Tier usage. Two categories in the listing carry extra exposure. `ami-recycle-bin/` schedules automation around machine images, which is recurring work rather than a one-off stack. And the Bedrock and Nova entries, `apigw-bedrock-cognito-cdk/`, `apigw-bedrock-nova-canvas/`, `apigw-cors-nonproxy/`, imply a request path through a model endpoint, which bills per invocation. The repository does not provide a teardown script at the top level, and the README does not mention cost estimation or teardown. Cleaning up after experimenting is on you. ## A single tag release in 2024, against a repository pushed yesterday Maintenance here is continuous at the repository level and effectively absent at the release level, and the two need to be read separately. The repository is not archived and the last push was on 2026-10-15. Ownership is stated in the README: the project is owned, managed and maintained by the AWS Serverless Developer Advocacy team. The publishing guidelines live in `PUBLISHING.md`, and there are governance files for contributions, conduct, and contribution mechanics, plus `AGENTS.md` and `CLAUDE.md` at the top level, which read as instructions for coding agents working in the repository rather than for human contributors. The release history is one entry: v1.0.0, tagged on 2024-08-19. That does not mean nothing has changed since, because for a catalogue repository the work is new directories and edits rather than versioned artefacts. It does mean you cannot use tags to tell which patterns are new or whether a pattern was updated for a service change. There is no per-pattern changelog described. If a pattern looks stale, the only check the README supports is opening its directory and reading what is there. ## Licensing is MIT-0 in the source header, with a LICENSE file GitHub cannot classify The README carries a copyright line for 2025 Amazon.com, Inc. or its affiliates, all rights reserved, followed by the SPDX identifier MIT-0. That identifier means the licence text is effectively waived: no attribution is required when you reuse the code. The repository metadata classifies the licence as other, custom, pointing at the LICENSE file, which is a common outcome when a licence has an SPDX identifier in the header but a different or longer text in the file. This article has not opened that file, so treat the classification as unresolved rather than contradictory. For an MIT-0 codebase the practical answer is almost certainly that reuse is unrestricted, but the authoritative statement is the LICENSE file, and if a compliance process needs certainty, that file is what to read. There is a third-party dimension for anyone copying code out of a pattern rather than deploying it: the patterns reference AWS services and each carries its own service dependencies, whose own terms apply to anything you run. ## Where the catalogue stops and the AWS reference material begins The realistic alternative is not another GitHub repository. It is the AWS documentation itself, plus Serverless Land, the site the README links for the pattern catalogue at serverlessland.com/patterns. The difference in approach is editorial. A pattern here is a complete, opinionated deployment of one integration with working IaC, which is faster to copy than to write and shows the wiring end to end. AWS documentation is normative: it tells you what a service guarantees and how to configure it correctly, without committing to one IaC tool or one topology. The other comparison is the CDK and Terraform constructs in your own organisation. If your team already has a curated set of internal patterns with your naming conventions, logging, alarms and tagging baked in, this catalogue is a source of ideas rather than something to adopt, and copying an example wholesale tends to import whatever defaults the example author chose. What makes the collection worth browsing regardless is its breadth of combinations. Seeing `amazonmq-rabbitmq-msg-replication/` next to `api-sqs-lambda-python/` next to the Bedrock patterns is a cheap way to notice an integration you did not know you needed, and then to go read the service documentation about it. ## Conclusion Use this repository when you need a working reference for one integration, such as putting a Lambda behind an Application Load Balancer, and want to see the IaC rather than read a diagram. Do not adopt it as a framework, a dependency or a deployment pipeline, because nothing here is packaged that way and every folder is a standalone example you own once deployed. Verify first that the specific pattern you want still matches current service behaviour, that your AWS account and region are configured for the services it touches, and what the running cost looks like after Free Tier, since the README puts that responsibility on you. ## FAQ ### How do I deploy a pattern from aws-samples/serverless-patterns? Create an AWS account, install Git and the AWS Serverless Application Model CLI, clone the repository with `git clone https://github.com/aws-samples/serverless-patterns`, then open the pattern's own subdirectory, which the README says contains its installation and usage instructions. ### Do the AWS serverless patterns cost money to deploy? They can. The README states the patterns use various AWS services, that costs apply after Free Tier usage, and that you are responsible for any AWS costs incurred, with no warranty implied. ### Can I use a pattern written in Terraform or Pulumi instead of SAM? Yes. The repository contains folders per integration and per tool, for example alb-lambda-cdk/, alb-lambda-terraform/, alb-lambda-pulumi-go/ and alb-lambda-pulumi-ts/. The README names only the SAM CLI as a global prerequisite, so extra tools are per pattern. ### What license does aws-samples/serverless-patterns use? The README footer carries an MIT-0 SPDX-License-Identifier with a 2025 Amazon.com, Inc. copyright line. The repository metadata classifies the licence as other and points at the LICENSE file, so read that file if you need certainty. ### Who maintains the aws-samples/serverless-patterns repository? The README states the project is owned, managed and maintained by the AWS Serverless Developer Advocacy team. Submission rules for new patterns are in PUBLISHING.md. ### How can I contribute a new serverless pattern? The README points to the publishing guidelines page in PUBLISHING.md for how to submit a pattern, and the repository also holds CONTRIBUTING.md and CODE_OF_CONDUCT.md. ## Sources - [aws-samples/serverless-patterns on GitHub](https://github.com/aws-samples/serverless-patterns) - [Issues](https://github.com/aws-samples/serverless-patterns/issues) - [Project website](https://serverlessland.com) - [README](https://github.com/aws-samples/serverless-patterns/blob/main/README.md) - [Releases](https://github.com/aws-samples/serverless-patterns/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-samples-serverless-patterns