Support inbound TCP/UDP (Layer 4) connections for Lambda MicroVMs in VPC

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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](https://danguisinger.com/blog/lambda-microvms-on-demand-stateful-compute/). The "What I'd Want to See Next" section covers this specifically.

リポジトリのファイル、テスト、実装のエントリポイントは特定されていません。まずリクエストと、そこからリンクされている On-Demand Stateful Compute の記事を読み、その後 AWS Lambda MicroVM の VPC および ENI の動作を調査してください。完了条件は、VPC に接続された MicroVMs への受信 TCP および UDP アクセスを定義して実装することです。

索引モデルが issue の本文から書いたものです。