Support inbound TCP/UDP (Layer 4) connections for Lambda MicroVMs in VPC
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- aws
- Ambito
- cloud, infrastructure, networking
Direzione di ricerca
Non sono stati identificati file del repository, test o punti di ingresso dell’implementazione. Inizia leggendo la richiesta e l’articolo collegato On-Demand Stateful Compute, quindi analizza il comportamento di VPC ed ENI di AWS Lambda MicroVM; il lavoro sarebbe completato definendo e implementando l’accesso TCP e UDP in ingresso per le MicroVMs connesse a VPC.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
Allow Lambda MicroVMs attached to a VPC to expose inbound TCP/UDP ports accessible from within that VPC (via the assigned ENI/private IP), in addition to the existing managed HTTPS endpoint.
Which service(s) is this request for?
AWS Lambda (Lambda MicroVMs). Tangentially related to VPC Networking / ENI management.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Lambda MicroVMs can already be attached to a VPC, but inbound access is limited to the managed HTTPS endpoint (Layer 7). There's no way to expose a TCP or UDP port on the VPC ENI for other resources in the same VPC to connect to.
This means any service running inside a MicroVM must speak HTTP, WebSocket, or gRPC. You can't run a Redis, Postgres, NATS, or any other service that uses native TCP wire protocols and have VPC resources connect to it directly.
The use case I'm most interested in: on-demand coordination infrastructure for serverless workloads. A Step Functions workflow fans out to hundreds of parallel Lambda invocations. Those invocations need shared state (dedup, locking, or aggregation) for the 20–30 minutes the job runs. A MicroVM running Redis (launched from a snapshot, available in milliseconds) would be perfect for this. But native Redis clients speak TCP on port 6379. Without inbound port access on the VPC, I'd have to wrap Redis in an HTTP adapter, which adds latency, eliminates compatibility with standard client libraries, and defeats the purpose of running a real Redis instance.
The same limitation applies to fire-and-forget patterns (UDP for high-throughput status reporting where occasional loss is acceptable) and integration testing scenarios where you want to run real service binaries unmodified.
The on-demand ephemeral infrastructure pattern, which the snapshot-resume model and suspend-to-zero pricing are uniquely suited for, is blocked by the inability to accept connections on standard service ports.
Are you currently working around this issue?
Using traditional always on infrastructure
Additional context
I wrote about this in more detail here: Lambda MicroVMs: On-Demand Stateful Compute. The "What I'd Want to See Next" section covers this specifically.
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 196
- Fork
- 5
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di aws/aws-lambda-roadmap
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
aws/aws-lambda-roadmap#101 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
aws/aws-lambda-roadmap#100 · 2 reazioni ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 28/100
aws/aws-lambda-roadmap#97 · 1 commento · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
aws/aws-lambda-roadmap#96 · 1 reazione ·
-
Feature-Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 10/100
aws/aws-lambda-roadmap#94 ·
Tutte le issue di aws/aws-lambda-roadmap
Issue simili
-
area: providers/aws priority: p2 size: S type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
finos/open-resource-broker#418 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
GCP region parser selects the wrong region for multi-digit region numbersForse già presa @nawaaaaaAaar l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
mlco2/codecarbon#1438 ·
I maintainer di solito rispondono entro 1 giorno
-
bug needs-triage service/agentregistry
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
hashicorp/terraform-provider-aws#50277 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement internal-synced
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
azureblob: sync at the account root fails on soft deleted containers and deletes nothingForse già presa @LudovicBondon l’ha presa oggi. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 3 giorni