Screaming in the Cloud - Leading the Cloud Security Pack with Yoav Alon

Episode Date: May 3, 2022

About YoavYoav is a security veteran recognized on Microsoft Security Response Center’s Most Valuable Research List (BlackHat 2019). Prior to joining Orca Security, he was a Unit 8200 researcher and team leader, a chief architect at Hyperwise Security, and a security architect at Check Point Software Technologies. Yoav enjoys hunting for Linux and Windows vulnerabilities in his spare time.Links Referenced:Orca Security: https://orca.securityTwitter: https://twitter.com/yoavalon

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Vulture, spelled V-U-L-T-R, because they're all about helping save money, including on things like, you know, vowels.

So what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that, well, sure, they claim it is better than AWS's pricing. And when they say that, they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently elastic and open. They can mean the same thing sometimes. They have had over a million users. Deployments take less than 60 seconds across

12 pre-selected operating systems, or if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes, except maybe Amazon,

who stubbornly insists on having something of the scale on their own. Try Vulture today for free by visiting vulture.com slash screaming, and you'll receive $100 in credit. That's v-u-l-t-r dot com slash screaming. Finding skilled DevOps engineers is a pain in the neck, and if you need to deploy a secure and compliant application to AWS without such things, forget about it. But that's where Duplo Cloud can help. Their comprehensive no-code-slash-low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks while automating the full DevSecOps lifestyle. Get started with DevOps as a service from Duplo Cloud, and your cloud configurations will be done

right the first time. Tell them I sent you, and your first two months are free. To learn more, visit snark.cloud slash duplocloud. That's snark.cloud slash d-u-p-l-o-c-l-o-u-d. Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I would say that I enjoy dealing with cloud platform security issues, except I really don't. It's sort of forced upon me to deal with, much like a dead dog is cast into their neighbor's yard for someone else to have to worry about. Well, invariably, it seems like it's my yard. And I'm only on the periphery of these things. Someone who's much more in the trenches in the wide world of cloud security is joining me today.

Yoav Alon is the CTO at Orca Security. Yoav, thank you for taking the time to join me today and suffer the slings and arrows I'll no doubt be hurling your way. Thank you, Corey, for having me. I've been a longtime listener and it's an honor to be here. I'm still periodically surprised to learn that anyone listens to these things

because it's unlike a newsletter where everyone will hit reply and give me a piece of their mind. People generally don't wind up sending me letters about things that they hear on the podcast. So whenever I talk to someone who listens to it, it's, oh, oh, right, I did turn the microphone on. Awesome. So it's always just a little on the surreal side. But we're not here to talk necessarily about podcasting or the modern version of an AM radio show. Let's start at the very beginning. What is Orca security,

and why would folks potentially care about what it is you do? So Orca Security is a cloud security company and our vision is very simple. Given a customer's cloud environment, we want to detect all the risks in it and implement mechanisms to prevent it from recurring. While it sounds trivial, before Orca it wasn't really possible. You had to install multiple tools and aggregate them and do a lot of manual work and it was messy. And we wanted to change that.

So we had like three guiding principles. We call it seamless. So I want to detect all the risks in your environment without friction, which is our speak for fighting with your peers. We also want to detect everything so you don't have to install like a tool for each issue, a tool for vulnerabilities, a tool for misconfigurations and for sensitive data, IAM roles and such. And we put a very high priority on context, which means telling you what's important and what's not.

So, for example, S3 bucket open to the internet is important if it has sensitive data, not if it's a, I don't know, static website. Exactly. I have a few that I'd like to get screamed at in my AWS account. Like, this is an open S3 bucket, and it's terrible. I look at it, and the name is assets.lastweekinaws.com. Gee, I wonder if that's something that's designed to be a static hosted website. Increasingly, I've been slapping CloudFront in front of those things just

to make the broken warning light go away. I feel like it's an underhanded way of driving CloudFront adoption some days, but that may not be the most charitable interpretation thereof. Orca has been top of mind for a lot of folks in the security community lately, because let's be clear here, dealing with security problems in cloud providers from a vendor perspective is an increasingly crowded and clouded space. Just because there's so much, there's investment pouring into it, everyone has a slightly different take on the problem. And it becomes somewhat challenging to stand out from the pack. You didn't really stand out from the pack

so much as leaped to the front of it and more or less have become the de facto name in a very short period of time. Specifically, at least for my world, when you wound up having some very interesting announcements about vulnerabilities within AWS itself. You will almost certainly do a better job of relating the story. So please, what did you folks find?

So back in September of 2021, two of my researchers, Yanir Tsarimi and Zach Fakhimi, each one of them, within a relatively short span of time from each other, found a vulnerability in AWS. Zach found a vulnerability in CloudFormation, which we named BreakingFormation. And Yanil found a vulnerability in AWS Glue, which we named SuperGlue. We're not the best copywriters, but...

No, naming things is hard. Ask any Amazonian. Yes. So I'll start with BreakingFormation, which caught the eyes of many. It was an XXESSRF, which is jargon to say that we were able to read files and execute HTTP requests and read potentially sensitive data from CloudFormation servers. This one was mitigated within 26 hours by AWS. That was mitigated globally? Yes, globally, which I've never seen such quick turnaround anywhere.

It was an amazing security feat to see. Particularly in light of the fact that AWS does a lot of things very right when it comes to designing cloud infrastructure. Imagine that. They've had 15 years of experience and basically built the idea of cloud in some respects at the scale that the hyperscalers operate at.

And one of their core tenets has always been that there's a hard separation between regions. There are remarkably few global services and those are treated with the utmost of care and delicacy to the point where when something like that breaks, there's an issue that spans more than one region. It is headline-making news in many cases. So they almost never wind up deploying things to all regions at the same time.

That can be irksome when we're talking about things like I want a feature that solves a problem that I have, and I have to wait months for it to hit a region that I have resources living within. But for security stuff like this, I am surprised that going from this is the problem to it has been mitigated took place within 26 hours. I know it sounds like a long time to folks who are not deep in the space, but that is superhero speed.

Small correction, it's 26 hours for the main regions, and it took three to four days to propagate to all regions, but still, it's speed hours for the main regions, and it took three to four days to propagate to all regions. But still, it's a bit of light for a security space. When this came out, I was speaking to a number of journalists on background about trying to wrap their head around this. And they said that security is always a top priority for AWS, second only to uptime and reliability. And I understand the perception, but I disagree with it in the sense of the nightmare scenario that every time I mention to a security person watching the blood drain from their face is awesome. But the idea that

take IAM, which as Werner said in his keynote processes, what was it, 500 million or was it 500 billion requests a second, some ludicrous number. Imagine it fails open, where everything suddenly becomes permitted. I have to imagine in that scenario, they would physically rip the power cables out of the data centers in order to stop things from going out. And that is the right move. Fortunately, I am extremely optimistic that that will remain a hypothetical because that is nightmare fuel right there. But Amazon says that security is job zero. And my cynical interpretation is that, well, it wasn't, but they forgot security and decided to bolt it on at the end like everyone else does. And they just didn't want to renumber all their slides. So instead of making it 0.1,

they just put another slide in front of it and called it job zero. I'm sure that isn't how it worked, but for those of us who procrastinate in building slide decks for talks, it has a certain resonance to it. That was one issue. The other seemed a little bit more pernicious, focusing on Glue, which is their ETL as a service, service, one of them, I suppose. Tell me more about it.

So one of the things that we found when we found the breaking information, when we reported the vulnerability, led us to do a quick Google search, which led us back to the Glue service. It had references to Glue, and we started looking around it. And what we were able to do with the vulnerability is, given a specific feature in Glue, which we don't disclose at the moment, we were able to effectively take control over the account which hosts the Glue service in US East 1.

And having this control allowed us to essentially be able to impersonate the Glue service. So every role in AWS that has a trust to the glue service, we were able to effectively assume role into it in any account in AWS. So this was more critical vulnerability in its effect. I think on some level, the game of security has changed because for a lot of us who basically don't have much in the way of sensitive data living in AWS, and let's be clear, I take confidentiality extremely seriously.

