#745: Accelerating Cloud Migration: How Occidental Petroleum Transformed with Terraform and AFT

0:00This is episode 745 of the AWS podcast, released on November 10th, 2025. Hello, everyone, and welcome back to the AWS Podcast. I'm Lish here with you. Great to have you back. And I'm joined by two very special guests today. Firstly, I'm joined by Brian Moore, who is a cloud architect with Occidental Petroleum in Houston, Texas. Occidental is also known as Oxy. He leads Oxy's cloud computing practices and has spearheaded strategy and adoption of AWS at Oxy. He's also passionate about evangelizing DevOps culture and finding better ways to automate everything. Sounds like a man after my own heart.

0:33Welcome to the podcast, Brian. Thank you. It's good to be here. It's good to have you here. And we're also joined by Chris Spitzenberger, who is a senior solutions architect here at AWS, also worked very closely with Oxy on this and knows a bunch of stuff that's really relevant. Chris, welcome to the podcast. Thank you. Also glad to be here. Awesome. Now we're going to talk about some cool stuff today. We're going to talk a bit about a cloud transition, a sort of an approach that was taken rapidly and at pace. But before we do that brian tell us just a little bit about oxy for our global audience so i understand a little bit about your organization um what you were dealing with in terms of uh the transformation sure so yeah oxy uh is a oil and gas company based in houston texas um we also had to do chemicals there's oxy chem is another subsidiary so like i think we're like the largest uh pvc producer in the world um we also do a carbon capture business so that's another subsidiary um so yeah we we have uh operations all around the world like oman uh algeria south america so you know we're definitely a globe have a global footprint and that's where you know the need for digital transformation around the globe really drove the need for us to move into the cloud because traditionally we were all there for a very long time interesting and i guess that's the thing is that you know it's a very common common situation that you grow to a certain level and you do a lot of great work especially globally and the overhead of managing all that becomes quite challenging i'm assuming exactly yeah exactly and then you know the disruptivity uh moving to a more scalable way of doing things that also create a lot of challenges for us in just terms of skilling and the way we work um you know so i know we started on azure initially and you know that's where we got started in in terraform but it was like it's a very small team operating that way for many years.

2:32And like, you know, we decided to move to AWS and that created this sort of call to action. Hey, we need to make this same transformation across the enterprise, across all of the IT department. So that's where, you know, we started going, okay, we need to find a more scalable way to set up all these AWS accounts. For example, like we have a really amazing data architect, Like Jamie Johnson, he's driven the adoption of this data mesh architecture, but it requires like tons and tons of AWS accounts. And we needed to sell the form. Like we're expecting so many, like hundreds of AWS accounts over time.

3:11And we need to automate this process. We need to make sure we can keep AWS accounts, you know, consistent, have a repeatable pattern and be able to maintain that pattern and, you know, iterate on it. And so that's where, hey, we do everything with Terraform. We love Terraform. We try to apply Terraform where we can. And so there's an offering, you know, AWS account factory for Terraform, where you have a Terraform framework for calling Control Tower to spin up an AWS account, but then also provision all these baseline resources, depending on what kind of account it is, you know, whether it's, you know, more public facing or internal facing, like you might get a different network architecture, you know, production versus sandbox, et cetera.

3:54So we've got a very useful, you know, bringing our existing Terraform skill set to bear in using that. Let's talk about that because you've obviously mentioned the fact that you're very passionate about automating things, et cetera. And it's always tempting to write your own tooling and your own scripting, et cetera. And you've adopted Terraform, which I know a lot of organizations have as well. There's many pathways and none of the pathways are wrong or right. They're just different pathways. What helped you choose Terraform, this approach, and also, I guess, the multi-account approach you were taking as well.

4:28Yeah. I mean, with Terraform, it's sort of the key to the city and the cloud. Everyone does Terraform. You learn Terraform. It takes you to so many places. And if you try to do an in-house script, because I know our IT department has gone down that path of, oh, have an internal framework to do something, and it's bit them forever because they have to maintain it. And yeah, it's... It's hard work. Lessons have been learned in the past. let's not go down that road again. Let's go with the gold standard. Let's go with what we know works, what we're going to get support from AWS. And we continue to get new releases of AFT from AWS, new features, bug fixes.

5:07And so it's a big limit off of our shoulders. I think actually Chris had initially given us the idea for AFT. Is it all your fault, Chris? Oh, yeah, it probably is. I was working in AWS professional services at the time. We were a team worker with Oxy, the mass migration project. And I believe we were the ones who ultimately recommended AFC. It's a solution maintained by the AWS Control Tower service team. And it, of course, allows you to use Terraform, like Bran said. But it worked well. Yeah, I think the interesting thing here is there's always this sort of tension, for want of a better word, between using a generalist tool that can work across everything versus getting access to key capabilities of a particular platform or cloud or capability or what have you.

6:01And so I guess with this, Brian, you've been able to sort of combine the both, whereas, you know, it's hooking deeply into what you can do within Control Tower, et cetera. But from a user perspective, it's Terraform. It's like, it's familiar. Yeah, yeah. it's like it's it's a it's a skill that we know but it's a general framework to run any code that we want and afd has lots of different hooks like i know so we have uh another team that maintains you know azure devops and like okay you want uh git repository and azure devops project i mean yeah i know azure devops is kind of old but um we'll move to get up eventually but uh we had like code lanny's i was like hey you know if someone wants to get started uh with you know Git repository, projects, boards, and like, okay, connections from that to your AWS account, like, you know, have an automated process to do that.

6:54Well, that's where we had, okay, AFT has these lifecycle hooks. They're called provisioning customizations, but that's where you basically can add a step function and say, hey, you know, a new AWS account got created, and we just hooked it up to HashiCorp Vault. That's another product we have. and need to communicate that to the platform engineering sort of DevOps framework so they can hook things up on their side. So there's all kinds of opportunities. Hey, okay, yeah, you control the baseline stuff that gets up in the account, but then also notifications, events be afforded to other places as well.

7:29So rather than being, I guess, a generic thing, it's really letting you have that flexibility to give the users what they want and what they need. Yes, yes. yeah like there's definitely been like times where we've had to customize AFT a little bit just in terms of okay like the baseline uh was kind of assuming you know it's mostly assuming that you're you're working within the same region as the like the control tower home region it was like okay you know like this would work a little bit better if I may so oh when I specify my Avis account I want to just arbitrarily say oh well it's gonna be set up in these this many different regions with this many different default VPCs.

8:08And that's what we had to do, like a little bit of fun, okay, the information that the code build passes to the Terraform configuration, let's mess with the provider.tf a little bit to make that easier. Otherwise, it just won't work. So let's talk about, I guess, from a process perspective, you sort of touched on the fact that you can kind of vend things pretty quickly and what people need. But what does this look like in terms of, I guess, the speed and efficiency of the way Oxy works in the migration to the cloud? like what what did it help with from an end user perspective from an user perspective like there were there were days when like hey uh this one team i'm talking about the the the it's called odaf is the the data mesh architecture but like someone would literally request like 10 10 it is accounts or something yeah and like okay you know we're waiting on this uh to set up you know dev stage prod uh accounts for you know a couple different groups and you know like we could turn around very quickly just like okay got your requirements and just basically copy pasting some some terraform uh configuration code uh where we define our accounts and it's just very easy we actually have some a little bit of code generation even for that uh to make it really streamlined so like it was just very rapid turnaround and not only not not just initial standing up because sometimes uh you know like you're not going to get everything right the first time.

9:31It was like, okay, you know, we started out with decentralized VPC endpoints where we had VPC endpoints set up in individual accounts, but then it's like, okay, well, we need to migrate to more of a centralized architecture to save costs because we didn't want to pay for, you know, so many VPC endpoints in every single A-Bus account, whether it was being used or not. Okay, let's consolidate into a more centralized approach. I think it's more best practice. And then that that created an impact where, okay, well now we've got this new version of the account pattern and now we've got to roll it out.

10:01And then we've got like, you know, at that point, if you have 150 address accounts, now we've got to rerun the apply, you know, across all of those. And that made it really easy. That's amazing. And I guess the other thing is also from an organizational perspective, one of the most frustrating things of doing any project is waiting for other teams to do what they need to do. So not being that sort of bottleneck of, you know, I can't move forward till my accounts are created, but my accounts are taking too long. You're just eliminating that frustration. Yes, exactly. Exactly. So I guess in our relationship, in practice, it kind of moves the bottleneck elsewhere, but at least it's not us.

10:40Well, look, life is moving bottlenecks around, really. I know, exactly. You're eventually trying to smooth things out as well as possible. In fact, one of the things that I thought was interesting was you touched on that piece of not wanting to have sort of too many networking components going on. And you really automated this a lot. How did you use AFT to standardize your networking? Was it just don't create these things or was there more robustness that you wanted to build in about the network strategy? Whenever we define the AWS account, we say, okay, is this going to be a public-facing account?

11:15We call a certain pattern. Is this a sandbox account? We call a certain pattern. But basically, each one of those patterns calls our Terraform modules. So we use Terraform Cloud, those Terraform modules, and the modules will define the standard networking Terraform. So, okay, I'm going to make a VBC. It's going to have three availability zones by default. It's going to have a SudNet, any availability, something like a private SudNets, transit gateway SudNets. So we kind of planned out the standard network architecture for an application account. So basically, it's making it easy to just repeat, rinse and repeat.

11:56And I guess, Chris, maybe you want to jump in here and talk about what was going on with the networking component, but also maybe a little bit more about AFT and why you even talked about AFT with Oxy. yeah definitely from it from networking perspective that's one of my favorite things about working at the aft when you're stamping out you know these accounts uh what are the fundamental things you need uh when working at abs uh typically i mean not always uh you know as a vpc and subnets uh if you want to work with compute resources typically you need those things but anyways one of the things we're doing with aft um through the customizations feature you know we can mention there's different patterns there's the terminology in aft is customization so we had different customizations for different scenarios.

12:38We first deploy the VPC and deploy the subnets, but what was happening is we were actually leveraging the AWS IPAM, IP address management feature, and dynamically leasing IP space for the VPC, using that lease space and subnetting it out. So these things were happening dynamically. So basically at the account request level, you wouldn't have to worry about the management of all your overlapping ciders. no more spreadsheets. You can just say, I want to slash 23 DPC. And then even as simple as that, passing it into our module, which then knows how to interpolate that into subnets and break it down.

13:17But taking that a step further, something that I really am proud of that we did is we actually set up an integration with Palo Alto Panorama. So based on account tags, we could actually create firewall rules for that VPC and basically tag things and dynamically set up that entire VPC into our network inspection process, which is a pretty cool integration. So not only were we deploying the VPC, deploying the subnets, all the other standards that we're deploying with the account, but we're also setting things up panorama. So we are no, you know, what to expect and we can lock down that traffic even further.

13:59So it really - Secure by default is a beautiful thing. Yeah. Yeah. Yeah. Although like sometimes we've encountered challenges, like the Panorama integration is an interesting example because so like the Panorama integration is great. And then recently there was sort of an incident where, you know, someone didn't really realize that the Ciders are being integrated and managed by Terraform. And so like someone was in the Panorama console doing click ops. and like oh well i need to move the device group around like you know we got to rearrange things so like someone's like sat down and spent like four hours in the console moving like 600 objects in the panorama and like it just completely broke any connection like now now terraform and this is across hundreds of workspaces because every account is uh two workspaces but one of them but i know i didn't tell you about this but it's caused so much pain but like make sure everyone knows that it's managed by terraform like lock it down we're actually looking at some way in panorama to like define a policy but hey like you can't touch this like we can't we can't make those teams use terraform yeah yeah we don't manage everybody's stuff yeah but like at least you know lock yourself down from being able to manage this because it's being managed by terraform well i guess the good thing is the fact that it is managed by terraform means you know what it looked like before someone click opt it yes yes exactly that that has helped and i guess brian And this touches on something I wanted to ask is, you know, what are some of the lessons you learned about, I guess, cloud adoption and Terraform and AFT that others could benefit from?

