Amazon SageMaker Serverless Inference è GA

Amazon ha recentemente annunciato che SageMaker Serverless Inference è ora GA. La nuova opzione serverless è progettata per flussi di lavoro intermittenti o poco frequenti e gestisce il sizing in funzione delle richieste di inferenza.

In modo simile ad altri servizi serverless su AWS, con SageMaker Serverless gli endpoint di inferenza gestiscono automaticamente le risorse di calcolo in base al traffico, senza aver bisogno di scegliere a priori un tipo di istanza o gestire il sizing. Sagemaker Serverless Inference è in grado di scalare da decine a migliaia di inferenze in pochi secondi ed è anche possibile specificare i requisiti di memoria per l’endpoint. Antje Barth, principal developer advocate presso AWS, spiega i vantaggi della nuova opzione:

in molti incontri con i professionisti del ML, ho recepito la richiesta di un’opzione di inferenza ML completamente gestita che consenta agli sviluppatori  di concentrarsi sullo sviluppo del codice di inferenza senza gestire l’infrastruttura. SageMaker Serverless Inference ora offre questa possibilità.

Photo by Kiyoshi on Unsplash

La preview dell’opzione serverless era stata annunciata a re:Invent 2021 e da allora il AWS ha aggiunto il supporto per Amazon SageMaker Python SDK e Model Registry per integrare gli endpoint di inferenza serverless con i workload MLOps. 

Se l’endpoint non riceve traffico per un po’, riduce le risorse a zero. Se l’endpoint riceve improvvisamente nuove richieste, potresti notare che è necessario del tempo prima che l’endpoint sia in grado di elaborare le richieste. Questo tempo di avviamento dipende molto dalle dimensioni del modello e dal tempo di avvio del container. Per ottimizzare i tempi di cold start, puoi provare a ridurre al minimo le dimensioni del tuo modello, ad esempio applicando tecniche come knowledge distillation, quantization, o model pruning.

Oltre all’ultima aggiunta serverless, Amazon SageMaker ha altre tre opzioni per supportare diversi casi d’uso: SageMaker Real-Time Inference, progettata per carichi di lavoro con latenza nell’ordine dei millisecondi, SageMaker Asynchronous Inference, consigliata per inferenze di grandi dimensioni o che richiedono lunghi tempi di elaborazione e SageMaker Batch Transform per eseguire previsioni su batch di dati.

E’ possibile creare e aggiornare un endpoint di inferenza serverless utilizzando la console SageMaker, la SDK AWS, l’SDK Python SageMaker, l’AWS CLI o AWS CloudFormation. Il prezzo di Sagemaker Serverless Inference dipende dal tempo di calcolo e dalla quantità di dati elaborati.

Vuoi leggere altre news su AWS?

“FURL” per semplificare i deployment serverless? AWS introduce le URL per le funzioni Lambda

Amazon MSK Serverless è GA

AWS ha recentemente annunciato che Amazon MSK Serverless è GA. L’opzione serverless per gestire Apache Kafka su AWS elimina la necessità di monitorare il sizing del cluster e gestisce automaticamente le partizioni.

Amazon MSK Serverless è un cluster per Amazon MSK progettato per il provisioning e la scalabilità automatica delle risorse di calcolo e dello storage. Marcia Villalba, Senior Developer Advisor presso AWS, spiega il vantaggio principale dell’opzione serverless:

MSK Serverless è la soluzione perfetta per iniziare con un nuovo progetto che usa Apache Kafka in cui non conosci a priori quanta capacità ti servirà o se le tue applicazioni producono carichi imprevedibili e non desideri pagare per la capacity inattiva. Inoltre, è ottimo se vuoi evitare il provisioning, il ridimensionamento e la gestione dell’utilizzo delle risorse dei tuoi cluster.

Secondo Amazon, un cluster MSK Serverless supporta qualsiasi tool compatibile con Apache Kafka per elaborare i dati e si integra con Amazon Kinesis Data Analytics per Apache Flink e AWS Lambda. 

Amazon MSK Serverless supporta AWS IAM per l’autenticazione e l’autorizzazione client e, per garantire HA, crea due repliche di una partizione in AZ differenti.

Photo by Will Myers on Unsplash

Introdotto da AWS nel 2018, Amazon MSK è un servizio gestito per applicazioni basate su Apache Kafka per elaborare i dati in streaming. L’opzione serverless per MSK era una funzionalità richiesta dalla community ed era stata presentata in preview all’ultimo re:Invent, insieme alle versioni serverless di Redshift e EMR.  

Amazon MSK non è l’unico servizio serverless per l’elaborazione e l’analisi dati su AWS: Kinesis è un servizio di streaming di dati in cui la quantità di dati che può essere processata è determinata dal numero di shard assegnati a uno stream. Esistono anche altre opzioni per avere una managed version di Kafka su un cloud pubblico: Confluent Cloud è una piattaforma di streaming di eventi distribuita nativa del cloud creata dagli sviluppatori originali di Apache Kafka.
Il prezzo dell’offerta serverless di MSK si basa, tra gli altri fattori, sul throughput. Ogni cluster Amazon MSK Serverless fornisce fino a 200 MBps di throughput in scrittura e 400 MBps di throughput in lettura e alloca fino a 5 MBps di throughput in scrittura e 10 MBps di throughput in lettura per ogni partizione.

Vuoi leggere altre news su AWS?

Infrastruttura come SQL su AWS: IaSQL è ora Open Source e SaaS

Infrastruttura come SQL su AWS: IaSQL è ora open source e SaaS

IaSQL, l’azienda che ha creato un servizio per gestire l’infrastruttura AWS utilizzando SQL, ha recentemente annunciato che IaSQL è disponibile come progetto open source e come  software as a service.

Mappando i servizi AWS in tabelle SQL, IaSQL gestisce una connessione bidirezionale tra un account AWS e un database PostgreSQL per descrivere un deployment su AWS. LuisFer De Pombo, co-fondatore e CEO, spiega:

I tradizionali software di gestione Infrastructure as Code non hanno un buon modo per gestire le dipendenze tra le parti dell’infrastruttura in un’architettura di microservizi, il che rende davvero difficile apportare e ripristinare le modifiche. Una rappresentazione SQL risolve il problema principale degli strumenti di infrastruttura basati su YAML.

Photo by eberhard 🖐 grossgasteiger on Unsplash

Il servizio può essere configurato anche per gestire deployment AWS esistenti: collegando un account AWS a un’istanza IaSQL, il database viene popolato con le risorse cloud disponibili e nuovi servizi possono essere definiti utilizzando i moduli IaSQL, ad esempio aws_ec2 o aws_elb. 

IaSQL non è l’unico servizio che si propone di gestire l’infrastruttura cloud tramite SQL: altre opzioni sono CloudQuery, Steampipe, trino-cloud, e StackQL. De Pombo descrive con un esempio un vantaggio dell’approccio SQL:

Non è possibile definire il tipo di istanza EC2 come “t2.mucro” e fare in modo che IaSQL tenti di crearla. L’istruzione insert fallirà, ti dirà che sono state inserite zero righe e potrai rapidamente capire il problema.

Uno dei vantaggi dell’utilizzo di SQL è l’ampia adozione del linguaggio: SQL è già utilizzato nella maggior parte dei team di sviluppo, quindi gli ingegneri del cloud non devono imparare un nuovo linguaggio per gestire l’infrastruttura. 

Secondo i creatori, uno dei vantaggi di un’istanza PostgreSQL come repository è la possibilità di sostituire completamente il database IaSQL in esecuzione con uno snapshot da AWS, ripristinando l’intero deployment a uno stato precedente.

La versione corrente di IaSQL supporta solo alcuni servizi AWS: EC2, Elastic Container Register (ECR), ECS + Fargate, ELB, RDS, VPC e IAM. IaSQL prevede di supportare Google Cloud, Azure e altri provider in futuro. 

Vuoi leggere altre news su AWS?

Una vulnerabilità di RDS e Aurora PostgreSQL porta AWS a deprecare numerose minor version

Una vulnerabilità di RDS e Aurora PostgreSQL porta AWS a deprecare numerose minor version

Una ricercatrice della società di sicurezza Lightspin ha recentemente ottenuto le credenziali per un servizio AWS interno utilizzando un’estensione PostgreSQL e sfruttando una vulnerabilità di lettura dei file di sistema su RDS. AWS ha confermato il problema e ha deprecato numerose minor version di Amazon Aurora e RDS per PostgreSQL.

Secondo Amazon, gli utenti di database con autorizzazioni sufficienti avrebbero potuto utilizzare queste credenziali per ottenere un accesso elevato alle risorse associate al cluster di database da cui sono state estratte le credenziali. Le stesse credenziali non potevano invece essere utilizzate per accedere ai servizi RDS interni o ad altri database o account AWS. 

Gafnit Amiga, director of security research a Lightspin, spiega come ha ottenuto le credenziali per un servizio AWS chiamato Grover utilizzando un’estensione PostgreSQL :

L’estensione log_fdw consente all’utente di accedere ai log del database utilizzando un’interfaccia SQL (…) Ho passato un po’ di tempo ad esaminare i file di sistema finché non ho trovato una proprietà interessante nel file di configurazione di PostgreSQL (…) Il file apg_storage_conf_file punta a un altro file di configurazione chiamato grover_volume.conf (…) che a sua volta mi ha portato ad un altro file, csd-grover-credentials.json.

