re:Invent 2020: Virtual, Massive, and ECS Anywhere

AWS re:Invent 2020 started this week, and for the first time in its history, the conference is entirely virtual. No Venetian convention center. No party at the LINQ. No badge scanning and swag bags. Just three weeks of online sessions, streamed keynotes, and Andy Jassy presenting from what appears to be a very well-lit studio.

The virtual format has its tradeoffs. You lose the hallway conversations, the vendor booth demos, and the energy of 65,000 people packed into a convention center who all genuinely care about cloud infrastructure. But you gain accessibility: anyone can attend, the sessions are available on-demand, and you do not need to expense a week in Las Vegas.

More importantly, the announcements are strong this year. AWS is filling critical gaps in their container and compute portfolio, and several of the launches have immediate relevance to how we architect and operate infrastructure.

ECS Anywhere

The announcement I am most interested in is ECS Anywhere. This extends Amazon ECS to run on customer-managed infrastructure: on-premises servers, edge locations, other cloud providers, anywhere you can run the ECS agent.

The concept is straightforward. You install the ECS agent on your servers, register them with your ECS cluster, and then deploy tasks to them using the same ECS APIs, task definitions, and deployment mechanisms you use for Fargate or EC2-backed ECS workloads. The control plane remains in AWS. The data plane (your containers and the compute they run on) is wherever you want it.

This is significant for several reasons.

Hybrid cloud becomes operational rather than aspirational. Most hybrid cloud architectures involve running separate orchestration systems on-premises and in the cloud, with some integration layer in between. ECS Anywhere provides a single control plane for container workloads regardless of where they run. You define a task, specify a capacity provider strategy, and ECS handles placement.

Edge computing gets a management story. Running containers at edge locations (retail stores, manufacturing facilities, content delivery points) is increasingly common, but managing those containers has been painful. You either run a Kubernetes cluster at every edge location (operationally expensive) or use custom deployment tooling (fragile and bespoke). ECS Anywhere provides a managed control plane for edge containers without requiring you to operate a cluster locally.

Migration paths become smoother. Organizations with significant on-premises workloads can start using ECS on their existing hardware, then migrate workloads to Fargate or EC2 incrementally. The task definitions do not change. The deployment automation does not change. Only the capacity provider changes.

For our platform team, this is directly relevant. We have workloads that run in AWS and a smaller set of workloads that run on-premises for latency or data residency reasons. Today, the on-premises workloads use a different deployment stack (Ansible and systemd, essentially). ECS Anywhere would let us unify on a single orchestration model.

EKS Anywhere

Alongside ECS Anywhere, AWS announced EKS Anywhere: the same concept applied to Kubernetes. You get an AWS-supported Kubernetes distribution that runs on your infrastructure, with optional connectivity to AWS for management, monitoring, and integration with AWS services.

This is AWS's answer to Google Anthos and Azure Arc. The multi-cloud control plane battle is now fully joined, with all three major cloud providers offering a way to extend their management plane to infrastructure they do not own.

The difference in AWS's approach is pragmatic rather than ideological. Google and Microsoft have been more aggressive about the "run anywhere" narrative, positioning Anthos and Arc as cloud-agnostic management layers. AWS has historically been more focused on making AWS itself the best place to run workloads. EKS Anywhere and ECS Anywhere feel like concessions to the reality that not everything will move to the cloud, rather than a strategic embrace of multi-cloud.

For platform teams evaluating these options, the question is not which cloud provider's distribution is best in isolation, but which one integrates most naturally with the cloud services you already use. If your monitoring is in CloudWatch, your secrets are in Secrets Manager, your IAM is in AWS, and your CI/CD pushes to ECR, then ECS/EKS Anywhere is the path of least resistance.

Lambda Container Support

Lambda now supports container images up to 10GB as a packaging format. Instead of zipping your code and uploading it, you can build a Docker image with your Lambda function and push it to ECR.

This solves a practical problem. Lambda's previous packaging constraints (50MB zipped, 250MB unzipped) were limiting for functions that depended on large libraries, machine learning models, or significant runtime dependencies. Data science workloads with NumPy, SciPy, and TensorFlow often exceeded these limits and required layer management gymnastics.

With container image support, you build a Docker image, include whatever dependencies you need, push it to ECR, and point your Lambda function at it. The container starts via Lambda's micro-VM infrastructure (Firecracker), so you still get the cold start behavior and execution model of Lambda. You are not running a long-lived container; you are using a container image as a packaging format for serverless functions.

The nuance here is that this does not change the Lambda execution model. You still have the 15-minute timeout, the stateless execution environment, and the cold start latency. If your container image is 5GB, the cold start will be longer because the image needs to be pulled and decompressed. Lambda optimizes this with caching, but the first invocation of a large image will be slow.

For our team, this is useful for ML inference functions that bundle trained models. We have been using SageMaker for model serving, which works but is more infrastructure than we need for simple inference endpoints. Lambda with container images could simplify several of these use cases.

Other Notable Announcements

AWS Proton is a new service for managing container and serverless application infrastructure. It provides a framework for platform teams to define infrastructure templates (using CloudFormation or Terraform) that development teams can instantiate through a self-service interface. The concept is similar to what we have built internally: a platform layer that abstracts Kubernetes and ECS complexity behind a simplified interface.

My initial reaction is cautious. The problem Proton solves is real, but the solution is heavily opinionated and tied to the AWS ecosystem. We have built similar capabilities using custom Kubernetes operators and internal tooling that gives us more flexibility. Whether Proton's managed approach is worth the reduced control depends on your organization's platform engineering maturity.

AWS Glue Elastic Views provides materialized views that combine data across DynamoDB, S3, Aurora, and Redshift. You write SQL to define a view, and Glue keeps it synchronized as the underlying data changes. For data platform teams that spend significant effort building and maintaining ETL pipelines for cross-service data aggregation, this could eliminate a category of operational burden.

Amazon DevOps Guru uses machine learning to identify operational anomalies and provide remediation recommendations. It integrates with CloudWatch and CloudFormation to build a model of your application's normal behavior and alert on deviations. The concept is sound (ML-based anomaly detection for operations), but I want to see how it performs on real workloads before forming an opinion. Operational ML tools have a history of generating more noise than signal.

The re:Invent Pattern

Every re:Invent follows a pattern: a few genuinely significant announcements, a batch of incremental improvements, and a handful of services that feel like solutions looking for problems. The 2020 vintage is no different.

ECS Anywhere and Lambda container support are the significant announcements. They change the architecture of what is possible and will influence how we design systems in 2021 and beyond. The container orchestration story, in particular, is becoming more coherent: ECS for simplicity, EKS for Kubernetes-native workflows, Fargate for serverless containers, and Anywhere variants for hybrid deployments.

The virtual format works for information delivery but fails at community building. I miss the energy of being in a room with thousands of people who care deeply about infrastructure. The hallway track at re:Invent, where you meet the engineers who build the services you depend on, is irreplaceable.

But the announcements are strong. ECS Anywhere, in particular, addresses a gap we have been working around for two years. The ability to manage on-premises containers through the same API as cloud containers is not revolutionary in concept, but it is transformative in practice.

I will be spending the next few weeks evaluating ECS Anywhere for our hybrid workloads. The re:Invent sessions are available through the end of the month, and the deep-dive talks on the new container capabilities are at the top of my watch list.

Virtual or not, re:Invent remains the most important week in cloud computing. The announcements shape the infrastructure landscape for the year ahead, and this year is no exception.