Skip to content

Instantly share code, notes, and snippets.

@alessandrodolci

alessandrodolci/aws.md

Last active June 17, 2022 12:27
Show Gist options
  • Save alessandrodolci/88d78adc98c11c95f0de42727574bbc2 to your computer and use it in GitHub Desktop.
Save alessandrodolci/88d78adc98c11c95f0de42727574bbc2 to your computer and use it in GitHub Desktop.
Download ZIP
AWS Certified Developer Associate - Note e appunti
Raw
aws.md

Amazon Web Services

Nozioni generali

  • Un insieme di data center AWS geograficamente vicini compone una Availability Zone

    • Ciascuna AZ prevede internamente fault tolerance e ridondanza

  • Un insieme di due o più AZ compone una Region

    • Ciascuna AZ è isolata e separata fisicamente dalle altre
    • Progettate per coprire un'area non troppo grande, al fine di non subire problemi di latenza, ma nemmeno troppo piccola, al fine di evitare il più possibile di esporre le diverse AZ agli stessi guasti

  • Un insieme di Region compone una partition

  • Edge Locations: punti di presenza strategici che mantengono cache per distribuzione efficiente

    • Costituiscono la CDN di AWS (CloudFront)

  • Amazon Resource Names (ARN): nomi che identificano risorse AWS in maniera univoca a livello globale

    • Risorse definite contestualmente a servizi, utenti, ruoli, ecc.

