re:Invent 2019: Outposts, EKS on Fargate, and the Hybrid Future

I just got back from Las Vegas, where AWS held re:Invent 2019. This was my third consecutive re:Invent, and every year the conference gets bigger and the announcements get denser. Over 65,000 attendees this year, spread across six venues on the Strip, with a pace of keynotes and breakout sessions that makes it physically impossible to absorb everything.

But certain announcements cut through the noise, and this year had several that will directly affect how we build infrastructure at the enterprise level. Let me break down the ones that matter most.

AWS Outposts: The Cloud Comes to You

Outposts went generally available this week, and it is the announcement I find most strategically significant. Outposts is AWS infrastructure (actual AWS-designed hardware running AWS services) installed in your own data center. You order it, AWS ships it, installs it, and manages it. You get EC2, EBS, S3, RDS, ECS, and EKS running locally, managed through the same AWS console, APIs, and tools you use for your cloud workloads.

This is AWS acknowledging what enterprise infrastructure teams have known for years: not everything can move to the public cloud. Data residency requirements, latency-sensitive workloads, local data processing for IoT, and regulatory constraints all create legitimate reasons to run workloads on-premises. The question was never "should we use the cloud?" but "how do we bridge the gap between cloud and on-premises?"

Before Outposts, the answer was VMware, OpenStack, or some combination of homegrown tooling that approximated a cloud-like experience without actually being one. The operational model was fundamentally different from the public cloud, which meant teams needed different skills, different tools, and different processes for on-premises versus cloud workloads.

Outposts collapses that distinction. An EKS cluster on Outposts is the same EKS cluster you run in us-east-1. The same kubectl commands, the same IAM policies, the same CloudWatch metrics. For enterprises that have invested heavily in AWS skills and tooling, this is enormously valuable because it extends that investment to workloads that cannot leave the data center.

The pricing model is interesting: you pay for the hardware configuration on a three-year term (no upfront purchase option), plus standard AWS service pricing for what you run on it. It is not cheap, but compared to building and maintaining your own on-premises infrastructure with a separate operational model, the total cost of ownership argument is compelling.

EKS on Fargate: Serverless Kubernetes

The second announcement that has immediate practical implications is EKS on Fargate. Until now, running Kubernetes on AWS meant managing EC2 instances as worker nodes. You had to choose instance types, manage node groups, handle patching, deal with node scaling, and monitor host-level metrics. Fargate eliminates all of that.

With EKS on Fargate, you deploy pods and AWS handles the compute. No nodes to manage, no AMIs to maintain, no instance types to choose. Each pod runs in its own isolated micro-VM (the same Firecracker technology that powers Lambda), and you pay per pod based on the CPU and memory it consumes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  namespace: commerce
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
    spec:
      containers:
      - name: payment-service
        image: 123456789.dkr.ecr.us-east-1.amazonaws.com/payment:v2.1.0
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1000m"
            memory: "2Gi"

This deployment looks identical whether it runs on EC2 nodes or Fargate. The difference is in the Fargate profile, which maps namespaces and label selectors to Fargate compute:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: production
  region: us-east-1
fargateProfiles:
  - name: commerce-profile
    selectors:
      - namespace: commerce
        labels:
          app: payment-service

Any pod matching the selector runs on Fargate. Everything else runs on EC2 nodes. This gives you a hybrid model: stateless services on Fargate for simplicity, stateful workloads on EC2 nodes where you need more control.

The limitations are real and worth understanding. Fargate pods cannot run DaemonSets (there are no nodes to run them on). Privileged containers are not supported. Persistent volumes are limited to EFS (no EBS). GPUs are not available. And there is a cold start latency of roughly 30 to 60 seconds for new pods, which is acceptable for most services but problematic for latency-sensitive workloads that need rapid scaling.

For our use case, running dozens of microservices that are stateless, HTTP-based, and horizontally scalable, EKS on Fargate is a natural fit. It eliminates an entire layer of infrastructure management and lets the team focus on application concerns rather than node management.

Other Notable Announcements

Amazon EKS on EC2 Spot Instances. Managed node groups now support Spot Instances, which can reduce compute costs by up to 90% for fault-tolerant workloads. We already use Spot aggressively for batch processing; extending it to Kubernetes node groups through a managed experience simplifies what was previously a complex custom setup.

AWS Savings Plans. Compute Savings Plans offer the same discounts as Reserved Instances but with more flexibility. Instead of committing to a specific instance type, you commit to a dollar amount of compute per hour and the discount applies to any instance family, region, or operating system. This is a significant improvement for organizations running diverse workloads.

Amazon Managed Cassandra Service (MCS). A fully managed Apache Cassandra-compatible service. For teams running self-managed Cassandra clusters (and I know several), this could eliminate a significant operational burden. The CQL compatibility means existing applications should work with minimal changes.

AWS Transit Gateway Inter-Region Peering. Transit Gateways can now peer across regions, enabling hub-and-spoke network architectures that span the globe. For enterprises running multi-region deployments, this simplifies network topology considerably compared to the mesh of VPC peering connections we manage today.

The Hybrid Cloud Is Real

The meta-narrative of this re:Invent is the maturation of hybrid cloud from marketing concept to operational reality. Outposts, Local Zones, Wavelength (for edge computing at carrier networks), and the continued investment in Transit Gateway all point to a future where "the cloud" is not a place but a model: a set of services, APIs, and operational practices that extend wherever your workloads need to run.

For enterprise infrastructure teams, this is the right trajectory. The idea that everything moves to a single public cloud region was always a simplification. Real enterprises have data centers, edge locations, regulatory jurisdictions, and latency requirements that demand a more nuanced approach.

What AWS is doing with Outposts and the surrounding services is making the hybrid model first-class rather than an afterthought. You do not have to choose between cloud and on-premises. You run both, with the same tools, the same skills, and the same operational model.

What I Am Taking Back

Coming home from re:Invent, the action items are concrete:

First, evaluate EKS on Fargate for our stateless microservices. The potential to eliminate node management for a significant portion of our workloads is too compelling to ignore. I plan to run a pilot with two non-critical services in Q1.

Second, build the business case for Outposts. We have workloads in a co-located data center that need to stay there for regulatory reasons. Outposts could bring those workloads into the same operational model as our cloud infrastructure, which would be a major simplification.

Third, migrate to Compute Savings Plans. Our current Reserved Instance portfolio is a patchwork of commitments made at different times for different instance types. Savings Plans would give us the same discounts with far more flexibility.

re:Invent always generates more ideas than any team can execute. The discipline is in selecting the three or four that will have the most impact and pursuing them with focus. For 2020, hybrid cloud and serverless Kubernetes are where we are placing our bets.