Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(150.4, 93%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECB%3C/text%3E%3C/svg%3E)
Ciao a tutti, stiamo riscontrando dei problemi di timeout sui Cold Start con alcune Lambda function attestate all'interno di una VPC personalizzata, soprattutto durante gli spike improvvisi di traffico/concorrenza.
Quando scatta l'autoscale e la concurrency sale di colpo, le invocazioni vanno in timeout ancora prima di eseguire il codice dell'applicazione. Il sospetto è che il collo di bottiglia sia legato al provisioning dinamico delle ENI (Elastic Network Interface) e al binding della scheda di rete durante la fase di init del container.
Nello specifico, stiamo analizzando questi punti:
Qualcuno ha già affrontato uno scenario simile in produzione e ha qualche best practice sul tuning di Provisioned Concurrency + VPC Attachment per evitare i cold start timeout?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 62%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EH%3C/text%3E%3C/svg%3E)
Se tutto funziona correttamente, non dimenticare di condividere la tua esperienza sulla risoluzione del problema contrassegnando questa risposta come "Risposta accettata". Se hai bisogno di ulteriori informazioni, sentiti libero di lasciare un messaggio. Saremo lieti di aiutarti
Ciao Chiara
I cold start dentro una VPC con Lambda possono diventare un incubo quando la concurrency esplode all’improvviso. Il collo di bottiglia che sospetti sugli ENI è reale: ogni nuovo container deve agganciarsi alla rete e se le subnet sono già tirate al limite di IP o se colpisci i rate limit di CreateNetworkInterface, i timeout arrivano subito. La best practice che vedo più spesso in produzione è abilitare Provisioned Concurrency per pre‑riscaldare gli ambienti e ridurre il penalty di latenza. Occhio anche alla configurazione delle subnet: avere abbastanza IP disponibili e distribuirli su più AZ può aiutare. Per il traffico a burst, un’architettura decoupled con SQS o EventBridge è spesso la via più semplice per smussare i picchi e non stressare l’Hyperplane ENI. In pratica: provisioned concurrency + tuning delle subnet + smoothing del traffico = meno cold start e meno timeout.
Se questa spiegazione ti aiuta a chiarire come muoverti, ti chiedo di cliccare su “accept answer” così sappiamo che la risposta ti è stata utile!
