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à.
# Fondamento della piattaforma
Questa sezione si concentra sulla valutazione della disponibilità dell'infrastruttura locale, sulla preparazione della AWS landing zone o sulla revisione della progettazione della landing zone esistente e sull'identificazione degli strumenti di migrazione necessari. Vengono esaminate le domande comuni relative all'infrastruttura, alle operazioni e alla sicurezza da prendere in considerazione per la creazione di una piattaforma. Documentate le vostre risposte e decisioni come principi di migrazione. Di conseguenza, disponi di una solida piattaforma per raggiungere la scalabilità e la velocità necessarie per migrazioni di grandi dimensioni.
Questa sezione contiene gli argomenti seguenti:
+ [Considerazioni sulla zona di atterraggio per una migrazione su larga scala](landing-zone.md)
+ [Considerazioni locali per una migrazione su larga scala](on-premises.md)
+ [Documenta i tuoi principi di migrazione](document.md)
# Considerazioni sulla zona di atterraggio per una migrazione su larga scala
Una *landing zone* è un AWS ambiente ben progettato, scalabile e sicuro. Stabilendo degli standard per la landing zone, come la definizione del numero di account e la progettazione delle sottoreti e dei gruppi di sicurezza, si costruiscono solide fondamenta. Questa base ti offre la possibilità di abilitare, fornire e gestire il tuo ambiente sia per l'agilità aziendale che per la governance su larga scala, accelerando al contempo il percorso di adozione del cloud. Per ulteriori informazioni sulle zone di atterraggio e sulle strategie per costruirle, consulta [Configurazione di un ambiente multi-account sicuro e scalabile](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/). AWS
Oltre alle considerazioni commerciali, operative, di sicurezza e di conformità standard per la tua strategia di landing zone, devi considerare come facilitare una migrazione su larga scala. È necessario progettare la landing zone in modo da supportare i carichi di lavoro locali esistenti durante la migrazione e dopo, nei casi in cui alcuni carichi di lavoro rimangano in locale. Questa guida fornisce ulteriori considerazioni sulle landing zone che influiscono sulla velocità di migrazione e sulla tempistica complessiva della migrazione.
In genere, le zone di atterraggio sono progettate e implementate per supportare nuovi carichi di lavoro in. Cloud AWS Questo perché le organizzazioni stanno adottando AWS prima di prendere la decisione di migrare un gran numero di applicazioni esistenti. Il vantaggio di questo approccio è che l'organizzazione acquisisce conoscenze e competenze preziose AWS prima della migrazione su larga scala, ma può anche portare a conflitti tra le varie parti interessate. Alcune parti interessate potrebbero voler modernizzare l'applicazione durante la migrazione perché desiderano sfruttare le funzionalità native del cloud. Tuttavia, l'obiettivo comune di una migrazione su larga scala è raggiungere la massima velocità di migrazione e facilitare la transizione migrando il maggior numero possibile di applicazioni senza modificare il carico di lavoro. Queste applicazioni vengono quindi modernizzate una volta completata la migrazione.
Alcuni fattori chiave della landing zone che possono influire su un ampio progetto di programma di migrazione sono:
+ Disponibilità e gestione della larghezza di banda di rete
+ Strategia degli account per l'isolamento del carico di lavoro e la gestione delle risorse
+ Controlli amministrativi e di sicurezza per i carichi di lavoro migrati
Questa sezione esamina le questioni relative all'infrastruttura, alle operazioni e alla sicurezza che dovresti considerare quando costruisci la tua AWS landing zone. Contiene anche consigli su come progettare e implementare una landing zone per supportare un progetto di migrazione di grandi dimensioni. Rispondendo alle domande di questa sezione, queste decisioni diventano principi di migrazione, che vengono documentati secondo le istruzioni contenute in [Documenta le tue decisioni come principi di migrazione di grandi dimensioni](document.md).
## Considerazioni sull'infrastruttura
| Avete preso in considerazione? | Descrizione | Operazioni |
| --- | --- | --- |
| Quanti dati migrerai al giorno e alla settimana? | La velocità di migrazione desiderata determina il tipo di connessione di rete e i requisiti di velocità di trasmissione della rete. Inoltre può influire sui criteri di selezione della pianificazione delle ondate. | Dopo aver completato la valutazione del portafoglio, determina la quantità totale di storage necessaria per tutte le risorse migrate nel cloud. Utilizzate questo valore per calcolare la quantità di tempo necessaria per migrare i dati utilizzando l'attuale larghezza di banda della rete. Potrebbe essere necessario aumentare la larghezza di banda per rispettare i tempi di migrazione oppure potrebbe essere necessario utilizzare alternative, ad esempio soluzioni. AWS Snow Family Nei [modelli di playbook di base](samples/foundation-playbook-templates.zip), puoi utilizzare il *calcolatore di replica dei dati (*formato Microsoft Excel) per calcolare la larghezza di banda richiesta per ogni ondata di migrazione. |
| Qual è la velocità media di scrittura dei server di origine in ogni ondata? | La larghezza di banda richiesta per trasferire i dati replicati si basa sulla velocità di scrittura dei server di origine partecipanti. La quantità di larghezza di banda richiesta per la replica dei server è la velocità di scrittura media dei server di origine moltiplicata per il numero di server nell'ondata più grande. | Durante la valutazione del portafoglio, è necessario determinare il numero medio di scritture di dati eseguite per ogni server. Nei [modelli di playbook di base](samples/foundation-playbook-templates.zip), puoi utilizzare il *calcolatore di replica dei dati (*formato Microsoft Excel) per comprendere la larghezza di banda richiesta per il traffico di migrazione. La larghezza di banda richiesta per il traffico di migrazione si aggiunge alla larghezza di banda utilizzata per le normali attività aziendali. Una volta completata la migrazione, non è più necessaria la larghezza di banda aggiuntiva per supportare le attività di migrazione. |
| Le attività di rete aggiuntive o l'infrastruttura esistente potrebbero limitare o ridurre la velocità di replica? | Se la larghezza di banda della rete supporta anche altre funzioni aziendali, queste attività possono ridurre la quantità di larghezza di banda disponibile per la replica dei server durante la migrazione. | Nelle prime fasi del ciclo di vita del progetto, valuta e calcola attentamente la larghezza di banda di rete necessaria per supportare tutte le attività aziendali. Considerate la larghezza di banda necessaria per le normali attività aziendali, la replica dei server e le nuove attività legate alla migrazione, come la sincronizzazione delle condivisioni di file locali con i dati presenti. AWS I provider potrebbero avere tempi di consegna lunghi per aumentare la capacità di rete e potrebbe essere necessario aggiornare l'infrastruttura locale esistente. Valuta se sarebbero necessari aggiornamenti aggiuntivi come conseguenza dell'aggiornamento dell'infrastruttura di rete. La valutazione dei requisiti di larghezza di banda nelle prime fasi del progetto offre il tempo necessario per apportare le modifiche necessarie. |
| La tua attuale strategia di AWS sottorete soddisfa i requisiti di indirizzamento IP per la migrazione dei carichi di lavoro locali? | Il numero di server e i requisiti di isolamento del carico di lavoro determinano la strategia di sottorete per la landing zone. Le migrazioni di grandi dimensioni potrebbero richiedere sottoreti più grandi del previsto. In una migrazione di grandi dimensioni, i carichi di lavoro vengono raggruppati in sottoreti in modo simile alla loro configurazione nell'infrastruttura locale. Per semplificare la migrazione, si preferiscono inizialmente progetti di sottoreti più grandi e piatti, quindi, durante la modernizzazione, si riprogettano le sottoreti secondo necessità. | Quando la valutazione del portafoglio contiene informazioni sufficienti sull'inventario dell'infrastruttura, valuta la struttura di rete locale e incorporala nella progettazione della landing zone il prima possibile. |
| Quanti server intendi replicare e migrare in parallelo? | [La dimensione della più grande ondata di migrazione influisce sui requisiti della sottorete e AWS sulle quote di servizio.](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) | Esamina il piano di migrazione di alto livello e utilizzalo per progettare la tua sottorete. Ad esempio, se hai intenzione di migrare 200 server in una sottorete, l'intervallo CIDR (Classless Inter-Domain Routing) per quella sottorete dovrebbe avere indirizzi IP sufficienti per supportare il numero di server di destinazione. Inoltre, aumenta la quota di AWS servizio per ogni account di destinazione in base alle esigenze. |
| Avete identificato le strategie dei gruppi di sicurezza per le vostre risorse di migrazione? | I gruppi di sicurezza vengono utilizzati per gestire il traffico in entrata e in uscita relativo alle risorse. AWS È importante progettare tempestivamente i gruppi di sicurezza per evitare ritardi nella migrazione. | Nel tuo runbook per la prioritizzazione delle applicazioni, esamina le strategie di migrazione e quindi progetta i gruppi di sicurezza in base alle strategie di migrazione. Ad esempio, se la strategia di migrazione consiste nel riospitare la maggior parte dei carichi di lavoro, prendi in considerazione un gruppo di sicurezza temporaneo e generico che supporti il cutover della migrazione anziché rifattorizzare la rete e applicare gruppi di sicurezza specifici delle applicazioni. |
| Sono in uso sistemi di bilanciamento del carico? | In genere, durante la migrazione dei server in un ambiente con sistemi di bilanciamento del carico, è necessario valutare la configurazione del load balancer e quindi migrare il load balancer. Le opzioni di migrazione per il load balancer includono l'utilizzo di Elastic Load Balancing (ELB) o di una soluzione basata su appliance partner. | La valutazione dei sistemi di bilanciamento del carico deve iniziare all'inizio della fase di scoperta per tenere conto di eventuali configurazioni personalizzate. Nella maggior parte degli ambienti, le configurazioni del load balancer sono piuttosto standard, ma alcune potrebbero avere una logica complessa che determina se è possibile migrare a ELB o a una soluzione basata su appliance partner. |
| È necessario che i server mantengano l'indirizzo IP di origine? | Il modo più sicuro e semplice per migrare i server sul cloud consiste nell'allocare nuovi indirizzi IP alle istanze migrate. In alcune situazioni, potrebbe essere necessario mantenere lo stesso indirizzo IP del server di origine. Ad esempio, un'applicazione precedente potrebbe avere un indirizzo IP codificato che nessuno sa come modificare. | La conservazione degli indirizzi IP di origine influisce sul modo in cui si formano i gruppi di spostamenti durante la pianificazione delle ondate. L'approccio più comune consiste nel migrare un'intera sottorete AWS in un unico gruppo di spostamento, poiché ciò semplifica il routing e la commutazione a livello di rete. Di seguito sono riportate le azioni chiave per la conservazione degli indirizzi IP: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html) |
| Quanta latenza è accettabile tra la sorgente e? AWS | È comune iniziare la migrazione con i collegamenti VPN perché possono essere configurati rapidamente e quindi passare a una connessione diretta stabilita utilizzando AWS Direct Connect. I link VPN hanno generalmente una latenza più elevata e variabile, che influisce sulla velocità di trasmissione dei dati e, soprattutto, sui tempi di risposta delle applicazioni. | Se utilizzi un tipo di connessione a latenza elevata o variabile, esamina i requisiti di ciascuna applicazione e pianifica le ondate di migrazione di conseguenza. Pianificate di inserire le applicazioni che richiedono connessioni a bassa latenza in ondate successive, quando saranno disponibili tipi di connessione alternativi. |
## Considerazioni sulle operazioni
| Ci hai pensato? | Descrizione | Operazioni |
| --- | --- | --- |
| Hai identificato una strategia di AWS account per la tua landing zone? | AWS le migliori pratiche per un ambiente ben progettato consigliano di separare le risorse e i carichi di lavoro in più account. AWS Puoi pensare AWS agli account come contenitori di risorse isolati: offrono la categorizzazione dei carichi di lavoro e possono ridurre la portata dell'impatto in caso di disastro. | Nel tuo runbook per la prioritizzazione delle applicazioni, esamina le strategie di migrazione selezionate e usale per determinare la strategia del tuo account. Ad esempio, se desideri migrare il più rapidamente possibile e il rehosting è la strategia di migrazione più comune, è più facile gestire meno account. Tuttavia, se le vostre strategie di migrazione richiedono la modernizzazione delle applicazioni e avete bisogno di separare le unità aziendali per motivi di conformità, dovreste includere uno o più account per ogni unità aziendale nella vostra strategia di account. |
| È necessario cambiare gli strumenti di monitoraggio durante la migrazione? In caso affermativo, fa parte del processo di migrazione o avviene prima o dopo la migrazione? | Gli strumenti di monitoraggio sono fondamentali per le operazioni sul cloud. Gli strumenti esistenti potrebbero non funzionare nel cloud per motivi di compatibilità o di licenza. Come parte della progettazione, è necessario decidere quali strumenti di monitoraggio utilizzare per il carico di lavoro in. Cloud AWS | Seleziona uno strumento di monitoraggio prima di iniziare la migrazione. Assicurati che il team addetto alla migrazione includa le istruzioni per configurare il monitoraggio nei modelli di migrazione. Ti consigliamo di creare uno script di automazione che sostituisca o riutilizzi gli strumenti di monitoraggio, se necessario. |
| Hai identificato i proprietari delle applicazioni e sono a conoscenza delle eventuali modifiche da apportare all'applicazione per farla funzionare correttamente nel cloud? | La migrazione su larga scala è una trasformazione piuttosto che un semplice progetto di infrastruttura. Includi tempestivamente i proprietari delle applicazioni per supportare la migrazione. Ad esempio, i proprietari delle applicazioni convalidano il piano Wave, creano piani di test e partecipano al cutover. | Collabora con un ufficio di gestione dei progetti e il team di Cloud Enablement Engine per allinearti con i leader dei team applicativi e assicurarti che la comunicazione sia chiara tra tutti i team applicativi. Per ulteriori informazioni sulla comunicazione e sulla trasparenza dei progetti, consulta la [guida sulla governance di Project per migrazioni di grandi dimensioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/). AWS |
| Hai selezionato una soluzione di backup e ripristino e funziona con carichi di lavoro migrati? | Gli strumenti di backup e ripristino sono fondamentali per le operazioni cloud. Gli strumenti esistenti potrebbero non funzionare nel cloud per motivi di compatibilità o di licenza. Come parte della progettazione, è necessario decidere quali strumenti di backup e ripristino utilizzare per il carico di lavoro di. Cloud AWS | Seleziona gli strumenti di backup e ripristino prima di iniziare la migrazione. Assicurati che il team addetto alla migrazione includa le istruzioni per la configurazione del backup e del ripristino nei modelli di migrazione. Ti consigliamo di creare uno script di automazione che sostituisca o riutilizzi gli strumenti di backup e ripristino, se necessario. |
| Hai identificato tutti i servizi condivisi e li hai implementati nella landing zone? | I *servizi condivisi* sono servizi che supportano più applicazioni, come e-mail, Active Directory o ambienti di database condivisi. In genere è necessario distribuire servizi condivisi nel cloud prima della migrazione in modo che le applicazioni migrate funzionino come previsto. | Pianifica un'analisi approfondita con il team dell'infrastruttura e i responsabili del team applicativo prima di completare la progettazione della landing zone. Rivedi e conferma l'elenco dei servizi condivisi che devi implementare nel cloud prima di iniziare la migrazione. I servizi condivisi più comuni sono Active Directory, dispositivi di rete, Domain Name System (DNS) e software di infrastruttura. |
| Hai esaminato le quote AWS di servizio per la AWS regione e l'account di destinazione? | Ogni AWS servizio ha una quota di servizio. Alcune di queste quote possono essere aumentate. È importante rivedere le quote prima del limite. Se le risorse disponibili sono insufficienti, il cutover potrebbe fallire. | Rivedi il piano di migrazione. Per qualsiasi account di destinazione che richieda una quota di servizio maggiore, richiedi un aumento. Per ulteriori informazioni e istruzioni, consulta le [quote AWS di servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). |
| Devi aggiornare il tuo piano AWS Support? | AWS Il piano di supporto Enterprise offre assistenza telefonica 24 ore su 24, 7 giorni su 7 e tempi di risposta più rapidi rispetto ad altri piani. Poiché la finestra intermedia è in genere molto breve, la possibilità di rivolgersi a un tecnico esperto per risolvere i problemi intermedi può essere fondamentale per il successo di una migrazione su vasta scala. | Contatta il team AWS del tuo account per discutere delle diverse opzioni di supporto e selezionare il piano di supporto appropriato per il tuo progetto di migrazione di grandi dimensioni. |
| Hai informato il tuo AWS Technical Account Manager (TAM) del tuo piano di migrazione su larga scala? | Il team di supporto di AWS Enterprise On-Ramp assegna un pool di Technical Account Manager (TAMs) che coordinano l'accesso a programmi proattivi, programmi preventivi ed esperti in materia. AWS TAMs È possibile pianificare la disponibilità delle risorse di supporto in base alle esigenze. | Informate il vostro account manager AWS tecnico del vostro imminente grande progetto di migrazione e condividete il vostro piano di migrazione. Ti TAMs assicurerai che le risorse di AWS supporto siano disponibili quando necessario. Ad esempio, è TAMs possibile pianificare l'intervento di un tecnico dell'assistenza durante la fase di cutover, che può contribuire a mitigare i problemi tecnici e a semplificare la procedura. |
## Considerazioni relative alla sicurezza
| Ci hai pensato? | Descrizione | Operazioni |
| --- | --- | --- |
| Hai identificato AWS Identity and Access Management (IAM) ruoli e politiche per la gestione degli accessi? | Gestisci l'identità e l'accesso per tutti i membri del tuo grande progetto di migrazione. Associando i ruoli IAM alle risorse migrate e definendo le policy di accesso, controlli chi può accedere alle risorse migrate nel cloud. | Collabora con il team di migrazione per identificare i ruoli e le responsabilità. Determina quali ruoli possono accedere a quale AWS account e identifica il livello di accesso di ciascun ruolo. Collabora con i team di sicurezza per verificare che i ruoli IAM siano corretti per ogni AWS risorsa di destinazione. |
| Esistono requisiti di conformità per i tuoi carichi di lavoro? | I carichi di lavoro potrebbero avere requisiti di conformità diversi, come l'Health Insurance Portability and Accountability Act (HIPAA) o il Data Security Standard (PCI DSS) del settore delle carte di pagamento. È necessario identificare questi requisiti prima della migrazione e pianificare come soddisfarli. | Collabora con il team di conformità e il team di portfolio per identificare i requisiti di conformità per ciascuna applicazione e progetta l' AWS account di destinazione di conseguenza. Ad esempio, potrebbe essere necessario migrare alcuni carichi di lavoro verso AWS GovCloud (US) o verso una regione specifica AWS . Si consiglia di documentare i requisiti di conformità per ciascuna applicazione in modo da poter utilizzare queste informazioni in un secondo momento nel processo di prioritizzazione delle applicazioni e di pianificazione delle ondate. |
| Il vostro team addetto alla sicurezza deve esaminare e approvare gli strumenti o i servizi che intendete utilizzare durante la migrazione? | Un grande progetto di migrazione verso il Cloud AWS utilizza molti servizi, come AWS Application Migration Service, AWS Database Migration Service (AWS DMS) e strumenti di scoperta del portafoglio (come Flexera One). AWS DataSync Alcune organizzazioni richiedono che tutti i nuovi strumenti e servizi siano approvati prima dell'uso. | Collabora con il team addetto alla migrazione per identificare tutti gli strumenti, i servizi e le applicazioni che prevedi di utilizzare nella migrazione. Collabora con il team di sicurezza per rivedere le politiche aziendali e approvare questi strumenti di conseguenza prima dell'inizio della migrazione. |
# Considerazioni locali per una migrazione di grandi dimensioni
L'infrastruttura locale che supporta le operazioni aziendali deve inoltre essere preparata per la migrazione su larga scala. Preparando l'infrastruttura attuale, è possibile contribuire a ridurre l'impatto della migrazione su larga scala sulle operazioni aziendali e sugli utenti delle applicazioni.
Questa sezione esamina le questioni relative all'infrastruttura, alle operazioni e alla sicurezza da considerare durante la preparazione dell'infrastruttura locale per la migrazione su larga scala. Rispondendo alle domande di questa sezione, queste decisioni diventano *principi di migrazione*, che vengono documentati secondo le istruzioni contenute in [Documenta le tue decisioni come principi di migrazione di grandi dimensioni](document.md).
## Considerazioni sull'infrastruttura
| Avete preso in considerazione? | Descrizione | Operazioni |
| --- | --- | --- |
| Hai progettato il DNS e i router locali per supportare il traffico da e verso gli account di destinazione? AWS | A causa dell'elevato numero di server e AWS account di destinazione, è importante confermare che i diversi componenti di rete siano configurati correttamente per supportare le strategie e la scalabilità di migrazione. | Esamina la progettazione delle tabelle di routing e assicurati che vi siano percorsi corretti tra gli AWS account e i data center locali. Inoltre, assicurati che il server DNS sia in grado di supportare le query DNS provenienti sia dai server che dalle risorse locali. AWS |
| In che modo il team di migrazione accederà sia all'ambiente locale che a quello locale? AWS | Il team di migrazione deve accedere ai server di origine e di destinazione per eseguire attività di migrazione, ad esempio installare un agente di replica su un server di origine o disinstallare il vecchio software su un server di destinazione. | Rivedi i meccanismi di autenticazione e autorizzazione esistenti e crea una strategia per concedere l'accesso. Puoi utilizzare un gruppo Active Directory, un ruolo IAM e una federazione Security Assertion Markup Language 2.0 (SAML 2.0) per consentire il single sign-on all'account. AWS Ti consigliamo di creare un utente amministratore locale in caso di problemi di autenticazione con Active Directory. |
| Esistono punti di congestione noti nell'attuale configurazione di rete che potrebbero rallentare la velocità di trasmissione dei dati durante la migrazione? | Una migrazione di grandi dimensioni richiede molta larghezza di banda per replicare i dati dal data center locale al cloud. La comprensione di eventuali punti di congestione o limitazioni esistenti aiuta a pianificare meglio la migrazione. | Rivedi la configurazione di rete con il team di rete per comprendere meglio il percorso di rete dai computer di origine agli AWS account di destinazione. Identifica i potenziali punti di congestione, ad esempio una connessione condivisa tra i carichi di lavoro di migrazione e di produzione. |
## Considerazioni sulle operazioni
| Ci hai pensato? | Descrizione | Operazioni |
| --- | --- | --- |
| Hai dei giorni bloccati programmati, noti anche come *blocchi delle modifiche*, che potrebbero influire sulla migrazione? | Un blocco delle modifiche durante la migrazione può sottrarre risorse e tempo critici a un progetto di migrazione in corso. | Rivedi il processo di gestione delle modifiche con il team operativo e prendi in considerazione i giorni bloccati quando pianifichi le finestre interrotte. |
| Hai riservato giorni di modifica per la migrazione? | I processi di gestione delle modifiche possono essere complessi e alcune organizzazioni consentono modifiche solo in determinate finestre di manutenzione. | In base al processo di gestione delle modifiche, pianifica le modifiche con almeno cinque ondate di anticipo. Questo aiuta a prevenire ritardi |
| Tutti i server oggetto della migrazione sono stati riavviati di recente? | Le modifiche al sistema o le patch disinstallate potrebbero causare problemi durante la migrazione, che richiederebbero lunghe finestre di chiusura o il ripristino del server. La procedura ottimale consiste nel verificare che il server sia stato riavviato di recente sul lato di destinazione prima della migrazione. | Controlla le date degli ultimi riavvii del server. Se un server non è stato riavviato negli ultimi 90 giorni, pianifica un riavvio prima di migrare il server. |
| Come funziona oggi il piano di disaster recovery e business continuity e questo è stato preso in considerazione nella progettazione delle landing zone? | I piani di disaster recovery e business continuity sono componenti fondamentali per il raggiungimento del Recovery Time Objective (RTO) e del Recovery Point Objective (RPO) dell'applicazione. È necessario assicurarsi che questi piani funzionino sia per i carichi di lavoro locali che per i AWS carichi di lavoro durante il periodo di transizione. | Rivedi i piani di disaster recovery e continuità aziendale esistenti e assicurati che funzionino per l'account di destinazione AWS . In caso contrario, progetta nuovi piani prima di spostare il Cloud AWS carico di lavoro su. |
## Considerazioni relative alla sicurezza
| Hai considerato? | Descrizione | Operazioni |
| --- | --- | --- |
| Avete creato regole firewall per supportare la migrazione su larga scala? | A seconda dei processi dell'organizzazione, il completamento di una richiesta di modifica delle configurazioni del firewall può richiedere molto tempo. | Rivedi il processo di modifica del firewall esistente con il team di sicurezza e progetta di conseguenza una strategia per modifiche di migrazione di grandi dimensioni al firewall. Potrebbe essere necessario progettare un processo personalizzato per il grande progetto di migrazione oppure potrebbe essere necessario inviare le modifiche nelle prime fasi del progetto. Si consiglia di prendere in considerazione l'utilizzo di un cloud privato AWS virtuale (VPC) come estensione del data center ed evitare di creare regole firewall troppo complesse, che potrebbero ritardare in modo significativo la migrazione su larga scala. |
| Hai configurato Active Directory nell' AWS ambiente? | Active Directory viene utilizzato per l'autenticazione e l'autorizzazione. È necessario assicurarsi che i carichi di lavoro dell'account di destinazione siano in grado di connettersi al controller di dominio per l'autenticazione e l'autorizzazione. Puoi aggiungere un nuovo controller di dominio nel VPC di destinazione oppure consentire al AWS carico di lavoro di connettersi ai controller di dominio locali. | Rivedi la progettazione di Active Directory con i tuoi team di sicurezza e infrastruttura. Assicurati che l' AWS account di destinazione sia connesso al controller di dominio corretto. Assicurati che i blocchi CIDR della AWS sottorete di destinazione si trovino nei siti Active Directory corretti in modo che i carichi di lavoro in esso contenuti AWS siano in grado di connettersi ai controller di dominio più vicini. |
| Hai identificato connessioni di terze parti e interdipendenze tra applicazioni? | Le connessioni di terze parti e le interdipendenze delle applicazioni richiedono la modifica della regola del firewall, dell'elenco di controllo dell'accesso alla rete e del gruppo di sicurezza. | Durante la sessione di approfondimento con i proprietari delle applicazioni, esamina le dipendenze esterne per ciascuna applicazione. Invia una richiesta per modificare le regole del firewall e l'elenco di controllo degli accessi alla rete e modifica i gruppi di sicurezza di conseguenza, in base ai requisiti di dipendenza di terze parti. |
| L'ambiente locale dispone di strumenti di sicurezza aggiuntivi che controllano l'accesso e i processi in esecuzione sui sistemi, ad esempio? CyberArk | Potrebbe essere necessario valutare e aggiornare questi strumenti di sicurezza per consentire agli strumenti di migrazione di funzionare nella AWS landing zone. | Rivedi la politica di accesso nel tuo ambiente di origine. Se nella politica di accesso viene utilizzato uno strumento di sicurezza, verifica che lo strumento funzioni nell'ambiente di origine e quindi assicurati che il Cloud AWS team addetto alla migrazione abbia accesso sia all'ambiente di origine che a quello di destinazione. Se sono necessarie modifiche, aggiungi questi passaggi nei runbook di migrazione. |
# Documenta i tuoi principi di migrazione
Dopo aver esaminato la landing zone e le considerazioni relative alla sede, dovreste documentare le vostre risposte e le vostre decisioni. Questi diventano i principi di migrazione che guidano il resto del progetto.
Esegui questa operazione:
1. Nei [modelli di playbook di base](samples/foundation-playbook-templates.zip), apri il *modello Principi di migrazione* (formato Microsoft Word).
1. Esamina le considerazioni sull'infrastruttura, le operazioni e la sicurezza nelle sezioni [Considerazioni sulla zona di destinazione per una migrazione di grandi dimensioni](landing-zone.md) e [Considerazioni locali per una migrazione di grandi dimensioni](on-premises.md) di questa guida e discuti le domande con i team consigliati.
1. Documenta le decisioni relative all'infrastruttura, alle operazioni e alla sicurezza nel documento sui principi di migrazione. Per esempi su come registrare queste decisioni, consulta la tabella seguente.
1. Se necessario per il tuo caso d'uso, aggiungi nuove categorie, elementi e principi. Ad esempio, potreste voler registrare i principi di migrazione per la valutazione del portafoglio o le decisioni di gestione dei progetti.
Di seguito è riportato un esempio di come è possibile registrare le decisioni relative ad alcune delle domande di questa guida.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)