Skip to content
Mengi Cloud Mengi Cloud Docs

AWS BYOC Setup

This guide walks you through connecting your own Amazon Web Services account to Mengi Cloud as a BYOC (“Bring Your Own Cloud”) credential. When you use BYOC, Mengi provisions and manages a Kubernetes cluster (Amazon EKS) inside your own AWS account, billed directly by AWS. Mengi only charges a management fee instead of the full infrastructure cost.

You will:

  1. Create a dedicated IAM user for Mengi (a non-human identity).
  2. Attach a policy that grants the user the permissions Mengi needs.
  3. Generate an access key (access key ID + secret access key).
  4. Store the credential in Mengi Cloud and create a cluster.

The whole process is done in the AWS Management Console — no CLI required.

What Mengi creates in your account

When you provision a BYOC cluster, Mengi creates the following in your account:

ResourceAWS product
A VPC with public and private subnetsVPC
An Internet Gateway and a NAT GatewayVPC
An EKS managed Kubernetes clusterEKS
An EKS managed node group (with optional autoscaling)EKS / EC2
IAM roles for the cluster and the worker nodesIAM
Core add-ons (VPC CNI, CoreDNS, kube-proxy)EKS

The cluster’s nodes, load balancers and EBS volumes are created and billed in your account. You can delete everything at any time from the Mengi dashboard (which cleanly tears down the infrastructure) or from the AWS console.

Required permissions

The access key Mengi uses needs permission to manage EKS, the VPC/EC2 networking it sits on, and the IAM roles EKS attaches to the cluster and its nodes. AWS does not ship a single managed policy that covers all of this, so the recommended approach is a dedicated IAM user with the customer-managed policy below.

Isolation: On other providers you isolate Mengi inside a project (Scaleway, Hetzner, GCP) or a subscription (Azure). AWS has no equivalent inside an account — the AWS account itself is the isolation boundary (IAM, billing and resource namespaces are all per-account). The direct equivalent of a dedicated project/subscription is therefore a dedicated AWS account, normally a member account created under AWS Organizations. That is the only way to get a true hard boundary. At minimum, within an existing account, use a dedicated IAM user (as below) so the key can be revoked independently of your own users — but note this is soft separation, not a true boundary.

Prerequisites

  • An AWS account with a valid payment method (EKS clusters incur AWS charges in your account).
  • Permission in your AWS account to create IAM users, policies and access keys (an administrator).

Part 1 — AWS console setup

Sign in first. Before any of the steps below, sign in to the AWS Management Console as the root user, or as an IAM user with IAM-admin rights (i.e. permission to create IAM users, policies and access keys). Without those rights the steps below will be blocked by AWS.

1. Create the IAM policy

  1. In the AWS Management Console, open IAM → Policies → Create policy.

  2. Switch to the JSON tab and paste the policy below. It grants the EKS, EC2/VPC and IAM-role permissions Mengi needs to create and tear down a cluster:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "Eks",
          "Effect": "Allow",
          "Action": "eks:*",
          "Resource": "*"
        },
        {
          "Sid": "Ec2AndVpc",
          "Effect": "Allow",
          "Action": [
            "ec2:*",
            "elasticloadbalancing:*",
            "autoscaling:*"
          ],
          "Resource": "*"
        },
        {
          "Sid": "IamForEks",
          "Effect": "Allow",
          "Action": [
            "iam:CreateRole",
            "iam:DeleteRole",
            "iam:GetRole",
            "iam:TagRole",
            "iam:UntagRole",
            "iam:ListRolePolicies",
            "iam:ListAttachedRolePolicies",
            "iam:GetRolePolicy",
            "iam:PutRolePolicy",
            "iam:DeleteRolePolicy",
            "iam:AttachRolePolicy",
            "iam:DetachRolePolicy",
            "iam:PassRole",
            "iam:CreateServiceLinkedRole",
            "iam:CreatePolicy",
            "iam:DeletePolicy",
            "iam:GetPolicy",
            "iam:GetPolicyVersion",
            "iam:ListPolicyVersions",
            "iam:CreatePolicyVersion",
            "iam:DeletePolicyVersion",
            "iam:TagPolicy",
            "iam:UntagPolicy",
            "iam:ListEntitiesForPolicy",
            "iam:CreateInstanceProfile",
            "iam:DeleteInstanceProfile",
            "iam:GetInstanceProfile",
            "iam:ListInstanceProfiles",
            "iam:ListInstanceProfilesForRole",
            "iam:AddRoleToInstanceProfile",
            "iam:RemoveRoleFromInstanceProfile",
            "iam:CreateOpenIDConnectProvider",
            "iam:DeleteOpenIDConnectProvider",
            "iam:GetOpenIDConnectProvider",
            "iam:TagOpenIDConnectProvider"
          ],
          "Resource": "*"
        }
      ]
    }

    The iam:*Policy* actions are required because Mengi creates customer-managed policies for the AWS Load Balancer Controller (and Karpenter, when autoscaling is enabled); the iam:*InstanceProfile actions (including iam:ListInstanceProfilesForRole) are needed for the autoscaling (Karpenter) path and for clean teardown — deleting an IAM role makes AWS list the instance profiles attached to it first. Omitting these causes provisioning to fail with AccessDenied on iam:CreatePolicy, or deletion to fail with AccessDenied on iam:ListInstanceProfilesForRole.

  3. Click Next, name it e.g. mengi-cloud-byoc-eks, and click Create policy.

This policy is intentionally broad on EKS/EC2/IAM because Mengi creates the full networking stack plus the IAM roles and policies EKS and its controllers need. If you want tighter control, run Mengi in a dedicated AWS account where this scope only ever touches Mengi’s resources.

2. Create an IAM user

  1. Go to IAM → Users → Create user.
  2. Name it e.g. mengi-cloud-byoc.
  3. Do not enable console access — this is a programmatic identity only.
  4. On the Set permissions step, choose Attach policies directly and select the mengi-cloud-byoc-eks policy you just created.
  5. Click Create user.

3. Generate an access key

  1. Open the mengi-cloud-byoc user → Security credentials tab.
  2. Under Access keys, click Create access key.
  3. Choose Third-party service (or Application running outside AWS) as the use case and confirm.
  4. Copy both values now — the Secret access key is shown only once:
    • Access key ID (e.g. AKIAIOSFODNN7EXAMPLE)
    • Secret access key (e.g. wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)

You now have the values Mengi needs:

ValueWhere it came from
Access Key IDThe user’s access key
Secret Access KeyThe user’s access key (shown once)
Default Region (optional)Any region you plan to deploy to, e.g. eu-central-1

CLI alternative (AWS CLI)

If you prefer the AWS CLI, Part 1 is three commands. Save the policy JSON from Step 1 as mengi-cloud-byoc-eks.json first, and make sure the CLI is configured with an admin profile (aws configure).

Terminal window
# 1. Create the IAM policy
aws iam create-policy \
  --policy-name mengi-cloud-byoc-eks \
  --policy-document file://mengi-cloud-byoc-eks.json


# 2. Create the IAM user and attach the policy
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws iam create-user --user-name mengi-cloud-byoc
aws iam attach-user-policy \
  --user-name mengi-cloud-byoc \
  --policy-arn "arn:aws:iam::${ACCOUNT_ID}:policy/mengi-cloud-byoc-eks"


# 3. Create an access key — the output shows the secret only once
aws iam create-access-key --user-name mengi-cloud-byoc

The create-access-key output maps onto Mengi’s form:

CLI output fieldMengi field
AccessKey.AccessKeyIdAccess Key ID
AccessKey.SecretAccessKeySecret Access Key

For the dedicated-account isolation model, create the member account first with aws organizations create-account, then run the three commands above inside that account.

Part 2 — Store the credential in Mengi Cloud

  1. Sign in to the Mengi Cloud dashboard and open Cloud Credentials from the left-hand menu.
  2. Click Add Credential.
  3. Fill in the form:
    • Credential Name — any label, e.g. aws-byoc.
    • Cloud Provider — select Amazon Web Services.
    • Access Key ID — paste your access key ID.
    • Secret Access Key — paste your secret access key.
    • Default Region (optional) — e.g. eu-central-1.
  4. Click Add Credential.

The credential is stored encrypted and starts in Pending Validation. Mengi validates it by calling AWS STS GetCallerIdentity; once the call succeeds the status turns to Ready. If it shows Invalid, re-check the access key values and that the mengi-cloud-byoc-eks policy is attached to the user.

Part 3 — Create a BYOC cluster

  1. In the Mengi dashboard, click New cluster.
  2. Choose a cluster type: Dedicated (1 control plane + 1 worker) or Dedicated HA (3 control planes + 3 workers, with SLA). BYOC is not available on the Development type (see note below).
  3. Choose AWS as the provider.
  4. On the configuration step:
    • Give the cluster a name.
    • Enable Use my own cloud credentials (BYOC) and select the aws-byoc credential.
    • Select a region — the AWS picker offers us-east-1, us-east-2, us-west-1, us-west-2, eu-west-1, eu-west-2, eu-central-1, ap-northeast-1, ap-southeast-1 and ap-southeast-2.
    • Click Create cluster.

Mengi provisions the VPC, EKS control plane and managed node group in your account. The cluster moves through pending → provisioning → running (EKS typically takes 20–25 minutes). Deleting it from Mengi tears the infrastructure back down in your account.

BYOC is not available on the Development type — those are virtual clusters on Mengi’s own shared host infrastructure. Use Dedicated or Dedicated HA for BYOC.

Rotating the access key

  1. In the AWS console, create a second access key for the mengi-cloud-byoc user (Part 1, Step 3).
  2. In Mengi, edit the aws-byoc credential, paste the new access key ID and secret access key, then re-validate.
  3. Once the new key is Ready, deactivate and delete the old access key in the AWS console.

Revoking access

To cut Mengi off entirely, delete the access key (or the whole mengi-cloud-byoc user) in the AWS console. Delete any running BYOC clusters from the Mengi dashboard first so the infrastructure is cleaned up — once the key is gone, Mengi can no longer tear those resources down for you.

Security notes

  • The secret access key is shown only once at creation — store it securely and never commit it to version control.
  • Prefer a dedicated IAM user (or, better, a dedicated AWS account) so the key can never touch the rest of your organization.
  • Mengi stores BYOC credentials encrypted, not in plaintext.
  • Rotate the access key periodically.