Our clients on the consulting side view their AWS bills themselves as extremely confidential information that Amazon stuffs into a PDF and emails every month. But still, if there's going to be a leak, we absolutely do not want it to come from us. And that is something that we take extraordinarily seriously. But compared to other jobs I've had in the past, no one will die if that information gets out. It is not the sort of thing that is going to ruin people's lives, which is very often something that can happen

in some data breaches. But in my world, one of the bad cases of a breach of someone getting access to my account is they could spin up a bunch of containers on the 17 different services that AWS offers that can run containers and mine cryptocurrency with it. And the damage to me then becomes a surprise bill. Okay, great, I can live with that.

Something that's a lot scarier to a lot of companies with serious problems is, yeah, fine, cost us money, whatever, but our access to our data is the one thing that is going to absolutely be the thing that cannot happen. So from that perspective alone, something like Glue being able to do that is a lot more terrifying than subverting CloudFormation

and being able to spin up additional resources or potentially take resources down. Is that how you folks see it too? Or I'm sure there's nuance I'm missing. So yeah, the access to data is top of mind for everyone. It's a bit scary to think about it. I have to mention again, the quick turnaround time for AWS, which almost immediately issued a patch. It was a very fast one. And they mitigated, again, the issue completely within days. About your comment about data, data is king these days.

There is nothing like data, and it has all the properties of everything that we care about. It's expensive to store, it's expensive to move, and it's very expensive if it leaks. So I think a lot of people were more alarmed about the glue vulnerability than the CloudFormation vulnerability, and they're right in doing so. I do want to call out that AWS did a lot of things right in this area. Their security posture is very clearly built around defense in depth. The fact that they were able to disclose after some prodding that they checked the cloud

trail logs for the service itself dating back to the time the service launched and verified that there had never been an exploit of this, that is phenomenal as opposed to the usual milquetoast statements that companies have of, we have no evidence of it, which can mean that we did the same thing and we looked through all the logs and it's great, but it can also mean that, oh yeah, we probably should have logs, shouldn't we? But let's take a backlog item for that. And that's just terrifying on some level. It becomes a clear example, a shining beacon for some of us in some cases, of doing things right from that perspective. There are other sides to it, though.

As a customer, it was frustrating in the extreme to, and I mean no offense by this, to learn about this from you rather than from the provider themselves. They wound up putting up a security notification many hours after your blog post went up, which I would also just like to point out. And I spoke about it at the time, and it was a pure coincidence, but there was something that was just chef's kiss perfect about you announcing this on Andy Jassy's birthday. That was just very well done. So we didn't know about Andy's birthday, and it was... Well, I see only one of us has a company calendar with notable executive birthdays splattered all over it. Yes, and it was also published around the time that AWS CISO was announced, which was also a coincidence because the date was chosen a lot of time in advance.

So we genuinely did it now. Communicating around these things is always challenging because on the one hand, I can absolutely understand the cloud provider's position on this. We had a vulnerability disclosed to us. We did our diligence and our research because we do an awful lot of things correctly and everyone is going to have vulnerabilities. Let's be serious here. I'm not sitting here shaking my fist angry at AWS's security model. It works and I am very much a fan of what they do. And I can definitely understand that going through all of that, that there was no customer impact. They've proven it. What value is there to them telling anyone about it? I get that. Conversely, you're a security

company attempting to stand out in a very crowded market. And it is very clear that announcing things like this demonstrates a familiarity with cloud that goes beyond the common. I radically changed my position on how I thought about Orca based upon these discoveries. It went from Orca who, other than the fact that you folks have sponsored various publications in the past, thanks for that, but okay, a security company, great, to oh, that's Orca. We should absolutely talk to them about a thing that we're seeing. It has been transformative for what I perceive to be your public reputation in the cloud security space. So those two things are at odds. The cloud provider doesn't want to talk about anything, and the security company absolutely wants to demonstrate a conversational fluency with what is going on in the world of cloud.

