AWS Startups Blog

Crowdfunding for startups

by Iliyana Ilieva | on | in Startup Spotlight |

Four essential insights from the success stories of AWS startup customers Monzo and Crowdcube


In the second episode of AWS Startups Stories* we heard how Monzo, a mobile only challenger bank made one million pounds in 96 seconds on Crowdcube, the world’s first equity crowdfunding platform.

Below we’ve captured the most essential insights from Darren, CEO and co-founder of Crowdcube and Tom, CEO and founder of Monzo into how today’s startups can make the most of the crowdfunding platform – enjoy!


Darren (left) and Tom (right) in the recording studio.


1. Be meticulous with your preparation

Preparation is everything to a successful crowdfunding campaign. That means spending as much time as you can developing your project pitch, as well as planning how you’re going to get initial exposure, and which kinds of investors you want to attract. Think about what you want to get from your network of investors in the years to come, and make provisions based on those objectives. For example, you might want to plan how you’ll share business developments with them over the coming months, or how you intend to collaborate with them as your product evolves.


2. Make a good impression

We heard from Darren that the biggest investments get secured by startups who get three things right. First, they make sure their valuations are on point, as exaggerated numbers are an immediate red flag for investors. Second, they present themselves well by taking advantage of different content formats like engaging videos that demonstrate their unique product benefits and discussion forums available on the Crowdcube platform. Third, they use the right language: a clear, simple, open tone of voice that conveys authority without sounding like a sales pitch. Brewdog is a good example of this: its quirky Crowdcube campaign helped it secure a recent £10 million investment.


3. Make the most of the platform

Crowdfunding isn’t just about sourcing money. It’s also a perfect opportunity to extend your user base and deepen the relationship with your existing customers. “We had a few extra people come in who were not existing users already, but the vast majority of people who invested were already Monzo users and this helped us deepen our relationship with those people and really further our brand. Values like transparency and customer centricity are just absolutely central to what we’re trying to do and crowdfunding just re-enforced that in such an amazing way”, we heard from Tom.


4. Stay connected 

Another important lesson Tom learned from crowdfunding is the importance of keeping connections with his Crowdcube investors. Tom’s made sure to always send them personal updates about the brand before making public announcements. Monzo investors also receive a special badge of honour – their Monzo card says Investor on it and their “title” also follows them around the community forums.


In a nutshell


Crowdfunding isn’t just about putting your name down and waiting for money to come in. It’s a huge opportunity that takes a lot of work to master. For pointers, follow the advice of Monzo and Crowdcube. Make sure you prepare your campaign meticulously, leaving no stone unturned. Ensure you make the right impression by crafting an appropriate tone of voice, and creating engaging content. Take advantage of the crowdfunding platform and use it for other things like expanding your user base. Finally, stay connected with your investor network so you’re always well-connected and supported. You may not make a million in 96 seconds, but if you follow these pointers, there’s nothing to stop you from doing so.

The podcast with Tom and Darren is available here. In the next episode, we’ll talk about VC funding – stay tuned and subscribe to receive the podcast straight in your inbox.


*What is AWS Startup Stories?

AWS Startup Stories is a business series of podcasts published on the AWS Podcast channel that showcases the success stories of startups running on AWS. Heroes of each business talk about how they overcame challenges and used technology to solve problems, providing tips for companies facing similar issues. Learn more about the series and who’s part of them on the webpage here and never miss an episode by subscribing today!

Four golden rules for taking your idea to market

by Rei Biermann | on | in Startup Spotlight |

Key takeaways from social startup OLIO


This week in AWS Startup Stories* we talked to Tessa Cook, CEO, and co-founder of OLIO Exchange – a food sharing app that builds connections between neighbours and local businesses in order to re-distribute surplus goods.

OLIO started as a simple experiment between twelve people, but today it’s a global brand that’s growing at pace. They piloted the app in the second half of 2015, made it available across the UK at the end of January 2016, and worldwide in October 2016. Since then they’ve had over 170k users sign up and over 210k items (equivalent to 90,000 meals) have been shared. Demand for this surplus food is incredibly high with 40% of items being requested in less than an hour, and 80% in less than 24 hours.

How it works

Users simply snap a picture of their items and add them to OLIO. Neighbours then receive customised alerts and can request anything that takes their fancy. Pick-up takes place – often the same day – at the home, store, an OLIO Drop Box, or another agreed location. Items typically found on the app include food nearing its use-by date from shops, cafes and markets; spare vegetables from the allotment; cakes from an amateur baker; or groceries from household fridges when people go away, move home or start a diet. All the food on OLIO is either available for free, or for a ‘pay as you feel’ donation to charity. OLIO also has a non-food section on the app which is used to share household [items] such as toiletries, cosmetics, light bulbs, cleaning products, books, toys, and clothes.

So here is what we learned from Tessa about taking your idea to market.
1. Conduct the right market research
Before launching OLIO, Tessa & Saasha (her Co-Founder) had to be certain people would engage with a solution to the problem of food waste. But even after weeks of heavy desk research, they couldn’t find many examples of them doing so. Instead of backing out, they decided to run a simple experiment in which they designed a short survey asking members of the public how the problem of food waste made them feel. Surprisingly, one in three people described themselves as feeling “physically pained”. It was a simple piece of research, but enough to prove that OLIO was addressing a real pain point and had a viable target audience.

2. Build a smart prototype
The next step for Tessa was to find out whether people would engage with her product. Instead of committing to launch right away, she decided to test her idea on a pre-existing social platform to minimize the risk. She invited 12 of the survey participants who’d described themselves as “physically pained” into a WhatsApp group. For two weeks they could exchange surplus food items with one another, and provide feedback on the experience. The experiment turned out to be a huge success, with users requesting that an OLIO product be launched as soon as possible. By taking advantage of a free, pre-existing platform, Tessa had all the proof she needed that the market wanted OLIO.

3. Know how and when to pivot 
Once OLIO was launched, things didn’t always run smoothly. Within weeks users started to exchange non-food items like household goods, books and clothing, detracting from the original business model. At first Tessa and her team tried to put a stop to it, but they quickly realised the user activity was an opportunity in disguise: OLIO users were passionate about the product, but not all of them had surplus food to give away. But if the business model was expanded to include other kinds of surplus items, they’d have much more opportunity to engage with the platform. Tessa decided to pivot: OLIO was transformed from a food sharing app to a platform for sharing other household items too.

And not long after OLIO expanded, it was time to pivot the business model again. An imbalance was growing between supply and demand, and Tessa needed to find new sources of supply – fast. She decided to reach out to local supermarkets, offering to pick up stock leftover at the end of the day through the help of OLIO volunteers. Soon after the OLIO “Food Waste Heroes” program was born, and big names like Sainsbury’s and Morrisons were getting on board. Through pivoting the OLIO model to incorporate other businesses, Tessa had a convenient solution to her problem of supply, with powerful new brand connections as a bonus.

4. Devise the right monetization strategy
When OLIO started out, the decision was made not to monetize right away. That way, Tessa could expand the OLIO user base as quickly as possible. But by the time the Food Waste Heroes program was launched, it was clear that OLIO should get back some of the value it was offering users. First, Tessa decided to add an in-app CTA for user donations. Later, as the Food Waste Heroes programme started to scale she needed to offset the costs of that with the retailers. And soon she is planning to offer paid-for premium features for “super users.” By introducing monetization features gradually, Tessa and her team minimized the risk of losing users.

In a nutshell

There’s always an element of risk when taking an idea to market. To minimize that, take inspiration from OLIO. Conduct the right market research so you know you’ve got a large enough audience for your product. Build a smart prototype that gives you a clear vision of the user experience without commitment. Know how and when to pivot your business model to meet evolving demands. And finally, devise the right monetization strategy so you retain a good number of users and return a healthy amount of revenue in the meantime. That’s what OLIO did, and that’s why it’s the successful global brand we see today.

You can listen to the podcast with Tessa here.

If you are interested to see how OLIO is using AWS, subscribe to the podcast here and get access to the cheat sheet to find out more!

There you’ll also find some further reading and resources around optimising your costs on AWS – something key for a social startup like OLIO.

*What is AWS Startup Stories?

AWS Startup Stories is a business series of podcasts published on the AWS Podcast channel that showcases startups running on AWS companies with innovative ideas. Heroes of each business talk about how they overcame challenges and used technology to solve problems, providing tips for companies facing similar issues. Learn more about the series and who’s part of them on the webpage here.

VC 101: how VCs operate, and what you should know as a founder

by admin | on | in Guides & Best Practices |

By Drew Russ, VC BDM, AWS

Drew Russ, AWS Startup & Venture Capital Business Development Manager, held sessions at the AWS Pop-up Lofts in San Francisco and New York that covered the basics that a founder needs to know about venture capital. From the definition of VCs to mechanics and bargaining, the discussion served as a primer for the second part of our series, “Selling to Fortune 100 Enterprises.”  That session featured entrepreneurs from Bitium, Proofpoint, and Segment who spoke about how they did it: the tools and processes that they deployed, the design principles that they used, and the AWS services that allowed them to navigate the procurement maze and land big deals. But you need to learn to walk before you can run, which is why Drew is recapping his VC101 session for everyone who couldn’t attend in-person.

What is venture capital?


“Venture capitalist” is a job. Venture capitalists get paid by others to do this job, and while it’s a pretty great job, it’s important for anyone interacting with a venture capital firm to understand the basic mechanics and incentives that shape how the industry functions.

Venture capital is a form of private equity. While there are many differences within the industry, both venture capital managers and private equity managers strive to achieve very high returns in a relatively short period of time.

Venture capitalists are professional money managers. They are paid to manage money for clients. Their goal is to return investors a multiple (e.g. 2x, 3x etc) of the capital they are provided by their investors. For many VCs, investing in technology and innovation is the vehicle that they use to attempt to achieve this goal. VCs are willing to invest in high-risk businesses because of the potentially high reward that can be achieved by taking on this risk.

Therefore, not all businesses should raise venture capital. You should always consider all financing options and find the best fit for your needs based on your planned growth rates and, most important, the ultimate goal that you have for your business.


The theory of venture capital

Venture capital typically uses a portfolio approach to capture a distribution of probabilities. Venture fund returns are not driven by the “average” outcome of the portfolio, but rather by the significant outliers. Fred Wilson, of Union Square Ventures, states, “I’ve said many times on [this blog] that our target batting average is ‘1/3, 1/3, 1/3,’ which means that we expect to lose our entire investment on 1/3 of our investments, we expect to get our money back (or maybe make a small return) on 1/3 of our investments, and we expect to generate the bulk of our returns on 1/3 of our investments.”

The reality is that most startups fail. For VCs to be successful, they must identify “home runs.” The venture business is driven by these outliers. And truly successful VCs don’t just identify the home runs, they identify the grand slams. This is shown in the data: funds that have returned more than 5x the capital provided to them by their investors almost always tend to show a high concentration of these “grand slams”. In fact, these exceptionally high returning funds have portfolios that consist of almost 20% of deals that exceed 10x on the capital the fund invested. These are the individual “grand slams” (10x) that drive the overall fund return (5x).1  These “grand slam” investments determine whether a VC is successful. VC is about the wins, not the losses.

The venture capital bargain

If you are the founder of a startup and want to raise venture capital, you need to understand the deal that you will strike with a VC when you accept an investment. In particular, you need to understand what you will give up.

First, you give up absolute authority and control. While most VCs don’t meddle in a company that performs according to plan, you likely will add these investors to your Board of Directors, where they will be able to wield influence (usually more often in bad times, but not exclusively). Remember, they have a portfolio of companies and a set of investors, just like you do. Their incentives won’t—and shouldn’t—always align with yours.

Second, you give up a degree of ownership, also known as dilution. Typically, a VC that invests in a seed or Series A deal (early stage) wants to own 20–30% of your company. This allows them to maintain a reasonable ownership stake in the likely event that you decide to raise more capital. As you raise more, they also get diluted, reducing overall ownership (often, investors in early rounds also participate in future rounds, using what is called their Pro Rata right, but let’s not get distracted). At the time the company achieves a liquidity event (for example, the company is sold or goes public), they might own only 2% or so.

Last, you give up preference (which we discuss in more detail at the end of this post). That means that even though your blood, sweat, and tears have gone into this (and maybe some of your own capital or capital from your friends and family), VC investors with a preference will almost always get their money back, before you see any returns. This preference is important to understand as you think about how you will fare in the event of the hallowed IPO or acquisition.

You give this stuff up for a reason, though. You give up (some) control, preference, and ownership in exchange for significant capital that you could not raise anywhere else. Additionally, you gain the experience of the investors who are now working with you to achieve the best outcome.

Understanding these three principles is key to understanding the bargain of venture capital.


How venture capitalists make money

Now that we have covered how VC funds think about investment returns, you need to understand how venture capitalists—the actual individuals you meet or who sit on your board—get paid. In particular, you should be aware of two mechanisms: management fees and carried interest.

Management fees are fees paid by the investors of the VC fund. This fee is similar to what you might pay when you invest in a mutual fund or would pay to a professional money manager who manages your stocks and bonds. It is typically in the range of 1.5–2.5% annually of the funds managed, and is paid quarterly. The fee is paid independent of investment success. That said, the fee will decrease over the lifetime of the fund as the focus of the fund shifts from making new investments to harvesting returns on the investments made.

The second way VCs make money—and the one that generally gets a bulk of the attention—is carried interest, often referred to as carry. Carry is the share of the profit that the VC fund keeps. That is, once a VC fund has returned 100% of the capital provided back to investors, the VC fund begins to participate in a share of the profits above that 100% of capital returned. Typically, carry is pegged at 20% of the profits. Carry is a tricky business, though, as it is a fund-wide return that relies on grand slams to make up for complete losses elsewhere in the portfolio. Furthermore, not all members of a VC fund participate equally in receiving a portion of the carry. For younger folks at VC firms, “achieving carry” is a very big step up in the world.

