Across accounts and regions deployment to EKS with Amazon CodeCatalyst

Amazon CodeCatalyst, officially launched on April 20, 2023, is a unified software development service designed to simplify the development, collaboration, and deployment processes for software teams. It integrates various tools and practices into a single platform to facilitate continuous integration and continuous delivery (CI/CD). Amazon Elastic Kubernetes Service (Amazon EKS) is a managed service that simplifies running Kubernetes on AWS without the need to install and operate the Kubernetes control plane or nodes yourself.
The CodeCatalyst workflow currently provides built-in Kubernetes actions to easily deploy applications to Amazon EKS. The EKS API server offers both public and private endpoints for external services. For security reasons, application deployments in EKS are typically done through the private endpoint of the API server. Additionally, in enterprise environments, business teams often have their own accounts and network address allocations on Amazon Web Services based on compliance and security considerations, meaning that each team's EKS cluster is deployed in different accounts and VPCs. Furthermore, the CodeCatalyst service is currently only available in the US West (Oregon) and EU West (Ireland) regions, and the Amazon Web Services console and CodeCatalyst console are independent of each other, each having its own account system. Interactions between CodeCatalyst and Amazon Web Services resources require public internet access. If you need to use CodeCatalyst to deploy applications through the private endpoint of EKS across multiple Amazon Web Services accounts and regions to meet business expansion and security compliance requirements, can CodeCatalyst meet these needs? The answer is yes. In November 2023, CodeCatalyst announced support for Amazon Virtual Private Cloud (Amazon VPC), allowing you to create VPC connections between CodeCatalyst and your VPC. Amazon CodeCatalyst can utilize all the features of VPC, and you can use VPC peering connections (or transit gateways) to allow CodeCatalyst to deploy applications to EKS in another region. Additionally, the environment management feature of CodeCatalyst can associate with multiple Amazon Web Services accounts, enabling cross-account resource access. This blog post will guide you on how to use and configure CodeCatalyst for cross-account and cross-region deployment of applications to EKS clusters.

Amazon CodeCatalyst provides a powerful integrated environment for continuous integration and continuous delivery (CI/CD). By leveraging CodeCatalyst, you can automate the deployment of applications to multiple EKS clusters, regardless of their region or account location. In the following case, we have a CodeCatalyst space named "testing1" associated with the account "8995xxxxxxxx" in the us-west-2 region. The target account "4729xxxxxxxx" has a ready-to-use EKS cluster in the ap-northeast-1 region. We need to deploy the application to this EKS cluster. The diagram below illustrates the architecture and workflow: When the CodeCatalyst action runs, it creates corresponding elastic network interfaces (ENIs) within the VPC using the VPC connection feature, allowing the action to access other resources via the internal network. Note that the ENIs do not have public IP addresses. Therefore, a path to the internet must be provided, and this internet connection enables CodeCatalyst to access APIs and public repositories like GitHub, PyPI, NPM, and Docker Hub. In this example, a NAT gateway is used to provide the internet connection.

Before you begin, please ensure you meet the following prerequisites:

CodeCatalyst only supports creating VPC connections in the same region(Limitations of VPC connections in CodeCatalyst). Here our space is in us-west2, so we need to create a VPC for workflow account in region us-west-2. It must meet the requirements for the VPC that CodeCatalyst can connect to. Below are some key requirements:

Once the VPC is created successfully we can create a VPC connection for it. The VPC connections allows CodeCatalyst to create workflow ENI for interacting with resources in your account. You must create one connection for each AWS account you want to use with your CodeCatalyst space.

According to the guidelines, create VPC peering connections for the workflow VPC and the target VPC (in this case, we use VPC peering to connect the two VPCs, but you can also achieve this through a transit gateway).

As we need to deployment apps to EKS cluster in target account (Please note the connected account can also be used as the billing account for the space if you choose to use a paid tier), we add the account and role (the role is used for EKS deployment so please make sure it is attached EKS policy) to CodeCatalyst.

Although we already have the account and VPC connection, the CodeCatalyst workflow cannot directly start deploying applications yet. To enable these deployments, we must set up the CodeCatalyst environment. The CodeCatalyst environment (do not confuse it with the development environment) defines the target AWS account and optional Amazon VPC that the CodeCatalyst workflow connects to. The environment also defines the IAM roles required for the workflow to access AWS services and resources in the target account. We can set up multiple environments and name them, such as development, testing, pre-release, and production. When we deploy to these environments, information about the deployment will be displayed in the deployment activity and deployment targets tabs in CodeCatalyst. Let's create an environment named "eks-dev-env" for later workflow deployment.

Please note that although the IAM role created by CodeCatalyst can access EKS, it cannot perform any operations on Kubernetes resources within EKS, meaning it cannot deploy applications to EKS. You can use the EKS cluster access management feature to add this role as an IAM access entry with sufficient policies to allow it to operate on Kubernetes objects. Additionally, please check the security groups of EKS to ensure they allow inbound traffic from the CodeCatalyst workflow ENIs. It is also important to note that the cross-account and role point to the target account, while the VPC connection points to the workflow account.

A workflow is an automated process that describes how to build, test, and deploy code in a continuous integration and continuous delivery (CI/CD) system. The workflow defines a series of steps or actions to be executed during the workflow run. It also specifies the events or triggers that initiate the workflow. To set up a workflow, you can use the visual editor or YAML editor in the CodeCatalyst console to create a workflow definition file. Since the workflow needs to be associated with a code repository, we will first create a code repository (to store the YAML files and related content, such as image versions, required for the EKS deployment).

Let’s create configurations file in the repo:

In the next step, we create a workflow by selecting the repo we just created.

Edit and update the workflow content as below:

Then we need to update Compute type of workflow:

Modify the configuration required for the DeployAppToEKS process:

Once completed, click Commit, then click Action to run the workflow once and observe the execution results.

This blog describes the main process of using CodeCatalyst to achieve cross-account and cross-region deployment of EKS applications. With this setup, you can manage and execute deployment tasks for container applications on a one-stop DevOps platform while maintaining network connectivity and security between different accounts and regions. Here, we summarize some key steps mentioned: