0. Prerequisites

• AWS account with permissions to create EKS clusters, node groups, IAM roles, and load balancers.

• Tools installed on your workstation:

  • AWS CLI
  • kubectl
  • eksctl (current version; needed for Windows managed node groups)

• A Cloudmersive Private Cloud subscription with:

  • A Private Cloud node (e.g., Virus Scan API) set up in the Cloudmersive Management Portal.
  • The CMPCAccessKey (your private‑cloud access key).
  • Container registry credentials and Kubernetes deployment instructions for that node (Kubernetes OS option in the Portal).

Note: Cloudmersive Private Cloud does not need direct access to your AWS account.

1. Create or update the EKS cluster with Windows Server 2022 nodes

EKS requires at least one Linux node group in the cluster, even if your actual workload runs only on Windows, because some core system pods only run on Linux.

You’ve got two paths:

• 1A – New cluster with Linux + Windows Server 2022 managed node groups
• 1B – Add a Windows Server 2022 node group to an existing cluster

1A. Create a new EKS cluster (Linux + Windows 2022 MNG)

1. Create a cluster config file, for example cloudmersive-eks-windows.yaml:

   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   
   metadata:
     name: cloudmersive-eks
     region: us-east-1              # change to your region
     version: "1.29"                # choose any currently supported EKS version >= 1.23
   
   availabilityZones:
     - us-east-1a                   # adjust as needed
     - us-east-1b
   
   managedNodeGroups:
     # Linux node group for system pods
     - name: linux-ng
       instanceType: t3.large
       desiredCapacity: 2
       minSize: 2
       maxSize: 4
   
     # Windows Server 2022 node group
     - name: windows-2022-ng
       amiFamily: WindowsServer2022FullContainer
       instanceType: m5.2xlarge     # >= 16 GB RAM (adjust to your sizing)
       volumeSize: 100
       desiredCapacity: 2
       minSize: 2
       maxSize: 4
       taints:
         - key: os
           value: "windows"
           effect: NoSchedule
   

   This uses a Windows managed node group with the WindowsServer2022FullContainer AMI family.

2. Create the cluster:

   eksctl create cluster -f cloudmersive-eks-windows.yaml
   

   When the command finishes, kubectl context should be set to this new cluster automatically (eksctl does this for you).

1B. Add a Windows Server 2022 node group to an existing EKS cluster

If you already have an EKS cluster (with Linux nodes) and just need a Windows node pool:

1. Make sure your cluster version supports Windows Server 2022 (EKS supports Windows 2022 for Kubernetes versions 1.23+; check current docs for supported versions).

2. Create a Windows Server 2022 managed node group with eksctl:

   eksctl create nodegroup \
     --cluster <your-cluster-name> \
     --region <your-region> \
     --name windows-2022-ng \
     --node-ami-family WindowsServer2022FullContainer \
     --node-type m5.2xlarge \
     --nodes 2 \
     --nodes-min 1 \
     --nodes-max 4
   

   This creates an EKS managed node group using Windows Server 2022 optimized AMIs.

3. Confirm the Windows nodes have joined:

   aws eks update-kubeconfig --name <your-cluster-name> --region <your-region>
   kubectl get nodes -o wide
   

   You should see nodes with os / kubernetes.io/os=windows in their labels.

2. Allow outbound access to Cloudmersive Management & Update endpoints

Cloudmersive installation & updates require outbound HTTPS access from your EKS worker nodes (Linux + Windows) to various Cloudmersive and registry endpoints. At a minimum, allow outbound 443 to the endpoints listed in their KB article, including (non‑exhaustive):

• https://cloudmersive.com
• https://account.cloudmersive.com
• https://portal.cloudmersive.com
• https://servicecore.cloudmersive.com
• https://management.cloudmersive.com
• https://virusdefinitions.cloudmersive.com
• https://privatecloud.cloudmersive.com
• https://927861292015.dkr.ecr.us-east-1.amazonaws.com
• https://ecr.us-east-1.amazonaws.com
• https://api.ecr.us-east-1.amazonaws.com
• https://appsapi.cloudmersive.com
• plus the Microsoft download / container registry endpoints in the same article.

Implement this in your:

• Security Groups (egress rules),
• Network ACLs, and/or
• Corporate firewall / proxy rules.

3. Connect kubectl to the EKS cluster

If eksctl didn’t already set your kubectl context, or you’re using an existing cluster:

aws eks update-kubeconfig --name <your-cluster-name> --region <your-region>

kubectl config current-context
kubectl get nodes -o wide

Confirm:

• Linux nodes are Ready.
• Windows nodes are Ready and show kubernetes.io/os=windows.

4. Create Cloudmersive secrets in the EKS cluster

You need two main secrets:

1. Container registry credentials (to pull the Cloudmersive image).
2. CMPCAccessKey (the Private Cloud access key).

Use the values shown for your node’s Kubernetes installation option in the Cloudmersive Management Portal (they may change over time; treat those as authoritative).

4.1. (Optional but recommended) Create a namespace

kubectl create namespace cloudmersive

4.2. Create the Docker registry secret

From Cloudmersive’s generic K8s/AKS docs you’ll see a kubectl create secret docker-registry command. For EKS you can use the same pattern; just ensure --docker-server and credentials match what the Portal shows:

kubectl create secret docker-registry cloudmersive-privatecloud-registry-creds \
  --namespace cloudmersive \
  --docker-server=<registry-host-from-portal> \
  --docker-username=<registry-username-from-portal> \
  --docker-password='<registry-password-from-portal>' \
  --docker-email='support@cloudmersive.com'

Examples of registry hosts you might see (don’t guess; copy the one from your portal):

• containers.cloudmersive.com (Cloudmersive registry)

4.3. Create a secret for the CMPCAccessKey

Instead of hard‑coding the access key directly in the Deployment YAML, store it in a secret:

kubectl create secret generic cloudmersive-privatecloud-config \
  --namespace cloudmersive \
  --from-literal=CMPCAccessKey='<YOUR_CMPCAccessKey>'

Your CMPCAccessKey value is shown in your Private Cloud node details in the Cloudmersive portal.

5. Create the Cloudmersive Private Cloud Deployment & Service manifest

Copy the EKS YAML from the Cloudmersive Management Portal and save this as cloudmersiveprivatecloud.yaml:

Notes:

• nodeSelector + tolerations line up with how AWS recommends targeting Windows managed node groups that are tainted os=windows.
• type: LoadBalancer tells EKS to create an AWS load balancer (usually an NLB/CLB/ALB depending on your defaults and annotations).
• For production, you’ll likely want TLS termination on the load balancer (see “Optional hardening” below).

If you prefer to keep using a plain env.value instead of a Secret, you can revert that stanza to what you had originally, but secrets are strongly recommended.

6. Deploy Cloudmersive Private Cloud to EKS

From a shell that has kubectl pointed at your EKS cluster:

kubectl apply -f cloudmersiveprivatecloud.yaml

Check status:

kubectl get pods -n cloudmersive
kubectl describe pod -n cloudmersive \
  -l app=cloudmersive-privatecloud-virusscanapi

You’re looking for:

• Pod(s) in Running state.
• Readiness & liveness probes passing.
• No image‑pull or permission errors (if you see ImagePullBackOff, double‑check the registry secret and image URI).

If pods fail specifically on Windows nodes, AWS’s Windows diagnostics guidance and Cloudmersive’s container diagnostics KB can help troubleshoot.

7. Get the external endpoint & test

The LoadBalancer service will have an external hostname or IP that fronts your Cloudmersive Private Cloud instance.

1. Get the service details:

   kubectl get svc cloudmersive-privatecloud-virusscanapi -n cloudmersive
   

   Example output (simplified):

   NAME                                     TYPE           CLUSTER-IP      EXTERNAL-IP                            PORT(S)
   cloudmersive-privatecloud-virusscanapi   LoadBalancer   10.0.48.132     a1b2c3d4e5f6g7h8.elb.amazonaws.com     80:32521/TCP
   

2. Extract just the external hostname programmatically (optional):

   kubectl get svc cloudmersive-privatecloud-virusscanapi \
     -n cloudmersive \
     -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
   

   This is the same idea AWS uses in their Windows sample app walkthrough.([Amazon Web Services, Inc.][2])

3. Test from a browser or curl:

   • Health endpoint:

     curl http://<EXTERNAL-HOSTNAME>/virus/status
     

   • Landing page (logo):

     Browse to:

     http://<EXTERNAL-HOSTNAME>/
     

   You should see the Cloudmersive Private Cloud UI / logo. This DNS name and path form your Private Cloud endpoint for the Virus Scan API (e.g. http://<EXTERNAL-HOSTNAME>/virus/scan/file).

8. Optional: scaling, TLS, and AWS‑native load balancing

Once the basic deployment works, you can iterate:

1. Scale out replicas

   Edit the Deployment:

   kubectl -n cloudmersive scale deployment cloudmersive-privatecloud-virusscanapi --replicas=3
   

2. Add TLS

   Common patterns on EKS:

   • Terminate TLS directly on the AWS load balancer (using ACM certificate) and keep HTTP between NLB/ALB and the pods.
   • Use the AWS Load Balancer Controller + Ingress and manage TLS at the ingress level.

   Cloudmersive KB also has AWS ELB best‑practices for Private Cloud (steady health checks on /virus/status, HTTP vs HTTPS choices, etc.).

3. Private‑only access

   • Use internal load balancers (set the appropriate annotations on the Service or Ingress).
   • Restrict inbound security groups to your app subnets / VPCs only.
   • Optionally, put Cloudmersive behind an internal API gateway.

4. Autoscaling

   • Use Cluster Autoscaler with EKS managed node groups.
   • Use Horizontal Pod Autoscaler (HPA) on the Cloudmersive Deployment to scale pods based on CPU/memory.