15:30Obviously, you know, don't click ops or reduce click ops as much as possible, which is a good practice anyway. Because I often say if you're doing it in the console, you're probably doing it wrong. Yes. Yeah. So, you know, well, the first thing, block people from customer resources that AFT manages. So, like, we introduced a tag managed by AFT. So there's an SCP that basically, I think it's permissions boundary. I think we put in the permissions boundary. You can't touch anything that's managed by AFT. So yeah, I talked about the provider. So like, I think there was a recent enhancement to the AWS Terraform provider where with a single AWS provider, you can do multiple regions.

16:08But historically, that hasn't been the case. Like for every region that you want to use, you had to find a separate AWS provider block. But like, you know, that was so recent that we couldn't really benefit from it. Because instead, we were having to do dynamic ginger code generation to generate different provider blocks for every AWS region. And I guess that's the classic thing of working in the cloud and working with cloud-based tools is they evolve. They evolve when people say, hey, I don't want to do it this way anymore. And it's not like, well, sucks to be you. It's like, oh, great. We'll make a change and get a new version that has what you need.

16:45Yeah, but at least having things defined this code makes you more resilient to change and able to manage change yeah and and speaking of that you know culturally how have you worked with within oxy to help other folks kind of embrace this you know passion for automation and repeatability etc what have been what have you found works in terms of helping people adjust maybe their mindset around how to operate sure yeah i've had like uh lunch and learns and presentations that i've given to people um that that helps at a high level of okay from a high level where are we coming from um it helps as an icebreaker i found now people say oh you've explained it in a way that made sense at a high level but at some point you have to get hands on keyboard and that usually in my experience that evolves just like sitting down with someone and kind of pair programming with them helping them hey you know okay you need you need to build uh something let's sit down together and do it because you know unless you you learn to do it yourself you're never going to take ownership of it um but so we had a lot of i guess failed starts in that like people thinking okay well we'll just get this get this done really quickly and then they'll they'll keep it going but then it kind of fizzles out um and maybe comes back to the to the devops team which i think is kind of an organizational anti-pattern, but it's a lot of work.

18:10So we've had, you know, sort of an enterprise infrastructure as code program where we train people on how to use our code landing zones. The code landing zones is basically a framework for, you know, getting everyone bootstrapped with like a best practices Terraform repository that has a connection to your ADS account and has pipelines that are deployed to AWS. So yeah, there's just been a lot of training well yeah it's it's kind of like you know you got to show people and see what the difference is and it's i i think if you can show people that it makes their jobs easier and faster you're going to get adoption if it's just seen as more complicated then you're not going to get adoption so that's kind of like yeah yeah you got you got to prove the value and it takes time and there's there's been a lot of skepticism but over time like it wins out like it's just you cannot manage all this stuff at scale.

19:02That's, that, that's, uh, you know, that's the point, isn't it? At some point there's, there's too many things to look after. And, um, if you're trying to keep it in a spreadsheet or in your head, you're going to make mistakes, like stuff's going to go wrong. Stuff always goes wrong, but if it's in source control, it makes it look a lot easier. Yeah. You can roll it back. Exactly. Um, Brian, thanks so much for coming on the show and sharing us a bit about your journey. It's always great to hear from customers who can tell the story from a position of reality. We did it. We used it. It had benefits.

19:35There was challenges. We overcame the challenges. Welcome to IT. Thank you. And Chris, thanks for sharing with us the genesis of the idea. And it must be quite satisfying for you to see a customer like this really automating and moving forward with this technology. Yeah, it's amazing. I'm really proud of seeing them go from 0 to 100, quite literally, really 100 plus. Yeah, 300 plus at this point. It's fantastic. And so thanks a lot for coming on as well. And for those of you who want more information, there's links in the show notes about how AFT works and things you might want to think about.

20:15And of course, until next time, keep on building.