Transcript of AWS re:Invent 2024 - Scaling on AWS for the first 10 million users (ARC201)

- Good afternoon. I'm Christine. I'm a senior startup solutions architect here at AWS.
And I'm joined here by my manager, Skye Hart, who is also in the startups team as well.
Skye and I talk to a lot of different startups about scaling. It's a very common challenge that we see in the startup space. So we're really excited to be kind of talking and walking you through some common architecture patterns and guidance on scaling on AWS for your first 10 million users.
So let's set the scene here. Let's pretend that Skye and I are startup founders and we want to launch an application starting from scratch.
We don't really know how we're gonna execute, but we want to be able to serve 10 million users, right?
So how do we wanna do that? So first, what's important to do first is we want to first define what we mean by an application, right? It could mean a lot of different things. If you're in a larger company, for example, an app could be one product in a suite of products. It could be a startup's entire product.
And so an app could really just be almost anything that you could think of.
So in our case, in our scenario, for the context of this session, we will be talking about an application as a three-tier web application. So think of something like a frontend.
You have a user that can interface with something in a mobile app, or a browser.
You have backend to, you know, have all of your business logic there. And then you have a data storage layer to store all of your data. So for many of you, again, this may not be the application that you're building out right now, or that you're working on right now, but, you know, hopefully, there are some repeatable patterns that you can apply to your own businesses and ideas.
Now, before we continue, it's important to acknowledge current technology trends.
So the technology landscape is always changing, right? Now frontend frameworks use JavaScript.
There's full-stack frameworks that exist now to make development easier. And we see a lot of startups move into the cloud, or more managed services, instead of the self-managed DIY infrastructure.
And, obviously, with, you know, the internet and social media, right?
There are applications that could go viral. And so we need to be able to account for rapid scale in not just days, but also in hours.
Now, no architecture is designed for high scalability on day one, but we'll try.
So it's really important to get into this mindset that your first architecture isn't going to be the one.
So the first architecture that you build out may not necessarily be a part of your final production architecture one year down the line, two years down the line, so on and so forth, right? So we get into this cycle of building, measuring, and learning, right? So we may start out with an initial architecture, we may measure out, or monitor how that architecture is based on, you know, our users feedback, et cetera.
And then we learn from it, and then we continue to make changes into our architecture. So it's just a continuous cycle of improvement.
And so you'll see later, we'll start with one architecture and build and iterate through as we scale.
So let's start from day one, right? We know two things so far. We know that we're going to build a three-tier web application, and we have this mindset of, you know, we're going to build now, improve later.
So day one, right? Is probably just me and Skye using it. Maybe we'll have, like, one or two beta testers, you know.
We're not really accounting for a lot of traffic at the moment, right? So now let's kind of dive a little bit deeper, and think about how we're going to build it. So instead of just running a frontend, backend data store on one large instance, right? We're gonna think about decoupling it. So first, we're gonna start by decoupling the frontend with the backend. So now let's take a look at how we would start thinking about the frontend. So in the past, what you would have is people starting on EC2, right? So you'll have EC2 hosting a web server.
Maybe you put in an auto-scaling group, right? To scale as you meet demand.
Maybe there's a shared storage layer, an elastic load balance, right? To distribute traffic efficiently.
And then, lastly, maybe a CDN, right? CloudFront to help speed up for caching to help speed up that loading page. Now, as we saw earlier, right?
We have this shift in popular frameworks. So how do we improve the developer experience and align that to the frontend technology, right? And that's where we see an emergence of purpose-built services and tools for frontend hosting. So that's where Amplify Hosting comes into play. So Amplify Hosting is a serverless service.
So you don't have to worry about managing any underlying infrastructure, and all you really have to do is worry about writing your code, and it'll build and scale to meet your needs and requirements.
And so the developer experience then becomes much better aligned because of these deeper integrations with these modern frontend frameworks. And it's really easy to get started with Amplify Hosting.
All you really have to do is connect to your repository. So if you're using something like GitHub, for example, configure your build settings. So, for example, if you want unit testing, that's something that you can configure in your build settings, and then voila, Amplify will deploy your application without any heavy-duty management. And that's really all it takes to run frontend at scale.
Now, here at AWS, we're always working backwards from the customer.
So developers in this case, right? And so we actually built out a set of Amplify Hosting features based on the developer feedback and experience that they're looking for, right?
So you have access to branch deployments, for example, atomic deployments, and you can't really do that with, you know, just a static webpage hosting on S3, for example, right?
So, again, we see this emergence of purpose-built frontend hosting, so.
A lot of early stage startups that I see use Amplify.
Now, Amplify Hosting supports these three different types of applications, right?
So we have client-side rendered. So think of, you know, an application that's loaded on the client's browser. So something like a React app, for example.
Server-side rendering, right? So server-side rendered applications are applications that are rendered on the server before being sent to the browser. So using a framework like Next, for example.
And, finally, static site generator applications, right? So static content that we see that could be used, that could be hosted, right? In tandem with, like, a CDN, for example.
So now that we've talked about the frontend, right? What about the backend? What should I use to host my backend?
And as you can see, we do have several options for compute, right? We talked about EC2, which is just our virtual machines in the cloud. We have our container ecosystem, right?
Amazon ECS, EKS for Kubernetes, and Fargate. And then, finally, we also have AWS Lambda, which is a serverless compute option, basically, for event-driven architectures.
So there are a lot of different options, right? So how do we choose, right? How do we know what is best?
So let's dive a little bit deeper there.
Well, now when it comes to evaluating the compute options, you know, there's a lot that you can do with just EC2 as a backend, right?
A lot of people do do that to start off, but as you can see, it becomes pretty apparent that there are downsides, right?
You're essentially putting all of your eggs in one basket, right? You're saying that all of the backend can be run on the singleInstance, and that's it. While that does work, right?
There is failover challenges that you'll see, redundancy challenges.
If you're putting your database in there as well, right? Then you can't scale those individual components.
And so maybe your backend might overwhelm your data. Your data tier might overwhelm your backend, right?
And so there are a lot of different things that become pretty apparent when it comes to just using good old-fashioned EC2.
So apart from all of that too, right? Then management of the instance also becomes a challenge, right?
It might be tedious as you think about scaling up and down. You could go into a larger instance size, right?
But, again, you have redundancy challenges there. And so our guidance is to make use of managed compute for your backend, and managed databases for your data tier.
So then how do we choose again, right? Like, EC2 might not be the best option.
What about ECS/EKS, right? That's our container ecosystem, right?
So there's a lot more considerations to think about there too, right?
You have to consider how to configure applications, control scaling, right?
Fargate, what about Fargate? Fargate is a great service to use for those who do not wanna worry about managing servers, right?
And then we have Lambda, right? So maybe you just want to focus on your code.
You wanna run any code without provisioning, or managing infrastructure. And as we dive a little bit deeper here, what you can see is, you know, your more opinionated services are at the top, and your less opinionated are at the bottom, right? So what that really means is as you go down this list, there are more and more things that you have to start thinking about when it comes to managed compute.
So, Lambda, when you look at Lambda, right? All you really have to worry about is the application code, but then when you go down to Fargate, ECS/EKS, and EC2, you find that you have to take on some more tasks as you continue going down.
So what's the best place to start, right? So our guidance is to kinda start around that midpoint.
And so we're suggesting that, you know, we're gonna go with Amazon ECS, which is our Elastic Container Service, and it's our fully managed container orchestrator.
It's integrated with AWS Services, as well as third-party tools like Docker. And it makes it easier for teams to focus on building the application rather than the environment itself. And you can use EC2 instances, or Fargate as the underlying compute. So, instead of EC2 instances, we are going to be using Fargate. So, again, Fargate is a serverless compute engine.
So again, you don't have to worry about, you know, managing any servers. All you have to do is really focus on building your application. And you don't have to worry about provisioning, or configuring, or scaling groups of virtual machines with Fargate.
Fargate is really designed by, we call them Fargate tasks, right?
So a task represents a singleInstance of a running container of how you want to run your application, right?
So a singleTask is just a singleInstance. So you don't have to worry about, you know, allocating specific number of instances when it comes to Fargate.
And so all you really have to worry about again, is just the overarching, you know, compute and memory that you need per task based on your environments.
So putting it all together, right? We have ECS as our fully managed control plane, and we have Fargate as the underlying compute. So again, I don't really have to worry about patching, or upgrading any AMIs, right? It's secure by design and it's really easy to auto scale.
So this is one aspect of the backend, right? What about exposing the business logic to the frontend, right? So we have a couple of different options, right? When it comes to building an API, right?
So the most common one is API gateway, right? It's purpose-built for REST APIs.
We have the Application Load Balancer, which is really just a layer seven proxy.
And we have AWS AppSync, which is more for hosting GraphQL based APIs.
Now it really just depends on, picking an API really just depends on what your requirements are. And so we're not really gonna go and pick a specific API fronting service today, but this is kind of just a good cheat sheet, and good discovery of how maybe you would want to pick an API when it comes to building out your application. So if you want something like WebSockets, for example, throttling, you know, you can go with API Gateway. If you have just a single action, right?
A single API method maybe go with Application Load Balancer. How many requests you're gonna have.
How many requests do you need to handle, right? These are all, like, questions you can think about when it comes to picking an API fronting service.
So let's put it all together for now, right? In the frontend we have the Amplify Hosting service for frontend, and then for the backend we're using AWS Fargate, right? And so far everything's looking great, everything is fully managed, and you don't really have to worry about any operational overhead.
There's built-in scale. So you don't really have to worry about how you're going to scale your application, and it's really aligned with the developer experience overall.
So now what about the database, right? And so the big question really is am I gonna go with a relational database, or a non-relational database, right? There's pretty much a service for every single database you can imagine right now, right? You have non-relational, NoSQL. There's time series databases, graph databases, so, you know, which database should you use? So our guidance is to start with SQL databases.
Now, why start with SQL, right? So, SQL is well-established, and a well-known technology, right? A lot of, you know, there are a lot of college classes, a lot of material and information already existing in, you know, the community, and you're really not going to break your SQL database with your first, like, million users, right? And so there's just this ease of getting started and still being able to serve, you know, your millions of first millions users.
Now there are gonna be people who will say, you know, a relational database might not work, right?
I might have too much data. I'm gonna have way too much data to think about putting us in a relational database. Now some of you out here might be saying, aha, you said massive amounts of data, that's me.
We're gonna have way too much data. Relational database is just not gonna work. We need to optimize today, right?
Now, what do we mean by massive amounts of data, right? Are you gonna have multiple terabytes of data in year one?
Are you going to have a highly data intensive workload, right?
If that's the case, okay, you might need NoSQL, but, again, going back to the cycle of build, measure, learn, right?
You can always think about optimizing your architecture over time, right?
So unless you know for a fact that you're gonna have multiple terabytes of data within that first year, you know, you don't really need to think about, you know, a non-relational database right away.
Now why else might you need NoSQL databases, or non-relational databases, right?
So things like super low-latency applications, for example. That could be, you know, something like high-frequency trading, for example. That's something that, you know, you might need a non-relational database for, but that's a very specific type of workload.
Again, there are applications that do require super low-latency, but 99% of the time you may not need a super low-latency application.
Other times you might need NoSQL, or non-relational databases, right? If you have highly non-relational data, or you have data that's essentially schema-less, right? Then you might need to think about a non-relational database, but, again, these are very specific and unique use cases. So unless you absolutely know that you need something like this, then the guidance really here for us is to start with SQL databases.
And the SQL database that we're gonna be using today is Amazon Aurora. So Amazon Aurora is a relational database that supports MySQL and PostgreSQL. It's durable, which means that the data is stored across three availability zones within a region, and it is a fully managed service.
So, again, you don't have to worry about, like, patching, for example, database setup, backups, right?
And so this is a really, really great service when it comes to a managed database service.
Now more specifically we will be using Amazon Aurora Serverless v2.
So we're always iterating and improving our services. So we're going with Amazon Aurora Serverless v2 here.
Basically, what it means is that it actually decouples the compute from the storage and the database cluster, so you can actually scale your compute and your storage respectively, and can scale based on your capacity demands and your application needs.
So now let's put this all together, right? So we have Amplify Hosting at our frontend.
We have AWS Fargate as our backend, and then we have Amazon Aurora Serverless v2 as our database. So this stack can actually take us pretty far without having to think, or manage a lot of upfront, like, infrastructure, right?
So, you know, you don't have to worry about, you know, scalability that much, right?
There's already a lot of built-in scalability, or knobs to turn to help you with scaling.
And there's high availability, right? Multiple. There's Multi-AZ in a single region.
And so from here we can go pretty far.
So once we've built our application, right? We've tested it, you know, maybe we have a beta tester, or two, right? Maybe word of mouth travels and we get to hundreds of users, maybe even thousands of users as time goes on, right?
And our application can really take us pretty far.
Everything's looking good until maybe we hit 10,000 users, and that's where maybe things start to go wrong.
And so I'm gonna pass it to Skye now to talk about how to scale from here.
- Thank you very much, Christine. Can everyone hear me too? Awesome. Hi everyone, my name is Skye Hart.
I'm a solutions architect manager here, and I'm gonna take you from 10,000 users to 10 million users right now, so with that.
So, Christine did a great job laying out the fundamental elements of the initial architecture, and what we're gonna start talking about, and I love being handed the mic when things start breaking, but what commonly happens and patterns there?
So a lot of you might not know that amazon.com was originally monolithic. And so we have seen this in our own business as things start to go wrong what happens. Actually, one of the major issues we saw with amazon.com originally was there were a lot of new product features complicating it, and the developers started to kinda step over each other, and code refactoring, things like that. Second, poor performance in one part of the application affecting other parts of your tiers, you know, high volumes of database queries affecting frontend, that sort of thing. And then, of course, an increasing amount of data.
This architecture that we have laid out just won't be sustainable through the scales, and through the growth phases.
So just like Christine did, I'm gonna kind of break down the parts from frontend, backend, and data storage tier for you now, but before I do that, I need to talk about something that's very important. You can raise your hand in the audience, but if you're building an application, has a customer ever said to you, your app's slow, there's latency issues, throughput issues.
Your internal customers are upset with you. Your external customers are upset with you, and why? And so I can't even tell you how many times a customer has told me why is this happening, what is this? And I ask them, can I see your logs?
And they don't have those. So very fundamental step before we start scaling is to talk about observability and monitoring every facet of your application. Now here at AWS, we have plenty of services that can help you through your observability and monitoring journey. I'm gonna mention a couple right here. CloudWatch and X-Ray. X-Ray more end-to-end tracing for your entire view of your entire application. CloudWatch is your best friend. And so every single time you're setting up alerts for logging, dashboards, performance, that sort of thing, is going to be critical for you in every step.
Now tuning for scale, we're gonna talk about data insights. And this goes back to that customer saying, what's going on?
Now I have the dashboards, now I have the visibility. Turn these on before you start scaling because you'll be able to show this.
I think a lot of times customers will come to us, and they'll say, I'm just gonna add more compute, or I'm gonna add an additional node. And, like, that's just a stop-gap.
So when we can start to tune and really understand what's going on, we can address those issues in a better light.
And we're not just adding more money to the problem, but we're actually addressing the inherent issues underlying your application.
Now I can start getting into the components. I'm gonna start with the frontend. I actually had the pleasure of talking to the Amplify Hosting team, and I kind of said, where are your stop-gaps? How far can Amplify go?
Where are the breakpoints of Amplify? And they said, "Theoretically there's not." And a lot of times the reason is it's because it's built on a service called CloudFront, which is CDN, and it's built on 550 points of presence around the globe.
And what's so powerful about CloudFront, it's been here for over 15 years, it's a really substantial thing, and it can bring your information closer to your customers globally. We do have plenty of global customers that we work with there. Now what can you control? What can't you control when it comes to Amplify and scale?
Honestly, it handles a lot of it for you to help with autoscaling, and things like that. There are some things you can tune.
You'll see in my image here, I'm tuning the cache hit ratio, and you can configure, sort it, so things like that.
What images are being cached more commonly for your customers to help improve performance?
Of course, tuning your frontend code, and that sort of thing as well, but the benefit is it's managed, it will will scale up for you. Now, data storage. I was just telling you I was a prior database engineer for a long time. Scaling is going to be critical, especially, at this stage you're having more data than ever before.
There's a couple different ways we're gonna scale. We're gonna scale vertically. We're also gonna scale horizontally. Talking about vertical scaling, I've used Postgres RDS my entire life, and I'd say what's powerful about Aurora is it actually decouples the compute in the storage layer. And the benefit there is that because of that decoupling, it will modify and automatically detect and scale those both separately. So the way it does it is pretty powerful as well.
Now, there's limitations like any other database. Aurora is built off of these things called ACUs, and the lower tier of that is gonna be one ACU, two gigabytes of memory, and then the maximum is gonna be up to 128 ACUs, but you can have multiple read replicas, and I'll get to that in a second. So this is the high for one node, but you can also fan-out.
Scaling factors. So what is it actually looking at? What is it measuring? How does it know?
It measures constantly a number of different insights including CPU usage, memory usage, network usage.
Not only to scale up, but also to rope it back and scale down. So peak windows, Black Friday sales, that sort of thing.
You need it to scale out, and then you can scale down. And it identifies those patterns so you do not have to, which is very powerful. Now, of course, there's gonna get to a point where we can't scale vertically anymore and we need to scale out. So it will house those up to 15 read replicas. There's a really cool tier zero and one system that it utilizes that had the same as the read and the write primary. And what happens there is you can actually segment out, like, let's say you have internal facing databases that you don't use as much, or it's business intelligence, it's not as mission critical, versus, like, the more important databases that are external facing, and things like that. So you can size those differently as well.
Also, Aurora is Multi-AZ, huge uptime. Think about resiliency, durability, that sort of thing as well.
Now the next thing we're gonna add for Aurora as we start to scale out, and I'll piece this together in just a moment here, are proxies. Proxies have been around for a long time. We have RDS Proxy, and what happens is you start to add, like, 15 read replica clusters, and there's a ton of open connections that you're leveraging right now. And so we need a way to, like, take those and consolidate them and improve the performance. And that's where we would put an RDS Proxy, in between the application and database tier, so.
There's a lot of benefits to using these. Now I'm gonna piece that together so you can see it in real time. In the architecture you'll see the RDS Proxy.
I have my primary and then I have multiple read replicas attached to the backend, or sorry, the data tier.
So we can continue to scale this out, but, ultimately, after 15 read nodes we already have the amount of ACUs is kind of at a maximum, and so we need to add additional things too.
Now, as a database engineer prior to coming to Amazon, the best database queries are the ones you never need to make often, which is how can you automate these a lot? And a lot of the times that's through caching.
So, Amazon ElastiCache is our dedicated service for this. There's two options, Memcached or Redis.
You can scale this up. There is a little bit more configuration. We're gonna be talking a lot about managed services.
So the only catch here is that ElastiCache does have some manual configuration that you'll have to put in here, but it also has self-healing practices as well, so, it's really powerful, ElastiCache.
So now piecing it all together, I'll have ElastiCache, which is off the database. I'll have a RDS Proxy in between my application and my backend here. And then you can keep seeing those read replicas come out. So I'm able to handle a lot more traffic, and a lot more scale for data. Now to summarize these three main methods, scale vertically, you can increase the node size. You can scale horizontally, which requires minor application.
And then, of course, you can really identify, take the time to understand what are the queries you're making the most and cache those closer to your end users.
So those are three primary ways we can scale up the data tier. Now let's talk about the backend for just a moment.
So, Christine managed to message Fargate prior, and what happened here is I actually worked with a customer who was, like, huge Kubernetes shop. They were super passionate about Kubernetes, but they needed to migrate their application really quickly. And the customer is actually cited saying that the fastest way to deploy is Fargate because it takes on a lot of these managers tasks.
And then once they scaled up, they were able to achieve 600% scale from Fargate. Once they scaled up, they actually went back to Kubernetes.
So from a quick deployment, easy configuration, self-healing, auto scaling, that sort of thing. And when we say self-healing, basically, it identifies specific tasks that are unhealthy.
and then can go and actually replace these. So for those of you who are really familiar with Kubernetes, great services, but you have to manage a lot of the underlying configurations, and that control and scale, probably you won't need until you're a little bit further along in your architecture. And we'll talk about that a little bit later.
Okay, now scaling the backend here, these are three different components, and ways that we can scale out.
Reducing the slow database queries, profiling code, you can use other similar tools like CodeGuru, and things to automate those processes. And, of course, caching when possible.
So great, we hit 100,000 users. We are drumming up excitement here and it starts to go viral and we are able to achieve one million users, still just with that three-tier using and leveraging read replicas, and that sort of thing. So at some point we will outgrow the complexity.
You can imagine one million users, the application complexity, feature growth, think about amazon.com again, there's shopping cart features, profiling, personalization. All these things you're starting to do, and it's going to necessitate understanding different sorts of departments are going to be using these. Database rights, you only have one primary. That's gonna start to become a bottleneck.
And then we're gonna have to start to talk about purpose-built databases. And then, of course, operational tasks weighing down with the monolithic application, everything is coupled and it can get you far enough, but 10 million users, we're gonna wanna start to think about microservices. Now there's a lot of talks that are going on at re:Invent that can kind of dive in if you're curious about microservices versus monolithic, but I'll just summarize a couple ways that we advise customers to start thinking about breaking up and decoupling your application into microservices.
The two primary ways are data domain mapping, and business function mapping. Data domain mapping looks at your databases and says what are commonalities in your data, and structures, and schemas, and how do I separate it and parse it out that way?
The second one is business function mapping. That's the marketing department different areas of your business and organizational will have different patterns and structures there. And so it's very interesting, too, 'cause you'll start to see very common patterns.
So, like, the Ubers of the world, Amazons of the world, will have thousands and millions of microservices that will have all the separate patterns that we start to develop.
Another way that's gonna be really critical, too, is database federation. So if you look at my VPC here, I have a couple forums, database, user database, product database, and you can start to see myself splitting up the relational databases into the different functions, so.
It'll help in terms of queries. It'll help offload of that and things like that with the different schemas and tables that you'll be leveraging. So really critical. I think people often forget about this component.
Now, shifting functionality to NoSQL, Christine mentioned in the beginning we get a lot of like, should I be using DynamoDB for this?
It's pretty typical. We see relational databases and then that starts to transform into NoSQL.
You need hot tables. You have tons and tons of scale, petabytes of data that are coming in. You'll also see a shift in moving towards more purpose-built databases. So maybe you have a key store, or you have a time series database for IoT data, and you have a mixture. You'll also see a trend of moving towards data lakes, data meshes, more unstructured and structured data, especially, with the rise of AIML apps, and stuff like that is it will not be one size fits all, nor should it. There's purpose-built databases for a specific reason, and you'll see kind of a combination of those multiple different types. Now we're gonna start to break up the backend here. I always start with the data you'll notice, and then the application will follow suit. So you can split it into new federated services. Revisit which managed compute best aligns for you.
Like I talked about my customer who started with Fargate, ended up with EKS, it was what the team was most familiar with, or Lambda in a serverless architecture as well. Explore what business logic can be moved to internal services.
And I'll be talking about sync to async in a little bit here.
So thinking asynchronously, you'll see my synchronous command, which is a pretty common pattern. You'll see where the client makes a call to service A, makes a call to service B, and that it takes time to come back. Service B makes the call to A to the client versus thinking asynchronously, which takes more configuration and time, but you'll see the client makes a call to service A.
It calls back before it even has to go to service B from that, so. I'd say another way to think about this, too, you have an order service, and an invoice service and you can kind of see the trend here on how it calls, and how we can start to think in an asynchronous light. Now, I think about this switch in this transition to your business all about opportunity cost. It definitely takes more time to understand the patterns and understand the communication and understand and change the configurations on this, but it will really help you in the long term in moving towards more of these event-driven architectures.
How do I do that? What services do I do that with? You'll see four on the screen here that we mention.
One, Amazon Simple Notification Service, or Amazon SNS. Amazon Simple Queue Service, Amazon SQS, Amazon EventBridge, which is fundamentally a bus. And then Amazon Kinesis Data Streams, which helps with fast-paced moving data. How do I pick?
You might be wondering. We have another cheat sheet here for you. You'll see massive throughput, ordering, that sort of thing.
Kinesis Data Streams is pretty powerful. The whole Kinesis family, very good for streaming data, and that sort of thing. Amazon SNS, minimal fan-out, buffer requests. Amazon SQS, and then one to many fan-outs I would use EventBridge. And you'll see sometimes that these will be used in combination and there's a lot of crossovers, and you might be wondering how do I use this? But you'll see that there are definitely more purposeful services in this category.
So you might use a combination, or you might use one that's more purpose-built for your specific architecture.
Now I'm gonna show you a really scary slide that should not dawn to you. This is pretty common. This is not a real customer example, but this is a pretty common theme that we start to see. And you see it overwhelms, but walk through it with us is that we start with the frontend, go to the backend, and then we start to fan-out in the different purposeful databases, and communication systems, and EventBridges. And what's gonna happen is at this point your architectures are gonna be pretty unique based off of your business requirements, based on your needs, whatever your product you are developing is.
And we are at 10 million users, we did it. So thank you for bearing with me. It's not done yet.
Usually it's 10 million. Like I said, at this point, what we typically see with customers is a lot of difference, a lot of uniqueness. You reach 10 million, you're gonna have different needs for those internal microservices.
You need to be deeply analyzing again to circle back on that point your entire stacks performance, and continue to find areas to iterate and improve on. And then you're gonna start probably switching to self-managed compute.
And then, of course, evaluating how to cache all of these tiers. So to infinity and beyond.
In closing, I wanna leave you with three points that we chatted about today. One, we are in a lot better place.
My colleague, Chris, was giving this presentation for 13 years now. And you can say that the iterations, and the products, and the features that we are constantly developing to improve, there's built-in scalability that we can leverage more resources to split and decouple the compute and the storage so you can iterate that way.
The second is bulk of scaling wins come from doing less. It's leveraging our fleet of managed services so that you can focus more on the application development, the co-development, and less time on the underlying infrastructure tuning, and self-healing, and that sort of thing. And then the third is evaluating refactoring cautiously.
Federation, pick your easy wins that you can do. Look for best case purpose-built technologies, and that should help you along the way, and constantly test and iterate. So, in closing, I wanna thank you all so much for coming to our presentation today. And thanks for coming on the journey for 10 million users. And I hope you have a wonderful time at re:Invent this week.
(audience applauding)