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à. # Architettura di riferimento L'[architettura di AWS riferimento Hosting WordPress on](https://github.com/awslabs/aws-refarch-wordpress), disponibile su, GitHub delinea le migliori pratiche per l'implementazione WordPress AWS e include una serie di AWS CloudFormation modelli per renderti operativo rapidamente. La seguente architettura si basa su tale architettura di riferimento. Il resto di questa sezione esaminerà i motivi alla base delle scelte architettoniche. Il based AMI in the GitHub è stato modificato da Amazon Linux1 ad Amazon Linux2 nel luglio 2021. Tuttavia, i modelli di distribuzione in S3 non sono ancora stati modificati. Si consiglia di utilizzare i modelli in GitHub caso di problemi per distribuire l'architettura di riferimento con i modelli in S3. ![Architettura di riferimento per l'hosting su WordPress AWS](http://docs.aws.amazon.com/it_it/whitepapers/latest/best-practices-wordpress/images/image4.png) *Architettura di riferimento per l'hosting WordPress su AWS* **Componenti dell'architettura** L'architettura di riferimento illustra un'implementazione completa delle migliori pratiche per un WordPress sito Web suAWS. + Inizia con l'edge caching in **Amazon CloudFront** (1) per memorizzare i contenuti vicino agli utenti finali per una **** distribuzione più rapida. + CloudFront estrae il contenuto statico da un **bucket S3** (2) e il contenuto dinamico da un **Application Load Balancer** (4) davanti alle istanze web. + Le istanze Web vengono eseguite in un gruppo **Auto Scaling** di istanze **EC2**Amazon**** (6). + Un ** ElastiCache **cluster (7) memorizza nella cache i dati richiesti di frequente per velocizzare le risposte. **** Un'SQListanza **Amazon Aurora** My (8) ospita il WordPress database. + Le WordPress EC2 istanze accedono ai WordPress dati condivisi su un EFS file system **Amazon** tramite un **EFSMount Target** (9) in ciascuna zona di disponibilità. + Un **Internet Gateway** (3) consente la comunicazione tra le risorse dell'utente VPC e Internet. + **NATI gateway** (5) in ciascuna zona di disponibilità consentono EC2 alle istanze in sottoreti private (app e dati) di accedere a Internet. **All'interno di **Amazon VPC** esistono due tipi di sottoreti: pubbliche (**Public** **Subnet**) e private (**App Subnet e Data Subnet**).** Le risorse distribuite nelle sottoreti pubbliche riceveranno un indirizzo IP pubblico e saranno visibili pubblicamente su Internet. L'**Application Load Balancer** (4) e un host Bastion per l'amministrazione vengono implementati qui. Le risorse distribuite nelle sottoreti private ricevono solo un indirizzo IP privato e quindi non sono visibili pubblicamente su Internet, il che migliora la sicurezza di tali risorse. Le **istanze del server WordPress ** **Web** (6), le **istanze ElastiCache cluster** (7), le **istanze Aurora My SQL database** (8) e **EFSMount Targets** (9) sono tutte distribuite in sottoreti private. La parte restante di questa sezione tratta ognuna di queste considerazioni in modo più dettagliato.