Introduzione

Questo corso sui principi fondamentali di AWS è progettato per insegnarti i concetti chiave di cui hai bisogno per lavorare in modo efficace all'interno di AWS.

Al primo avvio, AWS può sembrare opprimente. Un paradigma nativo del cloud di costruzione di infrastrutture può essere un radicale allontanamento dal modo tradizionale locale di fare le cose. E indipendentemente dal fatto che questa sia la prima volta che lavori con l'infrastruttura o hai messo a punto i kernel Linux nell'ultimo decennio, può essere difficile sapere da dove iniziare con la selezione AWS di oltre 175 servizi.

Il corso sui principi fondamentali di AWS è progettato per iniziare a utilizzare AWS indipendentemente dalla tua esperienza. In questo corso, descriveremo i cinque principi di AWS, i modelli mentali da utilizzare quando pensi al cloud e i concetti chiave che saranno applicabili a tutti i servizi che finirai per utilizzare.

 

Struttura

Il corso è diviso in cinque moduli. Ogni modulo segue il formato qui riportato:

  • Introduzione: una breve descrizione del principio su cui ci si concentrerà
  • Modello mentale: un modello mentale di guida per aiutarti a comprendere i concetti introdotti in ciascun principio
  • Concetti: i concetti chiave che trattano ampi argomenti di base per ciascun principio
  • Conclusione: il riepilogo di quanto discusso
  • Ulteriori letture: link e risorse aggiuntive
 

I cinque principi

I cinque principi trattati nel corso sui principi fondamentali di AWS provengono direttamente dal canone di architettura AWS. Questo canone è la sintesi di oltre un decennio di esperienza nella creazione di applicazioni scalabili sul cloud.

I cinque principi sono costituiti dalle seguenti aree:

  1. Sicurezza
  2. Efficienza delle prestazioni
  3. Affidabilità
  4. Eccellenza operativa
  5. Ottimizzazione dei costi
 

Sicurezza

Il principio della sicurezza è relativo alla protezione della tua infrastruttura nel cloud. Sicurezza e conformità sono una responsabilità condivisa tra AWS e il cliente. In questo modello di responsabilità condivisa, AWS è responsabile della sicurezza del cloud. Ciò include l'infrastruttura fisica, il software e le funzionalità di rete dei servizi cloud AWS. Anche il cliente è responsabile della sicurezza nel cloud. In questo caso però, la responsabilità include la configurazione di servizi cloud specifici, il software applicativo e la gestione di dati sensibili.

Se i tuoi carichi di lavoro devono soddisfare FedRAMP, DoD SRG, ITAR, CJIS o altri requisiti di conformità rigorosi oppure contengono dati classificati come Controlled Unclassified Information (CUI), consulta la sezione AWS GovCloud (Stati Uniti) del corso.

 

Modello mentale

Quando si pensa alla sicurezza nel cloud, è utile adottare il modello di fiducia zero, ovvero zero trust.

In questo modello, tutti i componenti e servizi dell'applicazione sono considerati entità discrete e potenzialmente dannose. Ciò implica la struttura di rete sottostante, tutti gli agenti che hanno accesso alle tue risorse, nonché il software eseguito all'interno del tuo servizio.

 

Nozioni di base

