ULA transforms rocket development efforts with AWS

Very excited to be with you all today. We have a great customer, a great cloud journey to share with you. But before we get into that, before we get into introductions and architectures, which we have a couple for you today, let me go ahead and share this video that tells you a little bit about ULA, the great things they do and some of the collaboration they've had recently with Project Kuiper here with Amazon.

Listen to this SFE. These cars, right? The as the 20 this time. If what, how cool is that? I mean little rocket science, right? It doesn't get any better than that.

The United Launch Alliance has been a space industry leader for decades, facilitating space exploration and getting all of us closer to knowing more about the great unknown. So we're very excited to have them with us today and talk about how ULA transforms rocket development with AWS.

Before we get into some of those architectures, I want to go ahead and introduce myself and of course, key players that are making today possible. My name is Cesar Monsvice and I'm a senior engagement manager with Amazon Web Services. I have been in the IT industry for over 12 years, latter part of that specifically focused in the space and aerospace industry. And at AWS, I'm part of professional services, which is an organization within AWS that enables customers with hands on side by side, support with to help progress their, their cloud journey.

I also have a peer of mine that is in the similar organization that I wanna go ahead and introduce and that's Kyle Kin. So Kyle, why don't you tell us a little bit about yourself?

Hello, everyone. My name is Kyle Kin. I am a senior software development engineer at AWS. I work for our AWS Space Services team. So we are working on several new AWS services that primarily benefit our space customers. So stay tuned for those. But previously I had the opportunity and privilege to work in professional services as well as a senior cloud infrastructure architect where I worked to design, develop and implement cloud solutions for our customers like ULA.

Fantastic. Thank you Kyle and thank you for being here. We also have a very special guest, a man whose vision of innovation has propelled the United Launch Alliance to new heights. So go ahead and please welcome our esteemed customer, John Liepins.

John, thank you for being here believing in the power of innovation. Of course, tell us about yourself and about ULA.

Great, thank you. So I'm thrilled to be here today, surrounded by all you space enthusiasts. I'm John Liens. I'm a senior leader of software engineering at United Launch Alliance. I've been in the space industry for over 20 years now. Honestly, there's no place I would rather be. I love the missions that we support, the innovation that we've achieved together and the lives that we've transformed in the process.

So today, I'm going to take you on an inside tour of ULA, what we do and how we do it. As you may or may not know, access to space is under incredible demand right now. And that's a great business opportunity when you're a launch service provider. So that opportunity has sparked new innovation here at ULA. So we're going to talk more about that and of course, that path led us towards AWS. And so Cesar is going to come back and talk about what that engagement looked like. Kyle's going to come in and talk about the architectures that we achieved together between our AWS pro serve team and my United Launch Alliance team. And I'll come back and talk about the really promising results that we achieved along the way. And of course, we'll have time at the end for all of your Q&A. So thanks for being here.

ULA launches our government and commercial customers most challenging and crucial missions and we do it with unparalleled reliability and precision. The missions that we launch save lives. We launch missions that provide accurate earth observations that feed climate models that feed weather forecasting to help move people out of harm's way. We launch missions that provide our war fighters with accurate positioning data and intel that they need to protect freedom around the globe. The missions that ULA launches explore the inner and outer reaches of our solar system. Some recent highlights include the Mars Perseverance rover and the Parker Solar Probe and a fun fact about the Parker Solar Probe - it's currently moving around our sun at 394,000 mph. That's the equivalent of taking a flight from LA to New York in 20 seconds. And that makes it also the fastest moving, fastest manmade moving object in our solar system. So pretty cool stuff.

Our track record and pedigree of success dates back to the earliest days of space exploration. The missions we launch, connect the world, we provide global com systems, we launch global com systems that provide worldwide communications for a variety of users. And we're helping Amazon through Project Kuiper to launch their global high speed broadband connectivity to help underserved and unserved markets throughout the world. And if you watch the video, you saw the inaugural launch of Project Kiper - super exciting times both for United Launch Alliance and for Project Kiper and Amazon.

Ok. And all of that leads to our first polling question. Now that you are all experts on our space launches. The first polling question, more of a trivia question. If anything, how many successful launches has ULA had since its inception in 2006? While you're spending time thinking hard about your answer, I want to tell a little story about somewhere in our headquarters. We have a specific hall in our headquarters with pictures of all of our successful launches. It's really a humbling experience quite honestly to walk down it. We had a recent bring your kids to work day and I took my kids down that hallway and you know, they got quiet and they were, they were talking about launches. I've taken my Amazon partners down that hall as well. And it's always interesting to me the missions that people identify with. Oh, I was there when you all launched this this mission.

So for me, I think about the NPP mission, which is an earth observing satellite for weather data as a young software engineer, it was my first foray into space missions and I helped write some of the command and control software on the ground to make that mission possible. I think about GPS. The majority of the GPS constellation is launched on our rockets. And I think about the innovation that that's achieved what started off as a weapon system has turned into something that you and I use on a daily basis. Fun fact there. You know, you think of it as positioning information, but time is actually the bigger, the bigger service out of GPS, it's used in ways you do and don't recognize on a daily basis. Pretty cool stuff.

So, about 10 seconds left, contemplate your, your final answer here and lock that in if you would. And with that, we're going to go ahead and show the results of your polling.

Wow. Alright. Well, 32% of you have got that correct. Let's, let's go on to the next slide here.

158 successful launches to date - mission success is in our DNA, that gray box that you see on the bottom, right? That represents our next launch, which is going to be a really special one. I'm gonna talk about that a little bit more, coming up in a few slides.

So now that you understand a little bit about what ULA does, let's talk about how we do it. We maintain launch pads on both the east coast and the west coast. And honestly, that's a humbling experience in and of itself to drive around the cape. It's like a living museum of history dating back to some of the earliest space exploration out of the 1950s. And it's truly an honor to be able to walk around there. You feel like you're following in the footsteps of giants.

So we maintain pads on both the east coast and west coast. We produce our own rockets. So the raw materials needed for the skin rings and domes of our booster in our upper stage, our engines, all our avionics and componentry. They all enter on one side of the factory and completed rockets exit on that big bay door you see on the left side. It's one of the most amazing factories I've ever been in for starters. It's huge. It's also amazing how clean it is and just the level of rigor that we put into each and every one of our rockets and each and every one of our missions.

Those rockets we produce today, it's our Atlas and Delta four heavy rockets and coming up very very soon, we're going to be launching our inaugural launch of Vulcan Centaur, which is why it's truly an exciting time to be part of ULA and just to go into a little bit more depth on what Vulcan Centaur is going to look like.

We're starting with that track record and that pedigree of launch success that we have from Atlas and Delta. We're combining our payload faring our common booster, our Centaur upper stage with the RL 10 and the BE 4 engine to produce Vulcan Centaur to truly utilize the best of the best of everything we've done that's made this company great.

I mean, the evolution of your fleet at ULA is incredible, especially as you're discussing how you took the best of two to make Vulcan and it all leads up to one day, right? Which is launch day. Can you tell us more about that?

Yeah, so obviously when you work at a space launch company, launch day is the best day. Not only for me for all of our employees, it's super exciting. So what you see here is one of our launch control rooms. Think about this - most of the payloads that we launch into space are years of development in the making and launch day is that exciting day in which we turn all of that development that led into that mission into something that's truly operational.

So these are some of our employees that are supporting day of launch. What you don't see is the entire company behind it. It takes all of us to make these launches possible. And that's what makes it so exciting.

One of my favorite stories - I was actually standing about the same place this picture was taken and I was supporting one of our engineers that was on console. I looked at that engineer and I looked to his right and on his right was Mr. Tory Bruno, our CEO of the company on console, just like all the rest of our engineers watching our launch. And to me, it just helped to embody the sort of company that we are, every launch matters, every mission matters. We like to say that rocket science is the ultimate team sport.

