significantly over time as we experimented with different ideas and iterations. We could not foresee with certainty what those programs would eventually look like, let alone whether they would succeed, but they were pushed forward with intuition and heart, and nourished with optimism. Intuition, curiosity, and the power of wandering FromveryearlyoninAmazon’slife,weknewwewantedtocreateacultureofbuilders–peoplewhoarecurious, explorers. They like to invent. Even when they’re experts, they are “fresh” with a beginner’s mind. They see the waywedothingsasjustthewaywedothingsnow.Abuilder’smentalityhelpsusapproachbig,hard-to-solve opportunities with a humble conviction that success can come through iteration: invent, launch, reinvent, relaunch, start over, rinse, repeat, again and again. They know the path to success is anything but straight. Sometimes (often actually) in business, you do know where you’re going, and when you do, you can be efficient. Put in place a plan and execute. In contrast, wandering in business is not efficient … but it’s also not random. It’s guided – by hunch, gut, intuition, curiosity, and powered by a deep conviction that the prize for customers is big enough that it’s worth being a little messy and tangential to find our way there. Wandering is an essential counter-balance to efficiency. You need to employ both. The outsized discoveries – the “non-linear” ones – are highly likely to require wandering. AWS’smillions of customers range from startups to large enterprises, government entities to nonprofits, each looking to build better solutions for their end users. We spend a lot of time thinking about what those organizations want and what the people inside them – developers, dev managers, ops managers, CIOs, chief digital officers, chief information security officers, etc. – want. MuchofwhatwebuildatAWSisbasedonlisteningtocustomers. It’s critical to ask customers what they want, listen carefully to their answers, and figure out a plan to provide it thoughtfully and quickly (speed matters in business!). No business could thrive without that kind of customer obsession. But it’s also not enough. The biggest needle movers will be things that customers don’t know to ask for. We must invent on their behalf. We have to tap into our own inner imagination about what’s possible. AWSitself–asawhole–isanexample.NooneaskedforAWS.Noone.Turnsouttheworldwasinfactreadyand hungry for an offering like AWS but didn’t know it. We had a hunch, followed our curiosity, took the necessary financial risks, and began building – reworking, experimenting, and iterating countless times as we proceeded. Within AWS,that same pattern has recurred many times. For example, we invented DynamoDB, a highly scalable, low latency key-value database now used by thousands of AWS customers. And on the listening- carefully-to-customers side, we heard loudly that companies felt constrained by their commercial database options and had been unhappy with their database providers for decades – these offerings are expensive, proprietary, have high-lock-in and punitive licensing terms. We spent several years building our own database engine, Amazon Aurora, a fully-managed MySQL and PostgreSQL-compatible service with the same or better durability and availability as the commercial engines, but at one-tenth of the cost. We were not surprised when this worked. But we’re also optimistic about specialized databases for specialized workloads. Over the past 20 to 30 years, companies ran most of their workloads using relational databases. The broad familiarity with relational databases amongdevelopers made this technology the go-to even when it wasn’t ideal. Though sub-optimal, the data set sizes were often small enough and the acceptable query latencies long enough that you could make it work. But today, many applications are storing very large amounts of data – terabytes and petabytes. And the requirements for apps have changed. Modern applications are driving the need for low latencies, real-time processing, and the ability to process millions of requests per second. It’s not just key-value stores like DynamoDB, but also in-memory databases like Amazon ElastiCache, time series databases like Amazon Timestream, and ledger solutions like Amazon Quantum Ledger Database – the right tool for the right job saves money and gets your product to market faster.
Amazon Shareholder Letters 1997-2020 Page 95 Page 97