# Deploying Atlassian Software with AWS and Spinnaker – Part 1: Infrastructure > How to deploy Atlassian software with AWS, Kubernetes and Spinnaker: Part 1 explains the four infrastructure layers and how the deployment gets automated. Source: https://www.xalt.de/en/blog/deploying-atlassian-software-aws-spinnaker-part-1-infrastructure/ TEAM XALT Atlassian Platinum Partner · 12 April 2021 · 4 min The deployment of [Atlassian Software](https://www.xalt.de/en/atlassian-services/) can be carried out using various tools. Here, AWS in combination with Kubernetes and Spinnaker are particularly well-suited. In the first part of this series, we focus on the infrastructure for deploying Atlassian Software with AWS. By combining the benefits of Kubernetes' reliability and scalability with Spinnaker's deployment automation and application management, we obtain an environment in which we can freely deploy various types of applications without having to worry about how and where they are deployed in the infrastructure. This deployment solution defines separate levels for development and operations, as well as distinct responsibilities. This ensures that everyone is aware of the surrounding applications and the deployment process. As a result, individuals can then focus on the tasks within their designated level. Here is an example of this deployment workflow: ![Bereitstellung / Deployment von Atlassian Software mit AWS und Spinnaker - Workflow und Infrastruktur](https://cdn.sanity.io/images/c475o02b/production/6a0ccfa426dff66a6fd51589c6c49328e953c2fc-1070x749.png?w=1504&q=75&fit=max&auto=format) In this diagram, we see **four infrastructure levels of deployment**: Code Repository, Container Registry, Deployment, and Infrastructure. If a developer needs to deploy an application or create a new environment for their project, they should not have to navigate to the Deployment or Infrastructure layer. Instead, Operations should provide interfaces in the form of code repositories that allow a developer to work within their environment. Consequently, Operations will act as the administrator for the deeper deployment layers, layout rules, and process automation using their chosen deployment tools and pipelines. However, both Development and Operations should still be familiar with the entire deployment workflow and have access to all tools. ## Automations at every level Automations extend across all levels of the infrastructure. This creates a well-maintained and carefully planned pipeline to securely build, test, and deploy applications. As a result, during every deployment, Development and Operations are able to track everything happening in production and can also access aggregated information through monitoring, logging, and feedback loops. ### Containers for all applications For this entire concept to work, all applications must be containerized. The idea behind this concept is to standardize and automate application deployment as much as possible to accelerate development and the release of new features. Subsequently, the process is built up step by step to integrate applications gradually and replace old legacy installations. ## Infrastructure Kubernetes offers great flexibility and a growing number of integration options. These include multiple cloud providers, locations, and a variety of compute nodes, as well as internal networking. Therefore, the big picture of the infrastructure may differ from the diagram below depending on functional requirements and use cases. ![AWS architecture diagram: Route 53 and two load balancers on top, below an EKS cluster with three nodes, each with Spinnaker in separate namespaces](https://cdn.sanity.io/images/c475o02b/production/c4fc2e91d098a75847508d3908a00a0fc4f920da-910x664.png?w=1504&q=75&fit=max&auto=format) ### AWS Elastic Kubernetes Service (EKS) In this example, we choose EKS as a managed service from AWS, but other managed or even self-hosted Kubernetes systems could also be a valid option. Since Kubernetes does not handle the hardware configuration and distribution of compute nodes added to a cluster, we can cover a wide range of use cases with different requirements. We recommend choosing an instance type that you are comfortable with and that enables steady scalability for your applications. The size of this instance type may vary depending on the application you intend to deploy. A compute node should be capable of hosting multiple instances of the application you wish to deploy. ### Scaling clusters To enable horizontal scaling of the cluster within the infrastructure, we used AWS [Auto Scaling Groups](https://aws.amazon.com/de/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) (referred to later as ASGs), which are capable of spawning new instances and automatically adding them to the cluster when a certain load is reached. Depending on the application, you can also implement triggers here that are based on the total RAM and/or CPU utilization of all compute nodes currently part of the cluster. This ensures that the cluster always has sufficient resources for deployments. Additionally, you should not forget to add a trigger to scale the cluster back down when the total load of the compute nodes decreases. This allows you to handle load shifts and spikes securely and cost-effectively. ### Using Kubernetes tags Since Kubernetes works extensively with tags and can distribute deployments based on compute node tags. With multiple **ASGs**, you can set up and scale different instance types, configurations, and tags. Kubernetes can then deploy projects or applications to hosts with specific tags. It is also worth mentioning that the compute nodes do not need to exist in the same cloud as the master. Rather, it is possible to combine nodes from different clouds and even on-premises hardware. This requires more effort in the overall cluster network configuration. **Continue to Part 2: [Deployment →](https://www.xalt.de/en/blog/deploying-atlassian-software-aws-spinnaker-part-1-infrastructure/)** ## Ready for automated Atlassian deployment? We help you build a scalable AWS and Kubernetes infrastructure for your Atlassian deployment. [Talk to us](https://www.xalt.de/en/contact/) ## More articles ### [The Agent Harness: The Real Foundation of Enterprise AI](https://www.xalt.de/en/blog/agent-harness-foundation-enterprise-ai/) Why the agent harness – not the AI model or the generated code – determines the success of enterprise AI initiatives, and how to build one in five steps. *DevOps* ### [Governing Agentic AI Safely: Zero Trust and Compliance for AI Agents](https://www.xalt.de/en/blog/governing-agentic-ai-zero-trust-compliance/) AI agents are transforming the enterprise at speed – and the risk is growing just as fast. How the "in dubio pro securitate" principle, formal verification, and zero trust keep agentic AI safe and compliant. *DevOps* ### [Shift Left: Catching Bugs Earlier in Your Development Cycle](https://www.xalt.de/en/blog/shift-left/) Bugs found late cost time, money, and trust. The shift-left approach moves testing and quality assurance as early as possible into the development cycle. *DevOps* --- *This version is for AI agents. Every page of this site is available as Markdown: append `index.md` to its path. Index of all pages: [llms.txt](https://www.xalt.de/llms.txt)*