I'd imagine by now you're thinking, well, gee what could possibly more, be more exciting than launching rockets? Well, there is one thing - watching them twice as often.

So one of the advantages that we have as a launch service provider is that we get to see all of the development activity in front of us of developing new missions and new payloads and we get to plan for that, right. And what the future holds for us is that we'll be moving from 10 to 12 launches per year to 25 plus launches per year, quite literally doubling our launch rate. And again, this is a great problem to have as a launch service provider. There's challenges that we recognized early on when we looked into the future. And I'm going to talk a little bit more about how we overcame some of our infrastructure and our hardware, how we scaled and how we maintained our security posture. That's so important to our mission success in the process of getting there.

So let's dive in just a little bit deeper when we talk about doubling our launch rate, just like with AWS and its services. There's specific times where you just need to provision more hardware to make things happen. We have a mobile launch platform that moves our rocket throughout the cape and ultimately supports the actual launch event. We need a second mobile launch platform to handle the load that we have of these rockets and to handle all the processing steps that go into each and every rocket that we prepare for launch.

Vertical integration is so important to our customers because of the uh intricate nature of these payloads. Vertical integration is required in most circumstances to protect those payloads so that they perform optimally in space.

I talked about our factory. And so as a result of doubling our launch rate, we obviously have to double our production rate and that poses new challenges in our factory as far as our factory lines and all throughout our supply chain. And I didn't mention we have a boat. We're going to need a second one of those to transport our rockets from our factory to our launch sites.

And all this is super exciting and and cool new developments here at ULA.

There's also things as a result of the air launch rate that we need to optimize to help us get there. We have the world's most powerful upper stage. We need to maximize that to be able to support more mass, the low earth orbit where we see this incredible rise in demand moving forward.

We also have processes that we utilize for mission assurance to make sure that each and every mission goes off flawlessly like we've executed 158 times and we have processes for mission integration which is taking the payload that we have and its unique nature, the mission that we need to be able to launch and all the uniqueness of that and marrying that up with the wide ranging capabilities of our rockets. That's mission integration.

I'm going to talk more about mission assurance and mission integration because ultimately in optimizing those two paths, it led us to the cloud all the while we need to maintain the foundation that has made ULA great our reliability, our experience, our high performance to all earth orbits and of course our security posture that is so important in protecting our missions, our customer data, our ULA proprietary information, a true asset to our national infrastructure.

So when I talk about optimizing to the cloud, and I talk about mission assurance, what I really mean is we need to dynamically validate our flight software. We need to give our engineers unfettered access to test environments to ensure the success of each of their components and the success of our software. This involves numerous simulations with real time interactions.

Mission integration. As I talked about that act of marrying up our rocket with the specific mission profile and payload that we're flying is all about data, elevated access to data, high data resiliency, expedited decision making. That's what it's all about.

And so just to dive one level deeper into our software, our flight software is quite literally the brains of a rocket. When our rocket leaves the pad, our flight software is in control of all stages of flight through separation and through disposal. This highly safety critical, we test every single mission exactly like we fly. We have a single flight sofware baseline that supports all of our launches. But it's highly parameterized in order to fly a specific mission profile for each and every mission that we support.

When I talk mission integration, just to put a few numbers behind our data, we support tens of thousands of unique vehicle telemetry parameters that are so important in monitoring the status of a rocket, its performance and continuous learning along the way so that we can tune for the next launch. We support thousands of data points that are vital in planning each and every one of our missions and hundreds of thousands of close out photos that help to ensure mission success of each and every one of our mission components.

ULA is and continues to be the experts in launching our rockets. But when we contemplated the challenges involved in scaling up our compute infrastructure to be able to support these workloads. We knew that we needed help and that's where we turned to AWS.

Yeah. Thank you, John.

AWS was more than happy to assist with ULA's challenge of having to do more and having to do it faster to do so. AWS lean on its customer enablement. capabilities and had its AWS account team and professional services organizations work together to truly understand the problem and create a plan that if executed could ultimately help them reach their business outcomes.

Therefore, by the account team and professional services team, which as I mentioned, um it's the organization, I'm a part of working together. They leveraged their cloud and space industry knowledge to develop a unique solution that was presented to ULA. And uh we worked and collaborated on in order to execute uh and advance their their cloud journey.

What we then focused on next was positioning them and positioning them in order to iterate on it. So once the the uh the proof of concept was identified, it was placed in the cloud iterated and optimized for optimal results.

So for those of you that don't know the AWS account team and professional services organizations are a dynamic duo focused on customer success. The account team focuses on strategically positioning customers like many of you in the audience to understand how the cloud is a good fit for you. But then professional services comes in and helps advance your cloud journey by doing side by side sessions and bring in expertise that helps do the hands on support to advance these projects, programs, proof of concepts and show how the cloud can help you reach those business outcomes and overcome the challenges like mission assurance and mission integration that John just mentioned with that in place ULA was in a position to work with the AWS accounting professional services and organizations which gave them the the proper support and understanding of AWS services as well as opportunities for training and certification that allowed their staff to ramp up and have an understanding of how to operate in the cloud, right? Because you're going from on premise to the cloud and that enabled them and position them for a great start to their cloud journey.

Now, the cloud journey is different for everybody. But at ULA, it was truly something unique. I mean think about it. ULA has been a space industry leader for decades with over 100 and 50 launches successfully in space 158 to be exact that shift from going on premise to the cloud was a significant change in their business model. They've been doing it for so long and had been successful at it now, they need to double it, right.

Therefore, in order to be successful and comfortable in the cloud, we have to build a strong, secure, reliable resilient and of course cust optimized foundation that allowed them to do just that in the cloud with a strong foundation in place. We then focused on identifying a proof of concept that was migrated to the cloud. It was lifted shifted enabled that mission assurance and mission integration capabilities that John discussed. And then we focused on modernizing using cloud native services so that we could do more, do it better do it faster with that in place. Then reinvention was truly in the horizon, which is what Carl was actually going to uh discuss next.

Thank you much.

Ok, go back one. So as the lead consultant for these ULA engagements, I wanted to take you through three engagements that we worked on with ULA that highlight this cloud journey.

Now for each engagement, I will go over the problems and challenges we were trying to solve. And I will also show you some architecture diagrams so that you can help or you can start to see how we use different AWS services together to deliver our solution.

So like Cessor said, the first engagement focused on building that foundation. And so we wanted to focus on three major pillars.

So the first, we wanted to ensure that our solutions met or exceeded the compliance requirements that a company like ULA who works in a heavily regulated environment has to deal with. So we architected our solutions to meet NIST 853 NIST 801 71 and CMMC compliance. We ensured that our design choices and patterns always mapped to these compliance requirements.

The second is that we wanted to focus on building scalable and resilient architectures and also design patterns. If you think back to what John had mentioned, they were scaling up the physical production systems. So we as AWS had to come in and provide scalable cloud capabilities.

And the third is we wanted to build a foundation where change was constant. We wanted to make sure that ULA could seamlessly blend AWS capabilities along with on prem capabilities that they already had deployed.

Now, when professional services works in engagement, we are always looking for opportunities to accelerate delivery and results for customers. Now, one solution we used with ULA was our AWS Landing Zone Accelerator or simply LZA.

Now LZA is a purpose built solution that addresses the three core needs. I just mentioned it helps customers that work in highly regulated environments, deploy a cloud foundation that is secure, resilient and scalable. It is specifically tailored to address the compliance needs of various different industries with different compliance standards.

So it's not just for aerospace and satellite, uh it can be used in many other different industries. Now LZA manages the complexity of setting up a multi AWS account organization structure, shared security and control policies and all of the networking that ties these components and accounts together.

