Screaming in the Cloud - The Demystification of Zero Trust with Philip Griffiths

Episode Date: March 30, 2022

About PhilipPhilip Griffiths is VP Global Business Development and regularly speaks at events from DevOps to IoT to Cyber Security. Prior to this, he worked for Atos IT Services in various roles working with C-suit executives to realise their digital transformation. He lives in Cambridge with his wife and two daughters.Links:NetFoundry: https://netfoundry.io/Blog article: https://netfoundry.io/demystifying-the-magic-of-zero-trust-with-my-daughter-and-opensource/netfoundry.io/screaminginthecloud: https://netfoundry.io/screaminginthecloud

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. Today's episode is brought to you in part by our friends at Minio, the high-performance Kubernetes native object store that's built for the multi-cloud,

creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere. And that's exactly what Minio offers. With superb read speeds in excess of 360 gigs and a 100 megabyte binary

that doesn't eat all the data you've got on the system, it's exactly what you've been looking for. Check it out today at min.io slash download and see for yourself. That's min.io slash download and be sure to tell them that I sent you. This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of hello world demos. Allow me to introduce you to Oracle's always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security.

And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisk next to the word free.

This is actually free, no asterisk. Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's promoted episode is about a topic that is near and dear to my heart. In the AWS universe, we have seen over time that the networking has gotten more and more capable, going from EC2 Classic to the world of VPC Network to a whole bunch of other things. But with that capability comes a stupendous amount of complexity

to the point where the easy answer to, do you understand how networking works within AWS, is of course, no, I don't. I'm joined today by Philip Griffiths, who's the head of business development at NetFoundry. Philip, thank you for joining me. Pleasure to be here, Corey. So NetFoundry has what I would argue to be one of the most intriguing slash differentiated approaches to handling that ever-increasing complexity around the networking story, not just in AWS, but a number of different cloud providers and between them. And that approach is to ignore it completely. Have I nailed the salient approach here with that, I guess we'll call it a flippant statement? Yeah, I would broadly say so. It's the interesting thing where a lot of people say cloud networking is hard. And from our perspective, it should just be super easy. You should be able to provision it in a few minutes with only

outbound ports and set up your policies so that malicious actors can't get inside it. It should be that easy and programmable, and it's a shame that the current world is not. One of the hard problems has always been in, I guess, security, which is the thing that everyone pretends to care about right up front, but in practice often winds up bolting it on after the fact, because we care about security is sort of the trademark phrase of things that we see, usually in emails announcing a data breach, when it was very clear that companies did not care about security. It's not just me complaining about how complex the network stack is, but by what directly flows from that. If you aren't able to fit all of that into your head as far as what's going on from a security perspective, the odds of misconfiguration creep in and you don't really become aware of what your risk exposure is.

I'm really partial to the idea of just avoiding it entirely. Is NetFoundry effectively a network overlay? Is it something that goes a bit beyond that effectively? Where do you folks start and where do you stop? Yes, that is precisely correct. We are a network overlay that's been built on the principles of zero trust. What is very unique is the ability to be able to start it wherever you want so yes you can deploy it from the alias marketplace in a few minutes into your vpc or into your operating system but we also have the ability to actually put it directly into the application it's stack itself which has some very interesting complications what i find as the most interesting starting point is the oxymoron of secure networking

there are no secure networks it's not possible networks are designed to share information and taking it to first principles you can only isolate networks and this is why we have the thought process for if we're going to put our overlay network into stuff and make it secure we have to start at the application level, because then we can actually just isolate it to an application communicating to an application, which has profound implications. The network part is relatively straightforward. I imagine it just becomes more or less what resembles a fairly flat network

where everything internal is allowed to talk to each other, and then in turn, this winds up effectively elevating what should be allowed to talk to what and on what ports and whatnot into something that's a lot closer to the application logic and transcends whatever provider it happens to be traversing. Yeah, correct. Following the principles of zero trust, we utilize strong embedded identity as a function of what the endpoints are, what the source and destination is. And therefore, you could build up your policies and services to say what should communicate to what on the basis that the default is least privileged. Absolutely nothing. Your underlay, then, the only thing you need is commodity internet with outbound ports. The whole concept of

