🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.
Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!
Overviewct aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Deploy Amazon EKS workloads with ArgoCD and GitOps (DEV209)
In this video, Dale Orders, an AWS community builder from Australia, demonstrates deploying AWS workloads using ArgoCD and GitOps principles. He explains the four main GitOps principles: declarative infrastructure definition, immutable versioned desired state, automatic state pulling by GitOps agents, and continuous monitoring. The session covers fleet management challenges in EKS and compares deployment architectures including standalone multi-cluster, hub-spoke model, and lightweight agent approaches. A live demo shows installing ArgoCD, syncing applications from a Git repository as the single source of truth, detecting configuration drift, and scaling replicas from two to three by updating the Git repository. The presentation emphasizes infrastructure as code, continuous observability, and selecting appropriate GitOps tools for managing Kubernetes deployments at scale.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction to GitOps: Principles, Challenges, and ArgoCD as a Solution for EKS Fleet Management
Great. Shane, thank you. All right, well thank you all for being here. I know that we're nearing the end of re:Invent, so I'm excited that you're all here with me today. My name is Dale Orders, and today I'm going to be presenting a session on how to deploy AWS workloads with ArgoCD and GitOps. So on the screen here you'll see the agenda for today's session. We're going to start with a very brief introduction to who I am. I'm then going to move on to GitOps, what it is and why it is that we should be using GitOps. I'm going to cover some of the main or the four main principles of GitOps. I'm going to then delve into fleet management using EKS. I'm then going to compare fleet management using EKS to using it with GitOps and a specific GitOps tool called ArgoCD, and then at the end, I'm going to conclude with a very short demo.
So let's make a start. As I said, my name is Dale Orders. I'm an AWS community builder from Australia. I work for Five9, which is a telecommunications company, and if you wish to connect with me, that is the QR code to my LinkedIn, so feel free to reach out. With that said, let's make a start. So we should all hopefully be familiar with this. This is a simple deployment. We have here on the left-hand side a Git repository. We then have a pipeline with this pipeline. We are usually using some sort of infrastructure as code. That could be Terraform, Pulumi, CloudFormation, or CDK. We're then going to have that infrastructure stored as a state file, either locally or in a remote repository such as an S3 bucket. And we're then finally going to deploy our infrastructure to a cloud provider, in this case, EKS.
So this here is a very simple deployment, and this here is how most applications start with this one simple deployment. But they don't stay like that for long because soon you have to scale your application. So suddenly you have multiple workloads that you have to deploy. Suddenly you have to worry about how it is that you're going to configure each of these workloads, how are you going to manage the infrastructure, and how are you going to store the state file. And then it continues to scale until you have something like this. You have multiple workloads across multiple regions across multiple environments. So an enterprise application may start like this, but very soon is going to look like something like what you see on the left-hand side there.
So the question becomes, how can we manage our workloads as they scale? We know that they are going to scale, but we have to have a method of being able to effectively manage that application as it scales. This is where GitOps comes in. GitOps is a way of managing your infrastructure and your application deployments where the Git repository serves as the single source of truth. A bit later I'll show you what I mean when I say single source of truth. The most important thing though is that this single source of truth is going to ensure that we have consistency throughout our deployments. So even as we scale up our deployments, we're going to maintain that consistency.
When we look at the actual components that make up a GitOps application, we have the infrastructure as code which I mentioned previously. We also have our Git repository where we're going to be versioning and performing pull requests of all the changes that we make to our application. And then finally we're going to have CI/CD which is going to ensure that we can build, test, and deploy our application. So all three components are going to work in tandem to ensure that we can effectively scale up our application.
So the principles, what are the main principles? I said there were four main principles of GitOps. The first of which is that infrastructure has to be defined declaratively. So this is where infrastructure as code comes in. It serves to ensure that whatever we define in our infrastructure will be the resources that are going to be deployed to our environment.
Doing so means that we can enforce reproducibility in our environment. Next, we need to make sure that our desired state is stored and that it is immutable, both immutable and correctly versioned. To do so means that we are able to more effectively audit our repositories, so we can see who made what changes and when they made those changes.
We're also going to ensure that our GitOps agents are able to automatically pull the desired state from the source, so this is where the automation fits into the GitOps application. That ensures predictability, so when we do our deployments, we know exactly what resources are going to be deployed. And finally, our GitOps agents are going to continuously monitor the system and apply changes to the infrastructure, and those changes are going to be based on our desired state. Doing so ensures that we have consistency throughout the entire process, because consistency is obviously very important as we are scaling up our application. So those are the four main principles of GitOps.
Now let's look into some of the challenges that you may encounter when deploying to EKS. So here we have on the left-hand side teams that maybe are making changes to our Git repository, updating features. That is going to be pushed to our Git repository, we're going to have our pipeline, which I spoke about earlier, and then finally we're going to have our application deployed to EKS. But this poses some questions. What is the source of truth in this application, in this pipeline? Where do we find the source of truth? Is it our Git repository? Is it the artifacts that are produced from the pipeline? Is it the state file that's stored in our S3 bucket? And if there is a failure or a drift between our state file and our EKS workloads, do we then treat our workloads as the source of truth?
This is a question that we need to answer if we are to ensure that we have a fully functional application. One such way we can answer this is through the use of a GitOps tool called ArgoCD. So ArgoCD is a declarative continuous delivery tool for Kubernetes. It follows GitOps because it uses the Git repository as the single source of truth. So I'm going to take the same situation, but this time I'm going to be using ArgoCD.
So we have the teams that are going to be pushing their changes to Git. We're going to have continuous integration there. You see we have our unit test, our artifacts, our image, and our registry. We are at continuous integration, so we do have the continuous integration process. A pull request is opened which is then approved. This is merged into the main branch, which is going to be our desired state. Okay, so ArgoCD is going to pull the desired state from the Git repository. It is going to then deploy it to EKS, and it is going to continuously monitor to ensure that those two states are in sync, that the desired state is reflected in the live state in our EKS.
Alright, so very quickly, what do we see here now that we are using GitOps? Well, we see a single source of truth. Everything is in code, is in infrastructure as code, which we mentioned earlier. There is the option to roll back the application, so we won't be doing that in the demo today, but that is an option that you have. There is drift detection, so again that drift that may occur between the live state and the desired state can be remedied. And finally this integrates with CI/CD, so you can see we're still using CI/CD. This just enhances the CI/CD process. So very quickly we're going to look at some ways that you could potentially deploy your applications using ArgoCD.
ArgoCD Deployment Models and Live Demonstration of Automated Application Scaling
Here we have what's called a standalone multi-cluster deployment. We have ArgoCD which is deployed onto the cluster, and because it is cluster bound, you need to deploy the ArgoCD agent onto each and every single cluster. So in this case we have two clusters, each running an individual instance of ArgoCD. But as you can imagine, this is a lot of work, because for each of these deployments, you have an individual ArgoCD application that needs to be managed.
A better alternative is instead to use the hub-spoke model. Here you'll see we have a hub-spoke deployment. We have a central account which has our ArgoCD agent, and then we have our two workloads in a different account. These are our spoke deployments. The hub deployment, the hub agent, is going to directly talk to the cluster API to ensure that these deployments are in sync using ArgoCD. Now this here is a better alternative, but it is still not entirely ideal because with this specific configuration, you do need to ensure that there is cross-account IAM and network access. So for each additional cluster that you add, you will need to be updating the ArgoCD cluster to ensure that it has access to those additional clusters.
This here is another alternative, but in fact there's an even better alternative, which is this here. You'll see here we have our central account with our ArgoCD agent. And this time in our spokes we're going to deploy what's called a lightweight ArgoCD agent. It's going to be in each cluster, and what that agent is going to do is ensure that we can have access to those deployments. The ArgoCD agents are going to pull from the central agent using egress access, thereby reducing the need for network configuration. And so this here is a better alternative because it allows for scalability.
And this is how the user would access it. The user would use either the web UI or the CLI to access the central ArgoCD agent, and they would then therefore have access to both of the other workloads. So it provides a centralized portal to be able to effectively manage all of your workloads across as many accounts as you have.
Let's have a look at a single source of truth. So this here is, I keep saying single source of truth, but this here is the ArgoCD YAML file. Very quickly we'll go through what it entails. So you see here we define the ArgoCD project in the first block here. We then have to provide the namespace and the server. And then finally we have the source, so you'll see the repo URL. This here is going to be the repo that my ArgoCD is going to pull from. So you can see there the repo and the path that it is going to use.
Very quickly, this here is the application lifecycle. So our application is synced. If there's configuration drift, it is going to be updated. It may show us out of date or out of sync, but that sync is then going to be automatically remedied by ArgoCD, and we'll see that in the demo.
So we can start the demo. Okay, so first thing I need to do is ensure that I have connection to the Kubernetes cluster, which I do. I'm going to create the ArgoCD namespace. I'm going to install ArgoCD. So it takes a few seconds to install. I'm going to change the ArgoCD server to the cluster port on port 80, so you can see there. Whilst those pods are spinning up, I'm going to have a look at the YAML file. So this is that same YAML file I showed earlier.
I've commented out this line here, so if you wanted these syncs to be automatic, you would uncomment that line, and those syncs would be automatically applied. That is the repository that I'm using, so I've already cloned it. And the path is there, guestbook. You can see my application has a deployment with two replicas, and it has a service. Both of those manifests are already there. I'm then going to forward to my local port. And I'm going to retrieve and decode the initial ArgoCD admin password, so if you want to use the UI you do need to use the password which I've just found there and I'm just going to paste it. I'm then going to open Chrome. So you can see that this is running on my localhost. I'm going to open that. Password is admin, and then I'm going to paste in that password there. So username is admin password, I'm just going to paste in, you'll see that I don't have any applications yet. And that is because I haven't yet applied my ArgoCD file, app.yaml, which I'm going to do now. So it's saying that the ArgoCD project has been created, and there it is. But you'll see it is saying that it is out of sync at the top there. So it is saying that there's a drift between my live state and my EKS cluster. So on the left you see that nothing has been deployed, it's empty, and on the right you'll see what's going to be deployed, so I'm going to sync it. Make sure both the service and deployment are synced. And you'll start to see that two replicas are being spun up.
And I can actually check the console, and if I go down you'll see that there are two guestbook replicas. Now if I want to make a change, so say for example I want to increase my deployment to three replicas, I want to scale up my application. I'm then going to add that change to my Git repository, I'm going to commit the change and push it. And ArgoCD is going to tell me that the two states are out of sync. So I go back to ArgoCD. It's looking good, but if I refresh it, you'll see out of sync. And it's saying the deployment is out of sync, if I scroll down. On the left hand I have two replicas in my live state, but the repository is saying that I should have three, so I'm going to, given that the repository is my single source of truth, I'm going to sync it. Give it a second.
And then if I go back, scroll down, you'll see I now have three replicas, so I have effectively scaled up my application using ArgoCD. And you can also confirm this with the CLI, so I've been using the web UI but you can also use the CLI to confirm that your application is in sync. So that there is how you can use ArgoCD. So takeaways from today's session. We need to be making sure all our code, that we are using infrastructure as code to deploy all our resources. We have to make sure that our teams are aware of GitOps and that they are correctly using all of these GitOps processes. We need to ensure that there is continuous observability by using a tool such as ArgoCD.
And finally we need to make sure that we use the correct GitOps tool because ArgoCD is just one of many that are available. With that said, thank you for attending today, it was lovely to have you here. On the way out I do have, I'm Australian, so I do have some Australian chocolate called Tim Tams, so please feel free to take some on your way out and if you have any questions you're very welcome to come up to me and chat. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)