Architecting on AWS (Membangun Arsitektur Cloud di AWS)_1

 

Pengantar ke Architecting on AWS

Halo, pecinta AWS! Dengan mengikuti kelas ini, Anda berarti sudah paham atau bahkan menguasai dasar-dasar AWS Cloud.

Dari nama kelasnya, tentu sudah jelas bahwa kelas ini akan membahas cara membangun arsitektur di AWS. Itu berarti, diharapkan Anda sudah pernah berinteraksi dengan layanan-layanan cloud, men-deploy aplikasi sederhana, atau sekadar meng-hosting website statis.

Di kelas ini juga akan sedikit bersinggungan dengan istilah-istilah pada pengembangan software. Maka dari itu, pahamilah terlebih dahulu materi tentang SDLC alias Software Development Life Cycle. 

Tentu bagi Anda yang sudah pernah mengembangkan produk dalam suatu tim/perusahaan tak akan kaget mendengar kata itu. SDLC adalah sebuah proses yang dapat membantu dalam mengembangkan perangkat lunak yang berkualitas, teruji, hemat waktu, hemat biaya, dan juga sesuai dengan apa yang pelanggan harapkan. SDLC terdiri dari 7 fase, yaitu:

• Planning (Perencanaan) 
• Requirement Analysis (Analisis kebutuhan) 
• Design & Prototyping (Perancangan dan Pembuatan Prototipe) 
• Development (Pengembangan) 
• Testing (Pengujian) 
• Deployment (Penggelaran) 
• Maintenance (Pemeliharaan)

Oke, sekarang Anda sudah paham dengan SDLC. Pertanyaannya, saat mengembangkan sebuah aplikasi, apakah Anda memperhatikan beberapa hal seperti scaling, cost optimization, atau bahkan serverless? Atau jangan-jangan, Anda mengembangkannya dengan arsitektur yang asal-asalan tanpa memedulikan hal-hal tersebut?

Nah, maka dari itu, ikuti setiap materi di kelas ini agar Anda dapat menguasai dan paham cara membangun arsitektur yang andal, aman, dan optimal, baik untuk arsitektur yang sederhana maupun berskala besar. 

Di sinilah kita berada. Selamat datang di modul pengantar dari kelas Architecting on AWS. Di modul ini kita akan berdiskusi mengenai hal-hal berikut:

• Apa itu AWS?
• AWS Well-Architected Framework
• Prinsip desain umum untuk cloud
• Desain arsitektur berskala besar

Penasaran seperti apa pembahasannya? Mari kita mulai!

Skenario

Sebelum masuk ke pembahasan, mari kita buat suatu skenario yang kontinu pada kelas ini. Katakanlah Anda dan beberapa kawan memiliki rencana besar untuk memulai startup. Startup ini nantinya akan bergerak di bidang penjualan kopi dan akan menjadi yang terbaik di dunia.

Rencananya, Anda dan tim akan gencar melakukan promosi, ekspansi, dan lain sebagainya agar startup ini berkembang. Anda pun sepakat bahwa untuk mewujudkannya pasti diperlukan sistem IT yang fleksibel, agile, dan mampu berkembang mengikuti perjalanan bisnis yang tentunya akan naik-turun seperti roller coaster.

Anda dan tim setuju bahwa menjalankan bisnis secara offline saat ini tidaklah cukup. Selain offline, perlu ada peranan IT yang mendukung bisnis agar dapat lebih berkembang pesat. Namun, sistem IT seperti apa yang cocok untuk start-up ya?

Jawabannya adalah dengan menggunakan cloud. Dengan begitu, disepakati juga bahwa sebaiknya Anda dan tim perlu memiliki dasar pemahaman yang baik mengenai cloud dengan mengikuti kelas Architecting on AWS. 

Nah, kalau begitu, tunggu apa lagi? Simak pembahasan lebih lanjut di modul berikutnya!

Pengenalan AWS

Sebelum membahas lebih jauh mengenai arsitektur cloud lebih dalam, mari kita berkenalan dulu dengan AWS.

AWS atau Amazon Web Services lahir dari pengalaman Amazon.com dalam membuat e-commerce. Amazon didirikan oleh Jeff Bezos di Bellevue, Amerika Serikat pada tahun 1994. Dalam perkembangannya, sekitar tahun 2000, Amazon.com mulai mengalami kesulitan dalam hal keandalan sistem (highly available) dan skalabilitas.

Dari sisi tool e-commerce, bisa dibilang mirip benang kusut. Aplikasi dan arsitektur dibangun tanpa perencanaan yang baik. Untuk membangun database, perlu waktu hampir 3 bulan lamanya. Bahkan, setiap tim membangun sendiri sumber dayanya tanpa berdiskusi terlebih dahulu dengan tim lain untuk kemungkinan penggunaan ulang. Keadaan ini mungkin dapat diilustrasikan seperti gambar berikut:

Nah, berkaca dari keadaan yang semrawut serta pengalaman yang menyakitkan tersebut, Amazon.com akhirnya berhasil diredefinisi ulang oleh tim internal perusahaan dengan sistem yang lebih reliable, scalable, dan highly available. 

Dari pengalaman membangun ulang tersebut, akhirnya pada tahun 2006 Amazon.com bangkit dan menjual layanan-layanannya secara terpisah sebagai Amazon Web Services.

AWS Well-Architected Framework

Seperti yang telah diuraikan pada awal modul, kita harus membangun arsitektur yang andal, aman, dan optimal. Begitu juga saat membangun arsitektur untuk startup warung kopi kita. Kita memerlukan suatu acuan atau best practice (praktik terbaik) sebagai referensi dan pembanding untuk arsitektur yang kita bangun. 

Tanpa adanya best practice tersebut, mungkin saat membuat dan menjalankan aplikasi di cloud, Anda sering bertanya-tanya, “Apakah yang saya lakukan ini sudah benar?”

Nah, untuk menjawab pertanyaan ini, AWS telah membuat Well-Architected Framework, yaitu sebuah dokumen hidup (living document) yang pertama kali dikeluarkan pada tahun 2015. Pada saat modul pengantar ini dibuat, AWS Well-Architected Framework yang terbaru rilis pada bulan Juli 2020.

Catat! Karena teknologi selalu berkembang, AWS Well-Architected Framework juga akan terus diperbaharui. Maka dari itu, ada baiknya Anda senantiasa memeriksa dokumen terbaru di laman web AWS, terutama jika ada pembuatan aplikasi yang membutuhkan fitur baru dari AWS.

AWS Well-Architected Framework awalnya dibuat dalam bentuk whitepaper, yakni buku panduan yang dapat diakses secara online. Tetapi seiring dengan perkembangannya, AWS Well-Architected Framework juga diperkaya dengan hands-on labs dan juga AWS Well-Architected Tools. Kita akan belajar lebih jauh mengenai hal-hal tersebut dalam modul ini.

AWS Well-Architected Framework memiliki lima pilar utama yang dijadikan sebagai fondasi dasar dalam membangun cloud. Selain itu, AWS Well-Architected Framework juga memiliki beberapa prinsip desain umum untuk Cloud, mari kita bahas terlebih dahulu prinsip-prinsip tersebut.

Prinsip Desain Umum untuk Cloud

AWS Well-Architected Framework menyarankan prinsip-prinsip di bawah ini untuk memfasilitasi desain yang baik untuk cloud:

• Berhenti memperkirakan kebutuhan kapasitas
  Cloud Computing menerapkan prinsip skalabilitas, yakni kita tidak perlu lagi mengestimasi atau memperkirakan kebutuhan kapasitas.
  
  Jadi, pada saat membuat desain untuk cloud--terutama AWS--kita bisa mulai dengan kapasitas seminim mungkin, lalu menambah ataupun mengurangi kapasitas sesuai kebutuhan.
  
  

• Tes sistem pada spesifikasi yang sama dengan production
  Di cloud, kita bisa membuat lingkungan testing pada spesifikasi yang sama dengan production. Setelah testing selesai, Anda bisa menonaktifkan atau bahkan menghapus lingkungan testing tersebut.
  
  

• Gunakan automasi untuk memudahkan dalam berinovasi
  Dengan automasi, kita dapat membuat dan mereplikasi sistem dengan biaya murah dan waktu yang cepat. Selain itu, kita bisa mencatat perubahan yang ada, mengaudit dampaknya, dan mengembalikan kondisi sistem ke parameter sebelumnya jika diperlukan. Sehingga dalam melakukan inovasi akan lebih cepat mudah dan murah.
  
  

• Arsitektur yang memungkinkan perubahan secara evolusioner
  Cloud memungkinkan kita untuk melakukan automasi dan testing sesuai keperluan. Hal ini sangat membantu dalam meminimalisir risiko akibat perubahan dari sisi desain. Seiring dengan perkembangan dan perubahan bisnis perusahaan, IT juga sebaiknya memiliki kemampuan untuk mengakomodasi perubahan tersebut.
  
  Bahkan, cloud juga memungkinkan sistem kita untuk berkembang dan mengadopsi hal-hal baru yang inovatif dan dapat memberikan kontribusi nyata terhadap perkembangan bisnis.
  
  

• Gunakan data sebagai dasar dari arsitektur aplikasi
  Cloud memungkinkan kita untuk mengumpulkan data yang menunjukkan bagaimana dampak dari perubahan terhadap arsitektur aplikasi yang kita buat. Artinya, saat ingin membuat perbaikan, kita dapat membuat keputusan berdasarkan fakta.
  
  Karena infrastruktur dari aplikasi kita berbentuk code, maka kita dapat membuat perubahan dari sisi arsitektur dan infrastruktur secara berkala dengan lebih mudah daripada on-premise.
  
  

• Tes arsitektur secara berkala
  Tes arsitektur dan sistem Anda secara berkala dengan melakukan simulasi terhadap hal-hal yang mungkin terjadi di production. Ini bertujuan untuk membantu Anda dalam mengidentifikasi kelemahan yang dapat diperbaiki serta menghindari hal-hal yang tidak diinginkan terjadi pada perusahaan Anda.

Lima Pilar AWS Well-Architected Framework

Tahukah Anda? Membuat sistem aplikasi sebenarnya hampir mirip dengan membangun sebuah gedung. Jika fondasi tidak dibangun dengan baik dan kuat, maka integritas struktur gedung akan terganggu. Bila itu terjadi, seiring berjalannya waktu besar kemungkinan gedung akan runtuh.

Sistem atau aplikasi pun demikian. Jika aplikasi yang Anda desain di AWS mengabaikan kelima pilar dari AWS Well-Architected Framework, besar kemungkinan aplikasi Anda akan sulit memenuhi tuntutan atau kebutuhan pengguna yang terus berkembang. 

AWS Well-Architected Framework saat ini dibangun di atas 5 pilar seperti pada gambar di bawah ini.

Kita akan bahas lebih lanjut mengenai kelima pilar di atas pada materi selanjutnya. Keep the spirit up!

Operational Excellence

Pilar ini membahas tentang kemampuan untuk mengoperasikan dan memonitor sistem demi memberikan nilai tambah bagi perusahaan serta menyempurnakan proses dan prosedur secara terus-menerus. 

Operational Excellence dilakukan sejak awal dan dilanjutkan secara terus-menerus sesuai perkembangan bisnis yang juga dinamis. Hal ini terutama ditunjukkan pada tiga hal di bawah ini, yaitu:

• Menyelaraskan proses operasi dengan tujuan bisnis.
• Membuat perubahan yang teratur, kecil, dan bertahap.
• Belajar dari kejadian dan kegagalan operasional.

Berikut penjelasan detail dari prinsip pada pilar Operational Excellence:

• Gunakan kode untuk menjalankan operasi
  Di cloud, Anda bisa menerapkan disiplin teknik yang sama--yakni menggunakan code--dalam menjalankan operasinya. Anda dapat menentukan dan memperbaharui seluruh workload (beban kerja) infrastruktur maupun aplikasi melalui kode.
  
  Dengan menggunakan kode dalam menjalankan operasi, Anda dapat mengautomasi operasi untuk dieksekusi berdasarkan sebuah event (peristiwa). Hal ini tentu akan meminimalisir terjadinya human error [1].
  
  

• Buatlah pembaruan yang sering, kecil, dan dapat diubah
  Rancanglah workload (beban kerja) yang dapat menerima pembaruan komponen secara teratur. Lakukan pembaruan sedikit demi sedikit dan pastikan pembaruannya dapat dibatalkan jika gagal (tanpa mengganggu jalannya operasional jika dimungkinkan).
  
  

• Sering-seringlah memperbarui prosedur operasi
  Lakukan pembaruan pada prosedur operasi seiring dengan mengembangkan beban kerja Anda. Luangkan waktu untuk meninjau dan memvalidasi bahwa semua prosedur sudah efektif serta dipahami dan digunakan oleh tim terkait.
  
  

• Mengantisipasi kegagalan
  Lakukan latihan “pra-mortem” untuk mengidentifikasi potensi sumber kegagalan sehingga dapat disingkirkan atau dikurangi.
  
  Uji skenario kegagalan Anda dan validasikan dampaknya. Lalu, ujilah response procedure (prosedur tanggapan) Anda untuk memastikan apakah sistem berjalan efektif? Apakah tim Anda terbiasa dengan pelaksanaannya? Selain itu, siapkan juga Game Day untuk menguji beban kerja dan respons tim terhadap simulasi event.
  
  

• Belajar dari semua kegagalan operasional
  Tingkatkan sistem Anda melalui pembelajaran yang dipetik dari semua kejadian dan kegagalan operasional. Bagikan apa yang dipelajari di tim Anda ke seluruh organisasi.
  
  

Jadi, pilar Operational Excellence ini memberikan prinsip desain, praktik terbaik, dan kumpulan pertanyaan terkait desain. Untuk petunjuk implementasi secara lebih mendetail, Anda bisa menemukannya di whitepaper untuk pilar Operational Excellence di tautan berikut ini Operational Excellence Pillar - AWS Well-Architected Framework.

Security

Pilar Security (Keamanan) mencakup mengenai bagaimana melindungi informasi dan memitigasi kerusakan atau kerugian. Arsitektur Anda akan memiliki perlindungan yang jauh lebih baik dengan mengimplementasikan langkah-langkah keamanan dasar, misalnya mengaktifkan traceability (keterlacakan), mengaplikasikan keamanan di seluruh lapisan, mengotomatiskan praktik terbaik keamanan, dan melindungi data baik in-transit maupun at rest.

Berikut penjelasan detail prinsip desain pada pilar Security:

• Terapkan fondasi identitas yang kuat
  Terapkan prinsip least privilege (hak akses secukupnya/sesuai kebutuhan) dan pemisahan tugas dengan otorisasi yang sesuai untuk setiap interaksi dengan sumber daya AWS Anda. Selain itu, Anda juga perlu memusatkan manajemen identitas yang bertujuan untuk menghilangkan ketergantungan pada kredensial statis jangka panjang.
  
  

• Aktifkan keterlacakan (Enabling traceability)
  Pantau, beri peringatan, serta audit tindakan dan perubahan pada lingkungan Anda secara real time. Integrasikan pengumpulan log dan metrik dengan sistem untuk menyelidiki sekaligus mengambil tindakan secara otomatis.
  
  

• Terapkan keamanan pada semua lapisan
  Terapkan pendekatan pertahanan yang mendalam dengan beberapa kontrol keamanan untuk semua lapisan, seperti edge network, VPC, load balancing, semua instance dan layanan komputasi, sistem operasi, aplikasi, dan kode.
  
  

• Otomatiskan praktik terbaik untuk keamanan
  Mekanisme keamanan berbasis perangkat lunak dapat secara otomatis meningkatkan kemampuan Anda untuk meningkatkan skala secara aman, lebih cepat, dan hemat biaya.
  
  Buatlah arsitektur yang aman, termasuk penerapan kontrol yang ditentukan dan dikelola sebagai kode dalam template yang menggunakan version control.
  
  

• Lindungi data in-transit dan at rest
  Klasifikasikan data Anda ke dalam tingkat sensitivitas dan mekanisme penggunaan, seperti enkripsi, tokenisasi, dan kontrol akses jika sesuai.
  
  

• Jauhkan orang dari data
  Gunakan mekanisme dan alat untuk mengurangi atau meniadakan kebutuhan akan akses langsung atau pemrosesan data secara manual. Dengan begitu, Anda dapat mengurangi risiko kesalahan penanganan, modifikasi, dan human error saat berurusan dengan data sensitif.
  
  

• Persiapkan diri Anda untuk insiden keamanan
  Anda perlu bersiap untuk suatu insiden keamanan dengan memiliki manajemen insiden dan kebijakan serta proses investigasi yang sejalan dengan kebutuhan organisasi Anda.
  
  Jalankan simulasi respons insiden dan gunakan alat dengan automasi untuk meningkatkan kecepatan deteksi, investigasi, dan pemulihan Anda.
  
  

Untuk petunjuk implementasi secara lebih mendetail, Anda bisa menemukannya di whitepaper untuk pilar Security di tautan berikut ini Security Pillar - AWS Well-Architected Framework.

Reliability

Pilar reliability membicarakan tentang kemampuan sebuah sistem untuk pulih dari gangguan, secara dinamis memperoleh dan mengalokasi sumber daya komputasi demi memenuhi permintaan, dan memitigasi gangguan seperti kesalahan konfigurasi atau gangguan lain yang sifatnya temporer.

Tahukah Anda? Tidaklah mudah untuk memastikan keandalan sebuah sistem di lingkungan data center tradisional. Masalah bisa saja terjadi dari mana saja, seperti tidak adanya redundancy di sistem kita, tak hadirnya automasi, dan tiadanya elastisitas. 

Dengan mengaplikasikan prinsip-prinsip dari pilar Reliability, kita bisa mencegah munculnya masalah-masalah di atas. Maka dari itu, desainlah arsitektur sistem Anda dengan memperhatikan hal-hal seperti High-Availability, Fault Tolerance, dan Redundancy.

Ada 5 prinsip desain untuk mencapai reliability/keandalan di cloud:

• Pemulihan otomatis ketika terjadi kegagalan
  Pantaulah beban kerja (workload) Anda agar sesuai dengan KPI (Key Performance Indicator). Anda dapat men-trigger automasi saat ambang batas terlewati. KPI ini harus menjadi ukuran nilai bisnis, bukan aspek teknis pengoperasian layanan.
  
  Ini memungkinkan Anda mendapatkan pemberitahuan secara otomatis dan melacak kegagalan untuk proses pemulihan otomatis serta perbaikan kegagalan.
  
  Bahkan dengan automasi yang lebih canggih, Anda dapat mengantisipasi dan memulihkan kegagalan sebelum terjadi.
  
  

• Uji prosedur pemulihan
  Di lingkungan on-premise, pengujian sering dilakukan untuk membuktikan beban kerja berfungsi dalam skenario tertentu. Dan biasanya, pengujian tidak digunakan untuk memvalidasi strategi pemulihan.
  
  Sedangkan di cloud, Anda dapat menguji bagaimana kegagalan bisa terjadi pada beban kerja serta memvalidasi prosedur pemulihan yang Anda buat. Anda juga dapat menggunakan automasi untuk mensimulasikan berbagai kegagalan atau membuat ulang skenario yang menyebabkan kegagalan sebelumnya.
  
  Pendekatan ini memperlihatkan alur kegagalan yang dapat Anda uji dan perbaiki sebelum skenario kegagalan sesungguhnya terjadi sehingga dapat mengurangi risiko.
  
  

• Lakukan horizontal scaling untuk meningkatkan ketersediaan beban kerja
  Gantilah satu sumber daya besar dengan beberapa sumber daya kecil guna mengurangi dampak kegagalan tunggal pada keseluruhan beban kerja. Distribusikan permintaan di beberapa sumber daya yang lebih kecil untuk memastikan permintaan tersebut tidak memiliki titik kegagalan yang sama.
  
  

• Berhenti memperkirakan kebutuhan kapasitas
  Penyebab umum terjadinya kegagalan dalam beban kerja di on-premise adalah resource saturation (kejenuhan sumber daya), yakni saat permintaan yang ditempatkan pada beban kerja melebihi kapasitas beban kerja tersebut (ini sering kali menjadi tujuan serangan denial of service alias DoS).
  
  Di cloud, Anda dapat memantau permintaan dan pemanfaatan beban kerja, serta mengotomatiskan penambahan atau penghapusan resource. Dengan begitu, Anda dapat mempertahankan tingkat optimal guna memenuhi permintaan tanpa kelebihan atau kekurangan penyediaan. Meski masih ada batasan, tetapi beberapa kuota dapat dikontrol dan dikelola.
  
  

• Kelola perubahan menggunakan automasi
  Perubahan pada infrastruktur Anda harus dilakukan menggunakan automasi. Perubahan yang perlu dikelola termasuk perubahan otomatisasi yang nantinya dapat dilacak dan ditinjau.