And that feels like it's got to be a very delicate balancing act to wind up coming up with answers that satisfy all parties. So I just want to underline something. We don't do what we do in order to make marketing stand. It's a byproduct of our work, but it's not the goal. For the Orca Security Research Pod, which it's the team at Orca which does this kind of research, our mission statement is to make cloud security better for everyone, not just Orca customers, for everyone. And you get to hear about the more shiny things like big headline vulnerabilities, but we also have very sensible blog posts explaining how to do things, how to configure things, and give you more in-depth understanding

into security features that the cloud providers themselves provide, which are great and advance the state of the cloud security. I would say that having a cloud vulnerability is sort of one of those things which makes me happy to be a cloud customer. On the one side, we had a very big vulnerability with a very big impact. And the ability to access a lot of customers' data is conceptually terrifying. The flip side is that everything was mitigated by the cloud providers in a warped speed compared to everything else we've seen in all other elements of security. And you get to sleep better knowing that it happened. So no platform is infallible,

but still the cloud provider do work for you and you get a lot of added value from that. You've made a few points when this first came out and I want to address them. The first is when I reached out to you with a, wow, great work, you effectively instantly came back with, oh, it wasn't me. It was members of my team. So let's start there. Who was it that found these things? I'm a huge believer in giving people credit for the things that they do. The joy of being in a leadership position is

if the company screws up, yeah, you take responsibility for that. Whether the company does something great, yeah, you want to pass praise on to the people who actually, please don't take this the wrong way, did the work. And not that leadership is not work. It absolutely is. But it's a different kind of work. So I am a security researcher, and I'm very mindful for the effort and the skill it requires to find vulnerabilities and actually do a full circle on them. The first that I'll mention is Zach Vachima, which found the breaking formation vulnerability and the vulnerability in cloud formation. And Yanir Tsarimi, which found the auto-warp vulnerability,

which is the Azure vulnerability that we have not mentioned, and the Glue vulnerability dubbed Super Glue. Both of them are phenomenal researchers, world-class, and I'm very honored to work with them every day. It's one of my joys. Couchbase Capella! Database as a Service is flexible, full-featured, and fully managed, with built-in access via key-value, SQL, and full-text search. Flexible JSON documents align to your applications and workloads.

Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com slash screaming in the cloud to try Capella today for free It's very clear that you have built an extraordinary team from people who are able to focus on the vulnerability research, which on some level is very interesting because you are not branded, as it were, as a vulnerability research company. This is not something that is your core competency. It's not a thing that you wind up selling directly that I'm aware of. You are selling a security platform offering. So it's, on the one hand, it makes perfect sense that you would have a division internally that works on this. But it's also very noteworthy, I think, that that is not

the core description of what it is that you do. It is a means by which you get to the outcome you deliver for customers, not the thing that you are selling directly to them. I just find that an interesting nuance. Yes, it is. And I would elaborate and say that research informs the product, and the product informs research. And we get to have this fun dance where we learn new things by doing research. We teach the product, and we use the customers to teach us things that we didn't know. So it's one of those happy synergies. I want to also highlight a second thing that you have mentioned and been very, I guess, on message about

since the news of this stuff first broke. And because it's easy to look at this and sensationalize aspects of it, where, see, the cloud provider security model is terrible. You shouldn't use them. Back to data centers we go is basically the line taken by an awful lot of folks trying to sell data center things. That shouldn't use them. Back to data centers we go, is basically the line taken by an awful lot of folks trying to sell data center things. That is not particularly helpful for

the way that the world is going. And you've said that, yeah, you should absolutely continue to be in cloud. Do not disrupt your cloud plan as a result. And let's be clear, none of the rest of us are going to find and mitigate these things with anything near the rigor or rapidity that the cloud providers can and do demonstrate. I totally agree. And I would say that the AWS security folks are doing a phenomenal job. I can name a few, but they're all great. And I think that the cloud is by far a much safer alternative than on-prem. I've never seen issues in my on-prem environment which were critical and fixed in such a high velocity in such a massive scale.

And you always get the incremental improvements of someone really thinking about all the ins and outs of how to do security, how to do security in the cloud, how to make it faster, more reliable, without business interruptions. It's just phenomenal to see and phenomenal to witness how far we've come in such a relatively short time as an industry. AWS in particular has a reputation for being very good at security. I would argue that, from my perspective,

Google is almost certainly slightly better at their security approach than AWS is. But to be clear, both of them are significantly further along the path than I am going to be. So great, fantastic. You also found something interesting over in the world of Azure. And that honestly feels like

a different class of vulnerability. To my understanding, the Azure vulnerability that you recently found was you could get credential material for other customers simply by asking for it on a random high port, which is one of those... I'm almost

positive I'm misunderstanding something here. I hope. Please. I'm not sure you're misunderstanding. So I would just emphasize that the vulnerability, again, was found by Yanil Tsarimi. And what he found was he used a service called Azure Automation,

which enables you essentially to run a Python script on various events and schedules. And he opened the Python script and he tried different ports. And one of the high ports he found essentially gave him his credentials. And he said, oh, wait,

that's a really odd port for an HTTP server. Let's try, I don't know, a few ports on either way. And he started getting credentials from other customers, which was very surprising to us. That is understating it by a couple orders of magnitude.

Yes, like, huh, that seems suboptimal, is sort of like the corporate messaging approved thing. At the time you discover that, I'm certain it was a three-minute-long blistering string of profanity in no fewer than four languages. I said to him that this is like a dishonorable bug because he worked very little to find it. So it was from start to finish, the entire research took less than two hours,

which in my mind is not enough for this kind of vulnerability. You have to work a lot harder to get it. Yeah, exactly. My perception is that when there are security issues that I have stumbled over, for example, I gave a talk at reInvent about it in the before times. One of them was an overly broad permission in a managed IAM policy for SageMaker. Okay, great.

That was something that obviously was not good, but it also was more of a privilege escalation style of approach. It wasn't, oh, by the way, here's the keys to everything. That is the type of vulnerability I've come to expect by and large from cloud providers. We're just going to give you access credentials for other customers is one of those areas that it bugs me on a visceral level, not because I'm necessarily exposed personally, but because it more or less shores up so many of

the arguments that I have spent the last eight years having with folks who are like, oh, you can't go to cloud. Your data should live on your own stuff. It's more secure that way. And we were finally, it feels like starting to turn a cultural corner on these things.

And then something like that happens and it almost have those naysayers become vindicated for it. And it almost feels on some level, and I don't mean to be overly unkind on this, but it's like, you are absolutely going to be in a better security position with the cloud providers, except Azure.

And perhaps that is unfair, but it seems like Azure's level of security rigor is nowhere near that of the other two. Is that generally how you're seeing things? I would say that they have seen more security issues than most other cloud providers. And they also have a very strong culture of report things to us. And we're very streamlined into patching those and giving credit where credit due. And they give out bounties, which is an incentive for more research to happen on those platforms. So I wouldn't say this categorically, but I would say that the optics are not very good.

Generally, cloud providers are much safer than on-prem because you only hear very seldom on security issues in the cloud. You hear literally every other day on issues happening to on-prem environments all over the place. And people just say they expect it to be this way. Most of the time, it's not even a headline like company X affected with cryptocurrency or whatever. It happens every single day and multiple times a day. Breaches which are massively bigger.

And people who don't want to be in the cloud will find every reason not to be in the cloud. Let us have fun. What are the interesting parts about this is that so many breaches that are on-prem are just never discovered, because no one knows what the heck's running in an environment, and the breaches that we hear about are just the ones that someone had at least enough wherewithal to find out that, huh, that shouldn't be the way that it is. Let's dig deeper. That's a bad day for everyone.

I mean, no one enjoys those conversations and those moments. And let's be clear, I am surprisingly optimistic about the future of Azure security. It's like, all right, you have a magic wand. What would you do to fix it? It's, well, I'd probably hire Charlie Bell and get out of his way is not a bad answer as far as how these things go. But it takes time to reform a culture, to wind up building in security as a foundational