It's open source and customers can download and start deploying this today. It's a great starting point for many of our customers, but some such as ULA need to customize and extend certain pieces in order to fit their own unique business and technical needs.

So I wanted to take you through four different examples of how we customize LZA for ULA.

So one of our first needs was how do we govern access to AWS ULA already had an on prem active directory server and we wanted to reuse those identities for AWS. So we use Identity Center to connect to that external identity provider.

We chose certain Active Directory groups to automatically sync and create corresponding AWS users and groups. We also created a variety of different permission sets for different types of groups at ULA such as software developers or maybe system administrators and these permission sets define the permissions and access to resources that these different groups have to do their job in a least privileged type manner.

And so when we apply those permission sets to those groups and users, they could access AWS through the single sign on portal that we had deployed for them. Now, this solution allowed us to leverage existing identities quickly on board users to AWS and it eliminated the need to set up any new IT processes for ULA.

So another need was log management ULA already had a robust on prem Splunk logging infrastructure that was part of their compliance packages. Now LZA creates the infrastructure that will collect and aggregate log information across all of your different AWS accounts and put that log information into a centralized logging account and series of S3 buckets.

So in order to reuse as much existing capability as possible, we deployed AWS resources to create a Splunk heavy forwarder that would take that aggregated centralized log information from AWS, transform it a little bit and copy it over to ULA's on prem network so that it could be ingested by their existing Splunk Enterprise.

And so because we were able to reuse existing Spunt capabilities, ULA maintained the same level of observable from their log data, whether it was coming from on prem or AWS and it eliminated the need to build any new capabilities or get any new capabilities certified.

Another need is ensuring that cloud resources are securely configured. LZA uses AWS Config to automatically scan AWS resources across all of your organization's account in order to make sure that they meet certain configuration standards that you can define AWS Config comes with hundreds of different rules that meet a broad range of use cases. But ULA did require some custom scanning for some of the resources.

So we extended AWS Config with AWS Lambda in order to scan for those resources identify when any misconfigurations occurred. And we also integrated with their ticketing system in order to alert IT security of any misconfigurations when it was appropriate.

We went one step further by adding auto remediation rules in order to automatically fix these issues. Now, this allowed ULA's environment to stay verifiably compliant, which is very important for future certification. And the auto remediation rules also lowered the total operational burden on ULA in order to have to fix any of these misconfigure items.

The final example I wanted to share is how we extended LZA to support advanced network routing. Now, internet access at ULA is restricted as a mechanism to protect, controlled but unclassified information. And this applies to both on prem and AWS.

So this presents a bit of a challenge since AWS services and endpoints are available on the open internet. And we also wanted to host capabilities in AWS. But by default, there was no way for ULA's on prem network and servers in order to access AWS resources.

So we extended LZ with a combination of Route 53 private hosted zones, VPC endpoints and some on prem DNS updates in order to provide bidirectional hostname resolution between AWS and ULA.

AWS Transit Gateway provided the network backbone in order to support this connectivity. And so what we get out of this is that ULA gets a similar end to end experience as many of our other customers.

ULA's on prem network can internally resolve and route traffic directly to capabilities hosted in AWS over their VPN. And because we are using private link, AWS traffic is kept within the AWS network and there's no need for outbound internet connectivity.

So now these four examples show how customers can deploy LZA to establish a foundational baseline level of capabilities but still have the flexibility in order to extend and add new capabilities to their overall architecture.

The sum of this work allowed us to quickly deploy a cloud foundation for ULA. We worked very closely with their IT and compliance teams in order to test and certify the platform. And when we received that certification, that gave us the opportunity to start deploying operational workloads to AWS.

So now let's transition to the next part of ULA's cloud journey, migration and modernization. But before we dive in, we have our second and final polling question that I will put up here.

So the question is what requirements do you have for application? migrations, select all that apply.

Um I'm excited to talk about this next engagement um because it was our first opportunity to really dive in and use some of these foundational capabilities that we had built in our first engagement.

Now in professional services, it's very common for us to work very closely with customers. Um in many of my own past engagements before ULA, um customers would absolutely be involved, but a lot of times they were more interested in the sprint deliverables or maybe like a retrospective session with ULA, we truly did work as a unified team.

So when professional services put together our road map for this next engagement, the ULA team proactively wanted to own different pieces and parts of that road map as a means to get more familiar and more experience with AWS.

So we worked very closely with them side by side, building out new features, fixing bugs, testing connectivity issues, uh whatever the case may be in order to deliver uh the capabilities for this engagement.

Um the manager of this team actually rotated out small groups of his developers uh to work closely with the AWS professional services team. So they got more one on one face time. So it was an approach i had never done before, but i found it to be um very effective. I think in, in leveling up the ULA team.

So I'll give folks just a couple more seconds uh to finish up the polling question.

Kyle: I think the one final thought I have about this engagement is I think the most satisfying part is that I've witnessed the ULA team continue to own and iterate on the solution, well after our professional services engagement ended, um which is really wonderful to see.

So let's swap to the poll results.

Um ok, so yeah, pretty evenly distributed. Um it seems like so probably most people are thinking, yeah, all of these apply. And so certainly when professional services works on this type of engagement, we are always concerned about all these different areas. Um and then some so if we swap back to the slides.

So with the foundation in place, we identified a business critical application that we could migrate to AWS. And one of the most important mission integration tools that John had mentioned earlier for ULA is their Parameters, Signals and Measurements application. So this is a suite of over 400 applications that handle end to end operations and testing for ULA. It's an application that is used 24/7 across the enterprise and is critical for uh rocket development operations.

So given this application's importance to begin with, plus the increased user demand that Vulcan development and this increased launch cadence would bring to the application. It made sense to choose this for migration and modernization.

So let me take you through what that looks like on AWS. So we started by rehosting the application on EC2. So we updated the code a little bit, we migrated dependencies and we also connected with the necessary on-prem resources. We use EC2 Auto Scaling groups to automatically scale our compute based on incoming demand. Now PSM can have some unpredictably spiky traffic in the days leading up to a launch. So this approach always ensured that we have enough compute capacity to meet that incoming uh demand.

Now, the computer resources themselves are placed behind an internal load balancer in order to make sure the requests are evenly distributed. Um and none of the underlying servers um reach any hotspots or whatnot. We took advantage of the networking capabilities from our foundational first engagement uh to deploy Route 53 private hosted zones that created private, internally rable uh domain names for PSM. So now this allowed users on ULA's on-prem network to connect to the application that was hosted in AWS without needing outbound internet access.

We also migrated from a single on-prem Oracle server to Amazon Aurora. So we transferred the schema we copied over the data and we deployed a cluster across multiple availability zones to improve resiliency. We also use read replicas to reduce database load and improve develop or data availability and application performance.

Now, another part of the PSM architecture uses on-prem NFS mounts in order to uh store and manage binary file data. Now, during our initial design sessions with the team, we realized that this isn't something that they wanted to support long term. So we wanted to implement an architecture that met the current need uh as PSM was designed but also provided a transition path for the application uh in the future.

So we used DataSync and S3 File Gateway to expose a series of NFS mounts to the PSM application that they it could connect to uh without needing any code changes. Now, when PSM is writing data to the NFS mounts, the data is being persisted to S3 and then synchronized with on-prem. So when the application is ready, the NFS dependencies can be removed and PSM can access the same data directly in S3.

Now this change overall reduced latency and it provided more resiliency because now both the application and also the underlying data that supports it are hosted within AWS and PSM no longer needs to connect and pull any data from the on-prem network.

So I'm happy to report that PSM is currently running on AWS. Uh it is reliably serving the tens of thousands of telemetry parameters, the thousands of data sheets and photos that John had mentioned before. Uh PSM is confidently positioned to handle the positioned to scale and handle the increased user demand. Uh that is being brought to the application. And PSM developers are also embracing more AWS managed services um because they can now focus on building more application features and functionality instead of having to worry about maintaining infrastructure or worrying about how their application is going to scale.

So after this second engagement with PSM ended the ULA and AWS team uh started our third engagement uh that really targets that last part of the cloud journey reinvention. So we were challenging ourselves to think big and really try to look for something that we could tackle with a native AWS solution.

So when we're looking at all of the challenges associated with Vulcan development and this increased launch cadence, software engineering challenges were a common thread. So for some context developers at ULA uh leverage a shared on-prem environment uh that contains all of the tools and compilers and libraries that they need to do a software development. So as more and more developers on board to this shared on-prem environment, the more software builds and tests and simulations need to be run. The need for more compute and storage simply was growing faster than what could be added to their on-prem network.

Developers also face another challenge in terms of how their application functions at the networking level. So their code has some unique networking requirements and developers spent a significant amount of time coordinating and deconflicting with other users and developers on this uh shared environment in order to make sure that their test didn't interfere with someone else's. So testing became more of a collaboration exercise rather than a software process that's done uh often uh often often.

So the AWS team took a look at this and came up with this container based solution for software development. Now the solution centers on the concept of purpose built containers that developers can spin up and use on demand. So for example, one container has that developer environment with all of their tools and libraries that they need. Another contains specialized build tools in order to run you know system wide end to end integration tests. Another container has modeling and simulation software that they use in order to test their flight software.

So here's how it works for a developer. Developers access this capability from their ULA workstation with AWS Systems Manager. Now, within the same IDE they use today, uh they run a script to dynamically spin up and connect to a development container. So within a matter of seconds, they have access to the same developer environment that they would have on-prem. But behind the scenes, these containers are being run by Amazon ECS as individual tasks, we are using our serverless offering Fargate so that ULA doesn't have to manage servers. And also uh it will automatically scale compute resources to meet the need.

We are also using Amazon EFS to provide elastic network file storage for users of this environment. So now comes the advantage of this uh container purpose built approach. So say a developer wanted to run a long running and an integration test. Instead of consuming resources from their current developer container environment, they run a script to spin up a separate container that's optimized in order to run that test and that runs in the background or say a developer wants to run a Monte Carlo simulation with hundreds of different parameters spread across hundreds of different containers.

So very similar run a script spins up those containers and the job gets run in the background while a developer continues their work, uninterrupted Amazon ECS handles the launch and scale of all of those containers. Containers are right size with just enough memory and cpu in order to efficiently complete the job. And when the job is over, the containers are shut down in order to save cost. And because we're using EFS, the data inputs and outputs from all these different containers can easily be shared across multiple different containers.

Another benefit of this approach is that containers provide a natural network isolation boundary when users are running their code. So when the developer is testing these unique networking requirements, their traffic is isolated in their container and doesn't interfere with anyone else on the same cluster. So now developers are able to run far more tests because they don't have to worry about that coordinations or deconfliction phase.

So this container development environment is helping re invent how ULA approaches software engineering. So within minutes, developers can spin up their own isolated developer environments that mirrors what they have on-prem today. And they have the self service capabilities to spin up additional containers to do and perform whatever job they have. Flight software is now being built tested and running at scale in AWS.

Software engineers can focus on writing and testing code to support Vulcan rocket development and everything else related to ULA's increased launch cadence while transparently leveraging AWS in the background.

Now, as I look back on these three engagements and yo a's cloud journey, it's really wonderful to see how our relationship has grown. So our first engagement, we established those foundational capabilities that we were using time and time again from the modernization and migration of PSM that really started to introduce uh what AWS can do for an organization and the capabilities that it can bring to this container development environment that is addressing some core technical challenges that's really helping ULA meet their increased launch cadence needs. It's been an incredible journey.

So thank you John and thank you ULA for letting us be a part of it.