north, south, east, west. If you're app-embedded, you don't even need public DNS, but you don't even need DNS at all. Name any conventions, go out the window, you don't need to conform to the standards. You say, I want to hit Jenkins. You go to Jenkins

because that can be done. I would approach this entire endeavor with a fair bit of suspicion and no small amount of alarm if it were something that you had developed internally as far as, well, we're just going to replace your entire network stack and just go ahead and trust us. It's fine. But you didn't do that. You're riding on top of the OpenZD open source project. And that basically assuages a whole raft of concerns I would have if something like this were proprietary and people who know what they're doing, let's be clear, aren't me,

were not able to inspect it and say, okay, this passes muster, as they have done, or alternately, no, this is terrifyingly dangerous for a variety of excellent reasons. And it really feels like a lot of the zero trust stories that we see these days that are taking advantage of either a network overlay approach or shifting authentication into a different layer have all taken a somewhat similar tack. I used to think it was a good idea. Now I'm starting to suspect it might very well be the only viable model. Do you find that that's accurate, or was this a subject of some contention when you were starting out? So there's two very interesting thoughts that came to as you were saying that

number one is yes, we drove forward of OpenZT. Because we've seen open source, just completely dominate the industry and everything new that's been built. If you want to deploy an application, you're building on Linux, and that you're you want to deploy an application, you're building it on Linux. In fact, you're probably also running on Kubernetes if you're building new. And our objective was to be able to turn OpenZT into the open source, zero trust, private networking equivalent,

where it's just standard. You'll bake your application with ZT by design. It will become a check function that people say you have to comply to. When I look at other vendors and how they look at zero trust, I broadly see a few into a few ways. You have people who are effectively acting as a proxy and they're adding authentication as a way to check what people should have access to. And they may give access to the whole network. They may do granular.

It varies between them. In fact, I've just written a blog on this where I effectively call that No Magic, Zero Trust. It's a blog conceptualized within Harry Potter and a conversation with my daughter. Any way to tell a story that beats the tip of the traditional enterprise voice is very much appreciated over at this point in the world.

Exactly. You have a second tier, which is what I like to think is semi-magical, and that's where you start saying, I am going to use a software-defined perimeter so that it's first-packet authenticate or outbound only based upon embedded identity. And in my eyes, this is basically an invisibility cloak. You then have app-embedded or magical zero trust.

And this is where you're putting the invisibility cloak inside your application, but you're also giving it a port key so that when it needs to connect to something else on the other side of the world, it just happens. It's transparent. And broadly speaking, I think it's very good that the whole world, including the US government, is taking zero trust incredibly importantly. But the distribution of how people tackle the problem is wildly different. There are some zero trust solutions which go in the right direction. But fundamentally, if you're putting it in front of your, I won't name the vendor, but there was a vendor who in December, they released a report that said in 90 seconds,

common vulnerabilities are exploited, something like 96% of the time, 24 hours, 100%. A few days later, they had a 9.8 cbe on their zero trust vpn concentration for public ip to which i thought if you're not patching that immediately you've got problems and so on's coming into your network absolutely we just completed our annual security awareness training here and so much of it just it really made my skin crawl. There was an entire module on how to effectively detect phishing emails. And I got to tell you, if they ever start running spellcheck on some of their spear phishing campaigns, then we're all doomed because that was what the entire training was here. My position is, is that, okay, if someone in your company clicks a bad link and it destroys

the company's infrastructure, maybe it's the person who's clicking the link that is not necessarily the critical failure point here. Great. If someone compromises an employee workstation, there should be a way to contain the blast radius. They should not now be inside the walls and able to traverse into whatever it is that they want. There should be additional barriers. And zero trust, though it has become, as you say, a catch-all term, seems to be a serious way of looking at this type of compromise and this sort of mitigation against that sort of behavior. Definitely. And I think that leads itself to, if you're using the correct zero trust solution, you're able to close all your

imports. Great. You've now massively reduced your tax tax office but what if someone does get a phishing injection of ransomware or something to their endpoint or into their their servers the two things that i like to think about is that if you're creating your overlay network so that the only communication from your server is outbound into the public ips of your private overlay and effectively even if the ransomware gets in there it can't then connect to its command and control module to then go through the kill cycle to other activities the other is that if you then look at that instead of on the server side but actually on the client side if someone infects my mac laptop with ransomware, we use this internal application called Mattermost. And it's basically Slack, but open source.

If my Mattermost is Zetified, even though I've got ransomware on my device, it can't side channel attack into Mattermost because you would actually have to break into the Mattermost application to somehow get that Mattermost application to make a compromised query or whatever to to get part of the system so in you know really when i look at zero trust it's not about saying we're secure

job done you know by the security department because we don't need them anymore it's more about saying hand it off to the auditor exactly it's more about saying the cost of attack, the cost of compromise is increased, ideally to the point where the malicious actors don't have a return on investment. So they have a return on investment, they will find something else that's not your applications and your systems to try and compromise. I want to make sure that I'm contextualizing this properly, because we're talking, I think, about what almost looks like two different worlds here. There's the, this is how things wind up working in the ecosystem, as far as your server environment goes in a cloud provider. But then we're also talking about what goes on in your corporate

network of people who are using laptops, which is increasingly being done from home these days. Where do you folks start? Where do you stop? Do you transcend into the corporate network as well, or is this primarily viewed as a production utility? We do. One of our original design principles with OpenZT was for it to be a platform rather than a point solution. So we designed it from the ground up to be able to support any IP packets, TCP, UDP, etc., whether you're doing client-server, server-server, machine-server, server-initiated, client-initiated, yada, yada, yada. So effectively, the same technology can be applied to many different use cases depending upon where you want to use it.

We've been doing work recently to handle, let's call them the hard use cases. Probably one of the hardest ones out there is is voip there is a playbook that is currently taking place where the voip managed service provider gets ddos'd by malicious actors the playbook is to move it onto a cdn so that you move the attack surface and you get respite for a few hours and there's not really any way to solve it because blocking DDoS attacks at layer three, layer four is incredibly difficult unless you can make your PBX dark. And I've seen a couple of our OpenZT engineers making calls from one device to another without going through the PBX by doing that over OpenZT and being able to solve some of the challenges that's normally associated with VoIP. Again, that was really one of our design principles. How can we make the platform so flexible that we can do X, Y, Z today,

but we're able to build it, again, to become a standard because it can handle anything. One of the big questions that people are going to have going into this is, and this may sound surprising, is a little bit less about technical risk of things like encryption and the rest, and a lot more around the idea of, okay, does this mean that what you are building becomes a central point of business risk? In other words, if the NetFoundry SaaS installation and wherever they happen to be using as their primary

winds up going down, does that mean suddenly nothing can talk to one another? Because it turns out that, you know, computers are not particularly useful in 2022 if they aren't able to talk to other computers. By and large, the network is the computer, as was famously stated. What is the failure mode in the event that you experience technical interruption? internal sessions which we call zt kitchens where our engineering team that are creating zt educators on on stuff that they're building and one of them in the zt kitchen was around ha hs etc and all of the functions that we've built in so that you have redundancy and availability within the different components because effectively it's an overlay network so we've designed it to be a mesh overlay network you can set it up with one point of failure but then simultaneously you can very easily set up to have no points of failure because it can have that redundancy and the overlay has its own mechanisms to do things like smart routing and calculation of underlying costs.

