AWS Weekly Roundup (Jan 12, 2026): .NET 10 hits Lambda, Client VPN gets a Quickstart, and re:Invent highlights go on tour

AI generated image for AWS Weekly Roundup (Jan 12, 2026): .NET 10 hits Lambda, Client VPN gets a Quickstart, and re:Invent highlights go on tour

January is when people make resolutions like “I will finally learn Kubernetes,” “I will stop hardcoding credentials,” or the timeless classic: “I will delete that one S3 bucket named final-final-really-final.” AWS, meanwhile, makes its own kind of January resolution: ship a bunch of product updates while we’re still trying to remember what day it is.

This week’s anchor is the AWS News Blog post “AWS Weekly Roundup: AWS Lambda for .NET 10, AWS Client VPN quickstart, Best of AWS re:Invent, and more (January 12, 2026)” by Danilo Poccia. I’m using that roundup as the “table of contents” and then expanding the story with verified details from AWS release notes, documentation, and related launch announcements.

Let’s walk through what matters, why it matters, and what you should actually do on Monday morning (besides more coffee).

1) AWS Lambda now supports .NET 10: the .NET LTS crowd gets a new runway

The headline-grabber for many enterprise teams is straightforward: AWS Lambda now supports .NET 10 for serverless applications, available as both a managed runtime and a container base image. AWS says it will automatically apply updates to the managed runtime and base image as they become available. That’s the standard “managed runtime” promise—but it matters a lot when you’re trying to keep hundreds of functions patched without turning your release calendar into a patch Tuesday tribute band.

According to AWS, this support landed on January 8, 2026, and .NET 10 is positioned as the latest long-term support (LTS) release with security and bug fixes expected through November 2028. AWS also notes the runtime is available in all Regions, including AWS GovCloud (US) and China Regions. (AWS “What’s New” announcement)

What’s actually new for Lambda developers (beyond the version number)

AWS’ companion deep-dive, “.NET 10 runtime now available in AWS Lambda”, calls out several practical developer-facing updates:

  • File-based C# apps: .NET 10 introduces “single file” style apps that can be contained in a single .cs file without a .csproj. AWS highlights these as a way to streamline small Lambda functions and prototypes.
  • Native AOT and runtime optimizations: AWS references improvements to the JIT and Native AOT that can help startup time and executable size—both relevant in serverless where cold starts and package size are not theoretical problems.
  • Tooling upgrades required: AWS explicitly points to needing updated tools (for example, updated Lambda .NET CLI tooling and updated AWS Toolkit for Visual Studio versions) to fully support new patterns like file-based apps.
  • Powertools for AWS Lambda (.NET): AWS says Powertools for Lambda in .NET supports .NET 10, which is a nice signal for teams standardizing on tracing, logging, idempotency, and other “serverless hygiene.”

If you’ve lived through the “we upgraded runtime, now everything is on fire because a transitive dependency disagreed” phase, note that AWS also cautions that new runtimes can show longer cold starts initially due to lower cache residency, and that performance comparisons stabilize over time. That’s not marketing; it’s basically a public service announcement for anyone about to tweet a benchmark graph 90 minutes after launch.

The interesting wrinkle: Lambda Managed Instances (and why it changes the serverless conversation)

The .NET 10 Lambda runtime also includes support for Lambda Managed Instances, which AWS describes as running Lambda functions on Amazon EC2 instances while keeping a serverless-style operational experience. The pitch is twofold: access to specialized EC2 compute options and the ability to tap commitment-based pricing like Savings Plans or Reserved Instances for steady-state workloads. AWS even gives the classic headline number—up to 72% discount over on-demand when using those commitment models—while urging workload-specific testing and concurrency safety practices. (AWS Compute Blog)

My read: this is AWS continuing to blur the line between “serverless” and “not serverless.” And that’s fine. Most teams don’t want ideology; they want predictable performance and cost. Lambda Managed Instances is one more lever to tune that trade-off—especially for high-volume, consistent traffic where pure on-demand Lambda pricing might not be the cheapest route.