Quando si pensa alla sicurezza in termini di zero trust, significa che dobbiamo applicare misure di sicurezza a tutti i livelli del nostro sistema. Di seguito sono riportati tre concetti importanti coinvolti nella protezione dei sistemi con zero trust nel cloud:

  1. Identity and Access Management (IAM)
  2. Sicurezza di rete
  3. Crittografia dei dati

 

  • Identity and Access Management (IAM)

    IAM è il servizio responsabile del monitoraggio delle identità e dell'accesso in un sistema. È gestito su AWS tramite il nome servizio IAM. L'accesso è gestito mediante policy IAM che impongono limiti di accesso per gli agenti all'interno di AWS. Esistono tre componenti fondamentali in una policy IAM:

    • le ENTITÀ specificano a CHI sono assegnate le autorizzazioni
    • le AZIONI specificano COSA viene eseguito
    • le RISORSE specificano a QUALI proprietà si accede

    Applicare il modello di zero trust a IAM significa adottare il principio del privilegio minimo. Ciò significa che ogni agente dovrebbe avere solo le autorizzazioni minime necessarie per svolgere la propria funzione.

    Una policy IAM può essere applicata a una entità o a una risorsa AWS. Le policy che sono associate a una entità sono note come policy basate su identità. Le policy associate a una risorsa sono note come policy basate su risorse. Solo alcuni servizi (ad esempio, S3, KMS, SES) hanno policy basate sulle risorse.

    Il fatto che un'entità disponga dell'autorizzazione per eseguire un'azione per una determinata risorsa dipende dal fatto che la policy basata sull'identità dell'entità consenta loro di farlo e che la policy basata sulle risorse della risorsa (se esiste) non gli proibisca di farlo.

    Questa è un'importante semplificazione del modello di autorizzazione IAM. Esistono molti tipi di policy aggiuntive che influiscono sulla possibilità di concedere l'accesso. Tra queste vi sono limiti di autorizzazione, policy di controllo dei servizi dell’organizzazione, liste di controllo accessi (ACL) e policy di sessione. Questi altri tipi di policy vanno oltre lo scopo di questo corso. Per maggiori dettagli, consulta la sezione Ulteriori letture di questo modulo.

    Punti da tenere a mente

    • Le policy IAM dichiarano i limiti di accesso per le entità all'interno di AWS
    • Le policy IAM sono costituite da ENTITÀ, AZIONI e RISORSE
    • Le policy IAM possono essere utilizzate per applicare il principio del privilegio minimo
    • IAM ha numerosi tipi di policy, tra cui quelle basate su identità e quelle basate su risorse
    • IAM valuta l'accesso in base alla valutazione di tutti i tipi di policy applicabili per una determinata risorsa
     

    Ulteriori letture

  • Sicurezza di rete

    La sicurezza di rete comprende qualsiasi sistema, configurazione o processo che salvaguardi l'accesso e l'usabilità della rete e delle risorse accessibili alla rete. AWS offre un'ampia gamma di funzionalità per proteggere la tua rete, sia a livello di rete che a livello di risorse.

    Un approccio zero trust alla sicurezza di rete implica un approccio di difesa approfondito che applica i controlli di sicurezza a tutti i livelli della rete (al contrario del livello più esterno).

    Sicurezza a livello di rete

    Il tipo primitivo fondamentale a livello di rete in AWS è Amazon Virtual Private Cloud (VPC). Questa è una rete logica che può essere definita e in cui si può effettuare il provisioning delle risorse.

    Di seguito sono riportati alcuni componenti che costituiscono il VPC:

    • Sottoreti: un intervallo di indirizzi IP all’interno del VPC
    • Tabelle di routing: una serie di regole che determinano dove è diretto il traffico
    • Gateway Internet: un componente che consente la comunicazione tra le risorse all’interno del VPC e su Internet

    Per proteggere il traffico nel tuo VPC, puoi dividere le tue risorse in risorse pubbliche e risorse interne. Per ridurre la superficie di attacco, puoi utilizzare un servizio proxy come Application Load Balancer (ALB) in modo da gestire tutto il traffico rivolto a Internet. Tutti i servizi interni come server e database possono quindi essere forniti all'interno di sottoreti interne che sono escluse dall'accesso pubblico a Internet.

    Oltre ai VPC, per limitare ulteriormente il traffico nella tua rete puoi utilizzare anche AWS Web Application Firewall (WAF).

    Sicurezza a livello di risorsa

    Le singole risorse AWS dispongono inoltre di controlli di sicurezza della rete che possono essere configurati. Il controllo più comune è noto come gruppo di sicurezza. I gruppi di sicurezza sono firewall virtuali che possono essere utilizzati per imporre il flusso di traffico in entrata e in uscita dalla risorsa. Utilizza i gruppi di sicurezza per consentire solo il traffico proveniente da porte specifiche e fonti attendibili verso la tua istanza. È possibile collegare gruppi di sicurezza a risorse come istanze EC2, istanze RDS e Lambda.

    Punti da tenere a mente

    • La sicurezza di rete comprende meccanismi progettati per salvaguardare l'accesso e l'usabilità della rete e delle risorse accessibili alla rete
    • Un approccio zero trust alla sicurezza di rete prevede l'implementazione della difesa in profondità a tutti i livelli della rete
    • I VPC e i WAF consentono di applicare le misure di sicurezza a livello di rete
    • I gruppi di sicurezza consentono di applicare le misure di sicurezza a livello di risorsa

    Ulteriori letture

  • Crittografia dei dati

    La crittografia dei dati è il processo di codifica delle informazioni in modo che non sia comprensibile per qualsiasi terza parte che non possiede la chiave necessaria per decifrare i dati.

    Adottare un modello zero trust per i dati significa crittografare i dati ovunque, sia i dati in transito che i dati inattivi.

    Crittografia in transito

    La crittografia in transito comporta la crittografia dei dati mentre questi si spostano tra i sistemi. Tutti i servizi di archiviazione e database all'interno di AWS forniscono endpoint HTTPS che supportano la crittografia dei dati in transito. AWS offre anche servizi di rete che possono aiutare a imporre la crittografia in transito per i propri servizi. Ad esempio, per imporre una connessione su HTTPS ai tuoi endpoint puoi utilizzare Application Load Balancer (ALB).

    Crittografia dei dati inattivi

    La crittografia dei dati inattivi implica la crittografia di tutti i dati all’interno dei sistemi. Tutti i servizi di archiviazione e di database AWS supportano la crittografia dei dati inattivi. La maggior parte di questi servizi ha la crittografia attivata per impostazione predefinita. Non vi è alcun costo aggiuntivo per la crittografia e il sovraccarico di prestazioni trascurabili per la crittografia dei dati.

    La maggior parte dei servizi di archiviazione e di database si integra anche direttamente con Amazon Key Management Service (KMS). Questo è un servizio di gestione delle chiavi centrale che ti dà la possibilità di creare Customer Managed Keys (CMK) per crittografare i tuoi dati.

    L’uso di un CMK fornisce un’ulteriore funzionalità oltre la crittografia. Hai infatti la possibilità di utilizzare il tuo archivio chiavi personalizzato, di creare una traccia di controllo per la risorsa crittografata tramite le integrazioni con AWS CloudTrail e di applicare la rotazione automatica delle chiavi.

    Punti da tenere a mente

    • La crittografia è il processo di codifica delle informazioni in modo tale che solo le parti che dispongono della chiave corretta possano decifrare le informazioni
    • I dati vengono protetti mediante la crittografia in transito e su dati inattivi
    • Tutti i servizi di archiviazione e di database su AWS forniscono la crittografia su dati inattivi e in transito
    • Puoi utilizzare i servizi di rete AWS (come ALB) per imporre la crittografia in transito per tutti i tuoi servizi
    • Puoi utilizzare un CMK per sbloccare la funzionalità avanzata di creazione di audit trail, utilizzando le tue chiavi personalizzate, e la rotazione automatica delle chiavi

    Ulteriori letture

    Caratteristiche

     

    Servizi

     

    Riferimenti

     

     

Conclusioni

In questo modulo, hai appreso informazioni sul principio di sicurezza di AWS. Hai ottenuto informazioni sul modello mentale zero trust. Hai imparato cose sullo IAM e il principio del privilegio minimo. Hai appreso in dettaglio la sicurezza della rete AWS e il principio della difesa. Hai imparato a conoscere la crittografia dei dati e applicarla sia in transito che su dati inattivi.

 

Ulteriori letture

Efficienza delle prestazioni

Il principio dell'efficienza delle prestazioni si concentra su come è possibile eseguire i servizi in modo efficiente e scalabile nel cloud. Mentre il cloud ti dà i mezzi per gestire qualsiasi quantità di traffico, richiede che tu scelga e configuri i tuoi servizi tenendo presente la scala.

 

Modello mentale

Quando si pensa all'efficienza delle prestazioni nel cloud, è utile considerare i propri servizi come bestiame, non animali domestici.

Nel modello locale di fare le cose, i server erano costosi e spesso distribuiti e configurati manualmente. Prima che un server venga effettivamente distribuito e collegato fisicamente al data center potrebbero passare settimane. Per questo motivo, i server sono stati trattati come animali domestici: ognuno era unico e richiedeva molta manutenzione. Alcuni di loro avevano perfino un nome.

Il cloud invece pensa ai server come capi di bestiame. I server sono risorse di largo consumo che possono essere fornite automaticamente in pochi secondi. Nessun singolo server deve essere essenziale per il funzionamento del servizio.

 

Nozioni di base

