Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Eoin: AWS is the leading cloud provider today, but there is competition and with AWS's popularity, there are plenty of haters and also lots of valid criticism as well. There's a lot about AWS that we love, but there's always room for improvement, so today we are going to reveal our top nine improvements that can catapult AWS to the next level. I'm Eoin, I'm here with Luciano and this is AWS Bites. What is your list of improvements?
Luciano, I'm dying to hear what your list is, but I want to get mine off my chest first. If I could sit down with Adam or Werner today and present my wishlist, what would I say? I think the number one thing is probably hard billing limits. And what I'm talking there about is preventing people from major bill shock by allowing us to limit API requests once you hit a budget. So let's say you set your budget, then every time you make an API request or have something running, AWS is clocking up the bill in real time.
And then once you hit that budget, you suddenly get throttled, rate limited, just as if you hit a quota. There are other APIs that do this. I think a lot of people have just experimented recently with the open API, and you get an API key, you get a budget, and once you reach that budget, it's capped. Suddenly your API requests are denied. I think something like that would be nice with AWS. Of course, they can still allow you to play with the free tier until you hit those limits too.
So that's number one, and I think that would work well for AWS in the long run. It's probably a lot of engineering to implement a feature like that. It might result in a bit of lost revenue, but I think ultimately it would bring more people to AWS and increase the trust relationship between AWS users and the company. Number two is much faster deployment times. And this is something that I think can really make developers' lives easier.
And we're talking about APIs that have control plane actions, creating instances, creating databases. Every speed improvement in those things matters. Creating load balancers and registering targets and load balancers, all of that stuff takes developer time. Developer time is a really valuable resource. CloudFormation speed as well. I've talked about this quite a few times, and I'm hopeful that it will improve over time.
But the sooner deployment time gets closer to zero, the better off we'll be. I've heard a lot of people asking for more consistent coverage for CloudFormation and X-ray as well. So I think there should be like a checkbox of things that teams need at AWS before they can launch a new service. One is complete and consistent CloudFormation support, and the other one is X-ray support. So we've seen... I think things have gotten a lot better.
CloudFormation support used to drag a lot behind new feature releases. I think largely most services launch with CloudFormation support these days, but there are still some gaps. And there's some weird ones, like you haven't been able to tag a VPC endpoint in CloudFormation for many years, and it's still an open issue. I don't know why. The fourth one on my list, so my second last one, and it was hard just to limit it to five, is easier multi-account management.
So we do a lot of kind of setting up AWS landing zones and best practices and all of the account structure, organizational units, service control policies, and then like templates for each account and things like governance and security. And then you have to manage multiple accounts, and you have our AWS organizations, which is an umbrella for all of that, but it's not really easy to see everything in one place.
And when you need to share things between accounts, it has to be done very explicitly. On the other hand, Azure has a much different approach where you can structure lots of different teams and resource groups and everything within different subscriptions in an Azure account. So you don't have this kind of scatter of individual isolated accounts. Individual accounts are great for isolating security boundaries and quota boundaries, but it becomes difficult to manage them.
My favorite tool for actually managing multiple accounts and deploying things to multiple accounts is OrgFormation, which is an open source project, a bit like CloudFormation and based on CloudFormation, but it allows you to deploy resources and deploy accounts and then deploy things to multiple accounts. It's a really nice, simple declarative language. AWS, on the other hand, has Control Tower, and Control Tower is more based through the console, and there's a lot of magic going on in the background.
So Control Tower works pretty well, but there are a lot of moving pieces. So I'd like to see AWS simplify this whole multi-account management thing and maybe provide some sort of CloudFormation-based Control Tower so that we can manage our organization in code. And the last one, which kind of relates back to the first one, is just price optimizations. So I'm talking about price decreases everywhere.
I think these days people are looking at AWS cloud cost quite a lot. I think the fear of pricing is slowing people down in AWS cloud migration, but there are some things that can just be optimized in general, like having a single VPC endpoint for all AWS services so that you don't have to create one for each service in each account. And then there's single NAT gateway. So if you have to have a NAT gateway, if they're not going to make it cheaper, which would be great, it would be nice if you could just have a single NAT gateway easily and share it easily with your accounts without having to do lots of complex IP routing. So I think two out of the five have been focused on cost, and that's an important thing. So I hope the lovely people at AWS are listening and furiously scribbling notes. Now, it's time for your additions, Luciano, and I'm very curious.
Luciano: Yeah, I really like your five, but I only have four, and I hope they will be interesting as well. The first one is automatic multi-region. So with many services today, you can just flick a switch and say, make this multi-AZ, and that will make sure, for instance, RDS, that you have multiple instances running on different availability zone and failover and everything is already nicely configured out of the box.
I think kind of trying to transpose that idea to multi-region doesn't feel like too much of a stretch. I'm sure that there is complexity there because the network characteristics will be much different from what you have between AZs with what you have between regions. But it feels from a product perspective like something that would be really nice to have, especially when you start to think about DR strategies for your own deployments.
It is always very, very difficult to configure things correctly, and with many services, you end up building everything yourself, while it could be a feature that AWS could just expose out of the box. The second one I have is something that annoys people a lot. Every time there is an announcement for a new service, especially when this new service is labeled as serverless and then it doesn't scale to zero.
So if you're labeling something as serverless, make sure it scales to zero and that you are going to pay zero when you are not using that particular service because I think that's the expected definition, or at least it's part of the expected definition of serverless for most people. So don't just label things as servers just for marketing reason. Make sure that they are really truly serverless and they also scale to zero.
So that would make every announcement, I don't know, better or less disappointing because there is always an element of, oh, a new serverless service is not really serverless, and then you forget about all the nice things about that new project or service just because you focus on the fact that it's not really truly serverless as it was advertised. So I guess that's, I don't know, more of a marketing thing than anything else, but it would be nice to see that because you will trust new announcement a lot more.
Another one that I have is better UX, especially when interacting with service like ElastiCache or RDS, which are a little bit more traditional services, so they still run behind the scenes in virtual machines that AWS is managing for you. And of course, these virtual machines are running in their own secure network environment. They, of course, they're not going to be easily accessible from the outside, except that you will need sometimes to interact with those databases from the outside, maybe because you want to query the data, maybe because you want to troubleshoot something.
And this is something we've been talking about quite a few times. There are several episodes that you can check, for instance, when we talk about Bastion hosts. And those are all escape patches that you need to put in place just to be able to access those databases. It would be really, really nice if AWS will give you even just a web UI in the console that would allow you to easily query your data in ElastiCache or RDS, or even if that's not easily possible because, of course, building a UI is not an easy feat.
It takes development time. It can be expensive for AWS. But even just giving VPC support to CloudShell, I think, would help a lot because at that point you can just run a shell in that VPC and then use any CLI client to interact with your databases. I think maybe not ideal because it's still a good amount of complexity for a developer to take in, but it would make things significantly simpler. And the last point I have is better DX and documentation in general.
Probably similar to my previous point, but it's more about the fact that every time I need to explore something new in AWS, and there is always something new because AWS is so broad, for me, even though I have some experience with AWS, I've been using it for several years, I easily get lost. Like, I try to figure out, can I use this particular service? Maybe let's make an example in the IoT space.
I'm trying to investigate a potential architecture. Okay, there are many, many services that AWS is giving us in the IoT space. So let's try to figure out which one can be more useful to my particular problem. And you end up reading all the marketing pages first, and they're very high level and they promise you lots of features, but without really giving you insights on the details. Then what do you do next?
It's like, okay, I can just check a workshop and that there are tons of workshops, which is great, but then doing all the workshops takes a lot of time and you need to make sure it's worth your time to invest in doing the workshops. So is that really the real service? So you end up looking at blog posts, or you end up looking at the official docs and very easily you end up spending days just trying to make sense of what are the capabilities of that particular service. So I don't know really if there is a solution to this, but I think having a more cohesive way to find information about services and drill down at the right level would be something very welcome. I think as much as to people that are new to AWS, but also to people that have a lot of experience with AWS and they are just trying to expand their knowledge into a new service or a new set of features that they haven't used yet. So this is my top four. What do you think? You have anything else you want to add?
Eoin: No, I completely agree with those additions. I think we've got nine there, which is probably a lot to ask. Maybe it's a good time to thank all the great people at AWS who are working hard to make it as good as it is. I hope that all of these suggestions are taken in the spirit of continuous improvement. I think if we even got one third of this list, AWS would really start to become next level for everybody listening and watching. What did we miss? Let us know your big ideas for making AWS better for all of us. And if you want to hear more from us about AWS, subscribe to our YouTube channel or add the podcast to your player so you get notified whenever we release new episodes. Thanks for listening and we'll see you next time.