That cost in that instance would be, well, eight of us have gone down. So the latency to send a packet or flow over it is incredibly high. Therefore, I'm going to avoid that route and send the traffic to another location. I always remember the ZT Kitchen episode because the underlying technology that does it is called terminators. ZT has these things called terminators. On the slides, there was these little heads of the terminator with the red eyes, you know, the silver exoskeleton, which always made me laugh. It's helpful to have things that fail out of band as opposed to, think of the traditional history in security. Before everything was branded with zero trust as a prerequisite for exhibiting at RSA. Before that, it was firewalls was the story. And the question always was, if a firewall fails, do you want it to fail open or fail close? And

believe it or not, there are legitimate answers in both directions. It depends on context and what you're doing. There are some things, for example, IAM in a cloud world where you absolutely never want to fail open full stop. You would rather someone bodily rip the power cable out the back of the data center rather than let that happen. With something like this, where nothing is able to talk to one another if the entire system goes down, yeah, you want to have the control system that you folks run to be out of band. That is almost always the right answer. As look at the various case studies that you have on your website and the serious companies that are using what you have built. Do you find that they are primarily centralizing around individual cloud providers? Are you seeing that they're using this as an expression of multi-cloud? Because I can

definitely see a story where, oh, it helps bring two cloud providers from a networking and security perspective onto the same page. But I can also see even within one cloud provider the idea that, hey, I don't have to play around with your ridiculous nonsense. What use cases are you seeing emerge among your customers? Definitely the multi-cloud challenge is one that we're seeing as a emerging trend. We do a lot of work with Oracle and their stated position is multi-cloud is a fact. In fact, for them, if we make the secure networking easier, we can bring workloads into our cloud quicker, the main driver between our partnership.

We recently did a blog talking about super clouds and the advent of organizations like Snowflake and HashiCorp and Confluent and Databricks, basically building value and business applications, which abstracts away the underlying complexity. But you get into the problem of the standard shared security model where the customer has to deal with DNS and VPNs and MPLS and AWS Private Endpoint or Azure Private Link or whatever they call it. And you have to assemble this Frankenstein of stuff just to enable a VM to communicate to another VM.

And the posit of our blog, in fact, we use that exact quote, John Gage, the computer is the network. If you can put the network inside the application, you've now given your super cloud superpowers, because it should natively, I mean, this is very marketing term, but develop wants to deploy anywhere and be multi cloud native. The idea of being able to adapt to emerging usage patterns without a full on redeploy is handy. What I also would like to highlight too, is that you are of course a network overlay. And that is something that is fairly well understood and people have seen it. But your preferred adoption model goes a couple of steps beyond that

into altering the way that the application thinks about these things. And you offer an SDK that ranges from single line of code implementation to I think up to 20. So it's not a massive rewrite of the application, but it does require modification of the stack. What does that buy you, for lack of a better term?

Because once you have the application that becomes aware of what is effectively its own special network, quote-unquote, it's work to wind up modifying existing applications around something like this. What's the payoff? So there's three broad ones that immediately come to my mind. Number one is the higher security that effectively your private network is inside the app, so you have to somehow break into the app, and that can be incredibly complicated, particularly if you run the app in something like a confidential compute enclave. You can now have a distributed confidential system. The second is what you're getting in programmability.

You're able to effectively operate in a fully uh even you know get to a gitops environment in fact we're currently working on documentation which says hey you can now do all the stuff in gitops and then it'll go into your cicd and i'll talk to the apis and effectively do everything in a completely programmable manner so that you can treat your private networks as cattle rather than as pets the third is transparency you used the words earlier of bolt on networking because that's how we always think about networking security we bolt it on as a user we have to jump through the vpn hoop we have to go through the bastion we have to interact with the network if your private network is inside the application that you interact with the application

i can have a mobile application on my device, and I have no idea that it's part of a private network and that the API is private and malicious actors can't get to. I just interact with the application. That is it. That is what no one else has the ability to do, and where OpenZT has its most power

because then you get rid of the constant tug of war between the security team that want to lock everything down and the users and the developers who want to move fast and give a great experience. You can effectively have your cake and eat it. The challenge, of course, with rolling a lot of these things out in a way that becomes highly programmable is that it unlocks a bunch of capability. But the double-edged sword there is always one of complexity. I mean, we take a look at the way that AWS networking has progressed, and they finally rolled out the VPC reachability analyzer. So when two things can't talk to each other while you run this thing, and it tells you exactly why, which is super handy. And then just as a way of twisting

the knife a little bit, every time you run it, they charge you 10 cents for the privilege, which doesn't actually matter in the context of what anyone is being compensated for until and unless you build this into something programmatic. But it stings a little bit. And the idea of being able to program these things to abstract away a lot of that complexity is incredibly compelling, except for the part where now it feels like it really increases developer burden on a lot of these things. Have you found that to be true? Do you find that it is sort of like a sliding scale? What has the customer experience been around this? I would say a sliding scale. You know, we had one organization who they started with the OpenZT tunnelers, and then we convinced them to use the SDK, and they were like, oh, this is super easy. And now they just run OpenZT on themselves. But then they've also said, at some point, we'll use the NetF they're like, oh, this is super easy. And now they just run OpenZT on themselves. But then they've also said at some point we'll use the NetFoundry platform,

which effectively gives us a SaaS experience in consuming that. One of the huge focuses, well, we've got a few big focuses for our product development, but one of the really big areas is really giving more visibility and monitoring so that rather than people having to react to configuration problems or things which they need to fix in order to ensure your perfect network overlay. Instead, those things are being seen and automatically dealt with, with human in the loop if you want it, in order to remove that burden. Because ultimately, if you can get the network to a point where as long as you've got underlay and you've set your policy, the overlay is going to work and it's going to be secure and it's going

to give you the uptime you need. That is the nirvana that we all have to strive for. 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 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. A common criticism of things that, shall we say, abstract away the network is a fairly common predictable failure mode. I've been making fun of Kubernetes on this particular point for years, and I'm annoyed that at the time that we're recording this, that is still accurate. But from the cloud provider's perspective,

when you run Kubernetes, it looks like one big, really strangely behaved single tenant application. And Kubernetes itself is generally not aware of zone affinity. So it could just as easily wind up tossing traffic to the node next to it at zero cost or across an availability zone at 2 cents per gigabyte, or, God forbid,

across the internet at nine cents a gigabyte and counting, depending upon how it works. And the application inside has absolutely no conception of this. How does OpenZD address this in the real world? Because it's one of those things where it almost doesn't matter what you folks charge on top of it, but instead, oh wow, this winds up being so hellaciously expensive that we can't use it regardless of whatever benefit it provides just because it becomes a non-starter. So when we built the overlay and the mesh, we did it from the perspective of making it as programmable and self-driven as possible. So with the whole Terminator strategy that was mentioned earlier,

it gives you the ability to start putting logic into how you want packets to flow. Today, it does it on a calculation of end-to-end latency and chooses and re-routes traffic in order to give that information. But there's no reason that you couldn't hook it up into understanding what is the numerical, the monetary cost for sending a packet along a certain path. Or even what is my application performance monitoring tool saying?

Because what that says versus what the network believes could be different things. And effectively, you can ingest that information to make your smart routing decisions. So all of that logic can exist within the overlay that operates for you. I will say that it really harkens back on some level to what I was experimenting with back when I got my CCNA many years ago, where there's an idea of routing protocols I've built into the idea of the cost of a link. I will freely admit slash confess that at the time, the low-cost link, I assumed this was about what was congested or what would wind up having theoretically some transit versus peering

agreement. It never occurred to me that I'd have to think about those things in a local network and have to calculate in the Byzantine pricing models of cloud providers. But I've seen examples of folks who are using OpenZD and NetFoundry alike to wind up building in these costing models so that, yeah, ideally it just keeps everything local. But if that path degrades, then yes, we would prefer to go over an expensive link than to basically have TCP terminate on the floor until everything comes back up. It sort of feels like there's an awful lot of logic you can bake into that that goes well beyond what routing protocols are capable of just by virtue of exposing that programmability. Well, for this customer, because they're on the extreme tier, then we want to have the expensive fallback. For low-tier customers, we might want to have them just have an outage until things end. And it really comes down to letting business decisions express themselves in terms of application behavior while in a degraded state. I love that idea. path diversity and visibility of how the internet operates that we'll be able to say within certain risk parameters of what we can deliver but then you can take it to other logical extremes you could say hey i want to build a green overlay i want to make sure that i'm using arm instances

and data centers of renewable energy so that my network is is green or you can say hey i want a gdpr compliant overlay so that my data stays within a certain country. You start being able to say, you know, really start dreaming up what are the different policies that I can apply to this. Because you're applying the central policy to them, what is in the distributed system. One last topic I want to cover before we call it an episode is that you are effectively a SaaS company that is built on top of an open source project. And that has been an interesting path for a lot of companies that early on figured that if they wrote the software, a lot of the contributors who were doing the lion's share of contribution, that they were the best people to run it. And Amazon's approach towards operational excellence, as they called it, wound up causing some challenges when they launched the Amazon Basics version of that service. I feel like there are some natural defenses built into OpenZD to keep it from suffering that fate, but I'm very curious to get your take on it. Fundamentally, our take is that,

in fact, our mission is to take what was previously impossible and turn it into a standard. And the only way you can really create standards is to have an open source that is adopted by the wider community and that ecosystems get built around and into. And that means giving OpenZT to absolutely everyone so that they can use it, they can innovate on top of it. We all know that very few people actually want to host their own infrastructure. So we assume a large percentage of people will come along go hey

the founder you you provide us the hosting you provide us the sas capabilities we have to deal with ourselves but fundamentally in the knowledge that there's something bigger because it's not just us maintaining this project there's a bunch of people who are doing pull requests and finding out cool fun ways to build further value on what we can build ourselves we believe the recent history is littered with examples of the new world being built on open source and fundamentally we think that's really the only way to be able to change an industry so profoundly as we intend to i would also argue that to be able to change an industry so profoundly as we intend to. I would also argue that to be very direct, and I can probably get away with saying this in a way that I suspect you might not be able to, but if AWS had it in their character to simplify things and make it a lot easier for people to work with in a networking sense,

what's stopping them? They didn't need to wait for an open source company to wind up coming out of nowhere and demonstrating the value of this. Customers have been asking it for years. I think that at this point, this is something that is unlikely to ever wind up being integrated into a cloud provider's primary offering until and unless the entire industry shifts, at which point we're having a radically different conversation very far down the road. Yeah, potentially, because it opens the interesting thing that if you make it so easy for someone to take their data out, do they use your cloud less? There are some cloud providers that would lean into that because they

do see more to cloud in the future than others that won't. I see it more myself that as those kind of things happen, it will be done on a product-by by product basis. For example, we're talking to an organization, could you Zetify our JDBC driver so that when users access our database, they don't have to use a VPN? We said, yeah, we've already done that with JDBC. We call it ZDBC. So we'll just, instead of using the general industry one, probably the Oracle one or something,

because that's kind of the standard, we'll take your one that you've created for yourself and be able to solve that problem for you. I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place to find you? Best place to go to is netfoundry.io slash screaming in the cloud. From there, anyone can grab some free Ziggy swag. Ziggy's our little open source mascot. Cute little piece of pasta with many different outfits. Bit of sass as well. And you can find further information both on OpenZT and NetFoundry.

And we'll put links to both of those in the show notes. Thanks so much for taking the time to speak with me today. I really appreciate it. It's a pleasure. Thanks, Corey. Philip Griffiths, head of business development at NetFoundry. 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. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me exactly why I'm wrong about AWS's VPC complexity. And that comment will get moderated and I won't get

to read it until you pay me 10 cents to tell you how it got moderated. 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 HumblePod production. Stay humble.