Action items: what to do if you run .NET on Lambda today

  • If you’re on .NET 8: evaluate whether you need .NET 10 features immediately. If not, treat .NET 10 as a planned upgrade in your next platform modernization cycle. (AWS previously added .NET 8 as a Lambda runtime in February 2024, establishing the AL2023-based runtime line.) (AWS “What’s New” for .NET 8)
  • Update tooling first: AWS points out you’ll need newer versions of tooling like the AWS Toolkit for Visual Studio and Amazon.Lambda.Tools to target dotnet10. Upgrade tooling in a branch, then upgrade the runtime.
  • If you build container image Lambdas: remember Amazon Linux 2023 base images use dnf (via microdnf) instead of yum. AWS explicitly warns Dockerfiles may need updates when moving from older Amazon Linux 2-based images. (AWS Compute Blog)
  • Benchmark like an adult: test cold start and steady-state on your own workload. Use provisioned concurrency, SnapStart (where supported), or Native AOT where appropriate. Don’t bet production on a synthetic microbenchmark.

2) AWS Client VPN Quickstart: fewer clicks, same networking consequences

Next up: AWS Client VPN gets a new Quickstart setup method that streamlines onboarding for creating and configuring Client VPN endpoints. AWS says this reduces the setup process to three key inputs: IPv4 CIDR, server certificate ARN, and subnet selection. The feature is available alongside the existing “Standard” setup, at no additional cost in all regions where Client VPN is available. (AWS “What’s New”, Jan 7, 2026)

This is the kind of feature that sounds small—until you’ve helped a team set up remote access VPN under deadline pressure. Anything that reduces “console archaeology” is welcome.

What AWS Client VPN is (and why Quickstart matters)

AWS Client VPN is AWS’ managed remote access VPN solution, built to securely connect remote users to AWS resources and on-prem networks. It’s elastic and supports OpenVPN clients. (AWS Client VPN product page)

In practice, Client VPN sits in a space where organizations have historically done one of three things:

  • Run their own VPN concentrators on EC2 (high control, high ops burden).
  • Use third-party VPN appliances or SaaS ZTNA solutions (varied trade-offs).
  • Use a managed option like AWS Client VPN (simpler ops, AWS-native integration).

Quickstart doesn’t change the underlying architecture, routing, authentication method choices, or security model. It changes the time-to-first-connection. That matters for dev/test environments, small teams, or larger orgs that want to stamp out consistent baselines quickly.

Where Quickstart shows up (and what it doesn’t do for you)

AWS documentation now reflects that when you create a Client VPN endpoint, you can choose a setup method: Quickstart (AWS-recommended defaults) or Standard (manual configuration). (AWS Docs)

Quickstart is not a magic wand for:

  • Identity and access strategy: You still need to decide how you’ll authenticate clients (mutual auth, federated, etc.) and how you’ll handle certificate lifecycle.
  • Network access boundaries: You still need to think through split-tunnel vs full-tunnel, which subnets are associated, and which routes are pushed.
  • Logging and visibility: You still need to plan connection logs, client behavior monitoring, and incident response workflows.

But if your pain point was “setting it up takes too long and is too error-prone,” Quickstart is AWS acknowledging that reality and smoothing the first 80%.

3) Amazon ECS tmpfs mounts on Fargate and ECS Managed Instances: a small knob with big security implications

One of the quieter but very practical updates: Amazon ECS now supports tmpfs mounts for Linux tasks running on AWS Fargate and ECS Managed Instances, extending beyond the EC2 launch type. tmpfs mounts create memory-backed file systems inside containers, useful for scratch files, caches, and sensitive short-lived data because it doesn’t persist after the task stops. AWS also explicitly ties tmpfs to the ability to keep your container root filesystem read-only (via readonlyRootFilesystem) while still allowing writes to designated in-memory paths. (AWS “What’s New”, Jan 6, 2026)

Why tmpfs is a DevSecOps feature disguised as a container feature

Performance is the obvious win: memory-backed scratch space avoids disk I/O for temporary workloads. But the bigger story is security posture.

Many container hardening guides push you toward a read-only root filesystem. That’s easy in theory and painful in practice because applications still want to write temp files, PID files, caches, or runtime state somewhere. tmpfs gives you a compromise: immutable root + explicit writable directories backed by memory.

That reduces the blast radius of certain classes of compromise. If an attacker lands in a container, they have fewer durable places to persist changes, and sensitive temp artifacts are less likely to end up on disk.

Who should care

  • Teams running secrets-adjacent workloads: if your app briefly writes decrypted material, tokens, or ephemeral credentials to disk, tmpfs reduces persistence risk.
  • Compliance-heavy orgs: immutable infrastructure patterns are easier to justify when the platform supports the primitives without hacky workarounds.
  • High-throughput apps: caches and temporary transforms can benefit from memory-backed storage, especially on Fargate where storage options can add cost and complexity.

4) AWS Config expands coverage: 21 new resource types (including SageMaker and S3 Tables)

AWS Config is one of those services you only notice when you don’t have it. This week, AWS Config added support for 21 additional resource types across services including Amazon EC2, Amazon SageMaker, and Amazon S3 Tables. AWS says that if you record all resource types, Config will automatically track these new additions, and that they’re available in Config rules and aggregators. (AWS “What’s New”, Jan 6, 2026)

This matters because governance tooling is only as useful as its coverage. Every unsupported resource type becomes a compliance blind spot, and blind spots become audit findings. (Auditors have an uncanny ability to find your weakest control surface the way toddlers find the one sharp corner in the room.)

Why “S3 Tables” being in Config is worth noting

Whenever a new data storage construct shows up in the cloud ecosystem, it tends to arrive with a multi-year trail of operational learning: permissions models, policy best practices, monitoring patterns, and “how not to leak this accidentally.” If AWS Config is expanding to cover resources like S3 Tables, it’s a signal that these resource types are moving into mainstream operational scope—and that you should treat them like first-class infrastructure, not “that experimental thing in one account.”

5) Amazon MQ for RabbitMQ: identity integration gets more flexible (HTTP auth + mTLS)

Message brokers are the plumbing you forget exists—until authentication becomes the thing that blocks a release. Amazon MQ introduced two related improvements for RabbitMQ brokers:

  • HTTP-based authentication and authorization (Jan 6, 2026): RabbitMQ brokers can authenticate and authorize by making requests to an external HTTP server, configurable via broker configuration changes. AWS notes it’s available for RabbitMQ 4.2+ and tied to certain instance type/engine version combinations for new brokers. (AWS “What’s New”)
  • Certificate-based authentication with mutual TLS (mTLS) (Jan 8, 2026): RabbitMQ brokers can authenticate using X.509 client certificates with mTLS via RabbitMQ’s auth_mechanism_ssl plugin. (AWS “What’s New”)

AWS’ Amazon MQ release notes summarize both additions and place them into the bigger RabbitMQ 4.2 evolution, including earlier support for OAuth 2.0 and LDAP authentication for Amazon MQ RabbitMQ. (AWS Docs release notes)

Why HTTP auth is useful (and what to watch out for)

HTTP auth is attractive because it’s an integration pattern many organizations already understand. You can centralize user validation and permissions in an existing service rather than duplicating identity logic in every broker cluster.

But AWS documentation includes some important considerations, including that the external HTTP server must be accessible over the public internet and that Amazon MQ can be configured to authenticate to the HTTP server using mutual TLS. It also notes IAM permission requirements (such as mq:UpdateBrokerAccessConfiguration for enabling HTTP authentication on existing brokers) and that some SSL configuration options are unsupported. (AWS Docs)

The key operational takeaway: if your security posture doesn’t love “public internet reachable” identity endpoints, plan accordingly (for example, architecture choices, strict TLS, monitoring, and careful endpoint design). AWS is giving you flexibility, but you still own the threat model.

6) Amazon MWAA supports Apache Airflow 2.11 (and Python 3.12)

Data teams get a more direct “upgrade path” update: Amazon Managed Workflows for Apache Airflow (MWAA) now supports creating Apache Airflow 2.11 environments. AWS frames Airflow 2.11 as containing changes that help prepare for upgrading to Airflow 3, and also notes MWAA support for Python 3.12 in these workflows. The update is dated January 7, 2026. (AWS “What’s New”)

If you’ve been postponing Airflow upgrades because of plugin compatibility anxiety, treat this as a reminder to test now—before Airflow 3 forces your hand. Managed services reduce the undifferentiated heavy lifting, but they don’t eliminate dependency reality.

7) EC2 instance family expansions: M8i, C8i, R8i, and the relentless march of price-performance

The roundup also points to new EC2 instance availability expansions for several instance families. These announcements are mostly about additional Regions rather than brand-new families, but they still matter because Region availability often controls whether you can standardize your fleet globally.

  • M8i became available in additional Regions (announcement dated Dec 16, 2025) and is positioned as a general-purpose option powered by custom Intel Xeon 6 processors. AWS claims up to 15% better price-performance and significantly higher memory bandwidth compared to previous generations, plus workload-specific performance deltas (PostgreSQL, NGINX, and recommendation models). (AWS “What’s New”)
  • C8i and C8i-flex expanded to additional regions (Jan 7, 2026), again with custom Intel Xeon 6 processors and AWS-provided performance claims versus C7i/C7i-flex for web apps, recommendation models, and caching workloads. (AWS “What’s New”)
  • R8i and R8i-flex expanded to additional regions (Jan 8, 2026). AWS highlights R8i-flex as “memory-optimized Flex” instances aimed at getting price-performance benefits for many memory-intensive workloads without necessarily needing the largest configurations. (AWS “What’s New”)

Practical guidance: how to treat new instance options

Instance families are not Pokémon—you don’t have to catch them all. But you should consider them when:

  • You are CPU-bound or memory-bound and are already spending time tuning performance. A modest price-performance improvement can compound into real savings at scale.
  • You are standardizing infrastructure across Regions and want consistent instance types available globally.
  • You are planning modernization and can absorb the testing work during a scheduled migration rather than as an emergency.

And, as always: test your workload. AWS’ published comparisons are useful signals, but your system’s bottlenecks are rarely as polite as a benchmark graph.

8) The meta story: AWS is making “getting started” easier, while making “running at scale” more controllable

If you step back, this roundup isn’t just a list of features. It’s a pattern:

  • Faster ramps for newcomers: AWS is pushing a simplified onboarding story across services (Client VPN Quickstart, and the Free Tier focus in the roundup).
  • More enterprise identity and governance integration: Amazon MQ adds flexible auth patterns; AWS Config expands coverage; all of this supports the “you can run serious regulated workloads here” narrative.
  • More compute choices without changing your abstractions: .NET 10 on Lambda plus Lambda Managed Instances, and broader new instance availability, give teams knobs to tune cost/performance while keeping developer experience consistent.

It’s classic AWS: make the surface area bigger, then try to provide enough paved roads that you don’t need a machete just to get to “hello world.”

9) Events and programs: Best of AWS re:Invent (Jan 28–29, 2026) and the new Free Tier shape

The AWS Weekly Roundup points to upcoming events and programs, and there are two that are especially actionable.

Best of AWS re:Invent: a curated replay with live Q&A

AWS is running Best of AWS re:Invent as a free virtual event on January 28 or 29, 2026 depending on time zone. The event broadcasts live in three time zones, and AWS says AWS VP and Chief Evangelist Jeff Barr will join the opening session to cover highlights. (AWS event page)

If you didn’t attend re:Invent live—or you attended but your brain has since replaced half the announcements with memories of conference coffee—this is a useful way to get the “what mattered” version, with the option to ask questions while the experts are awake.

AWS Free Tier changes: up to $200 credits and a 6-month Free Plan

Danilo’s roundup also mentions a Free Tier angle: new customers can receive up to $200 in credits and have up to 6 months to experiment without cost on a Free Plan. AWS’ Free Tier page and “What’s New” announcement from July 2025 align with that: $100 credits at sign-up and the ability to earn up to $100 more by exploring key services. (AWS Free Tier page) (AWS “What’s New”, Jul 16, 2025)

This matters because it changes the entry economics for learners and small teams. More importantly, it also changes how AWS positions experimentation: it’s not “here’s a 12-month micro-EC2 deal,” it’s “here’s a controlled ramp with credits and tooling to track usage.” It’s a subtle but meaningful shift toward cost governance from day one.

10) Developer productivity: migrating AWS SDK for Java v1 to v2 (and why the deadline matters)

One of the “additional updates” in the roundup is a post about automating AWS SDK for Java v1 to v2 upgrades using AWS Transform. The reason this is urgent is not just better APIs—it’s the calendar: AWS states that AWS SDK for Java v1 reaches end-of-support on December 31, 2025. (AWS DevOps & Developer Productivity Blog)

There’s also an AWS Developer Tools post noting SDK for Java 1.x entered maintenance mode on July 31, 2024, and reiterating the Dec 31, 2025 end-of-support date, along with a migration tool built on OpenRewrite. (AWS Developer Tools Blog)

What this means in plain terms

  • If you still have Java apps on AWS SDK v1, you’re now in “past the deadline” territory as of January 13, 2026.
  • You should expect increasing friction: fewer docs/examples, more security risk, and more compliance issues.
  • Automation tooling (AWS Transform, OpenRewrite-based migration tools) can reduce the manual work, but you’ll still need testing and human review—especially for patterns the tools can’t translate.

This is a good example of AWS quietly shipping tools that acknowledge a basic truth: large organizations can’t refactor everything by hand at the speed that platform deprecations happen.

11) A quick “so what”: who should prioritize what this week

If you’re a .NET shop

Plan your .NET 10 evaluation now. If you’ve been waiting for LTS alignment, this is your moment. But treat it as a controlled migration: tooling upgrades, dependency compatibility checks, and workload benchmarks first.

If you manage remote access

Client VPN Quickstart can reduce deployment friction. Use it to standardize baselines, then immediately follow up with a security review of routing, split tunneling choices, certificate management, and logging. Quickstart saves time, not responsibility.

If you run containers on Fargate/ECS Managed Instances

tmpfs mounts are worth testing, particularly if you’ve been avoiding read-only root filesystems because “the app needs to write somewhere.” This feature makes hardening patterns easier to implement without duct tape.

If you’re in governance/compliance

Review AWS Config recording coverage. If you rely on Config aggregators and Config rules across accounts, new resource types can materially reduce blind spots. Make sure they’re recorded and included in your controls.

If you run RabbitMQ on Amazon MQ

Evaluate whether HTTP auth or mTLS-based certificate auth helps you align with your identity strategy. But read the docs carefully—especially around network accessibility and TLS requirements—before you adopt. (AWS Docs)

Conclusion

The January 12, 2026 AWS Weekly Roundup by Danilo Poccia is the kind of post that looks like a simple weekly digest, but it’s also a snapshot of how AWS is steering the platform: richer runtime support (.NET 10), simpler onboarding (Client VPN Quickstart), more security-friendly primitives in containers (tmpfs on Fargate), more governance coverage (AWS Config), and more flexible identity options for core infrastructure (Amazon MQ auth plugins).

And if you’re the kind of person whose New Year’s resolution included “reduce technical debt,” AWS helpfully reminded you that some of it now comes with a date stamp and an end-of-support notice.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org