John: Absolutely. It's been a pleasure working with this team and I did want to pause and take a moment. I do have a few of my teammates here in the room and I know I have quite a few uh working from home uh watching this. And uh I just want to say thank you. We really took what was a grand vision of doubling our launch rate? Uh but it was the team that decomposed that into more manageable parts.

Uh I have a very talented team but great engineers know that they need to be continuously learning. And along the way, uh my team upskilled and was able to take over the management and maintenance and continuous development of these environments in ways that really kind of surprised and delighted me uh in the process.

So, uh with that said, let's talk a little bit about the results we achieved Kyle mentioned early on and, and so did I the importance of our security posture and the protection of our data and our customers' data. Uh after we implemented our first environments, we independently audited our results against 801 71 and came back with no major findings. This is a test to the team, but also a testament to the power that AWS provided to rapidly implement a security and compliance framework that gave us the confidence to be able to move forward with our future endeavors.

And with that said, when I look back at my mission assurance right, we have um now virtual test environments that are running in AWS running test workloads and continuously verifying our software. We've reduced the timelines associated with mission integration because our data is more accessible and reliably available. Yeah. And you know, by the way, with a launch service provider, we may get lucky and launch at 3 p.m. but we may also launch at 3 a.m. right? Uh we are more or less a 24 7 operation and so highly available data for all of our engineers and launch operators is so crucial to what we do. We've achieved that uh in the process as a leader, I'm equally excited about what we've done for our teams in giving our developers and our teams the power of AWS to help to control their environments and to innovate, I've seen results that I never expected to occur environments that I thought were going to be used for one thing suddenly helped us to solve another business case that I didn't even know existed. And that was truly exciting to see as a result of going through this.

And really at the advice of our proser and our account team, we started to um kind of put the structures in place we established a cloud center of excellence that really helped to transform the culture that we have at ULA to be able to contemplate future workloads and to be able to help to govern that. Ah and so that has really made a difference in our ability to make cloud smart solutions for future workloads because our journey is far from over and I mentioned those skills that are so important to build up.

We used immersion days, we used the advice of our count and pro serve team uh to provide not only kind of shoulder to shoulder on the job type of training, but also, you know, point of need type of training to learn a new skill or a new service on AWS that made all the difference for our teams as they work through this. And so as excited as excited as I am about where we've gone, I'm even more excited about what lies ahead. This is really just the beginning already.

And as you can imagine with a rocket science company, we rely heavily on high performance compute. And for me, this has always been a very obvious and game changing type of capability to take our high performance compute onto a scalable cloud based platform like AWS. And so we've already piloted uh and are now beginning to contemplate operationalize our high performance compute workloads into AWS. And that's really exciting.

Also, as you can imagine for a company that does rocket science we generate a ton of data that we learn from, from a performance standpoint in order to tune our rockets for each and every flight. And that data has incredible value. And so we see the value in data sharing with not only our customers but also our supply chain and being able to exploit that data and make faster decisions using that data. And we see the power of AWS to help to transform us in that area.

And of course, we're already beginning a foray into a I and ML to harness the power that AWS has given us for a I and ML based solutions that we can employ to further make automated decisions using our myriad of data.

I want to leave you with two thoughts. One, I hope during this presentation, you captured some of the excitement of space and of launch and specifically at United Launch Alliance for that spirit of exploration and discovery that's in each of us. And we all remember the first time we watched the rocket launch no matter how old you are. right.

Second, I want to emphasize that powerful intersection between data and software and it with scalable cloud based services and the power that that has to transform and even re invent an organization, even one as unique as ULA.

Thank you John. Well, I wanna thank you all for coming and I hope you enjoyed the presentation learning more about AWS and how ULA has transformed rocket development with AWS. There's still a lot to come. Their cloud journey has progressed significantly in the last year and a half. There's so much more in flight. As John pointed out, if you're interested in learning more, please do reach out and if you have any questions at this time, feel free to ask. Thank you.