2026 marked probably the first time in history that data centers had been deliberately targeted in an armed conflict. We saw corporate and hyperscaler facilities damaged on multiple occasions, leading to several outages.
If you’re an infrastructure architect, you’ve probably been asking yourself an uncomfortable question: how do we keep our apps running when a cloud region might go offline unexpectedly?
And for teams running workloads on AWS Outposts Servers specifically, there’s a second question: when your service link drops, what happens to your Kubernetes cluster running on those servers?
This post explains how Palette can help answer that question (and we’ll show you how it works, too).
AWS Outposts Server: the cloud, just at the edge
AWS Outposts Servers are exactly what they sound like: a 1U or 2U rack-mounted server that AWS ships to your facility and connects back to your AWS region.
They're designed for locations where a full Outposts Rack (a 42U behemoth that mirrors a regional AWS availability zone) would be overkill — retail branches, manufacturing floors, hospital networks, edge processing sites, and really anywhere that space is measured in rack units rather than square footage.
The 1U form factor runs Graviton2-powered c6gd instances with 64 vCPUs, 128 GiB RAM, and 4 TB of NVMe. The 2U runs third-gen Intel Xeon-based c6id instances, scaling to 128 vCPUs, 256 GiB RAM, and 8 TB of NVMe. Both connect to your local network through a Local Network Interface (LNI), and both support a focused set of AWS services: primarily EC2 and ECS. What you get is AWS APIs, AWS tooling, and AWS-managed hardware, running in your building.
You get a consistent, familiar AWS operations experience at the edge, without standing up your own data center infrastructure. For organizations already deep in the AWS ecosystem, Outposts removes a lot of operational seams, including procurement hurdles — you order Outposts just like any other AWS service.
But there's a dependency baked into the design.
The service link
Every AWS Outposts Server maintains a persistent encrypted connection back to its parent AWS region called the service link. This connection is how the Outposts Server receives control plane operations, configuration updates, IAM validation, CloudWatch telemetry, and almost everything else that makes it feel like AWS.
When the service link is healthy, the Outposts Server behaves like an extension of the region. When it isn't… well.
AWS is transparent about what fails during a disconnect: mutating API calls stop working. You can't start, stop, or terminate instances. You can't launch new workloads. CloudWatch metrics and logs stop flowing in real time (they buffer locally for up to 7 days, then sync on reconnect; if you're down longer than that, you lose telemetry). IAM calls that depend on a live region connection can fail, which can block new authentication events.
What does keep running: instances already in flight on the Outposts Server continue to operate and remain reachable over the LNI. ECS worker nodes stay up. Existing traffic continues to flow. The Outpost becomes, in effect, an island: locally accessible, but cut off from its control plane.
For a lot of workloads running on ECS, this is acceptable. Stateless apps that don't need to scale, restart, or update can ride out a short disconnect. But if you're running Kubernetes (specifically if you've chosen Outposts Server as the substrate for containerized workloads that need lifecycle management), the native AWS story is more problematic. AWS EKS local clusters with a local control plane are supported on Outposts Racks, but not on Outposts Servers. On a Server, your Kubernetes control plane lives way back in the region. When the service link drops, that control plane is unreachable, and your on-premises cluster is effectively headless.
How Palette keeps the control plane on the Outposts Server
We have an answer to this, thankfully.
Palette deploys to AWS Outposts Servers using a lightweight Palette agent that runs directly on an EC2 instance provisioned on the Outpost and registers that instance as an Edge host. Once registered, Palette manages a full Kubernetes control plane running locally on the Outpost, entirely independent of the AWS service link.
If the region goes away (a fiber cut, a routing anomaly, a power event at the AWS facility, or something more deliberate), your cluster stays up, stays schedulable, and keeps running workloads. Existing pods keep running. New pods can be scheduled.
Palette also supports local application and update delivery through its decentralized architecture. Palette clusters can receive workload updates, configuration changes, and even pack updates through local mechanisms when the connection to the Palette management plane is interrupted. Lifecycle management doesn't stop because the cloud is unavailable. When connectivity returns, the cluster reconciles cleanly.
For teams in financial services, healthcare, manufacturing, defense, or any sector where regulatory requirements demand local data residency alongside operational continuity, this is a big difference.
Deploying Palette on AWS Outposts Server: a step-by-step guide
We'll assume your Outposts Server is already racked, stacked, and linked to your AWS region. What follows takes you from a fresh Outpost through a running, Palette-managed Edge host using the agent-mode deployment method.
Ensure you have ordered an AWS Outposts Server size that supports bare metal instances.
The full documentation lives at docs.spectrocloud.com/clusters/public-cloud/aws/aws-outpost.
Step 1: configure capacity on the Outposts
Before you can launch EC2 instances on the Outposts, you need to configure a capacity task that tells AWS how to allocate the Outposts Server's compute resources.
1. Log in to the AWS Console and navigate to AWS Outposts.
2. Select your Outposts Server, then choose Capacity tasks from the left menu.
3. Click Create capacity task. Select the Resource ID for your Outposts Server, then select the Asset ID corresponding to the C6id instance family.
4. Set the Instance size to c6id.metal and Instance quantity to 1. Review and create the task.
Capacity provisioning can take a few hours. Go get coffee. Come back when it's done.
Step 2: create and configure a subnet
Every Outposts Server needs its own subnet within your VPC. This subnet is what connects the Outpost to the rest of your environment.
1. In the AWS Console, navigate to AWS Outposts and select your server.
2. From the Actions menu, select Create a subnet.
3. Select your VPC ID, enter a CIDR block appropriate for your environment, and create the subnet.
4. Now enable the Local Network Interface (LNI) for device index 1 on that subnet. This is what allows Outpost instances to communicate directly on your on-premises LAN — critical for Palette Agent Mode communication. Run the following from the AWS CLI:
aws ec2 modify-subnet-attribute \
--subnet-id <subnet-id> \
--enable-lni-at-device-index 1
Note the subnet name — you'll need it in the next step.
Step 3: generate a Palette registration token
In the Palette console, you need a registration token to pair your Edge host with your project.
1. Log in to console.spectrocloud.com.
2. Navigate to your project, then go to Settings > Registration Tokens.
3. Create a new token and copy it. You'll embed it in the EC2 user data in the next step.
Step 4: launch the EC2 instance and install the Palette agent
This is where the Palette agent gets installed on your Outpost. You're launching an EC2 instance that runs on the Outpost hardware, and using cloud-init user data to configure networking and bootstrap the Palette agent.
1. In the AWS Console, navigate to AWS Outposts and select your server.
2. Click Launch instance.
3. In Application and OS Images, select a supported Linux distribution — Ubuntu works well here.
4. Confirm the Instance type is c6id.metal.
5. Under Key pair (login), select your EC2 key pair.
6. In Network settings, click Edit and select the VPC and the subnet you created in Step 2.
7. Expand Advanced network configuration and click Add network interface. Set the Device index to 1 — this attaches the LNI and enables your instance to talk directly to your local network.
8. Expand Advanced details and populate the User data field with the following cloud-init configuration, replacing the placeholders with your environment's values:
#cloud-configwrite_files: # Netplan configuration for static IP and routing - path: /etc/netplan/99-custom-network.yaml permissions: "0600" content: | network: version: 2 renderer: networkd ethernets: ens1: dhcp4: true dhcp4-overrides: use-routes: false routes: - to: <remote-network-cidr> via: <upstream-gateway-ip> ens2: dhcp4: false dhcp6: false addresses: - <interface-ip-cidr> routes: - to: 0.0.0.0/0 via: <default-gateway-ip> metric: 50 # Palette agent configuration - path: /opt/palette/user-data owner: root:root permissions: "0644" content: | #cloud-config stylus: site: edgeHostToken: <your-palette-registration-token> paletteEndpoint: api.spectrocloud.com projectName: <your-project-name> install: reboot: true stages: initramfs: - users: <username>: groups: - sudo passwd: <password>runcmd: - touch /var/log/cloud-init-userdata.log - rm -f /etc/netplan/50-cloud-init.yaml - rm -f /etc/netplan/01-network-manager-all.yaml - rm -f /etc/netplan/00-installer-config.yaml - chmod 600 /etc/netplan/99-custom-network.yaml - netplan apply - sleep 10 - apt-get update - apt-get install --yes bash jq zstd rsync systemd-timesyncd iptables rsyslog conntrack --no-install-recommends - snap install amazon-ssm-agent --classic - systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service - systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service - echo "USERDATA=/opt/palette/user-data" >> /etc/environment - mkdir -p /opt/palette - curl --location --output /opt/palette/palette-agent-install.sh https://github.com/spectrocloud/agent-mode/releases/latest/download/palette-agent-install.sh - chmod +x /opt/palette/palette-agent-install.sh - echo 'USERDATA=/opt/palette/user-data' >> /etc/environment - cd /opt/palette && export USERDATA=./user-data && sudo --preserve-env ./palette-agent-install.sh - sleep 30 - rebootA few things to note about this configuration. The Netplan section sets up two interfaces with different jobs: ens1 is your VPC-facing interface (use DHCP, but don't pull routes through it), and ens2 is your LNI interface with a static IP and a default route pointing to your local gateway. The split is deliberate: you want local LAN traffic going through the LNI, not the VPC. Do not use VPC DHCP option sets to configure the LNI; it lives on your LAN, not in AWS.
The Palette agent section embeds your registration token, your Palette endpoint, and your project name. The runcmd block installs dependencies, pulls the Palette agent installer from GitHub, runs it, and reboots. On reboot, the agent comes up and reaches out to register with Palette.
1. Launch the instance.
Step 5: validate the Edge host in Palette
Once the instance boots and the agent completes its installation (allow a few minutes), confirm it registered successfully.
1. Log in to console.spectrocloud.com.
2. Navigate to your project and select Clusters from the left menu.
3. Click the Edge Hosts tab.
4. Confirm your Edge host appears as Ready and HEALTHY.
Step 6: deploy a cluster
With your Edge host registered, you can now create a cluster profile and deploy a full Kubernetes cluster to the Outpost. Navigate to Cluster Profiles to build your stack, then create a new cluster and assign your Outpost Edge host as the target. Palette will manage the full lifecycle — provisioning, upgrades, policy enforcement — from there.
For cluster creation details, refer to the Create Cluster Definition guide.
Where to go from here
AWS Outposts Servers are very useful. Running AWS APIs and tooling on-premises, in a form factor that fits almost anywhere, is the whole appeal. But they weren't designed for a world where the region itself can be taken offline. A Kubernetes control plane that leans entirely on a region-based service link is a single point of failure. And as the AWS strikes showed, the region is now a target.
Palette removes that dependency, giving you a control plane running locally on the box, lifecycle management that tolerates a disconnect, and the ability to take workload and configuration updates even when the cloud is unreachable.
If you want to see it in action, reach out to our team or explore the full AWS Outposts documentation in the Palette docs.