Untuk petunjuk implementasi secara lebih mendetail, Anda bisa menemukannya di whitepaper untuk pilar Reliability di tautan berikut ini Reliability Pillar - AWS Well-Architected Framework.

Performance Efficiency

Pilar Performance Efficiency (Efisiensi Kinerja) mencakup kemampuan untuk menggunakan sumber daya komputasi secara efisien guna memenuhi persyaratan sistem. Dan ia juga mempertahankan efisiensi tersebut seiring dengan perubahan permintaan dan perkembangan teknologi.

Ada 5 prinsip desain untuk pilar performance efficiency di cloud:

• Demokratisasi teknologi canggih
  Permudah penerapan teknologi canggih untuk tim Anda dengan mendelegasikan tugas kompleks ke vendor cloud. Daripada meminta tim IT Anda untuk mempelajari tentang hosting dan menjalankan teknologi baru, pertimbangkanlah untuk menggunakan technology as a service (teknologi sebagai layanan). Misalnya, database NoSQL, transcoding media, dan machine learning.
  
  Semua teknologi di atas tentunya membutuhkan keahlian khusus. Nah, di cloud, teknologi tersebut adalah layanan yang dapat digunakan oleh tim Anda. Dengan begitu, tim Anda bisa fokus pada pengembangan produk daripada penyediaan dan pengelolaan resource.
  
  

• Mendunia dalam hitungan menit
  Terapkan beban kerja Anda di beberapa AWS Regions yang tersedia di seluruh dunia sehingga akan memberikan latensi yang lebih rendah dan pengalaman penggunaan yang lebih baik untuk pelanggan Anda dengan biaya minimal.
  
  

• Gunakan arsitektur serverless
  Arsitektur serverless (tanpa server) dapat menghilangkan kebutuhan Anda untuk menjalankan dan memelihara server fisik pada aktivitas komputasi tradisional.
  
  Misalnya, layanan penyimpanan serverless dapat bertindak sebagai situs web statis (menghilangkan kebutuhan akan server web) dan layanan event yang dapat meng-hosting kode. Ini menghilangkan beban operasional dalam mengelola server fisik dan dapat menurunkan biaya transaksional karena layanan terkelola beroperasi pada skala cloud.
  
  

• Bereksperimenlah lebih sering
  Dengan sumber daya virtual dan otomatis, Anda dapat dengan cepat melakukan pengujian komparatif menggunakan berbagai tipe instance, penyimpanan, atau konfigurasi.
  
  

• Gunakan teknologi yang tepat
  Pahami bagaimana layanan cloud dikonsumsi dan gunakan selalu pendekatan teknologi yang paling sesuai dengan sasaran beban kerja Anda. Misalnya, pertimbangkan pola akses data saat Anda memilih pendekatan database atau penyimpanan.

Untuk petunjuk implementasi secara lebih mendetail, Anda bisa menemukannya di whitepaper untuk pilar Performance Efficiency di tautan berikut ini Performance Efficiency Pillar - AWS Well-Architected Framework.

Cost Optimization

Cost Optimization (Optimalisasi biaya) merupakan persyaratan berkelanjutan dari setiap desain arsitektur yang baik. Prosesnya berulang dan harus disempurnakan serta ditingkatkan selama masa produksi. 

Pahamilah seberapa efisien arsitektur Anda saat ini agar dapat membantu menghilangkan biaya yang tidak diperlukan. Pertimbangkan juga untuk menggunakan layanan terkelola (managed service) yang beroperasi pada skala cloud. Layanan tersebut dapat menawarkan biaya per transaksi atau layanan yang lebih rendah.

Ada 5 prinsip desain untuk pilar Cost Optimization di cloud:

• Terapkan Cloud Financial Management
  Untuk mencapai kesuksesan finansial dan mempercepat realisasi nilai bisnis di cloud, Anda perlu berinvestasi dalam Cloud Financial Management / Cost Optimization. Organisasi Anda perlu mendedikasikan waktu dan sumber daya untuk membangun kemampuan dalam domain baru teknologi dan manajemen penggunaan ini.
  
  Sama halnya dengan pilar Security atau Operational Excellence, Anda perlu membangun kemampuan melalui pengembangan pengetahuan, program, sumber daya, dan proses untuk menjadi organisasi yang hemat biaya.
  
  

• Adopsi model konsumsi
  Bayar hanya untuk sumber daya komputasi yang Anda perlukan lalu tingkatkan/kurangi penggunaan bergantung pada persyaratan bisnis, bukan dengan menggunakan perkiraan yang rumit.
  
  Misalnya, lingkungan pengembangan dan pengujian biasanya hanya digunakan selama 8 jam sehari di hari kerja. Nah, Anda dapat menghentikan sumber daya ini saat tidak digunakan dengan potensi penghematan biaya 75% ketimbang menjalankannya tanpa henti 24/7 (40 jam vs 168 jam).
  
  

• Ukur efisiensi keseluruhan
  Ukurlah output bisnis Anda dari beban kerja dan biaya yang terkait dengan pengirimannya. Gunakan ukuran ini untuk mengetahui keuntungan yang Anda peroleh dari peningkatan output dan pengurangan biaya.
  
  

• Berhenti menghabiskan uang untuk undifferentiated heavy lifting (pekerjaan berat yang tak memberikan perbedaan nilai)
  AWS melakukan heavy lifting (pekerjaan berat) pada data center seperti racking, stacking, dan powering server. Ini juga menghilangkan beban operasional dalam mengelola sistem operasi dan aplikasi dengan layanan terkelola.
  
  Prinsip ini juga memungkinkan Anda untuk fokus pada pelanggan dan proyek bisnis daripada infrastruktur IT.
  
  

• Analisis dan atribusikan pengeluaran
  Cloud akan membuat Anda lebih mudah untuk mengidentifikasi penggunaan dan biaya sistem secara akurat. Bahkan, cloud juga memungkinkan atribusi yang transparan terhadap biaya IT.
  
  Prinsip ini dapat membantu mengukur Return on Investment (ROI) alias laba atas investasi dan memberi Anda kesempatan untuk mengoptimalkan sumber daya dan mengurangi biaya.
  
  

Untuk petunjuk implementasi secara lebih mendetail, Anda bisa menemukannya di whitepaper untuk pilar Cost Optimization di tautan berikut ini Cost Optimization Pilar - AWS Well-Architected Framework.

AWS Well-Architected Tools

Seperti yang sudah dijelaskan sebelumnya, AWS Well-Architected Framework semula dibuat dalam bentuk whitepaper. Namun sekarang, tersedia juga dalam bentuk AWS Well-Architected Tools sehingga akan lebih mudah mengimplementasikan lima pilar tersebut ke arsitektur Anda.

AWS Well-Architected Tool (AWS WA Tool) menyediakan proses untuk mengukur apakah arsitektur Anda sudah menggunakan praktik terbaik AWS. AWS WA Tool akan membantu di sepanjang life cycle (siklus hidup) produk Anda dengan:

• Membantu mendokumentasikan keputusan yang Anda buat.
• Memberikan rekomendasi untuk meningkatkan beban kerja Anda berdasarkan praktik terbaik.
• Memandu dalam membuat beban kerja Anda lebih andal, aman, efisien, dan hemat biaya.

Agar lebih mudah memahaminya, silakan amati gambar dari AWS WA Tool di bawah ini: 

Berikut adalah langkah-langkah umum dalam menggunakan AWS WA Tools:

1. Identifikasi beban kerja yang akan didokumentasikan. Kemudian, jawablah serangkaian pertanyaan tentang arsitektur Anda (contoh pertanyaannya bisa Anda lihat pada gambar di atas).
2. Tinjau jawaban Anda terhadap 5 pilar yang ditetapkan oleh AWS Well-Architected Framework, yakni Operational excellence, Security, Reliability, Performance efficiency, dan Cost optimization.
3. Hasilnya adalah Anda bisa 
   • mendapatkan video dan dokumentasi; 
   • membuat laporan yang merangkum tinjauan beban kerja Anda; dan
   • melihat hasil tinjauan dalam satu dashboard.

Anda dapat menggunakan AWS WA Tool untuk mendokumentasikan dan mengukur beban kerja Anda menggunakan praktik terbaik dari AWS Well-Architected Framework. Praktik terbaik ini dikembangkan oleh AWS Solutions Architects berdasarkan pengalaman mereka selama bertahun-tahun membangun solusi di berbagai bisnis. Framework alias kerangka kerja ini memberikan pendekatan yang konsisten untuk mengukur arsitektur dan memberikan panduan untuk menerapkan desain yang sesuai dengan kebutuhan Anda dari waktu ke waktu.

AWS Well-Architected Labs

AWS Well-Architected Framework telah dikembangkan untuk membantu Anda dalam membangun infrastruktur yang paling aman, berkinerja tinggi, tangguh, dan efisien. Nah, Anda bisa mempraktikkan AWS Well-Architected Framework dengan lab/praktikum dan skenario sesuai dunia nyata untuk beban kerja yang Anda miliki.

AWS Well-Architected Labs adalah repositori berisi dokumentasi dan kode dalam format lab praktis untuk membantu Anda mempelajari, mengukur, dan membangun solusi menggunakan praktik terbaik arsitektur. Laboratorium dikategorikan ke dalam level, di mana 100 adalah pengantar, 200/300 adalah menengah, dan 400 adalah lanjutan.

Prasyarat Penggunaan

Untuk mengakses AWS Well-Architected Lab, Anda harus memiliki akun AWS. Untuk menggunakannya, Anda disarankan untuk memiliki akun yang terpisah dari akun AWS yang digunakan di lingkungan Production. 

AWS Well Architected Labs saat ini bisa diakses di tautan https://www.wellarchitectedlabs.com/

AWS Well-Architected Labs dikelompokkan berdasarkan pilar AWS Well-Architected Framework. Jika kita buka masing-masing tautan, maka akan terlihat konten spesifik terhadap pilar yang bersangkutan. Pada ilustrasi di atas terlihat konten dari lab untuk pilar Cost Optimization. 

Oke, itulah materi pembahasan kita terkait AWS Well-Architected. Dengan mempelajarinya, semoga Anda paham dan menguasai bagaimana membangun arsitektur di AWS agar andal, aman, dan optimal.

Selanjutnya, mari kita bahas materi yang tak kalah penting, yakni AWS Global Infrastructure alias Infrastruktur Global AWS yang juga akan membantu Anda dalam membangun arsitektur di AWS. Let’s Go!

AWS Global Infrastructure

Sebagai penyedia layanan cloud publik berskala global, Amazon Web Services memiliki infrastruktur jaringan dan data center yang tersebar di berbagai lokasi untuk memberikan pengalaman terbaik bagi pengguna. Infrastruktur di AWS dibagi menjadi Regions, Availability Zones, Edge Locations, dan Regional Edge Caches. Mari kita jabarkan!

Regions

Regions adalah kumpulan dari beberapa Availability Zones (AZ) yang terletak berdekatan di sebuah area geografis. Di setiap region, terdapat minimal 2 AZ yang saling terkoneksi dengan jaringan berlatensi rendah.

Kita dapat memilih region di mana kita akan meletakkan aplikasi dan data sesuai dengan target pengguna. Ini akan mengurangi waktu respons ketika pengguna menggunakan aplikasi kita. Atau, kita juga dapat meletakkan aplikasi di beberapa region sekaligus untuk meningkatkan availability dari aplikasi kita jika sewaktu-waktu terdapat masalah di salah satu region, misalnya bencana alam. 

Keuntungan lain dari penggunaan region adalah mempermudah kita untuk memenuhi syarat regulasi atau hukum terkait lokasi data yang disimpan.

Hingga saat ini ada 19 region AWS yang tersebar di seluruh dunia, yaitu North Virginia, Ohio, North California, Oregon, Central Canada, Sao Paulo, Frankfurt, Ireland, London, Paris, Mumbai, Seoul, Singapore, Sydney, Tokyo, Beijing, Ningxia, GovCloud US-East, dan GovCloud US-West.

Ketahuilah! Tidak semua region menawarkan layanan yang sama. Ada beberapa layanan yang tersedia di region tertentu, namun tak tersedia di region lainnya. Daftar lengkapnya dapat Anda lihat di situs AWS regional product services.

Availability Zones (AZs)

Seperti yang dijelaskan sebelumnya, di dalam satu region minimal terdapat 2 Availability Zones (AZ). Sederhananya, AZ adalah data center secara fisik yang AWS gunakan untuk menjalankan berbagai layanan yang dipakai oleh pelanggan, seperti komputasi, penyimpanan, ataupun database. 

Setiap AZ berjalan secara independen dan memiliki jaringan listrik serta internet yang berbeda dan saling terkoneksi dengan jaringan internet berkecepatan tinggi. Jika salah satu AZ mengalami kerusakan, AZ lainnya tak akan terpengaruh.

Saat modul ini ditulis, terdapat 57 AZ yang tersebar di berbagai region yang telah disebutkan sebelumnya.

Edge Locations

Edge locations adalah data center yang dioperasikan oleh AWS dan tersebar di seluruh dunia. Jumlahnya lebih banyak dari semua Availability Zones yang ada. Edge locations tidak dimaksudkan untuk meletakkan aplikasi atau melakukan komputasi, melainkan digunakan oleh beberapa layanan AWS seperti Amazon CloudFront. 

CloudFront adalah layanan Content Delivery Network (CDN) dari AWS. CloudFront bertugas untuk menyimpan data sementara (cache) di Edge Locations sehingga dapat mengurangi latensi ketika pengguna melakukan request dari lokasi yang jauh dari tempat di mana file berada.

Untuk mempermudah pembahasan, mari kita buat perumpamaan. Misalnya, seorang pelanggan mempunyai sebuah file yang disimpan di region Europe-London, kemudian seorang pengguna dari Indonesia mengunduh file tersebut untuk pertama kali. 

Pengguna itu akan mengunduh file tersebut langsung dari London. Kemudian file akan disimpan di Edge location terdekat dari lokasi pengguna secara otomatis. Dalam contoh ini, Edge Location terdekat dari Indonesia adalah Singapura. 

Setelahnya, jika pengguna tersebut atau lainnya mengunduh file itu kembali, mereka akan mendapatkan file yang telah tersimpan di Edge Location sehingga tak perlu lagi mengambilnya di server London. Alhasil, waktu yang diperlukan akan lebih cepat.

Regional Edge Caches

Selain Edge Locations, AWS juga memiliki Regional Edge Caches. Lokasi Regional Edge Caches terletak di antara server asal data dan Edge Locations. Fungsinya, sebagai perantara sehingga ketika cache yang berada di Edge Locations sudah dihapus, file tidak perlu diambil lagi dari server asal, melainkan dari Regional Edge Caches yang lokasinya lebih dekat. Pada akhirnya, ini juga mengurangi waktu yang dibutuhkan untuk mengunduh file tersebut.

Arsitektur Berskala Besar

Modul ini merupakan perkenalan dari apa yang akan kita pelajari dalam kelas ini. Di modul-modul mendatang kita akan mempelajari lebih jauh mengenai arsitektur di AWS dengan mempelajari satu per satu (termasuk hands-on lab alias latihan), fitur-fitur dan layanan AWS agar infrastruktur dan arsitektur IT startup Anda dapat memberikan keandalan, keamanan dan biaya yang optimal (cost optimized) walaupun arsitekturnya berskala besar seperti pada gambar di bawah ini.

Anda disarankan untuk memiliki akun AWS sebagai persiapan mempelajari modul-modul selanjutnya. Jangan khawatir, langkah-langkah membuat akun dan juga hands-on lab dari kelas ini akan dipelajari di modul kedua. Tetap semangat ya!

Ikhtisar

Di modul ini, kita sudah mempelajari secara singkat hal-hal sebagai berikut:

• AWS Well-Architected Framework
  Merupakan living document (dokumen hidup) yang menunjukkan bagaimana sebaiknya kita membangun solusi IT dengan menggunakan solusi dan fitur yang ada di AWS.
  
  

• AWS Well-Architected Labs
  Salah satu tool AWS yang memberikan pengertian lebih jauh bagaimana implementasi dari AWS Well-Architected Framework.
  
  

• AWS Global Infrastructure
  Memberikan dasar pengertian bagaimana infrastruktur global AWS disusun dan bekerja.

Pengantar ke Arsitektur Tersederhana

Ingat skenario startup kita di modul sebelumnya? Startup Anda baru saja resmi berdiri. Mungkin, sekarang Anda sudah tak sabar untuk mulai berlari, bukan? Tenang, kita akan mulai dengan layanan AWS yang paling mendasar yaitu storage alias penyimpanan.

Katakanlah Anda baru saja memulai perjalanan cloud dan membutuhkan cara termudah untuk mendistribusikan, menyimpan, dan menganalisis data secara reliabel di AWS. Misalnya, untuk menyimpan riwayat transaksi, data pelanggan, stok biji kopi, dan lain sebagainya. Atau mungkin, Anda membutuhkan layanan yang secara ajaib bisa meng-hosting website statis untuk startup warung kopi Anda.

Nah, untuk menjawab kebutuhan tersebut, Anda perlu fokus, tekun, dan menghayati modul ini dengan baik. Sepanjang modul, kita akan membahas hal-hal berikut:

• Masalah apa yang dapat diatasi oleh Amazon S3?
• Cara menyimpan konten secara efisien.
• Masalah apa yang dapat diatasi oleh Amazon Glacier?
• Cara memilih Region.

Masih ingat gambar arsitektur di modul sebelumnya? Itu adalah arsitektur bersakala besar. Tenang, untuk mewujudkan arsitektur seperti itu, kita akan mulai dari yang sederhana.

Pada modul kali ini, kita akan fokus pada bagian kecil dahulu (sisi kiri bawah), dari gambar arsitektur berikut.

Perhatikan gambar di atas. Di modul ini kita akan fokus belajar tentang layanan S3 untuk menyimpan static assets (aset statis) dan melakukan konfigurasi agar pelanggan bisa mengakses aset di S3 bucket tersebut. Tenang, jangan dulu khawatir tentang layanan-layanan yang lain, kita akan mempelajarinya di modul-modul berikutnya.

Pengenalan Amazon S3

Amazon Simple Storage Service (S3) adalah layanan dari AWS untuk menyimpan file berbasis objek (object storage). Artinya, file yang disimpan di S3 akan diperlakukan sebagai sebuah objek yang utuh.

Ketahuilah! Amazon S3 dapat menampung segala jenis file, baik itu video, gambar, data backup, bahkan konten web statis (HTML, CSS, dll). Nah, karena konten website itu dapat terdiri dari beberapa file, layanan Amazon S3 merupakan pilihan yang ideal sebagai langkah awal dalam perjalanan cloud kita di AWS.

Amazon S3 memudahkan kita untuk meng-hosting website startup warung kopi tanpa perlu menjalankan, mengelola, dan me-maintain server. Ingat, website statis memiliki beberapa limitasi. Namun, ini merupakan permulaan yang baik untuk mempelajari arsitektur di AWS, sesuai dengan nama modulnya yakni Arsitektur Tersederhana.

Untuk mengawali pembahasan, silakan amati gambar berikut:

Oke, mari kita uraikan setiap poin-poinnya.

• Amazon S3 adalah layanan penyimpanan tingkat objek (object level storage). Ini berarti, jika kita ingin mengubah sebagian kecil isi dalam sebuah file (misalnya dokumen word), kita harus mengunggah keseluruhan file itu kembali ke S3 bucket.
• Tidak ada limitasi dalam ukuran bucket. Kita bisa menyimpan data sebanyak yang kita mau, akan tetapi ukuran maksimum untuk masing-masing objek adalah 5 TB.
• Untuk mencapai daya tahan yang tinggi (high durability), data akan disimpan dan direplikasi ke lebih dari satu lokasi data center dalam satu AWS region. Hal ini membuat Amazon S3 sangat andal dan memiliki daya tahan (durability) 99.999999999 persen.

Amazon S3 juga memiliki fitur event notifications yang memungkinkan kita untuk mendapatkan pemberitahuan saat ada sebuah kejadian misalnya ketika object diunggah atau dihapus dari sebuah bucket tertentu. Event notifications ini bisa dikirimkan ke kita atau digunakan untuk menjadi pemicu (trigger) sebuah proses lanjutan, misalnya eksekusi AWS Lambda function.

Kita bisa mengakses Amazon S3 dari berbagai metode: AWS Management Console atau melalui akses terprogram dengan cara CLI (Command Line Interface), SDK (Software Development Kit), dan solusi pihak ketiga yang memanfaatkan API/SDK.

Amazon S3 juga memiliki fitur storage class analysis yang akan sangat membantu kita dalam menganalisis pola akses objek di S3 bucket. Fitur ini secara otomatis mengidentifikasi apakah objek di dalam bucket sering diakses atau tidak. Lalu dengan lifecycle policy, objek-objek di dalam bucket dapat dipindahkan ke storage class yang lebih sesuai.

Salah satu contohnya adalah memindahkan suatu objek ke storage class yang jarang diakses alias Amazon S3 Standard-Infrequent Access (Amazon S3 Standard-IA). Kita bisa mengonfigurasi kebijakan storage class analysis untuk memonitor objek di dalam bucket berdasarkan prefiks ataupun object tag.

Setelah pola infrequent access (akses yang jarang) didapatkan, Anda dapat dengan mudah membuat lifecycle age policy yang baru berdasarkan hasil analisisnya. Storage class analysis juga menyajikan visualisasi harian dari penggunaan penyimpanan Anda di AWS Management Console. Bahkan, Anda dapat mengekspornya ke S3 bucket untuk kemudian dianalisis menggunakan alat business intelligence (kecerdasan bisnis) pilihan Anda, seperti Amazon QuickSight.

Seperti yang sudah kita bahas sebelumnya, hosting website statis hanyalah salah satu contoh penggunaan dari Amazon S3. Ada beberapa kasus penggunaan S3 yang layak Anda lihat. Mari kita bahas satu per satu dalam bentuk pembahasan kasus.

Kasus Penggunaan Amazon S3

Selamat datang di modul Kasus Penggunaan atau biasa disebut dengan Use Case. Di sini kita akan mendiskusikan 4 (empat) kasus penggunaan yang bisa Anda lakukan dengan Amazon S3. Persiapkan diri Anda dan pahami setiap kasus penggunaannya sebaik mungkin. Baiklah, tunggu apa lagi? Mari kita melangkah ke kasus penggunaan pertama. Semangat!

Kasus Penggunaan 1: Menyimpan dan Mendistribusikan Konten Web Statis dan Media

Anda dapat menggunakan Amazon S3 untuk menyimpan dan mendistribusikan konten web statis atau media. File ini dapat dikirim langsung dari Amazon S3 karena setiap objek dikaitkan dengan URL HTTP unik yang harus sesuai dengan nama domainnya (contoh startupwarungkopi.com).

Misalnya, Anda dapat menyimpan konten web (gambar atau video) di Amazon S3 dan menjalankan web server di Amazon EC2. Dengan strategi ini, beban kerja server menjadi lebih ringan karena ia bisa fokus terhadap kalkulasi proses bisnis.

Tak hanya itu, Amazon S3 juga dapat digunakan sebagai origin (asal) untuk layanan content delivery network seperti Amazon CloudFront.

Amazon S3 berfungsi dengan baik untuk situs web yang berkembang pesat dan membutuhkan elastisitas kuat. Termasuk juga beban kerja dengan konten yang dibuat pengguna dalam jumlah besar, seperti photo atau video sharing.

Secara default, semua sumber daya Amazon S3—bucket, objek, dan sub-sumber daya terkait (konfigurasi lifecycle dan situs web) bersifat private. Artinya, hanya pemilik sumber daya (owner dari bucket) yang dapat mengaksesnya. Pemilik sumber daya dapat memberikan izin akses kepada orang lain dengan menulis access policy.

Amazon S3 bucket terlindungi secara default. Hanya akun administrator dan root user-lah yang memiliki akses ke bucket yang baru dibuat dan belum dimodifikasi.

Lalu, bagaimana jika ingin mengaktifkan akses tambahan untuk pengguna lain? Nah, tenang! Caranya, Anda dapat memodifikasi bucket policy.

Selain itu, AWS menyediakan sejumlah alat (tool) berbeda yang memungkinkan developer mengonfigurasi bucket untuk berbagai macam beban kerja.

Amazon S3 juga menyertakan fitur "block public access" yang bertindak sebagai lapisan perlindungan tambahan untuk mencegah pembukaan akses data pelanggan tanpa sengaja.

Di setelan akses publik untuk sebuah bucket, pelanggan dapat menentukan 4 opsi yang mana semuanya telah diaktifkan secara default. Di antaranya:

• Memblokir akses publik terhadap bucket dan objek yang diberikan melalui ACL (Access Control List) yang baru.
• Memblokir akses publik terhadap bucket dan objek yang diberikan melalui ACL (Access Control List) yang sudah ada (existing) maupun yang baru.
• Memblokir akses publik terhadap bucket dan objek yang diberikan melalui bucket policy yang baru.
• Memblokir akses untuk publik dan akses antar akun terhadap bucket dan objek melalui bucket policy yang sudah ada (existing) maupun yang baru.

Karena semua opsi pengaturan di atas diaktifkan secara default, maka jika Anda memerlukan akses publik, Anda perlu menonaktifkan setelan-setelan tersebut secara manual.

PENTING! Meskipun kasus penggunaan situs web atau konten statis dengan S3 adalah contoh yang bagus untuk menyiapkan arsitektur AWS dengan cepat, namun akses publik ke Amazon S3 bukanlah termasuk ke dalam mayoritas kasus penggunaan. Tahukah Anda bahwa sebagian besar kasus penggunaan Amazon S3 TIDAK memerlukan akses publik. Lebih sering, Amazon S3 menyimpan data yang merupakan bagian dari aplikasi lain. Akses publik tidak boleh digunakan untuk jenis bucket pribadi.

Kasus Penggunaan 2: Hosting Seluruh Konten Web Statis

Amazon S3 juga bisa digunakan untuk hosting seluruh konten web statis termasuk file html, gambar, video, dan juga skrip sisi klien (client-side scripts).

Untuk mengonfigurasi bucket agar dapat meng-hosting situs web statis, Anda bisa menggunakan AWS Management Console tanpa perlu menulis kode apa pun. Anda juga dapat membuat, memperbarui, dan menghapus konfigurasi situs web secara terprogram dengan menggunakan AWS SDK.

SDK menyediakan utility agar dapat mengunggah objek ke Amazon S3 dengan mudah.. Jika aplikasi Anda membutuhkan akses langsung ke Amazon S3, Anda dapat mengirim permintaan melalui REST API.

Untuk meng-hosting situs web statis di Amazon S3, aktifkan fitur “static website hosting” pada Amazon S3 bucket Anda, kemudian unggah konten situs web yang diinginkan.

Saat Anda mengonfigurasi bucket sebagai situs statis, selain harus mengaktifkan fitur “static website hosting”, Anda juga perlu mengatur permission dan membuat serta menambahkan dokumen indeks. Bergantung pada kebutuhan situs web Anda, Anda juga dapat mengonfigurasi redirect, web traffic logging, dan custom error document.

Setelah mengonfigurasi bucket sebagai situs web statis, Anda dapat mengakses bucket melalui website endpoint untuk AWS Regions tertentu dari bucket Anda.

Website endpoint ini berbeda dengan endpoint tempat Anda mengirim permintaan REST API. Untuk informasi lebih lanjut, lihat Amazon S3 Website Endpoints.

Ketahuilah! Amazon S3 tidak mendukung akses HTTPS untuk website endpoint. Jika Anda ingin menggunakan HTTPS, Anda dapat menggunakan Amazon CloudFront untuk melayani situs web statis yang di-hosting di Amazon S3.

Kasus Penggunaan 3: Penyimpanan Data untuk Komputasi dan Analisis Skala Besar

Anda juga dapat menggunakan Amazon S3 sebagai penyimpanan data untuk komputasi atau analitik berskala besar, seperti analisis transaksi keuangan, analitik clickstream, dan transcoding media. Amazon S3 dapat mendukung beban kerja ini karena kemampuannya dalam horizontal scaling (penyesuaian kapasitas secara horizontal) yang dengan mudah memungkinkan beberapa transaksi dilakukan secara bersamaan.

Dewasa ini, banyak organisasi maupun perusahaan yang mengumpulkan dan menganalisis data dengan jumlah yang masif sehingga sangat sulit diimplementasikan di solusi on-premise untuk menyimpan, mengelola, dan menganalisis data tersebut.

Nah, hadirlah Amazon S3 dan S3 Glacier yang memberikan solusi penyimpanan ideal. Keduanya menyediakan opsi yang luas dan mendalam untuk integrasi dengan alat analitik big data tradisional serta query-in-place (kueri-di-tempat) inovatif yang dapat membantu Anda menghilangkan proses extract (ekstraksi), transform (transformasi), dan load (pemuatan) yang mahal dan kompleks. Kita akan mempelajari mengenai S3 Glacier lebih jauh di modul ini.

Kasus Penggunaan 4: Media Penyimpanan Data Backup

Karena sifatnya yang sangat durable dan scalable, Amazon S3 juga berfungsi dengan baik sebagai alat pencadangan (backup) dan pengarsipan. Selain itu, Anda dapat memindahkan data yang sifatnya untuk jangka panjang ke Amazon Glacier melalui penggunaan lifecycle policies. Untuk menjaga kehilangan/korupsi data, Anda dapat menggunakan cross-region replication untuk menyalin objek secara otomatis ke Amazon S3 bucket lainnya di region berbeda.

Tahukah Anda? Jumlah data yang dihasilkan di on-premise kian bertambah, begitu pula permintaan untuk penyimpanan arsip cadangan. 

Jika Anda mengikuti metodologi pencadangan secara umum dan memiliki beberapa cadangan di lokasi yang berbeda, maka kemungkinan besar Anda memiliki banyak data yang tersimpan di disk storage atau physical tape archives (arsip pita fisik). Melacak beberapa salinan data lokal dapat menjadi tantangan dan sering kali menimbulkan biaya yang signifikan, baik dalam hal waktu maupun biaya.

AWS Cloud memberikan alternatif menarik untuk penyimpanan backup di on-premise atau physical tape archives. Misalnya, Amazon S3 Glacier Deep Archive memberikan daya tahan sebelas 9 (99.999999999%) dengan harga sekitar $1 per TB / bulan. 

Dengan AWS Cloud, tidak ada perangkat keras penyimpanan yang harus Anda kelola, tidak ada tape yang harus Anda kirim ke luar lokasi, dan tidak perlu mengeluarkan biaya ketika ada hardware yang perlu diperbaharui dalam sebuah siklus. Bahkan, Anda akan mendapatkan semua keuntungan di sisi skalabilitas dan daya tahan cloud, dengan hanya membayar sesuai yang Anda gunakan.

Oke, itulah beberapa kasus penggunaan yang dapat Anda terapkan sesuai dengan kebutuhan. Jadi, hosting website statis bukanlah satu-satunya fitur yang tersedia di Amazon S3, melainkan ada banyak manfaat lainnya yang bisa berguna untuk kasus-kasus tertentu, termasuk startup warung kopi Anda.

Versioning di Amazon S3

Sebelum masuk ke pembahasan, tahukah Anda apa itu versioning? Versioning adalah pembuatan dan pengelolaan beberapa rilis dari suatu produk, yang mana memiliki fungsi umum yang sama namun telah dilakukan perbaikan, peningkatan, atau penyesuaian.

Di Amazon S3, versioning adalah cara untuk menyimpan beberapa versi objek dalam bucket yang sama. Sehingga ketika ada objek yang tertimpa (override) baik sengaja atau tidak, Anda dapat memulihkan setiap versi dari setiap objek yang disimpan di bucket Anda.

Misalnya, Anda memiliki website statis untuk startup warung kopi yang dihosting di Amazon S3. Karena suatu kebutuhan, Anda ingin memperbarui website tersebut untuk menambahkan logo. Tapi sayangnya, proses update tersebut malah menimbulkan eror.

Nah, jika Anda mengaktifkan versioning di Amazon S3, maka tak perlu khawatir. Anda masih bisa mengembalikan (restore) versi sebelumnya dari website tersebut. Dengan begitu, Anda bisa memperbaiki eror dan meng-hosting kembali website tersebut dengan aman. Mari kita pelajari tentang versioning di S3 lebih lanjut!

Bucket yang mendukung versioning memungkinkan Anda untuk memulihkan objek dari penghapusan atau overwrite (penimpaan) yang terjadi secara tidak disengaja. Sebagai contoh:

• Jika Anda menghapus objek, aksi penghapusan ini tidak akan permanen, melainkan Amazon S3 akan menyisipkan penanda hapus (delete marker) yang menjadi versi objek saat ini. Anda selalu dapat memulihkan versi sebelumnya.
• Jika Anda menimpa objek, Amazon S3 akan menghasilkan versi objek baru di S3 bucket dan menjaga versi objek sebelumnya. Anda selalu dapat memulihkan versi sebelumnya.

Amazon S3 Bucket dapat berada di salah satu dari tiga status: unversioned (default), versioning-enabled, atau versioning-suspended.

Penting! Setelah Anda mengaktifkan fitur versioning, bucket tidak akan pernah bisa kembali ke status unversioned. Namun, Anda dapat menangguhkan (suspend) pembuatan versi pada bucket tersebut.

Status pembuatan versi berlaku untuk semua objek dalam S3 bucket dan tidak bisa diberlakukan untuk beberapa objek saja. Saat pertama kali Anda mengaktifkan bucket untuk pembuatan versi, objek di dalamnya akan selalu dibuat versinya dan diberi version ID yang unik. Perhatikan hal-hal berikut:

Objek yang disimpan di bucket sebelum Anda menyetel status pembuatan versi, memiliki version ID “null”. Jika Anda mengaktifkan pembuatan versi, objek yang ada di bucket Anda tidak berubah. Melainkan, yang berubah adalah bagaimana Amazon S3 menangani objek untuk permintaan di masa mendatang. Jika tertarik untuk belajar lebih mendalam mengenai ini, Anda dapat membaca detail lengkapnya di tautan ini Working with objects in a versioning-enabled bucket.

Pemilik bucket (atau pengguna dengan izin yang sesuai) dapat menangguhkan (suspend) pembuatan versi untuk memberhentikan fitur object versioning. Jika Anda menangguhkan pembuatan versi, objek yang ada di bucket Anda tidak berubah. Melainkan, yang berubah adalah bagaimana Amazon S3 menangani objek untuk permintaan setelah suspension terhadap bucket diaktifkan.

Bagaimana, sudah paham kan dengan versioning di Amazon S3? Intinya, versioning ini merupakan fitur yang sangat bermanfaat dan bisa menjadi penyelamat Anda dalam melakukan pekerjaan.

Bayangkan saja jika tak ada fitur versioning, lalu file pekerjaan Anda terhapus (baik sengaja atau tidak), Anda akan pusing bukan main. Percayalah, jangan sampai itu terjadi!

Memindahkan Data ke Amazon S3

Masihkah Anda menyimpan data secara lokal di komputer atau laptop? Jika jawabannya “masih”, lalu bagaimana jika Anda membutuhkan data itu sesegera mungkin namun Anda tak membawa laptop atau tak sedang berada di depan komputer? Tentu, itu akan menyulitkan.

Tak hanya itu, masih banyak alasan lain mengapa Anda harus memindahkan data ke cloud, terutama Amazon S3, seperti biaya yang murah, aman, dan awet.

Saat Anda mengunggah file ke Amazon S3, file tersebut akan disimpan sebagai objek S3. Objek terdiri dari file data dan metadata yang memberikan gambaran mengenai objek tersebut. Sebuah bucket dapat menampung objek dalam jumlah yang tak terbatas.

Anda dapat memindahkan data ke Amazon S3 dengan beberapa cara yang berbeda:

• Transfer menggunakan AWS Management Console, AWS Command Line Interface (AWS CLI), atau API 
  Jika Anda memiliki sejumlah kecil data atau data yang sudah ada di dalam jaringan AWS, Anda dapat mentransfernya ke Amazon S3 dengan mudah menggunakan console, CLI, atau API.
  
  
• Unggah ke S3 bucket
  Anda dapat mengunggah semua jenis file—gambar, backup, data, film, dll—ke dalam S3 bucket. Ukuran maksimum file yang dapat Anda unggah dengan menggunakan Amazon S3 console adalah 160 GB. Jika menggunakan CLI atau API, Anda dapat memindahkan file dengan ukuran yang lebih besar.
  
  
  
• AWS DataSync
  AWS DataSync adalah layanan transfer data yang memudahkan Anda mengotomatiskan pemindahan data antara penyimpanan di on-premise dan layanan penyimpanan di AWS, seperti Amazon S3, Amazon Elastic File System (Amazon EFS), dan Amazon FSx (untuk Windows File Server file systems).
  
  
• AWS Transfer for SFTP
  AWS Transfer for SFTP adalah layanan Secure File Transfer Protocol atau SFTP yang terkelola sepenuhnya dan sangat tersedia. Layanan ini memungkinkan aplikasi mentransfer file melalui protocol SFTP langsung ke Amazon S3.
  
  

Selain itu, Anda juga dapat menggunakan metode multipart upload yang memungkinkan Anda mengunggah objek berukuran besar secara konsisten di bagian yang dapat dikelola.

Proses ini melibatkan 3 langkah:

• Mulai pengunggahan (initiate).
• Unggah bagian objek (upload object parts).
• Selesaikan proses multipart upload (complete).

Setelah permintaan multipart upload selesai, Amazon S3 akan menyusun objek secara keseluruhan dari masing-masing bagian. Berikut adalah manfaat multipart upload bagi Anda:

• Throughput yang lebih baik
  Anda dapat mengunggah bagian-bagian objek secara paralel untuk meningkatkan throughput.
  
  
• Pemulihan yang cepat dari masalah jaringan
  Ukuran bagian objek yang lebih kecil meminimalkan dampak untuk mengulang proses unggahan yang gagal karena kesalahan jaringan.
  
  
• Jeda dan lanjutkan unggahan objek
  Anda dapat mengunggah bagian objek dari waktu ke waktu. Setelah Anda memulai proses multipart upload, tidak akan ada nilai expiry time; Anda harus secara eksplisit menyelesaikan atau menghentikan proses tersebut.
  
  
• Mulailah mengunggah sebelum Anda mengetahui ukuran objek akhir
  Dengan multipart upload, Anda dapat mengunggah objek saat membuatnya.
  
  
• Unggah objek besar
  Dengan API multipart upload, Anda dapat mengunggah objek besar, bahkan hingga 5 TB.

Amazon S3 Glacier

Seiring berkembangnya startup warung kopi Anda, katakanlah telah berjalan beberapa tahun dan kian sukses, tentu Anda akan mempunyai banyak sekali data yang harus disimpan sebagai arsip. Tak hanya masalah besarnya penyimpanan, melainkan regulasi, compliance, dan keamanan pun harus Anda penuhi.

Perkenalkan, Amazon S3 Glacier. Layanan ini adalah pilihan penyimpanan yang tepat jika faktor penentu Anda adalah biaya yang rendah, data dengan pattern yang jarang diakses, dan tak masalah jika latensi pengambilan data memerlukan waktu beberapa jam. Jika aplikasi Anda membutuhkan akses yang cepat atau sering ke data Anda, pertimbangkanlah untuk menggunakan Amazon S3 saja.

Dengan Amazon S3 Glacier, Anda dapat melakukan pengarsipan data. Itu berarti, meskipun Anda dapat menyimpan data dengan biaya yang sangat rendah (bahkan dibandingkan dengan Amazon S3), Anda tidak dapat mengambil data dengan segera di saat itu juga. Data yang disimpan di Amazon S3 Glacier membutuhkan waktu beberapa jam untuk diambil, itulah mengapa layanan ini sangat ideal untuk pengarsipan.

Anda memiliki 3 opsi untuk mengambil data dengan waktu akses dan biaya yang berbeda-beda:

• Pengambilan dipercepat (expedited) biasanya tersedia dalam 1 - 5 menit.
• Pengambilan standar (standard) biasanya tersedia dalam 3 - 5 jam.
• Pengambilan massal (bulk) biasanya tersedia dalam 5 - 12 jam.

Berikut adalah beberapa detail tambahan terkait Amazon S3 Glacier:

• Amazon Glacier adalah layanan pengarsipan data yang dirancang untuk keamanan, daya tahan, dan biaya yang sangat rendah.
• Didesain untuk ketahanan objek 99.999999999%.
• Mendukung enkripsi SSL/TLS data in transit.
• Fitur Vault Lock memberikan kontrol compliance melalui lockable policy (kebijakan yang dapat dikunci untuk mencegah perubahan di masa depan).
• Desain yang sangat murah dan ideal untuk pengarsipan jangka panjang.

Perbandingan Amazon S3 dan Glacier

Sebelumnya, kita sudah belajar mengenai Amazon S3 dan Glacier. Mungkin Anda akan merasa bingung harus memilih layanan mana. Tentunya, setiap layanan penyimpanan memiliki kasus penggunaan yang berbeda, tergantung pada kebutuhan. Maka dari itu, mari kita bandingkan kedua layanan tersebut dengan meninjau dari storage class-nya.

Berikut adalah kelas penyimpanan dari Amazon S3:

• Amazon S3 Standard (untuk penggunaan umum)
  Jika Anda memiliki kebutuhan akan ketersediaan yang lebih tinggi, maka gunakanlah cross-region replication (replikasi antar region).
  
  
• Amazon S3 Standard - Infrequent Access (untuk data yang jarang diakses)
  Kelas penyimpanan ini menawarkan semua manfaat Amazon S3, termasuk daya tahan, ketersediaan, dan keamanannya. Kelas ini hanya berjalan pada model biaya yang berbeda untuk memberikan solusi penyimpanan data yang jarang diakses, seperti gambar digital lawas atau file log yang sudah berumur lama.
  
  Beberapa poin lainnya adalah:
  • Biaya lebih rendah per GB yang disimpan.
  • Biaya tinggi untuk setiap permintaan PUT, COPY, POST, atau GET ditambah dengan biaya untuk pengambilan data (Data retrievals fee).
  • Penyimpanan minimal 30 hari.
• Amazon S3 Reduced Redundancy Storage (untuk mengurangi redundansi)
  • Menyimpan objek di beberapa perangkat di berbagai fasilitas.
  • Menyimpan data yang tidak penting dan dapat direproduksi ulang pada tingkat redundansi yang lebih rendah.
• Amazon S3 One Zone-IA (untuk data yang lebih jarang diakses, tetapi membutuhkan akses cepat saat diperlukan)
  Tidak seperti kelas penyimpanan S3 lainnya yang menyimpan data di minimal 3 Availability Zone (AZ), S3 One Zone-IA menyimpan data dalam satu AZ dan biayanya 20% lebih murah dari S3 Standard-IA.
  
  Oleh karena itu, kelas penyimpanan ini sangat ideal untuk pelanggan yang menginginkan opsi biaya lebih rendah untuk data yang jarang diakses tetapi tidak memerlukan ketersediaan dan ketahanan seperti yang dimiliki kelas S3 Standard atau IA - Standar S3.
  
  
• S3 Glacier Deep Archive
  S3 Glacier Deep Archive ini merupakan tingkat penyimpanan termurah yang tersedia bagi pengguna dengan tetap mempertahankan daya tahan dan retensi data jangka panjang.
  
  Jenis penyimpanan ini ideal untuk pelanggan yang perlu membuat arsip, salinan data tahan lama yang jarang atau tidak perlu diakses. Opsi Ini juga memungkinkan pelanggan untuk menghilangkan kebutuhan akan on-premises tape libraries (perpustakaan pita lokal). Data yang tersimpan pada kelas penyimpanan ini dapat diambil dalam waktu 12 jam.
  
  
• Amazon S3 Intelligent Tiering
  Ini adalah kelas penyimpanan untuk Amazon Simple Storage Service (Amazon S3) yang mengoptimalkan biaya penyimpanan dengan memindahkan objek secara otomatis di antara dua tingkat akses penyimpanan saat pola akses berubah.
  
  Amazon S3 Intelligent Tiering merupakan pilihan yang ideal jika Anda mengakses data yang disimpan selama lebih dari sebulan dan memiliki pola akses yang tidak terprediksi atau berubah-ubah. Misalnya, Anda mungkin memiliki aplikasi dan data lake yang baru diluncurkan, di mana pola akses dapat bervariasi di berbagai sub-kumpulan penyimpanan.
  
  Selain itu, Amazon S3 Intelligent Tiering juga menawarkan latensi milidetik dan SLA ketersediaan 99% terlepas dari objek tingkat S3 mana yang disimpan. Karena Amazon S3 Intelligent Tiering mengotomatiskan pengoptimalan biaya penyimpanan, Anda tidak perlu menganalisis atau mengaudit pola akses penyimpanan secara manual untuk menghemat pada penyimpanan yang jarang diakses.

Oke, itulah pembahasan kita mengenai Amazon S3 dan Glacier. Intinya, AWS memiliki layanan yang lengkap terkait storage alias penyimpanan. Setiap layanan memiliki kasus penggunaan yang berbeda sesuai kebutuhan pelanggan. Jadi, pilihlah layanan penyimpanan yang paling sesuai dengan kebutuhan Anda.

Amazon S3 Analytics dan Insights

Fitur ini akan mengamati pola akses data yang jarang diakses pada penyimpanan STANDARD untuk dipindahkan ke kelas penyimpanan STANDARD_IA atau Infrequent Access. Mari kita pelajari kelas penyimpanan ini lebih lanjut.

Seiring pertumbuhan storage, Anda akan membutuhkan kemampuan untuk menganalisis apa saja data yang disimpan di storage tersebut. Amazon S3 menawarkan sejumlah fitur untuk membantu Anda lebih memahami, menganalisis, dan mengoptimalkan penyimpanan dalam skala besar. Mari kita bahas!

Storage Class Analysis

Dengan menggunakan Amazon S3 analytics storage class analysis, Anda dapat menganalisis pola akses penyimpanan guna memutuskan kapan akan mentransisikan data yang tepat ke kelas penyimpanan yang sesuai. Fitur ini mengamati pola akses data yang jarang diakses pada penyimpanan STANDARD untuk dipindahkan ke kelas penyimpanan STANDARD_IA.

PENTING! Storage class analysis tidak memberikan rekomendasi untuk transisi ke kelas penyimpanan ONEZONE_IA atau S3 Glacier.

S3 Storage Lens

Amazon S3 Storage Lens memberikan satu tampilan penggunaan dan aktivitas penyimpanan objek di seluruh Amazon S3 Anda. Ini mencakup opsi lihat perincian untuk menghasilkan insights di tingkat Organization, Accounts, Region, Bucket, atau bahkan tingkat prefix.

Storage lens menggabungkan penggunaan dan metrik aktivitas Anda serta menampilkan informasi di dashboard interaktif di Amazon S3 console atau melalui ekspor data metrik yang dapat diunduh dalam format CSV atau Parquet.

Anda dapat menggunakan dashboard untuk memvisualisasikan insight dan trend, memberikan rekomendasi pengoptimalan biaya penyimpanan, serta menerapkan praktik terbaik perlindungan data. Anda dapat menggunakan Storage Lens melalui AWS Management Console, AWS CLI, AWS SDK, atau REST API.

Tahukah Anda? Data yang Anda simpan juga akan berhubungan erat dengan lokasi di mana ia ditempatkan. Nah, bagaimana cara memilih Region yang tepat untuk menyimpan data kita? Simak di materi berikutnya!

Memilih AWS Regions untuk Arsitektur Anda

Data kita harus tunduk pada hukum negara dan wilayah tempat ia disimpan. Selain itu, beberapa undang-undang menetapkan bahwa jika Anda menjalankan bisnis di yurisdiksinya, Anda tidak dapat menyimpan data tersebut di tempat lain.

Demikian pula, standar kepatuhan (seperti United States’ Health Insurance Portability and Accountability Act atau HIPAA) memiliki pedoman ketat tentang bagaimana dan di mana data dapat disimpan. Selain itu, AWS juga membuka wilayah netral karbon pertamanya pada tahun 2011 dan sekarang telah menawarkan lima wilayah netral karbon yang terpisah.

Pertimbangkan semua hal ini saat mengevaluasi lokasi untuk menempatkan lingkungan Anda.

Selain memikirkan soal compliance, kita juga harus menimbang hal-hal berikut ini:

Hal yang Harus Dipertimbangkan	Pokok Pikiran
Kedekatan Lokasi Pengguna dengan Data	Perbedaan kecil dalam latensi dapat memengaruhi pengalaman pelanggan. Maka dari itu, pilihlah region yang paling dekat dengan pengguna Anda.
Ketersediaan Fitur dan Layanan	Beberapa layanan masih belum tersedia di semua region. Dapat menggunakan beberapa layanan lintas region, tetapi dengan peningkatan latensi. Layanan diperluas ke wilayah baru secara teratur.
Keefektifan Biaya	Biaya bervariasi menurut region. Beberapa layanan seperti Amazon S3 memiliki biaya untuk mentransfer data keluar. Pertimbangkan efektivitas biaya untuk mereplikasi seluruh lingkungan di region lain.

Wow, cukup banyak hal yang kita pelajari mengenai Storage di AWS. Sebagai penutup modul ini, kita akan mulai mempraktikkan Hands-on Lab pertama dari kelas ini.

Hands-on Lab: Membuat Akun AWS

Selamat datang di modul latihan pertama kita pada kelas ini. Tenang, kita tak akan langsung membuat arsitektur yang kompleks kok.

Untuk bisa menggunakan layanan AWS, Anda wajib mempunyai akun AWS terlebih dahulu. Jika Anda belum memilikinya, jangan khawatir ya. Di latihan pertama ini Anda akan belajar bagaimana cara membuatnya.

Untuk mendaftar di AWS, Anda membutuhkan kartu debit/kredit yang valid dan menyiapkan saldo 1 dollar di kartu tersebut. Biaya ini berfungsi untuk verifikasi kartu saja dan nantinya akan dikembalikan lagi dalam waktu beberapa hari.

Setelah memahami tujuan latihan ini, sekarang mari kita uraikan tahapan-tahapan yang akan dipraktikkan. Berikut tahapannya:

• Masuk ke halaman awal Amazon Web Services.
• Isi data pribadi Anda.
• Masukkan informasi kartu debit/kredit Anda.
• Pilih paket dukungan yang Anda inginkan.
• Akun Anda selesai dibuat.

Bagaimana, sudah siap? Mari kita mempelajari AWS Cloud lebih dalam dengan membuat akun AWS. Berikut caranya:

1. Buka browser dan kunjungi tautan berikut https://aws.amazon.com/.
2. Klik tombol Create an AWS Account yang ada di pojok kanan atas halaman.
3. Anda akan diarahkan ke halaman pendaftaran akun. Silakan isi email, password, dan nama akun AWS Anda. Jika selesai, klik tombol Continue.
   
   
   
4. Kita masuk ke halaman selanjutnya. Pada bagian How do you plan to use AWS? Pilih Personal. Lalu, isikan data pribadi Anda dengan lengkap dan klik Continue.
   
   
   
5. Di halaman ini Anda harus mengisi informasi pembayaran melalui kartu debit/kredit. Anda juga bisa menggunakan virtual credit card yang disediakan beberapa bank di Indonesia. Jika sudah, maka Anda bisa langsung klik Verify and Continue.
   
   
   

6. Selanjutnya, Anda akan diarahkan ke halaman konfirmasi. Silakan masukkan nomor telepon dan isi Security check sesuai pada layar Anda masing-masing, lalu klik Send SMS. (Jika gagal, cek solusinya pada akhir latihan).
   
   
   

7. Masukkan kode verifikasi yang dikirim Amazon ke Smartphone Anda. Lalu, klik Continue.
   
   
   

8. Di halaman ini ada beberapa pilihan paket dukungan. Basic Support, Developer Support, dan Business Support. Silakan pilih yang Basic Support, kemudian klik Complete sign up.
   
   
   

9. Selamat! Anda sudah berhasil membuat akun AWS. Jika Anda ingin, silakan eksplorasi berbagai layanan AWS dengan klik Go to the AWS Management Console.
    

Dengan membuat akun AWS, sekarang Anda bisa menggunakan banyak layanan dan membuat sumber daya yang Anda inginkan secara langsung.

Solusi jika pembayaran gagalJika Anda mengalami hal seperti ini:


Itu menandakan adanya masalah pada informasi pembayaran Anda. Bisa jadi karena saldo pada kartu debit/kredit Anda kurang dari 1 dolar atau informasi kartu yang tidak sesuai/kurang lengkap.

1. Silakan klik sign in to your account.

2. Selanjutnya, klik Edit.
   
   
   

3. Centang Use contact address. Pastikan semua informasi tersebut lengkap dan sesuai. Jika sudah, klik tombol Update.
   
   
   

4. Lanjut, klik tombol Make Payment yang ada di kanan atas.
   
   
   

Nah, jika semuanya telah dilakukan, AWS akan mencoba kembali untuk menarik 1 dolar dari kartu debit/kredit Anda. Jika berhasil, silakan kembali ke langkah 6 untuk lanjut membuat akun AWS.

Jika masih gagal, cobalah masuk kembali ke halaman informasi kartu dan klik tombol Verify yang terletak sesuai tanda panah di bawah. Jika sudah terverifikasi, silakan kembali ke langkah 6.

Jika metode pembayaran Anda telah terverifikasi dan saldo sudah terpotong namun masih belum bisa mengakses layanan AWS, seperti gambar berikut:

Silakan klik Complete your AWS registration, lalu ikutilah langkah yang muncul pada layar Anda. Jika langkah registrasi akun Anda sudah lengkap, tetapi masih tidak bisa mengakses layanan AWS, tunggulah hingga maksimal 24 jam, lalu coba kembali.

Masih belum bisa? Hubungilah customer service Bank Anda dan tanyakan apakah kartu kredit/debit Anda dapat melakukan transaksi internasional atau tidak.

Hands-on Lab: Hosting Website Statis

Di awal modul ini kita diberi tahu bahwa salah satu kasus penggunaan Amazon S3 adalah meng-hosting website statis. Nah, sekarang waktunya untuk mengimplementasikan apa yang sudah kita pelajari.

Agar semakin mudah memahami materi, mari kita kaitkan latihan ini dengan skenario startup warung kopi kita.

Katakanlah startup Anda ingin membuat sistem pemesanan kopi yang kompleks dan inovatif agar bisa melayani semua pelanggan dengan baik. Tetapi, tentu mewujudkannya akan membutuhkan waktu yang lama.

Maka dari itu, Anda terlebih dahulu ingin meng-hosting website statis yang memiliki ketersediaan tinggi di AWS. Website sederhana tersebut berisi ucapan selamat datang dan informasi bahwa sistem ini akan segera hadir.

Oke, setelah mengetahui latar belakangnya, lalu apa saja langkah-langkahnya? Baiklah, mari kita uraikan:

1. Pertama, kita akan membuat S3 bucket.
2. Lalu, deploy website kita.
3. Terakhir, membuat website tersebut dapat diakses secara publik.

Bagaimana? Sudah siap mempraktikkannya? Let’s go!

1. Pertama, unduhlah file website yang akan kita gunakan nanti dari tautan ini.
2. Pastikan Anda sudah berada di AWS Management Console dan masuk ke menu Amazon S3 dengan cara mengetikkan “Amazon S3” di kotak pencarian.
   
   
   
3. Di sini (di dalam Amazon S3 dashboard console), kita akan membuat S3 bucket terlebih dahulu. Silakan klik tombol Create bucket.
   
   
   
4. Selanjutnya, beri nama untuk S3 bucket Anda. Ingat! Nama bucket S3 haruslah unik. Jadi, silakan isi sesuai format berikut: my-public-website-XXXX (ganti XXXX dengan digit angka yang Anda inginkan). Pada bagian AWS Region, pilihlah Region Singapore, yang mana merupakan Region terdekat dari lokasi kita.
   
   
   
5. Langkah selanjutnya, hapus centang pada Block all public access agar bucket ini mengizinkan akses publik. Kemudian, centang pada bagian bawah untuk menyatakan Anda sadar membuka akses publik untuk kepentingan hosting website statis.
   
   
   
6. Konfigurasi kita sudah selesai untuk tahap ini. Silakan scroll ke bagian halaman yang paling bawah dan klik Create bucket.
   
   
   
7. Sekarang, S3 bucket Anda sudah siap digunakan. Silakan klik pada nama S3 bucket untuk masuk ke dalamnya.
   
   
   
8. Untuk mengunggah file, klik pada tombol Upload.
   
   
   
9. Anda akan diarahkan ke halaman Upload file.
   
   
   
10. Silakan unzip/extract file yang telah Anda unduh sebelumnya pada langkah ke-1, lalu drag and dropfile file di dalamnya ke S3 bucket. 

    
    
    

11. Jika sudah, tampilan halaman akan berubah menjadi seperti ini.
    
    
    

12. Oke, silakan scroll halaman ke paling bawah dan klik Upload.
    
    
    

13. Selamat! Anda telah berhasil mengunggah file yang dibutuhkan. Selanjutnya, mari kita aktifkan fitur static website hosting. Yuk klik tombol Exit terlebih dahulu!
    
    
    

14. Setelah menekan tombol Exit, Anda akan diarahkan ke halaman S3 bucket. Silakan masuk ke tab Properties dan gulir halaman ke paling bawah sampai Anda menemukan bagian Static website hosting.
    
    
    

15. Klik tombol Edit pada bagian Static website hosting.
    
    
    

16. Klik Enable untuk mengaktifkan fitur. Pastikan juga pada bagian Hosting type yang dipilih adalah Host a static website. Terakhir, untuk bagian Index document, Anda bisa isikan dengan index.html. Jika sudah, silakan gulir halaman ke paling bawah dan klik Save changes.
    
    
    

17. Anda akan diarahkan ke halaman S3 bucket di tab Properties. Lanjut, scroll halaman ke paling bawah hingga menemukan tautan website statis Anda. Coba klik link URL yang tersedia untuk membuka halaman website Anda.
    
    
    

18. Waduh, kenapa bisa seperti ini ya? Tahukah Anda apa penyebabnya? Tenang, ini karena kita belum mengatur bucket policy.
    
    

19. Pada S3 bucket, silakan masuk ke tab Permissions.
    
    
    

20. Gulir halaman sampai ke bagian Bucket policy, lalu klik Edit.
    
    
    

21. Silakan salin kode di bawah ini dan tempel di bucket policy Anda. Perhatikan! Ubah bagian Bucket-ARN sesuai dengan ARN yang ada di bucket Anda. Jika Anda merasa kesulitan, silakan cek langkah selanjutnya!

    {
      "Version": "2012-10-17",
      "Statement": [
            {
                "Sid": "PublicReadGetObject",
                "Effect": "Allow",
                "Principal": "*",
                "Action": "s3:GetObject",
                "Resource": "Bucket-ARN/*"
            }
      ]
    }

    Saran: Gunakanlah teks editor dalam melakukan copy-paste bucket policy untuk mencegah terjadinya eror.
    
    

22. Bucket ARN Anda tertera di bagian atas teks editor. Hasilnya akan seperti gambar di bawah. Jika sudah, klik Save changes.
    
    
    

23. Silakan kembali ke tab browser yang tadi Anda coba untuk membuka alamat URL website pada langkah ke-17, kemudian lakukan refresh. Boom!
    
    
    

Selamat! Dengan menyelesaikan latihan ini, Anda sudah berhasil melakukan hosting website statis di AWS menggunakan layanan Amazon S3. Mudah, bukan? 

Kalau begitu, mari kita lanjut ke modul berikutnya untuk memasuki materi yang lebih menantang! Ready, Set, Go!

Clean Up Menurut halaman AWS Free Tier, Anda dapat menyimpan 5 GB gratis selama 12 bulan di Amazon S3. Namun, karena di latihan berikutnya kita tak akan lagi menggunakan Amazon S3 dan juga untuk menghindari penagihan di masa mendatang, silakan hapus S3 bucket yang telah Anda buat beserta isinya. Caranya, silakan ikuti langkah-langkah berikut: Masuk ke halaman Amazon S3. Pilih bucket Anda. Klik tombol Delete.

Ikhtisar

Di modul ini, kita sudah mempelajari beberapa hal terkait arsitektur yang sederhana, antara lain:

• Amazon S3
  Amazon S3 adalah layanan dari AWS untuk menyimpan file berbasis objek (object storage). Artinya, file yang disimpan di S3 akan diperlakukan sebagai sebuah objek yang utuh. Kita juga telah menguraikan beberapa kasus penggunaan pada Amazon S3. Bahkan, kita telah belajar tentang Amazon S3 Glacier dan apa perbedaannya dengan Amazon S3.
  
  

• Memilih Region
  Dalam memilih region, kita telah belajar terkait cara memilih region untuk membangun arsitektur. Ada 4 faktor, yakni compliance (kepatuhan), kedekatan lokasi, ketersediaan fitur, dan biaya.

Pengantar ke Menambahkan Lapisan Komputasi

Mari kembali ke skenario startup warung kopi yang saat ini sudah mulai berkembang. Kita telah melakukan promosi dengan gencar sehingga banyak orang yang mengunjungi website warung kopi. Dari perorangan hingga perusahaan besar sudah tahu bahwa produk dari startup kita--yakni warung kopi terbaik di dunia--akan segera rilis. Selamat untuk itu!

Tapi, tunggu. Pada modul sebelumnya kita hanya belajar cara meng-hosting website statis, apakah itu cukup? Hmm, jika sekedar menaruh informasi bahwa warung kopi kita akan rilis, mungkin cukup. Namun sayangnya, sekarang kebutuhan kita lebih dari itu.

Begini kebutuhannya. Dalam waktu dekat, kita akan merilis sebuah website penjualan kopi secara online, mari kita singkat sebagai “Warung Kopi”. Website ini tentu saja membutuhkan server yang dipakai untuk men-deploy aplikasi yang lebih canggih dan storage untuk menyimpan berbagai data, baik informasi pengguna, riwayat transaksi, hingga stok biji kopi.

Nah melihat kebutuhan tersebut, kita tidak bisa hanya mengandalkan website statis. Maka solusinya, kita memerlukan website yang dinamis.

Untuk itulah di modul ini kita akan belajar berbagai hal mengenai layanan komputasi di AWS, antara lain:

• Server
  Kita akan bahas banyak hal terkait layanan server di AWS, dari Amazon Elastic Compute Cloud (Amazon EC2), Amazon Machine Images, hingga EC2 Image Builder.
  
  
• Storage
  Kita akan mengulas beberapa materi tentang storage di AWS, seperti Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), dan Amazon FSx.

Nah, sebelum masuk ke pembahasan, mari kita amati gambar di bawah yang mengilustrasikan perkembangan arsitektur yang sesuai dengan perjalanan kita di kelas ini.

Gambar di atas menjelaskan perkembangan arsitektur yang telah kita lalui. Pada modul sebelumnya, arsitektur yang kita miliki hanyalah berupa S3 bucket untuk meng-hosting website statis. Nah di modul ini, arsitektur yang kita miliki akan semakin berkembang karena adanya penambahan layanan, seperti Amazon EC2 instance, Amazon EFS Mount Target, dan Amazon EFS.

Tenang, jangan dulu pusing. Mari kita bahas secara mendalam di modul ini!

Amazon EC2

Pada awal modul, telah dijelaskan bahwa startup warung kopi kita membutuhkan layanan server untuk dapat men-deploy aplikasi yang lebih canggih sebelum akhirnya rilis dan dapat dinikmati oleh pelanggan.

Nah, AWS memberikan solusi untuk kebutuhan ini. Perkenalkan, Amazon EC2 alias Amazon Elastic Compute Cloud. Sederhananya, Amazon EC2 itu sama seperti server lokal tradisional, bedanya ia tersedia di cloud.

Amazon EC2 dapat mendukung berbagai beban kerja, seperti web hosting, aplikasi, database, layanan autentikasi, dan hal lain yang dapat dilakukan server pada umumnya.

Amazon EC2 menyediakan kapasitas komputasi yang dapat melakukan scaling (penyesuaian kapasitas) di AWS Cloud. Dengan menggunakan Amazon EC2, Anda dapat menghilangkan kebutuhan berinvestasi di awal untuk perangkat keras. Dengan begitu, Anda dapat mengembangkan dan men-deploy aplikasi lebih cepat.

Anda juga dapat menggunakan Amazon EC2 untuk meluncurkan server virtual dengan jumlah sesuai kebutuhan, mengkonfigurasi keamanan dan jaringan, serta mengelola penyimpanan. Bahkan, Amazon EC2 memudahkan Anda untuk mengatur kebutuhan server sesuai dengan permintaan yang ada.

Oke, sekarang mari kita telaah apa saja fitur dari Amazon EC2. Berikut adalah poin-poinnya:

• Instance : Virtual computing environments.
• Amazon Machine Image (AMI) : Preconfigured template untuk instance, yakni informasi mengenai paket yang akan dikemas untuk kebutuhan server Anda (termasuk sistem operasi dan aplikasi yang diperlukan).
• Instance type (tipe instance) : Berbagai macam konfigurasi CPU, memori, penyimpanan, dan kapasitas jaringan untuk instance.
• Key pairs : Secure login information untuk instance (AWS menyimpan public key, sementara user menyimpan private key).
• Instance store volume : Penyimpanan sementara yang akan terhapus apabila instance dihentikan atau diakhiri.
• Amazon EBS volume : Volume penyimpanan yang persisten untuk data Anda dengan menggunakan layanan Amazon EBS.
• Regions dan Availability Zone : Beberapa lokasi fisik untuk resource (sumber daya) Anda, seperti instance dan Amazon EBS volume.
• Security groups : Berfungsi sebagai firewall untuk menspesifikasi protocol, port, dan IP address sumber yang ingin menjangkau instance Anda.
• Elastic IP addresses : IPv4 statis yang didesain untuk dynamic cloud computing.
• Tags : Metadata yang dapat Anda buat dan tetapkan untuk Amazon EC2 resource.
• Virtual Private Cloud (VPC) : Jaringan virtual yang digunakan untuk mengisolasi rangkaian sistem kita di AWS Cloud agar hanya dapat diakses oleh pihak-pihak tertentu.

Bagaimana, sudah paham? Intinya, Amazon EC2 adalah layanan server di AWS Cloud. Poin-poin yang dijabarkan di atas semuanya berkaitan dengan Amazon EC2. Tak perlu khawatir, setiap poin akan kita bahas secara mendalam dan terpisah di modul yang akan datang.

Jenis Harga EC2 Instance

Setelah belajar mengenai pengertian dan juga fitur-fitur dari Amazon EC2, sekarang mari kita berbincang terkait jenis harga atau pricing plan dari EC2 instance.

Oke, kembali ke skenario startup warung kopi kita. Saat nanti rilis, kita tidak tahu kapan waktu pengunjung akan ramai atau sepi. Tapi, jangan khawatir soal itu. Pada materi sebelumnya kita telah belajar kan bahwa Amazon EC2 mampu untuk melakukan scaling (menyesuaikan kapasitas) sesuai permintaan yang ada.

Namun, jika kita berbicara tentang scaling, pasti akan erat hubungannya dengan harga alias pricing. Jadi, mari kita bahas apa saja jenis-jenis harga pada Amazon EC2 yang dapat Anda pilih sesuai dengan kebutuhan.

EC2 merupakan salah satu layanan yang di-cover pada AWS Free Tier, pelanggan AWS yang baru mendaftar dapat segera memulai dengan t2.micro instance, S3 bucket, dan banyak penawaran layanan AWS lainnya yang dapat digunakan secara gratis hingga satu tahun yang dihitung sejak akun dibuat.

Dari AWS Free Tier, mari kita beranjak masuk ke materi berbagai jenis harga yang ditawarkan Amazon EC2. Silakan amati gambar berikut:

Dapat Anda lihat pada gambar di atas bahwa Amazon EC2 menawarkan 4 jenis harga, antara lain:

• On-Demand Instances
  Ada banyak keuntungan saat Anda menggunakan On-Demand Instances, yakni:
  • Anda membayar untuk penggunaan kapasitas komputasi per detik (Amazon Linux dan Ubuntu) atau per jam (semua OS lainnya).
  • Tanpa komitmen jangka panjang.
  • Tanpa pembayaran di muka.
  • Anda dapat meningkatkan atau mengurangi kapasitas komputasi Anda sesuai kebutuhan.
    
    
• Reserved Instances
  Reserved Instances (RI) bisa sangat membantu mengurangi biaya penggunaan dalam arsitektur Anda. Jika Anda dapat mengetahui tingkat penggunaan dasar untuk EC2 instance Anda, RI dapat memberikan diskon yang signifikan.
  
  Anda dapat menyiapkan RI dengan berbagai cara:
  • Standard RI : Memberikan diskon yang signifikan (hingga 75% dari harga On-Demand) dan digunakan untuk penggunaan dengan kapasitas yang sudah stabil dan tidak berubah-ubah (steady-state usage).
  • Convertible RI : Memberikan diskon (hingga 54% dari harga On-Demand) di mana penggunaannya masih dapat mengubah atribut RI selama perubahan tersebut menghasilkan RI dengan biaya yang sama atau lebih besar.
  • Scheduled RI : RI ini dimaksudkan untuk digunakan dalam jadwal dan jangka waktu yang Anda inginkan. Dengan begitu, opsi ini dapat memungkinkan Anda untuk menyesuaikan dengan kebutuhan kapasitas dalam waktu tertentu.
    
    Jangka waktu: AWS menawarkan Standard RI untuk jangka waktu 1 atau 3 tahun. Alternatif lainnya, beberapa vendor di Marketplace Reserved Instance juga menawarkan RI dengan jangka waktu yang lebih pendek. Selain itu, AWS menawarkan Convertible RI untuk jangka waktu 1 atau 3 tahun.
    
    Opsi pembayaran: Anda kemudian dapat memilih di antara tiga opsi pembayaran (All Upfront, Partial Upfront, dan No Upfront). Dan apabila Anda memilih opsi pembayaran Partial Upfront atau No Upfront, sisa saldo akan jatuh tempo setiap bulan selama jangka waktu tersebut.
    
    
• Savings Plans
  Savings Plans adalah model harga yang fleksibel yang menawarkan penghematan hingga 72% pada penggunaan komputasi AWS Anda. Terdapat dua jenis Savings Plans:
  • Compute Savings Plans
    Compute Savings Plans memberikan fleksibilitas paling besar dan membantu mengurangi biaya Anda hingga 66% (seperti Convertible RI). Paket tersebut secara otomatis berlaku untuk semua EC2 instance apa pun terlepas dari Region, instance family, sistem operasi, atau tenancy. Bahkan, termasuk yang merupakan bagian dari klaster EMR, ECS, maupun EKS, atau yang diluncurkan oleh Fargate.
    
    Misalnya, dengan Compute Savings Plans, Anda dapat beralih dari C4 ke C5 instance, memindahkan beban kerja dari Dublin ke London, atau bermigrasi dari EC2 ke Fargate. Bahkan, Anda bisa mendapatkan keuntungan dari harga Savings Plans selama penggunaan tanpa harus melakukan apa pun.
    
    
  • EC2 Instance Savings Plans
    EC2 Instance Savings Plans berlaku untuk instance family tertentu dalam suatu Region (misal, penggunaan M5 di N.Virginia) dan dapat memberikan diskon terbesar (hingga 72%, seperti RI Standard).
    
    Sama seperti RI, Savings Plans juga mencakup penggunaan perubahan ukuran instance yang berbeda dari tipe instance yang sama (seperti c5.4xlarge atau c5.large) di seluruh Region. Bahkan, Anda dapat beralih dari Windows ke Linux sambil terus menggunakannya tanpa harus melakukan perubahan apa pun pada Savings Plans Anda.
    
    
• Spot Instances
  AWS telah membangun kapasitas komputasi untuk volume penggunaan tertinggi dari On-Demand. Nah, ada saatnya AWS memiliki kapasitas yang tidak terpakai yang dapat digunakan para pelanggan dengan diskon hingga 90% yang dapat digunakan berdasarkan permintaan sebagai Spot Instances.
  
  Anda tidak perlu menawar (bid) untuk mendapatkan Spot Instances. Anda cukup membayar penggunaan per jam untuk instance yang diluncurkan.
  
  Anda dapat melakukan request (permintaan) untuk kapasitas Spot Instances seperti halnya mengajukan request kapasitas On-Demand. Sehingga, Anda tak perlu lagi menghabiskan waktu untuk menganalisis harga pasar atau menetapkan harga penawaran tertinggi (spot instances tidak lagi menggunakan aturan bidding untuk pengajuan penggunaannya).
  
  Namun, terkadang AWS perlu mengklaim kembali kapasitas Spot Instances yang Anda gunakan untuk melayani pelanggan On-Demand. Dalam situasi ini, AWS akan mengeluarkan pemberitahuan dalam waktu 2 menit sebelum pemberhentian layanan, dengan tujuan untuk memungkinkan pengguna mengambil tindakan sebelum terjadinya interupsi. Pemberitahuan tersebut akan dikirimkan melalui instance metadata dan juga dalam Cloudwatch Events.
  
  Untuk menggunakan Spot Instances, beban kerja Anda harus memiliki keleluasaan terhadap tipe instance, lokasi (Region dan/atau AZ, dan waktu penggunaan (di luar jam sibuk).
  
  Kasus penggunaan yang populer untuk Spot Instances adalah untuk kebutuhan container (ECS / EKS / Kubernetes), pemrosesan big data (EMR - Hadoop), dan HPC (high performance computing alias komputasi berkinerja tinggi).

Penggunaan Amazon EC2 untuk instance berbasis Amazon Linux dan Ubuntu yang diluncurkan dalam bentuk On-Demand, Reserved, dan Spot akan dihitung dalam hitungan per detik, dengan minimal penggunaan selama 60 detik. Sedangkan untuk semua sistem operasi lain akan ditagihkan dalam kelipatan satu jam. Dan tidak ada perbedaan sama sekali antara Reserved Instance dan On-Demand Instance dari sisi kemampuan maupun fitur.

Oke, itulah pembahasan kita terkait harga untuk EC2 instance. Dengan mempelajarinya, semoga Anda bisa semakin mantap dalam memilih jenis pricing yang tepat sesuai kebutuhan.

Namun, muncullah suatu pertanyaan, “Bagaimana jika semua opsi tersebut masih belum pas dengan kebutuhan kita?” Simak jawabannya di modul selanjutnya ya!

EC2 Dedicated Instance & Host

Mari kita lanjutkan pertanyaan yang belum terjawab pada modul sebelumnya, “Bagaimana jika semua opsi tersebut masih belum pas dengan kebutuhan kita?”

Mari kita tarik kembali skenario startup warung kopi ke materi ini. Katakanlah investor yang mendanai startup Anda memiliki keinginan tertentu yang harus dipenuhi, yakni aplikasi yang Anda kembangkan harus berada hanya di satu server fisik dan tidak berbagi dengan pelanggan AWS lain. Atau, misalnya Anda membeli software khusus yang menggunakan lisensi berbasis perangkat keras, seperti lisensi yang dihitung per socket CPU.

Nah, jika Anda memiliki kebutuhan seperti itu, AWS dapat memberikan solusi dengan menghadirkan EC2 Dedicated Host.

Untuk mempermudah penjelasan, mari kita bahas dari teknologi yang dipakai oleh Amazon EC2 terlebih dahulu.

Ketahuilah! Amazon EC2 menggunakan teknologi yang umumnya dikenal sebagai virtualization (virtualisasi) untuk menjalankan beberapa sistem operasi pada satu mesin fisik. Virtualisasi memastikan setiap guest OS menerima bagian yang adil dari waktu CPU, memori, dan bandwidth I/O ke disk lokal dan ke jaringan menggunakan sistem operasi host. Terkadang, virtualization juga dikenal sebagai hypervisor.

Hypervisor mengisolasi sistem operasi pelanggan dari yang satu dengan lainnya sehingga satu pelanggan tidak dapat memodifikasi atau mengganggu pelanggan yang lain pada mesin yang sama. Saat ini, AWS menggunakan versi Xen hypervisor yang sangat disesuaikan (highly customized). Ketahuilah, AWS adalah partisipan aktif dalam komunitas Xen dan akan terus aktif untuk mengikuti semua perkembangan terbaru.

Meskipun isolasi logis ini berfungsi dengan sangat baik untuk sebagian besar kasus penggunaan EC2, beberapa pelanggan AWS memiliki peraturan atau batasan yang mewajibkan keperluan isolasi fisik. Dan layanan baru akhirnya diperkenalkan pada tahun 2011 untuk menangani kebutuhan ini, yaitu EC2 Dedicated Instance dan Dedicated Host.

 

EC2 Dedicated Instance

Dedicated Instance adalah Amazon EC2 instance yang berjalan di VPC pada perangkat keras yang didedikasikan untuk satu pelanggan. Dedicated Instance diisolasi secara fisik pada tingkat perangkat keras host dengan instance milik akun AWS lainnya. 

Harga untuk Dedicated Instance memiliki dua komponen:

• Biaya penggunaan per jam.
• Biaya khusus per region (biaya ditagihkan sekali per jam terlepas dari berapa banyak Dedicated Instance yang Anda jalankan).

Ingat! Dengan menggunakan Dedicated Instance, bukan berarti mesin virtual EC2 kita akan berada di perangkat keras server yang sama setiap waktu. Selain itu, Dedicated Instance memiliki biaya yang lebih mahal daripada instance biasa.

EC2 Dedicated Host

Dedicated Host (Host Khusus) adalah server EC2 fisik dengan kapasitas instance yang sepenuhnya didedikasikan untuk Anda. Dengan Dedicated Host, Anda dapat menggunakan lisensi perangkat lunak yang memenuhi syarat dari vendor seperti Microsoft dan Oracle di Amazon EC2.

Ini membuat Anda bisa mendapatkan fleksibilitas dan efektivitas biaya dengan menggunakan lisensi yang Anda punya, tetapi juga dengan ketahanan, kemudahan, dan elastisitas AWS. Dengan begitu, Dedicated Host dapat membantu Anda memenuhi persyaratan compliance dari vendor atau regulator tertentu.

Dedicated Host juga dapat digunakan jika aplikasi Anda membutuhkan latensi minimal di antara setiap instance. Selain itu, Dedicated Host juga dapat memberi Anda visibilitas dan kontrol tambahan atas bagaimana instance ditempatkan di server fisik. Bahkan, Anda bisa secara konsisten meluncurkan instance ke server fisik yang sama dari waktu ke waktu.

Dedicated Host dapat dibeli On-Demand (setiap jam). Tetapi, Anda juga dapat melakukan reservasi yang mana akan memberikan diskon hingga 70% dibandingkan dengan harga On-Demand.

Setelah mengenal apa itu Dedicated Host, mari kita menilik manfaat dari Dedicated Host, antara lain:

• Menghemat uang untuk biaya lisensi: Dedicated Host memungkinkan Anda untuk menghemat uang dengan menggunakan lisensi perangkat lunak per socket atau per core untuk Anda pribadi di Amazon EC2.
• Membantu memenuhi persyaratan compliance dan regulasi: Dedicated Host memungkinkan Anda menempatkan instance di VPC pada server fisik tertentu. Ini memungkinkan Anda untuk meluncurkan instance menggunakan konfigurasi yang dapat membantu menangani compliance perusahaan dan persyaratan regulasi.

Tabel berikut memberikan ulasan singkat mengenai perbedaan instance EC2.

	Hanya akun AWS Anda yang ada di perangkat keras server?	Penjelasan
Default	Tidak	Berbagi pakai dengan pengguna lain.
Dedicated Instance	Yes	Berjalan di perangkat keras server yang tidak dapat ditentukan.
Dedicated Host	Yes	Berjalan di perangkat keras server yang Anda tentukan, ini dapat memberikan kendali yang lebih besar.

Nah, sampailah kita di akhir pembahasan terkait Dedicated Instance dan Dedicated Host. Dengan ini, Anda diharapkan sudah bisa memutuskan apakah beban kerja Anda memerlukan opsi Dedicated atau tidak.

Pertimbangan Arsitektural

Sebelum masuk ke pembahasan, mari kita ingat sejenak materi terkait Amazon EC2. EC2 instance adalah sebuah server virtual di AWS. Oleh karena itu, kita tak bisa memakainya secara sembarangan, melainkan kita harus menyesuaikannya dengan beban kerja sesuai kebutuhan.

Misalnya, apabila Anda memiliki kebutuhan untuk menjalankan komputasi yang memiliki latensi serendah mungkin. Solusinya, bangunlah arsitektur berjenis Cluster Placement Groups. Masih ada beberapa opsi arsitektur lainnya yang dapat Anda pertimbangkan sesuai kebutuhan, silakan pahami uraian berikut:

• Pertimbangan Arsitektural 1: Apakah lapisan komputasi Anda memerlukan latensi terendah dan throughput setinggi mungkin?
  
  Jika jawabannya iya, maka pertimbangkanlah untuk menggunakan arsitektur Cluster Placement Groups.
  Cluster Placement Groups adalah pengelompokan logis dari instance dalam satu Availability Zone. Pengelompokan ini memberikan latensi terendah dan kinerja jaringan packet-per-second tertinggi.Contoh dari penggunaan arsitektur jenis ini adalah aplikasi yang menggunakan High Performance Computing.
  
  
• Pertimbangan Arsitektural 2: Apakah Anda memiliki aplikasi yang punya beberapa critical instance dan harus ditempatkan terpisah dari instance lainnya? Pertimbangkanlah untuk menggunakan arsitektur Spread Placement Groups jika kasus Anda serupa dengan pertanyaan tersebut.
  Spread Placement Groups adalah pengelompokan instance yang sengaja ditempatkan pada perangkat keras yang berbeda. Dengan begitu, pengelompokan ini mengurangi risiko kegagalan secara simultan yang dapat terjadi jika instance berbagi perangkat keras yang mendasarinya.Jenis dari pengelompokkan ini juga dapat menjangkau beberapa Availability Zone, hingga maksimum tujuh instance untuk setiap Availability Zone per grup.Salah satu contoh yang menggunakan arsitektur jenis ini adalah front-end server yang memiliki high availability (ketersediaan tinggi) yang lebih baik.
  
  
• Pertimbangan Arsitektural 3: Apakah Anda memiliki beban kerja yang terdistribusi dan tereplikasi secara masif, misalnya aplikasi big data seperti HDFS, HBase, dan Cassandra yang dijalankan di EC2? Gunakanlah arsitektur Partition Placement Groups jika beban kerja Anda sesuai dengan poin ke-3 ini.
  Partition Placement Groups menempatkan EC2 instance di seluruh logical partition dan memastikan bahwa instance di partisi yang berbeda tidak berbagi perangkat keras yang sama, sehingga dampak kegagalan perangkat keras akan terjadi hanya ke satu partisi saja. Selain itu, partition placement groups menawarkan visibilitas ke dalam partisi dan memungkinkan topology aware applications (aplikasi yang sadar topologi) yang menggunakan informasi ini untuk membuat keputusan replikasi data yang cerdas, meningkatkan ketersediaan, dan ketahanan data.

Amazon Machine Images

Amazon Machine Image (AMI) adalah sebuah virtual image yang digunakan untuk meluncurkan EC2 instance. Saat meluncurkan sebuah instance, Anda harus menentukan AMI terlebih dahulu, baik yang sudah disediakan AWS, yang Anda buat sendiri, atau melalui AWS Marketplace.

Image yang dimaksud adalah seperti template yang telah dikonfigurasi. Ia berisikan sistem operasi dan perangkat lunak yang dibutuhkan.

Dengan AMI, Anda bisa meluncurkan beberapa instance dengan konfigurasi yang identik hanya dari satu AMI saja. Namun jika Anda ingin meluncurkan instance dengan konfigurasi yang berbeda, maka Anda dapat menggunakan AMI yang berbeda.

Berikut adalah uraian dari beberapa hal yang termuat di sebuah AMI, antara lain:

• Penggunaan satu atau beberapa Amazon Elastic Block Store (Amazon EBS).
• Template untuk root volume dari sebuah instance (misalnya, sistem operasi, server aplikasi, dan aplikasi).
• Launch permission, mengontrol akun AWS mana yang dapat menggunakan AMI Anda untuk meluncurkan instance.
• Block device mapping (pemetaan perangkat blok), menentukan berapa volume yang akan dilampirkan ke instance saat diluncurkan.

Saat membuat, membangun, menyimpan, dan mendistribusikan AMI yang Anda buat sendiri atau container image, Anda akan dikenakan biaya tergantung pada konfigurasinya. Berikut adalah contoh daftar penggunaannya:

• Meluncurkan Amazon EC2 instance.
• Menyimpan log di Amazon S3.
• Melakukan validasi image dengan Amazon Inspector.
• Menyimpan Amazon EBS Snapshot untuk AMI Anda.
• Menyimpan container image di Amazon ECR.
• Mengunggah (pushing) dan mengunduh (pulling) container image ke dalam dan ke luar Amazon ECR.
• Mengaktifkan Systems Manager Advanced Tier dan menjalankan Amazon EC2 instance dengan aktivasi on-premise akan dikenai biaya melalui Systems Manager.

Oke, setelah belajar mengenai apa saja yang dapat menimbulkan biaya pada AMI, sekarang mari kita tinjau hal-hal yang AMI bisa lakukan untuk membantu Anda, di antaranya:

• Repeatability
  Menggunakan AMI dapat membantu memecahkan banyak masalah, yang pertama adalah repeatability alias kemampuan untuk melakukan pengulangan. Maksudnya, instances yang akan dihasilkan dari AMI yang sama akan menjadi sebuah replika antara satu sama lain.
  
  Maka dari itu, AMI bisa memudahkan Anda untuk membangun cluster dari instance serupa atau membuat ulang sebuah lingkungan komputasi.
  
  
• Reusability
  AMI mengemas konfigurasi lengkap dan konten dari EC2 instance sehingga dapat digunakan berulang kali, dengan efisiensi dan presisi.
  
  
• Recoverability
  AMI sangat ideal untuk mengganti mesin yang gagal dengan instance baru yang dibuat dari AMI yang sama.
  
  
• Marketplace Solutions
  Jika Anda mencari solusi perangkat lunak dari vendor tertentu, mungkin Anda akan dapat menemukan AMI di Marketplace yang dapat diluncurkan untuk menerapkan solusi yang diinginkan pada EC2 instance tersebut.
  
  
• Backups
  AMI menyediakan cara terbaik untuk melakukan backup terhadap konfigurasi EC2 instance secara lengkap yang dapat Anda gunakan untuk meluncurkan instance pengganti jika suatu saat terjadi kegagalan.

EC2 Image Builder

EC2 Image Builder memudahkan Anda untuk membuat, menguji, dan menerapkan server image dan container image untuk digunakan di AWS atau on-premise.

Sebelumnya, menjaga image agar tetap up-to-date adalah proses yang memakan waktu dan rawan untuk terjadi kesalahan. Nah, maka dari itu, hadirlah EC2 Image Builder yang dapat memberikan solusi.

EC2 Image Builder secara signifikan mengurangi upaya Anda untuk selalu memperbarui dan mengamankan image dengan menyediakan antarmuka yang sederhana, automasi, dan memiliki pengaturan keamanan yang disediakan AWS.

Anda dapat menggunakan EC2 Image Builder dengan berbagai metode: AWS Management Console, AWS CLI, atau API.

Tahukah Anda? Tidak ada biaya yang dibutuhkan saat menggunakan EC2 Image Builder untuk membuat container image atau AMI Anda sendiri. Namun, harga standar akan berlaku untuk layanan lain yang terlibat digunakan dalam proses tersebut.

Oke, kita telah sampai di akhir dari bagian pembahasan server. Seperti pada skenario awal, selain server, kita juga memerlukan storage yang berguna untuk menyimpan berbagai data, seperti informasi pengguna, riwayat transaksi, bahkan stok biji kopi.

Oleh karenanya, yuk kita bahas layanan storage yang tersedia di AWS secara mendetail di modul berikutnya. Keep the spirit up!

Amazon EBS

Sampai di tahap ini, Anda sudah memahami seputar layanan server yang tersedia di AWS. Tentu itu akan membantu kita dalam men-deploy aplikasi menjadi lebih cepat tersedia dengan proses yang lebih baik sehingga website warung kopi pun dapat segera rilis.

Masih ada hal lain yang kita butuhkan sebelum merilis website tersebut, yakni layanan storage. Di modul ini, layanan storage yang akan kita kupas tuntas adalah Amazon EBS.

Sekarang mungkin Anda akan bertanya, “Bukankah salah satu fitur dari Amazon EC2 adalah memiliki instance store volume yang mana dapat digunakan untuk penyimpanan juga?”

Oke, mari kita bahas sejenak. Seperti yang telah dijelaskan sebelumnya, instance store volume itu memang dapat menyimpan data di EC2 instance. Namun, ia menyimpan data secara sementara sehingga jika Anda menghentikan instance, semua data di dalamnya akan terhapus.

Berbeda jika Anda menggunakan Amazon EBS volume. Ia dapat menyimpan data secara persisten sehingga walaupun Anda menghentikan instance, data di dalamnya akan tetap tersedia.

Amazon Elastic Block Store (Amazon EBS) menyediakan volume penyimpanan tingkat blok (block-level storage) untuk digunakan bersama EC2 instance. EBS volume yang dilampirkan ke sebuah instance adalah volume penyimpanan yang persisten dan independen dari masa pakai instance.

Anda dapat menggunakan Amazon EBS untuk data yang harus dapat diakses dengan cepat dan membutuhkan penyimpanan jangka panjang.

EBS volume sangat cocok digunakan sebagai penyimpanan utama untuk sistem file, database, atau apa pun yang Anda inginkan layaknya hard drive.

Selain itu, dengan EBS, Anda dapat secara dinamis mengubah konfigurasi volume yang dilampirkan ke sebuah instance. AWS juga menyediakan beragam jenis EBS volume yang berbeda dalam karakteristik kinerja dan harga sesuai kebutuhan aplikasi. Silakan amati gambar di bawah ini (klik gambar untuk visibilitas yang lebih jelas).

Volume yang mendukung SSD, optimal untuk beban kerja transaksional yang melibatkan operasi read (baca) / write (tulis) yang sering dengan ukuran I/O (input/output) yang kecil, di mana atribut kinerja yang dominan adalah IOPS.

Volume yang mendukung HDD, optimal untuk beban kerja streaming yang besar di mana throughput (diukur dalam MiB / detik) adalah ukuran kinerja yang lebih baik daripada IOPS.

Amazon EFS

Amazon EFS atau Amazon Elastic File System adalah layanan file system yang terkelola. Eits, tahan dulu! Sebelum membahasnya lebih lanjut, mari kita tilik tentang apa itu file system terlebih dahulu.

Sederhananya, file system adalah proses mengelola bagaimana dan di mana data pada suatu disk/drive disimpan dan diakses. Umumnya, file system mengatur berbagai hal seperti manajemen penyimpanan, pemberian nama pada file, pengelompokan file ke dalam grup, pengaturan mengenai akses data, dan lainnya.

Oke, sekarang Anda sudah paham tentang file system. Mari kita masuk ke pembahasan Amazon EFS.

Amazon Elastic File System (Amazon EFS) menyediakan sistem file yang sederhana, dapat diskalakan, dan elastis untuk beban kerja berbasis Linux. Ia dapat digunakan dengan layanan AWS Cloud dan sumber daya on-premise.

Anda dapat mengakses sistem file di seluruh Availability Zone, AWS Regions, dan VPC sambil berbagi file antara ribuan EC2 instance dan server on-premise melalui AWS Direct Connect atau AWS VPN.

Anda dapat membuat sistem file, memasangnya pada Amazon EC2 instance, lalu melakukan proses read (baca) dan write (tulis) data ke dan dari sistem file. Anda juga dapat memasang sistem file Amazon EFS di VPC melalui protokol Network File System versi 4.0 dan 4.1 (NFSv4).

Ketahuilah! Sistem file Amazon EFS dapat diakses secara bersamaan dari Amazon EC2 instance di Amazon VPC, sehingga aplikasi yang berskala lebih dari satu koneksi dapat mengakses sistem file.

Amazon EC2 instance yang berjalan di beberapa Availability Zone di dalam region yang sama dapat mengakses sistem file, sehingga banyak pengguna dapat mengakses dan berbagi sumber data yang sama.

Amazon FSx

Modul ini masih berhubungan dengan materi sebelumnya, yakni file system. Bedanya, di sini kita akan membahas tentang layanan file system pihak ketiga dengan kompatibilitas dan rangkaian fitur yang native (asli) untuk beban kerja seperti penyimpanan berbasis Microsoft Windows, komputasi berkinerja tinggi, hingga machine learning.

Amazon FSx memberi Anda dua sistem file yang dapat dipilih: Amazon FSx for Windows File Server (untuk aplikasi berbasis Windows) dan Amazon FSx for Lustre (untuk beban kerja komputasi yang intensif).

Amazon FSx for Windows File Server 

Opsi ini dirancang untuk aplikasi perusahaan dan merupakan layanan fully managed (terkelola sepenuhnya) yang didukung oleh sistem file windows asli. Ini adalah aplikasi perusahaan yang dapat dengan mudah dilakukan lift and shift alias pemindahan ke Amazon Web Services.

Amazon FSx for Windows File Server dibangun pada penyimpanan SSD. Ia ideal untuk mendukung beban kerja Windows yang membutuhkan penyimpanan bersama seperti CRM, ERP, aplikasi .NET, dan direktori home pengguna.

Ribuan instance komputasi dapat mengakses satu sistem file Amazon FSx pada waktu bersamaan, yang mana juga dapat menyediakan akses dari on-premise melalui AWS Direct Connect atau AWS VPN. Bahkan, ia juga memungkinkan akses dari beberapa VPC, akun, dan region menggunakan VPC Peering atau AWS Transit Gateway.

Amazon FSx for Windows File Server menyediakan sistem penyimpanan file bersama untuk Amazon EC2 instance dengan sistem operasi Windows dengan tingkat throughput yang tinggi dan latensi yang rendah.

• Amazon FSx untuk Windows File Server mendukung:
• Protokol SMB
• Windows NTFS
• Integrasi Active Directory (AD)
• Distributed File System (DFS) alias Sistem File Terdistribusi

Amazon FSx for Windows File Server juga dapat dipasang pada Amazon EC2 instance Linux. Untuk informasi detailnya, silakan lihat Using Microsoft Windows File Shares.

Amazon FSx untuk Lustre

Amazon FSx for Lustre menyediakan sistem file serupa yang dikelola sepenuhnya dan dioptimalkan untuk High Performance Computing (HPC) alias komputasi berkinerja tinggi, machine learning, dan alur kerja pemrosesan media.

Satu sistem file Amazon FSx for Lustre dapat memproses kumpulan data yang masif dengan ratusan gigabyte (GB) per detik throughput pada latensi sub-milidetik.

Amazon FSx for Lustre dapat diintegrasikan dengan Amazon S3 sehingga Anda dapat menggabungkan kumpulan data jangka panjang dengan sistem file berperforma tinggi. Data dapat disalin secara otomatis ke dan dari Amazon S3 dari sistem file Amazon FSx for Lustre Anda.

Amazon FSx untuk Lustre telah POSIX-compliant, sehingga Anda dapat menggunakan aplikasi berbasis Linux tanpa harus melakukan perubahan apa pun.

FSx for Lustre menyediakan antarmuka sistem file yang native dan berfungsi seperti halnya sistem file apa pun dengan OS Linux. Ini juga memberikan konsistensi read-after-write dan mendukung file-locking (penguncian file). Anda juga dapat mengontrol akses ke sistem file FSx for Lustre dengan permission dari POSIX dan Amazon Virtual Private Cloud (VPC). Bahkan, Amazon FSx for Lustre juga dapat dipasang ke Amazon EC2 instance.

Nah, kita sudah lihat kan opsi untuk Amazon FSx. Kedua penawaran tersebut mendukung koneksi dengan beban kerja on-premise menggunakan AWS Direct Connect atau koneksi VPN. Dengan kedua penawaran tersebut, Anda hanya membayar sumber daya yang digunakan.

Ikhtisar

Di modul ini kita telah mempelajari banyak hal mengenai layanan server dan storage dari AWS, yaitu:

• Server
  • Amazon EC2, yaitu layanan penggunaan Virtual Machines (VM) dari AWS yang hadir dengan banyak kombinasi pilihan antara CPU, GPU, dan Memory.
  • Amazon Machine Images, menyimpan informasi mengenai konfigurasi dari EC2.
  • EC2 Image Builder, layanan pembuatan konfigurasi image yang dikelola sepenuhnya oleh AWS.
• Storage
  • Amazon EBS, layanan block level storage atau dikenal juga sebagai disk yang digunakan oleh EC2.
  • Amazon EFS, layanan storage dengan protokol NFS yang dikelola sepenuhnya oleh AWS dan dapat digunakan baik dari AWS maupun on-premise.
  •  Amazon FSx, layanan storage dengan protokol khusus (pihak ketiga) yang dikelola sepenuhnya oleh AWS. Saat ini hadir dengan Amazon FSx for Windows Server dan FSx Lustre.

Pengantar ke Menambahkan Lapisan Database

Pada modul sebelumnya, kita sudah belajar seputar layanan komputasi di AWS. Nah kali ini, kita akan membahas tentang layanan database. Mari kita kaitkan kembali dengan skenario startup warung kopi.

Setelah menambahkan lapisan komputasi, startup kita kian berkembang dan melayani banyak pelanggan. Ini bagus untuk bisnis! Tapi tunggu, seiring berkembangnya bisnis, startup kita juga memiliki kebutuhan yang semakin banyak. 

Sekarang, startup warung kopi ingin mengeluarkan program-program baru. Setelah diskusi internal ternyata tim marketing ingin meluncurkan program loyalty untuk pelanggan yang setia, dengan harapan dapat meningkatkan retensi pelanggan. 

Demi melancarkan program loyalty tersebut, tentunya dibutuhkan skema penyimpanan yang mencukupi. Misalnya, untuk menandakan seorang pelanggan menjadi ‘pelanggan setia’, sistem kita harus bisa menghitung dari catatan pembelian pelanggan tersebut berdasarkan 3-5 bulan ke belakang. 

Bayangkan, pasti akan sangat sulit jika kita harus menghitung data dengan menggunakan penyimpanan sederhana seperti text editor. Oleh karena itu, sistem kita membutuhkan database yang dapat mempermudah dalam perhitungan program loyalty tersebut.

Nah, di AWS tersedia layanan database yang highly available (sangat tersedia) dan scalable (mudah diskalakan). Layanan database ini akan dipisahkan dari bagian server aplikasi. Namun sebelum memulai pembahasan, mari kita tengok apa saja yang akan dipelajari di modul ini, antara lain:

• Membandingkan jenis-jenis database.
• Menjelaskan layanan terkelola (managed service) dan tidak terkelola (unmanaged service).
• Menguraikan materi tentang layanan database relasional Amazon (Amazon RDS) dan Amazon DynamoDB.
• Menguraikan layanan migrasi AWS.

Sebagai gambaran sebelum memulai modul, silakan amati gambar di bawah ini yang mengilustrasikan perkembangan arsitektur pada startup warung kopi kita.

Dari gambar di atas dapat disimpulkan bahwa di modul ini kita akan menambahkan layanan Amazon RDS. Jadi, mari awali langkah kita dengan membahas seputar hal-hal penting yang patut dipertimbangkan dalam mendesain database. Let’s Go!

Pertimbangan dalam Mendesain Database

Seperti yang diketahui bersama, kita tak bisa sembarangan membangun arsitektur, begitupun saat membuat database. Mengapa begitu? Ini karena nantinya database tidak akan berjalan optimal dan menyulitkan kita jika memiliki kebutuhan yang terus berkembang.

Maka dari itu, pertimbangkanlah beberapa hal saat mendesain layanan database untuk sistem kita, di antaranya:

• Scalability
  Dalam hal scalability (skalabilitas), kita perlu mempertimbangkan faktor-faktor seperti berapa besar transaksi data yang akan masuk dan keluar ke solusi database. Apakah solusi yang kita pilih dapat meningkat nanti sesuai dengan kebutuhan atau tidak.
  
  

• Storage Requirements
  Amazon RDS menyediakan tiga jenis storage, yaitu General Purpose SSD, Provisioned IOPS SSD, dan Magnetic. Gunakan jenis storage yang tepat dan sesuai dengan kebutuhan kita.
  
  

• Object Size and Type
  Kita patut mempertimbangkan struktur, jenis, dan juga ukuran objek data. Misalnya, apakah kita akan menyimpan tipe data seperti numerik, string, tanggal, gambar, dan lainnya.
  
  

• Durability
  Pertimbangan database ini melihat seberapa tinggikah tingkat ketahanan, ketersediaan, dan pemulihan database yang Anda butuhkan. Apakah ada aturan terkait database yang harus dipenuhi atau tidak.

Database Relasional dan Nonrelasional

Berdasarkan skenario di awal, sepertinya warung kopi kita membutuhkan database relasional sebagai penyimpanannya. Di modul ini, kita akan berkenalan dengan layanan database relasional AWS, yakni Amazon Relational Database Service (Amazon RDS). 

Tetapi ketahuilah bahwa sebenarnya ada jenis database lain yang tersedia. Tentu, tidak ada salahnya untuk berkenalan dengannya.

Terdapat dua jenis database yang tersedia saat ini di AWS, yaitu relasional dan nonrelasional. Gambar berikut menunjukkan pembagian database beserta contohnya:

Baik database relasional maupun nonrelasional, keduanya memiliki kasus penggunaan yang berbeda sesuai kebutuhan Anda. Database relasional biasanya digunakan untuk OLTP (Online Transaction Processing) dan data warehouse (gudang data). Sedangkan untuk database nonrelasional, banyak dipakai untuk data visualization (graph); leaderboard dan shopping-cart data (key-value); customer dan order data (document).

Penasaran seperti apa perbedaan keduanya secara lebih mendalam? Simak di pembahasan selanjutnya!

Database Relasional

Database Relasional menyimpan data dalam baris dan kolom. Baris berisi semua informasi tentang satu entri, sedangkan kolom adalah atribut yang memisahkan titik data (data points). Skema database relasional bersifat fixed alias tetap, di mana kolom harus dikunci sebelum melakukan entri data. Untuk mengubah skema, misalnya menambahkan kolom baru, umumnya database harus dijadikan offline terlebih dahulu.

Ilustrasi di atas menunjukkan sebuah skema database relasional penjualan buku yang terdiri dari tiga tabel. Tiap tabel merepresentasikan datanya masing-masing, yaitu data buku, pengarang, dan penjualan. Perhatikan tanda panah di ketiga tabelnya, tanda ini menunjukkan relasi antar tabel di mana tiap tabel memiliki data yang sama yaitu author. 

Dengan skema dan relasi ini, kita bisa melakukan kueri untuk mendapatkan informasi tertentu, misalnya, “Berapa total penjualan (Revenue) untuk pengarang Wilson, Joe?”

Pengolahan data dalam database relasional dilakukan dengan menggunakan bahasa kueri yang disebut sebagai SQL (Structure Query Language). Oleh karena itu, umumnya database relasional juga dikenal sebagai server SQL.

Saat ini, pilihan untuk melakukan scaling (penyesuaian kapasitas) terhadap database relasional dapat dilakukan secara vertikal (vertical scaling) dengan meningkatkan daya perangkat keras, misalnya dengan menambahkan CPU ataupun memori. Amazon RDS mendukung horizontal scaling dengan menambahkan read replica, sehingga anda dapat mengalihkan misalnya beban pembuatan report ke read replica tersebut.

Database relasional adalah pilihan yang baik untuk memenuhi kondisi-kondisi sebagai berikut:

• Anda memerlukan aturan skema yang ketat dan enforcement terhadap kualitas data.
• Database Anda tidak membutuhkan kapasitas read (baca) / write (tulis) yang ekstrem.
• Anda memiliki kumpulan data (dataset) relasional yang tidak memerlukan kinerja/performance database yang tinggi.

Nah, itulah sedikit gambaran tentang database relasional yang nantinya akan kita praktikkan ke dalam website warung kopi kita. Selanjutnya, mari kita bahas mengenai database nonrelasional. Tetap semangat!

Database Nonrelasional

Database Nonrelasional sering juga disebut NoSQL. Database NoSQL menyimpan data menggunakan salah satu dari banyak model penyimpanan, seperti pasangan nilai kunci (key-value), dokumen, dan grafik. 

Skema NoSQL bersifat dinamis. Baris tidak harus berisi data untuk setiap kolom. Data dalam database NoSQL diolah dengan berfokus pada kumpulan dokumen. Ilustrasi berikut menunjukkan cara untuk menyimpan data ke database NoSQL.

Database NoSQL dapat melakukan horizontal scaling, yang berarti bahwa ia dapat menangani peningkatan lalu lintas hanya dengan menambahkan jumlah server untuk melayani transaksi database. 

Database NoSQL memiliki kemampuan untuk menjadi lebih besar dan jauh lebih kuat dibandingkan database relasional. Ini menjadikannya pilihan yang lebih disukai untuk kumpulan data (dataset) yang besar atau terus berkembang.

Database nonrelasional bisa menjadi pilihan yang baik untuk memenuhi kebutuhan-kebutuhan berikut:

• Anda membutuhkan database yang dapat melakukan horizontal scaling (penyesuaian kapasitas secara horizontal).
• Data Anda tidak cocok dengan skema tradisional.
• Kecepatan read/write melebihi kecepatan yang didukung secara ekonomis di SQL DB tradisional.

Tabel berikut menunjukkan perbedaan mendasar antara database relasional dan nonrelasional

	Relasional	Nonrelasional
Penyimpanan Data	Baris dan kolom	Key value, dokumen, dan graphs
Skema	Fixed	Dinamis
Pengolahan data	Menggunakan SQL	Berfokus pada kumpulan dokumen
Skalabilitas	Vertikal	Horizontal

Oke, kita telah tuntas membahas jenis-jenis database. Selanjutnya, mari kita bandingkan layanan database yang tersedia di AWS.

Layanan Database AWS

Pada dasarnya ada dua jenis layanan database yang tersedia di AWS yaitu Managed (terkelola) dan Unmanaged (tidak terkelola). Mari kita uraikan perbedaan keduanya.

AWS Unmanaged Service 

Diagram di bawah ini menunjukkan perbedaan antara meng-hosting database sendiri (on-premise) atau menjalankan database di atas layanan Amazon EC2.

Jika kita meng-hosting database secara on-premise, maka seluruh aktivitas fisik yang diperlukan sebelum server bisa diakses harus Anda lakukan sendiri, seperti masalah daya, jaringan, racking (penempatan), stacking (penyusunan), sampai instalasi OS. 

Bahkan setelah OS diinstal pun, Anda masih harus bertanggung jawab untuk aktivitas  tambahan, seperti patching OS hingga optimasi aplikasi. 

Ketahuilah! Empat kegiatan pertama (masalah daya sampai instalasi OS) adalah kegiatan fisik yang perlu dilakukan dan mungkin memerlukan rentang waktu yang lama dalam hitungan beberapa jam hingga hari.

Saat menggunakan layanan Unmanaged Service di AWS, itu berarti kita akan menggunakan VM untuk server database alias menggunakan Amazon EC2. Nah, empat kegiatan awal tadi sudah dikerjakan oleh tim data center AWS, sehingga yang perlu dilakukan adalah menyalakan VM tersebut, yang mana dapat diakses dalam hitungan menit. Selanjutnya, kita hanya perlu melakukan kegiatan tambahan dari patching OS hingga mengoptimasi aplikasi.

AWS Managed Service

Sebelumnya kita telah belajar tentang AWS Unmanaged Service yang mampu membebaskan kita dari tugas-tugas dasar (tetapi tetap penting!) seperti pemeliharaan perangkat keras server, perangkat jaringan, instalasi OS, dan sebagainya. Ini sangat membantu kita dalam mengirimkan aplikasi ke pelanggan (time to market) menjadi lebih cepat. Tetapi jangan lupa, selain aktivitas tersebut, kita masih harus mengerjakan hal-hal di bawah ini:

• Instalasi aplikasi (dalam hal ini adalah database)
• Patching
• Backup dan restore
• High Availability
• Skalabilitas

Hal-hal di atas tetap harus Anda lakukan dan sangat memakan waktu. Nah, untungnya AWS telah memikirkan hal itu dan meluncurkan AWS-Managed Database Service. 

Dengan menggunakan layanan ini, AWS akan melakukan semua hal di atas sehingga kita dan tim akan lebih fokus serta hanya perlu melakukan sesuatu yang benar-benar memiliki nilai tambah, yaitu optimasi aplikasi (app optimization). Hal ini ditunjukkan pada gambar berikut:

Wow, menarik bukan? Dengan AWS Managed Service, tim kita terbebas dari tugas rutin (yang sekali lagi, tetap penting!) dan bisa berkonsentrasi mengoptimalkan kinerja aplikasi. Mari kita pelajari apa saja layanan AWS Managed Service yang tersedia untuk database di pembahasan selanjutnya!

Opsi Database di AWS

Seperti yang telah kita pelajari sebelumnya, saat ini ada dua jenis database yang tersedia, yaitu database relasional dan nonrelasional. Gambar di bawah menunjukkan beberapa pilihan dari kedua jenis database tersebut yang tersedia di AWS. Harap diperhatikan bahwa ini hanya sebagian pilihan saja.

Di modul ini, kita hanya akan mempelajari dua saja, yakni Amazon RDS dan Amazon DynamoDB. Ayo kita mulai pembahasannya!

Amazon RDS

Amazon RDS atau Amazon Relational Database Service adalah layanan database relasional yang ditangani sepenuhnya (fully managed) oleh AWS. Di Amazon RDS, Anda bisa memilih beberapa tipe database engine, seperti Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, dan Microsoft SQL Server.

Dengan menggunakan Amazon RDS, Anda akan mendapatkan banyak keuntungan, di antaranya:

• Layanan database relasional yang ditangani sepenuhnya (fully managed) oleh AWS. 
• Pembuatan instance database baru dicapai dalam hitungan menit.
• Proses peningkatan kapasitas hanya dengan beberapa klik.

Dari semua pilihan mesin dari Amazon RDS di atas, ada satu opsi yang unik. Apakah Anda bisa menebaknya? Cek jawabannya di modul berikutnya!

Amazon Aurora

Amazon Aurora adalah mesin database relasional terkelola sepenuhnya yang kompatibel dengan MySQL dan PostgreSQL. Layanan ini mengombinasikan kecepatan dan keandalan dari database komersial kelas atas dengan kemudahan dan efektivitas biaya dari database open-source. 

Tunggu sebentar, apa yang dimaksud dengan “kompatibel dengan MySQL dan PostgreSQL?” Maksudnya, sebagian besar kode, alat, serta aplikasi yang menggunakan database MySQL dan PostgreSQL dapat digunakan bersama Aurora dengan sedikit atau tanpa perubahan sama sekali. Menarik, kan?

Tak hanya itu, Amazon Aurora juga memiliki beberapa keuntungan, antara lain:

• Throughput yang sangat cepat, bahkan hingga 5x dibandingkan dengan MySQL dan hingga 3x jika dikomparasi dengan PostgreSQL.
• Replikasi data secara synchronous ke 6 storage nodes di tiga Availability Zone.
• Hanya butuh sedikit perubahan pada aplikasi Anda.
• Dukungan Aurora global database.

Database Nonrelasional (NoSQL) - Amazon DynamoDB

Kita telah mempelajari secara singkat apakah database NoSQL itu. Nah, di modul ini Anda akan berkenalan dengan Amazon DynamoDB. Ia adalah salah satu dari beberapa layanan database NoSQL yang tersedia di AWS. 

Silakan amati gambar berikut yang menjelaskan keunggulan menggunakan Amazon DynamoDB:

Oke, mari kita uraikan beberapa poin dari gambar di atas, antara lain:

• Fully Managed (terkelola sepenuhnya)
  Dengan menggunakan layanan Amazon DynamoDB, tim kita bisa berfokus pada hal yang benar-benar memberikan nilai tambah, seperti mengoptimasi aplikasi.
  
  

• Event-driven programming
  Saat menggunakan Amazon DynamoDB kita tidak perlu mengelola server. Dengannya, kita bisa menerapkan event-driven programming atau serverless computing.
  
  

• Extreme Horizontal Scaling
  Amazon DynamoDB adalah database nonrelasional yang mendukung model data key-value (nilai-kunci) dan dokumen. Layanan ini bahkan mendukung tabel berukuran apa pun secara virtual dengan horizontal scaling (penyesuaian kapasitas secara horizontal).
  
  Hal tersebut memungkinkan DynamoDB untuk melakukan scaling lebih dari 10 triliun permintaan per hari dengan puncak lebih dari 20 juta permintaan per detik dengan penyimpanan pada tingkat petabyte.
  
  

Alright, tibalah kita di akhir materi tentang opsi Database di AWS. Intinya, baik relasional maupun nonrelasional, keduanya memiliki kasus penggunaan yang berbeda sesuai kebutuhan Anda. 

Gunakanlah Amazon Aurora sebagai pilihan untuk database relasional jika aplikasi Anda membutuhkan kecepatan dan keandalan dari layanan database kelas atas. Aurora tersedia secara global dengan biaya yang ekonomis dan ditangani sepenuhnya oleh AWS.

Sementara itu, gunakanlah Amazon DynamoDB sebagai pilihan untuk database NoSQL dengan kemampuan horizontal scaling yang luar biasa dan serverless programming (dikombinasikan dengan AWS Lambda). Layanan ini juga sepenuhnya ditangani oleh AWS.

AWS Database Migration Service (AWS DMS)

Saat bisnis telah berjalan dan berkembang, ada kalanya terjadi hal-hal yang tak bisa kita hindari, seperti migrasi database. Ini bisa terjadi karena berbagai faktor, misalnya kebutuhan yang kian berkembang. 

Tapi tenang saja, AWS telah menyediakan layanan yang memudahkan Anda untuk melakukan migrasi database. Penasaran seperti apa? Check it out!

AWS DMS adalah layanan migrasi database yang dapat digunakan untuk memindahkan database dari on-premise, Amazon EC2, ataupun Amazon RDS dengan database engine tertentu ke Amazon RDS yang sesuai pilihan kita. Pada dasarnya, ada dua jenis migrasi data yang dapat dilakukan, mari kita uraikan.

Migrasi Database Homogen

Pada migrasi database homogen, mesin database target dan database sumber harus sama atau kompatibel, misalnya seperti Oracle Database ke Amazon RDS for Oracle, MySQL ke Amazon Aurora, MySQL ke Amazon RDS for MySQL, atau Microsoft SQL Server ke Amazon RDS for SQL Server. 

Karena struktur skema, tipe data, dan kode antara database sumber dan database target itu kompatibel, maka migrasi jenis ini adalah proses satu langkah. Gambar berikut menunjukkan ilustrasi migrasi database homogen:

Migrasi Database Heterogen

Dalam migrasi database heterogen, database engine sumber dan database target berbeda, seperti dalam kasus migrasi Oracle ke Amazon Aurora, Oracle ke PostgreSQL, atau Microsoft SQL Server ke MySQL. 

Dalam kasus ini, struktur skema, jenis data, dan kode antara database sumber dan database target cukup berbeda sehingga memerlukan transformasi skema database. Hal itu membuat migrasi heterogen menjadi proses dua langkah.

Migrasi dua langkah ini dapat dijabarkan sebagai berikut:

1. Gunakan AWS SCT (AWS Schema Conversion Tool) untuk mengonversi skema database sumber (dari SQL Server) ke format yang kompatibel dengan database target (dalam contoh ilustrasi ini PostgreSQL).
2. Mereplikasi data antara sumber dan database target menggunakan AWS DMS.

Pada poin di atas disebutkan layanan AWS SCT, apa itu? Mari kita bahas! 

AWS SCT alias AWS Schema Conversion Tool adalah alat yang memungkinkan Anda untuk dapat mengonversi skema database yang ada dari satu database engine ke mesin database yang lain. Tabel di bawah menunjukkan konfigurasi migrasi atau konversi skema database yang didukung oleh AWS SCT.

Source Database	Target Database
Microsoft SQL Server	Amazon Aurora, MySQL, PostgreSQL
MySQL	PostgreSQL
Oracle	Amazon Aurora, MySQL, PostgreSQL
Oracle Data Warehouse	Amazon Redshift
PostgreSQL	Amazon Aurora, MySQL
Teradata	Amazon Redshift

Oke. Jadi itulah pembahasan kita kali ini mengenai migrasi database di AWS. Memang, kebutuhan akan migrasi database bisa saja terjadi dan tak bisa kita hindari. Untungnya, AWS telah menyediakan layanan migrasi database sehingga memudahkan kita untuk melakukannya tanpa perlu repot dan mengeluarkan biaya yang mahal seperti di on-premise.

Catatan: Latihan ini akan melibatkan NAT Gateway, yang mana ia tidak termasuk ke dalam AWS Free Tier. Jadi, mungkin Anda akan dikenakan tagihan. Kami menyarankan kepada Anda untuk menyelesaikan latihan dalam satu waktu sehingga bisa langsung menghapusnya saat latihan selesai. Sebagai informasi, biaya NAT Gateway di region Asia Pacific (Singapore) saat modul ini ditulis adalah $0,059 per jam.

Hands-on Lab: Deploy Aplikasi Web di AWS

Setelah mempelajari tentang komputasi dan database di AWS, mari kita akan praktikkan langsung pada latihan ini. Namun, sebelum memulai, yuk kita ingat kembali skenario startup warung kedai kopi kita.

Pada latihan sebelumnya, Anda telah berhasil meng-hosting web statis dan semuanya berjalan lancar. Seiring waktu berjalan, startup Anda akhirnya siap untuk meluncurkan produknya, yakni aplikasi web beserta database-nya.

Pertanyaannya, bagaimana cara mewujudkannya di AWS? Oh, tak perlu khawatir, pada latihan ini kita akan mempelajarinya. Teknologi yang akan kita gunakan antara lain: Amazon EC2, Amazon RDS, dan Security group.

Agar lebih mempermudah penjelasan, perhatikan gambar arsitektur berikut:

Seperti itulah gambaran arsitektur yang akan kita implementasikan pada latihan kali ini. Mari kita bedah:

• EC2 instance berisi aplikasi web Anda akan ditempatkan di subnet publik sehingga bisa diakses oleh publik.
• RDS instance yang berisi database Anda akan ditempat di subnet privat. Ia hanya bisa mengirim dan menerima data ke/dari EC2 instance.

Nah, setelah Anda mengetahui apa yang akan kita lakukan, mari lihat tahapan-tahapan yang akan kita lakukan berikut:

1. Membuat VPC yang berisi subnet publik dan privat.
2. Men-deploy layanan AWS-Managed database dengan Amazon RDS.
3. Men-deploy server aplikasi dengan Amazon EC2.
4. Menguji aplikasi.

Sebelum meminta layanan database dan EC2 instance, Anda terlebih dahulu perlu membuat VPC, subnet, dan security group. Komponen-komponen tersebut diperlukan agar database dan EC2 instance Anda bisa terhubung dan saling berkomunikasi. 

Oke, tak perlu menunggu lama lagi, mari kita meluncur ke langkah-langkahnya. Semangat!

Hands-on Lab: Deploy Aplikasi Web di AWS - Membuat VPC

Di bagian pertama, kita akan membuat VPC yang berisi subnet publik dan privat, serta mengonfigurasi security group. Nah, sebelum membuat VPC, kita perlu memiliki Elastic IP address yang terasosiasi dengan NAT gateway terlebih dahulu. Mari kita mulai!

1. Silakan buka halaman utama Amazon EC2 dari AWS Management Console.
   
   
   

2. Oiya jangan lupa, pastikan Region yang Anda pilih adalah yang terdekat, yakni Singapore (ap-southeast-1).
   
   
   

3. Oke lanjut, pada panel navigasi sebelah kiri, klik Elastic IPs di bagian Network & Security.
   
   
   

4. Lalu, klik tombol Allocate Elastic IP address.
   
   
   

5. Pada bagian Public IPv4 address pool, pilih Amazon’s pool of IPv4 addresses dan klik Allocate.
   
   
   

6. Nah, kita sudah berhasil membuat Elastic IP address. Langkah selanjutnya adalah membuat VPC, silakan masuk ke VPC console dan pastikan Anda masih berada di Region Singapore ya.
   
   
   

7. Pada panel navigasi di sebelah kiri, pilih VPC Dashboard. Untuk mulai membuat VPC, klik tombol Launch VPC Wizard.
   
   
   

8. Pada halaman “Step 1: Select a VPC Configuration”, pilih VPC with Public and Private Subnets (opsi yang kedua), lalu klik tombol Select.
   
   
   

9. Pada halaman “Step 2: VPC with Public and Private Subnets”, silakan konfigurasikan nilai-nilai berikut:

   IPv4 CIDR block	10.0.0.0/16
   IPv6 CIDR block	No IPv6 CIDR Block
   VPC name	dicoding-tutorial-vpc
   Public subnet's IPv4 CIDR	10.0.0.0/24
   Availability Zone	ap-southeast-1a
   Public subnet name	Dicoding Tutorial Public
   Private subnet's IPv4 CIDR	10.0.1.0/24
   Availability Zone	ap-southeast-1a
   Private subnet name	Dicoding Tutorial Private 1
   Elastic IP Allocation ID	Elastic IP address yang telah Anda buat sebelumnya untuk diasosiasikan dengan NAT gateway. Klik di dalam box dan pilih IP address yang ditampilkan.
   Service endpoints	Lewati bagian ini
   Enable DNS hostnames	Yes
   Hardware tenancy	Default

   Jika Anda bingung, amatilah gambar di bawah ini. Kemudian, silakan klik Create VPC.
   
10. Tunggu hingga proses loading selesai, mungkin memerlukan waktu hingga beberapa menit. Jika sudah selesai, klik OK. VPC Anda pun akan terlihat di daftar VPC.
    
    
    
11. Sampai tahap ini, Anda sudah berhasil membuat Elastic IP address dan VPC dengan subnet publik dan privat. Mari kita lanjutkan ke tahap berikutnya, yaitu membuat subnet privat tambahan untuk DB subnet group kita nantinya.
    
    
12. Untuk membuat subnet privat tambahan ke VPC, silakan masuk ke menu Subnets dan klik Create subnet.
    
    
    
13. Pada halaman “Create subnet”, isikan seperti berikut:

    VPC ID	vpc-identifier (dicoding-tutorial-VPC)
    Subnet name	Dicoding Tutorial Private 2
    Availability Zone	ap-southeast-1b
    IPv4 CIDR block	10.0.2.0/24

    Jika sudah, silakan klik Create subnet.
    
    

14. Untuk memastikan bahwa subnet privat tambahan tersebut menggunakan route table yang sama dengan subnet privat pertama, silakan klik lagi menu Subnets dan perhatikan pada dua baris subnet privat yang Anda miliki.
    
    
    

15. Scroll ke bagian kanan hingga Anda menemukan kolom Route table. Pastikan keduanya memiliki route table yang sama.
    
    
    

16. Oke, langkah selanjutnya adalah membuat security group untuk web server publik. Agar EC2 instance Anda dapat diakses publik, tambahkan inbound rules ke security group yang mengizinkan traffic dari internet.
    
    

17. Silakan masuk ke menu Security Groups yang ada di panel navigasi sebelah kiri. Lalu, klik tombol Create security group.
    
    
    

18. Pada halaman “Create security group”, silakan isi sesuai nilai-nilai berikut:
    Amati gambar berikut:

    Security group name	dicoding-tutorial-securitygroup
    Description	Dicoding Tutorial Security Group
    VPC	vpc-identifier (dicoding-tutorial-VPC)

    
    
    

19. Selanjutnya, konfigurasikan bagian Inbound rules. Silakan tambahkan rule dengan klik Add rule. Lalu, sesuaikan dengan nilai-nilai berikut:

    Type	SSH
    Source	0.0.0.0/0 (semua IP address)

    Konfigurasi di atas mengizinkan akses SSH ke EC2 instance. Dengan begitu, Anda bisa terhubung ke EC2 instance dan menginstal web server.
    
    

20. Lanjut, klik lagi tombol Add rule untuk menambahkan rule kedua. Kemudian, sesuaikan dengan konfigurasi berikut:

    Type	HTTP
    Source	0.0.0.0/0 (semua IP address)

    Konfigurasi di atas mengizinkan akses HTTP ke EC2 instance Anda dari semua IP address. Jika Anda kesulitan, silakan ikuti gambar berikut:
    
     

21. Untuk membuat security group, silakan klik Create security group.
    
    
    

22. Sampai tahap ini, Anda sudah berhasil membuat security group untuk web server. Selanjutnya, untuk membuat DB instance Anda tetap privat, mari kita buat security group yang hanya akan menerima traffic dari web server saja. Silakan klik Security Groups pada menu atas.
    
    
    

23. Kemudian, klik tombol Create security group.
    
    
    

24. Pada halaman “Create security group”, silakan sesuaikan dengan konfigurasi berikut:

    Security group name	dicoding-tutorial-db-securitygroup
    Description	Dicoding Tutorial DB Instance Security Group
    VPC	vpc-identifier (dicoding-tutorial-VPC)

    
    
    

25. Selanjutnya, tambahkan inbound rules dengan klik Add rule. Lalu, sesuaikan seperti berikut:

    Type	MySQL/Aurora
    Source	dicoding-tutorial-securitygroup

    
     

26. Untuk mengakhiri, silakan klik tombol Create security group. Selamat! Anda telah sukses membuat security group untuk DB instance.
    
    
    

27. Tahap selanjutnya, kita akan membuat DB subnet group. Group ini berisi subnet-subnet untuk penempatan DB instance Anda. DB subnet group memungkinkan Anda untuk meletakkannya di VPC tertentu saat membuat DB instance.

28. Oke, sekarang mari masuk ke Amazon RDS console (ketik “RDS” di bagian pencarian layanan pada bagian atas management console).
    
    
    

29. Pada panel navigasi di sebelah kiri, silakan buka menu Subnet groups dan klik tombol Create DB Subnet Group.
    
    
    

30. Di halaman “Create DB Subnet Group”, isikan nilai-nilai berikut pada bagian Subnet group details:

    Name	dicoding-tutorial-db-subnet-group
    Description	Tutorial DB Subnet Group
    VPC	dicoding-tutorial-VPC (vpc-identifier)

    
    

31. Selanjutnya, pada bagian Add subnets, sesuaikan dengan konfigurasi berikut:

    Availability Zones	ap-southeast-1a, ap-southeast-1b
    Subnets	10.0.0.0/24, 10.0.1.0/24, dan 10.0.2.0/24

    Jika Anda kesulitan, silakan amati gambar di bawah ini, lalu klik Create.
    
     

32. Hore! DB subnet group akan muncul di daftar subnet groups pada RDS console Anda.
    

Hands-on Lab: Deploy Aplikasi Web di AWS - Membuat DB instance

Oke, bagian ini adalah lanjutan dari latihan latihan Membuat VPC. Sebelumnya, kita telah berhasil membuat VPC dengan subnet publik dan privat, subnet privat tambahan, security group untuk web server dan DB instance, dan DB subnet group.

Nah, di latihan bagian kedua ini, kita akan fokus untuk membuat DB instance menggunakan Amazon RDS bertipe MySQL. Penasaran? Yuk langsung kita praktikkan.

1. Silakan masuk ke halaman utama dari Amazon RDS.
   
    

2. Pastikan Anda masih berada di Region Singapore ya.
   
   
   

3. Pada panel navigasi di sebelah kiri, silakan masuk ke menu Databases dan klik tombol Create database.
   
    

4. Pada halaman Create database, pastikan Anda memilih konfigurasi di bawah ini:

   Choose a database creation method	Standard create
   Engine options	MySQL
   Version	MySQL 5.7.16

5. Pada bagian Templates, pastikan Anda memilih Free tier. Lalu untuk bagian Settings, silakan ikuti konfigurasi berikut:

   DB instance identifier	dicoding-tutorial-db-instance
   Master username	dicoding_user
   Auto generate a password	Matikan opsi ini
   Master password	Isikan password sesuai keinginan Anda
   Confirm password	Ketik ulang password

   Jika Anda tidak menemukan bagian pengisian username dan password, klik bilah Credentials Settings.
   

   
   

6. Selanjutnya, biarkan konfigurasi pada bagian DB instance size dan Storage sesuai default. Perhatikan gambar di bawah ini:
   

7. Kita tak perlu mengubah apa pun pada bagian Availability & durability, silakan lanjut ke langkah berikutnya.

8. Di bagian Connectivity, silakan ikuti konfigurasi berikut:

   Virtual private cloud (VPC)	dicoding-tutorial-VPC (vpc-identifier)
   Subnet group	dicoding-tutorial-db-subnet-group
   Public access	No
   VPC security group	Choose existing
   Existing VPC security groups	dicoding-tutorial-db-securitygroup (Catat! Hapuslah security group yang lain, semisal default dengan klik tombol X)
   Availability Zone	ap-southeast-1b
   Database port	3306

   Jika Anda tidak menemukan letak Database port, silakan buka bilah Additional configuration tepat di bawah opsi Availability Zone.

9. Kita tak perlu mengubah apa pun pada bagian Database authentication.

10. Kemudian, klik tanda panah pada Additional configuration, lalu isikan “sample” pada bagian Initial database name. Biarkan pengaturan lainnya secara default.
    
     

11. Scroll halaman ke paling bawah dan klik Create database untuk membuat RDS MySQL DB instance.
    
    
    

12. DB instance Anda akan terdaftar di halaman Databases dengan status Creating.
    
    
    

13. Tunggulah beberapa menit hingga status DB instance Anda berubah menjadi Available. Jika sudah, silakan klik nama DB instance untuk melihat detailnya. Pada bagian Connectivity & security, catat Endpoint dari DB instance karena Anda akan memerlukannya nanti.
    
    
    

Selamat! Anda telah berhasil membuat Amazon RDS DB instance dengan tipe MySQL. Tinggal satu tahap lagi yang perlu Anda lakukan, yakni membuat EC2 instance untuk web server. Mari kita selesaikan di bagian selanjutnya.

Hands-on Lab: Deploy Aplikasi Web di AWS - Membuat EC2 instance

Pada bagian ini, Anda akan membuat web server menggunakan Apache lalu mengoneksikannya dengan Amazon RDS DB instance yang telah dibuat di bagian sebelumnya. Bagian ini pun akan menjadi akhir dari latihan kita di modul ini. Mari kita mulai langkah-langkahnya:

1. Dari AWS Management Console, silakan masuk ke Amazon EC2 console. Ketik “EC2” di bagian atas pencarian layanan.
   
   
   

2. Pada EC2 Dashboard, klik tombol Launch instance.
   
    

3. Pilih Amazon Linux 2 AMI.
   
   
   

4. Pilih tipe instance t2.micro, lalu klik tombol Next: Configure Instance Details.
   
   
   

5. Pada halaman Configure Instance Details, sesuaikan dengan konfigurasi di bawah dan biarkan lainnya default.

   Network	vpc-identifier | dicoding-tutorial-VPC
   Subnet	subnet-identifier | Dicoding Tutorial Public
   Auto-assign Public IP	Enable

   Jika kesulitan, Anda bisa melihat gambar di bawah. Lalu, klik tombol Next: Add Storage untuk lanjut ke langkah berikutnya.
   

   
   

6. Di halaman Add Storage, kita tak perlu mengubah apa pun. Jadi, biarkan saja default dan klik Next: Add Tags.
   
    

7. Kemudian, pada halaman Add Tags, klik tombol Add Tag untuk menambahkan tag dan isikan:

   Key	Name
   Value	dicoding-tutorial-web-server

   Silakan lihat gambar di bawah. Jika sudah, klik tombol Next: Configure Security Group.
   
   
   

8. Di halaman Configure Security Group, pilih Select an existing security group. Lalu, pilih security group yang telah Anda buat untuk web server, yaitu dicoding-tutorial-securitygroup. Pastikan security group tersebut memiliki inbound rules untuk akses SSH dan HTTP.
   
    

9. Silakan tinjau lagi konfigurasi EC2 instance Anda. Jika sudah sesuai, klik tombol Launch.
   
   
   

10. Setelah itu, pilih Create a new key pair dan isikan nama key pair Anda (misal dicoding-tutorial-key-pair). Lalu, unduh key pair tersebut dan simpanlah di folder Downloads di komputer Anda agar mempermudah pengaksesan pada step selanjutnya. Jika sudah, klik tombol Launch Instances.
    
     

11. Langkah selanjutnya, klik View Instances. Anda akan diarahkan ke halaman daftar instance.
    
    

12. Tunggu sampai status instance Anda menjadi Running sebelum melanjutkan ke tahap berikutnya.
    
     

13. Oke, Anda sudah berhasil membuat EC2 instance. Sekarang, kita akan menginstal Apache web server dengan PHP pada instance tersebut. Let’s Go!
    
    

14. Mari kita terhubung terlebih dahulu ke EC2 instance. Silakan pilih instance Anda, lalu klik tombol Connect.
    
    
    

15. Lalu, masuk ke tab SSH client dan salinlah sintaks ssh sesuai yang ada pada layar Anda.
    
    Catatan: Anda juga bisa terhubung ke EC2 instance melalui EC2 Instance Connect. Buka tab EC2 Instance Connect -> Connect.
    
    

16. Kemudian, buka aplikasi command prompt/terminalpada komputer Anda. Silakan pindah ke folder Downloads di mana Anda menyimpan file key pair (di step 10), ketik perintah berikut:

    cd Downloads

    
    

17. Lalu, tempelkan sintaks ssh yang telah Anda salin (untuk menempel sintaks, klik kanan pada command prompt).
    
    
    

18. Jika Anda menggunakan Linux dan cara tersebut tidak bisa, silakan tulis sintaks chmod 400 namaFileAnda.pem terlebih dahulu, barulah tempelkan sintaks ssh.
    
    

19. Setelah itu, akan muncul konfirmasi “Are you sure you want to continue connecting (yes/no)?”, ketikkan saja yes dan Anda pun akan segera terhubung ke Amazon EC2 instance.
    
    
    

20. Untuk mendapatkan perbaikan bug dan pembaruan keamanan terbaru, lakukan update software pada EC2 instance Anda dengan mengetikkan sintaks:

    sudo yum update -y

    
    
21. Setelah proses update selesai, silakan instal PHP, beberapa software package, dan dependencies secara bersamaan.

    sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2

    
    
22. Selanjutnya, mari kita instal Apache web server.

    sudo yum install -y httpd

    
    
23. Mulai web server dengan sintaks berikut:

    sudo systemctl start httpd

    
    

24. Oke, web server kita sekarang telah terinstal dan berjalan. Yuk kita tes!
    
    

25. Silakan kembali ke AWS Management Console, di halaman instance pada EC2 console, klik Instances pada menu atas.
    
     

26. Pilih instance Anda dan salin public IPv4 DNS-nya. Lalu, tempelkan pada address bar di browser Anda.
    
     

27. Ta-da! Halaman test page pun akan muncul.
    
    
    

28. Selanjutnya, kembali lagi ke terminal Anda (ssh connection yang sedang terhubung_ dan konfigurasikan web server agar tetap berjalan setiap system boot.

    sudo systemctl enable httpd

    
    
29. Guna mengizinkan ec2-user mengelola file di direktori root default untuk Apache web server, Anda perlu memodifikasi ownership dan permission terhadap direktori /var/www. Pertama, tambahkan grup www ke EC2 instance dengan perintah berikut:

    sudo groupadd www

    
    
30. Tambahkan pengguna ec2-user ke grup www.

    sudo usermod -a -G www ec2-user

    
    
31. Oke, sekarang silakan logout untuk me-refresh konfigurasi Anda dengan perintah:

    exit

    
    

32. Silakan login kembali dengan memasukkan sintaks ssh yang Anda miliki.
    
    
    

33. Lalu, periksa apakah grup www telah tersedia atau belum dengan sintaks groups. Output yang keluar akan seperti gambar berikut:
    
    
    

34. Ubahlah group ownership pada direktori /var/www and konten di dalamnya ke grup www.

    sudo chgrp -R www /var/www

    
    
35. Kemudian, ubah permission /var/www dan subdirektorinya untuk menambahkan write permission pada grup sekaligus menyetel ID grup pada subdirektori yang dibuat di masa mendatang. Lalu, ubah permission secara berulang untuk file yang ada di /var/wwwdan subdirektorinya guna menambahkan write permission pada grup.

    sudo chmod 2775 /var/www
    find /var/www -type d -exec sudo chmod 2775 {} +
    find /var/www -type f -exec sudo chmod 0664 {} +

    
    
36. Oke, kita telah selesai mengatur permission untuk Apache web server. Sekarang, mari kita hubungkan Apache web server ke DB instance. Pertama, beralihlah ke direktori /var/www dan buat subdirektori baru bernama inc.

    cd /var/www
    mkdir inc

    
    
37. Silakan masuk ke direktori inc, lalu buatlah file baru di dalamnya bernama dbinfo.inc. Selanjutnya, edit file dbinfo.inctersebut.

    cd inc
    >dbinfo.inc
    nano dbinfo.inc

    
    
38. Silakan copy dan paste baris kode di bawah ini ke instance Anda. Jangan lupa, ubah db_instance_endpoint dan master password sesuai dengan yang Anda miliki. Jika sudah, silakan keluar dari file dbinfo.inc dengan cara CTRL + X, lalu tekan Y, kemudian Enter.

    <?php
     
    define('DB_SERVER', 'db_instance_endpoint');
    define('DB_USERNAME', 'dicoding_user');
    define('DB_PASSWORD', 'master password');
    define('DB_DATABASE', 'sample');
     
    ?>

    
    
39. Langkah selanjutnya, masuklah ke direktori /var/www/html.

    cd /var/www/html

    
    
40. Buatlah file baru di dalam direktori html dengan nama SamplePage.php, lalu edit file tersebut.

    >SamplePage.php
    nano SamplePage.php

    
    

41. Kemudian, tambahkan baris kode di bawah ke file SamplePage.php (klik kanan untuk paste di command prompt).

    <?php include "../inc/dbinfo.inc"; ?>
    <html>
    <body>
    <h1>Sample page</h1>
    <?php
     
      /* Connect to MySQL and select the database. */
      $connection = mysqli_connect(DB_SERVER, DB_USERNAME, DB_PASSWORD);
     
      if (mysqli_connect_errno()) echo "Failed to connect to MySQL: " . mysqli_connect_error();
     
      $database = mysqli_select_db($connection, DB_DATABASE);
     
      /* Ensure that the EMPLOYEES table exists. */
      VerifyEmployeesTable($connection, DB_DATABASE);
     
      /* If input fields are populated, add a row to the EMPLOYEES table. */
      $employee_name = htmlentities($_POST['NAME']);
      $employee_address = htmlentities($_POST['ADDRESS']);
     
      if (strlen($employee_name) || strlen($employee_address)) {
        AddEmployee($connection, $employee_name, $employee_address);
      }
    ?>
     
    <!-- Input form -->
    <form action="<?PHP echo $_SERVER['SCRIPT_NAME'] ?>" method="POST">
      <table border="0">
        <tr>
          <td>NAME</td>
          <td>ADDRESS</td>
        </tr>
        <tr>
          <td>
            <input type="text" name="NAME" maxlength="45" size="30" />
          </td>
          <td>
            <input type="text" name="ADDRESS" maxlength="90" size="60" />
          </td>
          <td>
            <input type="submit" value="Add Data" />
          </td>
        </tr>
      </table>
    </form>
     
    <!-- Display table data. -->
    <table border="1" cellpadding="2" cellspacing="2">
      <tr>
        <td>ID</td>
        <td>NAME</td>
        <td>ADDRESS</td>
      </tr>
     
    <?php
     
    $result = mysqli_query($connection, "SELECT * FROM EMPLOYEES");
     
    while($query_data = mysqli_fetch_row($result)) {
      echo "<tr>";
      echo "<td>",$query_data[0], "</td>",
           "<td>",$query_data[1], "</td>",
           "<td>",$query_data[2], "</td>";
      echo "</tr>";
    }
    ?>
     
    </table>
     
    <!-- Clean up. -->
    <?php
     
      mysqli_free_result($result);
      mysqli_close($connection);
     
    ?>
     
    </body>
    </html>
     
     
    <?php
     
    /* Add an employee to the table. */
    function AddEmployee($connection, $name, $address) {
       $n = mysqli_real_escape_string($connection, $name);
       $a = mysqli_real_escape_string($connection, $address);
     
       $query = "INSERT INTO EMPLOYEES (NAME, ADDRESS) VALUES ('$n', '$a');";
     
       if(!mysqli_query($connection, $query)) echo("<p>Error adding employee data.</p>");
    }
     
    /* Check whether the table exists and, if not, create it. */
    function VerifyEmployeesTable($connection, $dbName) {
      if(!TableExists("EMPLOYEES", $connection, $dbName))
      {
         $query = "CREATE TABLE EMPLOYEES (
             ID int(11) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
             NAME VARCHAR(45),
             ADDRESS VARCHAR(90)
           )";
     
         if(!mysqli_query($connection, $query)) echo("<p>Error creating table.</p>");
      }
    }
     
    /* Check for the existence of a table. */
    function TableExists($tableName, $connection, $dbName) {
      $t = mysqli_real_escape_string($connection, $tableName);
      $d = mysqli_real_escape_string($connection, $dbName);
     
      $checktable = mysqli_query($connection,
          "SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_NAME = '$t' AND TABLE_SCHEMA = '$d'");
     
      if(mysqli_num_rows($checktable) > 0) return true;
     
      return false;
    }
    ?>
    
    

34. Jika sudah, silakan simpan dan tutup file tersebut dengan cara CTRL + X, tekan Y, lalu Enter.
    
    

35. Huh, ayo sedikit lagi! Sekarang, kita masuk ke tahap pengujian. Silakan buka kembali Public IPv4 address dari EC2 instance Anda di browser. Namun, tambahkan http://Public-IPv4-DNS/SamplePage.php. Contoh: http://ec2-18-141-178-139.ap-southeast-1.compute.amazonaws.com/SamplePage.php (ini adalah URL contoh).

Silakan bereksplorasi dengan halaman tersebut. Anda bisa menambahkan data ke DB instance dengan memasukkan nilai nama dan alamat, lalu klik tombol Add Data. Data yang Anda tambahkan akan langsung terlihat pada halaman tersebut. Lihat gambar berikut:

Clean Up Jika Anda telah selesai dengan pengujian web server dan database tersebut, silakan hapus semua komponen yang telah dibuat guna menghindari penagihan. Berikut adalah urutan penghapusannya: Delete RDS database instance.  Delete RDS database subnet groups (pastikan database instance telah terhapus). Terminate EC2 instance. Delete NAT gateway. Release Elastic IP addresses. Delete VPC.

Ikhtisar

Tibalah kita di penghujung modul ini. Mari kita tengok kembali apa saja yang telah kita pelajari, di antaranya:

• Jenis Database
  Kita telah belajar tentang perbedaan antara database relasional dan nonrelasional. Berikut adalah tabel perbedaannya:

  	Relasional	Nonrelasional
  Penyimpanan Data	Baris dan kolom	Key value, dokumen, dan graphs
  Skema	Fixed	Dinamis
  Pengolahan data	Menggunakan SQL	Berfokus pada kumpulan dokumen
  Skalabilitas	Vertikal	Horizontal

  
  

• Database di AWS
  Kita telah menilik dua jenis layanan database yang tersedia di AWS, yaitu Managed dan Unmanaged. Selain itu, kita juga telah mempelajari beberapa layanan, seperti Amazon RDS, Amazon Aurora, dan Amazon DynamoDB.
  
  

• AWS Database Migration Service
  AWS Database Migration Service adalah layanan migrasi database yang dapat digunakan untuk memindahkan database dari on-premise, Amazon EC2, ataupun Amazon RDS ke Amazon RDS pilihan kita.