Pensare ai server come capi di bestiame ci consente di avere numerosi vantaggi legati alle prestazioni. Nel modello di “animale domestico” per la gestione dei server, è abbastanza comune usare lo stesso tipo di server (o anche lo stesso server) per più carichi di lavoro; era troppo seccante ordinare e eseguire il provisioning di macchine diverse. Nel "modello bestiame", il provisioning è un processo più rapido ed economico e ci da la libertà di selezionare il tipo di server che più si avvicina al nostro carico di lavoro.

Questo modello inoltre facilita il ridimensionamento del servizio. Poiché ogni server è intercambiabile e rapido da implementare, possiamo rapidamente ridimensionare la nostra capacità aggiungendo più server.

Ci concentreremo pertanto sui seguenti due concetti per ottenere un'efficienza delle prestazioni:

  1. Selezione
  2. Dimensionamento
 
  • Selezione

    La selezione in AWS è la possibilità di scegliere il servizio che si allinea di più al tuo carico di lavoro. AWS ha la più ampia selezione di servizi, con oltre 175 servizi distribuiti in oltre due dozzine di categorie. Raggiungere le prestazioni attraverso la selezione significa essere in grado di scegliere lo strumento giusto per il lavoro.

    Il carico di lavoro tipico richiede in genere la selezione di un determinato numero delle quattro principali categorie di servizi in AWS: elaborazione, archiviazione, database e rete.

    • L’elaborazione ha a che fare con il servizio che elaborerà i tuoi dati (ad esempio, la macchina virtuale)
    • L’archiviazione ha a che fare con lo storage statico dei dati (ad esempio, lo storage di oggetti)
    • I database sono relativi allo storage organizzato dei dati (ad esempio, database relazionale)
    • La rete ha a che fare con il modo in cui i dati vengono trasferiti (ad esempio, rete di distribuzione dei contenuti)

    In questo modulo, esamineremo la scelta giusta nelle prime tre categorie. Fai riferimento alla sezione Ulteriori letture per informazioni su come scegliere tra le diverse opzioni di rete.

    Indipendentemente dalla categoria di servizio scelta, ci sono tre cose che vanno considerate.

    1. Tipo di servizio
    2. Grado di gestione
    3. Configurazione

    Tipo di servizio

    Quando effettui una selezione in una categoria, AWS offre numerose opzioni per il tipo di servizio che si può utilizzare. Il tipo è unico per ciascuna categoria.

    Quando si seleziona un servizio di elaborazione, puoi scegliere tra un’elaborazione basata su macchina virtuale, su contenitore o su un sistema serverless.

    • L’elaborazione basata su macchina virtuale ha il modello mentale più familiare per la maggior parte delle persone, ma può essere più costoso e richiedere una maggiore manutenzione
    • L’elaborazione basata su contenitore consente una divisione più fine del carico di lavoro e può essere ridimensionata rapidamente, ma presenta una complessità aggiuntiva di configurazione e orchestrazione
    • L’elaborazione basata su un sistema serverless elimina la maggior parte delle complessità di gestione e ridimensionamento, ma presenta forti limitazioni di sistema e richiede l'adozione di nuove toolchain e processi

    Quando si seleziona un servizio di archiviazione, puoi decidere se è necessario un archivio di file, uno storage a blocchi, uno storage di oggetti o uno storage con archiviazione.

    • I servizi di storage a blocchi come EBS sono ottimali per la conservazione di dati da una singola istanza EC2
    • I sistemi di file come EFS sono adatti per fornire a più clienti l’accesso agli stessi dati
    • Gli storage di oggetti come S3 sono perfetti per grandi quantità di dati a cui deve accedere un numero qualsiasi di clienti
    • Lo storage con archiviazione come S3 Glacier è perfetto per grosse quantità di dati a cui non si accede con una grande frequenza

    Quando si seleziona un servizio di database, puoi decidere se hai bisogno di un database relazionale, un database non relazionale, una soluzione di data warehouse o una soluzione di indicizzazione e ricerca di dati.

    • I database relazionali ti consentono di avere join e proprietà ACID ma hanno un limite superiore sulle prestazioni e lo storage di dati
    • I database non relazionali hanno schemi più flessibili e possono scalare a limiti molto più alti rispetto alle loro controparti relazionali ma generalmente mancano di join e funzionalità ACID complete
    • Le soluzioni di data warehouse consentono un’analisi su larga scala attraverso l'accesso rapido a petabyte di dati strutturati
    • Le soluzioni di indicizzazione e ricerca dei dati ti consentono di indicizzare e cercare i dati da un'ampia varietà di fonti
     

    Grado di gestione

    Una volta deciso un tipo di servizio, è necessario restringere ulteriormente a un servizio specifico: AWS a volte offre più offerte per tipi di servizio specifici. La differenza principale tra vari servizi AWS dello stesso tipo si trova nel loro grado di gestione.

    Quando si utilizzano servizi di elaborazione e si decide il tipo di macchina virtuale, puoi scegliere tra EC2, Lightsail e Elastic Beanstalk. L'utilizzo diretto di EC2 ti dà il massimo controllo ma ha la gestione minima, mentre la scelta di Lightsail consente di effettuare delle personalizzazioni in modo da avere un'esperienza più gestita. Elastic Beanstalk si trova da qualche parte nel mezzo: offre un framework convenzionale per la tua architettura di servizio ma ti consente di personalizzare attraverso la configurazione.

    Quando si utilizzano i servizi di archiviazione, la selezione di un servizio è più semplice in quanto tende a esserci un solo servizio per un determinato tipo (ad esempio, S3 per lo storage di oggetti, EFS per un archivio file).

    Se si utilizzano i servizi di database e si sceglie il tipo relazionale, potrai scegliere tra RDS e Aurora. RDS offre un maggiore controllo sul database sottostante ed è disponibile per la maggior parte dei database relazionali. Aurora funziona solo con alcune versioni di MySQL e PostgreSQL ma si occupa della gestione dello storage sottostante e ha il supporto integrato per il clustering.

    Alla fine della giornata, la scelta di un servizio specifico dipende in gran parte dalla tua familiarità con la tecnologia disponibile e dalle tue preferenze per un'esperienza più o meno gestita.

     

    Configurazione

    Una volta deciso il servizio da utilizzare, dovrai decidere se configurarlo o meno. La configurazione dipende dalle caratteristiche prestazionali specifiche che si desidera ottenere, che differiscono per ciascuna categoria di servizio.

    Quando si valutano le caratteristiche prestazionali per i servizi di elaborazione, un buon punto di partenza è la memoria e i requisiti di calcolo:

    • Se si utilizza l’elaborazione basata su macchina virtuale, la memoria e la CPU sono influenzate dalle dimensioni dell'istanza (ad esempio, t3.small rispetto a t3.xlarge) e dalla famiglia dell’istanza (ad esempio, r3.small rispetto a c5.small)
    • Se si utilizza l’elaborazione basata su contenitore, la memoria e la CPU possono essere impostate individualmente
    • Se si utilizza l’elaborazione basata su un sistema serverless, solo la memoria può essere impostata direttamente - il valore di calcolo (così come altre risorse di sistema) aumenta linearmente alla quantità di memoria disponibile

    Tieni presente che, a seconda del carico di lavoro, esistono ulteriori vincoli di risorse che potrebbero essere importanti, come la capacità di rete e la disponibilità di determinate risorse come lo storage dell’istanza.

    Quando si valutano le caratteristiche prestazionali per i servizi di archiviazione, considerare i requisiti di latenza, throughput e IOPS:

    • Se si utilizza un servizio di storage a blocchi:
      • La latenza dipende dalla selezione del tipo di volume (ad esempio, solid-state drive, hard disk, ecc.)
      • Il throughput è proporzionale alla dimensione del volume per la maggior parte dei tipi di volumi
      • La capacità IOPS è proporzionale alla dimensione del volume per la maggior parte dei tipi di volumi
    • Se si utilizza un servizio di file system:
      • La latenza e IOPS dipendono dalla tua scelta della modalità di prestazione
      • Il throughput dipende dalla tua scelta di utilizzare o meno il throughput assegnato
    • Se si utilizza uno storage di oggetti:
      • La latenza dipende dalla distanza geografica dell’endpoint del bucket
      • Il throughput dipende dall’uso delle API ottimizzate del throughput, come il caricamento a più parti
      • IOPS non è configurabile
    • Se si utilizza uno storage con archiviazione:
      • La latenza dipende dalla distanza geografica dell’endpoint del bucket e dalla scelta del metodo di recupero
      • Il throughput dipende dall’uso delle API ottimizzate del throughput, come il caricamento a più parti
      • IOPS non è configurabile

    Nel valutare le caratteristiche prestazionali per i servizi di database, bisogna considerare i requisiti di utilizzo (ad esempio, CPU, memoria, archiviazione, ecc):

    • Se si utilizza un database relazionale:
      • Le capacità delle risorse sono determinate dalla tua scelta dell'istanza EC2
    • Se si utilizza un database non relazionale, come DynamoDB:
      • Le capacità delle risorse sono determinati dalle opzioni di configurazione come la capacità assegnata
    • Se si utilizza una soluzione di data warehouse come Redshift:
      • Le capacità delle risorse sono determinate dalla tua scelta dell'istanza EC2 sottostante
    • Se si utilizza una soluzione di indicizzazione come Elasticsearch Service:
      • Le capacità delle risorse sono determinate dalla tua scelta dell'istanza EC2

     

    Punti da tenere a mente

    • AWS dispone di numerosi servizi e molti modi per ottenere un risultato
    • L’implementazione di un carico di lavoro in AWS implica la selezione dei servizi nelle categorie di elaborazione, storage, database e rete
    • All’interno di ciascuna categoria, viene selezionato il tipo di servizio più adatto in base al tuo caso d’uso
    • All'interno di ciascun tipo, è possibile selezionare il servizio specifico in base al grado di gestione desiderato
    • All'interno di ciascun servizio, è possibile selezionare la configurazione specifica in base alle caratteristiche prestazionali specifiche che si desidera ottenere
     

    Ulteriori letture

  • Dimensionamento

    Mentre la scelta del servizio giusto è la chiave per iniziare, scegliere come dimensionare è importante per le prestazioni continue.

    AWS ha due modi per eseguire il dimensionamento:

    1. Dimensionamento verticale
    2. Dimensionamento orizzontale


    Dimensionamento verticale

    Il dimensionamento verticale implica l'aggiornamento del calcolo sottostante verso un tipo di istanza più grande. Ad esempio, supponiamo di eseguire un’istanza t3.small. Il dimensionamento verticale di questa istanza consiste nell’aggiornarla a una istanza t3.large.

    Il dimensionamento verticale è in genere più semplice da implementare in quanto è possibile farlo senza dover raggruppare il servizio. Lo svantaggio è che si incontra un limite superiore molto più basso (uguale alla dimensione massima dell'istanza di elaborazione) rispetto al ridimensionamento orizzontale. Rappresenta inoltre un singolo punto di errore poiché l'interruzione dell'istanza può rendere il servizio completamente non disponibile.

     

    Dimensionamento orizzontale

    Il dimensionamento orizzontale implica l’aumento del numero di istanze sottostanti. Ad esempio, supponiamo di eseguire un’istanza t3.small. Il dimensionamento orizzontale di questa istanza implica il provisioning di altre due istanze t3.small.

    Questo tipo di dimensionamento comporta un maggior sovraccarico dal punto di vista dell'implementazione. Questo perché è necessario un servizio proxy per instradare il traffico al tuo gruppo di servizi. È inoltre necessario eseguire controlli di integrità per rimuovere le istanze errate dal pool di routing, nonché scegliere un algoritmo di routing specifico ottimale per il tuo carico di lavoro. Per contro, si finisce con un servizio che è molto più resistente e può scalare a limiti molto più alti rispetto alla loro controparte in scala verticale.


    Punti da tenere a mente

    • Il dimensionamento verticale è più semplice dal punto di vista operativo ma rappresenta un rischio di disponibilità e presenta limiti inferiori
    • Il dimensionamento orizzontale richiede un maggiore sovraccarico, ma offre una migliore affidabilità e limiti molto più elevati
     

    Ulteriori letture

Conclusioni

In questo modulo, hai appreso informazioni sul principio di efficienza delle prestazioni di AWS. Hai imparato a considerare i tuoi server come bestiame e non come animali domestici. Hai appreso come scegliere il servizio più adatto e la relativa configurazione in base ai tuoi obiettivi prestazionali. Hai imparato a conoscere i servizi di dimensionamento e i compromessi tra dimensionamento verticale e dimensionamento orizzontale.

 

Ulteriori letture

Affidabilità

Il principio dell'affidabilità si concentra su come è possibile creare servizi resistenti alle interruzioni dei servizi e dell'infrastruttura. Proprio come con l'efficienza delle prestazioni, mentre il cloud ti offre i mezzi per creare servizi resilienti in grado di resistere alle interruzioni, richiede di progettare i tuoi servizi tenendo conto dell'affidabilità.


Modello mentale

Quando si parla di affidabilità nel cloud, risulta utile ragionare in termini di raggio d’azione. Il raggio d’azione può essere considerato come il massimo impatto che potrebbe essere sostenuto in caso di guasto del sistema. Per costruire dei sistemi affidabili, è necessario ridurre al minimo il raggio d’azione di ogni singolo componente.

 

Nozioni di base

Quando si ragiona in termini di raggio d’azione, il problema guasto non è più una questione di se ma una questione di quando. Per gestire i guasti che si verificano e limitare il raggio d’azione, è possibile utilizzare le seguenti tecniche:

  1. Isolamento del guasto
  2. Limiti


  • Isolamento del guasto

    L'isolamento del guasto limita il raggio d’azione di un incidente utilizzando componenti indipendenti ridondanti separati attraverso le zone di isolamento del guasto. Tali zone contengono l'impatto di eventuali guasti nell'area all'interno della zona.

    AWS dispone di zone di isolamento del guasto a tre livelli:

    1. Risorsa e richiesta
    2. Zona di disponibilità
    3. Regione

     

    Risorsa e richiesta

    I servizi AWS partizionano tutte le risorse e le richieste su una data dimensione come l'ID risorsa. Tali partizioni sono dette celle. Queste sono progettate per essere indipendenti e contenere errori all'interno di una singola cella. Nella pratica, AWS utilizza tecniche come lo shuffle sharding per limitare il raggio d’azione. Tutto ciò avviene in modo trasparente ogni volta che effettui una richiesta o crei una risorsa e non è richiesta alcuna azione aggiuntiva.


    Zona di disponibilità

    Una zona di disponibilità AWS è una struttura completamente indipendente con funzionalità di alimentazione, servizio e rete dedicate. Ogni zona è geograficamente distante dalle altre in modo da evitare guasti correlati da pericoli ambientali come incendi e inondazioni.

    L'isolamento del guasto si ottiene a livello di zona di disponibilità distribuendo istanze ridondanti del servizio attraverso più zone. In questo modo un evento di potenza in una zona non influirà sul traffico in un'altra zona.

    Per quel che riguarda la latenza, nonostante siano geograficamente separate, le zone di disponibilità sono abbastanza vicine l'una all'altra tanto che la latenza di rete tra loro è minima. Ciò consente a determinate funzionalità come la replica di dati sincrona di funzionare tra diverse zone di disponibilità.


    Regione

    Una regione AWS offre il massimo isolamento. Ogni regione è un data center completamente autonomo, composto da due o più zone di disponibilità. L'isolamento del guasto si ottiene a livello di area geografica distribuendo copie ridondanti dei servizi in diverse regioni AWS (questo è esattamente ciò che AWS fa con i propri servizi).

    Se hai necessità di livelli di disponibilità molto alti, puoi considerare la possibilità di una distribuzione in più regioni. La gestione di un servizio su più regioni ha un sovraccarico notevole a causa dell'assenza di infrastrutture condivise tra le regioni. Esistono servizi e funzionalità che possono aiutarti con le creazioni multi-regione. Ad esempio, puoi utilizzare Route53, un servizio DNS scalabile di AWS, per instradare il traffico tra regioni differenti. Puoi utilizzare anche funzionalità come DynamoDB Global Tables e S3 Cross-Region Replication per replicare i tuoi dati tra le varie regioni.


    Punti da tenere a mente

    • Utilizza le zone di isolamento del guasto per limitare il raggio d’azione delle interruzioni dei servizi o dell’infrastruttura
    • L'isolamento del guasto a livello di risorse e richieste è integrato nella progettazione di ogni servizio AWS e pertanto non sono richieste ulteriori azioni da parte dell’utente
    • L’isolamento del guasto a livello di zona di disponibilità si ottiene distribuendo i servizi su più zone; ciò è possibile con un impatto minimo sulla latenza
    • L'isolamento del guasto a livello di regione si ottiene distribuendo i servizi in più regioni; ciò richiede un notevole sovraccarico operativo


    Ulteriori letture

  • Limiti

    I limiti sono vincoli che possono essere applicati per proteggere i tuoi servizi da un carico eccessivo. Questi rappresentano un un mezzo efficace per limitare il raggio d’azione da incidenti sia esterni (ad esempio attacco DDoS) che interni (ad esempio, configurazione errata del software).

    I servizi AWS hanno limiti specifici dei servizi stessi in base all'account per regione. Questi limiti sono noti anche come quote di servizio. Questi sono i valori massimi per determinate risorse, azioni ed elementi nel tuo account AWS.

    Esistono due tipi di limiti:

    • i limiti inferiori, che possono essere aumentati richiedendo un aumento da AWS
    • i limiti superiori, che non possono essere aumentati

    Ciascun servizio ha limiti differenti. Per monitorare i tuoi limiti e richiedere degli aumenti, puoi utilizzare il servizio Service Quotas.

    È importante monitorare i limiti di un servizio e sapere quando ci si avvicina ai propri per evitare interruzioni del servizio. Per alcune risorse, come esecuzioni simultanee di Lambda, è possibile monitorare tramite CloudWatch. Altre risorse, come ad esempio il numero di istanze EC2, devono essere monitorate manualmente o tramite degli script. Puoi utilizzare il servizio AWS Trusted Advisor per monitorare i tuoi limiti se hai un piano Business Support o Enterprise Support. Anche gli strumenti open source come awslimitchecker possono essere utilizzati per automatizzare il processo.


    Punti da tenere a mente

    • I limiti sono vincoli che possono essere applicati per proteggere un servizio da un carico eccessivo
    • I limiti dei servizi AWS possono essere monitorati e gestiti tramite il servizio Service Quota
    • Esistono dei limiti inferiori che possono essere aumentati e limiti superiori che non possono essere aumentati
    • Dovrai monitorare i limiti per i servizi in uso e pianificare gli aumenti dei limiti di conseguenza per evitare interruzioni dei servizi


    Ulteriori letture

Conclusioni

In questo modulo, hai appreso informazioni sul principio di affidabilità di AWS. Hai iniziato a utilizzare il modello mentale di pensare in termini di raggio d’azione. Hai imparato a utilizzare le zone di isolamento del guasto per limitare il raggio d’azione Hai appreso informazioni sui limiti dei servizi e come aumentare i tuoi limiti per evitare una interruzione.

 

Ulteriori letture

Eccellenza operativa

Il principio dell'eccellenza operativa si concentra su come migliorare continuamente la capacità di eseguire sistemi, creare procedure più adatte e ottenere approfondimenti.


Modello mentale

Quando si pensa all'eccellenza operativa nel cloud, è utile pensarci in termini di automazione.

L'errore umano è la causa principale di difetti e incidenti operativi. Più operazioni possono essere automatizzate, minori sono le possibilità di errore umano.

Oltre a prevenire errori, l'automazione ti aiuta a migliorare continuamente i tuoi processi interni. L’automazione promuove inoltre una serie di best practice riproducibili che possono essere applicate all'intera organizzazione.


Nozioni di base

Quando si pensa a operazioni come l'automazione, si pensa a concentrare i propri sforzi nelle aree che richiedono il maggior lavoro manuale e potrebbero avere più conseguenze per un eventuale errore. È preferibile inoltre di disporre di un processo per monitorare, analizzare e migliorare gli sforzi operativi.

Ci concentreremo pertanto sui seguenti due concetti per ottenere un'eccellenza operativa:

  1. Infrastruttura come codice
  2. Osservabilità


  • Infrastruttura come codice

    Infrastruttura come codice (IaC) è il processo di gestione della propria infrastruttura tramite file di configurazione leggibili a macchina. IaC è la base che consente l'automazione della tua infrastruttura.

    Invece di eseguire il provisioning manuale dei servizi, crei modelli che descrivono le risorse desiderate. La piattaforma IaC si occupa quindi del provisioning e della configurazione delle risorse per tuo conto.

    IaC offre un modo dichiarativo e automatizzato di provisioning dell'infrastruttura. Consente infatti di applicare gli stessi strumenti (ad esempio, Git) e i processi (ad esempio, la revisione del codice) alla tua infrastruttura come già fai per il tuo codice.

    IaC è stato tradizionalmente implementato in AWS tramite il servizio CloudFormation. CloudFormation richiede la dichiarazione delle risorse tramite JSON o YAML. Se non sei pratico di questi linguaggi di configurazione, AWS fornisce anche Cloud Development Kit (CDK) che consente di creare modelli CloudFormation utilizzando linguaggi di programmazione nativi come JavaScript, Python e Java.

     

    Punti da tenere a mente

    • IaC è il processo di gestione dell’infrastruttura tramite file di configurazione leggibili a macchina
    • IaC offre un modo dichiarativo e automatizzato di provisioning dell'infrastruttura
    • È possibile applicare gli stessi strumenti e processi alla propria infrastruttura come al proprio codice
    • Per implementare IaC in AWS puoi utilizzare servizi come CloudFormation e CDK
     

    Ulteriori letture

  • Osservabilità

    L'osservabilità è il processo di misurazione dello stato interno del sistema. Questo di solito viene fatto per ottimizzare il sistema fino allo stato finale desiderato.

    Quando si parla di eccellenza operativa, non è possibile migliorare ciò che non si misura. Costruire una solida base di osservabilità ti dà la possibilità di monitorare l'impatto del processo di automazione e migliorarlo continuamente.

    L’implementazione dell’osservabilità prevede le seguenti fasi:

    1. Raccolta
    2. Analisi
    3. Azione


    Raccolta

    La raccolta è il processo di aggregazione di tutte le metriche necessarie per la valutazione dello stato del sistema.

    Tali metriche possono rientrare nelle seguenti categorie:

    • Metriche a livello di infrastruttura
      • Queste metriche sono emesse automaticamente dai servizi AWS e sono raccolte dal servizio CloudWatch
      • Alcuni servizi emettono anche registri strutturati che possono essere abilitati e raccolti tramite CloudWatch Logs
    • Metriche a livello di applicazione
      • Queste metriche sono generate dal software e possono essere raccolte da CloudWatch Custom Metrics
      • I log del software possono essere memorizzati tramite CloudWatch Logs oppure possono essere caricati in S3
    • Metriche a livello di account
      • Queste metriche sono registrate dal tuo account AWS e possono essere raccolte dal servizio CloudTrail


    Analisi

    Per analizzare le metriche raccolte, puoi utilizzare una delle numerose soluzioni di analisi e database fornite da AWS.

    La scelta della soluzione più adatta dipende dal tuo caso d’uso:

    • Per analizzare i log archiviati in CloudWatch Logs, puoi utilizzare CloudWatch Logs Insight, un servizio che ti consente di ricercare e analizzare in maniera interattiva i dati dei log Cloudwatch
    • Per analizzare i log archiviati in S3, puoi utilizzare Athena, un servizio di query serverless
    • Per analizzare i dati della struttura, puoi utilizzare RDS, un servizio di database relazionali gestiti
    • Per analizzare grosse quantità di dati strutturati, puoi utilizzare RedShift, un servizio gestito di data warehouse con una capacità di più petabyte
    • Per analizzare i dati basati sui log, puoi utilizzare Elasticsearch Service, una versione gestita di Elasticsearch, il più famoso motore di analisi open-source

     

    Azione

    Dopo aver raccolto e analizzato le metriche, potrai utilizzarle per ottenere un determinato risultato o processo.

    Di seguito sono riportati degli esempi di risultati e processi:

    • Monitoraggio e allarmi
      • Per avvisare l'utente quando un sistema ha violato la soglia di sicurezza per una determinata metrica, puoi utilizzare CloudWatch Alarms
      • Questo allarme può attivare una mitigazione manuale o automatica.
    • Pannelli di controllo
      • Puoi creare i pannelli di controllo relativi alle tue metriche utilizzando Cloudwatch Dashboards
      • Tali pannelli di controllo possono essere utilizzati per monitorare e migliorare le prestazioni dei servizi nel tempo
    • Decisioni basate sui dati
      • Puoi monitorare le prestazioni e gli indicatori KPI aziendali per prendere decisioni basate sui dati

     

    Punti da tenere a mente

    • L'osservabilità è il processo di misurazione dello stato interno del sistema per raggiungere uno stato finale desiderato
    • L’osservabilità consiste nel raccogliere, analizzare e effettuare operazioni sulle metriche
    • Puoi raccogliere le metriche a livello di servizio, applicazione e account
    • Puoi analizzare le metriche tramite servizi come CloudWatch Log Insight, Athena, Elasticsearch Service, RDS e Redshift
    • Puoi agire sulle metriche creando monitoraggi, allarmi e pannelli di controllo e tenendo traccia delle prestazioni e degli KPI aziendali

     

    Ulteriori letture

Conclusioni

In questo modulo, hai appreso informazioni sul principio di eccellenza operativa. Hai iniziato a utilizzare il modello mentale di pensare alle operazioni in termini di automazione. Hai imparato a conoscere IaC e come può essere utilizzato per eseguire il provisioning automatico dei tuoi servizi utilizzando gli stessi strumenti e processi che attualmente usi per il codice. Hai capito cos’è l’osservabilità e come raccogliere, analizzare e utilizzare le metriche per migliorare continuamente gli sforzi operativi.

 

Ulteriori letture

Ottimizzazione dei costi

Il principio dell'ottimizzazione dei costi ti aiuta a raggiungere i risultati aziendali riducendo al minimo i costi.


Modello mentale

Quando si pensa all'ottimizzazione dei costi nel cloud, è utile pensare alla spesa del cloud in termini di OpEx piuttosto che di CapEx. OpEx è un modello a consumo in corso mentre CapEx è un modello di acquisto.

I costi IT tradizionali nei data center locali sono stati principalmente CapEx ovvero paghi anticipatamente tutta la tua capacità, indipendentemente dal fatto che finisca per utilizzarla. L'acquisto di nuovi server in questo caso poteva essere un processo lungo che comportava l'approvazione di più parti. Questo perché i costi di CapEx erano spesso significativi e gli errori erano costosi. Dopo aver effettuato un acquisto, i server effettivi potevano impiegare ancora settimane per arrivare.

In AWS, i costi sono OpEx ovvero paghi su base continuativa per la capacità che realmente usi. Il provisioning di nuovi server può essere eseguito in tempo reale dal reparto di progettazione senza la necessità di un lungo processo di approvazione. Questo perché i costi OpEx sono molto inferiori e possono essere invertiti se i requisiti cambiano. Poiché paghi solo ciò che utilizzi, qualsiasi capacità in eccesso può essere semplicemente interrotta e terminata. Se decidi di utilizzare un servizio, potrai eseguire il provisioning in pochi minuti o addirittura secondi.


Nozioni di base

Passare da un modello CapEx a un modello OpEx cambia radicalmente il tuo approccio ai costi della tua infrastruttura. Invece di grandi costi fissi anticipati, si pensa a piccole spese variabili in corso.

Questo modello a consumo introduce le seguenti modifiche al processo di ottimizzazione dei costi:

  1. Prezzi calcolati in base all’utilizzo effettivo
  2. Ciclo di vita di ottimizzazione dei costi


  • Prezzi calcolati in base all’utilizzo effettivo

    I servizi AWS utilizzano un modello di prezzi calcolati in base all’utilizzo effettivo in cui si paga soltanto la capacità realmente utilizzata. Di seguito sono riportati quattro modi comuni per ottimizzare la spesa del cloud quando si paga per l'uso effettivo:

    1. Dimensionamento corretto
    2. Serverless
    3. Prenotazioni
    4. Istanze spot


    Dimensionamento corretto

    Il dimensionamento corretto si riferisce alla corrispondenza del provisioning e della configurazione dei servizi con il carico di lavoro. Per i servizi basati su EC2 ciò significa scegliere la dimensione e la famiglia di istanze corrette. Se le tue risorse di elaborazione sono principalmente inattive, puoi prendere in considerazione l'utilizzo di un'istanza EC2 più piccola. Se invece il tuo carico di lavoro richiede un numero elevato di risorse di sistema specifiche, puoi decidere di passare a una famiglia di istanze ottimizzata per tali risorse.

    Per facilitare questo processo, puoi utilizzare AWS Compute Optimizer per ottenere suggerimenti di dimensionamento EC2 ottimali basati sulle metriche di sistema precedenti.


    Serverless

    Quando si utilizzano tecnologie serverless come Lambda, i prezzi sono calcolati solo in base all’utilizzo effettivo. Se Lambda non viene eseguito, non viene addebitato alcun costo. La tecnologia serverless è l’esempio di prezzi in base al reale utilizzo più adatto in assoluto. Laddove possibile, la scelta del serverless può essere il modo più economico per costruire il tuo servizio.


    Prenotazioni

    Richiedere una prenotazione significa impegnarsi a pagare un determinato importo di capacità in cambio di uno sconto significativo. Per EC2, ciò può comportare uno sconto del 72% per la tua elaborazione.

    Per effettuare prenotazioni per la tua elaborazione, puoi utilizzare Savings Plans. Puoi iscriverti per un periodo di 1 o 3 anni e impegnarti a utilizzare una determinata quantità di elaborazione, ottenendo in questo modo risparmi su EC2, Fargate e Lambda.

    Tieni presente che le prenotazioni non sono esclusive di EC2, in quanto è possibile richiedere anche altri servizi come RDS, DynamoDB e CloudFront.


    Istanze spot

    Le istanze spot EC2 consentono di sfruttare la capacità EC2 non utilizzata per eseguire istanze con uno sconto fino al 90% rispetto ai prezzi on demand. Ciò può comportare enormi risparmi per i carichi di lavoro tolleranti ai guasti.

    Il compromesso quando si utilizza un'istanza spot è che EC2 può recuperare la capacità in qualsiasi momento. La tua applicazione riceverà un preavviso due minuti prima che ciò accada.


    Punti da tenere a mente

    • I servizi AWS sono a pagamento per quel che utilizzi: ti vengono addebitati solo i costi della capacità utilizzata
    • Puoi dimensionare correttamente le tue istanze per risparmiare denaro per i servizi che non corrispondono al tuo carico di lavoro
    • Puoi utilizzare le tecnologie serverless per assicurarti di pagare solo quando i clienti utilizzano il tuo servizio
    • Puoi utilizzare le prenotazioni per ottenere sconti in cambio di un impegno iniziale
    • Puoi utilizzare le istanze spot per ottenere sconti su carichi di lavoro con tolleranza ai guasti


    Ulteriori letture

  • Ciclo di vita di ottimizzazione dei costi

    Il ciclo di vita di ottimizzazione dei costi è il processo continuo di miglioramento delle spese nel cloud nel tempo.

    Tale processo implica il seguente flusso di lavoro in tre passaggi:

    1. Riesame
    2. Monitoraggio
    3. Ottimizzazione


    Riesame

    Prima di poter ottimizzare le spese del cloud, dovrai capire da dove provengono.

    AWS Cost Explorer consente di visualizzare ed esaminare le spese del tuo cloud nel tempo. Puoi suddividere la spesa in diversi aspetti, come servizio e categoria. Utilizza Cost Explorer per ottenere sia una panoramica di alto livello sia rapporti dettagliati sulla fattura.

    Se hai bisogno di dati più dettagliati, puoi ottenere le voci dei prezzi a ora tramite il report di costi e utilizzo di AWS.


    Monitoraggio

    Una volta che hai una visione d'insieme delle tue spese cloud complessive, puoi iniziare a raggrupparle in base alle dimensioni che più ti interessano. Ciò è possibile utilizzando i tag di allocazione dei costi Tali tag devono essere attivati per ogni tag che desideri monitorare.

    Di seguito sono riportati degli esempi comuni di categorie di tag:

    • ID applicazione: identifica le risorse correlate a una applicazione specifica per un facile monitoraggio del cambio di spesa e la disattivazione alla fine dei progetti.
    • Opt-in/opt-out di di automazione: indica se una risorsa deve essere inclusa o meno in un'attività automatizzata come l'avvio, l'arresto o il ridimensionamento delle istanze.
    • Centro di costo/unità operativa: identifica il centro di costo o l’unità operativa associati a una risorsa, in genere per allocazione e monitoraggio dei costi.
    • Proprietario: identifica il responsabile della risorsa. Di solito questo è il proprietario tecnico. Se necessario, puoi aggiungere un tag separato per il proprietario aziendale. Il proprietario può essere specificato come un indirizzo e-mail. L'uso di un indirizzo e-mail supporta notifiche automatizzate sia per i proprietari tecnici che per quelli aziendali, in base alle necessità (ad esempio, se la risorsa è candidata per l'elasticità o il dimensionamento corretto).

    Oltre ai tag, puoi utilizzare AWS Budgets per creare obiettivi di budget. Con AWS Budgets, puoi monitorare la tua spesa attraverso le dimensioni che ti interessano. Budgets tiene traccia e crea previsioni per la spesa AWS corrente in base ai filtri impostati.


    Ottimizzazione

    Dopo aver revisionato e monitorato le tue spese, potrai iniziare a ottimizzarle. L'ottimizzazione della spesa implica l'implementazione delle tecniche di cui abbiamo parlato in Prezzi calcolati in base all’utilizzo effettivo. Questa ottimizzazione viene generalmente eseguita come parte di un obiettivo di budget completo.

    Di seguito sono riportati degli esempi di obiettivi di ottimizzazione:

    • Percentuale di istanze EC2 coperte da un piano di risparmio: l'organizzazione dovrebbe puntare a una copertura dell'80%-90%
    • Percentuale di risorse inattive: la definizione di inattività e la percentuale esatta varieranno a seconda dell'azienda


    Punti da tenere a mente

    • Il ciclo di vita di ottimizzazione dei costi è un processo continuo di miglioramento delle spese nel cloud nel tempo
    • Tale ciclo consiste nella revisione, il monitoraggio e l’ottimizzazione delle spese
    • La revisione delle spese implica l'utilizzo di strumenti come Cost Explorer e il rapporto costi e utilizzo per comprendere le spese stesse
    • Il monitoraggio delle spese comporta l'uso di tag e budget per l'allocazione dei costi per filtrare i dati in base alle dimensioni rilevanti per la tua attività
    • L'ottimizzazione delle spese implica l'utilizzo delle tecniche descritte nella sezione precedente come parte di un obiettivo di budget completo


    Ulteriori letture

Conclusioni

In questo modulo, hai appreso informazioni sul principio di ottimizzazione dei costi. Hai imparato come applicare un modello OpEx alle spese del tuo cloud. Hai appreso le tecniche di ottimizzazione dei costi come dimensionamento corretto, serverless, prenotazioni e istanze spot. Hai imparato a revisionare, monitorare e ottimizzare il tuo budget utilizzando servizi come Cost Explorer, tag e budget.

 

Ulteriori letture

AWS GovCloud (Stati Uniti)

Questa sezione è per coloro i cui carichi di lavoro devono soddisfare FedRAMP, DoD SRG, ITAR, CJIS o altri requisiti di conformità rigorosi, oppure contengono dati classificati come Controlled Unclassified Information (CUI).

AWS GovCloud (Stati Uniti) aiuta a soddisfare le specifiche esigenze di conformità e regolamentazione delle agenzie governative statunitensi a livello federale, statale e locale, nonché delle organizzazioni commerciali statunitensi nel settore aerospaziale, manifatturiero della difesa, forze dell'ordine, sanità, servizi finanziari, energia e altri settori fortemente regolamentati. Progettate per ospitare dati sensibili e carichi di lavoro regolamentati nel cloud, le regioni AWS GovCloud (Stati Uniti) sono regioni AWS isolate gestite da dipendenti cittadini degli Stati Uniti sul suolo degli Stati Uniti.

