Apa perbedaan antara instance Amazon ec2 dan beanstalk?

Saya adalah pengembang solo dan situs yang saya gunakan sangat kecil, biasanya situs hobi dan saya punya beberapa pertanyaan tentang layanan Amazon.

Apakah ada alasan bagi saya untuk menggunakan beanstalk atau haruskah saya tetap menggunakan instance EC2 saja?
Haruskah saya menggunakan RDS untuk basis data? Saya mendengar seseorang mengatakan bahwa saya bisa menginstal database pada contoh EC2 saya, membuatnya lebih murah. Saya mencoba untuk menjaga semuanya semurah mungkin.
Saya perlu mengarahkan domain khusus ke situs saya. Cukup yakin itu berarti saya harus berurusan dengan IP elastis. Apakah itu bekerja dengan beanstalk atau hanya dengan instance EC2 individu?

Terima kasih sebelumnya!

— Chev
sumber

Anda dapat menganggap AWS Elastic Beanstalk sebagai semacam versi otomatis EC2 - artinya, ia menggunakan EC2 di backend untuk server, tetapi Anda tidak perlu khawatir tentang penyediaan server secara manual, memperluas server ketika Anda menekan kapasitas , dan seterusnya. Pada dasarnya, Anda memberikan Beanstalk aplikasi Anda dan itu akan "skala" untuk Anda. Bahkan, Anda tidak dikenai biaya untuk Beanstalk sendiri - Anda akan dikenai biaya untuk sumber daya AWS yang Anda gunakan, seperti S3, SNS, dan EC2.

Jadi untuk menjawab pertanyaan Anda:

Jika Anda ingin kontrol atas penskalaan dan kontrol sumber daya, EC2 adalah apa yang Anda inginkan - tetapi perlu diingat, ini mengarah pada banyak pekerjaan administratif, dan jika Anda tidak terbiasa dengan konsep yang ada, Anda mungkin akan sedikit tersesat. . Plus, itu mungkin tidak sepadan dengan waktu dan upaya untuk melakukannya. Beanstalk memberi Anda skalabilitas tanpa manajemen mikro.
Mesin virtual Micro RDS mulai dari $ 0,025 per jam , sedangkan mesin kecil EC2 mulai dari $ 0,020 per jam . Namun, layanan RDS menyediakan beberapa fitur yang bermanfaat , seperti penskalaan otomatis, cadangan otomatis, pengoptimalan basis data, dan sebagainya. Ini benar-benar terserah Anda jika Anda mau atau tidak. Anda harus menjalankan angka sendiri dan memutuskan berapa banyak waktu yang ingin Anda habiskan berurusan dengan DB.
Anda hampir pasti perlu menggunakan penyedia DNS untuk menyiapkan CNAME di domain Anda. Secara kebetulan, ada layanan AWS - Rute 53 - yang melakukan ini. IIRC, ada juga beberapa layanan pihak ketiga yang dapat menjembatani kesenjangan ini untuk Anda.

Semoga ini membantu!

— Andrew M.
sumber

Sempurna. Persis apa yang saya cari. Penjelasan yang sangat bagus. Bahkan, pada saat sejak mengajukan pertanyaan dan melihat jawaban Anda, saya telah menemukan dan mengatur rute 53. Sepertinya itu adalah pilihan terbaik karena ia dapat secara dinamis mengembalikan IP yang tepat yang ditugaskan ke situs saya dan yang lainnya. Satu-satunya hal yang saya khawatirkan adalah memungut biaya dengan hal-hal database. Apakah ".025 / jam" berarti per jam bahwa layanannya ada di atas sana atau per jam sehingga menghabiskan waktu CPU karena aktivitas situs web?

— Chev

Untuk database bukankah itu sebenarnya $ 0,020 per jam untuk contoh tetapi $ 0,045 per jam untuk RDS karena saya juga akan membuat instance berjalan juga?

— Chev

Jika Anda menggabungkan hosting web Anda dengan hosting database Anda, ya. Seperti yang saya katakan - ini sangat tergantung pada apa yang Anda lakukan. Saya juga menyarankan Anda melihat beberapa penyedia VPS - saya pikir Anda akan menemukan mereka dapat memberi Anda pengembalian yang jauh lebih baik, dan Anda tidak perlu khawatir tentang banyak infrastruktur.

— Andrew M.

Saya telah melakukan itu, tetapi saya mencoba untuk menjaga biaya saya sangat rendah, seperti $ 15 / bln atau lebih murah. Menjalankan VPS penuh tampaknya berjalan sekitar $ 60 atau lebih.

— Chev

Bagaimana dengan shared hosting? Sebagai contoh, saya dan beberapa teman saya menggunakan DreamHost (tidak menganjurkan penggunaannya, hanya memberikan contoh), yang menawarkan hosting dasar seharga $ 9 per bulan, dengan VPS mulai dari $ 15. Karena tidak terdengar seperti ini intensif, Anda dapat mempertimbangkan sesuatu seperti ini.

— Andrew M.