{"id":168,"date":"2026-04-13T01:39:01","date_gmt":"2026-04-13T01:39:01","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-serverless-application-repository-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-13T01:39:01","modified_gmt":"2026-04-13T01:39:01","slug":"aws-serverless-application-repository-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-serverless-application-repository-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"AWS Serverless Application Repository Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>AWS Serverless Application Repository is an AWS service that lets you <strong>discover, deploy, publish, and share serverless applications<\/strong> that are packaged as <strong>AWS Serverless Application Model (AWS SAM)<\/strong> or <strong>AWS CloudFormation<\/strong> templates.<\/p>\n\n\n\n<p>In simple terms: it\u2019s an <strong>app catalog for serverless<\/strong>, where an \u201capplication\u201d is a deployable template that can create AWS resources such as <strong>AWS Lambda functions, IAM roles, Amazon API Gateway APIs, Amazon DynamoDB tables, Amazon EventBridge rules<\/strong>, and more.<\/p>\n\n\n\n<p>Technically, AWS Serverless Application Repository (often abbreviated \u201cSAR\u201d) stores <strong>application metadata and versions<\/strong>, and it uses <strong>AWS CloudFormation<\/strong> to deploy those applications into your AWS account as <strong>stacks<\/strong>. You can publish applications for your own account (private), share them with specific accounts or organizations, or publish publicly (subject to AWS requirements).<\/p>\n\n\n\n<p>The core problem it solves is <strong>reusable serverless delivery<\/strong>: instead of copy\/pasting templates and code across repos and accounts, teams can treat serverless components as <strong>versioned, deployable products<\/strong> with controlled sharing and repeatable deployments.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming: <strong>AWS Serverless Application Repository<\/strong> is the current and active service name. It is commonly accessed from the AWS Console and integrates tightly with AWS CloudFormation and AWS SAM. Always verify the latest behavior and region availability in the official docs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Serverless Application Repository?<\/h2>\n\n\n\n<p><strong>Official purpose (what it is for)<\/strong><br\/>\nAWS Serverless Application Repository is a managed repository where you can <strong>store and share serverless applications<\/strong>. Consumers can <strong>deploy<\/strong> these applications into their accounts using CloudFormation, and publishers can <strong>version<\/strong> and <strong>control access<\/strong> to their applications.<\/p>\n\n\n\n<p><strong>Core capabilities<\/strong>\n&#8211; <strong>Discover applications<\/strong> (including public applications) and view descriptions, parameters, permissions, and version history.\n&#8211; <strong>Deploy applications<\/strong> into your AWS account via <strong>CloudFormation<\/strong>.\n&#8211; <strong>Publish applications<\/strong> (private or public) with <strong>semantic versions<\/strong>.\n&#8211; <strong>Share applications<\/strong> across AWS accounts using <strong>resource-based policies<\/strong>.\n&#8211; <strong>Integrate with AWS SAM<\/strong> authoring workflows and CI\/CD.<\/p>\n\n\n\n<p><strong>Major components<\/strong>\n&#8211; <strong>Application<\/strong>: The top-level artifact (name, description, author, labels, home page\/source links if provided).\n&#8211; <strong>Application version<\/strong>: A specific, immutable release (commonly semantic versioning like <code>1.2.3<\/code>).\n&#8211; <strong>Template<\/strong>: The AWS SAM or CloudFormation template that defines the resources.\n&#8211; <strong>Application policy<\/strong>: A resource-based policy that determines who can deploy the application.\n&#8211; <strong>CloudFormation stack<\/strong>: The deployed instance of an application in a consumer account\/region.<\/p>\n\n\n\n<p><strong>Service type<\/strong>\n&#8211; Primarily a <strong>management-plane service<\/strong> (catalog + versioning + deployment entry point).\n&#8211; Deployments are executed through <strong>AWS CloudFormation<\/strong> (which then provisions runtime resources).<\/p>\n\n\n\n<p><strong>Scope (regional\/global\/account-scoped)<\/strong>\n&#8211; <strong>Regional<\/strong>: Applications and deployments are tied to an AWS Region. If you need the \u201csame\u201d application in multiple regions, you typically publish\/manage it per region. (Verify region behavior in official docs for your specific use case.)\n&#8211; <strong>Account-scoped<\/strong> for private applications.\n&#8211; <strong>Public applications<\/strong> are discoverable by many users, but deployment still happens in a specific region.<\/p>\n\n\n\n<p><strong>How it fits into the AWS ecosystem<\/strong>\n&#8211; Works alongside <strong>AWS SAM<\/strong> (authoring and packaging), <strong>AWS CloudFormation<\/strong> (deployment), <strong>AWS Lambda<\/strong> (compute), and supporting services like <strong>Amazon CloudWatch<\/strong> (logs\/metrics) and <strong>AWS CloudTrail<\/strong> (audit).\n&#8211; Complements infrastructure-as-code approaches (CloudFormation\/SAM) by adding <strong>discovery, sharing, and versioning<\/strong> specifically for serverless apps.<\/p>\n\n\n\n<p>Official docs entry point:<br\/>\nhttps:\/\/docs.aws.amazon.com\/serverless-application-repository\/latest\/devguide\/what-is-serverlessrepo.html<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Serverless Application Repository?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster time-to-value<\/strong>: deploy proven building blocks (e.g., log processors, alarms, webhooks) rather than rewriting them.<\/li>\n<li><strong>Standardization<\/strong>: platform teams can provide \u201capproved\u201d serverless applications that product teams deploy consistently.<\/li>\n<li><strong>Reuse and governance<\/strong>: reduces duplicated engineering effort and promotes consistent controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Versioned templates<\/strong>: treat serverless solutions like software releases with semantic versions.<\/li>\n<li><strong>Repeatable deployments<\/strong>: CloudFormation ensures consistent provisioning and rollback.<\/li>\n<li><strong>Parameterization<\/strong>: consumers can deploy the same app with different parameters per environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Operational consistency<\/strong>: standard logging, alarms, IAM roles, and tagging can be embedded into published applications.<\/li>\n<li><strong>Change control<\/strong>: update patterns can follow CloudFormation stack update practices; rollbacks are supported by CloudFormation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security and compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Controlled sharing<\/strong>: publish privately; share only to specific accounts or AWS Organizations.<\/li>\n<li><strong>Auditability<\/strong>: deployments and policy changes can be tracked with <strong>CloudTrail<\/strong>.<\/li>\n<li><strong>Template review<\/strong>: security teams can review IaC templates and enforce guardrails before allowing consumption.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability and performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SAR itself doesn\u2019t \u201cscale\u201d your runtime; it scales the <strong>distribution<\/strong> and deployment of serverless patterns. Runtime scaling is handled by services deployed (e.g., Lambda concurrency, DynamoDB capacity modes).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need an internal catalog of reusable serverless applications.<\/li>\n<li>You want to share serverless components across many AWS accounts\/environments.<\/li>\n<li>You want to provide a \u201cgolden path\u201d for serverless implementations using SAM\/CloudFormation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You require <strong>non-CloudFormation<\/strong> deployment tooling only (e.g., strictly Terraform-only workflows) and can\u2019t introduce CloudFormation\/SAM.<\/li>\n<li>You need a full \u201cservice catalog with approvals, budgets, and portfolio management.\u201d (Consider <strong>AWS Service Catalog<\/strong> for broader catalog governance; SAR is specialized for serverless applications.)<\/li>\n<li>Your artifacts are not naturally represented as SAM\/CloudFormation templates (e.g., pure container platforms without serverless\/IaC templates).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Serverless Application Repository used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and software companies: reusable event-driven components, webhook handlers, tenant automation.<\/li>\n<li>Finance and regulated industries: standardized logging\/alerting apps deployed consistently across accounts.<\/li>\n<li>Media\/streaming: serverless ingest and processing components.<\/li>\n<li>Retail\/e-commerce: event-driven pipelines for orders, inventory, notifications.<\/li>\n<li>Healthcare: controlled sharing of compliant serverless patterns (with careful security review).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building internal \u201cserverless building blocks\u201d<\/li>\n<li>DevOps\/SRE teams packaging operations automations (e.g., scheduled checks, alert routers)<\/li>\n<li>Security engineering teams distributing security baselines (e.g., log forwarding)<\/li>\n<li>Application teams consuming approved components<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Event-driven processing<\/li>\n<li>Scheduled automation jobs<\/li>\n<li>API backends<\/li>\n<li>Log processing and alerting<\/li>\n<li>Data movement and transformation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-account AWS Organizations setups with shared internal apps<\/li>\n<li>Microservices architectures (serverless microservices as shareable modules)<\/li>\n<li>Central platform templates consumed by many teams<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: deploy vetted, versioned apps with strict sharing policies and change control.<\/li>\n<li><strong>Dev\/test<\/strong>: quickly deploy reference apps (including public ones) to prototype patterns.<\/li>\n<li><strong>Sandbox<\/strong>: evaluate public apps safely before internal adoption.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Serverless Application Repository is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Internal \u201cApproved Serverless Apps\u201d Catalog<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams build similar Lambda\/API patterns repeatedly with inconsistent IAM and logging.<\/li>\n<li><strong>Why SAR fits<\/strong>: Central team publishes vetted apps; consumers deploy consistent versions.<\/li>\n<li><strong>Example<\/strong>: Platform team publishes <code>org-standard-api-lambda<\/code> with standard IAM, logging, and alarms.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Cross-Account Shared Automation (Ops\/SRE)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Ops automation (e.g., scheduled checks) is duplicated across accounts.<\/li>\n<li><strong>Why SAR fits<\/strong>: Share one versioned app to many accounts via application policy.<\/li>\n<li><strong>Example<\/strong>: A scheduled Lambda that checks certificate expiry is deployed to every workload account.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Standardized Observability Add-ons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Not all apps ship logs\/metrics consistently.<\/li>\n<li><strong>Why SAR fits<\/strong>: Publish an observability \u201csidecar app\u201d (log subscription filters, alarms).<\/li>\n<li><strong>Example<\/strong>: Deploy an app that creates CloudWatch metric filters and alarms for error patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Security Baseline Components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security wants consistent controls (e.g., alert routing, audit log forwarding).<\/li>\n<li><strong>Why SAR fits<\/strong>: Publish security components and share with AWS Organizations accounts.<\/li>\n<li><strong>Example<\/strong>: Deploy a Lambda that forwards specific security findings to a central system.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Reusable EventBridge-to-Lambda Patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many teams need the same event routing patterns.<\/li>\n<li><strong>Why SAR fits<\/strong>: A published app can define EventBridge rules and targets consistently.<\/li>\n<li><strong>Example<\/strong>: Standard rule + DLQ + retry configuration for event-driven processing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Reference Implementations for New Projects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: New teams need a known-good starting point.<\/li>\n<li><strong>Why SAR fits<\/strong>: A reference app is discoverable and deployable in minutes.<\/li>\n<li><strong>Example<\/strong>: A \u201cHello serverless with structured logging\u201d app used during onboarding.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Multi-Environment Deployments with Parameters<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Dev\/stage\/prod need the same app but different settings.<\/li>\n<li><strong>Why SAR fits<\/strong>: Parameterized templates allow consistent deployments per environment.<\/li>\n<li><strong>Example<\/strong>: Deploy the same notification app with different SNS topics per environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Controlled Rollout of Shared Components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Updating a shared library across many apps is painful.<\/li>\n<li><strong>Why SAR fits<\/strong>: Consumers choose when to update to a newer application version.<\/li>\n<li><strong>Example<\/strong>: A shared webhook handler is updated from <code>1.1.0<\/code> to <code>1.2.0<\/code> across accounts in phases.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Publishing Public Serverless Solutions (If You\u2019re a Vendor\/ISV)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want customers to deploy your serverless solution easily.<\/li>\n<li><strong>Why SAR fits<\/strong>: Public SAR apps provide a simple AWS-native deployment path.<\/li>\n<li><strong>Example<\/strong>: A vendor publishes an integration app that deploys Lambda + API Gateway + DynamoDB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Rapid Prototyping from Public Catalog<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want to test a pattern quickly without writing IaC.<\/li>\n<li><strong>Why SAR fits<\/strong>: Public apps can be deployed as CloudFormation stacks for experimentation.<\/li>\n<li><strong>Example<\/strong>: Deploy a public app into a sandbox, validate behavior, then replicate internally.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Organization-Wide \u201cCompliance Pack\u201d for Serverless<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Compliance requires consistent tagging, retention, encryption defaults.<\/li>\n<li><strong>Why SAR fits<\/strong>: Embed tagging and defaults into a published serverless app template.<\/li>\n<li><strong>Example<\/strong>: App provisions Lambda + log groups with retention and KMS settings (where supported).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Consistent CI\/CD Baseline for Serverless<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Each team builds pipelines differently.<\/li>\n<li><strong>Why SAR fits<\/strong>: Publish pipeline components as deployable apps (where expressed as CloudFormation\/SAM).<\/li>\n<li><strong>Example<\/strong>: A \u201cserverless CI helper\u201d app provisions shared roles and a CodeBuild project for SAM builds.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 1: Application discovery and catalog experience<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you browse available serverless applications (private, shared, and public).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces time spent searching for internal templates and tribal knowledge.<\/li>\n<li><strong>Practical benefit<\/strong>: Teams can quickly identify vetted building blocks.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Public catalog items still require careful security review before deployment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 2: One-click (or guided) deployment via CloudFormation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Deploys an app as a CloudFormation stack, with parameter inputs.<\/li>\n<li><strong>Why it matters<\/strong>: Standardizes deployment and rollback behavior.<\/li>\n<li><strong>Practical benefit<\/strong>: Easy deployment without cloning repos.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: CloudFormation stack failures require typical troubleshooting (events, IAM, resource conflicts).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 3: Versioning (semantic versions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Publishers release versions; consumers can select which version to deploy.<\/li>\n<li><strong>Why it matters<\/strong>: Enables controlled change management and rollback to known-good versions.<\/li>\n<li><strong>Practical benefit<\/strong>: Safer upgrades across many accounts\/environments.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Consumers must update stacks intentionally; older versions remain deployed until updated.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 4: Private, shared, and public publishing models<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Publish apps for yourself, share to other AWS accounts, or publish publicly.<\/li>\n<li><strong>Why it matters<\/strong>: Supports both internal platform catalogs and public distribution.<\/li>\n<li><strong>Practical benefit<\/strong>: Secure sharing patterns without copying templates around.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Public publishing may require additional metadata and compliance steps (verify requirements in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 5: Resource-based application policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls which principals (accounts\/orgs) can deploy an application.<\/li>\n<li><strong>Why it matters<\/strong>: Central governance for distribution.<\/li>\n<li><strong>Practical benefit<\/strong>: Prevents accidental deployment by unauthorized accounts.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: This is not a full governance suite; combine with AWS Organizations SCPs and IAM controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 6: Integration with AWS SAM authoring workflows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with SAM templates; many teams use SAM CLI to build\/package apps for publishing.<\/li>\n<li><strong>Why it matters<\/strong>: Aligns with serverless best practices and simplified IaC.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster authoring and consistent packaging.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: SAM CLI versions and commands evolve; verify with official SAM CLI docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 7: Metadata (descriptions, labels, links)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets publishers add descriptive metadata for discoverability.<\/li>\n<li><strong>Why it matters<\/strong>: Consumers can evaluate apps faster.<\/li>\n<li><strong>Practical benefit<\/strong>: Better internal documentation and onboarding.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Metadata quality depends on publisher discipline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 8: CloudTrail auditability for management-plane actions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: SAR and CloudFormation actions can be logged in CloudTrail.<\/li>\n<li><strong>Why it matters<\/strong>: Security and compliance teams need traceability of deployments and policy changes.<\/li>\n<li><strong>Practical benefit<\/strong>: Supports investigations and change tracking.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Ensure CloudTrail is configured for the relevant regions and events.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 9: Parameterized deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Templates can expose parameters; deployers provide values at deploy time.<\/li>\n<li><strong>Why it matters<\/strong>: One app version supports multiple environments.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduced duplication of templates.<\/li>\n<li><strong>Limitations\/caveats<\/strong>: Parameter sprawl can reduce clarity; keep interfaces small and well-documented.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Feature 10: CloudFormation lifecycle support (updates\/rollbacks\/deletes)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Once deployed, the app behaves like a CloudFormation stack.<\/li>\n<li><strong>Why it matters<\/strong>: Standard AWS operational model.<\/li>\n<li><strong>Practical benefit<\/strong>: Use CloudFormation change sets, drift detection, stack policies (where applicable).<\/li>\n<li><strong>Limitations\/caveats<\/strong>: If consumers manually edit resources, drift can occur.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Publishers<\/strong> create an application version with a SAM\/CloudFormation template and metadata.<\/li>\n<li><strong>Consumers<\/strong> browse or search for an application in AWS Serverless Application Repository.<\/li>\n<li>When a consumer clicks <strong>Deploy<\/strong>, SAR triggers <strong>AWS CloudFormation<\/strong> to create a <strong>stack<\/strong> in the consumer account\/region.<\/li>\n<li>CloudFormation provisions the resources defined in the template (Lambda functions, IAM roles, etc.).<\/li>\n<li>Logs\/metrics are emitted by runtime resources to <strong>CloudWatch<\/strong>; management actions are logged in <strong>CloudTrail<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow vs data flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: SAR \u2192 CloudFormation \u2192 provisioning of AWS resources.<\/li>\n<li><strong>Data plane<\/strong>: runtime service interactions (e.g., Lambda invoked by events, writing logs to CloudWatch).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related AWS services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CloudFormation<\/strong>: primary deployment engine<\/li>\n<li><strong>AWS SAM<\/strong>: common authoring model and transform<\/li>\n<li><strong>AWS IAM<\/strong>: roles\/policies created by stacks; SAR sharing uses resource policies<\/li>\n<li><strong>AWS Lambda<\/strong>: typical compute target for serverless applications<\/li>\n<li><strong>Amazon CloudWatch<\/strong>: logs\/metrics\/alarms for deployed apps<\/li>\n<li><strong>AWS CloudTrail<\/strong>: auditing repository and deployment actions<\/li>\n<li>Optional integrations in templates: API Gateway, EventBridge, DynamoDB, SQS, SNS, KMS, Secrets Manager, etc.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>SAR itself doesn\u2019t run your code. Your application template defines dependencies. Most serverless apps depend on:\n&#8211; IAM for execution roles\n&#8211; CloudWatch Logs\n&#8211; Lambda (and an event source such as API Gateway or EventBridge)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM permissions<\/strong> control who can publish, manage, and deploy from SAR.<\/li>\n<li><strong>Application policies<\/strong> (resource-based) control who can deploy a specific application.<\/li>\n<li><strong>CloudFormation permissions<\/strong> and capabilities (e.g., acknowledging IAM resource creation) govern stack creation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SAR is a management-plane service; deployments happen via CloudFormation within a region.<\/li>\n<li>Deployed resources may be public or private depending on template:<\/li>\n<li>Lambda can be in a VPC if configured.<\/li>\n<li>API Gateway endpoints can be public.<\/li>\n<li>VPC endpoints and private connectivity are template-driven.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>CloudTrail<\/strong> to log:<\/li>\n<li>Application creation\/versioning<\/li>\n<li>Policy updates<\/li>\n<li>Deployment actions (CloudFormation events also appear in CloudTrail)<\/li>\n<li>Use <strong>CloudFormation stack events<\/strong> for deployment diagnostics.<\/li>\n<li>Use <strong>CloudWatch Logs<\/strong> and metrics for runtime monitoring.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Publisher\/Developer] --&gt;|Publish App Version| SAR[AWS Serverless Application Repository]\n  User[Consumer\/Deployer] --&gt;|Select + Deploy| SAR\n  SAR --&gt;|Create\/Update Stack| CFN[AWS CloudFormation]\n  CFN --&gt;|Provision| Lambda[AWS Lambda]\n  Lambda --&gt; Logs[Amazon CloudWatch Logs]\n  CFN --&gt; IAM[AWS IAM Roles\/Policies]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph PublisherAccount[Publisher Account]\n    Repo[Source Repo]\n    CI[CI\/CD Pipeline\\n(CodeBuild\/GitHub Actions\/etc.)]\n    SAR[AWS Serverless Application Repository\\n(App + Versions)]\n    Repo --&gt; CI\n    CI --&gt;|Build\/Package| CI\n    CI --&gt;|Publish Version| SAR\n  end\n\n  subgraph ConsumerOrg[Consumer AWS Organization]\n    subgraph SharedServices[Shared Services Account]\n      Sec[Security Review\\nTemplate scanning, policy checks]\n      Trail[Org CloudTrail]\n      Sec --&gt; Trail\n    end\n\n    subgraph WorkloadAccounts[Workload Accounts]\n      CFN1[CloudFormation Stack\\nApp v1.2.3]\n      CFN2[CloudFormation Stack\\nApp v1.2.3]\n      Lambda1[Lambda + IAM + Logs]\n      Lambda2[Lambda + IAM + Logs]\n      CFN1 --&gt; Lambda1\n      CFN2 --&gt; Lambda2\n    end\n  end\n\n  SAR --&gt;|Deploy (per account\/region)| CFN1\n  SAR --&gt;|Deploy (per account\/region)| CFN2\n  WorkloadAccounts --&gt; Trail\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">AWS account and billing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>For organizational sharing scenarios: optional <strong>AWS Organizations<\/strong> setup.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM permissions<\/h3>\n\n\n\n<p>You need permissions for:\n&#8211; AWS Serverless Application Repository actions (publish, manage apps, deploy apps)\n&#8211; AWS CloudFormation stack operations\n&#8211; Any resources created by the application template (e.g., Lambda, IAM, CloudWatch Logs)<\/p>\n\n\n\n<p>Practical guidance:\n&#8211; For hands-on labs, an admin-like role is simplest.\n&#8211; For production, create a least-privilege role for:\n  &#8211; <strong>Publishers<\/strong> (who can create application versions and set policies)\n  &#8211; <strong>Consumers<\/strong> (who can deploy specific applications)<\/p>\n\n\n\n<p>CLI reference (for verifying permissions and APIs):<br\/>\nhttps:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/serverlessrepo\/index.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Console access (recommended for beginners)<\/li>\n<li>Optional: <strong>AWS CLI<\/strong> for validation and invocation<br\/>\n  https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SAR is region-based. Confirm supported regions for your account (including partitions like GovCloud) in the AWS Regional Services list:\n  https:\/\/aws.amazon.com\/about-aws\/global-infrastructure\/regional-product-services\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Relevant quotas come from multiple services:\n&#8211; AWS CloudFormation (stacks, resources per stack)\n&#8211; AWS Lambda (concurrency, code size, etc.)\n&#8211; IAM (roles\/policies)\n&#8211; CloudWatch Logs\n&#8211; SAR-specific quotas (verify in official docs)<\/p>\n\n\n\n<p>Because quotas evolve, <strong>verify current limits<\/strong> in:\n&#8211; Service Quotas console: https:\/\/docs.aws.amazon.com\/servicequotas\/latest\/userguide\/intro.html\n&#8211; SAR developer guide: https:\/\/docs.aws.amazon.com\/serverless-application-repository\/latest\/devguide\/what-is-serverlessrepo.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS CloudFormation<\/strong> (deployment engine)<\/li>\n<li>Commonly <strong>AWS Lambda<\/strong> and <strong>CloudWatch Logs<\/strong> (for most serverless apps)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (accurate high-level)<\/h3>\n\n\n\n<p>AWS Serverless Application Repository generally has <strong>no additional charge<\/strong> for using the repository itself; you pay for the <strong>AWS resources<\/strong> created when you deploy applications (Lambda, API Gateway, DynamoDB, CloudWatch, etc.). Always confirm in the official docs\/pricing pages because pricing models can change.<\/p>\n\n\n\n<p>Key idea: <strong>SAR is a distribution\/deployment mechanism; costs are driven by what you deploy.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what can generate cost)<\/h3>\n\n\n\n<p>Costs depend on the deployed architecture, commonly:\n&#8211; <strong>AWS Lambda<\/strong>\n  &#8211; Requests and duration (GB-seconds)\n  &#8211; Provisioned Concurrency (if enabled)\n&#8211; <strong>Amazon CloudWatch<\/strong>\n  &#8211; Log ingestion and retention\n  &#8211; Metrics and alarms\n&#8211; <strong>Amazon API Gateway<\/strong> (if used)\n  &#8211; Requests and data transfer\n&#8211; <strong>Amazon DynamoDB<\/strong> (if used)\n  &#8211; On-demand or provisioned read\/write capacity, storage\n&#8211; <strong>Amazon S3<\/strong> (if used)\n  &#8211; Storage and requests for artifacts or application data\n&#8211; <strong>AWS KMS<\/strong> (if used)\n  &#8211; Key usage requests\n&#8211; <strong>Data transfer<\/strong>\n  &#8211; Inter-AZ\/Region transfer (where applicable)\n  &#8211; Public internet egress<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many underlying services offer free tier usage (e.g., Lambda and CloudWatch have free-tier allocations in many regions\/accounts). Eligibility and amounts vary\u2014<strong>verify on official pricing pages<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers to watch (\u201chidden\u201d or indirect costs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>CloudWatch Logs<\/strong>: verbose logging can become a major cost driver.<\/li>\n<li><strong>API Gateway<\/strong>: high request volume can scale cost quickly.<\/li>\n<li><strong>VPC-enabled Lambda<\/strong>: may create ENI overhead; NAT Gateway usage (if required) can be expensive.<\/li>\n<li><strong>KMS<\/strong>: frequent encrypt\/decrypt calls can add cost.<\/li>\n<li><strong>Cross-region data transfer<\/strong>: if your app integrates across regions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploying an app does not usually transfer large data by itself, but runtime behavior might:<\/li>\n<li>Lambda calling external services over the internet<\/li>\n<li>API responses to clients<\/li>\n<li>Replication or cross-region calls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>short log retention<\/strong> and structured logging (reduce noise).<\/li>\n<li>Avoid NAT Gateways unless necessary; use <strong>VPC endpoints<\/strong> where feasible.<\/li>\n<li>Use DynamoDB <strong>on-demand<\/strong> for spiky workloads (or provisioned + auto scaling for predictable workloads).<\/li>\n<li>Use Lambda memory sized to minimize total cost (duration vs memory tradeoff).<\/li>\n<li>Parameterize logging levels and disable debug logs in production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal SAR-deployed app with:\n&#8211; 1 Lambda function invoked a few times\n&#8211; Basic CloudWatch logs\nwill typically cost very little, often within free-tier ranges for many accounts. Exact costs depend on:\n&#8211; Region\n&#8211; Invocation count and duration\n&#8211; Log volume and retention<br\/>\nUse the <strong>AWS Pricing Calculator<\/strong> for a realistic estimate:\nhttps:\/\/calculator.aws\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, costs are mostly driven by:\n&#8211; sustained Lambda invocation volume and duration\n&#8211; API Gateway traffic (if used)\n&#8211; logging\/metrics\/alarms volume\n&#8211; data storage and database capacity<br\/>\nUse official pricing pages for the actual services in your template, such as:\n&#8211; Lambda pricing: https:\/\/aws.amazon.com\/lambda\/pricing\/\n&#8211; CloudWatch pricing: https:\/\/aws.amazon.com\/cloudwatch\/pricing\/\n&#8211; API Gateway pricing: https:\/\/aws.amazon.com\/api-gateway\/pricing\/\n&#8211; DynamoDB pricing: https:\/\/aws.amazon.com\/dynamodb\/pricing\/\n&#8211; S3 pricing: https:\/\/aws.amazon.com\/s3\/pricing\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a <strong>private<\/strong> application in <strong>AWS Serverless Application Repository<\/strong>, then <strong>deploy<\/strong> it as a CloudFormation stack and <strong>invoke<\/strong> the Lambda function to verify it works.<\/p>\n\n\n\n<p>This lab is designed to be:\n&#8211; beginner-friendly\n&#8211; low-cost (one small Lambda function + logs)\n&#8211; executable using the AWS Console and optional AWS CLI<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a simple CloudFormation template that defines:\n   &#8211; an IAM role for Lambda\n   &#8211; a Lambda function with inline code\n2. Publish the template as a <strong>private SAR application<\/strong>.\n3. Deploy the application (creates a CloudFormation stack).\n4. Invoke the Lambda and view logs.\n5. Clean up (delete stack and SAR application).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a region and confirm permissions<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Sign in to the <strong>AWS Management Console<\/strong>.<\/li>\n<li>Select an AWS Region (for example, <code>us-east-1<\/code>). Use one region consistently for the lab.<\/li>\n<li>Confirm your IAM principal can:\n   &#8211; create\/update\/delete CloudFormation stacks\n   &#8211; create IAM roles\/policies\n   &#8211; create Lambda functions\n   &#8211; manage SAR applications<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a region selected and a user\/role capable of deploying serverless resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a CloudFormation template locally<\/h3>\n\n\n\n<p>Create a file named <code>sar-hello-lambda.yaml<\/code> on your workstation with the following content.<\/p>\n\n\n\n<pre><code class=\"language-yaml\">AWSTemplateFormatVersion: \"2010-09-09\"\nDescription: \"SAR lab: Hello Lambda (inline code) deployed via AWS Serverless Application Repository\"\n\nParameters:\n  FunctionNameSuffix:\n    Type: String\n    Default: \"hello\"\n    Description: \"Suffix appended to the Lambda function name (stack name will also be included).\"\n\nResources:\n  HelloFunctionRole:\n    Type: AWS::IAM::Role\n    Properties:\n      AssumeRolePolicyDocument:\n        Version: \"2012-10-17\"\n        Statement:\n          - Effect: Allow\n            Principal:\n              Service: lambda.amazonaws.com\n            Action: \"sts:AssumeRole\"\n      ManagedPolicyArns:\n        - arn:aws:iam::aws:policy\/service-role\/AWSLambdaBasicExecutionRole\n\n  HelloFunction:\n    Type: AWS::Lambda::Function\n    Properties:\n      FunctionName: !Sub \"${AWS::StackName}-${FunctionNameSuffix}\"\n      Runtime: nodejs20.x\n      Handler: index.handler\n      Role: !GetAtt HelloFunctionRole.Arn\n      Timeout: 3\n      MemorySize: 128\n      Code:\n        ZipFile: |\n          exports.handler = async (event) =&gt; {\n            const response = {\n              message: \"Hello from a SAR-deployed Lambda!\",\n              input: event\n            };\n            console.log(\"Response:\", JSON.stringify(response));\n            return response;\n          };\n\nOutputs:\n  HelloFunctionName:\n    Description: \"Deployed Lambda function name\"\n    Value: !Ref HelloFunction\n<\/code><\/pre>\n\n\n\n<p>Notes:\n&#8211; This uses inline Lambda code to avoid packaging artifacts for the lab.\n&#8211; <code>nodejs20.x<\/code> is commonly available, but runtime availability can change. If you see a runtime error, pick a runtime supported in your region\/account and update the template accordingly.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a valid CloudFormation template file that defines a Lambda function and role.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a private application in AWS Serverless Application Repository<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the AWS Console, search for <strong>Serverless Application Repository<\/strong>.<\/li>\n<li>Choose <strong>Create application<\/strong>.<\/li>\n<li>For authoring method, choose the option that allows you to <strong>upload a template file<\/strong> (wording may vary).<\/li>\n<li>Provide application details:\n   &#8211; <strong>Application name<\/strong>: <code>sar-hello-lambda<\/code>\n   &#8211; <strong>Description<\/strong>: <code>Hello Lambda deployed from AWS Serverless Application Repository<\/code>\n   &#8211; <strong>Author<\/strong>: your name\/team\n   &#8211; <strong>Semantic version<\/strong>: <code>1.0.0<\/code>\n   &#8211; <strong>Visibility<\/strong>: <strong>Private<\/strong> (only your account)<\/li>\n<li>Upload <code>sar-hello-lambda.yaml<\/code>.<\/li>\n<li>Create\/publish the application.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> A new private SAR application exists in your account in the selected region with version <code>1.0.0<\/code>.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In SAR, open the application page and confirm you can see:\n  &#8211; version <code>1.0.0<\/code>\n  &#8211; the template contents (or template view)\n  &#8211; the <strong>Deploy<\/strong> action<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Deploy the application (creates a CloudFormation stack)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>On the application page, choose <strong>Deploy<\/strong>.<\/li>\n<li>Enter:\n   &#8211; <strong>Stack name<\/strong>: <code>sar-hello-lambda-stack<\/code>\n   &#8211; <strong>Parameters<\/strong>:<ul>\n<li><code>FunctionNameSuffix<\/code>: keep default <code>hello<\/code> (or set <code>dev<\/code>)<\/li>\n<\/ul>\n<\/li>\n<li>Acknowledge IAM resource creation if prompted (CloudFormation often requires explicit acknowledgement when creating IAM resources).<\/li>\n<li>Start the deployment.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> CloudFormation creates a stack named <code>sar-hello-lambda-stack<\/code> and provisions:\n&#8211; an IAM role\n&#8211; a Lambda function named like <code>sar-hello-lambda-stack-hello<\/code><\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Go to <strong>CloudFormation<\/strong> \u2192 Stacks \u2192 select <code>sar-hello-lambda-stack<\/code>.\n&#8211; Confirm stack status is <strong>CREATE_COMPLETE<\/strong>.\n&#8211; In the <strong>Outputs<\/strong> tab, copy <code>HelloFunctionName<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Invoke the Lambda and check logs<\/h3>\n\n\n\n<p>You can test via Console or CLI.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Invoke using the Lambda console<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>AWS Lambda<\/strong> \u2192 Functions \u2192 select the function name from stack outputs.<\/li>\n<li>Choose <strong>Test<\/strong> and create a test event (any JSON).<\/li>\n<li>Run the test.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> The Lambda returns JSON containing the message and your input.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Invoke using AWS CLI (optional)<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Ensure AWS CLI is configured:\n   &#8211; https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/cli-configure-quickstart.html<\/li>\n<li>Invoke the function (replace the function name):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws lambda invoke \\\n  --function-name \"sar-hello-lambda-stack-hello\" \\\n  --payload '{\"from\":\"cli\",\"purpose\":\"sar-lab\"}' \\\n  response.json\ncat response.json\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>View logs:\n   &#8211; Go to <strong>CloudWatch<\/strong> \u2192 Logs \u2192 Log groups \u2192 find <code>\/aws\/lambda\/&lt;function-name&gt;<\/code>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> CloudWatch Logs contains a line starting with <code>Response:<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully validated all of the following:\n&#8211; A <strong>private<\/strong> application exists in AWS Serverless Application Repository.\n&#8211; The application deploys via <strong>CloudFormation<\/strong>.\n&#8211; Deployed resources (Lambda + IAM role) exist and function correctly.\n&#8211; You can observe runtime output in <strong>CloudWatch Logs<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Error: CloudFormation stack fails with IAM capability error<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Symptom<\/strong>: Stack fails and mentions IAM resources require acknowledgement.<\/li>\n<li><strong>Fix<\/strong>: Redeploy and ensure you check the box acknowledging IAM resource creation (CAPABILITY_IAM \/ CAPABILITY_NAMED_IAM depending on template).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Error: AccessDenied when deploying<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Symptom<\/strong>: CloudFormation or SAR deployment fails with <code>AccessDenied<\/code>.<\/li>\n<li><strong>Fix<\/strong>: Ensure your IAM principal has permissions for:<\/li>\n<li><code>cloudformation:*<\/code> (at least create\/update stack actions)<\/li>\n<li><code>lambda:*<\/code> for create function<\/li>\n<li><code>iam:CreateRole<\/code>, <code>iam:AttachRolePolicy<\/code>, etc.<\/li>\n<li>SAR permissions to deploy the application<br\/>\n  In production, implement least privilege; for the lab, use a role with broader rights.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Error: Lambda runtime not supported<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Symptom<\/strong>: Stack fails indicating unsupported runtime (rare but possible depending on region\/partition).<\/li>\n<li><strong>Fix<\/strong>: Change <code>Runtime<\/code> to an available runtime for your region\/account and redeploy.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Error: Function name already exists<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Symptom<\/strong>: CloudFormation fails because Lambda function name conflicts.<\/li>\n<li><strong>Fix<\/strong>: Use a unique stack name or a different <code>FunctionNameSuffix<\/code>, then redeploy.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges (even though this lab is typically low-cost), delete resources.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Delete the CloudFormation stack:\n   &#8211; CloudFormation \u2192 Stacks \u2192 select <code>sar-hello-lambda-stack<\/code> \u2192 <strong>Delete<\/strong><\/p>\n<\/li>\n<li>\n<p>Delete the SAR application (optional but recommended for lab hygiene):\n   &#8211; Serverless Application Repository \u2192 your application <code>sar-hello-lambda<\/code> \u2192 delete versions\/application<br\/>\n   The exact UI may vary; you may need to delete versions before deleting the application.<\/p>\n<\/li>\n<li>\n<p>Confirm Lambda function and log group are removed:\n   &#8211; Lambda function should be deleted with the stack\n   &#8211; CloudWatch log group is usually deleted if created by the stack; sometimes log groups persist depending on template and retention settings<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> No remaining stack resources; SAR application removed if you chose to delete it.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Keep applications small and composable<\/strong>: publish focused apps (e.g., \u201cS3 event processor\u201d) rather than huge monolith templates.<\/li>\n<li><strong>Use clear parameters and outputs<\/strong>: define a stable \u201cinterface\u201d (parameters, outputs) so consumers can integrate reliably.<\/li>\n<li><strong>Design for upgrades<\/strong>: avoid breaking changes; when needed, bump major version and document migration steps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege execution roles<\/strong>: never ship templates that grant <code>*:*<\/code> to Lambda roles.<\/li>\n<li><strong>Separate publisher vs consumer permissions<\/strong>:<\/li>\n<li>publishers: can create app versions and manage application policy<\/li>\n<li>consumers: can deploy approved apps (and only those apps)<\/li>\n<li><strong>Use permission boundaries<\/strong> for consumer-deployed IAM roles in strict environments (evaluate your org policy and verify behavior with CloudFormation\/IAM).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control logging costs<\/strong>: set reasonable CloudWatch log retention and avoid excessive logs.<\/li>\n<li><strong>Parameterize optional features<\/strong>: let consumers disable expensive components (e.g., detailed metrics, extra alarms) if not required.<\/li>\n<li><strong>Avoid NAT by default<\/strong>: don\u2019t require VPC + NAT unless needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Right-size Lambda memory<\/strong> and timeout defaults.<\/li>\n<li><strong>Use DLQs\/retries<\/strong> (where applicable) for event-driven reliability.<\/li>\n<li><strong>Prefer managed integrations<\/strong> (EventBridge, SQS) for backpressure and decoupling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use CloudFormation-safe patterns<\/strong>:<\/li>\n<li>stable logical IDs<\/li>\n<li>avoid replacing critical resources unnecessarily<\/li>\n<li>Provide safe defaults for:<\/li>\n<li>reserved concurrency (if needed)<\/li>\n<li>alarm thresholds<\/li>\n<li>retries and dead-letter handling<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Embed operational visibility:<\/li>\n<li>CloudWatch log groups and retention<\/li>\n<li>alarms for errors\/throttles (where reasonable)<\/li>\n<li>structured logging<\/li>\n<li>Document:<\/li>\n<li>what resources are created<\/li>\n<li>how to test<\/li>\n<li>how to roll back (select previous version; update stack)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply consistent tags from the template (environment, owner, cost center).<\/li>\n<li>Use naming conventions that avoid collisions across environments.<\/li>\n<li>Include a README (especially for shared\/internal catalogs) with:<\/li>\n<li>parameters<\/li>\n<li>outputs<\/li>\n<li>security notes<\/li>\n<li>cost notes<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Publishing and management<\/strong> are controlled by IAM permissions.<\/li>\n<li><strong>Deploying<\/strong> requires:<\/li>\n<li>permission to deploy the SAR application<\/li>\n<li>permission to create resources in CloudFormation (Lambda\/IAM\/etc.)<\/li>\n<li><strong>Sharing<\/strong> is controlled by application resource policies.<\/li>\n<\/ul>\n\n\n\n<p>Security recommendation:\n&#8211; Treat a SAR application like code that can create infrastructure. Apply the same governance as you would to:\n  &#8211; Terraform modules\n  &#8211; CloudFormation templates\n  &#8211; CI\/CD pipeline templates<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SAR metadata is managed by AWS; deployed resources must be designed for encryption where needed:<\/li>\n<li>KMS for secrets\/data services<\/li>\n<li>encryption at rest for DynamoDB\/S3 (service defaults vary)<\/li>\n<li>For logs, consider KMS encryption for CloudWatch Logs if required by compliance (verify feasibility and operational impact).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Templates might deploy public endpoints (API Gateway) or public permissions.<\/li>\n<li>Require publishers to document:<\/li>\n<li>what endpoints are public<\/li>\n<li>what authentication is used<\/li>\n<li>whether Lambda is inside a VPC<\/li>\n<li>Prefer least-exposure defaults: private where possible, authenticated where public.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do <strong>not<\/strong> embed secrets in templates or Lambda environment variables in plaintext.<\/li>\n<li>Use AWS-managed secret stores (commonly <strong>AWS Secrets Manager<\/strong> or <strong>AWS Systems Manager Parameter Store<\/strong>) and grant read access via IAM.<\/li>\n<li>Parameterize secret references (ARNs\/paths), not secret values.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>CloudTrail<\/strong> in all regions you use for SAR publishing\/deployment.<\/li>\n<li>Monitor:<\/li>\n<li>application policy changes<\/li>\n<li>application version publishing<\/li>\n<li>stack deployments\/updates\/deletions<\/li>\n<\/ul>\n\n\n\n<p>CloudTrail docs: https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For regulated environments, establish an approval workflow:<\/li>\n<li>template review<\/li>\n<li>dependency review (services used)<\/li>\n<li>logging and retention checks<\/li>\n<li>IAM policy review<\/li>\n<li>data residency (region) review<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploying public SAR apps into production without reviewing the template.<\/li>\n<li>Over-permissive Lambda execution roles in published apps.<\/li>\n<li>Publishing apps that create IAM users\/access keys (avoid unless absolutely necessary).<\/li>\n<li>Publishing apps that open security groups broadly or create unauthenticated APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a <strong>sandbox account<\/strong> for evaluating new SAR apps and versions.<\/li>\n<li>Use <strong>CloudFormation change sets<\/strong> for stack updates when upgrading app versions.<\/li>\n<li>Consider policy guardrails with AWS Organizations SCPs and IAM boundaries (org-specific).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Region scope<\/strong>: SAR applications are region-based; deploying across regions may require publishing\/managing versions per region. Verify exact behavior in official docs.<\/li>\n<li><strong>CloudFormation dependency<\/strong>: SAR deployments are CloudFormation stacks. If your org does not allow CloudFormation, SAR will not fit.<\/li>\n<li><strong>Template safety is your responsibility<\/strong>: SAR does not replace security review. A template can create powerful IAM permissions and public endpoints.<\/li>\n<li><strong>Upgrades are stack updates<\/strong>: Updating an application version generally means updating a CloudFormation stack to a new template\/version.<\/li>\n<li><strong>Drift risk<\/strong>: If consumers manually change resources created by a stack, drift can break future updates.<\/li>\n<li><strong>IAM capability prompts<\/strong>: Many serverless apps create IAM roles. Deployments may fail unless you acknowledge IAM capabilities.<\/li>\n<li><strong>Quotas vary by service<\/strong>: failures often come from Lambda\/IAM\/CloudFormation quotas rather than SAR itself.<\/li>\n<li><strong>Public apps aren\u2019t \u201cAWS-supported by default\u201d<\/strong>: public does not necessarily mean vetted for your environment; treat as third-party code.<\/li>\n<li><strong>Artifact handling<\/strong>: for real-world apps with packaged code, you must manage how artifacts are stored and accessed (often via SAM packaging). Follow official SAR + SAM guidance and verify latest packaging requirements.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Serverless Application Repository is one option for distributing reusable serverless infrastructure and patterns. Here are common alternatives.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Serverless Application Repository<\/strong><\/td>\n<td>Sharing\/deploying <strong>serverless<\/strong> apps as SAM\/CloudFormation<\/td>\n<td>Versioned apps, discoverability, CloudFormation-native deployments, resource-based sharing<\/td>\n<td>CloudFormation-only; requires strong governance for template review<\/td>\n<td>You want an AWS-native serverless app catalog<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudFormation (direct templates)<\/strong><\/td>\n<td>Teams who already manage templates in Git<\/td>\n<td>Full control, no extra catalog layer, standard IaC<\/td>\n<td>Harder discoverability; sharing across teams\/accounts is manual<\/td>\n<td>Small orgs or mature Git-based IaC workflows<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CDK (construct libraries)<\/strong><\/td>\n<td>Reusable infrastructure in code<\/td>\n<td>Strong abstraction, typed constructs, code reuse<\/td>\n<td>Consumers must adopt CDK\/toolchain; versioning and deployment differ<\/td>\n<td>Engineering teams standardizing on CDK<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Service Catalog<\/strong><\/td>\n<td>Governance-heavy catalog with portfolios\/constraints<\/td>\n<td>Enterprise governance, constraints, approvals<\/td>\n<td>Not serverless-specific; setup overhead<\/td>\n<td>Large orgs needing formal product governance<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Marketplace (where applicable)<\/strong><\/td>\n<td>Procuring third-party solutions<\/td>\n<td>Procurement workflows, vendor distribution<\/td>\n<td>Not a developer-oriented internal catalog<\/td>\n<td>Buying vendor solutions with procurement controls<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform modules + private registry<\/strong><\/td>\n<td>Cross-cloud IaC and module reuse<\/td>\n<td>Multi-cloud, strong ecosystem<\/td>\n<td>Different deployment engine; not SAR; may not align with SAM\/CloudFormation<\/td>\n<td>Standardizing on Terraform across providers<\/td>\n<\/tr>\n<tr>\n<td><strong>GitHub templates\/repos<\/strong><\/td>\n<td>Simple sharing of sample code<\/td>\n<td>Easy, familiar<\/td>\n<td>Not deployable \u201cas a product\u201d; no policy-based deployment controls<\/td>\n<td>Early-stage sharing; prototypes<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Marketplace \/ GCP Cloud Marketplace<\/strong><\/td>\n<td>Other cloud ecosystems<\/td>\n<td>Native distribution in those clouds<\/td>\n<td>Not AWS; different IaC models<\/td>\n<td>If you\u2019re operating primarily in Azure\/GCP<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (multi-account organization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A financial services company has 80+ AWS accounts. Teams deploy serverless APIs and background jobs, but logging, alerting, and IAM policies vary widely.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Platform team publishes:<ul>\n<li><code>org-structured-logging-lambda<\/code> (Lambda + standardized log format + retention)<\/li>\n<li><code>org-alarm-pack<\/code> (CloudWatch alarms for errors\/throttles)<\/li>\n<\/ul>\n<\/li>\n<li>Apps are shared via SAR application policies to all workload accounts.<\/li>\n<li>Each workload account deploys the apps as CloudFormation stacks, parameterized by environment.<\/li>\n<li>CloudTrail records publish\/deploy actions; security team reviews templates before versions are shared broadly.<\/li>\n<li><strong>Why AWS Serverless Application Repository was chosen<\/strong><\/li>\n<li>AWS-native catalog for serverless<\/li>\n<li>versioned distribution and controlled sharing<\/li>\n<li>easy consumption by many teams with CloudFormation<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>consistent observability and baseline security controls<\/li>\n<li>faster onboarding for new teams<\/li>\n<li>fewer incidents due to missing alarms\/log retention misconfigurations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup has a small team building event-driven workflows. They frequently spin up new services and want a consistent \u201cqueue worker\u201d pattern.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Team publishes a private SAR app: <code>sqs-worker-lambda<\/code><ul>\n<li>SQS queue<\/li>\n<li>Lambda consumer<\/li>\n<li>DLQ + basic alarms<\/li>\n<\/ul>\n<\/li>\n<li>For each new microservice, they deploy the app and parameterize the queue name and concurrency.<\/li>\n<li><strong>Why AWS Serverless Application Repository was chosen<\/strong><\/li>\n<li>Simple reuse without building a heavy platform<\/li>\n<li>clear versioning and rollback via CloudFormation<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>fewer copy\/paste errors<\/li>\n<li>faster feature delivery<\/li>\n<li>consistent operational defaults<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is AWS Serverless Application Repository the same as AWS SAM?<\/strong><br\/>\n   No. AWS SAM is a template model and tooling for serverless. AWS Serverless Application Repository is a catalog and publishing\/deployment mechanism for applications often defined using SAM.<\/p>\n<\/li>\n<li>\n<p><strong>Is AWS Serverless Application Repository free?<\/strong><br\/>\n   Generally, there is no additional charge to use the repository, but you pay for AWS resources created when you deploy apps (Lambda, API Gateway, logs, etc.). Verify current pricing guidance in official docs and the pricing pages of underlying services.<\/p>\n<\/li>\n<li>\n<p><strong>What exactly is an \u201capplication\u201d in SAR?<\/strong><br\/>\n   A versioned package defined by a SAM\/CloudFormation template plus metadata (description, author, version, etc.) that can be deployed as a CloudFormation stack.<\/p>\n<\/li>\n<li>\n<p><strong>How do deployments work?<\/strong><br\/>\n   Deployments create or update an <strong>AWS CloudFormation stack<\/strong> in your account\/region.<\/p>\n<\/li>\n<li>\n<p><strong>Can I deploy an application into multiple accounts?<\/strong><br\/>\n   Yes, by sharing the application via an application policy and ensuring the target account has permissions to deploy and create the required resources.<\/p>\n<\/li>\n<li>\n<p><strong>Can I publish private applications for internal use only?<\/strong><br\/>\n   Yes. Private apps are visible only in your account (unless shared via policy).<\/p>\n<\/li>\n<li>\n<p><strong>Can I publish applications publicly?<\/strong><br\/>\n   Yes, SAR supports public applications, but requirements may apply (metadata\/licensing). Verify current public publishing requirements in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>How do I update an app after publishing?<\/strong><br\/>\n   Publish a <strong>new version<\/strong>. Consumers update their CloudFormation stacks to the newer version.<\/p>\n<\/li>\n<li>\n<p><strong>Can consumers modify resources after deployment?<\/strong><br\/>\n   They can, but it may cause CloudFormation drift and complicate updates. Best practice is to manage changes through CloudFormation updates.<\/p>\n<\/li>\n<li>\n<p><strong>Can I restrict which versions consumers deploy?<\/strong><br\/>\n   Consumers generally select versions. To enforce, you typically use governance controls (process, IAM, org policies). Exact mechanisms depend on your environment.<\/p>\n<\/li>\n<li>\n<p><strong>How do I review what an app will create before deploying?<\/strong><br\/>\n   Inspect the template in SAR. For updates, use CloudFormation change sets. Always review IAM, network exposure, and data access patterns.<\/p>\n<\/li>\n<li>\n<p><strong>Does SAR run my code?<\/strong><br\/>\n   No. SAR stores and distributes application templates and metadata. Runtime execution is performed by resources deployed into your account (like Lambda).<\/p>\n<\/li>\n<li>\n<p><strong>Does SAR support containers (Lambda container images)?<\/strong><br\/>\n   It depends on whether your CloudFormation\/SAM template supports deploying those resources. Verify current SAM\/CloudFormation support and the SAR publishing workflow for container-based Lambdas in official docs.<\/p>\n<\/li>\n<li>\n<p><strong>How do I handle secrets in SAR apps?<\/strong><br\/>\n   Don\u2019t embed secrets. Use Secrets Manager or Parameter Store and grant runtime IAM access to read secrets securely.<\/p>\n<\/li>\n<li>\n<p><strong>How do I audit who deployed or updated an app?<\/strong><br\/>\n   Use <strong>AWS CloudTrail<\/strong> for SAR and CloudFormation events, and CloudFormation stack events for deployment details.<\/p>\n<\/li>\n<li>\n<p><strong>Is SAR suitable for non-serverless infrastructure?<\/strong><br\/>\n   SAR is intended for serverless applications, but it fundamentally distributes CloudFormation\/SAM templates. For broader infra catalogs, consider other approaches like Service Catalog.<\/p>\n<\/li>\n<li>\n<p><strong>Do I need the AWS CLI or SAM CLI to use SAR?<\/strong><br\/>\n   No. You can use the AWS Console. CLI tooling helps automate publishing and deployment.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Serverless Application Repository<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>AWS Serverless Application Repository Developer Guide: https:\/\/docs.aws.amazon.com\/serverless-application-repository\/latest\/devguide\/what-is-serverlessrepo.html<\/td>\n<td>Core concepts, publishing, sharing, deployment flow<\/td>\n<\/tr>\n<tr>\n<td>Official CLI Reference<\/td>\n<td>AWS CLI <code>serverlessrepo<\/code> commands: https:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/serverlessrepo\/index.html<\/td>\n<td>Automating publishing\/policy\/deployment tasks<\/td>\n<\/tr>\n<tr>\n<td>Official IaC Docs<\/td>\n<td>AWS CloudFormation User Guide: https:\/\/docs.aws.amazon.com\/AWSCloudFormation\/latest\/UserGuide\/Welcome.html<\/td>\n<td>Understand stacks, updates, rollback, change sets<\/td>\n<\/tr>\n<tr>\n<td>Official Serverless Model Docs<\/td>\n<td>AWS SAM Developer Guide: https:\/\/docs.aws.amazon.com\/serverless-application-model\/latest\/developerguide\/what-is-sam.html<\/td>\n<td>Authoring SAM templates used in many SAR apps<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>AWS Pricing Calculator: https:\/\/calculator.aws\/<\/td>\n<td>Estimate costs for resources created by deployed apps<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>AWS Lambda Pricing: https:\/\/aws.amazon.com\/lambda\/pricing\/<\/td>\n<td>Key cost driver for most SAR apps<\/td>\n<\/tr>\n<tr>\n<td>Security\/Audit<\/td>\n<td>AWS CloudTrail User Guide: https:\/\/docs.aws.amazon.com\/awscloudtrail\/latest\/userguide\/cloudtrail-user-guide.html<\/td>\n<td>Auditing publishing\/deployments and policy changes<\/td>\n<\/tr>\n<tr>\n<td>Architecture<\/td>\n<td>AWS Serverless Architectures: https:\/\/aws.amazon.com\/architecture\/serverless\/<\/td>\n<td>Reference patterns often packaged into reusable apps<\/td>\n<\/tr>\n<tr>\n<td>Official GitHub<\/td>\n<td>AWS SAM CLI: https:\/\/github.com\/aws\/aws-sam-cli<\/td>\n<td>Tooling commonly used to build\/package\/publish serverless apps<\/td>\n<\/tr>\n<tr>\n<td>Official GitHub<\/td>\n<td>AWS Serverless Application Model: https:\/\/github.com\/aws\/serverless-application-model<\/td>\n<td>SAM spec, examples, and tooling references<\/td>\n<\/tr>\n<tr>\n<td>Community Learning<\/td>\n<td>AWS Compute Blog \/ Serverless content: https:\/\/aws.amazon.com\/blogs\/compute\/<\/td>\n<td>Practical serverless tutorials and patterns (verify SAR applicability per post)<\/td>\n<\/tr>\n<tr>\n<td>Community Samples<\/td>\n<td>aws-samples on GitHub: https:\/\/github.com\/aws-samples<\/td>\n<td>Many serverless reference projects; adapt into SAR apps with governance<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to advanced DevOps\/cloud engineers<\/td>\n<td>AWS, DevOps, CI\/CD, IaC, operations practices (check course outline for SAR\/serverless specifics)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Developers\/DevOps practitioners<\/td>\n<td>SCM, DevOps practices, automation tooling (check serverless coverage)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations and platform teams<\/td>\n<td>Cloud operations, reliability, automation (verify AWS\/serverless modules)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations, reliability engineers<\/td>\n<td>SRE practices, monitoring, incident response (apply to serverless ops)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops engineers exploring AIOps<\/td>\n<td>Monitoring, automation, AIOps concepts (verify AWS integration content)<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify current AWS\/serverless coverage)<\/td>\n<td>Engineers seeking guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify AWS modules)<\/td>\n<td>Beginners to intermediate<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training resources (verify offerings)<\/td>\n<td>Teams needing short-term guidance<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify AWS\/serverless focus)<\/td>\n<td>Ops\/DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify service catalog on site)<\/td>\n<td>Cloud architecture, automation, DevOps process improvements<\/td>\n<td>Designing a serverless app catalog strategy; implementing CI\/CD for SAM + SAR publishing<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training (verify consulting offerings)<\/td>\n<td>DevOps transformations, tooling, cloud enablement<\/td>\n<td>Establishing internal SAR publishing standards; building template review and governance workflow<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify service list)<\/td>\n<td>CI\/CD, automation, operational practices<\/td>\n<td>Multi-account deployment strategy for SAR apps; integrating CloudFormation\/SAM with org guardrails<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Serverless Application Repository<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS fundamentals<\/strong>: IAM, regions, VPC basics, CloudWatch basics<\/li>\n<li><strong>Serverless basics<\/strong>: Lambda triggers, permissions model, logging\/metrics<\/li>\n<li><strong>Infrastructure as Code<\/strong>: CloudFormation fundamentals (stacks, parameters, outputs)<\/li>\n<li><strong>AWS SAM basics<\/strong> (recommended): how SAM maps to CloudFormation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Serverless Application Repository<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Advanced serverless architecture<\/strong><\/li>\n<li>event-driven design<\/li>\n<li>idempotency and retries<\/li>\n<li>DLQs and failure handling<\/li>\n<li><strong>CI\/CD for serverless<\/strong><\/li>\n<li>CodePipeline\/CodeBuild or GitHub Actions<\/li>\n<li>automated tests (unit + integration)<\/li>\n<li>versioning and release management<\/li>\n<li><strong>Governance at scale<\/strong><\/li>\n<li>AWS Organizations SCPs<\/li>\n<li>permission boundaries<\/li>\n<li>centralized logging and security monitoring<\/li>\n<li><strong>Observability<\/strong><\/li>\n<li>structured logging<\/li>\n<li>tracing (AWS X-Ray where applicable)<\/li>\n<li>SLOs\/SLIs for serverless services<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud\/Platform Engineer (internal developer platform for serverless)<\/li>\n<li>DevOps Engineer \/ SRE (operational automation distributed via templates)<\/li>\n<li>Solutions Architect (standard serverless building blocks)<\/li>\n<li>Security Engineer (distributing compliant patterns; reviewing templates)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>SAR is not typically a standalone certification topic, but it supports skills used in:\n&#8211; AWS Certified Solutions Architect (Associate\/Professional)\n&#8211; AWS Certified Developer (Associate)\n&#8211; AWS Certified SysOps Administrator (Associate)\n&#8211; AWS Certified DevOps Engineer (Professional)<br\/>\nVerify current AWS certification tracks: https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a private SAR app that provisions:<\/li>\n<li>a Lambda + EventBridge schedule for automated maintenance tasks<\/li>\n<li>Build an \u201cobservability pack\u201d SAR app:<\/li>\n<li>CloudWatch alarm(s), log retention, metric filters<\/li>\n<li>Build a shared SAR app across two accounts:<\/li>\n<li>application policy allowing a specific account to deploy<\/li>\n<li>Implement a CI workflow:<\/li>\n<li>bump semantic version<\/li>\n<li>publish a new SAR version<\/li>\n<li>update a test stack automatically<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Serverless Application Repository (SAR)<\/strong>: AWS service for publishing, discovering, sharing, and deploying serverless applications as versioned templates.<\/li>\n<li><strong>Serverless application<\/strong>: A collection of AWS resources (commonly Lambda and event sources) deployed together to deliver a capability.<\/li>\n<li><strong>AWS SAM (Serverless Application Model)<\/strong>: An extension to CloudFormation that simplifies defining serverless resources.<\/li>\n<li><strong>AWS CloudFormation<\/strong>: Infrastructure-as-code service that creates and manages AWS resources using templates and stacks.<\/li>\n<li><strong>Stack<\/strong>: A CloudFormation deployment instance created from a template.<\/li>\n<li><strong>Semantic versioning<\/strong>: Version format like <code>MAJOR.MINOR.PATCH<\/code> used to communicate compatibility changes.<\/li>\n<li><strong>Resource-based policy<\/strong>: A policy attached to a resource (here, a SAR application) controlling which principals can access it.<\/li>\n<li><strong>Least privilege<\/strong>: Security principle of granting only the minimum permissions required.<\/li>\n<li><strong>CloudTrail<\/strong>: AWS service that records API calls and events for auditing.<\/li>\n<li><strong>CloudWatch Logs<\/strong>: Service for collecting and storing log data from AWS resources.<\/li>\n<li><strong>Drift<\/strong>: When deployed resources differ from what the CloudFormation template expects (often due to manual changes).<\/li>\n<li><strong>Parameter<\/strong>: A value provided at deployment time to customize a template.<\/li>\n<li><strong>Output<\/strong>: A value returned by a CloudFormation stack (useful for integration).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Serverless Application Repository is an AWS <strong>Compute-adjacent<\/strong> service that acts as a <strong>versioned catalog<\/strong> for serverless applications defined with <strong>AWS SAM or CloudFormation<\/strong>, deployed through <strong>AWS CloudFormation stacks<\/strong>.<\/p>\n\n\n\n<p>It matters because it enables <strong>repeatable serverless deployments<\/strong>, <strong>controlled sharing across accounts<\/strong>, and <strong>versioned reuse<\/strong>\u2014critical capabilities for platform teams and organizations scaling serverless adoption.<\/p>\n\n\n\n<p>Cost is not primarily driven by the repository; it\u2019s driven by the <strong>resources you deploy<\/strong> (Lambda, API Gateway, logs, databases, and data transfer). Security is mainly about <strong>IAM discipline and template review<\/strong>: a SAR application can create powerful infrastructure, so treat it like production code.<\/p>\n\n\n\n<p>Use AWS Serverless Application Repository when you need an AWS-native way to <strong>publish, discover, and deploy reusable serverless building blocks<\/strong>. Next, deepen your skills with <strong>AWS SAM + CloudFormation operations<\/strong> and build a CI\/CD workflow to publish and roll out application versions safely.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,26],"tags":[],"class_list":["post-168","post","type-post","status-publish","format-standard","hentry","category-aws","category-compute"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/168","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=168"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/168\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=168"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=168"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=168"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}