Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Valutazione prioritaria delle applicazioni Uno dei risultati principali della fase precedente, l'[individuazione del portafoglio e la pianificazione iniziale](portfolio-discovery-initial-planning.md), è stato quello di [dare priorità a un sottoinsieme di applicazioni per una valutazione dettagliata](prioritization-and-migration-strategy.md#prioritizing-applications). Questa sezione esplora la valutazione dettagliata delle applicazioni. L'analisi precoce dei dettagli di alcune applicazioni favorirà l'accelerazione. Il processo di valutazione e la futura progettazione dell'architettura eliminano i potenziali ostacoli e chiariscono le attività importanti che precedono la migrazione su più vasta scala. Queste attività includono la raccolta dei requisiti per stabilire AWS le basi, come la landing zone AWS, o per estendere e convalidare la landing zone esistente. Questa valutazione è anche il momento di considerare le fasi e la strategia per la migrazione. I risultati principali di questa fase sono i seguenti: + Elenco convalidato di applicazioni prioritarie + Architettura dello stato attuale documentata + Architettura di destinazione iniziale documentata e strategia di migrazione per i candidati alla migrazione + Modelli e strumenti di migrazione identificati + Requisiti documentati della piattaforma (sicurezza, AWS infrastruttura e operazioni) + Considerazioni introduttive documentate per la pianificazione della migrazione + Frequenza di esecuzione stimata AWS # Comprendere i requisiti dettagliati relativi ai dati di valutazione La tabella seguente descrive le informazioni necessarie per ottenere una visione completa del portafoglio delle applicazioni oggetto della migrazione e dell'infrastruttura associata. Le tabelle utilizzano le seguenti abbreviazioni: + R, per obbligatorio + O, per opzione + N/A, in quanto non applicabile **Applicazioni** | **Nome attributo** | **Descrizione** | **Strategia di scoperta, progettazione e migrazione** | **Frequenza di esecuzione stimata** | **Livello di fedeltà consigliato (minimo)** | | --- |--- |--- |--- |--- | | Identificatore univoco | Ad esempio, l'ID dell'applicazione. In genere disponibile su inventari e sistemi di controllo esistenti CMDBs o altri sistemi di controllo interni. Prendi in considerazione la possibilità di creare IDs elementi unici ogni volta che questi elementi non sono definiti nella tua organizzazione. | R | O | Elevata | | Application name (Nome applicazione) | Nome con cui l'applicazione è nota all'organizzazione. Includi il nome del fornitore commerciale off-the-shelf (COTS) e del prodotto, se applicabile. | R | R | Elevata | | È COTS? | Sì o no. Che si tratti di un'applicazione commerciale o di uno sviluppo interno | R | R | Elevata | | Prodotto e versione COTS | Nome e versione del prodotto software commerciale | R | R | Elevata | | Description | Funzione e contesto principali dell'applicazione | R | O | Elevata | | Criticità | Ad esempio, un'applicazione strategica o che genera entrate o che supporta una funzione critica | R | O | Elevata | | Tipo | Ad esempio, database, gestione delle relazioni con i clienti (CRM), applicazioni Web, contenuti multimediali, servizi IT condivisi | R | O | Elevata | | Ambiente | Ad esempio, produzione, pre-produzione, sviluppo, test, sandbox | R | R | Elevata | | Conformità e normative | Framework applicabili al carico di lavoro (ad esempio, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e ai requisiti normativi | R | O | Elevata | | Dipendenze | Dipendenze a monte e a valle da applicazioni o servizi interni ed esterni | R | N/D | Elevata | | Mappatura dell'infrastruttura | Mappatura su risorse and/or virtuali fisiche che compongono l'applicazione | R | R | Elevata | | Licenza | Tipo di licenza software commodity (ad esempio, Microsoft SQL Server Enterprise) | R | R | Elevata | | Costo | Costi per la licenza software, le operazioni software e la manutenzione | N/D | R | Medio-alta | | Unità aziendale | Ad esempio, marketing, finanza, vendite | R | O | Elevata | | Dettagli del proprietario | Informazioni di contatto per il proprietario dell'applicazione | R | O | Elevata | | Tipo di architettura | Ad esempio, applicazione web, microservizi a 2 e 3 livelli, architettura orientata ai servizi (SOA) | R | R | Elevata | | Recovery Point Objective (RPO), Recovery Time Objective (RTO) e SLA (Service Level Agreement) | Attributi attuali di gestione del servizio | R | R | Elevata | | Applicazione che genera ricavi o applicazione strategica per l'azienda? | Sì, se l'applicazione influenza direttamente o indirettamente i ricavi dell'azienda o è considerata strategica dall'azienda. | R | O | Medio-alta | | Numero di utenti (simultanei) | Ad esempio, utenti interni o esterni o utenti/clienti and/or esterni interni | R | R | Medio-alta | | User location (Ubicazione dell'utente) | Origine delle sessioni utente | R | R | Medio-alta | | Rischi e problemi | Rischi e problemi noti | R | O | Medio-alta | | Considerazioni sulla migrazione | Eventuali informazioni aggiuntive che potrebbero essere rilevanti per la migrazione | R | R | Medio-alta | | Strategia di migrazione | Ad esempio, una delle AWS 6 R per la migrazione | R | R | Medio-alta | | Dettagli del database | Ad esempio, partizionamento, crittografia, replica, estensioni, supporto Secure Sockets Layer (SSL) | R | R | Elevata | | Team di supporto | Ad esempio, il nome del team addetto alle operazioni applicative | R | O | Medio-alta | | Soluzione di monitoraggio | Prodotto utilizzato per monitorare questa applicazione | R | O | Medio-alta | | Requisiti di backup | Pianificazione di backup richiesta in AWS | R | R | Medio-alta | | Informazioni sul DR | Ad esempio, componenti di disaster recovery per questa applicazione | R | R | Medio-alta | | AWS Requisiti dell'obiettivo | Ad esempio, componenti, posizionamento degli account, rete, sicurezza | R | R | Elevata | **Infrastruttura** | | | | | | | --- |--- |--- |--- |--- | | **Nome dell'attributo** | **Descrizione** | **Strategia di scoperta, progettazione e migrazione** | **Frequenza di esecuzione stimata** | **Livello di fedeltà consigliato (minimo)** | | Identificatore univoco | Ad esempio, l'ID del server. In genere disponibile su inventari e sistemi di controllo esistenti CMDBs o interni. Prendi in considerazione la possibilità di crearne di unici IDs ogni volta che questi elementi non sono definiti nella tua organizzazione. | R | O | Elevata | | Nome della rete | Nome della risorsa nella rete (ad esempio, hostname) | R | O | Elevata | | Nome DNS (nome di dominio completo o FQDN) | Nome DNS | O | O | Medio-alta | | Indirizzo IP e maschera di rete | and/or Indirizzi IP pubblici interni | R | R | Elevata | | Tipo di asset | Ad esempio, server fisico o virtuale, hypervisor, contenitore, dispositivo, istanza di database | R | R | Elevata | | Product name (Nome del prodotto) | Nome del fornitore commerciale e del prodotto (ad es. IBM Power VMware ESXi Systems, Exadata) | R | R | Elevata | | Sistema operativo | Ad esempio, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Elevata | | Configurazione | CPU allocata, numero di core, thread per core, memoria totale, storage, schede di rete | R | R | Elevata | | Utilizzo | Picco e medio di CPU, memoria e storage. Throughput delle istanze di database. | R | R | Elevata | | Licenza | Tipo di licenza commodity (ad esempio, RHEL Standard) | R | R | Elevata | | L'infrastruttura è condivisa? | Sì o No per indicare i servizi di infrastruttura che forniscono servizi condivisi come provider di autenticazione, sistemi di monitoraggio, servizi di backup e servizi simili | R | O | Elevata | | Mappatura delle applicazioni | Applicazioni o componenti applicativi eseguiti in questa infrastruttura | R | O | Elevata | | Dati di comunicazione | Ad esempio, da server a server a livello di processo | R | N/D | Medio-alta | | AWS Requisiti dell'obiettivo | Ad esempio, tipi di istanze, account, sottoreti, gruppi di sicurezza, routing | R | R | Elevata | | Strategia, modelli e strumenti di migrazione | Ad esempio, una delle 6 R per la migrazione, modello tecnico specifico, strumenti di migrazione | R | O | Elevata | | Rischi e problemi | Rischi e problemi noti | R | O | Medio-alta | # Valutazione dettagliata dell'applicazione L'obiettivo di una valutazione dettagliata dell'applicazione è la comprensione completa dell'applicazione interessata e dell'infrastruttura associata (elaborazione, storage e rete). I dati ad alta fedeltà sono necessari per evitare insidie. Ad esempio, è normale che le organizzazioni presumano di comprendere appieno l'applicazione. Questo è naturale ed è vero in molti casi. Tuttavia, per ridurre al minimo i rischi per l'azienda, è importante convalidare le conoscenze istituzionali e la documentazione statica ottenendo il maggior numero possibile di dati programmatici. In questo modo si risolverà la parte pesante del processo di scoperta. Puoi concentrarti sugli elementi di dati che provengono da fonti alternative, come informazioni aziendali specifiche, tabelle di marcia strategiche e altro. La chiave è evitare modifiche dell'ultimo minuto durante e dopo la migrazione. Ad esempio, durante la migrazione, è importante evitare modifiche basate su dipendenze non identificate che potrebbero richiedere l'inclusione di un server in un'ondata di migrazione in corso. Subito dopo la migrazione, è importante evitare modifiche basate sui requisiti di piattaforma associati per consentire il traffico o implementare servizi aggiuntivi. Questi tipi di modifiche non pianificate aumentano il rischio di problemi operativi e di sicurezza. Consigliamo vivamente di utilizzare strumenti di rilevamento programmatico per convalidare i modelli di traffico e le dipendenze durante l'esecuzione di valutazioni dettagliate delle applicazioni. All'inizio della valutazione, è necessario identificare gli stakeholder dell'applicazione. Questi sono in genere i seguenti: + Responsabili delle unità aziendali + Proprietari delle applicazioni + Architetti + Operazioni e supporto + Team di abilitazione al cloud + Team di piattaforme specifiche come elaborazione, archiviazione e reti Esistono due approcci per una scoperta dettagliata. L'individuazione dall'alto verso il basso inizia dall'applicazione, o anche dall'utente, e arriva fino all'infrastruttura. Questo è l'approccio consigliato quando l'identificazione dell'applicazione è chiara. Al contrario, la scoperta dal basso verso l'alto inizia dall'infrastruttura e arriva fino all'applicazione o al servizio e ai relativi utenti. Questo approccio è utile quando i programmi di migrazione sono guidati dai team dell'infrastruttura e quando la application-to-infrastructure mappatura non è chiara. In generale, è probabile che utilizzi una combinazione di entrambi. Per approfondire un'applicazione, i diagrammi di architettura esistenti sono un buon punto di partenza. Se questi non sono disponibili, creane uno basato sulle conoscenze attuali. Non sottovalutate l'importanza di questa attività, anche per semplici strategie di migrazione di rehosting o trasferimento. La creazione di diagrammi architettonici consente di identificare le inefficienze che possono essere risolte rapidamente con piccole modifiche quando si è nel cloud. A seconda che si stia adottando un approccio dall'alto verso il basso o dal basso verso l'alto, il diagramma iniziale riporterà i componenti e i servizi dell'applicazione o i componenti dell'infrastruttura come server e sistemi di bilanciamento del carico. Dopo aver identificato i componenti e le interfacce principali, convalidali con dati programmatici provenienti dagli strumenti di scoperta e dagli strumenti di monitoraggio delle prestazioni delle applicazioni. Gli strumenti devono supportare l'analisi delle dipendenze e fornire informazioni di comunicazione tra i componenti. Ogni componente che compone questa applicazione deve essere identificato. Successivamente, documenta le dipendenze da altre applicazioni e servizi, sia interni che esterni. In assenza di strumenti per convalidare le dipendenze e la mappatura, è necessario un approccio manuale. Ad esempio, è possibile accedere ai componenti dell'infrastruttura ed eseguire script per raccogliere informazioni di comunicazione come porte aperte e connessioni stabilite. Allo stesso modo, è possibile identificare i processi in esecuzione e il software installato. Non sottovalutate lo sforzo richiesto per l'individuazione manuale. Gli strumenti programmatici possono acquisire e segnalare la maggior parte delle dipendenze in pochi giorni, ad eccezione di quelle che si verificano a intervalli maggiori (in genere una piccola percentuale). L'individuazione manuale può richiedere settimane per raccogliere e unire tutti i punti dati e può comunque essere soggetta a errori e dati mancanti. Procedi all'ottenimento delle informazioni specificate nella sezione sui [requisiti dei dati](understanding-detailed-assessment-data-requirements.md) per ogni applicazione prioritaria e l'infrastruttura mappata. Successivamente, utilizza il seguente questionario per guidarti attraverso il processo di valutazione dettagliato. Incontra le parti interessate identificate per discutere le risposte a queste domande. ## Ambito generale + Qual è il livello di criticità di questa applicazione? Genera entrate? È un'applicazione aziendale strategica o di supporto aziendale? È un servizio di infrastruttura di base condiviso da altri sistemi? + Esiste un progetto di trasformazione in corso per questa applicazione? + Si tratta di un'applicazione rivolta all'interno o all'esterno? ## Architecture + Qual è il tipo di architettura attuale (ad esempio, SOA, microservizi, monolith)? Quanti livelli ha l'architettura? È strettamente accoppiato o accoppiato in modo lasco? + Quali sono i componenti (ad esempio, elaborazione, database, storage remoto, sistemi di bilanciamento del carico, servizi di memorizzazione nella cache)? + Cosa sono gli APIs? Descrivili, tra cui il nome dell'API, le operazioni URLs, le porte e i protocolli. + Qual è la latenza massima tollerata tra i componenti e tra questa e altre applicazioni o servizi? ## Operazioni + In quali luoghi funziona questa applicazione? + Chi gestisce l'applicazione e l'infrastruttura? Sono gestiti da team interni o AWS partner? + Cosa succede se l'applicazione non funziona? Chi è interessato? Qual è l'impatto? + Dove si trovano gli utenti o i clienti? Come accedono all'applicazione? Qual è il numero di utenti simultanei? + Quando è stato l'ultimo aggiornamento tecnologico? È previsto un aggiornamento in futuro? In caso affermativo, quando? + Quali sono i rischi e i problemi noti di questa applicazione? Qual è la cronologia delle interruzioni e degli incidenti di media e alta gravità? + Qual è il ciclo di utilizzo (in orario lavorativo)? Qual è il fuso orario di funzionamento? + Quali sono i periodi di blocco delle modifiche? + Quale soluzione viene utilizzata per monitorare questa applicazione? ## Performance + Cosa mostrano le informazioni sulle prestazioni raccolte? L'utilizzo è impennato o costante e prevedibile? Quali sono l'intervallo di tempo, l'intervallo e la data dei dati sulle prestazioni disponibili? + Esistono processi batch pianificati che fanno parte o interagiscono con questa applicazione? ## Ciclo di vita del software + Qual è il tasso di variazione attuale (settimanale, mensile, trimestrale o annuale)? + Qual è il ciclo di vita dello sviluppo (ad esempio, test, sviluppo, QA, UAT, preproduzione, produzione)? + Quali sono i metodi di implementazione per l'applicazione e l'infrastruttura? + Quali sono gli strumenti di distribuzione? + Questa applicazione o infrastruttura utilizza l'integrazione continua (CI) /la distribuzione continua (CD)? Qual è il livello di automazione? Quali sono le attività manuali? + Quali sono i requisiti di licenza per l'applicazione e l'infrastruttura? + Cos'è il contratto sul livello di servizio (SLA)? + Quali sono gli attuali meccanismi di test? Quali sono le fasi del test? ## Migrazione + Quali sono le considerazioni sulla migrazione? A questo punto, prendi nota di tutte le considerazioni relative alla migrazione di questa applicazione. Per una valutazione più completa e accurata, chiedi risposte a questa domanda alle diverse parti interessate. Quindi confronta le loro conoscenze e opinioni. ## Resilienza + Qual è l'attuale metodo di backup? Quali prodotti vengono utilizzati per il backup? Qual è la pianificazione dei backup? Qual è la politica di conservazione dei backup? + Quali sono gli attuali Recovery Point Objective (RPO) e Recovery Time Objective (RTO)? + Questa applicazione dispone di un piano di disaster recovery (DR)? In caso affermativo, qual è la soluzione DR? + Quando è stato l'ultimo test DR? ## Conformità e sicurezza + Quali sono i quadri normativi e di conformità che si applicano a questa applicazione? Quali sono le date dell'ultimo e del prossimo audit? + Questa applicazione ospita dati sensibili? Cos'è la classificazione dei dati? + I dati sono crittografati in transito o a riposo o entrambi? Cos'è il meccanismo di crittografia? + Questa applicazione utilizza certificati SSL? Qual è l'autorità emittente? + Qual è il metodo di autenticazione per utenti, componenti e altre applicazioni e servizi? ## Database + Quali database utilizza questa applicazione? + Qual è il numero tipico di connessioni simultanee al database? Quali sono il numero minimo e il numero massimo di connessioni? + Qual è il metodo di connessione (ad esempio, JDBC, ODBC)? + Le stringhe di connessione sono documentate? Se sì, dove? + Quali sono gli schemi del database? + Il database utilizza tipi di dati personalizzati? ## Dipendenze + Qual è la dipendenza tra i componenti? Nota tutte le dipendenze che non possono essere risolte e che richiedono la migrazione congiunta dei componenti. + I componenti sono suddivisi in diverse ubicazioni? Qual è la connettività tra queste località (ad esempio, WAN, VPN)? + Quali sono le dipendenze di questa applicazione rispetto ad altre applicazioni o servizi? + Quali sono le dipendenze operative? Ad esempio, cicli di manutenzione e rilascio come l'applicazione di patch a Windows. # AWS progettazione di applicazioni e strategia di migrazione Progettare e documentare lo stato futuro dell'applicazione è un fattore chiave di successo della migrazione. Ti consigliamo di creare un design per qualsiasi tipo di strategia di migrazione, non importa quanto semplice o complessa. La creazione del progetto farà emergere potenziali ostacoli, dipendenze e opportunità per ottimizzare l'applicazione anche nei casi in cui non si prevede che l'architettura cambi. Consigliamo inoltre di affrontare lo stato futuro dell'applicazione AWS con una lente di strategia di migrazione. In questa fase, assicuratevi di definire l'aspetto dell'applicazione a AWS seguito di questa migrazione. Il design risultante servirà come base per un'ulteriore evoluzione dopo la migrazione. L'elenco seguente contiene risorse per facilitare il processo di progettazione: + [AWS Architecture Center](https://aws.amazon.com/architecture/) combina strumenti e linee guida, come il AWS Well-Architected Framework. Inoltre, fornisce architetture di riferimento che è possibile utilizzare per l'applicazione. + [La Amazon Builders' Library](https://aws.amazon.com/builders-library/) contiene diverse risorse su come Amazon crea e gestisce il software. + [AWS Solutions Library](https://aws.amazon.com/solutions/) offre una raccolta di soluzioni basate sul cloud, esaminate per dozzine di problemi AWS tecnici e aziendali. Include un'ampia raccolta di architetture di riferimento. + [AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/) fornisce strategie, guide e modelli che facilitano il processo di progettazione e le migliori pratiche di migrazione. + [AWS Documentation](https://docs.aws.amazon.com/)contiene informazioni sui AWS servizi, tra cui guide per l'utente e riferimenti alle API. + Il [Getting Started Resource Center offre diversi tutorial pratici e approfondimenti per apprendere i fondamenti in modo da poter iniziare](https://aws.amazon.com/getting-started/) a sviluppare. AWS A seconda del punto in cui ti trovi nel percorso verso il cloud, le basi potrebbero già esistere. AWS Queste AWS basi includono quanto segue: + Regioni AWS sono stati identificati. + Gli account sono stati creati o possono essere ottenuti su richiesta. + Il networking generale è stato implementato. + I AWS servizi di base sono stati implementati all'interno degli account. Al contrario, potreste essere nelle prime fasi del processo e le AWS basi non sono ancora state stabilite. La mancanza di basi solide potrebbe limitare l'ambito della progettazione dell'applicazione o richiedere ulteriori lavori per definirle. In tal caso, consigliamo di definire e implementare il design di base della landing zone parallelamente al lavoro di progettazione dell'applicazione. La progettazione dell'applicazione aiuta a identificare requisiti quali Account AWS struttura, rete, cloud privato virtuale (VPCs), intervalli CIDR (Classless Inter-Domain Routing), servizi condivisi, sicurezza e operazioni cloud. [AWS Control Tower](https://aws.amazon.com/controltower/)offre il modo più semplice per configurare e gestire un AWS ambiente sicuro con più account, chiamato landing zone. AWS Control Tower crea la tua landing zone utilizzando AWS Organizations, che offre la gestione e la governance degli account continue e l'implementazione di un'esperienza basata sulle AWS migliori pratiche di lavoro con migliaia di clienti mentre passano al cloud. ## Stato futuro dell'applicazione Inizia stabilendo la strategia di migrazione iniziale per questa applicazione. A questo punto, la strategia è considerata iniziale perché potrebbe cambiare come parte del disegno dello stato futuro, che può rivelare potenziali limiti. Per convalidare le ipotesi iniziali, consulta l'albero decisionale delle [6 R.](prioritization-and-migration-strategy.md#migration-r-type) Inoltre, documenta le potenziali fasi di migrazione. Ad esempio, questa applicazione verrà migrata in un unico evento (tutti i componenti vengono migrati contemporaneamente)? Oppure si tratta di una migrazione graduale (alcuni componenti vengono migrati in un secondo momento)? Tieni presente che le strategie di migrazione per una determinata applicazione potrebbero non essere uniche. Questo perché è possibile utilizzare più tipi R per migrare i componenti dell'applicazione. Ad esempio, l'approccio iniziale potrebbe consistere nel sollevare e spostare l'applicazione senza modifiche. Tuttavia, i componenti di un'applicazione potrebbero risiedere in diversi asset infrastrutturali che potrebbero richiedere trattamenti diversi. Ad esempio, un'applicazione è composta da tre componenti, ciascuno eseguito su un server separato, e uno dei server esegue un sistema operativo legacy non supportato nel cloud. Tale componente richiederà un approccio ripiattaforma, mentre gli altri due componenti, in esecuzione nelle versioni server supportate, possono essere riospitati. È fondamentale assegnare una strategia di migrazione a ciascun componente dell'applicazione e all'infrastruttura associata che viene migrata. Successivamente, documenta il contesto e il problema e collega gli artefatti esistenti che definiscono lo stato corrente: + Perché viene eseguita la migrazione di questa applicazione? + Quali sono le modifiche proposte? + Quali sono i vantaggi? + Esistono rischi o ostacoli importanti? + Quali sono gli aspetti negativi attuali? + Cosa rientra nell'ambito e cosa non rientra nell'ambito di applicazione? ## Ripetibilità Durante tutto il lavoro di progettazione, considerate come la soluzione e l'architettura per questa applicazione possano essere riutilizzate per altre applicazioni. Questa soluzione può essere generalizzata? ## Requisiti Documenta i requisiti funzionali e non funzionali di questa applicazione, inclusa la sicurezza. Ciò include i requisiti statali attuali e futuri, a seconda della strategia di migrazione scelta. Utilizzate le informazioni raccolte durante la valutazione dettagliata dell'applicazione per guidare questo processo. ## Architettura futura Descrivi le future architetture di questa applicazione. Prendi in considerazione la creazione di un modello di diagramma riutilizzabile che contenga elementi costitutivi per l'ambiente di origine (locale) e AWS l'ambiente di destinazione (ad esempio, destinazione Regione AWS VPCs, account e zone di disponibilità). Crea una tabella dei componenti che verranno migrati e dei componenti che saranno nuovi. Includi altre applicazioni e servizi (in locale o nel cloud) che interagiscono con questa applicazione. La tabella seguente elenca alcuni componenti di esempio. Non rappresenta un'architettura di riferimento o una configurazione controllata. | **Nome** | **Descrizione** | **Dettagli** | | --- |--- |--- | | Applicazione | Servizio esterno (connessione in entrata) | Il servizio utilizza i dati dall'API esposta. | | DNS | Risoluzione dei nomi (interna) | Amazon Route 53 distribuito come parte delle impostazioni di base dell'account | | Application Load Balancer | Distribuisce il traffico tra i servizi di backend | Sostituisce il sistema di bilanciamento del carico locale. Migrazione del pool A. | | Sicurezza delle applicazioni | Protezione dagli attacchi DDoS | Implementato utilizzando AWS Shield | | Gruppo di sicurezza | Firewall virtuale | Limita l'accesso alle istanze dell'applicazione sulla porta 443 (in entrata). | | Server A | Front-end | Rehosting, utilizzando Amazon Elastic Compute Cloud (Amazon EC2). | | Server B | Front-end | Rehosting tramite Amazon EC2. | | Server C | Logica dell'applicazione | Rehosting tramite Amazon EC2. | | Server D | Logica dell'applicazione | Rehosting tramite Amazon EC2. | | Amazon Relational Database Service (Amazon RDS) — Amazon Aurora | Database | Sostituisce i server E e F | | Monitoraggio e avvisi | Controllo delle modifiche | Amazon CloudWatch | | Registrazione di controllo | Controllo delle modifiche | AWS CloudTrail | | Patch e accesso remoto | Maintenance (Manutenzione) | AWS Systems Manager | | Accesso alle risorse | Controllo sicuro degli accessi | AWS Identity and Access Management (IAM) | | Autenticazione | Accesso utente | Amazon Cognito | | Certificati | SSL/TLS | AWS Certificate Manager | | API 1 | API esterna | Gateway Amazon API | | Archiviazione di oggetti | Hosting di immagini | Amazon Simple Storage Service (Amazon S3) | | Credenziali | Gestione e hosting delle credenziali | Gestione dei segreti AWS | | AWS Lambda funzione | Recupero delle credenziali del database e delle chiavi API | AWS Lambda | | Internet Gateway | Accesso a Internet in uscita | Gateway Internet verso un VPC | | Sottorete privata 1 | Backend e DB | Zona di disponibilità 1 — VPC 1 | | Sottorete privata 2 | Backend e DB | Zona di disponibilità 2 — VPC 1 | | Sottorete pubblica 1 | Front-end | Zona di disponibilità 1 — VPC 1 | | Sottorete pubblica 2 | Front-end | Zona di disponibilità 2 — VPC 1 | | Servizi di Backup | Database e backup delle istanze EC2 | AWS Backup | | DR | Resilienza di Amazon EC2 | Ripristino di emergenza di elastico di AWS | Dopo aver identificato i componenti, tracciali in un diagramma utilizzando il tuo strumento preferito. Condividi il progetto iniziale con le principali parti interessate all'applicazione, inclusi i proprietari delle applicazioni, gli architetti aziendali e i team di piattaforma e migrazione. Prendi in considerazione la possibilità di porre le seguenti domande: + Il team è generalmente d'accordo con il design? + I team operativi possono supportarlo? + Il design può essere evoluto? + Esistono altre opzioni? + Il design è conforme agli standard architettonici e alle politiche di sicurezza? + Mancano dei componenti (ad esempio, repository di codice, CI/CD strumenti, endpoint VPC)? ## Decisioni architetturali Come parte del processo di progettazione, probabilmente troverai più opzioni per l'architettura generale o per parti specifiche di essa. Documenta queste opzioni insieme alle motivazioni alla base di un'opzione preferita o selezionata. Queste decisioni possono essere documentate come decisioni architettoniche. Assicurati che le opzioni principali siano elencate e descritte in modo sufficientemente dettagliato da consentire a un nuovo lettore di comprendere le opzioni e le ragioni alla base della decisione di utilizzare un'opzione rispetto a un'altra. ## Ambienti del ciclo di vita del software Documenta eventuali modifiche agli ambienti correnti. Ad esempio, gli ambienti di test e sviluppo verranno ricreati AWS e non migrati. ## Assegnazione di tag Descrivi i tag obbligatori e consigliati per ogni componente dell'infrastruttura, nonché il valore di etichettatura per questo progetto. ## Strategia di migrazione A questo punto della progettazione, le ipotesi iniziali sulla strategia di migrazione dovrebbero essere convalidate. Conferma che vi sia consenso sulla strategia R scelta. Documenta la strategia generale di migrazione delle applicazioni e le strategie per i singoli componenti dell'applicazione. Come accennato in precedenza, diversi componenti dell'applicazione potrebbero richiedere diversi tipi R per la migrazione. Inoltre, allinea la strategia di migrazione ai principali fattori e risultati aziendali. Descrivete inoltre qualsiasi approccio graduale alla migrazione, ad esempio lo spostamento dei componenti in diversi eventi di migrazione. Per ulteriori informazioni sulla determinazione delle 6 R, consulta i [consigli AWS Migration Hub strategici](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Modelli e strumenti di migrazione Con una strategia di migrazione definita per i componenti dell'applicazione e dell'infrastruttura, ora puoi esplorare modelli tecnici specifici. Ad esempio, una strategia di rehosting può essere implementata mediante strumenti di migrazione come. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Se non è necessario replicare lo stato o i dati, è possibile ottenere lo stesso risultato ridistribuendo l'applicazione utilizzando un'Amazon Machine Image (AMI) e una pipeline di distribuzione dell'applicazione. [Analogamente, per ripiattaforma o rifattorizzare (riprogettare) un'applicazione, puoi utilizzare strumenti come, (), () [AWS App2Container](https://aws.amazon.com/app2container/),AWS Database Migration Service .AWS DMS[AWS Schema Conversion ToolAWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)](https://aws.amazon.com/dms/schema-conversion-tool/)](https://aws.amazon.com/dms/) Per la containerizzazione, puoi utilizzare [Amazon Elastic Container Service (Amazon ECS), Amazon](https://aws.amazon.com/ecs/) Elastic Kubernetes [Service (Amazon EKS) oppure](https://aws.amazon.com/eks/). [AWS Fargate](https://aws.amazon.com/fargate/) Al momento del riacquisto, puoi utilizzare un'AMI per un prodotto specifico o una soluzione SaaS (Software as a Service) di. [Marketplace AWS](https://aws.amazon.com/marketplace/) Valuta i diversi modelli e opzioni disponibili per raggiungere l'obiettivo. Prendi in considerazione i pro e i contro e la prontezza operativa della migrazione. Per aiutarti con l'analisi, usa le seguenti domande: + I team di migrazione possono supportare questi modelli? + Qual è l'equilibrio tra costi e benefici? + È possibile spostare questa applicazione, servizio o componente in un servizio gestito? + Qual è lo sforzo necessario per implementare questo modello? + Esiste una normativa o una politica di conformità che impedisca l'uso di uno schema specifico? + Questo modello può essere riutilizzato? I modelli riutilizzabili sono preferiti. Tuttavia, a volte un pattern viene utilizzato una sola volta. Considera l'equilibrio tra lo sforzo di un modello monouso rispetto a un modello riutilizzabile alternativo. AWS La [guida prescrittiva](https://aws.amazon.com/prescriptive-guidance/) contiene una varietà di modelli e tecniche di migrazione. ## Gestione e operazioni dei servizi Quando crei progetti di applicazioni per la migrazione AWS, considera la prontezza operativa. Nel valutare i requisiti di preparazione con i team addetti alle applicazioni e all'infrastruttura, tenete conto delle seguenti domande: + Sono pronti a utilizzarlo? + Le procedure di risposta agli incidenti sono definite? + Qual è il contratto sul livello di servizio (SLA) previsto? + È richiesta la separazione dei compiti? + I diversi team sono pronti a coordinare le azioni di supporto? + Chi è responsabile di cosa? ## Considerazioni su Cutover Considerando la strategia e i modelli di migrazione, cosa è importante sapere al momento della migrazione dell'applicazione? La pianificazione dei cutover è un'attività post-progettazione. Tuttavia, documentate eventuali considerazioni relative alle attività e ai requisiti che possono essere previsti. Ad esempio, documenta il requisito di eseguire un proof of concept, se applicabile, e delinea i requisiti di test, audit o convalida. ## Rischi, ipotesi, problemi e dipendenze Documenta eventuali rischi, ipotesi e potenziali problemi non ancora risolti. Assegna una chiara proprietà a questi elementi e monitora i progressi in modo che la progettazione e la strategia complessive possano essere approvate per l'implementazione. Inoltre, documenta le dipendenze chiave per l'implementazione di questo progetto. ## Stima dei costi di esecuzione Per stimare il costo dell' AWS architettura di destinazione, utilizzate il [AWS Pricing Calculator](https://calculator.aws/). Aggiungi i componenti dell'infrastruttura in base a quanto definito dal tuo progetto e ottieni un costo di esercizio stimato. Tieni conto delle licenze software necessarie per i componenti dell'applicazione e che non sono già incluse nei AWS servizi che utilizzerai.