Photo by Federico Burgalassi on Unsplash

Questo file ha consentito ad Amiga di recuperare le credenziali temporanee IAM, tra cui una publicKey e una privateKey che ha potuto testare, confermando essere collegate a un ruolo interno chiamato  csd-grover-role. Amiga conclude:

Passando da tre diversi file ho potuto scoprire un servizio AWS interno e accedervi. Qui è dove la mia analisi e ricerca si sono concluse. Non ho tentato di sfruttare autorizzazioni IAM o accedere ad altri database nell’ambiente interno di AWS.

Secondo la società di sicurezza Lightspin, la vulnerabilità è stata segnalata ad AWS il 9 dicembre, più di quattro mesi fa, quando il team RDS ha iniziato a lavorare ad una fix. AWS ha installato una prima patch sulle ultime versioni di Aurora e RDS il 14 dicembre, escludendo le versioni precedenti, e ha iniziato a contattare i clienti potenzialmente impattati. In un security bulletin pubblicato il 13 aprile, AWS dichiara:

AWS ha immediatamente preso le misure necessarie per risolvere questo problema non appena è stato segnalato. Come parte della nostra mitigazione, abbiamo aggiornato Amazon Aurora PostgreSQL e Amazon RDS for PostgreSQL per prevenire questo problema. Abbiamo anche reso obsolete le versioni secondarie di Amazon Aurora PostgreSQL e di Amazon RDS for PostgreSQL elencate (…). I clienti non possono più creare nuove istanze con queste versioni In quanto obsolete.

Il security bullettin di AWS inizialmente non menzionava Lightspin e la mancanza di attribuzione della scoperta della vulnerabilità aveva sollevato ulteriori dubbi tra gli sviluppatori. L’annuncio non chiarisce cosa sia il servizio interno Grover e come funzioni. Amiga conferma: “Quanto a Grover, AWS non è in grado di rivelare dettagli sul servizio interno”.

Vuoi leggere altre news su AWS?

AWS Firewall Manager Supporta Palo Alto Networks

Amazon introduce il ripristino automatico di default delle EC2

Amazon ha recentemente annunciato che le istanze EC2 ora verranno ripristinate automaticamente nel caso in cui diventino irraggiungibili a causa di problemi hardware. Il ripristino automatico migra l’istanza su un hardware diverso mantenendo l’instance ID, gli indirizzi IP privati, l’Elastic IP e i metadati.

Esistono diversi scenari che possono attivare il ripristino automatico di una EC2: ad esempio, una perdita di connettività di rete o di alimentazione e problemi software o hardware sull’host. Durante il ripristino di un’istanza, è richiesto un reboot della EC2 e tutti i dati in memoria vengono persi. Se l’istanza aveva un indirizzo IPv4 pubblico, questo verrà mantenuto. Allo stesso modo, se la EC2 si trovava in un placement group, la nuova istanza verrà fatta ripartire nello stesso.  

Photo by JESHOOTS.COM on Unsplash

Mani Chandrasekaran, Principal Solutions Architect di AWS, scrive:

Questo può sembrare un annuncio minore, ma avrà un impatto significativo e positivo sui nostri clienti. Anche se era disponibile in precedenza,  “impostazione predefinita” è la parola chiave.

Una prima iterazione della funzionalità era stata rilasciata anni fa ed è in alternativa possibile ripristinare un’istanza automaticamente configurando un CloudWatch Alarm.

 Il nuovo comportamento di default  è pensato per accelerare il ripristino di un’istanza quando è impattata da un problema hardware, ma è sempre possibile disabilitarlo. Il ripristino automatico non viene avviato se un’istanza fa parte di un gruppo Auto Scaling.

Amazon evidenzia che il ripristino automatico di un’istanza non è inteso come una soluzione HA in quanto potrebbe non riuscire se la capacità nella zona di disponibilità è insufficiente o se si verificano problemi di infrastruttura che influiscono sul processo di recupero.

Non tutte le classi di istanze EC2 attualmente disponibili supportano il ripristino automatico. Anche le istanze con un’interfaccia EFA, le istanze che utilizzano instance store e le istanze metal non supportano il ripristino automatico. È possibile verificare le istanze che supportano il ripristino automatico utilizzando il comando CLI describe-instance-types :

aws ec2 describe-instance-types --filters Name=auto-recovery-supported,Values=true   --query "InstanceTypes[ *].[InstanceType]" --output text | sort

La nuova funzionalità non garantisce un massimo recovery time entro cui una EC2 sia disponibile.

Vuoi leggere altre news su AWS?

AWS Firewall Manager Supporta Palo Alto Networks

AWS Firewall Manager Supporta Palo Alto Networks

AWS ha recentemente annunciato che Firewall Manager supporta i firewall di Palo Alto Networks (NGFW). La funzionalità è frutto della collaborazione tra Palo Alto Networks e Amazon per offrire un servizio firewall gestito progettato per semplificare la protezione dei deployment su cloud AWS.

Jeff Barr, vicepresidente e chief evangelist di AWS, spiega i vantaggi di Cloud NGFW per AWS:

Palo Alto Networks è il precursore della deep packet inspection con NGFW. Cloud NGFW per AWS può analizzare i pacchetti di rete e identificare applicazioni utilizzando firme, decodifica del protocollo, analisi comportamentale ed euristica. Ciò offre la possibilità di implementare una gestione della sicurezza avanzata incentrata sull’applicazione, più efficace rispetto a modelli più semplici basati esclusivamente su porte, protocolli e indirizzi IP.

Grazie a Advanced URL filtering, i clienti possono creare regole per identificare e gestire il traffico di rete in base a feed, elenchi curati di siti che distribuiscono virus, spyware e altri tipi di malware. Altre tecnologie di Palo Alto supportate su AWS sono Threat Prevention, per bloccare gli exploit di vulnerabilità e i malware, e App-ID.

Photo by Markus Winkler on Unsplash 

Cloud NGFW può controllare il traffico tra VPC senza inserire appliance IPS per monitorare e proteggere carichi di lavoro cloud. L’utilizzo della tecnologia di Palo Alto su AWS era precedentemente possibile ma non facile da configurare, poiché richiedeva una connessione VPN o una cosiddetta VPC insertion. Inoltre era necessario gestire il firewall e la scalabilità dell’infrastruttura. 

Palo Alto Networks ha pubblicato una guida ntroduttiva a Cloud NGFW per AWS per documentare la configurazione del nuovo servizio.

AWS Firewall Manager e Cloud NGFW sono servizi regionali con Cloud NGFW attualmente supportato solo in Northern Virginia e Northern California. Il servizio è disponibile come  pay-as-you-go subscription sul AWS Marketplace e parte da $ 1,637/ora più il traffico processato. Le funzionalità Threat Prevention and Advanced URL Filtering vengono addebitate separatamente.

Vuoi leggere altre news su AWS?

“FURL” per semplificare i deployment serverless? AWS introduce le URL per le funzioni Lambda

“FURL” per semplificare i deployment serverless? AWS introduce le URL per le funzioni Lambda

AWS ha recentemente annunciato le URL per le funzioni Lambda, una funzionalità che consente agli sviluppatori di configurare direttamente un endpoint HTTPS e gli headers CORS per una funzione Lambda senza effettuare il provisioning di altri servizi.

Con la nuova funzionalità, gli sviluppatori possono non utilizzare Amazon API Gateway o Application Load Balancer per mappare una funzione Lambda ad una chiamata HTTP. Ogni URL di una funzione è univoca globalmente e può essere associata all’alias o all’ARN di una funzione Alex Casalboni spiega gli scenari in cui utilizzare la nuova funzionalità:

Gli URL delle funzioni sono la scelta migliore per i casi d’uso in cui è necessario implementare un micro servizio a funzione singola con un endpoint pubblico che non richiede le funzionalità avanzata dell’API Gateway.

Photo by Camille Minouflet on Unsplash

Testando la nuova feature, AJ Stuyvenberg, responsabile tecnico serverless di Datadog, commenta:

Le FURL sono utili in un paio di casi importanti: API Mono-Lambda, comunicazione Service to Service e webhook semplici. Penso che con alcune iterazioni, le URL delle funzioni potrebbero migliorare molto e forse essere il meccanismo di integrazione predefinito per l’invocazione Lambda via HTTP.

L’annuncio ha suscitato molti commenti su Hacker News e Reddit, con alcuni utenti che apprezzano la semplicità della soluzione mentre altri sottolineano la mancanza del supporto di domini personalizzati. Ebi Mirsafian pensa che le URL Lambda siano un “grande abilitatore nella direzione di 100% serverless” mentre Paul Zietsman rimane  scettico.

In un post popolare su LinkedIn, Rehan van der Merwe riassume i vantaggi e i prezzi della nuova funzionalità.  Amazon non è l’unico provider cloud che supporta endpoint HTTP per serverless, con Google Cloud Functions e Azure Functions che offrono una funzionalità simile. La nuova feature non è stata una vera e propria sorpresa per gli sviluppatori poiché era apparsa accidentalmente per poche ore lo scorso novembre, come notato all’epoca da Scott Piper.

Le “FURL” sono disponibili sono disponibili in tutte le regioni in cui è supportata AWS Lambda, Cina esclusa.

Vuoi leggere altre news su AWS?