As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Arquitetura de referência A [arquitetura de AWS referência Hosting WordPress on](https://github.com/awslabs/aws-refarch-wordpress), disponível em, GitHub descreve as melhores práticas para implantação WordPress AWS e inclui um conjunto de AWS CloudFormation modelos para que você comece a trabalhar rapidamente. A arquitetura a seguir é baseada nessa arquitetura de referência. O restante desta seção analisará os motivos por trás das escolhas arquitetônicas. A base AMI no GitHub foi alterada de Amazon Linux1 para Amazon Linux2 em julho de 2021. No entanto, os modelos de implantação no S3 ainda não foram alterados. É recomendável usar modelos em GitHub se houver um problema para implantar a arquitetura de referência com modelos no S3. ![Arquitetura de referência para hospedagem WordPress em AWS](http://docs.aws.amazon.com/pt_br/whitepapers/latest/best-practices-wordpress/images/image4.png) *Arquitetura de referência para hospedagem WordPress em AWS* **Componentes da arquitetura** A arquitetura de referência ilustra uma implementação completa de melhores práticas para um WordPress site emAWS. + Tudo começa com o cache de borda na **Amazon CloudFront** (1) para armazenar o conteúdo em cache perto dos usuários finais para uma **** entrega mais rápida. + CloudFront extrai conteúdo estático de um **bucket do S3** (2) e conteúdo dinâmico de um **Application Load** Balancer (4) na frente das instâncias da web. + As instâncias da web são executadas em um **grupo Auto Scaling de EC2** **instâncias** **da Amazon** (6). + Um ** ElastiCache **cluster (7) armazena em cache os dados consultados com frequência para **** acelerar as respostas. Uma SQL instância **do Amazon Aurora** My (8) hospeda o WordPress banco de dados. + As WordPress EC2 instâncias acessam WordPress dados compartilhados em um sistema de EFS arquivos **da Amazon** por meio de um **EFSMount Target** (9) em cada zona de disponibilidade. + Um **Internet Gateway** (3) permite a comunicação entre seus recursos VPC e a Internet. + **NATOs gateways** (5) em cada zona de disponibilidade permitem que EC2 instâncias em sub-redes privadas (aplicativo e dados) acessem a Internet. ****Na **Amazon**, VPC existem dois tipos de sub-redes: pública (sub-rede pública) e privada (**sub-rede** do **aplicativo e sub-rede** de dados).**** Os recursos implantados nas sub-redes públicas receberão um endereço IP público e ficarão visíveis publicamente na Internet. O **Application Load Balancer** (4) e um host Bastion para administração são implantados aqui. Os recursos implantados nas sub-redes privadas recebem somente um endereço IP privado e, portanto, não são visíveis publicamente na Internet, melhorando a segurança desses recursos. As **instâncias do servidor WordPress ** **web** (6), as **instâncias ElastiCache do cluster** (7), as **instâncias do Aurora My SQL Database** (8) e o **EFSMount Targets** (9) são todas implantadas em sub-redes privadas. O restante desta seção aborda cada uma dessas considerações com mais detalhes.