principle. It's not something you can slap on after the fact. And perhaps this is unfair, but Microsoft has 30 years of history now of getting the world accustomed to, oh yeah, just periodically terrible vulnerabilities are going to be discovered in your desktop software. And once a month on Tuesdays, we're going to roll out a whole bunch of patches and here you go, make sure you turn on security updates, yada, yada, yada. That doesn't fly in the cloud. It's like, oh yeah, here's this month's list of security problems on your cloud provider. That's one of those things that's like the record scratch freeze frame moment of, wait, what are we doing here exactly? So I would say that they also have a very long history of making those turnarounds. Bill Gates famously did his speech where security comes first,

and they have done a very, very long journey and to turn around the company from doing things a lot, a lot quicker and a lot safer. It doesn't mean they're perfect. Everyone will have bugs and Azure will have more people finding bugs into it in the near future. But security is a journey and they've not started from zero. They're doing a lot of work. I would say it's going to take time. The last topic I want to explore a little bit is, and again, please don't take this as any way being insulting or disparaging to your company, but I am actively annoyed that you exist. By which I mean that if I go into my AWS account

and I want to configure it to be secure, great. It's not a matter of turning on the security service. It's turning on the dozen or so security services that then round up to something like GuardDuty that then in turn rounds up to something like Security Hub. And you look at not only the sheer number of these services and the level of complexity inherent to them, but then the bill comes in and you do some quick math and realize that getting breached

would have been less expensive than what you're spending on all of these things. And somehow, the fact that it's complex, I understand. Computers are like that. The fact that there is no great messaging story that's cohesive around this, I come to accept that because it's AWS. Talking is not really their strong suit. Basically, declining to comment is. But the thing that galls me is that they are selling these services and not inexpensively either. So it

almost feels on some level like, shouldn't this ensemble be built into the offerings that you folks are giving us? And don't get me wrong, I'm glad that you exist because bringing order to a lot of that chaos is incredibly important, but I can't shake the feeling that this should be a foundational part of any cloud offering. I'm guessing you might have a slightly different opinion than mine. I don't think you show up at the office every morning. I hate that we exist. And no, and I'll add a bit of context and nuance. So for every other company than cloud providers, we expect them to be very good at most things, but not exceptional at everything. I'll give the Redshift example.

Redshift is a pretty good offering, but Snowflake is a much better offering for a much wider range of... There's a reason we're about to become Snowflake customers ourselves. So, yeah. And there are a few other examples of that. A security company,

a company that is focused solely on your security, will be much better suited to help you in a lot of cases more than the platform. And we work actively with AWS, Azure, and GCP requesting new features, helping us find places where we can shed more light and be more proactive. And we help to advance the conversation and make it a lot more actionable and improve from year to year. It's one of those collaborations. I think the cloud providers can do anything, but they can't do everything.

And they do a very good job at security. It doesn't mean they're perfect. As you folks are doing an excellent job of demonstrating. Again, I'm glad you folks exist. I'm very glad that you are publishing the research that you are. It's doing a lot to bring a lot, I guess, a lot of the undue credit that I was giving AWS for years.

No, no, it's not that they don't have vulnerabilities like everyone else does. It's just that they don't ever talk about them. And their operationalizing of security response is phenomenal to watch. It's one of those things where I think you've succeeded in what you said earlier, that you were looking to achieve, which is elevating the state of cloud security for everyone, not just Orca

customers. Thank you. Thank you. I really appreciate your taking the time out of your day to speak with me. If people want to learn more, where's the best place they can go to do that? So we have our website at orca.security, and you can reach me out on Twitter. My handle is

at Yoav Alon, which is at Y-O-A-V-A-L-O-N. And we will, of course, put links to that in the show notes. Thanks so much for your time. I appreciate it. Thank you, Corey. Yoav Alon, Chief Technology Officer at Orca Security. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud if you've enjoyed this podcast please leave a five star review on your podcast platform of choice

or of course on YouTube smash the like and subscribe buttons because that's what they do on that platform whereas if you've hated this podcast

please do the exact same thing five star review smash the like and subscribe buttons on YouTube but also leave an angry comment

that includes a link that is both suspicious and frightening and when we click on it suddenly our phones will all begin mining cryptocurrency. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS.

We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble