Amazon Web Services on Northflank

Select the features that your AWS integration needs. Northflank shows the corresponding permissions as a table and an inline policy that you can copy.

For ECR access, select Docker Registries. To push project builds, also select Docker Registry Push. The generated push policy includes permission to create ECR repositories.

For cluster deployment, select BYOC and any required features, such as BYOC - Custom VPC or BYOC - Static Egress. Registry-only integrations do not require these cluster features.

Open an existing provider link under Cloud → Provider links. On its Edit tab, select Verify all permissions under Credentials. If you add features, update the AWS policy to grant their required access.

The following policy is a cluster example with custom VPC and static egress permissions. Use the policy shown in Northflank for your current feature selection.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Northflank",
      "Effect": "Allow",
      "Action": [
        "ec2:AllocateAddress",
        "ec2:AssociateRouteTable",
        "ec2:CreateNatGateway",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRoute",
        "ec2:DeleteRouteTable",
        "ec2:DeleteSubnet",
        "ec2:DescribeAddresses",
        "ec2:DescribeNatGateways",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DisassociateRouteTable",
        "ec2:ReleaseAddress",
        "eks:AssociateAccessPolicy",
        "eks:CreateAccessEntry",
        "eks:CreateAddon",
        "eks:CreateCluster",
        "eks:CreateNodegroup",
        "eks:DeleteAccessEntry",
        "eks:DeleteAddon",
        "eks:DeleteCluster",
        "eks:DeleteNodegroup",
        "eks:DescribeAccessEntry",
        "eks:DescribeAddon",
        "eks:DescribeCluster",
        "eks:DescribeNodegroup",
        "eks:DescribeUpdate",
        "eks:DisassociateAccessPolicy",
        "eks:ListAccessEntries",
        "eks:ListAccessPolicies",
        "eks:ListAddons",
        "eks:ListAssociatedAccessPolicies",
        "eks:ListClusters",
        "eks:ListIdentityProviderConfigs",
        "eks:ListInsights",
        "eks:ListNodegroups",
        "eks:ListTagsForResource",
        "eks:ListUpdates",
        "eks:TagResource",
        "eks:UntagResource",
        "eks:UpdateAccessEntry",
        "eks:UpdateAddon",
        "eks:UpdateClusterConfig",
        "eks:UpdateClusterVersion",
        "eks:UpdateNodegroupConfig",
        "eks:UpdateNodegroupVersion",
        "iam:AttachRolePolicy",
        "iam:CreateOpenIDConnectProvider",
        "iam:CreateRole",
        "iam:CreateServiceLinkedRole",
        "iam:DeleteOpenIDConnectProvider",
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:GetOpenIDConnectProvider",
        "iam:GetRole",
        "iam:ListAttachedRolePolicies",
        "iam:PassRole",
        "iam:PutRolePolicy",
        "iam:SimulatePrincipalPolicy",
        "iam:TagOpenIDConnectProvider",
        "iam:TagRole"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

A cross-account role grants Northflank access to your AWS account through temporary credentials. Use this method when it is available for your selected features.

For registry access, select Docker Registries and, for project builds, Docker Registry Push. You do not need to select BYOC unless this integration also manages clusters.

1. Open Cloud → Provider links in Northflank.
2. Open the AWS provider link form .
3. Under Basic information, enter a Name. Select the features you need under Desired features.
4. In Credentials, select Cross-account role.
5. Select Copy Custom trust policy.
6. Open Roles in the AWS IAM console .
7. Select Create role → Custom trust policy.
8. Paste the copied policy.
9. Name and save the role.
10. In Northflank, select Copy AWS inline policy under Required permissions.
11. Open the new role's Permissions tab in AWS.
12. Select Add permissions → Create inline policy.
13. Paste the copied policy into the JSON editor. Save the policy with a name.
14. In Northflank, enter the IAM role ARN under Credentials.
15. Select Create provider link.

You can now use the integration for its selected features. To deploy a cluster, continue to create a cluster.

You can update the integration's shared secret and role ARN.

You can integrate AWS with an IAM user's access key and secret key. Prefer a cross-account role when it supports your selected features, because it uses temporary credentials.

For registry access, select Docker Registries and, for project builds, Docker Registry Push. You do not need to select BYOC unless this integration also manages clusters.

1. Open Cloud → Provider links in Northflank.
2. Open the AWS provider link form .
3. Under Basic information, enter a Name. Select the features you need under Desired features.
4. In Credentials, select Access key.
5. Select Copy AWS inline policy under Required permissions.
6. Open Users in the AWS IAM console .
7. Create and save a user without console access.
8. Open the user's Permissions tab.
9. Select Add permissions → Create inline policy.
10. Paste the copied policy into the JSON editor. Save the policy with a name.
11. Under Security credentials, select Create access key.
12. Select the Third-party service use case and continue.
13. Enter a description for the access key. Select Create access key.
14. In Northflank, enter the Access key and Secret key under Credentials.
15. Select Create provider link.

You can update the integration's credentials when required.

To successfully deploy a cluster on AWS using Northflank you must have the required resources available to your account for your desired region.

Check the node types you wish to deploy and ensure your cluster has access to the relevant resources. The specific quotas for each provider may differ, you will need to ensure you have sufficient quotas for your required node type, vCPU, and disk type for your desired regions.

You can change your AWS service quotas by selecting the relevant region in the console and navigating to the service quotas page. You may need to opt-in to a region first. Choose the relevant AWS service from the dashboard, or search for it on the AWS services page, then search for the relevant resource quotas to increase.

For example, to increase the number of node pools you can deploy on AWS using the m5.large node type select the relevant region in the console, search for and open the AWS service Amazon Elastic Compute Cloud (Amazon EC2), search for Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances and click request quota increase.

To add a new cluster, navigate to the clusters page in your account settings and click create cluster.

Enter a name for the cluster and select AWS as the cloud provider. Choose your integration credentials and select the region to deploy in.

Select a Virtual Private Cloud

When you create a cluster you can select which Virtual Private Cloud to use. The VPC defines public and private networks in your clusters, allowing access to other AWS services and the internet.

The default VPC includes public subnets for each availability zone, and its components cannot be modified. You should not use the default VPC for production deployments.

For production deployments, use a custom VPC to select private subnets or access other services in your AWS account. Private nodes can still receive workload traffic through public ingress. See Public and VPC ingress for cluster ingress choices. Separate VPCs are defined for each region.

You can select which subnets (and therefore availability zones) will host the control plane components for your cluster, this has no impact on the subnets that you can select for node pools. You should select between 2 and 4 subnets for the cluster's control plane.

Configure node pools

You can now configure the node pools for your cluster. Node pools can also be added, deleted, and updated after creating your cluster. Click add node pool to add another pool.

The number of pods that can be scheduled on each node is determined by networking and node scheduling limits.

Cluster networking limits

The AWS Load Balancer only allows a maximum of 500 targets per availability zone. This total includes each node pool deployed to the availability zone for that cluster.

To help avoid issues with networking capacity you should create node pools with fewer, larger nodes rather than lots of smaller nodes.

See deploy and scale node pools for more information on configuring nodes and node pools.

Configure advanced options

After adding your initial node pools you can configure advanced options for the cluster, such as build infrastructure, resource request modifiers, and volume deletion options.

When you create the cluster Northflank will begin installing system components in node pools according to their capacity. This may take up to 20 minutes.

When you create a new cluster you can select a custom VPC that you have defined in your account and selected region. You can create and manage your VPCs in the AWS console . You must create a subnet in each availability zone that you want to use, and your VPC must include at least one public subnet.

Subnets

Public subnets require an internet gateway. Private subnets require a NAT gateway for internet egress. A NAT gateway lets resources with private addresses initiate internet connections. You can use one NAT gateway for multiple private subnets, but high traffic can exceed its capacity.

Workloads on private nodes can communicate within your VPC and initiate internet connections through the NAT gateway. They can also receive public requests through a public ingress load balancer. See Public and VPC ingress to control workload ingress. Read more about connecting your VPC here .

Security

You can enable the control plane IP allow list option to block all except Northflank’s egress IP from accessing the cluster’s Kubernetes API endpoint.

IP addresses

Subnets need to have sufficient available IPs for pods and load balancers. Northflank requires at least 32 available IPs for public subnets that will host load balancers. Private subnets which will host node pools require a minimum of 64 available IPs, we strongly recommend to allocate much more (CIDR range /22, /21, or /20) depending on the number of workloads you expect to run. The default CIDR ranges provided by Amazon when configuring a subnet should be sufficient for most use-cases.

Cluster subnet selection

You can select which subnets (and therefore availability zones) will host the control plane components for your cluster, this has no impact on the subnets that you can select for node pools. You should select between 2 and 4 subnets for the cluster's control plane.

Keep at least one public subnet in your custom VPC, including for private-only ingress. You do not need to select that public subnet for the cluster.

If you are using the default VPC you can enable static egress to route the cluster’s outgoing traffic through a static IP. This is useful if you use external services that only accept requests from specified IP addresses.

If you are using a custom VPC, you must set up your own static egress IP for your cluster in AWS.

Private subnets prevent direct connections from the internet to your nodes. Workloads on private nodes can still receive traffic through a public ingress load balancer. Subnet placement alone does not make workload ingress private.

To use private nodes, create a cluster with a custom VPC that contains private subnets. Select a private subnet when you create a node pool.

You can then create a project on your cluster. Use node pool labels and Northflank tags to schedule workloads to private nodes.

See Public and VPC ingress for private ingress, client connectivity, and AWS limitations.

Northflank supports the use of AWS launch templates to customise the EC2 instances provisioned for node pools on your AWS clusters, for example to enable nested virtualization, configure node disks, or use Capacity Blocks.

See use AWS launch templates for the use cases and setup instructions.

When you create an AWS EKS cluster with Northflank, AWS automatically creates a security group to manage traffic between cluster components. This security group is initially permissive to ensure cluster functionality, but you may want to restrict it for production workloads.

How do I harden my EKS security group?

For production deployments, review and restrict your EKS security group according to your use case. AWS provides detailed guidance on which rules are mandatory for cluster operation and which can be restricted.

Common hardening approaches include:

• Restricting inbound traffic to necessary ports and sources (e.g., your VPN or office IP ranges)
• Limiting outbound traffic to specific destinations and ports required by your workloads
• Adding tags and descriptions to security group rules for audit purposes
• Using AWS security groups alongside Northflank's network policies for defense in depth

You can manage your cluster's security group in your AWS console under EC2 security groups, or programmatically using AWS APIs and infrastructure-as-code tools.