> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/integrations/integrations-overview/aws-integration/using-an-existing-vpc.md). # Using an Existing AWS VPC By default, Release creates a new, dedicated VPC when you create an EKS cluster, but you can create an EKS cluster in an existing VPC. It's important to follow the steps carefully to successfully create an EKS cluster in an existing VPC. Begin by reviewing the [eksctl documentation](https://eksctl.io/usage/vpc-configuration/#use-existing-vpc-other-custom-configuration) and ensuring the requirements listed there are in place. ## Summary of requirements To create an EKS cluster in an existing VPC, you will need: * An existing VPC with security, networking, and IP ranges configured. * At least **two** private subnets and usually **two** public subnets with all the matching route tables, security groups, and necessary gateways. * Several tags added to the VPC and subnets so that Release and EKS can pick the correct ones to attach to. ## Tagging {% hint style="info" %} Although tagging is not strictly necessary to create a functional cluster, we recommend you use the following tagging scheme when using Release to ensure your setup is stable and straightforward. Tag keys and values are flexible; Release will detect the correct tags by key or value if they contain the name of the cluster you are creating. However, for best results and supported use cases, we encourage you to follow our recommended tagging scheme. {% endhint %} ### VPC tags You need to set several tags on the VPC **BEFORE** you create the cluster so that Release knows which VPC to deploy to. Ensure that the name of the cluster you are going to create matches the variable `` wherever it is used. | Tag Key | Tag Value | Example | Notes | | -------------------------------------- | --------- | ---------------------------------------- | ----------------------------------------------------------------- | | kubernetes.io/cluster/\ | shared | kubernetes.io/cluster/production: shared | In our testing, it didn't matter if "owned" or "shared" was used. | ### Subnet tags You need to apply several tags to each subnet **BEFORE** you create the cluster so that Release knows which subnets to deploy to and what the function of each subnet is, private or public. Ensure that the name of the cluster you are going to create matches the variable `` wherever it is used. Note that you should tag private and public subnets differently and you should have at least two of each, although public subnets are optional. | Tag Key | Tag Value | Example | Notes | | -------------------------------------- | --------- | ------------------------------------------ | ----------------------------------------------------------------- | | kubernetes.io/cluster/\ | shared | kubernetes.io/cluster/production: "shared" | In our testing, it didn't matter if "owned" or "shared" was used. | | kubernetes.io/role/internal-elb | 1 | kubernetes.io/role/internal-elb: "1" | This tag should only be applied to each **PRIVATE** subnet. | | kubernetes.io/role/elb | 1 | kubernetes.io/role/elb: "1" | This tag should only be applied to each **PUBLIC** subnet. | ## Gather the information required Now that your VPC and subnets are tagged, gather the required information to fill in the fields in the Create New Cluster form **EXACTLY** as you have created and entered them in the dialog box: ![](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-21212ba8be228a6495dc32f0c88732cdfbdc1a09%2Fvpc-cluster.png?alt=media) | Name of Field | Required Information | Example | Notes | | -------------------------- | ---------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cloud Provider Integration | The cloud integration tied to your AWS account | my-AWS-integration | This is a drop-down that you cannot edit, so you need to create it beforehand and make sure it is attached to the same account with the existing resources. | | Region | The region where the existing resources exist | us-west-2 | This is a drop-down and must match the exact region where the existing resources are created. | | IP Address Range | The VPC CIDR from the existing VPC | 10.7.0.0/16 | Note that the drop-down will not show the existing VPC CIDR, you must type it in exactly. | | Kubernetes Engine Version | Choose a supported version | 1.29 | This is a drop-down showing supported versions. Compatibility between Kubernetes versions is usually plus or minus one minor version number. | | Cluster Name | The name for the new cluster | my-new-cluster | This **must match** the tags you added previously. | | Domain | The subdomain to use | release.example.com | This is the domain created as part of the cluster requirements or choose a Release-supplied domain name. | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.release.com/integrations/integrations-overview/aws-integration/using-an-existing-vpc.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.