Roles and responsibilities of a VC team

Speaking of the different members of a VC team, you should know the roles of the people you talk to when engaging a VC fund. It will help you craft your discussion to get the optimal result. Plus, it will help you understand their power to influence decisions within the firm.

The first chapter of Brad Feld’s and Jason Mendelson’s book, Venture Deals, does a wonderful job of outlining the different roles within a VC firm. I’ve borrowed heavily from that book in my descriptions of VC roles below (Mendelson, 2013):

  • Analysts – Generally very smart people with limited power and responsibility. They usually are recent graduates from college, and they typically do a lot of the important work that no one else wants to do or has the time to do, such as crunching numbers and writing memos.
  • Associates – Typically not deal partners, but they support one or more deal partners, usually a General Partner or Managing Director. They have a wide variety of responsibilities including scouting new deals, helping with due diligence, and writing internal investment memos.
  • Sr. Associates/Principals – The next generation of Managing Directors. They are junior deal partners. They typically have some limited deal responsibility, but also often require support from a Managing Director. Typically they don’t make final decisions. That’s usually left to the Investment Committee, comprised of GPs and Managing Directors.
  • Managing Directors/General Partners – The most senior people in the firm. These folks are the leaders of the firm. They approve all investments and sit on the boards of companies.
  • Others: EIRs, Venture Partners, Operating Partners – These titles can mean a variety of things depending on the firm and the individual who holds the title. In general, these folks either are responsible for assisting the portfolio companies post-investment (Operating Partner) or they are part-time affiliates of the fund who incubate their own startup idea (EIR) or provide more deal flow to the VC fund (Venture Partner).


Deal sourcing

Venture capitalists typically look at 1000s of deals per year and invest in a small minority of these opportunities (approximately 1–4% of these deals, depending on the strategy of the fund). So, where do all these deals come from? “Deal flow,” the colloquialism often used to describe the volume of deals that a VC reviews, comes from a variety of sources. But the most valuable deal flow often comes from fellow VCs, founders, or other parts of an investor’s network who can pass along reliable, well-vetted, and well-accustomed opportunities.

Some VC firms use cold calling or outbound deal flow tactics, but the vast majority rely on warm leads sent by colleagues, friends, and former business partners. In fact, some VCs meet only with companies where the founder was introduced by another VC or from a founder that the investor has already worked with in the past. Some VCs won’t look at deals with a first-time founder. Some look at deals only if the founding team is from a certain school, or has a pedigree from certain technology companies. And, of course, some VCs ignore all these policies. The point is that the value of a VC is often equivalent to the reach and extent of their network of collaborators willing to send them investment opportunities that they know will align with the investment parameters of the VC fund.

Why venture capitalists invest at different stages

VC funds invest at different stages of a company’s lifecycle. Some focus only on “early stage investing,” while other focus only on “late stage.” Others focus on all stages, often referring to themselves at “stage agnostic.” Broadly speaking, each stage of investment—early, mid, or late—can be defined by the different type of risk associated with the business at the stage in their maturation. In addition to risk, investors at different stages also tend to look at different metrics, or, in the absence of metrics, the traits of a business to justify an investment.

The type of risk associated with early stage investing is what is called ideation and/or product market fit. Will the service or product you are selling have a real market? Or is what you have built really just a solution looking for a problem? Early stage investors typically focus on the founding team and their pedigree as well as acumen and drive as parameters for justifying an investment because there is little else to go on at this point in the business. Early stage investors generally ask themselves, “Can this product or service solve a big problem, and is this the right team to build the product or service?”

The type of risk associated with mid-stage investing (known as “traditional” VC investing only a few years ago) is about gaining traction and creating a business that can successfully scale to reach the broadest markets possible. At this stage, companies typically raise capital to support growth in Sales & Marketing spend and hiring. While early stage investors focus on getting the fire started, mid-stage investors tend to invest to help the company “pour more gas on the fire” (another colloquialism you will hear plenty). Mid-stage VCs are usually more focused on the core team—not just the founder—and the quality of the team being built to help achieve the scale that they want.

Finally, the type of risk associated with late-stage investing is best described as exit risk. While early stage and mid-stage are focused on creating the foundations of the company, and then rapidly scaling the business off of those foundations, later-stage investors are more focused on how you can monetize the business, through either a sale or an Initial Public Offering (IPO). Valuation and deal structure is always important at any stage, but they become the primary drivers of the return at the later stage. Investing in a company at a $20 MM valuation with the goal of growing the business to a multiple of that is far different from investing in a company at a $500 MM valuation and having a good understanding of what type of pricing the company could likely get at an IPO. Late-stage investors spend much more time thinking about IPO windows (periods of time when going public is more conducive) and the cash balances of potential acquirers than either early or mid-stage investors.


The ABCs of VC funding

As I mentioned, there are different stages at which investors invest. Most people are familiar with terms such as seed or Series B, but many don’t quite understand what those terms actually mean. To be fair, these terms—particularly seed—are constantly redefined or orphaned, and many folks just use them to suit their own needs. But there is some logic to the ABCs of VC.

In general, VC funding follows a Last in, First out (LIFO) principle. Those who invest their money last into a company will typically receive their money back first, before anyone else (i.e., before those who invested earlier). This is not always the case, but a good rule of thumb. That means that all investors in a company ARE NOT EQUAL. Shares issued to VC investors are typically preferred securities. This means exactly what it sounds like: the securities have preference over the securities that were issued before. For example, an investor who invests in the Series B of a company will receive an allotment of Series B Preferred Stock, representing their ownership of the company. These Series B preferred stock will generally have “preference” over the Series A Preferred stock holders (who in turn have preference over common stockholders, who have no preference at all).

Seed, Series A, or Series B and so on can be good indications of the stage of a company (although they also can be misleading), but the truth is that the reference is more to the preference of the holders of the securities. There are other important concepts, such as liquidation preference, that relates to this idea, but I will cover that in subsequent posts.


Venture capitalists have a job to do, just like everyone else. Yes, it’s a pretty cool job, but a job nonetheless. The goal of all VCs is to generate returns through liquidation events (and with all the talk about valuations in the news these days, it’s easy to forget that a valuation means nothing in terms of actual returns until the company achieves a liquidity event).

I hope this post has helped to expose some of the basic functions, mechanics, and, important, incentives as to why VCs do what they do and how they do it. If you are a founder of a company who plans to raise or has already raised venture capital financing, you don’t have to be an expert in the ins-and-outs of venture capital. However, it’s helpful to have a solid understanding given the potential impact on your ultimate success and achievements, both financially as well as personally.

We can help: AWS Activate

AWS Activate is a program designed to provide your startup with the resources you need to get started on AWS. All startups can apply for the Self-Starter Package. We also have custom Portfolio and Portfolio Plus packages for startups in select accelerators, incubators, Seed/VC Funds, and startup-enabling organizations.

Portfolio Package

The Portfolio Package is designed for startups in select accelerators, incubators, Seed/VC Funds, and other startup-enabling organizations. If your startup qualifies for a Portfolio Package, you can receive up to $15,000 in AWS Promotional Credit and other benefits. Ask your program director for more information about how to apply.

Portfolio Plus

If your startup qualifies for a Portfolio Plus package, you can receive up to $15,000 in AWS Promotional Credit for 2 years or $100,000 for 1 year and other benefits. Ask your program director for more information about how to apply.

To learn more about corporate VCs and the other flavors of VCs, and to obtain links to blogs, books, and newsletters from prominent thought leaders, check out Russ’s slideshare deck, “VC 101: How, What & Why VCs Do What They Do.



1Chris Dixon, Andreessen Horowtiz Blog Post,

Spotinst helps to reduce Amazon EC2 costs up to 80%

by Alexander Moss-Bolaños | on | in Startups On Air |

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.



Spotinst is an Israeli startup that was founded 18 months ago by four veterans of MAMRAM (the elite Infrastructure Technology unit of the Israel Defense Forces). The initial idea for Spotinst came from the current CEO, Amiram Shachar, who had been working on a big cloud migration project. During the migration, Shachar experienced firsthand the high costs of running gigantic compute clusters on AWS. He saw a future where Spot Instances could be leveraged to solve the problem. To bring this vision to fruition, the Spotinst team developed software that adds a predictability layer to the Spot Market. They did this by creating technology that uses an understanding of an application’s state in order to reliably run it on Spot Instances. Today, Spotinst has more than 40 employees in both Tel Aviv and San Francisco, and they continue to grow. Currently, Spotinst manages over 1,000 AWS accounts that collectively have many thousands of EC2 instances.

Spotinst built a SaaS platform that provides intelligent workload management, allowing Spotinst’s customers to save 50–80% of their EC2 spend while maintaining 100% availability for customers’ applications. They achieve through a set of heuristics and prediction algorithms that determine the most suitable EC2 instance types on which to place Spot bids. To make predictions, these heuristics and algorithms combine historical statistics and real-time analytics about various EC2 resource pools.

There are many use cases for Spotinst: web services and applications, including those behind an Elastic Load Balancer; big data clusters (such as Hadoop clusters); containerized environments (including Amazon EC2 Container Service, Kubernetes, and Docker Swarm); and high performance computing (HPC).

Spotinst is a big user of EC2 Container Service (ECS). In particular, Spotinst uses ECS to deploy and run containers in Spotinst’s containerized microservices architecture. Additionally, Spotinst uses Elastic Load Balancing with ECS to manipulate and forward traffic. Spotinst also uses other AWS services such as Amazon SQS, Amazon SNS, and individual EC2 instances from time to time.



Interested in learning more about Spotinst? Check out their website or twitter page

Monitoring an app: examples from the AWS Startup Kit

by Brent Rabowsky | on | in Guides & Best Practices |

Monitoring involves processing app logs and metrics to provide insights into your app’s performance and health so that you can keep your app running smoothly. It’s a best practice and key aspect of operational excellence, which focuses on how to optimally run systems. Operational excellence is one of the pillars of the AWS Well-Architected framework. The framework emphasizes the importance of monitoring for automating changes such as scaling, responding to events such as service disruptions, and implementing standards for managing daily operations.

To demonstrate monitoring with AWS services, I’ll use the AWS Startup Kit, which is a set of resources designed to accelerate a startup’s product development on AWS. This post is the fourth in a series about the Startup Kit. Before you read this post, I recommend that you read Building a VPC with the AWS Startup Kit and Launch your app with the AWS Startup Kit so that you’re familiar with the relevant parts of the Startup Kit. This post builds on the previous two posts and covers material that is more advanced.

A core component of the Startup Kit is well-architected sample workloads that you can launch within minutes. The workloads are supported by AWS CloudFormation templates and code published on GitHub. For this post, I’ll refer to the templates at and the Node.js sample app at

The primary AWS service for monitoring is Amazon CloudWatch. You can use CloudWatch to collect and track metrics, collect and monitor log files, set alarms, and automatically react to changes in your AWS resources. The following architecture diagram shows a typical use case where CloudWatch collects metrics from AWS resources and custom sources, provides access to metric statistics, and provides alarms with actions for sending email notifications and triggering an Auto Scaling group to scale out or scale in.

Out of the box, CloudWatch provides metrics for all of your AWS resources, and you can extend it using custom metrics to capture other key metrics for monitoring your app and infrastructure. There are two options for capturing custom metrics with CloudWatch: using the CloudWatch API, and using filters on CloudWatch Logs. In this post, I examine both options. I also discuss using CloudWatch to set alarms. The discussion includes examples that you can use as a starting point for your own apps.


Custom metrics with the CloudWatch API

 You can collect many different metrics at the application level. Because an app’s responsiveness is important for its success, it’s a best practice to collect a variety of latency metrics. At a minimum, you should collect latency metrics for the app’s own API calls, calls to dependencies such as third-party services, and data store transactions. Counts of calls to each of the app’s API calls are useful metrics to measure activity in the app.

Metrics also can help detect unusual and problematic conditions. For example, a metric can track the number of failed app login attempts. Let’s now examine how the CloudWatch API can be used to create such a metric. Because I’m working with the Startup Kit’s Node.js sample app for this post, I’ll use the AWS SDK for JavaScript to call the CloudWatch API.

If you want to see the examples in this post in action, launch the relevant Startup Kit resources including the sample app by following steps 1 through 5 in the README of the Startup Kit templates. Alternatively, you can view the complete code for all examples by referring to the templates and the GitHub repository of the Node.js sample app.

You can access the CloudWatch API through the AWS.CloudWatch object of the JavaScript SDK. The relevant method is putMetricData. The following code snippet from the sample app’s util/aws.js source file shows how to invoke this method for a count metric such as a count of failed app login attempts. Invoking the exported method with the argument LOGIN_FAILURE will publish a metric named LOGIN_FAILURE_COUNT to CloudWatch.

const cloudWatch = new AWS.CloudWatch();