IAM

  • Gestione degli accessi

    • Servizio globale

  • Identità organizzate secondo tipologie differenti:

    • Users: singoli individui che operano nel contesto dell'account
    • Groups: raggruppamenti di utenti relativi a mansioni o attività svolte
    • Roles: identità assunte da altri servizi (anziché da individui) per applicare ad essi controllo degli accessi
      • Nel caso, ad esempio, di EC2, è opportuno non utilizzare user e relative credenziali per attribuire permessi e svolgere operazioni, ma definire roles con le autorizzazioni necessarie

  • Gestione affidata a policy associate alle identità

    • Documenti JSON che definiscono i loro permessi
    • Sia policy gestite da AWS che policy custom, definite dall'utente
    • Principio del minimo privilegio: fornire solo i permessi strettamente necessari in base all'obiettivo
    • Diverse tipologie:
      • Policy basate su identità IAM: associate a identità IAM, specificano autorizzazioni per esse
      • Policy basate su risorse: associate a risorse create sui servizi, specificano autorizzazioni concesse ai principal specificati riguardo alle risorse stesse
    • Composte da uno o più statement, che comprendono:
      • Effect: specifica se lo statement si applica come ALLOW oppure DENY
      • Action: indica l'azione oggetto dello statement
      • (Nel caso di policy per identità) Resource: indica la risorsa a cui si applica l'azione specificata
      • (Nel caso di policy per risorsa) Principal: indica l'attore a cui si applica lo statement
      • Condition: indica una condizione necessaria per applicare lo statement (facoltativa)

  • Si può configurare MFA per root account e per ogni singolo user

  • Credentials Report: permette di ottenere un elenco di tutte le identità attive e le loro autorizzazioni

  • Access Advisor: utile per effettuare audit degli accessi dei vari utenti e ottenere uno storico degli accessi e delle autorizzazioni che sono state concesse loro

  • Valutazione di policy

    • La decisione è sempre DENY, a meno che applicando tutte le policy non vi sia un ALLOW esplicito e nessun DENY esplicito
    • Nel caso vi siano policy a livello di risorsa (come nel caso di S3), viene valutata l'unione delle policy dell'identità che agisce e della risorsa

  • Dynamic policies: possibilità di utilizzare variabili nella definizione di policy, che aiutano a creare policy parametriche e scalabili

    • Variabili well-known per accedere a dati relativi ad utenti e risorse
    • Ad esempio, policy per autorizzare ciascun utente IAM ad accedere alla propria directory all'interno di un bucket: non una policy per utente, ma un'unica policy con riferimento allo username AWS

  • Tre tipologie di policy:

    • Managed: gestite e aggiornate da AWS
    • Customer Managed: definite e gestite dall'utente, riutilizzabili e versionabili
    • Inline: definite contestualmente alla definizione di un Principal, strettamente legate ad esso e scarsamente gestibili

  • Passaggio di un ruolo ad un servizio (ad esempio un'istanza EC2 o una Lambda)

    • L'utente che passa il ruolo deve essere autorizzato
      • Action iam:PassRole
    • Non tutti i ruoli possono essere passati ad un servizio
      • La Trust policy del ruolo definisce quale principal lo può assumere

  • Ruoli e policy basate su risorse non permettono di delegare accesso ad account posti in partition AWS diverse da quella in cui si trova l'account di partenza

Directory Service

  • Tre possibilità:
    • Managed Microsoft Active Directory: permette di definire istanze managed
      • Possibilità di mettere in relazione le istanze ad installazioni on-premises
    • AD Connector: proxy verso la propria istanza on-premises
    • Simple AD: servizio di directory managed compatibile con AD
      • Non può essere connesso a installazioni on-premises
    • Cognito User Pools

STS

  • Permette di ottenere token temporanei per l'accesso a risorse

    • Fino a un'ora di durata

  • Diverse operazioni possibili:

    • AssumeRole: fornisce credenziali temporanee utili ad assumere un ruolo IAM, anche se definito in un account differente
    • GetSessionToken: permette agli utenti con MFA di ottenere credenziali temporanee con un token di sessione
    • GetCallerIdentity: fornisce informazioni sull'utente chiamante
    • DecodeAuthorizationMessage: consente di decodificare un messaggio di errore ottenuto invocando un'API

KMS

  • Gestione chiavi e cifratura di risorse

    • Integrato con IAM per autorizzazione e con tutti i servizi AWS che effettuano storage o persistenza di dati

  • Chiavi (Customer Master Keys) simmetriche o asimmetriche

    • Possibilità di audit con CloudTrail
    • Tre tipi di CMK:
      • CMK di default per uso con servizi AWS
        • Non modificabili o rotabili, gestite da AWS e relative a specifici servizi
      • Chiave utente creata in KMS
      • Chiave utente importata dall'esterno

  • Cifratura simmetrica

    • AES-256
    • Utilizzata da tutti i servizi AWS che si integrano con KMS
    • La chiave non è mai accessibile direttamente, la si usa sempre attraverso KMS

  • Cifratura asimmetrica

    • RSA / ECC
    • Sia cifratura che firma e verifica
    • La chiave privata non è mai accessibile direttamente

  • KMS effettua cifratura di dati fino a un massimo di 4 KB per operazione

  • Chiavi limitate ad una singola Region

    • In caso di copia di snapshot tra Region diverse, occorre cifrare con una nuova chiave

  • Key policy per definire permessi e autorizzazioni

    • Default: permessi all'account (root), valgono le policy IAM dell'account
    • Custom: possibilità di definire permessi IAM e autorizzare accessi esterni all'account

  • Envelope Encryption: permette di cifrare dati di dimensioni superiori a 4 KB

    • Cifratura e decifrazione lato client
    • GenerateDataKey API
      • Restituisce una chiave particolare (DEK) sia in chiaro che cifrata
      • Si cifra il file con la chiave in chiaro e si costruisce un messaggio (envelope file) con file cifrato e chiave cifrata ricevuta da KMS
      • Per decifrare l'envelope file, si utilizza la normale Decrypt sulla chiave cifrata contenuta nell'envelope stesso, che restituisce la chiave in chiaro
    • AWS Encryption SDK/CLI implementa questa operazione e la espone per comodità
      • Cache per data key

  • API principali:

    • Encrypt e Decrypt: cifrano e decifrano dati fino a 4 KB
    • GenerateDataKey
    • GenerateDataKeyWithoutPlaintext: genera una DEK da utilizzare in futuro, restituendo solo la versione cifrata (si invocherà poi Decrypt per utilizzarla)
    • GenerateRandom: restituisce una stringa di byte casuali

  • Limiti sul numero di richieste effettuabili a KMS nel tempo

    • ThrottlingException nel caso in cui vengano superati
    • Quote condivise tra operazioni diverse e servizi diversi
    • Incrementabili su richiesta

Systems Manager

Parameter Store

  • Storage di parametri, credenziali e segreti

    • Entry in chiaro o cifrate
    • Integrazione opzionale con KMS (tipo SecureString)
    • Versioning

  • Due tier

    • Standard: fino a 10000 entry di dimensione massima pari a 4 KB, gratuito
    • Advanced: nessun limite di entry memorizzabili, dimensione massima pari a 8 KB, a pagamento

  • Entry organizzate in gerarchia, accessibili tramite il loro path

  • Solo relativamente al tier Advanced è possibile associare policy di vario tipo alle entry

    • TTL per forzarne la scadenza
    • Invio di notifiche tramite CloudWatch Events in prossimità della scadenza del TTL

  • Le policy IAM per l'accesso possono essere specifiche per parametro

Secrets Manager

  • Servizio più nuovo di SSM Parameter Store, orientato a credenziali segrete

    • Possibilità di specificare rotazione dei segreti
    • Integrazione con altri servizi
    • Cifratura con KMS
    • Costo elevato

  • Diverse tipologie di entry, specifiche per integrazione con determinati servizi

    • Attenzione maggiore verso servizi per database (RDS, Redshift, DocumentDB)

EC2

  • Compute service

    • VM, drive virtuali, load balancing, scaling automatico

  • EC2 Instances

    • Diverse tipologie in base a numero di vCPU, capacità di memoria, tipologia di storage, performance di rete
      • General purpose: prestazioni equilibrate, adatta a web server generico
        • Può fare bursting in caso di picchi di carico
          • Gestione tramite crediti, accumulati con tempo di idle e consumati durante i burst
      • Compute optimized: alta potenza computazionale, adatta a batch processing o server ad alte prestazioni
      • Memory optimized: alta capacità di RAM, adatta a database ad alte prestazioni o in-memory, cache, processing real-time
      • Storage optimized: alte prestazioni di IO, adatta a database, cache, data warehouse
    • AMI: snapshot di VM, con annessi permessi di avvio, periferiche di storage e mapping dei mount point
      • Specifiche per Region, ma possono essere copiate
      • Sia fornite da AWS, che custom, definite dall'utente a partire da istanze EC2
      • Eliminano il tempo di bootstrap presente al primo avvio
      • Image Builder per creare e gestire AMI in maniera semplificata e automatizzata
    • User Data: script di bootstrap associabile ad una VM
      • Lanciato all'avvio dell'istanza, solo la prima volta oppure ad ogni riavvio
      • Esegue come root

  • Security Groups: firewall per istanze EC2

    • Definiti da un insieme di regole che consentono determinate tipologie di traffico in entrata e in uscita dall'istanza a cui sono associati
      • Di default, tutto il traffico in entrata è bloccato e tutto il traffico in uscita è consentito
    • Livello 4: regole applicate a porte di rete su uno specifico indirizzo IP o su un range di indirizzi
      • In alternativa, si può definire una regola specificando un altro SG come sorgente o destinazione, per evitare di dover usare gli indirizzi delle istanze
    • Riutilizzabili: un SG può essere associato a più istanze
    • Specifici per coppia Region/VPC

  • Diverse tipologie di acquisto e prenotazione di istanze EC2:

    • On-demand: utili per prenotazioni limitate nel tempo, costo predicibile calcolato al secondo per sistemi Linux e all'ora per altri sistemi (0.10$ all'ora)
    • Reserved: utili per prenotazioni di lungo periodo (1 oppure 3 anni) in ottica di risparmio (fino al 75% di sconto)
      • Convertible: tipo di istanza modificabile nel tempo (fino al 54% di sconto)
      • Scheduled: prenotazione per intervalli precisi di tempo (ad esempio, ad una certa ora di un certo giorno della settimana)
    • Spot: utili per prenotazioni brevi che possono resistere a fallimenti, economiche (fino al 90% di sconto), possono essere revocate
      • Si definisce un prezzo massimo che si è disposti a spendere, istanze assegnate fino a quando vi è disponibilità di istanze e lo spot price non supera la soglia stabilita
      • La revoca può avvenire con preavviso di due minuti
      • Si può definire il comportamento da adottare in caso di revoca:
        • Ibernazione dell'istanza
        • Stop dell'istanza
        • Terminazione dell'istanza
    • Dedicated host: intera macchina fisica, utile se si hanno requisti di licensing particolari, ad esempio incompatibile con tenancy condivisa
    • Dedicated instance: istanza singola su hardware dedicato (non intera macchina), condiviso non con altri account, ma eventualmente con altre istanze dello stesso account; possibilità che l'hardware dedicato cambi se si stoppa e si riavvia l'istanza

  • Tutte le informazioni e i metadati relativi ad una determinata istanza EC2 sono accessibili programmaticamente dall'istanza stessa attraverso un endpoint apposito esposto su un indirizzo privato

    • http://169.254.169.254/latest/meta-data/

  • Elastic Block Store (EBS): block storage device di diverso tipo

    • Network drive
    • Associabili a una sola istanza per volta
    • Ciascun drive EBS è bloccato su una specifica AZ e può essere collegato solo a istanze che si trovano in quella AZ
    • Occorre definire a priori la capacity (dimensione e throughput) di ciascun dispositivo
    • Possibilità di effettuare snapshot di volumi per backup e copia tra AZ o Region diverse
    • Diverse tipologie:
      • General Purpose SSD (gp2 / gp3)
        • Bilanciati in termini di prezzo e prestazioni
        • 1 - 16 TiB
        • 16000 IOPS al massimo, baseline di 100 per gp2 e 3000 per gp3
        • IOPS e dimensione incrementano assieme per gp2, sono indipendenti per gp3
          • 3 IOPS per GB in gp2, sopra 33.33 GB, fino a 5.334 TB
      • Provisioned IOPS SSD (io1 / io2 / io2 Block Express)
        • Prestazioni più elevate a prezzi superiori, ottimi per database
        • 4 - 16 TiB per io1 e io2, 4 - 64 TiB per io2 Block Express
        • 64000 IOPS al massimo per io1 e io2 e istanze EC2 Nitro (32000 con istanze standard), 256000 per io2 Block Express
        • IOPS e dimensione sono indipendenti
      • Hard Disk Drives (st1 / sc1)
        • Non possono essere utilizzati come boot device
        • 125 MiB - 16 TiB
        • Ottimizzati per throughput (st1) o per archiviazione a basso costo (sc1)
    • EBS Multi-Attach: se si hanno device io1 e io2, è possibile collegarli a più istanze nella stessa AZ
      • Tutte le istanze possono leggere e scrivere
      • Utile per HA
      • Occorre usare file system cluster-aware e gestire la concorrenza

  • EC2 Instance Store: periferiche hardware di storage ad alte prestazioni

    • Throughput più elevato rispetto a EBS
    • Effimere: i dati sono persi quando l'istanza è stoppata
    • Ottime per cache, buffer, risorse temporanee
    • Nessun backup automatico

  • Elastic File System (EFS): file system di rete, utilizzabile da istanze diverse, anche in più AZ

    • Altamente disponibile e scalabile (non occorre fare provisioning di capacità)
    • Tendenzialmente più costoso rispetto a EBS, ma pay-per-use, quindi dipende
    • Utile per contenuto condiviso (ad esempio per CMS)
    • Utilizza il protocollo NFS, compatibile con istanze Linux
    • Diverse modalità per performance selezionabili alla creazione:
      • General purpose: bassa latenza e basso throughput
      • Max I/O: latenza e throughput più elevati, utile per big data
    • Diverse possibilità per throughput:
      • Bursting: throughput proporzionale alla dimensione, con burst
      • Provisioned: throughput scelto a piacere, indipendentemente dalla dimensione
    • Diversi tier per il costo di memorizzazione:
      • Standard: per file ad accesso frequente, basso costo per accedervi
      • Infrequent access: basso costo per lo storage, alto costo per l'accesso
      • Si possono definire policy per il passaggio da un tier all'altro dopo determinati intervalli di tempo
    • Per il funzionamento con istanze EC2 occorre definire un Security Group per il file system che consenta l'accesso in entrata alla porta di NFS alle istanze che lo utilizzano
    • Nel caso di EC2 poste in AZ diverse, è possibile creare un mount target per ogni AZ, così da ottenere fault tolerance ed evitare di collegare tutte le EC2 tramite lo stesso mount target

  • Elastic Load Balancing (ELB): load balancer gestito

    • Utile per diversi scopi:
      • Distribuire il traffico e fornire un unico punto di accesso ad un'applicazione o servizio
      • Ottenere tolleranza ai guasti di singole istanze
      • Aggiungere SSL
      • Separare servizi accessibili pubblicamente da quelli interni
    • Redirigono il traffico verso insiemi di host, detti target group
    • Necessario definire una rotta di healthcheck sui servizi per permettere al load balancer di sapere se una determinata istanza è disponibile
    • Tre tipi di load balancer:
      • Classic Load Balancer
        • "Deprecato"
        • Supporta HTTP, HTTPS, TCP
      • Application Load Balancer
        • Livello 7, supporta HTTP, HTTPS, WebSockets
        • Possiede un hostname statico
        • Diverse possibilità per i target group:
          • Istanze EC2
          • Task ECS
          • Lambda
          • IP privati
        • Routing sulla base di path, hostname, e/o query parameter all'interno di un URL
        • Rispetto a CLB, uno stesso ALB può servire più applicazioni o servizi (ad esempio, tramite path diversi)
        • X-Forwarded-For header per permettere ai server dei target group di conoscere l'IP dei client che passano dal balancer
      • Network Load Balancer
        • Livello 4, supporta TCP (anche con TLS) e UDP
        • Possiede un IP statico per ciascuna AZ in cui è attivo (a cui è associabile un Elastic IP)
        • Permette latenza inferiore e prestazioni più elevate rispetto ad ALB
    • Possibilità di abilitare sticky sessions, al fine di associare tutte le richieste di un determinato utente ad una specifica istanza del target group in caso di applicazioni stateful
    • Cross-Zone Load Balancing: le istanze del load balancer poste in diverse AZ distribuiscono il traffico tra le istanze del target group in maniera uniforme attraverso le diverse AZ
      • Senza questa opzione attiva, il traffico è distribuito in maniera non uniforme tra AZ diverse (se traffico uniforme tra due AZ e numero di EC2 diverso, l'AZ con il numero minore di EC2 ha istanze più cariche)
      • Opzione sempre attiva per ALB, attivabile per NLB
    • Monitoring del traffico attraverso diverse modalità:
      • Access logs: log contenenti informazioni dettagliate sulle richieste in arrivo al balancer
        • Timestamp, IP del client, latenza, path richiesti, ecc.
        • Log salvati su S3 e cifrati con SSE-S3
      • Request tracing: aggiunta di un header alle richieste da parte del balancer per permetterne il tracciamento
      • CloudWatch Metrics
      • CloudTrail

  • Auto Scaling Groups: possibilità di definire servizi e applicazioni in grado di scalare orizzontalmente in maniera automatica

    • ASG definito da:
      • Dimensione minima del pool di istanze
      • Dimensione massima
      • Capacità desiderata (attuale)
      • Launch configuration (o Launch template)
      • Policy di scaling
        • Target tracking: regole basate sul carico medio, il numero di richieste, il traffico in entrata o uscita
        • Simple / Step scaling: scaling quando scattano allarmi CloudWatch
        • Scheduled Actions: scaling in momenti prefissati (un determinato giorno ad una determinata ora)
        • Si può impostare uno scaling cooldown, un periodo che segue un'azione di scaling, durante il quale non vengono iniziate ulteriori azioni, al fine di lasciare tempo al sistema per stabilizzarsi
    • Posto in genere a valle di un load balancer
    • Ruoli IAM collegati all'ASG vengono ereditati dalle istanze EC2 da esso lanciate
    • Di default, ASG sono configurati per fare health check delle istanze EC2
      • Nel caso in cui un'istanza risulti unhealthy, essa viene terminata e sostituita con una nuova
      • Se si utilizza un load balancer e si vuole automatizzare la sostituzione di istanze unhealthy, occorre modificare questa configurazione per rivolgere l'health check al balancer, anziché alle istanze

RDS

  • Gestione di database relazionali

    • Compatibile con i principali DBMS, più Amazon Aurora (soluzione proprietaria AWS)
    • Servizio managed
      • Provisioning di istanze gestito da AWS
      • Backup automatici
      • Setup su multi AZ

  • Backup in due modalità:

    • Automatici
      • Backup completi effettuati quotidianamente durante una finestra di manutenzione
      • Log delle transazioni ogni 5 minuti
      • Mantenuti per 7 giorni
    • DB Snapshot
      • Effettuati manualmente
      • Mantenuti per periodi arbitrari

  • Storage Auto Scaling: possibilità di incrementare la dimensione del database in maniera automatica, in base al carico richiesto

    • Occorre impostare un limite superiore alla dimensione
    • Diverse possibilità per le politiche di scaling

  • Read Replica: copie asincrone in sola lettura di un database

    • Fino a 5 repliche per database
    • Endpoint (connessioni) diversi per diverse repliche
    • Collocabili anche in AZ o Region diverse
      • Costo aggiuntivo solo per replica in una Region diversa
    • Replica effettuata in maniera asincrona
      • Eventual consistency
    • Possibilità di promuovere repliche a database operativi

  • Multi AZ: copia sincrona di un database per Disaster Recovery

    • Le copie sono in standby, pronte a sostituire la principale
    • Failover automatico in caso di problemi di disponibilità
    • Modalità attivabile senza downtime del database

  • Cifratura dei database

    • At rest: cifratura mediante KMS
      • Da definire al momento dell'avvio
      • Attivabile per le Read Replica solo se l'istanza principale ne dispone
    • In-flight: cifratura tramite SSL
      • Da attivare all'interno del DBMS
    • Gli snapshot sono cifrati solo se lo è il database
      • Possibilità di cifrarli in un secondo momento
    • Un database non cifrato può essere cifrato effettuandone uno snapshot, cifrandolo e utilizzandolo per ricreare il database stesso
    • Un database cifrato può essere spostato o copiato tra region diverse, selezionando una chiave di cifratura diversa appartenente alla region di destinazione
      • Le chiavi KMS sono confinate alla region di creazione
      • La copia di destinazione deve necessariamente rimanere cifrato

  • Si possono associare Security Group ai database per controllarne l'accesso

  • In genere, utilizzo delle modalità di accesso built-in nei DBMS

    • Per MySQL, PostgreSQL e Aurora, anche autenticazione tramite IAM
      • L'istanza EC2 che si connette ottiene prima un authentication token effettuando una richiesta API a RDS (necessario un ruolo IAM), poi utilizza il token per effettuare la connessione

  • Amazon Aurora: alternativa proprietaria ai DBMS comuni

    • Compatibile con i driver di MySQL e PostgreSQL
    • Più efficiente e performante degli altri, ma più costoso
    • Può disporre di 15 Read Replica
      • Ciascuna replica può diventare l'istanza principale
      • Un unico endpoint per le repliche, con Auto Scaling
    • Di default, ciascun database mantiene 6 copie dei dati attraverso 3 AZ
      • 4 per scrittura, 3 per lettura
      • Failover istantaneo

ElastiCache

  • Servizio managed per sistemi di caching applicativo in-memory

    • Permette di scegliere tra Redis e Memcached

  • Diverse possibili strategie di caching:

    • Write Through: lettura sempre da cache, ciascuna scrittura insiste sia sulla cache, che sul database
      • Dati in cache sempre aggiornati, ma molto spazio occupato in cache, che comporta penalità in scrittura
        • Strong consistency
        • Cache churn: molti dati in cache non saranno utilizzati
      • Utile per accesso frequente a tutti i dati
    • Lazy Loading / Cache-Aside / Lazy Population: lettura sempre da cache, ma il dato è scritto in cache solo in caso di miss e lettura dal database
      • Dati in cache non sempre aggiornati, necessità di prevedere un TTL per i dati in cache, ma poco spazio occupato
        • Eventual consistency
      • Probabilità più alta di cache miss, che comporta anche penalità in lettura derivante dalla necessità di leggere dal database e scrivere in cache

  • Tre possibilità per cache eviction:

    • Cancellazione esplicita di un item
    • Item Least Recently Used (LRU): gli item meno utilizzati vengono rimossi quando la memoria è piena
    • Si specifica un TTL

  • Utilizzando Redis, due possibilità per replicazione:

    • Cluster Mode Disabled: un nodo primary e fino a 5 repliche in sola lettura, con un unico shard
      • Replica asincrona
      • Multi AZ abilitato di default
      • Utile per far scalare le letture
    • Cluster Mode Enabled: più nodi primary in diversi shard, ciascuno con fino a 5 repliche in sola lettura
      • Fino a 500 nodi per cluster (comprendendo sia nodi primary che secondary)
      • Utile per far scalare le scritture

Route 53

  • Servizio managed per DNS

    • Utilizzo di domini pubblici acquistati e di domini privati
    • Possibilità di ottenere load balancing, health check per servizi, routing con policy di vario tipo

  • Hosted zone: insieme di record DNS che fanno riferimento ad uno stesso dominio padre

    • All'interno di una hosted zone, definizione di record di tipo A, CNAME, alias verso servizi AWS, ecc.
    • Possibilità di impostare un TTL per ciascun record, che indica per quanto tempo i client manterranno il valore restituito in cache, senza interrogare nuovamente il servizio
      • TTL alti comportano meno query e costi inferiori, ma possibilità di valori errati in cache
      • Alias: tipo particolare di record che permette di ottenere record simili a CNAME, ma in grado di puntare a nomi di risorse AWS o nomi di altre hosted zone, anche utilizzando domini non di livello root (zone apex)
        • Alias punta ad un dominio, ma è risolto in maniera trasparente in un indirizzo IP, come se fosse un record A
        • Record CNAME non possono avere nomi di livello root
        • Record Alias sono gratuiti, CNAME a pagamento

  • Possibilità di definire health check per gli host riferiti dai record

    • Diversi parametri configurabili: intervallo tra i check, soglia di fallimento

  • Definizione di routing policy, nel caso di record che ritornano più di un valore:

    • Simple: il valore di ritorno è scelto in maniera casuale
    • Weighted: assegnazione di pesi a ciascun valore impostato, per indicare la probabilità con cui essi sono ritornati
    • Latency: il valore è scelto in base alla latenza tra il server riferito e il client
      • Latenza calcolata tra il client e la Region
    • Failover: viene ritornato sempre un valore configurato come primary, con valori secondary che subentrano nel caso di fallimento del primo
      • Il valore primary deve essere associato ad un health check
    • Geolocation: il valore è scelto in base alla posizione geografica del client
      • Posizione indicata come paese o continente
      • Possibilità di definire un valore di default per i casi in cui non ci sia match con la posizione del client
    • Geoproximity: il valore è scelto in base alla posizione geografica del client e ad un valore di bias associato ai diversi valori
      • Il valore di bias aumenta o diminuisce la dimensione dell'area geografica per la quale si restituisce un determinato valore
        • Valore positivo: più utenti verso un certo host
        • Valore negativo: meno utenti verso un certo host
      • Utile per spostare progressivamente il traffico tra regioni diverse
    • Multi Value: più valori vengono ritornati ai client (tutti quelli healthy, se associati ad health check)
      • Fino a 8 valori

VPC

  • Creazione di reti private all'interno del cloud AWS

    • Una VPC esiste all'interno di una specifica Region
    • Definita da uno spazio di indirizzi IPv4 (e opzionalmente da uno spazio IPv6)

  • Una VPC può prevedere più subnet al proprio interno

    • Una subnet appartiene ad un'unica AZ, più subnet possono essere collocate nella stessa AZ
    • Identificate da parti del CIDR block della VPC
    • Public subnet: dispone di una entry nella tabella di routing verso un Internet gateway
      • Le macchine della subnet sono connesse a Internet, accessibili dall'esterno
      • Utili per servizi esposti pubblicamente
    • Private subnet: non ha una rotta verso un Internet gateway, ma dispone di un NAT Gateway
      • Le macchine della subnet possono uscire in Internet, ma non sono pubbliche e non possono ricevere traffico in ingresso
      • Il NAT Gateway è posto in una subnet pubblica, la tabella di routing associata alla rete privata invia ad esso il traffico in uscita verso Internet
      • Utili per istanze di backend, data store

  • Occorre prevedere almeno una route table per ciascuna VPC

    • Route table di default, eventualmente modificabile

  • Sicurezza tramite Network ACLs (NACL), che agiscono da firewall per una VPC

    • Regole che permettono o bloccano il traffico in entrata e in uscita
    • Definite al livello di subnet
    • Diverse dai Security Group, che agiscono al livello di istanze EC2 (ENI) e possono avere solo regole di tipo ALLOW

  • VPC Flow Logs: log su CloudWatch Logs o S3 relativi al traffico che attraversa le interfacce di una VPC

    • Log a livello di intera VPC, singole subnet o ENI

  • VPC Peering: possibilità di connettere tra loro due VPC che non abbiano range di indirizzi in comune

    • Nessuna transitività: ciascuna coppia di VPC deve essere interconnessa singolarmente

  • VPC Endpoints: interfacce per connettere risorse AWS a VPC e subnet in maniera privata, evitando di passare per Internet

  • Connessione di reti on-premises a VPC

    • Site to Site VPN: attraverso Internet, con cifratura automatica
    • Direct Connect (DX): connessione fisica e privata alla rete AWS

  • Esistono use case che prevedono l'utilizzo di un'unica VPC

    • High-performance computing
    • Applicazioni web di portata limitata

  • In ambiti aziendali è diffusa una struttura multi-VPC e multi-account

    • Account principale che si occupa della fatturazione per tutti gli account e degli utenti
    • Ciascuno degli altri account è dedicato ad uno specifico servizio
      • Ad esempio, un particolare ambiente di un'applicazione

S3

  • Storage a oggetti

    • Costi in base all'uso: vengono calcolati lo spazio occupato e le richieste effettuate (in base al tipo), ma non la larghezza di banda occupata per effettuare trasferimento dati in entrata a S3 da Internet

  • S3 Access Points: endpoint che permettono di accedere ad un bucket a cui sono associate determinate policy di accesso

    • Permettono di condividere URL verso risorse poste su S3 in maniera sicura

  • Hosting di siti web statici: un caso d'uso frequente di S3 riguarda la possibilità di ospitare siti statici

    • Possibilità di configurare CORS

  • Si può configurare la storage class da utilizzare per le risorse di un bucket, che definisce le caratteristiche di durabilità dei dati e le prestazioni di trasferimento

    • Glacier: storage a oggetti per archiviazione di dati a lungo termine
      • Due possibilità:
        • S3 Glacier: classe standard
        • S3 Glacier Deep Archive: per archiviazione a lungo termine e ad accesso molto poco frequente (una/due volte all'anno), costo basso
      • Possibile definire una politica di retrieval, in base alle necessità
        • Expedited: lettura veloce del file (1-5 minuti), ma costo elevato (non disponibile per Deep Archive)
        • Standard: lettura più lenta (3-5 ore), con costo inferiore
          • Policy di default
        • Bulk: attesa di 5-12 ore per avere la risorsa, ma costo ancora più basso
          • Utile per dati di dimensioni molto elevate, non necessari subito
    • Intelligent-Tiering: modalità di storage dinamica, adatta a dati per cui si prevedono pattern di accesso variabili
      • Utilizza tre sottoclassi, Frequent Access, Infrequent Access, Archive Instant
      • Monitoring automatico dei dati e delle modalità con cui vi si accede al fine di spostarli nella classe più conveniente
        • Inizialmente salvati nella prima classe, spostati nella seconda e nella terza dopo rispettivamente 30 e 90 giorni senza accessi

  • Tre modi diversi per ottenere cifratura

    • SSE-S3: cifratura degli oggetti direttamente su S3, in maniera totalmente gestita da S3
    • SSE-KMS: cifratura su S3, ma utilizzando chiavi definite in KMS
      • Possibile fare auditing delle operazioni
      • Richiede header x-amz-server-side-encryption: aws:kms
        • Si può aggiungere una policy che blocchi richieste sprovviste dell'header per forzare l'utilizzo di cifratura
      • Utilizza le API KMS GenerateDataKey e Decrypt in coppia, per poter cifrare dati più grandi di 4 KB
      • Richiede:
        • Una KMS Key Policy che autorizzi l'identità IAM
        • Una policy IAM che autorizzi l'identità IAM all'accesso a KMS
      • S3 Bucket Key: chiave generabile una-tantum da una CMK di KMS, utilizzata poi per generare tante data keys per cifrare gli oggetti caricati, non dovendo così passare più per KMS
    • SSE-C: cifratura su S3, ma utilizzando chiavi proprie dell'utente
    • Cifratura lato client, totalmente gestita dall'utente prima di caricare gli oggetti

  • Si può forzare l'utilizzo di SSL mediante una policy che blocchi richieste che non lo utilizzino

    • DENY su aws:SecureTransport = false

CloudFront

  • CDN globale

    • Sfrutta le Edge Location

  • Si definiscono distribution, che corrispondono al contenuto da servire agli utenti

    • Ciascuna distribution ha associata una origin, che ospita le risorse da servire
      • Risorse statiche, come bucket S3
      • Risorse dinamiche, come web app, anche ospitate on-premises
    • I contenuti di una distribution sono salvati sulle varie Edge Location, così che gli utenti possano essere serviti secondo criteri geografici
    • I contenuti sono di fatto cacheati, in caso di miss (o di contenuti dinamici), la distribution si rivolge alla propria origin per recuperarli, attraversando la rete backbone di AWS
      • Diversi modi per definire scadenza dei dati sulle Edge Location:
        • TTL (If-Modified-Since header nella richiesta da CloudFront a origin)
        • Modifica dei nomi dei file per le risorse statiche servite
        • Invalidazione della distribuzione
          • Poco efficiente, in genere da considerare come ultima possibilità

  • Più possibilità per sicurezza:

    • Origin Access Identity (OAI): identità utilizzata dalla distribution e associata all'origin, per consentire accesso esclusivo a quest'ultima
    • Geo Restriction: controllo degli accessi in base a paesi o aree geografiche di provenienza
    • Viewer Protocol Policy e Origin Protocol Policy: possibilità di accettare o meno traffico HTTP, e eventualmente di redirigerlo a HTTPS, rispettivamente tra client e CloudFront e tra CloudFront e origin
    • Field Level Encryption: layer aggiuntivo di cifratura per singoli campi di richieste effettuate alla distribution (ad esempio, richieste POST per form web), che vengono inoltrati ai server dell'origin cifrati

  • Due modi per servire contenuti ad accesso riservato

    • Signed URL: URL che permettono accesso diretto a singoli file serviti da CloudFront e non accessibili pubblicamente
      • Hanno una scadenza configurabile
      • Permettono di filtrare per IP dei client
      • Utili ad esempio se si utilizza una OAI e i client non hanno accesso diretto all'origin, in alternativa agli S3 Pre-Signed URL
      • Generabili tramite chiavi aggiunte ad un trusted key group definito per la distribution
        • In alternativa ai trusted key group, si possono usare coppie di chiavi CloudFront associate ad un account AWS (sconsigliato, occorrerebbe necessariamente usare il root account per gestire tali chiavi)
    • Signed Cookie: simili agli URL, ma utilizzabili per accesso a più di un file

  • Costo variabile in base alla Edge Location da cui si è serviti

    • Price Class per abilitare tutte le Edge Location o solo alcune di esse

  • Origin Groups: più origin per la stessa distribution, al fine di consentire failover in caso di crash

ECS

  • Cluster: raggruppamento di servizi in esecuzione, composto a livello infrastrutturale da una flotta di istanze EC2

  • Task definition: collezione di uno o più container con le rispettive configurazioni

  • Task: specifica istanza di una task definition

    • Messo in esecuzione manualmente

  • Service: modalità di lancio dei task alternativa a quella manuale

    • Monitora il task in esecuzione al fine di mantenerlo sempre attivo
    • Permette di specificare il numero minimo e massimo di ciascun task, l'autoscaling, ecc.

  • Si può avere bilanciamento su più copie di un container (un service con 4 task) utilizzando un Application Load Balancer

    • Nella task definition occorre effettuare mapping delle porte senza indicare la porta dell'host
      • Dynamic port mapping
    • Il load balancer deve essere creato manualmente, senza alcun target group
    • Il cluster deve essere configurato per permettere tutto il traffico su qualsiasi porta dal security group del load balancer

  • Ruoli IAM necessari

    • Uno a livello di EC2, utilizzato dall'ECS agent per operare (fare pull di immagini da ECR, permettere log su CloudWatch, ecc.)
      • EC2 Instance Profile
    • Uno a livello di task, per permettere ad esso di interagire con i servizi di cui necessita
      • ECS task role

  • Task placement

    • Strategie e vincoli per stabilire come scegliere le istanze per i task da lanciare
    • Specificabili al lancio manuale di un task o alla creazione di un service
    • ECS piazza un nuovo task controllando, nell'ordine
      1. requisiti rispettati sulle istanze
      2. vincoli impostati
      3. strategia impostata
    • Strategie possibili
      • binpack: riempio un'istanza il più possibile secondo una metrica (memoria disponibile, CPU, ecc.) prima di passare ad un'altra
      • random
      • spread: dispongo equamente sulle istanze disponibili rispetto alla metrica selezionata (memoria disponibile, AZ, ecc.)
    • Vincoli possibili
      • distinctInstance: ogni task deve trovarsi su un'istanza diversa
      • memberOf: permette di utilizzare un DSL per descrivere l'istanza che può ospitare il task

  • Autoscaling ha concettualmente lo stesso funzionamento di quello di EC2

    • Target tracking, step scaling, scheduled scaling
    • Non è la stessa cosa!
      • ECS scala a livello dei task
      • EC2 scala con le istanze
    • Capacity Provider semplificano le cose
      • Associati ad un servizio ECS e ad un autoscaling group
      • Descrivono la capacità delle istanze che ospitano il servizio
      • Sovrascrivono il capacity provider di default del cluster (che non è necessariamente presente)

  • Occorre fare attenzione allo stato delle istanze su cui eseguono i container: se l'istanza è in stato STOPPED, occorre rimuoverla manualmente dal cluster ECS prima di terminarla

ECR

  • Repository privato per immagini Docker

  • Necessario un ruolo IAM affinché un servizio (una task definition) possa accedervi

  • Login tramite CLI diverso tra v1 e v2

    • v1: eval dell'output di ecr get-login
    • v2: ecr get-login-password | docker login --password-stdin

Fargate

  • Nessuna necessità di creare le EC2 che compongono il cluster ECS
    • ECS serverless
    • Autoscaling automatico
    • A parità di risorse lanciate, più costoso rispetto ad una gestione manuale di ECS

Elastic Beanstalk

  • PaaS di AWS

  • Un'applicazione è associata ad uno o più environment e può avere più versioni

    • Environment di default, modificabile all'atto della creazione dell'applicazione
    • Environment aggiuntivi, creati in seguito

  • L'environment specifica la piattaforma su cui l'applicazione è eseguita

    • Web server environment
      • Dominio
      • Codice dell'applicazione
      • Runtime
      • Logging
      • Tipo di istanze
      • Capacity / numero di istanze / HA / autoscaling
      • Database
      • ...
    • Worker environment
      • Per esecuzione di task batch, periodici, in background

  • Diverse Modalità di deployment

    • All at once: sostituzione brutale sulle stesse istanze
      • Veloce
      • Con downtime
      • Zero costi aggiuntivi
    • Rolling: un batch (set di istanze configurabile) alla volta
      • Lento
      • Zero costi aggiuntivi
      • Più versioni in esecuzione alla volta
      • Ci sono momenti in cui solo alcune istanze sono attive (si è sotto la capacity)
    • Rolling with additional batches: come rolling, ma si aggiungono istanze per rimanere sempre alla capacity desiderata
      • Ok per prod
      • Più costoso, si accendono nuove istanze
    • Immutable: si aggiungono tante istanze quanta è la capacity, si installano e si sostituiscono le vecchie
      • Molto costoso
      • Zero downtime
      • Ottimo per prod
    • Si può avere anche un blue/green deployment, creando un nuovo environment e installando lì la nuova versione
      • Manuale
        1. Si installa la nuova versione su una nuova istanza
        2. URL swap sulla vecchia istanza: modifica la configurazione di Route 53 in maniera trasparente per puntare alla nuova istanza
      • Comodo per rollback in caso di fallimenti: occorre solo modificare l'URL

  • Opportuno definire lifecycle settings per evitare accumulo di versioni (limite di 1000 per applicazione)

    • Numero di versioni, età delle versioni, ecc.

  • La configurazione dell'environment può avvenire anche tramite file nell'applicazione

    • .ebextensions/*.config
    • Utilizza CloudFormation, quindi è possibile creare qualsiasi tipo di risorsa

  • Si possono clonare environment, ad esempio per creare ambienti di staging da uno di prod

  • Per prod è meglio non utilizzare un database definito nell'environment, ma crearne uno indipendente

    • Per mantenere un DB quando si distrugge un environment occorre farne un backup prima

  • Docker su EB

    • Presente tra i vari runtime
    • Single container, tramite Dockerfile o eseguendo un'immagine già esistente
    • Multi container, che prevede la creazione di una task definition e di un cluster ECS

CodeCommit

  • Git repository

  • Autorizzazione tramite IAM

  • Notifiche verso altri servizi quando si verificano eventi su di un repository

    • SNS / Lambda: modifiche al codice (push su main branch, nuovi branch, merge, ecc.)
    • CloudWatch Event Rules: pull request aggiornate, commenti, ecc.

CodePipeline

  • Tool di CI, orchestratore dei servizi Code*

  • Una pipeline necessita di un ruolo IAM per interagire con gli altri servizi

  • Ciascuno step della pipeline genera un artefatto, salvato su S3 e passato allo step successivo

  • Una pipeline è lanciata attraverso CloudWatch Events, emessi ad esempio quando ci sono cambiamenti al repository

    • In alternativa, CodePipeline può fare polling, sconsigliato

  • Ciascuno step emette eventi CloudWatch, utilizzabili per troubleshooting

    • A loro volta, possono scatenare notifiche SNS
    • Ad esempio, si possono prevedere eventi per pipeline fallite

  • Ciascuno step può avere action group associato

    • Gli action group sono sequenziali
    • Ciascun action group è composto da più action parallele
      • Diverse tipologie (provider)

CodeBuild

  • Build tool, si inserisce in uno step di CodePipeline, oppure si utilizza stand-alone

    • Anche con VCS esterni (GitHub)

  • Completamente gestito e pay-per-usage, non necessita di istanze sempre accese (al contrario di Jenkins su EC2)

  • Supporta molti runtime, estensibile poiché utilizza Docker

    • Si può definire un Dockerfile per un'immagine custom, oppure utilizzarne una managed
    • Container creati per la build e cancellati subito dopo

  • Istruzioni di build definite nella root del sorgente, nel file buildspec.yml

    • Più step:
      • install: specifica del runtime
      • pre-build, build, post-build: comandi da eseguire

  • CodeBuild lancia i container fuori dalla propria VPC, si può specificare la VPC desiderata per consentire interazione con le relative risorse

    • Si specificano la VPC, le subnet (solo le private se si vuole connessione a Internet, tramite NAT gateway) e i security group desiderati

  • Per variabili d'ambiente con segreti o credenziali è opportuno utilizzare SSM Parameter Store o Secrets Manager

    • Specifica di una variabile d'ambiente di tipo Parameter o Secrets Manager, con il nome della entry come valore
    • Necessario fare in modo che il ruolo di CodeBuild abbia accesso al servizio utilizzato

CodeDeploy

  • Deployment su EC2 (anche Lambda o ECS)

    • Ciascuna EC2 deve avere l'agent di CodeDeploy in esecuzione

  • appspec.yml per definire come eseguire il deployment

    • Definizione della posizione del sorgente
    • Hooks per definire gli step del deployment
    • Configurazione
      • Strategia di deployment (pattern simili a quelli di Elastic Beanstalk)
        • In-place: aggiorna le istanze esistenti un po' alla volta
        • Blue/green: crea un nuovo ASG copiando quello esistente, con una nuova Launch configuration
      • Failure handling
        • Rollback in caso di fallimenti
        • Un rollback utilizza l'ultima immagine valida e crea una nuova versione
      • Target (istanze EC2 oppure ASG)

  • Necessita di un ruolo IAM

    • Anche le istanze EC2 devono avere un ruolo, con policy per leggere da S3 se si ha il codice su AWS

  • Deployment group: insieme di istanze target di un deployment

    • Si definisce un insieme di tag e le istanze che hanno quei tag fanno parte del gruppo

CodeStar

  • Wrapper per i servizi Code*, più CloudFormation, CloudWatch, issue tracking, Cloud9

  • Permette di gestire un progetto software per intero

CloudFormation

  • Stack creati a partire da template

    • Template hanno versioni, non sono modificabili, per aggiornare stack occorre una nuova versione
    • Formato YAML o JSON (sconsigliato), salvati su S3
    • Modificabili anche dall'apposito Designer

  • Un template può descrivere componenti di diverso tipo

    • Resources
      • Dichiarate staticamente (no codice per derivarle)
    • Parameters
      • Riferiti con Fn::Ref <nome> o !Ref <nome>, dove nome può essere un parametro o una risorsa dichiarata
      • Pseudo-parametri sono disponibili, iniettati da AWS
    • Mappings
      • Costanti
      • Riferite con Fn::FindInMap <nome-mappa> <top-level-key> <second-level-key>
    • Outputs
      • Valori esportati, a disposizione di altri template
      • Export per esportare, Fn::ImportValue per riferire
      • Devono essere unici in tutta la Region
    • Conditionals
      • Condizioni definite e richiamate nel template
    • Metadata

  • Intrinsic functions

    • Fn::Ref: utilizzata per riferire risorse o parametri
    • Fn::GetAtt: permette di accedere agli attributi di una risorsa
    • Fn::FindInMap: permette di leggere mapping
    • Fn::ImportValue: importa output di altri template
    • Fn::Join: concatena valori
    • Fn::Sub: sostituisce valori
    • Funzioni per operatori logici

  • In caso di fallimento nella creazione di uno stack la politica di default è di avere un rollback

    • Si può disabilitare per lasciare le risorse create prima del fallimento e fare troubleshooting

  • ChangeSets: permettono di visualizzare le modifiche che l'esecuzione di un template comporterebbe

  • NestedStacks: moduli innestati in uno stack, per riutilizzo

  • CrossStacks: stack che sono utili ad altri stack (ad esempio lo stack per una VPC) ed esportano valori

  • StackSets: stack lanciati su account e Region diversi con un'unica operazione

CloudWatch

  • Metrics

    • Variabili osservate (ad esempio, utilizzo hardware)
    • Visualizzabili direttamente, oppure tramite un grafico temporale osservabile
    • Raggruppate per namespace
    • Raccolte a intervalli di 5 minuti, ma regolabile anche a valori più bassi (Detailed Monitoring)
    • Possibile anche definirne di custom
      • Intervalli di un minuto, fino a un secondo (High Resolution) tramite parametro StorageResolution

  • Alarms

    • Trigger di notifiche relative alle metriche
    • Stato
      • OK: metrica nei valori accettati
      • ALARM: metrica nei valori non accettati
      • INSUFFICIENT DATA: osservazione appena iniziata, in attesa di aggiornamenti della metrica
    • Intervalli fino a 10 secondi (non più bassi, nemmeno con metriche High Resolution)

  • Logs

    • Log inviati dai servizi
    • Necessario un ruolo IAM sul servizio per inviare a CloudWatch
    • Log esportabili su S3
    • Metric filter: dai log è possibile applicare dei filtri e creare metriche basate su essi
    • Non scadono di default, si può impostare una scadenza

  • Per inviare log EC2 necessita del CloudWatch Agent e di un apposito ruolo IAM

    • Logs agent: vecchia versione, può inviare solo a CloudWatch Logs
    • Unified agent: nuova versione, raccoglie anche metriche oltre ai log (utilizzo hardware, processi, rete, ecc.)

  • Possibilità di cifrare log associando una CMK KMS ad un log group

    • Non effettuabile da console, necessario utilizzare API associate-kms-key (se il log group esiste) o create-log-group (se il log group non esiste ancora)
    • Occorre modificare la key policy della CMK per consentire l'accesso a CloudWatch Logs

  • Events

    • Eventi schedulati (cron)
    • Eventi sulla base di pattern, in reazione ad azioni compiute su un servizio (ad esempio, cambio di stato di una pipeline)
    • Evoluzione di Events: EventBridge, che aggiunge la possibilità di raccogliere trigger per eventi da servizi esterni (anche custom)
      • Custom schema registry: permette di definire il proprio set di eventi utilizzabili per i pattern

X-Ray

  • Permette di tracciare tutta l'attività di un'applicazione alla ricezione di una richiesta e di osservare come i vari servizi interagiscono tra loro

  • Attivabile tramite integrazione dell'SDK, esecuzione del rispettivo demone e configurazione del ruolo IAM necessario

    • I servizi serverless hanno il demone abilitato
    • Elastic Beanstalk necessita che il demone sia specificato in .ebextensions/

  • Tramite l'SDK è possibile fare instrumentation, per configurare quali dati analizzare e inviare a X-Ray

    • Segment: dato inviato da un servizio
    • Trace: insieme di segment che formano un link end-to-end
    • Sampling: regole per modificare la quantità di dati inviati
      • Reservoir: quantità di richieste inviate sempre per ogni secondo
      • Rate: percentuale di richieste rimanenti in ciascun secondo oltre alla reservoir
      • Regole per matchare in base a parametri (nome e tipo del servizio, metodo HTTP, ecc.)
    • Annotation: campi chiave-valore che permettono di indicizzare e filtrare i trace
    • Metadata: campi chiave valore non indicizzati

  • API di X-Ray

    • Vanno autorizzate in un'apposita policy IAM
    • Scrittura
      • PutTraceSegments e PutTelemetryRecords: upload di segment e dati statistici del demone (segment inviati, rifiutati, ecc.)
      • GetSamplingRules, GetSamplingTargets e GetSamplingStatisticSummary: necessari al demone per sapere come agire
    • Lettura
      • GetServiceGraph: accesso al grafico di X-Ray
      • BatchGetTraces: trace in base all'ID
      • GetTraceSummaries: ID dei trace in base a filtri
      • GetTraceGraph: grafico di uno o più trace in base agli ID

  • In ECS, due soluzioni possibili per il demone

    • Un container per ciascuna EC2
    • Un container sidecar per ogni container applicativo su tutte le EC2
    • Fargate: solo il pattern sidecar è possibile, un sidecar per ogni task
    • Container con mapping della porta 2000, sui container applicativi link verso il container e variabile d'ambiente AWS_XRAY_DAEMON_ADDRESS che punta a quella porta del container

CloudTrail

  • Mantiene uno storico di tutte le azioni compiute sull'account

    • Eventi, chiamate API, ecc.

  • Si può integrare con CloudWatch

  • Per quanto riguarda l'auditing di S3, di default solo le operazioni sui bucket sono riportate, è possibile abilitare anche il tracciamento delle azioni sugli oggetti accendendo S3 Data Events

  • Possibilità di creare Trail per Organization

    • Di default gli account membri possono vedere il trail, ma non modificarlo o cancellarlo, e non hanno accesso ai file S3 che lo compongono

SQS

  • Servizio per code

Standard Queues

  • Throughput illimitato per inviare messaggi

  • Retention dei messaggi tra 4 (default) e 14 giorni

  • Limite di 256 KB per messaggio, nessun limite sul numero di messaggi in una coda

  • Consegna at-least-once, con ordinamento best-effort

  • Consumer

    • Possono essere servizi su EC2, on-premises e anche Lambda
    • Possono ritirare al massimo 10 messaggi alla volta
    • Più di uno su ciascuna coda
    • Devono cancellare i messaggi ricevuti dalla coda con DeleteMessage
      • Limite di 120000 messaggi ricevuti, ma non cancellati
    • Devono scalare con le dimensioni della coda
      • Metrica CloudWatch sulla lunghezza della coda, per comandare lo scaling dei consumer in un ASG

  • I messaggi possono essere cifrati anche sulla coda, oltre che quando in transito

  • Controllo degli accessi con IAM, oppure tramite SQS Access Policies

  • Visibility Timeout: finestra di tempo avviata alla ricezione di un messaggio da parte di un consumer, durante la quale il messaggio non è ritornato ai poll di altri consumer

    • Se troppo alto, rischio di tempi di processamento lunghi
      • Caso in cui un consumer legge e va in crash prima di finire il processamento
    • Se troppo basso, rischio di processamenti multipli
      • Caso in cui un consumer legge e non fa in tempo a finire il processamento e a cancellare il messaggio nella finestra
    • ChangeMessageVisibility: API per permettere ai consumer di rinnovare il timeout

  • Dead Letter Queue: coda nella quale finiscono i messaggi per i quali il processamento è fallito molteplici volte

    • MaximumReceives: valore di soglia che indica il numero di tentativi di processamento da effettuare (e pertanto il numero di volte in cui un messaggio rientra nella coda) prima di inserire un messaggio nella DLQ
    • Si tratta di una normale coda SQS
    • Anche i messaggi nella DLQ scadono
      • Considerare un periodo di retention lungo

  • Delivery delay: indica un delay da applicare all'istante di visibilità dei messaggi da parte dei consumer

    • Default a 0
    • Impostabile a livello di coda e ridefinibile al momento dell'invio da parte dei producer (parametro DelaySeconds)

  • Long polling: possibilità per i consumer di attendere per un certo intervallo di tempo sulla chiamata di poll ReceiveMessage

    • Doppio beneficio:
      • Riduce il numero di richieste effettuate
      • Riduce la latenza di ricezione
    • Impostabile tra 1 e 20 secondi
    • Impostabile a livello di coda e ridefinibile al momento della chiamata (parametro WaitTimeSeconds)

  • SQS Extended Client: permette di inviare messaggi più grandi di 256KB

    • In realtà carica il payload su S3 e invia un messaggio con solo metadati a SQS

  • API principali:

    • CreateQueue, DeleteQueue
    • PurgeQueue: cancella tutti i messaggi nella coda
    • SendMessage, ReceiveMessage, ReceiveMessageWaitTimeSeconds, ChangeMessageVisibility, DeleteMessage
      • Anche batch

FIFO Queues

  • Code con semantica exactly-once e con garanzia di ordinamento

    • Deduplication dei messaggi

  • Throughput limitato

    • 300 msg/s (3000 se invio con batching)

  • Deduplication dei messaggi può avvenire in due modi:

    • Hash del contenuto dei messaggi
    • ID applicato ai messaggi stessi

  • MessageGroupID: permette di associare un messaggio a un gruppo, in modo che venga processato sempre dallo stesso consumer

    • In assenza di diversi gruppi, una coda può avere un unico consumer
    • Ciascun gruppo può avere ordinamento al suo interno

SNS

  • Servizio di notifica pub/sub

  • Ciascun subscriber di un topic riceve tutti i messaggi di quel topic

    • Fino a 10 milioni di subscriber

  • Subscriber di vari tipi

    • Code SQS
    • Endpoint HTTP
    • Lambda
    • Mail
    • SMS
    • Notifiche mobile

  • Anche altri servizi possono essere publisher

    • CloudWatch
    • ASG
    • S3

  • Riguardo alla cifratura e al controllo degli accessi, stesse opzioni di SQS

  • SNS + SQS Fan out: più code SQS sono subscriber di un topic SNS

    • Invio una volta e permetto il processamento del messaggio in maniera asincrona da parte di tutti i consumer delle code
    • Permette di aggiungere nuovi consumer quando necessario
      • Estensibilità
    • Occorre concedere a SNS l'accesso in scrittura alle code nella SQS Access Policy
    • Non è possibile scrivere su code FIFO
    • Possibile caso d'uso: su S3 si può avere una sola Event Rule per coppia "prefisso path - tipo di evento"; per aggirare questa limitazione, si può inviare l'evento a più code SQS e avere consumer diversi

Kinesis

  • Tool per streaming e processamento di big data, anche in tempo reale, alternativa a Apache Kafka

    • Log, telemetria, IoT

  • Tre sottoprodotti principali

    • Kinesis Streams: streaming di dati (utilizzo classico)
    • Kinesis Analytics: analisi in tempo reale su stream con SQL
    • Kinesis Data Firehose: ingestion e caricamento su S3, Redshift, ElasticSearch, ecc.

Kinesis Streams

  • Convoglia stream di dati

  • Gli stream possono essere divisi in shard, per parallelizzare e aumentare il throughput verso la destinazione

    • 1 MB/s in scrittura, 2 MB/s in lettura per shard

  • Retention di un giorno, incrementabile fino a 7 giorni

  • Permette di riprocessare e risottomettere i dati

    • Contrario rispetto a quanto avviene in SQS

  • Più applicazioni possono processare lo stesso stream

  • I dati inseriti non sono eliminabili

  • I record inseriti sono ordinati per shard

  • Inserendo un messaggio (PutRecord), si specifica una partition key, sulla base di cui si stabilisce in quale shard il messaggio verrà convogliato

    • La partition key deve avere una natura molto sparsa, per avere valori diversi e ottimizzare la collocazione (ad esempio, user id)

  • ProvisionedThroughputExceeded se si supera il limite di throughput

  • Per realizzare producer e consumer è possibile usare Kinesis Producer Library e Kinesis Client Library, rispettivamente

    • Ciascuno shard può essere letto da una sola istanza di KCL
    • Un'istanza di KCL può essere eseguita su EC2, Elastic Beanstalk oppure on-premises
    • Gli shard sono letti in ordine su ciascuno shard
    • KCL salva checkpoint per le letture su DynamoDB

  • API principali:

    • DescribeStream: permette di ottenere informazioni su uno stream (nome, shard, ecc.)
    • PutRecord: inserisce un record
      • Occorre passare stream name, partition key e payload
    • GetShardIterator: permette di ottenere un iteratore per leggere record da uno stream
      • Occorre passare stream name, shard id e tipo dell'iteratore
    • GetRecords: legge record da uno shard iterator
      • Occorre passare shard iterator

  • Paragonabile a SQS FIFO

    • In Data Streams si possono avere più shard per stream, ciascuno letto da un consumer diverso, distribuendo i record sulla base della partition key, ottenendo così parallelismo e un throughput alto
    • In SQS si ha una sola coda, da cui possono leggere tanti consumer tramite i gruppi
    • In Data Streams, ordinamento all'interno degli shard (letture in parallelo), in SQS ordinamento all'interno dell'unica coda (lettura in sequenza, ma potenzialmente da più consumer)

  • Sicurezza tramite IAM, cifratura tramite HTTPS/KMS

Kinesis Data Analytics

  • Effettua analisi in tempo reale su stream di Kinesis Streams
    • Impiego di SQL
  • Completamente gestito

Kinesis Data Firehose

  • Carica dati quasi in tempo reale su Redshift, S3, ElasticSearch, ecc.
  • Permette di convertire il formato dei dati
  • Completamente gestito

Lambda

  • Funzioni invocabili on-demand

    • Limite temporale su ciascuna esecuzione

  • Le risorse utilizzate possono essere controllate

    • RAM, e di conseguenza CPU e rete

  • Una funzione necessita di un ruolo IAM

    • Accesso a CloudWatch

  • Logging su CloudWatch

    • Un log stream per invocazione

  • Una funzione riceve in ingresso un evento, descritto come un oggetto JSON

  • Synchronous Invocation

    • Modalità utilizzata invocando la funzione da CLI, SDK, API Gateway, ALB, ecc.
    • Il client attende il risultato e si occupa dell'error handling
    • Si può usare un ALB per esporre una Lambda tramite endpoint HTTP
      • Registrazione in un target group
      • ALB deve avere una policy per invocare la Lambda
      • ALB trasforma la richiesta HTTP in un documento JSON, e fa altrettanto con la risposta
      • Sull'ALB si possono attivare i Multi-Header Values, per poter passare array come valori dei parametri (in query string o negli header): si passa la stessa chiave più volte con tutti i valori desiderati

  • Lambda@Edge: deployment di una Lambda non in una Region specifica, ma su CloudFront

    • Modifica richieste e risposte verso e da CloudFront
    • Vari casi d'uso, tra cui API per siti web statici su S3, autenticazione, A/B testing, ecc.

  • Asynchronous Invocation

    • Modalità utilizzata da Event Notification di S3, SNS, CloudWatch Events, ecc.
    • La Lambda è dotata di una coda in cui gli eventi di trigger sono raccolti, la funzione legge gli eventi e viene invocata
    • Sono possibili fallimenti e tentativi multipli di invocazione per ciascun evento, quindi la funzione deve essere idempotente
      • Tentativi multipli riportano lo stesso RequestId
    • Può essere opportuno definire una DLQ in SQS
    • Diverse possibilità per il trigger
      • Si possono definire EventBridge Rule come cron (schedule pattern) o con CodePipeline
      • S3 Event Notification: invocazione passando per code SQS, fan out con SNS oppure diretta
        • Se notifiche relative a interazioni (scritture) con oggetti non versionati, in caso di interazioni concorrenti potrebbe essere scatenata una sola invocazione; abilitando il versionamento sui bucket si può evitare il problema

  • Event Source Mapping

    • Modalità che si applica a Kinesis Data Streams, code SQS e DynamoDB Streams
    • La funzione Lambda effettua polling, al recupero di un record viene invocata in maniera sincrona
    • Kinesis Data Streams e DynamoDB Streams
      • Una volta processato un record, esso non viene cancellato dallo stream
      • Si possono accumulare record (batch) per processarli con un'unica invocazione
        • Fino a 10 batch concorrenti per shard contemporaneamente (processamento in ordine in ciascuno shard)
      • In caso di errori, un batch viene riprocessato e nel frattempo non vengono processati altri batch relativi allo stream
        • Si può configurare il mapping per scartare record che danno errore o limitare il numero di tentativi
    • Code SQS
      • Mapping effettua long polling specificando una batch size
      • Se si vuole usare una DLQ, occorre impostarla lato SQS, oppure usare una Lambda Destination
      • Si possono usare code FIFO se si vuole processamento in ordine
      • Una volta processato un record, Lambda si occupa di eliminarlo
      • Fino a 1000 batch contemporaneamente
        • Fino a 60 istanze in più per scalare
      • In code FIFO, processamento di ciascun message group in ordine e scaling fino al numero di message group attivi
      • La Lambda deve poter leggere da SQS

  • Lambda Destinations: possibilità di definire destinazioni per il risultato delle invocazioni

    • Sia in caso di successo che di fallimento
    • Consigliato rispetto all'uso di DLQ

  • Diverse policy managed per i ruoli delle Lambda

    • Lettura dalle diverse sorgenti
    • Scrittura log su CloudWatch e X-Ray
    • Deploy in VPC

  • Nel caso in cui la Lambda sia invocata da altri servizi si possono utilizzare Resource Based Policy

    • Simile a S3 bucket policy
    • Un IAM principal può invocare una Lambda se ha di per sé una policy che glielo permette, oppure se una resource based policy della Lambda lo autorizza
      • Nel caso di Lambda con un bucket S3 come source, l'invocazione è permessa dalla resource based policy
      • Nel caso di SQS come source, non serve alcuna policy per SQS, è Lambda che fa polling da SQS

  • Si possono definire variabili d'ambiente per le Lambda

    • Eventualmente, si possono cifrare
    • Numero di variabili illimitato, ma dimensione massima consentita di 4 KB

  • Lambda può scrivere log e metriche su CloudWatch, e trace su X-Ray

    • Metriche relative a numero di invocazioni, numero di errori, percentuale di successo, ecc.
    • Per X-Ray, occorre abilitarlo nella configurazione di una Lambda, settare le variabili d'ambiente per trace id e path del demone di X-Ray e prevederlo nel ruolo della Lambda

  • Di default, le Lambda sono eseguite in una VPC di AWS, ma si può specificare una VPC diversa in cui lanciarle

    • Si definisce il VPC id, la subnet e il security group, in più si configura il ruolo IAM per poter accedere alla VPC e per poter creare interfacce ENI (occorrono alla Lambda)
    • Di default, le Lambda eseguite nella propria VPC non hanno accesso a Internet, per ovviare a questo si possono utilizzare NAT Instance e NAT Gateway; per accedere ad altri servizi AWS si possono utilizzare i VPC Endpoint

  • Per poter incrementare la capacità di calcolo di una Lambda, occorre incrementare la RAM

    • Più RAM, più vCPU credit
    • Fino a 3008 MB, con incremento di 64 MB alla volta

  • Di default le Lambda hanno un timeout di 3 secondi, incrementabile fino a 15 minuti

  • Lambda Execution Context: permette di definire oggetti e risorse da condividere attraverso esecuzioni multiple

    • Connessioni a DB, client HTTP, riferimenti a SDK, ecc.
    • Si possono definire oggetti fuori dall'handler, saranno condivisi da tutte le invocazioni
    • La directory /tmp è utilizzabile per buffer su storage e operazioni che lo richiedono (fino a 512 MB)

  • Fino a 1000 invocazioni concorrenti per account per Region

    • Se si supera la soglia, throttle
      • Per invocazioni sincrone, ThrottleError
      • Per invocazioni asincrone, retry con intervalli esponenziali e in seguito DLQ
    • Il limite è condiviso anche tra più Lambda diverse
    • Reserved concurrency: numero di istanze concorrenti riservate esclusivamente ad una particolare Lambda, non utilizzabili da altre
      • Serve anche a limitare la concurrency di una particolare funzione

  • Cold start: la prima invocazione di una Lambda (anche dopo un po' di tempo o dopo una modifica) è più lenta delle altre, poiché esegue il codice esterno all'handler per preparare l'ambiente

    • Provisioned concurrency per ovviare al problema: si specifica un numero di ambienti sempre pronti, per evitare i tempi del cold start
      • Scalabile automaticamente con Application Auto Scaling
      • Non può superare il valore di reserved concurrency

  • Dipendenze esterne di una Lambda vanno incluse nell'archivio assieme al codice

    • Solo l'SDK di base di AWS è incluso di default

  • Per definire Lambda da CloudFormation, due modalità:

    • Inline: direttamente nel template
      • Solo per funzioni semplici, prive di dipendenze esterne
    • Attraverso S3: si carica l'archivio in un bucket e lo si riferisce dal template
      • Occorre aggiornare le chiavi apposite nel template quando si aggiorna la Lambda (S3Bucket, S3Key o S3ObjectVersionParam)

  • Lambda Layers: permette di definire runtime custom per le Lambda e di fattorizzare dipendenze per riutilizzarle

    • Modularizzazione di Lambda in più layer
    • Si aggiungono layer ad una Lambda per aggiungere funzionalità

  • Versionamento: ciascun deployment di una Lambda ha una versione immutabile

    • $LATEST punta sempre all'ultima versione
    • Ciascuna versione ha il proprio ARN
    • Una versione comprende codice e configurazione della Lambda
    • Si possono definire alias, ovvero nomi che puntano a versioni specifiche e che si possono aggiornare nel tempo
      • Ad esempio dev, staging, prod
      • Possono anche puntare anche a due versioni, con pesi diversi

  • Integrazione con CodeDeploy per automatizzare lo switch di alias da una versione ad un'altra

    • Diverse modalità:
      • Linear: switch lineare nel tempo verso la nuova versione
      • Canary: una percentuale alla nuova versione per un determinato intervallo di tempo, poi tutto il traffico
      • AllAtOnce: tutto il traffico alla nuova versione
    • Anche con hook per controllare il corretto funzionamento prima di fare lo switch

  • Il limite per un deployment è 50 MB compresso, 250 MB non compresso con le dipendenze

  • Si possono definire variabili di ambiente cifrate attraverso KMS

    • Nel codice occorre, dopo averle lette, decifrarle tramite Decrypt API

DynamoDB

  • Database NoSQL gestito

    • Replica in tre AZ

  • Table - item - attribute

    • Ciascun item può avere dimensioni fino a 400 KB

  • Primary key definibile in due modi:

    • Solo partition key: hash
      • Deve essere il più sparsa possibile (ad esempio, user id)
    • Partition key + sort key (o range key): si specifica un attributo in più per l'ordinamento all'interno di una partition key
      • La combinazione deve essere unica

  • Di default, letture sono effettuate in modalità eventually consistent

    • Una lettura subito dopo una scrittura può dare risultati non aggiornati
      • Replica non ancora completata
    • Parametro ConsistentRead per effettuare letture strongly consistent

  • Read Capacity Units e Write Capacity Units: valori di throughput in lettura e in scrittura

    • Configurabili per tabella
    • Scalabili automaticamente
    • Si può eccedere e sfruttare burst credit fino a esaurimento, poi eccezione
      • Exponential backoff
    • Una WCU = una scrittura di massimo 1 KB al secondo
      • Sempre multipli di 1 KB
    • Una RCU = una lettura strongly consistent al secondo, oppure due eventually consistent, di massimo 4 KB
      • Sempre multipli di 4 KB
    • WCU e RCU sono ripartite equamente tra le partition

  • API principali

    • PutItem: aggiunge o sostituisce completamente un item
    • UpdateItem: sostituisce parzialmente un item o lo aggiunge alla tabella se non esiste
    • Si possono aggiungere condizioni necessarie che le operazioni di scrittura devono rispettare
    • DeleteItem: elimina un item
    • DeleteTable: elimina una tabella
    • BatchWriteItem: fino a 25 put o delete, fino a 16 MB e fino a 400 KB per item
      • Exponential backoff per i fallimenti
    • GetItem: legge in base alla primary key (anche con range), fino a 100 item (in parallelo) e 16 MB
      • ProjectionExpression se si vogliono solo alcuni attributi
    • Query: legge prendendo in ingresso partition key, eventualmente sort key e una filter expression per prevedere condizioni
      • Fino a 1 MB di dati, anche con paginazione
      • Utilizzabile su table e indici
    • Scan: ritorna (eventualmente filtrando) tutta la tabella
      • Fino a 1 MB di dati, anche con paginazione
      • Molto inefficiente, consuma molte RCU
      • Parallel scan: partizioni diverse sono esaminate assieme
      • Può prendere in ingresso projection expression e filter expression

  • Local Secondary Index (LSI): indice relativo (locale) alla partition key, per filtrare su un suo specifico valore

    • Fino a 5 per tabella
    • Da definire al momento della creazione della tabella

  • Global Secondary Index (GSI): partition key + sort key aggiuntive, utili per query su attributi che non appartengono alla chiave

    • Si ottiene come una tabella aggiuntiva con le chiavi specificate
      • Si può decidere quali attributi proiettarvi
    • Si possono sempre aggiungere e modificare
    • Occorre definire RCU e WCU specifici per l'indice
      • Se l'indice presenta throttling in scrittura, può causare throttling alla tabella principale
        • Non è così per gli LSI, poiché hanno gli stessi valori di capacity della tabella

  • DynamoDB è classificabile come un database con locking ottimistico

    • Conditional update/delete: ci si può assicurare che un dato non sia cambiato tra la lettura e il momento in cui lo si modifica

  • DynamoDB Accelerator (DAX): cache trasparente

    • Risolve il problema delle hot key: chiavi molto interrogate, che causano throttling
    • TTL di 5 minuti di default
    • Si definisce un cluster con fino a 10 nodi e possibilità di Multi AZ e cifratura
    • Evita di dover usare Elasticache, a meno di non voler aggregare o modificare i risultati delle letture

  • DynamoDB Streams: modifiche ad una tabella possono generare dati in stream, leggibili da altri servizi

    • Si può decidere cosa inviare allo stream
      • Solo le chiavi dell'item modificato, oppure tutto l'item (vecchia e/o nuova versione)
    • Shard gestiti automaticamente, diversamente da Kinesis Data Streams
    • Stream non popolati retroattivamente dopo la creazione
    • Con Lambda, occorre creare un Event Source Mapping nella Lambda per leggere dallo stream, oltre ad un ruolo IAM
      • Lambda invocata in maniera sincrona

  • TTL: permette di eliminare item dopo un certo intervallo di tempo

    • Non utilizza RCU/WCU
    • Si basa su una colonna (configurabile) con un timestamp che specifica l'istante di scadenza

  • Opzioni per CLI

    • page-size è per ottimizzare: si richiede comunque tutto il dataset, ma dietro le quinte la CLI utilizza richieste multiple
    • max-items (con starting-token per le pagine successive) è per paginare, si specifica la pagina desiderata e si ottiene solo quella

  • DynamoDB Transactions: modifica di più item in tabelle diverse allo stesso tempo (tutto o niente)

    • Consuma il doppio di RCU/WCU

  • Un caso d'uso comune di DynamoDB è il caching dello stato di sessione di una web application

    • Alternativa a Elasticache, EFS

  • Write sharding (partizionamento delle scritture): se si hanno chiavi con bassa cardinalità è opportuno appendervi un suffisso random per distribuire meglio gli item nelle partizioni

  • Scritture concorrenti possono essere evitate con conditional write o atomic write (specificare di quanto incrementare anziché assegnare un valore)

  • Se occorre persistere item di grandi dimensioni conviene salvare solo i metadati su DynamoDB e mettere il contenuto su S3

  • Se occorre indicizzare file salvati su S3 si può prevedere una Lambda che scrive metadati su DynamoDB quando si inseriscono i file su S3

  • Se occorre copiare una tabella, si può usare DataPipeline, che si appoggia a S3 per fare una copia

API Gateway

  • Permette di definire API REST che sfruttino Lambda

    • Endpoint HTTP / WebSockets
    • Versioning delle API
    • Autenticazione e sicurezza
    • Caching

  • Non solo Lambda, può fare proxy di richieste verso altri servizi AWS o servizi on-premises

  • Tre diversi tipi di deployment per gli endpoint

    • Edge-Optimized: richieste passano per CloudFront Edge locations
      • API Gateway comunque definito a livello di Region
    • Regional: richieste servite dalla Region in cui si trova API Gateway
    • Private: accessibile solo dalla propria VPC tramite VPC Endpoint

  • Deployment sono organizzati in stage

    • Ciascuno stage ha la propria cronologia di versioni
    • Stage ad esempio per ambienti diversi (dev, test, prod), oppure per versioni major diverse
      • Ad esempio, uno stage per ogni diverso Lambda Alias
    • Stage variables: coppie chiave-valore associate ad uno stage, utili per passare valori di configurazione
      • Simulano variabili d'ambiente
      • Indicabili utilizzando :$(stageVariables.variable-name) come suffisso al nome della Lambda configurata per il metodo in esame
      • Occorre essere sicuri che API Gateway abbia opportune policy per accedere tutte le Lambda che si vogliono invocare attraverso variabili diverse
    • Ciascuno stage è configurabile separatamente
      • Caching
      • Method throttling per limitare le richieste effettuabili al secondo
      • Firewall
      • Logging su CloudWatch
      • Stage variables

  • Canary Deployment: definibili in uno stage per redirigere una percentuale del traffico su una Lambda diversa

    • Realizza Blue/Green Deployment in API Gateway e Lambda

  • Tipi di integrazione

    • MOCK: nessun backend, API Gateway risponde con una risposta mock
      • Utile per testing
    • HTTP / AWS: redirezione verso un servizio AWS (anche Lambda) con mapping
      • Mapping templates per configurare richieste e risposte (entrambe modificabili da API Gateway in ingresso e uscita)
        • Possibile rinominare parametri, contenuto del body e degli header
        • Utile anche per integrare API SOAP: mapping template per convertire formati da un protocollo all'altro
    • AWS_PROXY (Lambda Proxy): proxy verso Lambda
      • Inoltro di richiesta e risposta, nessun mapping e nessuna possibilità di modifica per API Gateway
    • HTTP_PROXY: proxy verso un backend HTTP (ad esempio un load balancer)

  • Possibilità di esportare e importare API utilizzando definizioni OpenAPI

  • Caching delle risposte del backend

    • TTL di default 300 secondi
    • Cache definite per stage
    • Costoso
    • Invalidazione da parte di API Gateway o anche lato client, con header Cache-Control
      • Lato client, è opportuno aggiungere una policy o richiedere autorizzazione per permettere l'invalidazione

  • Usage plans per rendere disponibili API a clienti e stabilire le modalità con cui potranno utilizzarle

    • Autorizzazione
    • QoS e rate limiting
    • Usage plans associati a stage di API tramite API keys, da distribuire ai clienti

  • Logging a livello di stage

    • CloudWatch Logs
    • CloudWatch Metrics, con metriche a livello di stage
      • CacheHitCount e CacheMissCount misurano l'efficacia della cache
      • Count conta il numero di richieste
      • IntegrationLatency è il round-trip time tra API Gateway e backend
      • Latency è il round-trip time tra clienti ed API Gateway
    • X-Ray, quadro completo per analizzare le richieste

  • Di default, throttling a livello di account a 10000 richieste al secondo

    • Incrementabile su richiesta

  • Supporto per CORS

    • Se integrazione con proxy, occorre inviare gli header CORS manualmente (ad esempio dalla Lambda di backend)
    • Se integrazione di altro tipo, con possibilità per API Gateway di modificare richiesta e risposta, è possibile utilizzare le impostazioni CORS di API Gateway

  • Autenticazione e autorizzazione

    • Tramite IAM: utenti o ruoli con policy opportune, credenziali passate tramite header nella richiesta
      • Sigv4: si include una firma ricavata dalle proprie credenziali
    • Con resource policy: policy direttamente sulle API
      • Utile per accesso cross-account, oppure per autorizzare VPC Endpoint o indirizzi IP
    • Tramite Cognito Authorizer: autenticazione su Cognito (in uno User Pool), autorizzazione dell'utente connesso su API Gateway tramite la validazione di un token di Cognito
    • Tramite Lambda Authorizer: autenticazione su un sistema terzo, ottenendo un token che API Gateway può verificare tramite l'Authorizer, una Lambda che effettua una richiesta al sistema terzo

  • Tipologia HTTP per servizi molto semplici, senza tutte le opzioni di configurazione disponibili per la tipologia REST

    • Meno costoso
    • Integrazione nativa con OIDC, OAuth2 e CORS

Serverless Application Model (SAM)

  • Framework per definire applicazioni serverless attraverso template YAML

    • Converte tutto in template CloudFormation

  • Template riconoscibili dall'header Transform con valore AWS::Serverless-...

  • Helper per definire risorse

    • AWS::Serverless::Function per Lambda
    • AWS::Serverless::Api per API Gateway
    • AWS::Serverless::SimpleTable per DynamoDB

  • Comando aws cloudformation package per generare il template CloudFormation

    • sam package se si usa SAM CLI
    • Template caricato su un bucket S3

  • Comando aws cloudformation deploy per rilasciare l'applicazione

  • Definizione di policy IAM a partire da Policy Templates già pronti

  • Integrazione con CodeDeploy per rilasciare Lambda Alias

  • Applicazioni SAM possono essere distribuite su Serverless Application Registry (SAR), con possibilità di renderle pubbliche e installarle facilmente su account diversi

    • Configurazione attraverso variabili di ambiente
    • sam publish per pubblicare un'applicazione su SAR (di fatto su S3)

Cloud Development Kit

  • Infrastructure as code con linguaggio a scelta, anziché con CloudFormation

    • JavaScript, TypeScript, Python, Java, ecc.
    • Codice poi trasformato in template CloudFormation

  • Constructs: componenti messi a disposizione per definire risorse

  • Permette di definire infrastruttura e runtime applicativo assieme

  • Diverso da SAM, poiché non incentrato solo su applicazioni serverless

    • Disponibili tutti i servizi AWS

Cognito

  • Autenticazione e accesso federato

    • Login su applicazioni
    • Accesso a credenziali per usare direttamente servizi AWS
    • Sincronizzazione delle sessioni su più dispositivi

  • Cognito User Pools (CUP): directory serverless per gli utenti di un'applicazione, identity provider

    • Fornisce autenticazione con username e password, password reset, verifica della mail, MFA, ecc.
    • Possibilità di login con servizi terzi (federati)
    • JWT ritornato dall'operazione di login
    • Per API Gateway: richiesta del token a CUP, invio del token ad API Gateway, validazione su CUP da parte di quest'ultimo e accesso al backend
    • Per ALB: utilizzo di listener e rules per passare da CUP e in seguito fornire accesso ai target
    • Possibilità di utilizzare una UI hosted customizzabile per il login e la registrazione
    • Trigger per le operazioni di login e registrazione

  • Cognito Identity Pools (Federated Identities): fornisce credenziali temporanee per permettere agli utenti di accedere direttamente a servizi AWS (bucket S3, tabelle DynamoDB)

    • Gli utenti possono provenire ad esempio da provider federati o User Pools
    • Possibile prevedere anche un accesso per ospiti
    • Una volta loggati presso il provider, gli utenti comunicano con Identity Pools, che verifica il loro token, ottiene credenziali temporanee da STS e le fornisce agli utenti stessi, i quali hanno accesso alle risorse
    • Le credenziali temporanee forniscono agli utenti un ruolo IAM
      • Un ruolo di default, modificabile per ospiti e per singolo utente in base all'id

  • Cognito Sync: mantiene sessioni, preferenze, configurazioni relative all'accesso di un utente

    • Permette di sincronizzare i dati su più dispositivi dell'utente
    • Deprecato a favore di AppSync

Step Functions

  • Definizione di workflow come macchine a stati

    • Formato JSON
    • Visualizzazione grafica del flusso
    • Avviato tramite API Gateway, SDK o Event Bridge (ad esempio come CloudWatch Event)
    • Utile per orchestrare l'esecuzione di Lambda

  • Suddivisione in task

    • Due possibilità:
      • Invocazione di un servizio AWS
      • Avvio di un'Activity, un worker che esegue elaborazioni richiedendole alla Step Function e al termine invia i risultati alla stessa
    • Specifica dello stato che segue l'esecuzione del task

  • States

    • Choice State: test di una condizione
    • Fail or Succeed State: arresto con successo o fallimento
    • Pass State: no-op
    • Wait State: aggiunge un delay
    • Map State: iterazione sugli elementi di un array in input
    • Parallel State: fork del branch di esecuzione
      • Ad esempio, computazione necessita di raccogliere risultati da più Lambda e di elaborarli assieme alla fine

  • Occorre gestire i possibili errori che si possono verificare in uno stato

    • Errori di definizione, eccezioni nei task, ecc.
    • Gestione nella macchina a stati, non nel codice applicativo dei singoli task
    • Due possibilità:
      • Retry: ritentare uno stato fallito
        • Si specifica quante volte, con quale intervallo e con quale backoff rate ritentare l'esecuzione
      • Catch: transizione verso uno stato di handling del fallimento
        • Attivato una volta esauriti i tentativi specificati dal Retry
        • Si specificano, tramite match degli errori possibili, in quali stati spostarsi (Next) e quali input aggiungere oltre ai parametri dello stato corrente (ResultPath)
    • Codici di errore predefiniti per fare match dei possibili errori

  • Due tipologie di Step Functions:

    • Standard: per workflow più lunghi (fino a un anno), con un rate di invocazione massimo basso
      • Prezzo variabile in base al numero di transizioni di stato
      • Ispezionabili dalla console, tramite API e CloudWatch Logs
      • Semantica exactly-once
    • Express: per workflow più rapidi (fino a 5 minuti), con un alto rate di invocazione massimo
      • Prezzo variabile in base al numero di invocazioni, alla durata e al consumo di memoria
      • Ispezionabili da CloudWatch Logs
      • Semantica at-least-once

AppSync

  • Servizio managed per definire API GraphQL

    • Utile anche per servizi che sfruttano WebSockets o MQTT su WebSockets
    • Permette di effettuare sincronizzazione di dati su più dispositivi per applicazioni mobile e web

  • Si carica uno schema GraphQL e si definiscono resolver (DynamoDB, RDS, ElasticSearch, Lambda, ecc.) per il recupero dei dati, dopodiché i client possono effettuare query e ottenere risposte in formato JSON

  • Sicurezza e autorizzazione tramite API key, IAM, OpenID Connect provider o Cognito User Pools

SES

  • Servizio per mail

    • SMTP oppure SDK
    • Integrazione con altri servizi

  • Possibilità di utilizzare policy IAM per controllare l'invio di mail

Certificate Manager

  • Gestione di certificati SSL e di CA private

  • Due possibilità per certificati pubblici:

    • Caricare un proprio certificato
    • Demandare provisioning e gestione al servizio, che fornisce certificati gratuiti

  • Per richiedere un certificato pubblico occorre validare il dominio associato aggiungendo un record DNS CNAME come verifica

  • I certificati possono essere utilizzati con ALB (anche con Elastic Beanstalk), CloudFront, API Gateway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment