How AWS Profits from Open-Source Software — and What It Means for Cloud Computing Startups

This article is based on reporting originally published by Firstpost and draws on publicly available information about AWS practices, open-source licensing disputes, and antitrust scrutiny as reported circa late 2019.

The Cloud Giant and the Open-Source Dilemma

Amazon Web Services (AWS) is the dominant force in cloud computing — by most estimates, roughly triple the size of its nearest competitor, Microsoft Azure, in terms of infrastructure market share at the time of this writing. Millions of people interact with AWS daily without knowing it: Netflix video streams, Apple iCloud storage, and countless enterprise applications all run on Amazon’s infrastructure.

That dominance has come with a specific and controversial playbook: identify popular open-source software, offer it as a fully managed AWS service, and leverage Amazon’s existing customer base, billing infrastructure, and sales teams to out-compete the company that built the software in the first place.

The Elasticsearch Case: A Defining Example

Elastic, a software company founded in Amsterdam, built Elasticsearch — a widely used open-source tool for searching and analysing large datasets. By 2015, Elastic had grown to around 100 employees and was already distributing its software through AWS’s marketplace.

In October 2015, Amazon announced its own managed Elasticsearch service — built directly on Elastic’s open-source code, which Amazon was legally permitted to use under its open-source licence. Within a year, Amazon was reportedly generating more revenue from Elastic’s software than Elastic itself, primarily because AWS made the tool trivially easy to use alongside its other services.

Elastic’s response evolved in two stages:

• Premium feature restrictions: Elastic began adding proprietary, paid features to its product and restricted how companies like Amazon could use them.
• Legal action: In September 2019, Elastic sued Amazon in federal court in California, alleging trademark infringement because Amazon had named its service “Amazon Elasticsearch Service” — using the exact trademark Elastic held. Amazon denied wrongdoing. The case was pending at the time of publication.

Amazon’s response to Elastic’s premium feature restrictions was to duplicate many of those features independently and offer them free of charge to AWS customers.

A Repeating Pattern: Strip-Mining Open Source

The Elasticsearch dispute is not an isolated incident. Industry observers and affected companies describe a consistent pattern that some have termed strip-mining software:

1. A startup builds and open-sources a useful software tool, often growing a community and a business around commercial support or premium features.
2. AWS packages the open-source version as a managed service, handling infrastructure, scaling, and operations for customers.
3. Because AWS customers can add the service with a single click — on the same bill, in the same console — they often choose the AWS-managed version over the startup’s own offering.
4. The startup loses revenue traction while Amazon profits from work it did not originate.

AWS’s template for this approach was established as early as 2009, when it launched a managed database service built on open-source database software rather than anything Amazon had created in-house. That service was an immediate commercial success.

MongoDB’s Licensing Counter-Move

MongoDB, a popular document-oriented database, attempted a structural defence. In 2018, MongoDB announced a new licence — the Server Side Public License (SSPL) — that required any company offering MongoDB as a managed cloud service to also open-source the entire stack used to provide that service. This was widely interpreted as a direct response to AWS’s practices, since AWS does not open-source its own service-delivery infrastructure.

AWS responded by releasing its own compatible database service — DocumentDB — built to replicate MongoDB’s API using an older version of MongoDB’s software that pre-dated the new licensing terms, meaning the SSPL did not apply.

The episode illustrated a core problem: by the time a startup changes its licence, Amazon can often pivot to an older, licence-compatible version of the code, or build a compatible alternative independently.

Why Startups Still Work with AWS Anyway

Despite the competitive threat, smaller software companies often feel they have no realistic alternative to partnering with AWS. The reasons are structural:

• Customer access: AWS’s sales force has relationships with millions of enterprises. Selling through the AWS Marketplace gives startups distribution they could not otherwise afford.
• Ecosystem lock-in: Customers who are already running workloads on AWS prefer solutions that integrate natively into the same console and billing system.
• Investor perception: Being available on AWS is often seen as a mark of legitimacy for early-stage startups.

The trade-offs, however, are significant. Startups selling through AWS Marketplace pay Amazon a percentage of their revenue. They often agree to restrictions on how they can market their products independently. Some also share customer and product data with Amazon as part of these arrangements — data that, critics argue, gives Amazon valuable intelligence about market demand.

The Convenience Moat: How AWS Buries Competitors

Beyond open-source adoption, AWS compounds its advantage through user experience design. Between 2014 and late 2019, AWS grew from roughly 30 services to approximately 175. Each new service is integrated into the same management console, the same IAM permissions model, and the same monthly bill.

Adding a native AWS service is a single click. Integrating a third-party competitor’s tool running on AWS requires additional configuration, separate billing, and more complex identity and networking setup. That friction disadvantages even technically superior third-party products.

AWS has also been accused of bundling discounts — making its own services cheaper when customers commit to a broader AWS spend — that make competing on price alone extremely difficult for independent software vendors.

Antitrust Scrutiny and Regulatory Interest

By late 2019, AWS’s practices had attracted attention from US regulators and lawmakers:

• The House Judiciary Committee, as part of its broader investigation into large technology platforms, sent Amazon a letter in September 2019 specifically asking about AWS’s competitive practices.
• The Federal Trade Commission (FTC), which was also investigating Amazon more broadly, was reported to have contacted AWS competitors as part of its inquiry.

Several affected companies were reportedly discussing whether to file formal antitrust complaints. The core allegation is that AWS uses its infrastructure monopoly — its control of the underlying computing layer — to distort competition in the software markets that run on top of that infrastructure.

AWS’s Business Context

It is worth noting the financial stakes. AWS generated approximately $25 billion in revenue in 2018 and was Amazon’s most profitable division by a significant margin, effectively subsidising Amazon’s lower-margin retail operations. Jeff Bezos described AWS as an idea “no one asked for” — it originated from Amazon’s internal need to standardise its own computing infrastructure in the early 2000s, after which Amazon recognised the same need existed across the broader market.

Companies such as Airbnb, Netflix, and General Electric became major AWS customers, renting computing capacity rather than running their own data centres. This scale gives AWS a cost and reliability advantage that is extremely difficult for any single startup to replicate.

What Open-Source Maintainers and Startups Can Do

The situation has prompted the open-source community to rethink licensing strategy. Options that have been explored include:

• Copyleft-style cloud licences (such as the SSPL) that require cloud providers to open-source their entire service stack — though these are contested and may affect OSI open-source classification.
• Open-core models that keep the most valuable enterprise features proprietary, while open-sourcing the core — though Amazon has demonstrated willingness to re-implement proprietary features independently.
• Avoiding open-source entirely for commercially sensitive components, as Todd Persen (quoted in original reporting) chose to do when founding a new company specifically to eliminate the risk of AWS adopting his work.
• Building deeper integrations with AWS that create customer switching costs — though this deepens reliance on the platform.

None of these approaches is a complete solution. Each involves trade-offs between community growth, commercial protection, and platform reach.

Key Takeaways for DevOps and Platform Engineers

• When evaluating managed AWS services built on open-source projects, be aware that the upstream project maintainer may receive no revenue from your usage.
• If you are building infrastructure tooling, your open-source licence choice has direct commercial consequences — particularly with respect to cloud provider adoption.
• The regulatory environment around cloud platform dominance is evolving; antitrust actions in this space could affect service availability, pricing, and API compatibility.
• Distribution through AWS Marketplace comes with real revenue-share and data-sharing costs that are not always prominently disclosed.

The broader debate about whether AWS’s practices constitute anticompetitive behaviour under US law remains unresolved. What is clear is that the open-source model — which powered much of the modern cloud ecosystem — is under structural pressure from the very platforms that benefited most from it.