exports.publishMetric = (metricName) => {

              .on('error', (err, res) => log.error(`Error publishing metrics: ${err}`))

function metricDataHelper(metricName) {

    let params = {
        MetricData: [ 
          MetricName: `${metricName}_COUNT`, 
          Timestamp: new Date,
          Unit: 'Count',
          Value: 1.0
        Namespace: 'STARTUP_KIT/API'  

    return params;

After you launch the sample app, you can view a graph of the LOGIN_FAILURE_COUNT metric published by the app. Follow these steps:

  1. Get an app account: Create a new account in the sample app, or use a previously created one.
  1. Generate sample data points: Try to sign in with an incorrect password multiple times over the space of a few minutes.
  1. Graph the metric: On the CloudWatch console, choose Metrics in the navigation pane. Under the All metrics tab, choose Custom Namespaces, and then choose STARTUP_KIT/API. Choose Metrics with no dimensions, choose the LOGIN_FAILURE_COUNT metric name, and then choose Graph this metric only. Switch to the Graphed metrics tab, and set Statistic to Sum and Period to 1 Minute using the dropdown arrows.

When you’re finished, you should have a graph similar to the graph in the following screenshot.

In the graph, the leftmost data point represents 13 failed login attempts aggregated over the prior 1 minute period. The next data point occurs three minutes later and represents a further 8 failed login attempts over the 1 minute period ending 21:36.

We examined only one graph, but there are options to view multiple graphs at one time. For example, you can combine your most frequently viewed graphs in a CloudWatch dashboard, which is a customizable home page in the CloudWatch console that you can use to monitor your resources in a single view.

Instead of publishing individual data points for a metric as shown in the preceding screenshot, it’s also possible to do batch publishing. This helps minimize network activity by reducing the number of API calls, and can be used to comply with any applicable API limits. In CloudWatch, batch publishing is known as a statistic set, and it can be used to avoid the CloudWatch API limit of 20 individual metric data points per putMetricData request. When you have multiple data points per minute, aggregating data via statistic sets also minimizes the number of calls to putMetricData. For example, if you are creating a metric that keeps counts of calls to an API that will receive a large amount of traffic, it would be preferable to use a statistic set.


Creating metrics with CloudWatch Logs filters

 In addition to using an API such as the CloudWatch API to publish metrics, it also is common to extract metrics from log files. CloudWatch Logs simplifies the process of monitoring, storing, and accessing logs from Amazon EC2 instances and other sources. In general, to send logs from EC2 instances to CloudWatch Logs, you need to first install the CloudWatch Logs agent on the instances.

However, in this post I show how to get metrics for the Startup Kit Node.js sample app, which runs on EC2 instances managed by AWS Elastic Beanstalk. There is an easy way to get logs from Elastic Beanstalk to CloudWatch Logs: you simply enable CloudWatch Logs streaming. The sample app enables streaming logs via the Startup Kit’s app.cfn.yml CloudFormation template.

To demonstrate how to extract metrics from CloudWatch Logs, I’ll create a metric that measures the latency of login API calls. This is a critical measurement because users tend to be discouraged from using apps that suffer from slow login, especially if login is required to access the key features of the app. A metric based on a CloudWatch Logs group is extracted using a metrics filter. The following are the steps for creating and using a metrics filter for a LOGIN_LATENCY metric. For metric filter creation, use either step 1 (CloudFormation template) or 2 (CLI command), but not both.

  1. CloudFormation: For this purposes of this post, you can create the metrics filter by creating a CloudFormation stack based on the devops.cfn.yml template in the Startup Kit templates. See the README of the templates for complete directions about how to do so; you’ll need to complete steps 1 through 5.
  1. CLI command: Alternatively, you can create a metrics filter using the CloudWatch console or using the following AWS CLI command (replacing “<your-Elastic-Beanstalk-environment>” with your Elastic Beanstalk environment name). Let’s examine the command line-by-line. In the first line, put-metric-filter is the actual command. The second line specifies the name of the CloudWatch Logs group to which the filter is applied, and corresponds in this case to a log named nodejs.log that is automatically streamed to CloudWatch Logs by Elastic Beanstalk. The third line simply specifies a name for the filter itself, while the fourth line specifies a filter pattern. A filter pattern can apply to JSON log events, terms in a log or, if the log entries are fields organized as space-delimited values, particular fields of each log entry. The last two lines of the command specify a name and namespace for the metric, and which filter pattern field supplies the metric’s value.

aws logs put-metric-filter \
  --log-group-name /aws/elasticbeanstalk/<your-Elastic-Beanstalk-environment>/var/log/nodejs/nodejs.log \
  --filter-name LOGIN_LATENCY \
  --filter-pattern '[timestamp, level, message = POST_AUTH_latency, latency]' \
  --metric-transformations \
  1. Generate data: To view a graph for this metric, first generate some data by logging in a few times.
  1. Graph the metric: Next, follow the directions in the preceding section for viewing graphs, but choose the LOGIN_LATENCY metric rather than the LOGIN_FAILURE_COUNT metric. Also, set Statistic to Average rather than Sum.

It might take a couple of minutes for your data to appear in the graph.


Alarms and notifications

After you start collecting metrics, you have several options for using them. As discussed earlier, you can use the CloudWatch console to graph metric data. You also can create CloudWatch alarms based on your metrics to provide notifications and respond to events.

A CloudWatch alarm watches a single metric. The alarm performs one or more actions based on the value of the metric relative to a threshold over a number of time periods. The action can be an Amazon EC2 action, an Auto Scaling action, or a notification sent to an Amazon SNS topic. To receive messages published to the SNS topic, you can subscribe one or more endpoints to that topic. For monitoring purposes, SNS endpoints could include email addresses, SMS-enabled devices, web servers (HTTP/HTTPS), AWS Lambda functions, or Amazon SQS queues. These endpoints can be used as part of a workflow that automates responses to the alarm.

Let’s continue from the earlier example of the LOGIN_FAILURE_COUNT metric and create a related alarm. The next steps describe how to create and use the alarm. For alarm creation, use either a CloudFormation template (step 1) or a CLI command (steps 2 and 3), but not both.

  1. CloudFormation: If you created a CloudFormation stack based on the devops.cfn.yml template in the Startup Kit templates, as described earlier in the CloudWatch Logs filter section, a CloudWatch alarm based on the login failure count metric was created for you. A related SNS topic also was created. You can skip steps 2 and 3.
  1. CLI command – part 1: Alternatively, you can create an alarm using the CloudWatch console or the AWS CLI. First, create a SNS topic for notifications created by the alarm. You can do this with the CLI command: aws sns create-topic –name STARTUP_KIT_DEVOPS. Save the value of the TopicArn field from the response returned by this call.
  1. CLI command – part 2: Next, create the alarm itself with the command below, replacing the value for alarm-options with the value of TopicArn returned by the previous CLI command. Most of the options are self-explanatory. In plain English, this command says to create an alarm tied to LOGIN_FAILURE_COUNT where, if there are more than 10 failed login attempts in a single 60-second time period, the alarm is triggered and sends a SNS notification to the specified SNS topic.
aws cloudwatch put-metric-alarm \
--alarm-description 'Alarm on login attempt failures' \
--actions-enabled \
--alarm-actions <your-SNS-topic-ARN> \
--metric-name LOGIN_FAILURE_COUNT \
--namespace STARTUP_KIT/API \
--statistic Sum \
--period 60 \
--evaluation-periods 1 \
--threshold 10 \
--comparison-operator GreaterThanThreshold
  1. Subscribe to notifications: For this example, the alarm sends a notification to a SNS topic. This topic is created using the same template as the alarm and the metrics filter. For purposes of confirming everything is working together, it’s easiest to subscribe one of your email addresses to the topic. In the SNS console, choose the topic name (STARTUP_KIT_DEVOPS), choose Create subscription, choose Email for the Protocol field, and then enter your email address. Check your email for the confirmation message, and then click the link to confirm.
  1. Test the alarm and get a notification: Next, use a previously created app account and try to sign in more than 10 times with an incorrect password. Check your email for the alarm notification.

After you create the CloudWatch alarm, it always will be in one of three states. When you first create the alarm, its state likely will be INSUFFICIENT_DATA because there are no data points yet. As you make login attempts that fail, the alarm transitions to the OK state as long as the sum of failed calls is less than or equal to the threshold. After the threshold is exceeded, the alarm transitions to the ALARM state, and the alarm will trigger any enabled actions such as sending notifications.

Further Startup Kit reading

To check out the other resources provided by the AWS Startup Kit, refer to the following list of published resources:

Changing the way developers manipulate media with Cloudinary

by Alexander Moss-Bolaños | on | in Startups On Air |

This post comes as part of the Startups on Air series; where the Startup Evangelist Mackenzie Kosut, goes around to different startups and learns more about who they are, what they do, and how they utilize AWS. 


Founded in 2011 in Israel, Cloudinary is a boot-strapping success story, growing organically without venture capital funding. In 2015, the company expanded internationally, opening its U.S. headquarters in Palo Alto, California.

The key to Cloudinary’s success is its ability to solve a very real problem for today’s developers: how to deal with the challenges resulting from the use of images and videos in modern websites and apps. As the need for images and video grows in importance, developers must figure out how to best manipulate and deliver this media to a variety of screens at the proper resolution for each user, while minimizing page size to ensure a great user experience.

Cloudinary has reinvented the way that media is managed online, enabling developers to optimize sites for end users who expect fast access to high-quality, high-resolution images and videos, regardless of what device they’re using or where they are located. Cloudinary’s comprehensive cloud-based image and video management solution quickly has become a preferred solution used by web and mobile application developers at major companies around the world to streamline media management and deliver an optimal end-user experience.

Cloudinary automates the entire media lifecycle. Cloudinary supports image and video upload; cloud storage; digital asset management; on-the-fly image and video manipulations; and optimized delivery to end users.

In just over five years, Cloudinary has attracted more than 180,000 developers who are managing approximately 10 billion media files. Among Cloudinary’s users are, Conde Nast, Gawker, Gizmodo, GrubHub, Indiegogo, Outbrain, Snapdeal, Under Armour, Vogue, and Wired.



Technical Recap:

“From our customer’s perspective, DevOps perspective, and customer success perspective, AWS Athena is a nice addition to our core” -Nadav Soferman, Co-founder and Chief Product Officer, @NadavSoferman

Cloudinary runs their image processing using Amazon EC2 instances with Elastic Load Balancing, while using Amazon S3 for their storage needs. Since re:Invent 2016, Cloudinary has begun using some of Cloudfronts’s newer features such as Lambda@Edge, which allows Cloudinary to run “almost arbitrary code on the edge itself” for requests sent via the Amazon CloudFront CDN. Using Lambda@Edge gives Cloudinary the capability to create varying adaptations of an image in real time without having to forward the requests to centralized servers.

Additionally, Cloudinary has begun to move its databases from Cloudinary’s own EC2 instances to Amazon Aurora, which gives Cloudinary increased scalability, uptime guarantees, and cross-region replication. Auto Scaling in Aurora allows Cloudinary to avoid provisioning excess database storage to handle future growth: “It makes our lives much easier because we have so many objects (more than 13 billion stored).”

Lately, Cloudinary has shifted towards Amazon Athena, which helps them generate sophisticated reports and insight into their customer’s use of images. Through Athena, they can run ad-hoc queries on the data they’ve gathered, and dive into the data more deeply in a variety of ways depending on their specific needs each time. “From our customer’s perspective, DevOps perspective, and customer success perspective, this is a nice addition to our core.”

Cloudinary not only uses AWS Lambda at the CloudFront CDN level via Lambda@Edge, but also for integration purposes elsewhere in Cloudinary’s infrastructure. AWS Lambda allows Cloudinary to send callbacks via HTTP or SNS, get notified of any image that’s being uploaded, and have the ability to react to it in real time. “We have a way of triggering Cloudinary from a Lambda function when the new image or video arrives in your S3 bucket, and you can reuse your own S3 bucket for enterprise purposes.” This allows Cloudinary to give their customers a lot of flexibility and scalability, including the ability to process more than 5,000 new images per second.

“We have varying use across the day given the time of day and location, and AWS makes it very easy and adaptive to our needs. We use Spot Instances when it makes sense, and Auto Scaling across multiple services. AWS allows us to do all this while concentrating on the core product, which has been a huge win.”

Interested in learning more about Cloudinary? Check out their Twitter page.

What’s happening for Startups at the AWS Summit — San Francisco?

by Rei Biermann | on | in Announcements |

Whether you are a Startup new to the cloud or an experienced user, you will learn something new at the AWS Summit – San Francisco April 18- 19.

This free event is designed to educate you on the AWS platform and develop the skills to design, deploy, and operate infrastructure and applications. Don’t miss the opening keynote offered exclusively at the AWS Summit—San Francisco featuring Dr. Werner Vogels, Amazon CTO and Vice President and a fireside chat with AWS CEO Andy Jassy.


Startup Loft at the AWS Summit – San Francisco

At the AWS Summit – San Francisco we created an experience designed just for you to help you build and grow your startup.

  • AWS Startup Loft –We are bringing the AWS Loft to the AWS Summit – San Francisco. It’s a place where startups can meet, attend educational sessions, and get in-person answers to AWS technical questions.
  • Ask a Startup Expert—No appointment is necessary. AWS Startup customers will be onsite to answer technical questions on topics ranging from Serverless to Artificial Intelligence. AWS Solution Architects will also be there to help with any foundational questions.
  • Lightning Talks featuring Hot Startups –Join us for lightning talks to learn about cool projects startups such as Branch, CloudCoreo and Metabase are working on.

Continue your learning by attending sessions, workshops, and hands-on activities and adding them to your schedule via our mobile app! Download our app to maximize your AWS Summit experience. Find the talks listed below, build your startup schedule, reference way finding maps, and learn more about our exhibiting partners. You can also provide session feedback so we can continue to improve the Summit program. Search “AWS Summits 2017” in your app store or visit


Startup Agenda at the AWS Summit – San Francisco

Date/Time Lightning Talk/Session Speaker
4/18 – 10:30am The Philosophy of Monitoring Dmitri Gaskin, Cofounder, Branch
4/18 – 11:15am Automating security in the cloud Brent Langston, Director of Platform Architecture of CloudPassage
4/18 – 11:30am Ask a Startup Expert featuring CloudPassage

Brent Langston, Director of Platform Architecture of CloudPassage

4/18 – 11:45am Taking your Company Serverless with AWS & Track

Chris Labasky Cofounder & CFO, Track

Trent Bigelow, Cofounder & CEO, Track

Alex Cram, Cofounder & CTO, Track

4/18 – 12:00pm Ask a Startup Expert featuring Track

Chris Labasky Cofounder & CFO, Track

Trent Bigelow, Cofounder & CEO, Track

Alex Cram, Cofounder & CTO, Track

4/18 – 1:45pm Zero to Full Datacenter with Ansible Steve Salevan, Founder, SPINE
4/18 – 3:00pm Startups On Air featuring CloudCoreo Paul Allen, Founder & CTO, CloudCoreo
4/18 – 4:00pm Startups On Air featuring Metabase Sameer Al-Sakran, CEO, Metabase
4/19 – 11:15am Implementing Strategic Artificial Intelligence Using AWS

Philip West, Cofounder & Head of Product, Vidora

Abhik Majumdar, Cofounder & CTO, Vidora

4/19 – 11:30am Ask a Startup Expert featuring Vidora

Philip West, Cofounder & Head of Product, Vidora

Abhik Majumdar, Cofounder & CTO, Vidora

4/19 – 11:45am Processing satellite data at petabyte scale at Mapbox Camilla Mahon, PM, Mapbox
4/19 – 12:00pm Ask a Startup Expert Camilla Mahon, PM, Mapbox
4/19 – 12:15pm VC Fundraising 101 Ryan Kiskis, Startup BD Manager, AWS
4/19 – 12:45pm Partnering and Business Development to Grow Your Startup Jim Routh, Startup BD Manager, AWS
4/19 – 2:30pm Developing an ecosystem of software to handle your life 24/7 Nic Novak, Co-founder, Magic
4/19 – 3:30pm It’s Not Them, It’s You – Security at Scale Paul Allen, Founder & CTO, CloudCoreo
4/19 – 4:00pm Data Driven from Day 1 Sameer Al-Sakran, CEO, Metabase


Cybersecurity and Amazon Redshift with Namogoo Security

by Alexander Moss-Bolaños | on | in Startups On Air |

This post comes as part of the Startups on Air series; where the Startup Evangelist Mackenzie Kosut, goes around to different startups and learns more about who they are, what they do, and how they utilize AWS. 



Founders Chemi Katz and Ohad Greenshpan come from an extensive and broad background in security, eCommerce, and machine learning. After detecting a market opportunity and researching it thoroughly, they built a minimum viable product (MVP) and met key design partners to help bring their vision to fruition in 2014. They welcomed extremely positive feedback from the market, and went on to raise $6M in their first round. From there, they grew the Namogoo team and developed their IP, which is now sold to leading companies worldwide.

Namogoo provides a session firewall technology that protects consumer-facing applications and websites against client-side threats that operate on the application layer. These client-side threats include:

  • Digital malware – Code that runs through browser extensions. Malicious software is installed on the end user’s device or hacked WiFi network that the user is connected to. Right after a page is served and during the page rendering, digital malware takes control of the session in order to “inject” content and code and leverage various monetization channels. For example, it can inject competitive products into product pages to drive the user to competitors’ websites, or it can inject advertisements (such as distracting popups, banners, and in-text ads) to monetize through views and clicks.
  • Code injection – Client-side threats inject code in order to conduct fraud activity. By using code injection, a hacker can manipulate forms on the site to obtain sensitive information and “listen” to the user’s key strokes, sending the information directly from the session to the hacker’s servers. The hacker also can inject fake phishing surveys into a website to request the data directly from the user’s device.
  • Bots – Namogoo protects websites and applications from client-side bots that run on the application layer. These bots are a form of automated traffic that use browsers to conduct their activity.

Namogoo’s technology is based on unique, proprietary IP.  It includes strong machine learning, anomaly detection foundations, and reaches extremely high coverage with a zero false-positive rate. Their technology is robust, scalable, and self-learning It works in any environment and language, and it requires no customization or manual involvement. Namogoo provides high-quality analytics and intelligence about any session and device at a SessionID and PageView resolution. This allows for advanced device and threat investigation, along with integration into different analytical tools.

Namogoo currently protects top-tier retailers and eCommerce companies globally across all platforms, brands, and geographies. Namogoo provides a holistic, application-side layer that protects websites and applications against various client-side threats that are not covered today by other solutions.



Technical Recap:

“AWS enables us to focus less on solving problems, but rather on innovation, running faster, providing capabilities, and new technologies”– Ohad Greenshpan, COO/co-founder 

Namogoo uses Amazon EC2 and Auto Scaling infrastructure for their servers, but they plan to switch to AWS Lambda and a server-less architecture soon. They store their data in Amazon S3 before moving it over to Amazon Redshift, their big data warehouse, “We are very, very happy with Redshift – we’ve done some interesting work on Redshift with AWS. Something we’re really proud of is the ability to store data for life, and we do it with relatively minimum space.”

From Amazon Redshift, Namogoo aggregates the data using the MySQL engine in Amazon RDS. This gives Namogoo quick access, which provides “a lot of robustness and speed.” Namogoo’s customer success team uses Amazon QuickSight with the RDS database to track user data. Namogoo plans to further integrate with their customers in the future via Amazon QuickSight, with the goal of sharing more data with customers in the future.

Namogoo also uses Amazon Elasticsearch Service, which allows Namogoo to take advantage of the powerful Elasticsearch APIs without having to undertake the undifferentiated heavy lifting of setting up and managing an Elasticsearch cluster manually.  All of Namogoo’s research, classification, and statistical analysis is done by moving data from Redshift to Amazon Elasticsearch Service, and is moved on either a daily or hourly basis, “Amazon enables us to focus less on solving problems, but rather on innovation, running faster, providing capabilities, and new technologies.”


Interested in learning more about Namogoo and their ways of cyber security? Check out their twitter page!

Talking with Parsec, a Game-Changer of Gaming

by Alexander Moss-Bolaños | on | in Startups On Air |

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.



Cloud-gaming company Parsec, believes that we’re entering a new phase of computing where all of our software and processing are delivered via shared resources in the cloud. They want to eliminate personal hardware and free everyone from the constant upgrade cycles required to keep up with the latest software. Parsec was started in March 2016 when the founders realized that the confluence of ubiquitous access to low-priced, powerful video decoders, plummeting bandwidth costs, and cloud investments by companies like AWS were making it possible to deliver on this vision today.

Parsec is being built to power a magical cloud gaming experience, freeing people from investing and upgrading their gaming hardware. They’ve proven that low-powered, inexpensive devices, like a Raspberry Pi, can become your go-to gaming machine connected to the cloud. The technology behind this experience is a low latency, 60 frames-per-second video streamer and low latency UDP network to make cloud computers feel like native devices.

Technical Recap:

“We rely heavily on AWS internal services such as SQS and Kinesis. Because we don’t have to develop these in-house, we can deploy that much faster.”
-Eric Nygren, Senior Engineer @_nygren

Parsec builds small services that are deployed on Kubernetes clusters and rely on Amazon SQS for communication. Each service consists of a small code base that performs a specific function. For example, one service’s dedicated purpose is to start and stop AWS GPU instances in a given region. To trigger it, users interact with Parsec’s website, which in turn sends messages to launch or terminate instances on the SQS queue, ensuring that nobody else has access to the machines or services themselves.

Users can launch Parsec’s AMI from any of the AWS regions that currently have G2 instances.  “We’re in every region of the world right now because of AWS.” Parsec’s entire monitoring system is powered by an ELK stack on an Elasticsearch cluster on Amazon EC2 instances.

Going forward, Parsec has toyed with the idea of pushing their monitoring to Amazon CloudWatch to take advantage of notifications when latency is peaking in specific AWS regions. But they haven’t decided on any moves yet nor are they too worried about it,“that’s one of the reasons why AWS is the best service for us to use, because of their infrastructure.” Parsec is confident that whatever decision they make, AWS will be there with the right tool and capacity to support their infrastructure needs.

Interested in learning more about Parsec and staying up to date with their latest endeavors in gaming? Follow them on Twitter here.


From 0 to 100 K in seconds: instant scale with AWS Lambda

by admin | on | in Featured Guests |

Guest post by Michael Mendlawy, Senior developer, Crazylister

What is the best infrastructure for processing massive amounts of requests at unpredictable times?” In this blog post, we describe what led us to ask this question and how AWS Lambda helped us answer it.

Before we dive into the nuts and bolts of the solution, a bit of background:

Here at Crazylister we help online retailers easily expand to new sales channels by removing the technological barriers. One way we tackle this problem is by giving eBay sellers the ability to easily create professional HTML product pages for their eBay listings, without writing a single line of code.

Many eBay sellers use “cross-selling galleries” in the descriptions of their products. Cross-selling galleries promote related products from the same seller, as shown in the following example.

Recently, eBay announced that it will begin phasing out “active content” from product descriptions in June 2017. This includes banning JavaScript from product descriptions, and by extension will break many existing JavaScript-based cross-selling galleries. We used this opportunity to introduce a prominent feature of our product: a JavaScript-free cross-selling gallery, which eBay sellers can add to their listings in a single click.


How does it work?

When an eBay seller comes to our dedicated landing page and enters his eBay credentials, we inject our cross-selling gallery code into each of his product pages. To do that, we use eBay’s API to get all of the seller’s product pages, insert the cross-selling gallery code into the description part of each page, and send it back to eBay.

Sounds simple enough, right? Well… yes and no.

The problem is volume. Some eBay sellers have hundreds of thousands (and some even have millions) of product pages.

Processing this amount of requests is typically handled via one of two ways:

  1. Overprovisioning – determining an upper limit for the number of supported concurrent requests and having a large enough instance ready at all times.
  2. Automatic scaling – launching Amazon EC2 instances on demand. This can be done using AWS Elastic Beanstalk and Auto Scaling.

The following table summarizes the main issues that arise from these solutions.

As you can see, these solutions pose problems in terms of response time and cost efficiency. The nature of our cross-selling gallery feature means that seller requests come in peaks. Most of the time few (if any) requests are sent. However, when a seller wants to make an update, we have to process massive amounts of requests as fast as possible.

Although overprovisioning gives us the ability to instantly start handling these peaks, we have to pay for a monstrous instance that sleeps most of the time. The benchmark that we used was 100 K product pages. Treating a single product requires about 5 MB RAM. That means that the instance should have about 500 GB RAM to support this amount of product updates at our required speed.

One type of EC2 instance closely matches this load, the r4.16xlarge. As you can see from the AWS Simple Calculator shown in the following screenshot, this amounts to over $3,000 a month!

Now, for startups in an initial stage (pre-Series A funding) that’s too much to pay for a single feature. Needless to say, we couldn’t afford it.

Auto Scaling allows us to “pay for what we use,” but launching new instances takes about five minutes, which results in an unacceptable user experience.


Overprovisioning – too expensive

Auto Scaling – too slow


Is there a better solution out there?

Guess what? We found one.


AWS Lambda to the rescue!

We used AWS Lambda in the past for other microservices in our application, and when we considered it as a solution to our problem we found that AWS Lambda offers everything we were looking for. It lets us run as many concurrent functions as we want,* and we pay only when a Lambda function is running. Additionally, the price for running a Lambda function is low. Using the same 100 K listing benchmark as before, the monthly cost totals to a mere $13.

AWS Lambda gives us the best of both worlds: unlimited computing power instantly!

* There is a cap to the number of concurrent Lambda functions that you can have running, but asking nicely for an increase from the AWS support team will get you more Lambda functions up and running than you’ll know what to do with.


How did we implement it?

We designed an architecture that allows us to handle as many requests as we want using AWS Lambda. It is divided into three layers of Lambda invocations:

  1. Orchestration Lambda function
  2. Page Group Lambda function
  3. Page Lambda function

Orchestration Lambda

This is the Lambda that starts it all. This Lambda function does several things:

  • Initializes all the required data and makes sure that the user input is valid.
  • Gets the number of page requests to be made. For the sake of reducing call times, eBay paginates product information requests. This means that in order to receive all of a certain seller’s products, we need to tell eBay how many products we want returned for each call (up to 200 products per page), and eBay responds with the number of pages to be requested.
  • Invokes as many concurrent Page Group Lambda functions as needed.

Page Group Lambda function

We bundle several pages together to be treated by a single Lambda function. This Lambda function invokes concurrent Page Lambda functions to treat each page in the page group. We do this to reduce the overhead of Lambda invocation. Yes, we can call thousands of Lambda functions to run in parallel, but the act of invoking thousands of asynchronous functions sequentially takes too long to meet our performance requirements.

Page Lambda function

Each Page Lambda function handles one eBay page that contains a number of the seller’s products. It inserts the cross-selling gallery into each product’s description, and sends the updated product information back to eBay.

This architecture empowers us to process a virtually unlimited amount of product pages simultaneously.


A few things we learned along the way

Invest time in finding the right solution, it might save you time and money later on.

AWS Lambda wasn’t our go-to solution for our feature. We had little experience with it, and our use case is probably not what Lambda functions were made for. But sometimes, if you understand the problem at hand, if you know your available resources, and if you use a little “outside of the box” thinking, you might find the most fitting solutions in places you didn’t think were relevant.

The Serverless Framework is awesome! 

We use the Serverless Framework to write, check, and deploy our AWS Lambda functions with ease. If you want to work with AWS Lambda, you want to use the Serverless Framework. Serverless does all the AWS Lambda configuration for you and lets you deploy changes to your Lambda functions in seconds. But the best thing is that it allows you to invoke your Lambda function locally, making testing as easy as it can be and development much faster.

Make sure your Lambda functions are testable.

Local invoke, for us, is the best feature the Serverless Framework has to offer, so make sure you get the maximum out of it. Invoking locally doesn’t require deploying your Lambda functions, so testing is much faster. Try keeping your Lambda functions testable separately from the rest of the feature flow so that you can use your local Lambda functions. For example, we created test inputs that had the same format as an Invoke call to make sure our local Lambda functions work exactly as their remote versions will.

Use stages for environment separation.

The obvious use case for stages is to separate production code from development code, but you can take it a step further by using different stages for different features. If you have several people working on the same Lambda function, you might want each person to deploy his code to a different stage, thus avoiding deployment override when doing final testing.


Wrap it up!

As a startup, we’re used to doing things lean, but lean doesn’t always have to be about minimum effort to get something done. In our case, the lean way led us to build a far superior solution. We started with a $3,000 sub-par solution. With the help of AWS Lambda, we ended up with an excellent implementation for a fraction of the cost.