AWS GovCloud (Stati Uniti) offre ai clienti governativi e ai loro partner la flessibilità di progettare soluzioni cloud sicure conformi alla linea di base FedRAMP High, la politica di sicurezza dei sistemi di informazione sulla giustizia penale (CJIS) del DOJ, i regolamenti sul traffico internazionale di armi degli Stati Uniti (ITAR), Export Administration Regulations (EAR), Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) per i livelli di impatto 2, 4 e 5, FIPS 140-2, IRS-1075 e altri regimi di conformità.

Dalle informazioni non classificate controllate (CUI), dalle informazioni personali identificabili (PII), dalle cartelle cliniche sensibili dei pazienti e dai dati finanziari ai dati delle forze dell'ordine, i dati controllati dalle esportazioni e altre forme di CUI, le regioni AWS GovCloud (Stati Uniti) possono aiutare i clienti a rispondere alla conformità in ogni fase del loro viaggio nel cloud.

 

Ulteriori letture

Complimenti!

Hai appena completato il corso sui principi fondamentali di AWS. In questo corso hai imparato:

  • I cinque principi del canone di architettura AWS
  • Importanti modelli mentali che rappresentano un modo di pensare ai cinque principi collegato al cloud
  • I concetti chiave all’interno di ognuno dei cinque principi

A questo punto, hai imparato i punti fondamentali della creazione di servizi sicuri, efficienti, affidabili, eccellenti dal punto di vista operativo e ottimizzati in termini di costi nel cloud. Mentre abbiamo solo osservato in superficie tutto ciò che c'è da sapere, ora hai un solido punto di partenza per il resto del tuo viaggio in AWS. Ora che hai completato il corso sui principi fondamentali di AWS, vai avanti e applica ciò che hai imparato per creare il tuo prossimo servizio in AWS.