Arsitektur referensi - Praktik Terbaik WordPress untuk AWS

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Arsitektur referensi

Hosting WordPress pada arsitektur AWS referensi tersedia di GitHub menguraikan praktik terbaik untuk menerapkan WordPress AWS dan menyertakan serangkaian AWS CloudFormation templat untuk membuat Anda siap dan berjalan dengan cepat. Arsitektur berikut didasarkan pada arsitektur referensi itu. Sisa bagian ini akan meninjau alasan di balik pilihan arsitektur.

Berbasis AMI di GitHub diubah dari Amazon Linux1 menjadi Amazon Linux2 pada Juli 2021. Namun, templat penerapan di S3 belum diubah. Disarankan untuk menggunakan template di GitHub jika ada masalah untuk menyebarkan arsitektur referensi dengan template di S3.

Arsitektur referensi untuk hosting WordPress di AWS

Arsitektur referensi untuk hosting WordPress di AWS

Komponen arsitektur

Arsitektur referensi menggambarkan penerapan praktik terbaik yang lengkap untuk WordPress situs web. AWS

  • Dimulai dengan edge caching di Amazon CloudFront (1) untuk menyimpan konten yang dekat dengan pengguna akhir untuk pengiriman yang lebih cepat.

  • CloudFront menarik konten statis dari bucket S3 (2) dan konten dinamis dari Application Load Balancer (4) di depan instance web.

  • Instans web berjalan dalam grup Auto Scaling dari instans EC2Amazon (6).

  • ElastiCache Cluster (7) menyimpan data yang sering ditanyakan untuk mempercepat respons.

    Amazon Aurora My SQL instance (8) menghosting database. WordPress

  • WordPress EC2Instans mengakses WordPress data bersama pada sistem EFS file Amazon melalui Target EFS Mount (9) di setiap Availability Zone.

  • Internet Gateway (3) memungkinkan komunikasi antara sumber daya di Anda VPC dan internet.

  • NATGateway (5) di setiap Availability Zone memungkinkan EC2 instance di subnet pribadi (Aplikasi dan Data) untuk mengakses internet.

Di Amazon VPC ada dua jenis subnet: publik (Public Subnet) dan Private (App Subnet dan Data Subnet). Sumber daya yang digunakan ke subnet publik akan menerima alamat IP publik dan akan terlihat publik di internet. Application Load Balancer (4) dan host Bastion untuk administrasi digunakan di sini. Sumber daya yang digunakan ke subnet pribadi hanya menerima alamat IP pribadi dan karenanya tidak terlihat oleh publik di internet, meningkatkan keamanan sumber daya tersebut. Instance server WordPress web (6), instance ElastiCache cluster (7), instance SQL database Aurora My (8), dan EFSMount Targets (9) semuanya digunakan dalam subnet pribadi.

Sisa bagian ini mencakup masing-masing pertimbangan ini secara lebih rinci.