Architecting on AWS (Membangun Arsitektur Cloud di AWS)_2

 

Konsep Jaringan di AWS

Wow, startup warung kopi kita sudah mulai berkembang dan memiliki banyak pelanggan. Seiring dengan perkembangan bisnis, tuntutan terhadap keandalan dan fleksibilitas infrastruktur IT juga berubah. 

Sejauh ini kita telah membangun infrastruktur IT startup kita menggunakan layanan-layanan yang ditangani (managed) oleh AWS. Biarkan AWS menangani hal-hal dasar dari layanan IT. Dengan begitu, tim kita bisa berkonsentrasi ke hal-hal yang lebih membawa nilai tambah, misalnya mengoptimasi aplikasi.

Seiring dengan perkembangan bisnis, kita mungkin ingin mendapatkan kontrol lebih dalam (seperti akses jaringan, keamanan, dan pengelompokan sumber daya) terhadap infrastruktur, tetapi tetap dengan kemudahan yang ditawarkan oleh cloud. Apakah itu mungkin? 

Misalnya, Anda ingin server aplikasi yang menjalankan website warung kopi dapat diakses oleh publik, sementara database yang menyimpan data pelanggan terlindungi dengan aman, tidak dapat diakses oleh publik, dan hanya bisa diakses oleh alamat IP tertentu. 

Kembali ke pertanyaan, apakah itu mungkin dilakukan? Jika kita menggunakan AWS, jawabannya adalah ya. Menarik, bukan?

Nah, untuk memenuhi kebutuhan arsitektur di atas, pada modul ini kita akan mempelajari hal-hal berikut:

• Amazon Virtual Private Cloud (VPC)
• Subnets
• Gateways
• Keamanan Jaringan

Keempat subjek di atas akan dibahas menggunakan studi kasus startup. Kita juga akan menggunakan subjek-subjek tersebut untuk mengembangkan arsitekturnya. 

Sesuai gambar arsitektur di atas, kita akan menambah beberapa komponen terhadap arsitektur startup warung kopi, yaitu VPC, Internet Gateway, NAT Gateway, dan lain-lain. Di akhir modul, Anda akan dapat memahami semua komponen dari diagram arsitektur di atas. Bahkan, Anda juga dapat membangun solusi arsitektur Anda sendiri yang besar dan andal.

Amazon Virtual Private Cloud (VPC)

Pada modul sebelumnya, kita telah belajar tentang Amazon EC2, bahkan telah berlatih untuk meluncurkannya. Apakah Anda masih ingat? Saat meluncurkan sebuah EC2 instance, Anda wajib menentukan VPC mana yang akan menjadi tempat peluncuran instance.

Nah, di sinilah kita akan belajar tentang apa itu VPC. Amazon VPC memungkinkan Anda untuk membangun jaringan virtual di cloud AWS tanpa memerlukan VPN (Virtual Private Network), perangkat keras, ataupun data center fisik. 

Sesuai kebutuhan kita di awal modul, VPC ini bisa menjadi solusi. Anda dapat menentukan ruang jaringan Anda sendiri serta mengontrol bagaimana jaringan dan sumber daya Amazon EC2 terekspos ke Internet.

Bahkan, Anda juga dapat memanfaatkan opsi keamanan di Amazon VPC untuk memberikan akses yang lebih granular untuk paket yang akan masuk dan keluar dari Amazon EC2 instance di jaringan virtual Anda.

Amazon Virtual Private Cloud (VPC) merupakan sebuah konfigurasi di mana seakan-akan kita memiliki cloud sendiri di dalam AWS. Amati gambar di bawah ini yang menjelaskan seputar VPC:

Amazon VPC memiliki karakteristik sebagai berikut:

• VPC adalah jaringan virtual yang didedikasikan khusus untuk kita (atau lebih spesifik lagi, untuk akun AWS kita). Tidak ada orang/akun lain yang akan memiliki akses ke VPC tersebut tanpa seizin dan konfigurasi dari kita.
• VPC membutuhkan alamat IPv4. Secara paralel, kita juga bisa memberikan IPv6 jika diperlukan.
• VPC memungkinkan kita untuk menentukan alamat IP CIDR (Classless Inter-Domain Routing) tertentu bagi masing-masing resources di dalamnya.
• VPC memberikan aturan yang ketat untuk aliran data masuk dan keluar dari VPC.

Selain itu, penempatan landasan jaringan VPC akan berada di satu AWS Region. Di dalam VPC, Anda dapat meletakkan resources apa pun yang tersebar di beberapa Availability Zone di dalam satu Region. Hal ini ditunjukkan dalam gambar berikut:

Jenis-Jenis Amazon VPC

Berdasarkan arsitekturnya, Amazon VPC bisa dibagi ke dalam tiga kategori, yaitu:

• Satu VPC, dengan satu akun AWS.
• Banyak VPC, dengan satu akun AWS.
• Banyak VPC, dengan beberapa akun AWS.

Supaya dapat dipahami lebih jelas, mari kita uraikan satu per satu. Let’s go!

Satu VPC, Satu Akun

Di dunia nyata, jarang ada pengguna AWS yang hanya menggunakan satu VPC dalam satu akun. Terdapat beberapa kasus penggunaan untuk kategori ini, antara lain:

• Aplikasi kecil atau tunggal (single application) yang dikelola oleh satu orang atau tim yang sangat kecil
  Kasus penggunaan ini mungkin akan sesuai untuk aplikasi yang baru berkembang atau tim yang masih kecil.

• Komputasi berkinerja tinggi (High Performance Computing)
  HPC membutuhkan latensi sekecil mungkin di mana menempatkan resources di satu lingkungan VPC akan mendapatkan latensi yang lebih baik dibandingkan menyebarkannya di beberapa VPC.

• Manajemen identitas
  Untuk memenuhi unsur keamanan, satu VPC bisa memberikan solusi terbaik.

Selanjutnya, mari kita bahas konfigurasi yang lebih umum digunakan oleh pengguna AWS, yakni banyak VPC dalam satu akun.

Banyak VPC, Satu Akun

Arsitektur kedua ini umum digunakan oleh pengguna AWS. Kategori ini mendefinisikan beberapa VPC sesuai kebutuhan. Sebagai contoh, gambar di bawah ini menjelaskan empat buah VPC untuk beberapa environment (lingkungan) dalam satu akun AWS, yaitu Prod (Production), Staging, Test, dan terakhir Dev (Development).

Arsitektur ini ideal untuk:

• Tim atau organisasi tunggal, seperti penyedia layanan terkelola (managed service providers).
• Tim terbatas, ini membuatnya lebih mudah untuk mempertahankan standar dan mengelola akses.

Pengecualian: Harus diperhatikan apakah ada kebutuhan untuk memenuhi standar tata kelola dan kepatuhan (Governance and Compliance Standards) di mana mungkin memerlukan isolasi beban kerja yang lebih dalam lagi terlepas dari kompleksitas organisasi.

Banyak VPC, Beberapa Akun

Arsitektur ini mungkin akan lebih cocok untuk organisasi atau perusahaan yang besar dan/atau memiliki banyak tim IT. Selain itu, arsitektur ini juga sesuai untuk perusahaan yang sedang mengantisipasi pertumbuhan yang besar. Simak ilustrasi di bawah berikut:

Contoh di atas menggambarkan sebuah perusahaan multinasional yang memiliki banyak akun, di mana setiap akun juga punya VPC masing-masing. Arsitektur ini juga bisa digunakan untuk organisasi yang memiliki beberapa tim khusus di mana developers hanya akan memiliki akses penuh terhadap Dev environment dan punya restriksi akses terhadap Production environment.

Untuk pemahaman lebih lanjut mengenai arsitektur VPC, AWS telah menerbitkan whitepaper (buku putih) khusus mengenai ini yaitu Building a Scalable and Secure Multi-VPC AWS Network Infrastructure. 

Subnets

Seperti yang sudah dijelaskan sebelumnya, VPC adalah jaringan virtual yang didedikasikan untuk akun AWS kita. Saat membuat VPC, kita harus menentukan rentang alamat IPv4 dalam bentuk blok Classless Inter-Domain Routing (CIDR), misalnya 10.0.0.0/16. Ini adalah blok CIDR utama untuk VPC kita. 

Selanjutnya, kita membagi-bagi blok CIDR tadi ke beberapa sub block atau kelompok alamat IP yang lebih kecil. Sub block ini disebut sebagai subnet. 

Setiap subnet harus berada seluruhnya dalam satu Availability Zone. Itu artinya, kita bisa membuat Subnet 1 di Availability Zone A, Subnet 2 di Availability Zone B, dan Subnet 3 di Availability Zone C.

Berikut adalah beberapa atribut kunci dari subnet:

• Subnet adalah subset dari blok CIDR VPC.
• Subnet yang berada di dalam setiap blok CIDR tidak boleh bertumpang tindih (overlap).
• Setiap subnet berada sepenuhnya dalam satu Availability Zone.
• Availability Zone dapat terdiri dari beberapa subnet.

PENTING: AWS akan me-reserve 5 alamat IP dari setiap subnet yang didefinisikan.

Saat membicarakan sebuah subnet, kita juga perlu belajar bagaimana cara menentukan rute lalu lintas jaringannya. Maka dari itu, yuk kita belajar tentang route table di materi selanjutnya!

Route Table

Route table berisi sekumpulan aturan (disebut route) yang digunakan untuk menentukan ke mana lalu lintas jaringan dari subnet akan diarahkan. Agar lebih memperjelas pembahasan, berikut adalah hal-hal penting mengenai route table:

• Route table diperlukan untuk mengarahkan lalu lintas antar sumber daya VPC.
• Setiap VPC memiliki route table utama (default).
• Anda dapat membuat route table sendiri (custom).
• Semua subnet harus diasosiasikan ke route table.

Route table utama berada di tingkat VPC. Jika diperlukan, kita dapat menambah, mengubah, dan menghapus route yang ada di route table utama. Namun, kita tidak bisa menghapus route table utama.

Sementara itu, route table custom berada di tingkat subnet. Sebuah subnet hanya bisa diasosiasikan ke satu route table custom. Jika diperlukan, kita bisa menambah, mengubah, dan menghapus route yang ada di route table custom. Route table custom hanya bisa dihapus jika tidak ada lagi asosiasi subnet di dalamnya.

Ada dua jenis subnet yaitu Private dan Public Subnet. Silakan cek gambar berikut yang akan menunjukkan rekomendasi pembagian jenis subnet berdasarkan resources-nya:

Seperti yang ditampilkan pada gambar di atas, kita menggunakan subnet untuk mendefinisikan akses ke internet. Berikut adalah perbedaan antara public subnet dan private subnet:

Kita dapat melihat perbedaan public dan private subnet dari gambar di atas. Oke, setelah belajar mengenai subnet, mari kita bahas mengenai komponen lain yang digunakan terkait jaringan di AWS, yakni Elastic Network Interface dan juga Elastic IP address.

Elastic Network Interface

Elastic Network Interface (ENI) adalah network adapter atau network card virtual yang dapat dipasangkan ke instance AWS. ENI bisa dipindahkan antar-instance EC2 yang berada di Availability Zones yang sama.

Saat dipindahkan, ENI akan tetap menyimpan beberapa konfigurasi, seperti:

• Alamat IP Private
• Alamat IP Elastic (Elastic IP Address)
• MAC address

Ketahuilah! Satu instance EC2 bisa memiliki satu atau lebih ENI dan masing-masing ENI tersebut bisa saja berada di subnet yang berbeda, tetapi sekali lagi ingat, harus tetap berada di Availability Zone yang sama. Konfigurasi ini disebut dual-homed atau multi-homed.

Elastic IP Address

Elastic IP Address adalah alamat IPv4 publik yang dipesan (reserve) khusus untuk kita. Elastic IP address ini adalah resource yang ada di tingkat Region. Berikut adalah hal-hal penting mengenai Elastic IP Address:

• Dapat diasosiasikan dengan sebuah instance atau ENI.
• Bisa diasosiasikan kembali (re-associate) dan mengarahkan lalu lintas dengan segera.
• Secara default, setiap akun AWS dapat memiliki 5 IP Publik per AWS Region.
• EIP bisa didapatkan dari alamat yang dibawa sendiri alias Bring Your Own IP (BYOIP).

Gateways

Internet Gateway

Internet Gateway adalah komponen VPC yang dapat horizontal scaling, redundant, dan highly available. Ia memungkinkan kita untuk mengomunikasikan antara VPC dan internet. Internet Gateway adalah salah satu dari layanan Managed Services (layanan terkelola) dari AWS.

Internet Gateway memiliki dua tujuan: 

• Menjadi target di route table VPC kita untuk lalu lintas yang akan dirutekan internet. 
• Melakukan Network Address Translation (NAT) alias terjemahan alamat jaringan untuk instance yang telah di-assign alamat IPv4 publik. 

Internet Gateway mendukung lalu lintas IPv4 dan IPv6. Ilustrasi berikut menunjukkan konfigurasi Internet Gateway di route table:

Gambar di atas mendefinisikan sebuah subnet, yaitu subnet publik. Pada route table, kita memasukkan default route yaitu 0.0.0.0/0 dengan target igw-id yang merujuk ke Internet Gateway.

NAT Gateway

Kita dapat menggunakan Network Address Translation (NAT) gateway untuk memungkinkan resource yang berada di private subnet terhubung ke internet atau layanan AWS lainnya secara satu arah (outbound), tetapi mencegah traffic internet dari luar untuk masuk dan memulai koneksi dengan resource tersebut (inbound).

Pada ilustrasi di atas, kita membuat subnet tambahan yaitu private subnet 10.0.20.0/24. Subnet ini tidak memiliki route di dalam route table-nya yang menunjuk ke internet gateway. Dari konfigurasi sebelumnya, kita telah memiliki public subnet yang memiliki route yang menuju ke Internet Gateway yaitu <igw-id>. 

Di dalam public subnet, kita melakukan provisioning NAT gateway <nat-id>. Karena berada di public subnet, maka <nat-id> juga mengerti mengenai adanya default route yang mengarah ke <igw-id>. Selanjutnya, kita mendefinisikan default route di private subnet yang menunjuk ke <nat-id>.

Dengan informasi di atas, maka saat kita membuat sebuah instance EC2 di private subnet, walaupun ia memiliki IP address private, instance ini akan tetap bisa mengakses internet melalui NAT Gateway. Ingat! Koneksi dari instance ini akan bersifat satu arah (arah keluar/outbound).

PENTING! Kita dikenai biaya untuk membuat dan menggunakan NAT gateway.

Rekomendasi tentang Subnet

Gunakanlah subnet yang lebih besar dibandingkan yang kecil (misal /24 ke atas), sebabnya:  

• Penempatan workload (beban kerja) menjadi lebih sederhana.  
• Kemungkinan kehabisan alamat IP akan lebih kecil.

Selain itu, kita juga dapat mempertimbangkan dua hal berikut dalam membuat arsitektur subnet, antara lain:

• Jika kita tidak yakin mengenai konfigurasi subnet, mulailah dengan satu subnet public dan private di setiap Availability Zone.
• Umumnya kita akan butuh lebih banyak IP di subnet private dibandingkan subnet public.

Keamanan Jaringan

Saat menggunakan VPC, keamanan jaringan ditangani oleh dua layanan AWS, yaitu Security Group dan Network ACL. Sebelum kita membahas keduanya lebih lanjut, silakan pelajari tabel di bawah ini: 

Security Group	Network ACL
Bekerja di tingkat instance (sebagai pertahanan lapis pertama)	Bekerja di tingkat Subnet (sebagai pertahanan lapis kedua)
Mendukung rules Allow saja	Mendukung rules Allow dan Deny
Stateful:  Lalu lintas kembali (return traffic) diizinkan secara otomatis	Stateless:  Lalu lintas kembali (return traffic) harus diperbolehkan secara eksplisit dengan rules
Semua aturan dievaluasi sebelum memutuskan apakah akan mengizinkan lalu lintas	Rules akan dievaluasi dalam urutan numerik saat memutuskan apakah akan mengizinkan lalu lintas
Dapat di-apply (diterapkan) ke instance pada saat peluncuran atau bisa juga menambah/mengubah security group setelah instance diluncurkan	Secara otomatis, semua instance yang berada di dalam subnet akan diperiksa oleh NACL yang terasosiasi/terpasang

Security Group

Security Group bertindak sebagai firewall virtual untuk instance yang dapat mengontrol lalu lintas masuk dan keluar. Saat meluncurkan sebuah instance di VPC, kita dapat menetapkan hingga 5 Security Group untuk instance tersebut.

Security Group bekerja di tingkat instance, bukan di tingkat subnet. Oleh karena itu, setiap instance dalam subnet di VPC kita dapat ditetapkan ke kumpulan Security Group yang berbeda.

Kita dapat mendefinisikan rules untuk Security Group yang melakukan pemeriksaan berdasarkan arah (inbound/outbound), protokol dan port, serta sumbernya. Gambar berikut menunjukkan contoh konfigurasi dari Security Group:

Meski kita bisa mendefinisikan Inbound/Outbound rules, praktik yang umum dilakukan oleh pengguna AWS adalah dengan mendefinisikan hanya Inbound rules saja untuk setiap Tier dari aplikasi atau sistem yang ada di AWS VPC.

PENTING! Koneksi dan data yang berjalan dari/ke instance EC2 akan diperiksa terhadap seluruh rules yang didefinisikan dalam Security Group yang diaplikasikan ke instance tersebut.

Network Access Control List (Network ACL)

Network ACL adalah lapisan keamanan opsional yang bertindak sebagai firewall untuk mengontrol lalu lintas masuk dan keluar dari subnet. Kita dapat mengaitkan/mengasosiasikan beberapa subnet dengan satu Network ACL. Namun, subnet hanya dapat dikaitkan/diasosiasikan dengan satu Network ACL pada satu waktu.

Network ACL bekerja di tingkat subnet dan didefinisikan di tingkat VPC. Di tingkat VPC, terdapat Network ACL default yang akan diaplikasikan ke seluruh subnet yang tidak memiliki Network ACL custom. Berikut adalah contoh konfigurasi dari Network ACL:

Coba kita pikirkan, rules mana yang memperbolehkan seluruh akses terbuka? Apa yang akan terjadi jika rules tersebut dihapus?

Warning Ikuti modul latihan ini sesuai dengan langkah-langkah yang kami berikan. Jika Anda telah menyelesaikan latihan ini, harap mengikuti tahapan Clean Up yang ada di akhir latihan untuk mengetahui bagaimana cara menghapus resource yang telah dibuat.

Hands-on Lab: Membuat Virtual Private Cloud

Pada latihan sebelumnya, Anda telah berhasil membangun arsitektur sederhana, yakni membuat EC2 instance dan RDS instance, lalu menempatkannya ke subnet yang sesuai. Sekarang, kita akan membuat jaringan privat menggunakan VPC berdasarkan skenario tertentu. 

Memang betul kita sudah belajar membuat VPC di latihan sebelumnya, tetapi itu menggunakan VPC wizard sehingga proses pembuatannya otomatis dengan konfigurasi yang sederhana.

Nah, karena sudah belajar mengenai jaringan di AWS, mari naikkan level skill kita dengan membuat VPC secara manual, lalu ciptakan koneksi di antara dua VPC dengan VPC peering. Menarik, bukan?

Tetapi sebelum itu, yuk kita kaitkan ke skenario startup warung kopi. Katakanlah Anda ingin memiliki arsitektur yang membagi lingkungan beban kerja antara Development dan Testing. 

Pada lingkungan Development terdapat 2 EC2 instance (1 terletak di subnet publik dan lainnya di subnet privat). Sedangkan pada lingkungan Testing, hanya ada 1 EC2 instance di subnet privat. Berikut adalah gambaran arsitekturnya: 

Nah, dari skenario di atas menunjukkan bahwa kita memiliki kebutuhan yang unik. Maka dari itu, pada latihan kali ini kita akan melakukan tahapan-tahapan berikut:

1. Membuat dua VPC secara manual.
2. Membangun koneksi VPC peering untuk kedua VPC.
3. Menguji koneksi antara dua VPC tersebut.

Selama melakukan praktik, lihatlah gambar arsitektur di atas secara berulang agar Anda paham setiap langkah yang sedang dilakukan. Penasaran seperti apa langkah-langkahnya? Yuk kita mulai dari bagian ke 1.

Hands-on Lab: Membuat Virtual Private Cloud - Membuat VPC A

 Di bagian ini, kita akan melakukan beberapa tahapan. Mulai dari membuat VPC A, memasang Internet Gateway, membuat subnet publik dan privat, serta mengasosiasikan route table. Yuk kita langsung ikuti langkah-langkah berikut:

1. Langkah pertama, silakan buka AWS Management Console, lalu masuk ke halaman VPC (Virtual Private Cloud). Ketikkan VPC di kotak pencarian di samping Services.
   
   
   

2. Pastikan Anda sedang berada di Region Singapore (lihat kanan atas). Masuklah ke menu Your VPCs pada navigasi sebelah kiri, kemudian klik tombol Create VPC.
   
   
   

3. Isikan sesuai konfigurasi berikut:

   Name tag	VPC-A
   IPv4 CIDR block	10.100.0.0/16

   Jika sudah, lanjutkan dengan klik tombol Create VPC.
    

4. Oke, kita telah membuat VPC A. Selanjutnya, mari kita buat Internet Gateway yang kemudian akan dipasang ke VPC A. Masih berada di VPC dashboard, silakan masuk ke menu Internet Gateways -> Create Internet Gateway.
   
   
   

5. Isikan nama Internet Gateway Anda dengan VPC-A-IGW, lalu klik tombol Create internet gateway.
   
   
   

6. Setelah Internet Gateway terbuat, masuklah kembali ke menu Internet Gateways pada navigasi sebelah kiri, centang kotak di samping nama VPC-A-IGW, klik tombol Action -> Attach to VPC.
   
   
   

7. Pada bagian Available VPCs, pilihlah VPC-A, lalu klik tombol Attach internet gateway.
   
   
   

8. Oke, kita telah berhasil memasang Internet Gateway ke VPC A. Langkah selanjutnya adalah membuat subnet publik untuk VPC A. Yuk klik menu Subnets -> Create subnet.
   
   
   

9. Di bagian VPC ID, klik drop down arrow dan pilihlah VPC-A.
   
   
   

10. Kemudian pada bagian Subnet settings, silakan isi field yang diperlukan sesuai dengan konfigurasi berikut:

    Subnet name	VPC-A-Subnet-Public
    Availability Zone	No preference
    IPv4 CIDR block	10.100.0.0/24

    Jika sudah, silakan lanjutkan dengan klik tombol Create subnet.
     

11. Setelah berhasil membuat subnet publik di VPC A, selanjutnya mari kita buat konfigurasi route table untuknya. Masuklah ke menu Route Tables -> Create route table.
    
    
    

12. Pada halaman ini, silakan isikan dengan konfigurasi berikut:

    Name tag	VPC-A-RT-Public
    VPC	VPC-A

    Jangan lupa menambahkan tag agar mempermudah penamaan route table. Klik tombol Add Tag, lalu isilah sesuai dengan nilai-nilai berikut:

    Key	Name
    Value	VPC-A-RT-Public

    Jika sudah, lanjutkan dengan klik tombol Create.
    
    Setelah kalimat “The following Route Table was created” muncul, klik tombol Close. Seketika Anda akan diarahkan ke halaman awal Route Table.
    
    

13. Route table yang telah kita buat hanya memiliki rute lokal CIDR VPC A, yaitu 10.100.0.0/16 (lihat gambar di bawah). Sementara itu, kita juga membutuhkan route yang menuju ke Internet Gateway agar subnet publik dapat berkomunikasi dengan internet. Jadi, mari tambahkan route baru dengan klik Route Table Anda (VPC-A-RT-Public), lalu pada bagian bawah klik tab Routes, dan klik tombol Edit Routes.
    
    
    

14. Untuk menambahkan route, klik tombol Add route. Lalu isilah konfigurasi berikut:

    Destination	0.0.0.0/0
    Target	Internet Gateway -> VPC-A-IGW

    Jika sudah, silakan klik tombol Save routes. Saat muncul kalimat “Routes successfully edited”, lanjutkan dengan klik Close. Perhatikan, sekarang Anda akan memiliki route seperti berikut:
     

15. Selepas mengedit route, mari kita asosiasikan route table tersebut ke publik subnet yang telah dibuat. Caranya, masuklah ke tab Subnet Associations -> Edit subnet associations.
    
    
    

16. Di halaman ini, pilihlah subnet publik Anda, yakni VPC-A-Subnet-Public. Kemudian, klik tombol Save.
    
    
    

17. Oke, sampai tahap ini, kita telah berhasil membuat VPC A dan subnet publiknya. Langkah selanjutnya, yuk kita buat subnet privat. Silakan masuk kembali ke menu Subnets yang ada di navigasi kiri. Kemudian, klik tombol Create subnet.
    
    
    

18. Nah, kita sudah berada di halaman Create subnet. Di bagian VPC, pilihlah VPC ID yang telah kita buat sebelumnya, yaitu VPC-A.
    
    
    

19. Gulirkan halaman ke bagian Subnet settings. Sesuai gambar arsitektur kita, silakan isi dengan konfigurasi berikut:

    Subnet name	VPC-A-Subnet-Private
    Availability Zone	No preference
    IPv4 CIDR block	10.100.1.0/24

    
    Jika sudah selesai, silakan klik tombol Create subnet.
    
    
    

20. Seusai membuat subnet privat, jangan lupa untuk mengedit route table-nya. Klik Route Tables -> Create route table.
    
    
    

21. Di halaman ini, isikan dengan konfigurasi berikut:

    Name tag	VPC-A-RT-Private
    VPC	VPC-A

    Tambahkan juga tag agar memudahkan penamaan route table.

    Key	Name
    Value	VPC-A-RT-Private

    Jika sudah sesuai, silakan lanjutkan dengan klik tombol Create.
    
    Setelah kalimat “The following Route Table was created” muncul, klik tombol Close. Seketika Anda akan diarahkan ke halaman awal Route Table.
    
    

22. Yes! Route table pun telah terbuat. Selanjutnya, mari kita asosiasikan route table tersebut ke subnet privat. Pilih VPC-A-RT-Private, lalu masuk ke tab Subnet Associations, dan klik tombol Edit subnet associations.
    
    
    

23. Karena kita ingin mengasosiasikan route table tadi ke subnet privat, pilihlah VPC-A-Subnet-Private, lalu klik tombol Save.
    

 

Yeaah! Kita sudah berhasil membangun VPC A dan isinya. Yuk lihat kembali gambar arsitektur kita. 

Di bagian 1 ini, kita sudah menyelesaikan beberapa tahapan, mulai dari membuat VPC A, memasang Internet Gateway, membuat subnet publik dan privat, serta mengasosiasikan subnet tersebut ke route table masing-masing. 

Di bagian selanjutnya, kita akan meluncurkan EC2 instance di masing-masing subnet yang telah dibuat. Penasaran seperti apa? Let’s Go!

Hands-on Lab: Membuat Virtual Private Cloud - Meluncurkan EC2 Instance di VPC A

 Setelah pada bagian 1 membuat VPC A, sekarang mari kita coba untuk meluncurkan instance di masing-masing subnetnya. Yuk ikuti langkah-langkah berikut:

1. Masuklah ke halaman Amazon EC2 dari AWS Management Console dengan cara mengetikkan ec2 di kotak pencarian bagian atas..
   
   
   

2. Pada halaman EC2 Dashboard, gulirlah ke bawah dan klik Launch instance.
   
   
   

3. Pilihlah Amazon Linux 2 AMI dengan klik tombol Select.
   
   
   

4. Kemudian, pilih t2.micro, lalu klik tombol Next: Configure Instance Details.
   
   
   

5. Nah, di halaman ini, ubahlah beberapa konfigurasi berikut:

   Network	VPC-A
   Subnet	VPC-A-Subnet-Public
   Auto-assign Public IP	Enable

   Perhatikan gambar di bawah ini, jika sudah silakan klik tombol Next: Add Storage.
   
   
   

6. Kita tidak akan mengubah apa pun di sini, jadi langsung saja klik Next: Add Tags.
    

7. Tambahkan tag dengan klik tombol Add Tag, lalu sesuaikan seperti ini:

   Key	Name
   Value	VPC-A-EC2-Public

   Lalu, lanjutkan dengan klik tombol Next: Configure Security Group.
   
   
   

8. Ubahlah Security group name dan Description menjadi VPC-A-SG-Public dan biarkan yang lain sesuai default. Dengan konfigurasi ini kita mengizinkan akses SSH ke instance tersebut. Lanjut klik tombol Review and Launch.
   
   
   

9. Ini adalah halaman review sebelum instance Anda diluncurkan. Pastikan semua konfigurasinya sudah sesuai, lalu klik tombol Launch.
   
   
   

10. Agar bisa terhubung ke instance, Anda memerlukan key pair. Nah, silakan pilih Create a new key pair, berikan nama dicoding-demo, klik tombol Download Key Pair, dan simpanlah file tersebut di folder yang mudah diakses (taruh di folder Downloads agar mempermudah latihan kali ini).
    
    
    

11. Setelah itu, luncurkan instance Anda dengan klik tombol Launch Instances.
    
    
    

12. Horray! Instance Anda pun telah berhasil diluncurkan, silakan klik View Instances untuk melihatnya.
    
    
    

13. Tunggu hingga status pada instance Anda berubah menjadi Running yang menandakan bahwa instance Anda telah berjalan dengan sempurna.
    
    
    

14. Oke, pada tahap ini kita sudah berhasil meluncurkan instance di subnet publik VPC A. Langkah selanjutnya, silakan luncurkan instance di subnet privat VPC A dengan konfigurasi berikut (biarkan yang lainnya default):

    Configure Instance Details
    Network	VPC-A
    Subnet	VPC-A-Subnet-Private
    Auto-assign Public IP	Disable
    Add Tags
    Key	Name
    Value	VPC-A-EC2-Private
    Configure Security Group
    Security group name	VPC-A-SG-Private
    Description	VPC-A-SG-Private
    Source (kolom source pada tipe SSH)	10.100.0.0/24

15. Pada bagian key pair, pilih Choose an existing key pair, pastikan Select a key pair adalah dicoding-demo, centang pada kalimat “I acknowledge …”, lalu klik tombol Launch Instances.
    
    
    

Yuhuu! Kita sudah berhasil meluncurkan instance di setiap subnet VPC A, baik subnet publik maupun privat. Apa langkah selanjutnya? Simak di bagian selanjutnya!

Hands-on Lab: Membuat Virtual Private Cloud - Membuat VPC B, Meluncurkan EC2 Instance, dan Membangun VPC Peering

 Sebelum memulai, mari lihat kembali gambar arsitektur untuk mengetahui progres yang telah kita lakukan.

Tahukah Anda apa langkah selanjutnya? Yup! Kita belum membuat VPC B, subnet privatnya, dan meluncurkan instance di subnet tersebut. Langkah-langkah pembuatannya hampir serupa seperti pada bagian latihan sebelumnya, hanya saja di sini kita tidak akan memasang Internet Gateway ke VPC B. Mengapa begitu?

Itu karena memang kita tak ingin instance di dalamnya dapat diakses oleh siapa pun dari internet. Kebutuhan kita adalah instance di VPC B hanya bisa diakses oleh instance di subnet privat VPC A sesuai pada gambar arsitektur. Oke, tak perlu menunggu lama lagi, yuk langsung mulai saja.

1. Silakan buat VPC dengan konfigurasi berikut (biarkan yang lain default):

   Name tag	VPC-B
   IPv4 CIDR block	10.200.0.0/16

   
   

2. Selanjutnya, silakan buat subnet dengan konfigurasi berikut (biarkan yang lain default):

   VPC ID	VPC-B
   Subnet name	VPC-B-Subnet-Private
   IPv4 CIDR block	10.200.1.0/24

   
   

3. Kemudian, buatkan route table untuk subnet tersebut sesuai dengan nilai-nilai pada tabel di bawah ini:

   Name tag	VPC-B-RT-Private
   VPC	VPC-B
   Key (Tag)	Name
   Value (Tag)	VPC-B-RT-Private

   
   

4. Selepas itu, editlah subnet associations-nya agar route table yang kita buat barusan terpasang ke VPC-B-Subnet-Private.
   
   

5. Oke, kita sudah berhasil membuat VPC, subnet privat, serta mengedit route table-nya. Selanjutnya, yuk kita luncurkan instance di subnet tersebut.

   Configure Instance Details
   Network	VPC-B
   Subnet	VPC-B-Subnet-Private
   Auto-assign Public IP	Disable
   Add Tags
   Key	Name
   Value	VPC-B-EC2-Private
   Configure Security Group
   Security group name	VPC-B-SG-Private
   Description	VPC-B-SG-Private
   Source (kolom source pada tipe SSH)	10.100.1.0/24

   Oke, kita berhenti sejenak di bagian security group ini. Sesuai pada gambar arsitektur, kita ingin instance di subnet privat VPC A dapat melakukan SSH atau Ping ke instance di subnet privat VPC B. Maka dari itu, silakan tambahkan rule dengan Type adalah All ICMP - IPv4 dan Source-nya 10.100.1.0/24. Jika Anda merasa kesulitan, silakan amati gambar berikut:
    

6. Oh iya, untuk key pair, pilihlah yang sama seperti sebelumnya, yakni dicoding-demo. Silakan luncurkan instance Anda. Sekarang, kita telah memiliki 3 instance di masing-masing subnet yang berbeda.
   
   
   

7. Sekarang, mari lakukan SSH terhadap instance dengan nama VPC-A-EC2-Public. Tentu Anda sudah tahu caranya, bukan? Kita telah mempraktikkannya di latihan sebelumnya.
   
   
   

8. Dari instance VPC-A-EC2-Public, silakan coba untuk melakukan SSH ke instance VPC-A-EC2-Private. Caranya, salinlah Private IPv4 addresses untuk instance VPC-A-EC2-Private, lalu ketikkan sintaks berikut di Command Prompt/Terminal:

   ssh ec2-user@privateIP

   Jika Anda merasa kesulitan, silakan lihat gambar di bawah ini.
   (Cara melihat Private IPv4 addresses)
   
   
   (Cara melakukan SSH di dalam instance)
   
   
   

9. Waduh! Jika Anda lihat gambar di atas, kita mengalami eror sehingga tidak bisa melakukan SSH ke instance VPC-A-EC2-Private. Eror tersebut bisa terjadi karena tidak adanya file key pair di instance VPC-A-EC2-Public saat ini. Jadi, mari kita buat.
   
   

10. Silakan buka file key pair Anda (dicoding-demo.pem) yang tadi disimpan di folder Downloads dengan aplikasi notepad, lalu salin semua isinya.
    
    
    

11. Kembali ke Command Prompt/Terminal. Buatlah sebuah file bernama dicoding-demo.pem dengan sintaks berikut:

    nano dicoding-demo.pem

    
    

12. Kemudian paste (klik kanan) teks yang tadi Anda salin. Simpanlah file tersebut dengan cara CTRL + X -> Y -> Enter.
    
    
    

13. Selanjutnya, ketikkan sintaks di bawah ini untuk mengubah permission pada file dicoding-demo.pem.

    chmod 400 dicoding-demo.pem

    
    
14. Oke, cobalah lakukan SSH lagi ke instance VPC-A-EC2-Private dengan sintaks:

    ssh -i dicoding-demo.pem ec2-user@privateIP

    Amati gambar berikut:
    
    
    

15. Mantap! Kita sudah berhasil terhubung ke instance VPC-A-EC2-Private. Sekarang, yuk kita coba lakukan SSH dan Ping ke instance VPC-B-EC2-Private dari VPC-A-EC2-Private.
    
    

16. Pertama, salinlah Private IPv4 Private addresses dari instance VPC-B-EC2-Private.
    
    
    

17. Lalu, kembali ke Command Prompt/Terminal dan ketikkan sintaks:

    ssh ec2-user@privateIP dan ping privateIP

    Lihat gambar berikut:
    
    
    

18. Tenang! Anda memang tak akan bisa melakukan SSH maupun Ping ke instance VPC-B-EC2-Private karena kita belum melakukan VPC Peering. Jadi, mari kita buat!
    
    

19. Bukalah halaman layanan VPC, masuk ke menu Peering Connections pada navigasi sebelah kiri, dan klik tombol Create Peering Connection.
     

20. Pada bagian Peering connection name tag, isilah VPC-A-VPC-B-Peering. Kemudian untuk VPC (Requester), pilihlah VPC-A.
    
    
    

21. Nah di sini, biarkan bagian Account dan Region sesuai default. Lalu untuk VPC (Accepter), pilihlah VPC-B. Jika sudah, silakan gulir ke halaman paling bawah dan klik tombol Create Peering Connection. Saat muncul halaman yang menyatakan bahwa VPC Peering kita sukses, klik OK.
    
    
    

22. Koneksi VPC Peering Anda akan berstatus Pending Acceptance. Jadi, mari kita terima permintaan tersebut. Pilih koneksi VPC Peering Anda, klik tombol Actions -> Accept Request -> Yes, Accept -> Close. Status koneksi VPC Peering Anda pun akan berubah menjadi Active.
    
    
    

23. Oke, koneksi VPC Peering telah kita buat. Selanjutnya, agar instance VPC-A-EC2-Private dan VPC-B-EC2-Private bisa berkomunikasi, kita juga harus mengubah route table keduanya. Yuk kita eksekusi!
    
    

24. Masih di halaman VPC, bukalah menu Route Tables, pilih VPC-A-RT-Private, lalu masuk ke tab Routes, dan klik tombol Edit routes.
     

25. Silakan tambahkan route dengan klik Add route, lalu isikan konfigurasi berikut:

    Destination	10.200.1.0/24
    Target	Peering Connection -> VPC-A-VPC-B-Peering

    Amati gambar di bawah ini, jika sudah silakan klik tombol Save routes. Ketika muncul halaman yang mengatakan “Routes successfully edited”, klik Close.
    
    
    

26. Jangan lupa, ubah juga route table untuk VPC-B-RT-Private. Silakan pilih VPC-B-RT-Private, buka tab Routes, klik tombol Edit routes.
    
    
    

27. Tambahkan route dengan klik Add route, lalu isi sesuai konfigurasi berikut:

    Destination	10.100.1.0/24
    Target	Peering Connection -> VPC-A-VPC-B-Peering

    Amati gambar di bawah ini, jika sudah silakan klik tombol Save routes. Ketika muncul halaman yang mengatakan “Routes successfully edited”, klik Close.
    
    
    

28. Oke, mari kita kembali ke Command Prompt/Terminal. Silakan lakukan ping ke Private IP Addresses dari VPC-B-EC2-Private dengan sintaks:

    ping privateIP

    
    
    

29. Yuhuuu!Kita sudah berhasil melakukan ping ke instance VPC-B-EC2-Private. Sekarang, yuk kita coba lakukan SSH dengan sintaks berikut:

    ssh ec2-user@privateIP

    Lihat gambar di bawah ini.
    
    
    

30. Waduh, masih gagal ternyata! Tahukah Anda kenapa ini bisa terjadi? Yup, sama seperti kasus sebelumnya yaitu tidak ada file key pair di instance VPC-A-EC2-Private saat ini. Mari kita buat!
    
    

31. Silakan salin kembali isi dari file dicoding-demo.pemAnda. Kemudian, buatlah sebuah file dicoding-demo.pem di VPC-A-EC2-Private dengan sintaks:

    nano dicoding-demo.pem

    
    

32. Kemudian paste (klik kanan) teks yang tadi Anda salin. Simpanlah file tersebut dengan cara CTRL + X -> Y -> Enter.
    
    

33. Selanjutnya, ketikkan sintaks di bawah ini untuk mengubah permission pada file dicoding-demo.pem.

    chmod 400 dicoding-demo.pem

    
    
34. Oke, cobalah lakukan SSH lagi ke instance VPC-B-EC2-Private dengan sintaks:

    ssh -i dicoding-demo.pem ec2-user@privateIP

    Lihat gambar berikut:
    
    
    
35. Yeaah! Sekarang kita sudah berhasil melakukan SSH dan sekarang kita sudah berada di instance VPC-B-EC2-Private. Sesuai pada gambar arsitektur, VPC-A-EC2-Private dan VPC-B-EC2-Private harus bisa saling berkomunikasi. Jadi, mari kita tes dengan lakukan ping ke instance VPC-A-EC2-Private, ketikkan sintaks berikut:

    ping privateIP

    Simak gambar berikut:
    
    
    

36. Hmm! Sepertinya masih gagal. Tenang! Ini bisa kita selesaikan dengan mengubah konfigurasi dari security group dari instance VPC-A-EC2-Private. Silakan pilih VPC-A-EC2-Private, masuklah ke tab Security, dan klik nama VPC-A-SG-Private.
    
    
    
    
    

37. Kemudian, klik tombol Edit inbound rules.
    
    
    

38. Tambahkan rule dengan klik tombol Add rule, lalu sesuaikan dengan konfigurasi berikut:

    Type	All ICMP - IPv4
    Source	10.200.1.0/24

    Silakan amati gambar di bawah ini. Jika sudah, silakan gulir halaman ke paling bawah dan klik tombol Save rules.
    
    
    

39. Kembali ke Command Prompt/Terminal. Lakukan ping kembali ke  VPC-A-EC2-Private. Ta-da!
    
    
    

Yeah! Kita telah menyelesaikan semua tahapan dan merealisasikan skenario dari gambar arsitektur. Kita sudah membuat VPC A dan B, Subnet untuk setiap VPC, mengonfigurasi security group dan route table, memasang internet gateway, membuat koneksi dengan VPC Peering, dan mengujinya langsung dengan melakukan SSH dan Ping. Mantap!

Clean Up Hapus semua resource yang telah Anda buat, termasuk EC2, VPC, Subnet, VPC Peering, dll. Ini semua harus Anda lakukan untuk menghindari segala biaya meskipun akun Anda adalah Free Tier.

Ikhtisar 

Wow, banyak sekali materi yang kita bahas di modul ini ya. Jangan khawatir, berikut adalah beberapa hal yang bisa membantu dalam mengingat materi yang telah kita telaah:

1. Kita telah belajar tentang Amazon VPC dan beberapa kategorinya berdasarkan kasus penggunaan, seperti satu VPC dalam satu akun, banyak VPC dalam satu akun, dan banyak VPC dalam beberapa akun.

2. Kita juga telah membahas mengenai subnet, gateway, dan keamanan jaringan secara mendalam.

3. Gunakan hal-hal yang kita pelajari untuk membentuk pertahanan jaringan multi-layer.
   Konfigurasi-konfigurasi yang ada di Route Table, Network ACL, dan Security Group pada dasarnya berguna untuk kita mengatur dan mengarahkan lalu lintas jaringan di dalam VPC.Gunakan masing-masing komponen sebagai satu kesatuan dalam membentuk pertahanan jaringan kita. Gambar di atas dapat membantu memvisualisasikan hubungan masing-masing komponen.

4. Berikut adalah hal-hal mendasar yang harus dilakukan untuk memastikan akses internet dari dalam VPC.

   1. Tempatkan Internet Gateway di VPC.
   2. Pastikan ada route di dalam Route Table yang menunjuk ke Internet Gateway.
   3. Pastikan EC2 instance memiliki Public IP atau Elastic IP.
   4. Pastikan Network ACL dan Security Group memperbolehkan akses yang relevan.
      
      

Tetap semangat ya. Perjalanan kita masih panjang, bersiaplah! Yuk kita meluncur ke modul berikutnya!

Pengantar ke Jaringan di AWS

Selamat! Startup kita semakin berkembang. Kita telah melakukan promosi dan menghadiri banyak event agar semakin banyak orang yang mengenal dan mengunjungi website penjualan kopi online kita. 

Karenanya, tuntutan bisnis pun semakin kompleks. Coba bayangkan bagaimana jika kita ingin melakukan promosi “Beli satu kopi dapat kue coklat”, lalu tiba-tiba server mengalami gangguan. Bencana, bukan? Atau, bagaimana jika saking banyaknya orang yang membeli sehingga terjadi “server timeout”. Wah, ini tidak boleh terjadi!

Di modul ini kita akan mempelajari hal-hal yang akan menjawab tuntutan bisnis seperti contoh permasalahan di atas. Ayo kita mulai!

Pada modul sebelumnya kita telah belajar mengenai jaringan, tetapi pembahasan tersebut belum mencakup keseluruhan topik. Maka dari itu, di modul ini kita akan belajar beberapa hal berikut:

• Menghubungkan Jaringan
• VPC Endpoints
• Load Balancing
• High Availability

Keempat subjek di atas akan dibahas pada modul ini. Kita akan menggunakan subjek-subjek tersebut untuk mengembangkan arsitektur startup warung kopi seperti ditunjukkan pada gambar di bawah ini.

Luar biasa, bukan? Di akhir modul ini kita akan memiliki arsitektur aplikasi yang berada di dua availability zone, memiliki kemampuan failover, dan juga load balancing. Masih semangat? Ayo kita mulai!

Menghubungkan Jaringan

Saat membangun arsitektur di AWS, Anda perlu memahami bagaimana cara untuk menghubungkan jaringan. Misalnya, menghubungkan jaringan on-premise dengan AWS, VPC dengan VPC, dan lain sebagainya. Untuk itu, mari kita pelajari beberapa layanan yang dapat menghubungkan jaringan secara detail satu per satu.

Virtual Private Gateway

Secara default, instance yang diluncurkan ke Amazon VPC tidak dapat berkomunikasi dengan jaringan kita, misalnya yang berada di on-premise. 

Kita dapat mengaktifkan akses ke jaringan jarak jauh dari VPC dengan menempatkan virtual private gateway (VGW), membuat route table khusus, memperbarui aturan security group, dan membuat koneksi VPN yang dikelola AWS.

Meskipun kata koneksi VPN adalah istilah umum, dalam dokumentasi Amazon VPC, istilah ini merujuk pada koneksi antara VPC dan jaringan kita yang berada pada lokasi on-premise. AWS juga mendukung IPsec (IP security) VPN connection alias koneksi VPN dengan protokol keamanan internet.

VGW adalah konsentrator VPN di sisi Amazon dari koneksi VPN. Kita dapat membuat VGW dan menempatkannya pada VPC yang diinginkan untuk membuat koneksi VPN. 

Amati gambar di bawah ini yang mengilustrasikan koneksi VPN antara gateway virtual VPC dan data center kita. 

Di AWS, VGW juga mendukung beberapa koneksi gateway sehingga pelanggan dapat menerapkan redundancy dan failover di sisi koneksi VPN. Tersedia juga opsi perutean dinamis dan statis yang dapat memberikan fleksibilitas dalam konfigurasi perutean.

Lebih lanjut, keuntungan menggunakan VGW adalah segala masalah (seperti High Availability) sudah ditangani oleh AWS. 

Selain solusi di atas, tentu saja kita juga dapat membangun koneksi VPN ke jaringan remote (bisa on-premise atau cloud lain) dengan menggunakan Amazon EC2 instance di VPC yang menjalankan software VPN. Selain itu, keuntungan menggunakan VGW adalah segala masalah (seperti high availability) ditangani oleh AWS.

AWS Direct Connect (DX)

Untuk Anda yang membutuhkan koneksi yang lebih cepat dan lebih aman dibandingkan koneksi VPN, AWS menyediakan solusi Direct Connect (DX). AWS DX menyediakan koneksi langsung antara data center on-premise Anda, terhubung dengan Direct Connect partner, dan kemudian langsung terhubung dengan data center AWS sehingga jalur data yang disediakan jauh lebih besar mulai dari 1 sampai 10 Gbps.

AWS Direct Connect (DX) adalah solusi yang dapat melampaui kecepatan dari konektivitas internet. Anda bisa mendapatkan skala akses, kecepatan, dan konsistensi ke jaringan AWS untuk aplikasi penting ini. 

DX tidak melibatkan internet; sebaliknya, ia menggunakan koneksi jaringan pribadi terdedikasi antara solusi on-premise, DX partner, dan AWS. Oke, sekarang mari kita lihat beberapa kasus penggunaan untuk layanan AWS Direct Connect. 

Skenario Penggunaan Direct Connect

Agar memudahkan pembahasan kita, silakan amati gambar berikut yang menunjukkan dua skenario penggunaan Direct Connect.

1. Menggunakan Direct Connect untuk menghubungkan On-Premise network dengan AWS VPC.
   

2. Menggunakan Direct Connect dengan tambahan dukungan VPN.
   

Untuk menggunakan AWS Direct Connect, jaringan kita harus memenuhi salah satu dari ketentuan berikut:

• Jaringan kita terletak di Region yang memiliki layanan AWS Direct Connect. 
• Anda bekerja sama dengan mitra AWS Direct Connect yang merupakan anggota AWS Partner Network (APN). 
• Anda bekerja sama dengan penyedia layanan independen untuk terhubung ke AWS Direct Connect.

Menghubungkan VPC

Mengisolasikan workloads (beban kerja) adalah pendekatan yang baik dan hal ini umum diterapkan dengan penggunaan VPC. Tetapi, adakalanya kita tetap memerlukan komunikasi antara workload-workload yang terdapat di VPC yang berbeda. Hal ini bisa kita dapatkan dengan melakukan VPC Peering.

Berikut adalah hal-hal yang perlu diperhatikan saat kita mendesain VPC Peering:

• VPC Peering hanya bisa digunakan untuk IP private.
• Kita bisa melakukan Peering intra dan antar-Region.
• Block IP antara VPC tidak boleh tumpang tindih.
• Hanya satu resource peering di antara dua VPC mana pun.
• Tidak mendukung hubungan peering transitif.
• Dapat dibuat di antara akun AWS yang berbeda.

Untuk membuat koneksi VPC Peering, VPC pemohon/requester (VPC lokal) mengirimkan permintaan ke VPC peer untuk membuat koneksi VPC Peering. VPC peer dapat dimiliki oleh kita sendiri atau akun AWS lain, tidak boleh terjadi blok CIDR yang tumpang tindih dengan blok CIDR VPC pemohon. VPC peer tujuan harus menerima (accept) permintaan untuk mengaktifkan koneksi VPC Peering. 

Nah, untuk mengizinkan aliran lalu lintas antara VPC peer yang sudah terkoneksi dengan menggunakan alamat IP private, tambahkan route ke satu atau beberapa route table VPC kita yang mengarah ke alamat IP dari VPC peer tujuan. Demikian sebaliknya, VPC peer tujuan juga perlu menambahkan route pada salah satu route table VPC mereka yang mengarah ke rentang alamat IP VPC kita. Diagram di bawah menggambarkan hal ini.

Contoh Pengaplikasian VPC Peering

Sekarang, mari kita lihat contoh pengaplikasian VPC Peering untuk layanan berbagi (shared services). Dalam contoh ini, untuk melaksanakan tanggung jawabnya, tim IT dan Information Security perusahaan menyediakan "Services VPC" yang mana setiap departemen dapat melakukan peer satu sama lain. 

VPC ini memiliki koneksi ke Active Directory, alat pemindaian keamanan, alat pemantauan/pencatatan, dan beberapa fungsi lainnya. VPC ini juga menyediakan proxy yang dapat mengakses resource on-premise.

Perhatikan bahwa ada koneksi VPC Peering dengan VPC yang berada di region yang berbeda, yakni antara Region A dan Region B. Amazon EC2 memungkinkan hubungan peering antara VPC di berbagai AWS Regions. 

VPC Peering antar region memungkinkan sumber daya VPC (seperti EC2 instance, Amazon RDS, dan Lambda function) yang berjalan di AWS Region yang berbeda untuk berkomunikasi satu sama lain menggunakan alamat IP private tanpa memerlukan gateway, koneksi VPN, atau perangkat keras fisik terpisah.

AWS Transit Gateway

AWS Transit Gateway dapat mengoneksikan VPC dengan on-premise melalui hub terpusat sebagai layanan yang terkelola sepenuhnya yang tanpa mewajibkan kita untuk menyediakan peralatan khusus di on-premise. AWS-lah yang akan mengelola ketersediaan dan skalabilitas jaringan tersebut untuk Anda.

AWS Transit Gateway memungkinkan Anda untuk menghubungkan ribuan VPC. Kita dapat memasang semua konektivitas hybrid (VPN dan juga koneksi Direct Connect) ke satu Transit Gateway, di mana ia akan mengonsolidasi dan mengontrol seluruh konfigurasi perutean kita secara terpusat. 

Transit Gateway juga mengontrol bagaimana lalu lintas diarahkan di antara semua jaringan yang terhubung menggunakan route table. Transit Gateway menggunakan topologi hub-and-spoke, yakni model jaringan yang memiliki komponen terpusat dan menghubungkan beberapa jaringan di sekitarnya. Model hub dan spoke ini menyederhanakan manajemen dan mengurangi biaya operasional karena VPC hanya terhubung ke Transit Gateway untuk mendapatkan akses ke jaringan yang terhubung.

Contoh Implementasi Transit Gateway

1. Komunikasi antar-VPC
   Gambar di atas menunjukkan bahwa dengan menggunakan Transit Gateway, kita dapat menyederhanakan konfigurasi Route Table pada setiap VPC. Dengan menggunakan Transit Gateway, kita hanya mendefinisikan rute ke Transit Gateway pada masing-masing VPC. Selanjutnya, kita mendefinisikan route ke masing-masing VPC di dalam Route Table Transit Gateway.

2. Komunikasi terpisah antar masing-masing VPC dan akses VPN
   Skenario yang umum adalah memiliki akses penuh ke lingkungan kita dari sumber VPN. Namun dalam skenario kedua, kita tidak ingin VPC dapat berbicara satu sama lain.
   Untuk mencapai skenario ini, kita memerlukan dua Route Table di dalam Transit Gateway dengan fungsi sebagai berikut:

   1. Route Table warna hijau memberitahukan jalur default ke seluruh VPC yang mengarah ke VPN gateway.
   2. Route Table warna merah selanjutnya memberitahukan jalur ke CIDR block masing-masing VPC.

VPC Endpoints

Amazon VPC Endpoints memungkinkan koneksi pribadi antara VPC dan layanan lainnya tanpa meninggalkan jaringan AWS. Dengan VPC Endpoints, Amazon EC2 instance dapat berkomunikasi dengan layanan AWS di region yang sama dengan alamat IP private. Ia tidak perlu melewati internet, NAT instance, koneksi VPN, atau DX. 

VPC Endpoints juga menyediakan fitur keamanan tambahan seperti kemampuan untuk menambahkan kebijakan untuk mengontrol S3 bucket mana yang dapat diakses atau mengunci S3 bucket ke VPC tertentu.

VPC Endpoint adalah perangkat virtual. Ia merupakan komponen VPC yang horizontally scaled, redundant, highly available, serta memungkinkan komunikasi antara instance dalam VPC dan layanan lainnya tanpa perlu memikirkan availability atau keterbatasan bandwidth pada lalu lintas jaringan.

VPC Endpoints memiliki fitur-fitur berikut:

• Lalu lintas data tetap berada di dalam AWS.
• Layanan AWS tujuan harus berada di region yang sama.
• Horizontally scaled, redundant, dan highly available.

Ada dua jenis VPC EndPoints, yaitu Interface Endpoint dan Gateway Endpoint. Interface Endpoint merupakan ENI (Elastic Network Interface) dengan alamat IP private yang berfungsi sebagai entry point (titik masuk) untuk lalu lintas yang ditujukan ke layanan tertentu.

Sementara itu, Gateway Endpoint adalah target untuk route tertentu di dalam Route Table. Ia digunakan sebagai penghubung pada layanan AWS.

Berikut adalah beberapa layanan yang didukung untuk Interface Endpoint dan Gateway Endpoint:

Interface Endpoint	Gateway Endpoint
Amazon CloudWatch logs	Amazon S3
AWS CodeBuild	Amazon Dynamo DB
Amazon EC2 API
Elastic Load Balancing API
AWS Key Management Service
Amazon Kinesis Data Streams
AWS Service Catalog
Amazon SNS
AWS Systems Manager
Dan masih banyak lainnya

Load Balancing (Penyeimbang Beban)

Saat kita berbicara mengenai load balancing alias penyeimbang beban/muatan, Anda harus berkenalan dengan layanan Elastic Load Balancing (ELB). 

ELB secara otomatis mendistribusikan lalu lintas data yang masuk ke beberapa target, seperti Amazon EC2 instance, container, alamat IP, Lambda function, dan lainnya. ELB dapat menangani berbagai beban lalu lintas data, baik di dalam satu Availability Zone atau tersebar ke beberapa Availability Zone.

Dalam mendesain arsitektur aplikasi, kita tentunya harus memahami bagaimana Web Tier bekerja, beserta dengan penggunaan ELB dalam perancangannya. Dalam pelaksanaannya, ELB tidak hanya mengirim data ke EC2 instance, tetapi juga metrik ke Amazon CloudWatch (layanan pemantauan). 

Metrik dari Amazon EC2 dan ELB dapat juga bertindak sebagai pemicu (trigger) sehingga jika kita melihat kondisi latensi yang sangat tinggi atau server digunakan hingga mendekati batas maksimum, kita dapat memanfaatkan fungsi Auto Scaling (penyesuaian kapasitas otomatis) untuk menambahkan lebih banyak kapasitas ke armada server web.

Setelah mengetahui tentang cara kerjanya, perhatikan poin-poin di bawah ini yang menjelaskan karakteristik dari AWS Elastic Load Balancing:

• Menggunakan protokol HTTP, HTTPS, TCP dan SSL (secure TCP).
• Bisa eksternal atau internal facing.
• Setiap load balancer akan menggunakan DNS name.
• Mengenali dan merespons terhadap instance yang tidak sehat (unhealthy).

AWS ELB menawarkan tiga jenis load balancer yang semuanya memiliki fitur high availability, auto scaling, dan robust security yang diperlukan untuk membuat aplikasi kita lebih fault tolerance (toleran terhadap kegagalan). Ketiga jenis load balancer tersebut dijelaskan pada gambar di bawah ini.

Oke, kita telah mengenal berbagai jenis ELB. Sekarang muncul suatu pertanyaan, “Apa sih keuntungan kita menggunakan AWS Elastic Load Balancing?” Alright, berikut adalah uraiannya:

• High Availability
  ELB secara otomatis mendistribusikan lalu lintas ke banyak target—Amazon EC2 instance, container, dan alamat IP—dalam satu atau beberapa Availability Zone.
  
  

• Health Checks
  Untuk menjamin availability dari Amazon EC2 instance Anda, load balancing secara berkala mengirim ping, mencoba koneksi, atau mengirim permintaan untuk mengetes instance.
  
  Tes ini disebut health check. Setiap Amazon EC2 instance terdaftar harus merespons target health check dengan kode status HTTP 200 agar terdeteksi dengan status sehat oleh load balancing Anda.
  
  

• Fitur Keamanan
  ELB yang dibuat dalam Amazon VPC juga memanfaatkan fitur keamanan jaringan VPC tersebut, seperti Security Group.
  
  

• TLS Termination
  ELB menyediakan manajemen sertifikat terintegrasi dan dekripsi SSL yang memungkinkan kita mengelola pengaturan SSL load balancing secara terpusat dan melepaskan pekerjaan intensif CPU dari aplikasi Anda.
  
  

Pola Desain Cloud: Application Load Balancer

Application Load Balancer (ALB) beroperasi pada lapisan aplikasi, layanan ini membuat keputusan perutean dan load balancing (penyeimbangan beban) pada lalu lintas aplikasi menggunakan HTTP dan HTTPS.

Beberapa fitur untuk membantu kita dalam menggunakan fitur dari ALB antara lain:

• Perutean berbasis konten
  Hal ini memungkinkan kita menentukan aturan yang merutekan lalu lintas ke target group yang berbeda berdasarkan URL path. Target group biasanya mewakili sekumpulan layanan yang akan digunakan.
  
  

• Dukungan container
  Fitur ini memberikan kemampuan untuk melakukan load balancing untuk beberapa port pada Amazon EC2 instance yang sama. Fungsionalitas ini secara khusus menargetkan implementasi container yang diintegrasikan dalam layanan Amazon ECS.
  
  

• Pemantauan aplikasi
  Fitur ini memungkinkan kita memantau dan melakukan kontrol health check per target group.

Tak afdal rasanya jika kita telah belajar mengenai ALB, tetapi tidak membahas contoh arsitektur aplikasi penggunaannya. Berikut adalah contoh penggunaan dengan fitur perutean berbasis konten: 

Pada gambar di atas kita menggunakan sebuah Application Load Balancer untuk mengatur beban tiga sub-URL dari suatu aplikasi web, misalnya www.example.com. Masing-masing sub-URL mengacu kepada sepasang EC2 instance yang tersebar ke dua Availability Zone sebagai fitur dari high availability. 

Untuk mempelajari lebih lanjut, Anda bisa melihat tautan berikut: Introducing Application Load Balancer - Unlocking and Optimizing Architectures.

High Availability (Ketersediaan Tinggi)

Saat merancang suatu arsitektur, Anda harus mempertimbangkan soal aspek yang satu ini, yaitu High Availability atau Ketersediaan Tinggi. High Availability didefinisikan sebagai, “Kemampuan di mana aplikasi kita dapat pulih dari kegagalan atau beralih ke sumber sekunder dalam jumlah waktu kinerja terdegradasi yang masih dapat diterima.”

Semakin tinggi Availability-nya, semakin andal pula aplikasi kita, tetapi tentu saja ini akan berpengaruh terhadap biaya yang harus ditanggung. Tabel berikut menunjukkan perhitungan Uptime / Ketersediaan.

Uptime (%)	Maksimal downtime per tahun	Downtime jika disetarakan per hari
90%	36,5 hari	2,4 jam
99%	3,65 hari	14 menit
99,9%	8,76 jam	86 detik
99,99%	52,6 menit	8,6 detik
99,999%	5,25 menit	0,86 detik

Mendesain Ketersediaan

Dalam mendesain Ketersediaan, kita harus mengantisipasi kegagalan, dilanjutkan kemudian dengan memperhatikan dampaknya. Sebagai contoh dapat dilihat pada gambar di bawah ini.

Gambar di atas memperlihatkan arsitektur sebuah aplikasi yang mencakup dua app server dan dua database server dengan replikasi. Ini adalah arsitektur minimum untuk memenuhi standar ketersediaan tinggi.

Availability Zones

Sebagian besar aplikasi dapat dirancang untuk mendukung dua Availability Zone. Pada umumnya aplikasi tersebut tidak memperoleh keuntungan lebih dari penggunaan lebih banyak dari dua Availability Zone, terutama ketika kita menggunakan sumber data yang hanya mendukung failover primer dan sekunder. 

Availability Zone tersebar secara fisik. Pada prinsipnya, kita tidak akan menerima manfaat lebih dengan menduplikasi sumber daya kita di tiga atau lebih Availability Zone dalam satu region.

Gambar di atas memperlihatkan contoh arsitektur yang berada di dua Availability Zone. 

Multi-Region High Availability dan DNS

Amazon Route 53 menyediakan Domain Name System (DNS) alias Sistem Penamaan Domain, pendaftaran nama domain, dan layanan health check untuk aplikasi web Anda. 

Layanan ini dirancang untuk memberi developer dan bisnis cara yang mengarahkan pelanggan Anda ke alamat aplikasi tertentu di internet dengan menerjemahkan nama seperti example.com ke alamat IP numerik (misal 202.100.100.5) yang digunakan komputer untuk terkoneksi satu sama lain. 

Kita dapat menggabungkan DNS dengan layanan health-check untuk mengarahkan lalu lintas ke endpoint yang dituju atau secara independen memantau availability dari endpoint tersebut. Kita juga dapat membeli dan mengelola nama domain seperti example.com dan secara otomatis mengonfigurasi pengaturan DNS untuk domain Anda. 

Route 53 secara efektif menghubungkan permintaan pengguna ke infrastruktur yang berjalan di AWS, seperti Amazon EC2 instance, ELB, atau Amazon S3 bucket. Bahkan, layanan ini juga dapat digunakan untuk merutekan pengguna ke infrastruktur di luar AWS.

Berikut adalah beberapa opsi untuk melakukan routing di Amazon Route 53:

• Simple round robin
  Mendistribusikan jumlah permintaan dengan merata di antara semua server yang terlibat.
  
  

• Weighted round robin
  Menggunakan mekanisme pembobotan kepada kumpulan DNS Record tertentu untuk menghasilkan pengaturan yang berbeda berdasarkan pembobotan.
  
  

• Latency-based routing (LBR)
  Membantu kita meningkatkan kinerja aplikasi untuk akses global. LBR bekerja dengan merutekan pelanggan ke endpoint AWS berdasarkan latency (misalnya Amazon EC2 instance, Elastic IP address, atau Elastic Load Balancing).
  
  Opsi ini memberikan hasil pengalaman terbaik berdasarkan pengukuran kinerja aktual dari berbagai AWS Region di mana aplikasi kita berjalan.
  
  

• Health check and DNS failover
  Memantau kesehatan dan kinerja aplikasi web, server web, dan sumber daya lainnya. Setiap health check yang kita buat dapat memantau salah satu dari berikut ini:

  • Kesehatan sumber daya tertentu, seperti server web.

  • Status dari health check lainnya.

  • Status Amazon CloudWatch alarm.

• Geolocation routing
  Memungkinkan kita memilih sumber daya yang melayani lalu lintas berdasarkan lokasi geografis pengguna (asal query DNS).
  
  

• Geoproximity routing with traffic biasing
  Memungkinkan kita mengarahkan lalu lintas berdasarkan jarak fisik antara pengguna dan sumber daya jika kita menggunakan traffic flow (arus lalu lintas) Route 53.
  
  

• Multi-value answers
  Jika ingin merutekan lalu lintas secara acak ke beberapa sumber daya, seperti server web, kita dapat membuat satu DNS record Multi-value answer untuk setiap sumber daya dan--secara opsional--mengaitkan health check Amazon Route 53 dengan setiap DNS record tersebut.

Oke, tibalah kita di penghujung modul ini, cukup panjang ya pembahasan kita kali ini. Tapi tak mengapa, tetaplah semangat karena perjalanan kita masih panjang. Let’s Go!

Ikhtisar

Ada banyak materi yang telah kita lalui di modul ini. Yuk kita uraikan:

1. Menghubungkan jaringan dengan berbagai layanan, seperti virtual private gateway, AWS Direct Connect, VPC Peering, AWS Transit Gateway, dan VPC Endpoint.
2. Kita juga telah belajar bagaimana cara mendistribusikan aplikasi dengan Elastic Load Balancing (ELB). ELB menawarkan tiga jenis load balancer, yaitu Application Load Balancer, Network Load Balancer, dan Classic Load Balancer.
3. Tak luput, kita pun membahas mengenai High Availability yang menjadi aspek penting saat membangun sebuah arsitektur di AWS. 
4. Bahkan, kita belajar mengenai DNS di Amazon Route 53 dan opsi routing, antara lain: simple round robin, weighted round robin, latency-based routing, health check and DNS failover, geolocation routing, geoproximity routing with traffic biasing, dan multi-value answer.

Pengantar ke AWS Identity and Access Management (IAM)

Startup warung kopi kita kian bertumbuh. Sekarang, kita sudah bisa mulai menambah beberapa karyawan baru agar bisnis semakin berkembang dan terkelola dengan baik. 

Wow, sepertinya baru kemarin CTO (Chief Technology Officer) kita berkeluh, “Semua tugas saya yang kerjakan.” Sekarang dia harus memikirkan bagaimana membagi pekerjaannya ke para karyawan baru tersebut. CTO harus memberikan akses layanan AWS secara terbatas kepada karyawan baru sesuai perannya masing-masing guna tetap melindungi dan mengontrol lingkungan AWS startup warung kopi.

Hal ini sangat umum terjadi di dunia startup. Di modul ini kita akan melihat bagaimana masalah tersebut dapat terpecahkan dengan bantuan AWS Identity and Access Management (IAM).

Untuk memenuhi kebutuhan arsitektur di atas, pada modul kali ini kita akan mempelajari hal-hal berikut:

• IAM Users, Groups, dan Roles.
• Federated Identity Management.
• Amazon Cognito.
• AWS Organizations.

Tak hanya itu, kita juga akan membahas situasi-situasi yang umum terjadi dalam hal pengaturan akses, misalnya:

• Beberapa pengguna memerlukan akses ke AWS Management Console, sementara yang lain hanya perlu menggunakan AWS Command Line Interface (AWS CLI).
• Lingkungan yang berbeda (Dev/Test/Production) memiliki kumpulan persyaratan akses yang berbeda.
• Autentikasi on-premise dikelola dengan federasi menggunakan SSO (Single Sign On).
• Tim operasi keamanan perlu memiliki visibilitas tentang siapa yang menyentuh data di AWS Cloud.
• Auditor eksternal membutuhkan akses ke log dan tidak perlu akses lain.
• Aplikasi seluler perlu mengautentikasi ribuan pengguna.

Biasanya, pada setiap modul akan tampil sebuah gambar arsitektur. Namun, untuk modul kali ini kita tak akan melihatnya karena tidak ada perubahan/penambahan komponen.

Sudah tak sabar ingin memulai? Mari kita meluncur ke pembahasannya!

IAM Users dan Groups

AWS Root Account

Saat pertama kali membuat akun AWS, kita memulai interaksi pada AWS platform dengan akun root user. User/pengguna ini memiliki akses lengkap ke semua layanan dan sumber daya AWS di dalam akun AWS, seperti informasi tagihan, data pribadi, bahkan seluruh arsitektur dan komponennya. Identitas ini disebut juga sebagai AWS account root user. Ia dapat diakses dengan melakukan sign in menggunakan alamat email dan password yang Anda punya saat membuat akun AWS.

Ingatlah! AWS account root user itu memiliki akses yang mutlak dan tidak dapat dibatasi. Maka dari itu, AWS sangat merekomendasikan agar kita tidak menggunakan kredensial akun root untuk interaksi sehari-hari dengan AWS. 

Akun IAM dapat dikelola dan diaudit dengan relatif mudah. Jika akun IAM (dibahas nanti) membutuhkan lebih banyak privilege/hak istimewa, mereka dapat ditambahkan sesuai kebutuhan. Begitu pula, jika privilege perlu dihapus atau dicabut, hal itu dapat dilakukan bahkan dengan dampak yang minimal terhadap lingkungan AWS kita.

Gunakanlah akun root untuk membuat user/pengguna tambahan (IAM user) dan tetapkan permission untuk pengguna tersebut dengan mengikuti prinsip hak istimewa terendah (least privilege principle). 

Jika Anda telah mengamankan kredensial akun root, Anda bisa meminta semua orang di tim Anda untuk menggunakan IAM user saat mengakses AWS.

IAM Users

Akun IAM User bukanlah akun terpisah, melainkan principal dalam akun AWS kita. Setiap IAM User dapat memiliki password-nya sendiri untuk mengakses AWS Management console. Kita juga dapat membuat access key (kunci akses) individu untuk setiap user sehingga mereka dapat membuat permintaan secara terprogram untuk bekerja dengan sumber daya di akun AWS kita. 

Karena AWS IAM dapat memberikan akses secara granular, ia bisa memungkinkan Anda untuk memiliki akses ke console tanpa memiliki akses ke CLI. Begitu juga sebaliknya, AWS IAM memungkinkan Anda untuk memiliki akses ke CLI tanpa memiliki akses ke console. Menarik, bukan?

Tahukah Anda? IAM User yang baru dibuat tidak memiliki kredensial default untuk mengautentikasi dirinya sendiri dan mengakses sumber daya AWS. Jadi, kita harus menetapkan kredensial keamanan terlebih dahulu kepada IAM User untuk autentikasi, kemudian melampirkan permission yang memberi mereka otorisasi untuk melakukan tindakan atau mengakses sumber daya apa pun di AWS. Kredensial yang kita buat untuk user adalah apa yang akan mereka gunakan untuk mengidentifikasi dirinya sendiri secara unik ke AWS.

IAM IdP

IAM IdP (Identity Provider) dapat digunakan sebagai pengganti IAM User di akun AWS Anda. Dengan IdP, kita dapat mengelola identitas pengguna kita yang berada di luar AWS (seperti Amazon.com, Google, dan Facebook) serta memberikan permission kepada identitas pengguna eksternal tersebut untuk menggunakan sumber daya AWS di akun Anda.

Gambar di atas menunjukkan bahwa dengan menggunakan AWS IdP kita bisa memakai identitas yang sudah ada, misalnya akun google, facebook, atau twitter.

IAM Groups

IAM Group adalah kumpulan IAM User. Ia memungkinkan kita menentukan permission untuk beberapa pengguna, sehingga dapat mempermudah pengelolaan permission untuk pengguna tersebut. 

Misalnya, kita dapat memiliki group yang disebut Admin dan memberi group tersebut tipe permission yang biasanya diperlukan oleh administrator. Setiap pengguna di group Admin tersebut secara otomatis akan memiliki permission yang sama seperti yang ditetapkan ke group.

Jika user baru bergabung dengan organisasi kita dan membutuhkan hak administrator, kita dapat menetapkan permission yang sesuai dengan menambahkan user baru ke grup itu. Demikian pula, jika seseorang berganti pekerjaan di organisasi Anda, daripada mengedit permission user tersebut, kita dapat menghapusnya dari grup lama dan menambahkannya ke grup baru yang sesuai.

Berikut adalah beberapa ciri penting dari IAM Group:

• Sebuah group dapat berisi banyak user; seorang user dapat menjadi bagian dari beberapa group.
• Group tidak dapat bercabang (nested); mereka hanya dapat berisi user, dan bukan berisikan group yang lain.
• Tidak ada IAM Group default yang secara otomatis menyertakan semua user. Jika ingin memiliki group seperti itu, kita perlu membuatnya secara manual dan menetapkan setiap pengguna baru ke dalamnya.
• Jumlah dan ukuran sumber daya IAM di akun AWS dibatasi.

Sebagai pembahasan kita, silakan lihat struktur IAM Group di bawah ini.

Katakanlah Anda sebagai pemilik perusahaan membuat group bernama Admins bagi beberapa user (Bob dan Susan) untuk membuat dan mengelola user lain seiring perkembangan perusahaan. Kemudian, user di group Admins tersebut membuat group Developers dan Test. 

Masing-masing group ini terdiri dari user (orang dan aplikasi) yang berinteraksi dengan AWS (Budi, Sinta, DevApp1, dan seterusnya). Setiap user memiliki sekumpulan kredensial keamanan individu. Dalam contoh ini setiap user masuk ke dalam satu group. Walaupun begitu, sebenarnya user dapat menjadi bagian dari banyak group.

Policy dan Permission

Policy

Kita dapat mengelola akses di AWS dengan membuat Policy dan melampirkannya ke identitas IAM (user, group, atau role) atau sumber daya AWS. 

Policy adalah objek di AWS yang jika dikaitkan/dipasang ke identitas atau sumber daya, ia dapat menentukan izin/permission akses. AWS mengevaluasi policy (kebijakan) ini ketika IAM Principal (User atau Role) membuat permintaan. Permission dalam Policy menentukan apakah permintaan tersebut diizinkan atau ditolak. Sebagian besar Policy disimpan di AWS sebagai dokumen JSON. 

AWS mendukung enam jenis Policy, di antaranya: 

• Identity-based policies
• Resource-based policies
• Permission boundaries
• Organizations SCPs
• ACLs
• Session policies

IAM Policy menentukan izin/permission untuk suatu tindakan, terlepas dari metode yang kita gunakan saat melakukan operasi. Misalnya, jika suatu policy mengizinkan tindakan GetUser, maka user dengan policy tersebut bisa mendapatkan informasi user dari AWS Management Console, AWS CLI, atau AWS API. 

Saat membuat IAM user, kita dapat memilih untuk mengizinkan akses terhadap console atau melakukannya secara programmatic. Jika akses console diizinkan, IAM user dapat masuk ke AWS Management Console menggunakan username dan password. Atau jika akses secara programmatic diizinkan, user dapat menggunakan access key untuk berinteraksi dengan CLI atau API.

Permission

Permission memungkinkan kita menentukan akses ke sumber daya AWS. Permission diberikan kepada entitas IAM (user, group, dan role). Secara default, entitas tersebut tak memiliki permission sejak awal. Dengan kata lain, entitas IAM tidak dapat melakukan apa pun di AWS hingga kita memberikan permission yang diinginkan kepada mereka. 

Untuk memberikan permission kepada entitas, kita dapat melampirkan Policy yang menentukan jenis akses, tindakan yang dapat dilakukan, dan sumber daya di mana tindakan dapat dilakukan. Selain itu, kita dapat menentukan kondisi apa pun yang harus disetel agar akses diizinkan atau ditolak.

Perhatikan gambar di atas, saat menentukan apakah permission diizinkan, IAM terlebih dahulu memeriksa policy terkait adanya explicit deny (penolakan secara eksplisit). Jika tidak ada, maka IAM akan memeriksa policy terhadap explicit allow (izinkan secara eksplisit). Jika tidak ada keduanya, maka IAM kembali ke default: implicit deny (penolakan secara implisit).

Menggunakan IAM User untuk Aplikasi

IAM User sebenarnya hanyalah sebuah identitas (principal) dengan izin (permission) terkait/terpasang. Karenanya, kita dapat membuat IAM User untuk mewakili aplikasi yang harus memiliki kredensial untuk membuat permintaan ke AWS.

Sebuah aplikasi mungkin memiliki identitas dan serangkaian permission-nya sendiri untuk mengakses layanan AWS. Ini mirip dengan bagaimana dalam sistem operasi modern, setiap proses memiliki identitas dan permission-nya sendiri. Jika aplikasi atau bahkan EC2 instance membutuhkan permission untuk mengakses sesuatu seperti S3 bucket, maka kita perlu menghindari untuk menyematkan kredensial dalam kode.

Federated Identity Management (Manajemen Identitas Gabungan) 

IAM Roles

IAM Roles memungkinkan kita menentukan sekumpulan izin untuk mengakses sumber daya yang dibutuhkan user atau layanan, dengan cara di mana permission tidak perlu dilampirkan ke user atau IAM Group. Permission dapat dilampirkan ke Roles, dan Roles tersebut ketika dibutuhkan akan di-assume (digunakan) oleh suatu user atau layanan.

Dengan Roles, kita tak perlu membuat banyak akun untuk setiap user. Ketika seorang user meng-assume sebuah roles, permission yang ada akan dilupakan sementara. AWS me-return (mengembalikan) kredensial keamanan sementara yang digunakan user atau aplikasi untuk membuat permintaan secara programmatic ke AWS.

Karenanya, kita tidak perlu membagikan kredensial keamanan jangka panjang (misal dengan membuat IAM User) untuk setiap entitas yang memerlukan akses ke sumber daya di akun AWS kita. Roles dapat di-assign (ditetapkan) ke akun federated user yang sign in (masuk) menggunakan identity provider eksternal, bukan IAM.

Kita membuat Roles di akun AWS yang berisi sumber daya yang membutuhkan akses. Saat membuat Roles, kita menentukan dua policy: trust (kepercayaan) dan access/permission (akses/izin).

Trust Policy menentukan siapa yang diizinkan untuk meng-assume (mengambil) role (entitas atau principal yang tepercaya). Sementara itu, Permission Policy menentukan tindakan dan sumber daya mana yang boleh digunakan oleh Identity Principal.

Ini berguna jika organisasi kita sudah memiliki sistem identitasnya sendiri, seperti direktori pengguna perusahaan. Kasus penggunaan lainnya adalah dengan mengizinkan pengguna aplikasi seluler atau aplikasi web yang memerlukan akses ke sumber daya AWS. Dengan identity provider, autentikasi dikelola secara eksternal. Ini membantu menjaga keamanan akun AWS karena kita tidak perlu mendistribusikan atau menyematkan kredensial keamanan jangka panjang di dalam aplikasi.

Identity Principal juga dapat berupa IAM User, Group, atau Role dari akun AWS lain termasuk yang tidak kita miliki. 

Untuk informasi lebih lanjut dapat dilihat di laman web Identity providers and federation. 

Penggunaan IAM Roles

IAM Role dapat di-assume (digunakan) dengan  menggunakan AWS Management Console, AWS Command Line Interface (AWS CLI), AssumeRole API, dan AWS Security Token Service (AWS STS). AWS STS adalah layanan web yang memberikan kredensial sementara dengan hak istimewa terbatas (limited privilege) untuk IAM User atau pengguna yang diautentikasi menggunakan federasi.

AssumeRole API call me-return (mengembalikan) nilai berupa sekumpulan kredensial keamanan sementara yang terdiri dari access key ID, secret access key, dan security token. Biasanya, AssumeRole digunakan untuk akses lintas akun atau federasi.

AWS STS mendukung AWS CloudTrail, yang mana akan mencatat panggilan API untuk akun AWS dan mengirimkan log file ke Amazon S3 bucket. CloudTrail mencatat semua permintaan API yang diautentikasi (dibuat dengan kredensial) ke IAM dan AWS STS API. CloudTrail juga bahkan mencatat permintaan yang tidak diautentikasi ke daftar tindakan (action) AWS STS, AssumeRoleWithSAML, dan AssumeRoleWithWebIdentity. Bahkan, CloudTrail pun mencatat informasi yang diberikan oleh identity provider.

Amazon Cognito

Amazon Cognito adalah layanan terkelola sepenuhnya yang menyediakan autentikasi, otorisasi, dan manajemen user untuk aplikasi web dan seluler. Pengguna dapat masuk langsung dengan username dan password atau melalui pihak ketiga seperti Facebook, Amazon, atau Google.

Dua komponen utama Amazon Cognito adalah User Pool dan Identity Pool.

User Pool adalah direktori user yang menyediakan opsi sign up (pendaftaran) dan sign in (masuk) untuk pengguna aplikasi Anda. Selain itu, User Pool juga memberikan beberapa fitur lain, di antaranya:

• Web UI built-in yang dapat dikustomisasi untuk sign in user.
• Social Sign-in dengan Facebook, Google, Amazon, dll.
• Manajemen direktori dan profil user.
• Fitur keamanan seperti MFA (multi-factor authentication) hingga verifikasi melalui telepon dan email.
• Workflow dan migrasi user melalui Lambda Trigger.

Sementara itu, Identity Pool memungkinkan kita untuk memberi user akses ke layanan AWS lainnya. Dengannya, user dapat memperoleh kredensial sementara untuk mengakses layanan atau sumber daya AWS melalui Amazon API Gateway. Untuk menyimpan informasi profil user, Identity Pool harus diintegrasikan dengan User Pool.

Walaupun begitu, Identity Pool dan User Pool dapat digunakan secara terpisah maupun bersama-sama.

Contoh Aplikasi AWS Cognito

Di sini kita akan melihat skenario sederhana dari penggunaan AWS Cognito. Dalam skenario ini, tujuannya adalah untuk mengautentikasi user dan memberikan akses user tersebut ke layanan AWS lain.

Pada langkah pertama, user dari aplikasi melakukan sign in melalui user pool. Setelah berhasil mengautentikasi, user akan menerima token user pool.

Selanjutnya, aplikasi akan menukar token user pool untuk kredensial AWS melalui identity pool. Terakhir, user aplikasi menggunakan kredensial AWS tersebut untuk mengakses layanan AWS lainnya.

AWS Account Organization

Dua pola arsitektur utama yang direkomendasikan oleh AWS adalah multi-VPC (dalam satu akun AWS) dan multi-akun.

Dalam sistem multi-akun, setiap akun memiliki satu VPC di dalamnya. Dalam praktiknya, organisasi (besar dan kecil) membuat banyak akun. Mereka perlu mengelola, memelihara, dan mengauditnya.

Banyak pelanggan AWS membuat beberapa akun untuk organisasi mereka, seperti akun individu untuk berbagai unit bisnis atau akun terpisah untuk sumber daya pada lingkungan development, testing, dan production.

Menggunakan akun AWS terpisah (biasanya dengan consolidated billing alias penagihan gabungan) untuk sumber daya development dan production memungkinkan kita untuk dengan rapi memisahkan berbagai jenis sumber daya dan juga memberikan beberapa manfaat keamanan.

Tabel di bawah ini menunjukkan strategi pemilihan arsitektur akun AWS. Kita dapat merancang strategi akun AWS untuk memaksimalkan keamanan dan mengikuti persyaratan bisnis dan tata kelola.

Manajemen keamanan terpusat	Satu akun AWS
Pemisahan lingkungan development, testing, dan production	Tiga akun AWS
Banyak department dengan otonomi terpisah	Banyak akun AWS
Manajemen keamanan terpusat dengan proyek terpisah yang otonom	Banyak akun AWS

Jika kita lebih suka manajemen keamanan informasi terpusat dengan biaya minimum, kita dapat memilih satu akun AWS. Alternatifnya, jika bisnis kita mempertahankan lingkungan terpisah untuk production, development, dan testing, maka kita dapat mengonfigurasi tiga akun AWS—satu untuk setiap lingkungan. Selain itu, jika kita memiliki beberapa departemen yang otonom, kita juga dapat membuat akun AWS terpisah untuk setiap bagian otonom organisasi.

Saat kita menggunakan banyak akun, strategi yang lebih efisien adalah membuat satu akun AWS untuk sumber daya yang umumnya dapat digunakan bersama-sama (seperti layanan DNS, Active Directory, dan CMS) serta akun terpisah untuk proyek/departemen yang otonom. Ini memungkinkan kita untuk menetapkan permission dan policy di bawah setiap departemen atau akun proyek dan memberikan akses ke sumber daya di seluruh akun.

Karena sebuah akun AWS sejatinya adalah entitas terpisah, bagaimana kita bisa menyatukan manajemen dan pengelolaannya? Jawabannya, kita bisa menggunakan AWS Organizations. Berikut adalah arsitektur akun yang menggunakan AWS Organizations.

AWS Organizations

AWS Organizations adalah layanan manajemen akun yang memungkinkan Anda untuk menggabungkan beberapa akun AWS ke dalam sebuah organisasi yang Anda buat dan kelola secara terpusat. 

AWS Organizations mencakup manajemen akun dan kemampuan consolidated billing (penagihan gabungan) yang memungkinkan Anda memenuhi kebutuhan anggaran, keamanan, dan compliance (kepatuhan) bisnis dengan lebih baik. Sebagai administrator, Anda dapat membuat akun di organisasi dan mengundang akun yang ada untuk bergabung dengan organisasi tersebut.

Berikut adalah beberapa kegunaan AWS Organizations, antara lain:

• Group-based account management
  Dengan menggunakan AWS Organizations, Anda dapat membuat grup untuk akun AWS. Bahkan, Anda bisa membuat grup terpisah yang dapat digunakan dengan sumber daya pada lingkungan development dan production, lalu menerapkan policy yang berbeda untuk setiap grupnya.
  
  

• Policy-based access to AWS services
  Dengan AWS Organizations, Anda dapat membuat Service Control Policies (SCP) yang secara terpusat mengontrol penggunaan layanan AWS di beberapa akun.
  
  Misalnya, Jika Anda ingin membatasi akses ke AWS Direct Connect, SCP harus mengizinkan akses sebelum IAM Policy berfungsi. Anda dapat menerapkan policy ke sekelompok akun atau semua akun di organisasi Anda.
  
  

• Automated account creation and management
  Gunakan AWS Organizations API untuk mengotomatiskan pembuatan dan pengelolaan akun AWS baru.
  
  

• Consolidated billing
  AWS Organizations memungkinkan Anda mengatur satu metode pembayaran untuk semua akun AWS di organisasi melalui consolidated billing. Dengannya, Anda juga dapat memanfaatkan keuntungan harga dari penggunaan agregat seperti diskon volume untuk Amazon EC2 dan Amazon S3.
  
  

• API-based
  Dengan AWS Organizations, Anda dapat menggunakan SCP untuk mengelola penggunaan layanan AWS di tingkat API. Misalnya, Anda bisa menerapkan policy ke grup akun untuk hanya mengizinkan IAM User di akun tersebut guna membaca data dari Amazon S3 bucket.
  
  

Berikut adalah struktur dari AWS Organizations:

Berdasarkan gambar di atas, mari kita bedah apa saja struktur dari AWS Organizations.

• Root
  Tingkat teratas di AWS Organizations. Jika kita mengaplikasikan policy di level Root, maka ini akan berdampak ke seluruh OU (Organizational Unit) atau akun AWS di organisasi.
  
  
• OU
  Tingkat di bawah Root. Saat Anda meng-attach (melampirkan) policy ke salah satu node dalam hierarki, policy tersebut mengalir ke bawah dan memengaruhi semua cabang (OU) dan daun (akun) di bawahnya. Sebuah OU hanya dapat memiliki satu parent dan setiap akun hanya bisa menjadi anggota dari satu OU.
  
  
• Policy
  Policy yang menentukan layanan dan tindakan apa yang dapat digunakan oleh user dan role di akun, dipengaruhi oleh SCP. SCP mirip dengan IAM policy, bedanya, SCP menentukan permission untuk level organisasi, OU, atau akun.
  
  Saat melampirkan SCP ke root dari organisasi atau OU Anda, SCP akan membatasi apa saja yang bisa dilakukan untuk entitas di akun anggota.

Ikhtisar

INGATLAH! Jika ada satu hal yang bisa Anda ambil dari modul ini, jangan gunakan root account di lingkungan Production. Segera buat IAM User dan delegasikan akses admin ke akun ini, kemudian jaga akses ke root account secara ketat (atau Anda juga dapat menyimpan dan sebisa mungkin untuk tidak menggunakannya). Informasi lebih jauh untuk praktik keamanan root account dan juga langkah-langkah mengamankan resource AWS di akun Anda dapat dibaca lebih lanjut di tautan ini Security best practices in IAM.

Alright. Di modul ini, kita telah mempelajari beberapa hal, antara lain:

• Identity and Access Management (IAM) di AWS akan sangat membantu kita dalam memastikan keamanan dari aplikasi dan data. 
• Kita bisa menggunakan IAM User, Group, dan Role untuk memudahkan kita mengorganisasi akses dan keamanan di dalam akun AWS.
• Untuk mengelola akses, kita bisa menggunakan Policy & Permission. Policy dibuat untuk diasosiasikan/dikaitkan dengan IAM Identity atau Resources. AWS akan mengevaluasi Policy ini saat ada permintaan dari identity principal atau resources. Sementara itu, permission akan menentukan apakah permintaan/request tersebut diperbolehkan atau dilarang.
• Selain menggunakan akun IAM User, kita dapat menggunakan Identity Provider lain misalnya dari amazon.com, google, maupun facebook sebagai pengganti IAM User.
• Kita juga telah belajar mengenai AWS Organizations dan strukturnya, seperti root, OU, dan policy.

Pengantar ke Elastisitas, Ketersediaan Tinggi, dan Pemantauan

Startup warung kopi kita mengalami pertumbuhan yang luar biasa. Karena promosi yang cerdas dan dikombinasikan dengan produk kopi terbaik, permintaan terhadap produk kita pun meningkat pesat. Bayangkan, dalam waktu beberapa bulan saja sejak startup warung kopi meluncur, kita telah memiliki puluhan ribu pengguna.  

Dengan pertumbuhan yang ekstrem tersebut, tentu saja itu berarti tuntutan terhadap infrastruktur IT kita juga semakin tinggi. Nah, di modul ini kita akan mempelajari bagaimana AWS adalah partner terbaik untuk menjawab tuntutan bisnis seperti skenario tadi.

Beberapa materi yang akan kita bahas di antaranya:

• Elastisitas
• Pemantauan
• Skalabilitas

Di akhir modul kita akan memiliki pemahaman yang lebih baik untuk mengembangkan arsitektur seperti yang ditunjukkan pada gambar di bawah ini.

Sekarang, arsitektur kita akan memiliki komponen Auto Scaling yang membuatnya elastis. Menarik bukan? Mari kita mulai.

Elastisitas

Pada data center tradisional, perusahaan harus membayar sumber daya di muka dan berharap semoga hal itu dapat memenuhi kebutuhan. Bahkan, bisa saja sumber daya yang telah dibeli terlalu banyak sehingga menimbulkan keborosan.

Umumnya data center tradisional selalu harus memikirkan masalah klasik, yaitu bagaimana memenuhi tuntutan terhadap sumber daya komputasi (memori, CPU, jaringan, penyimpanan) dengan biaya yang paling optimal.

Tahukah Anda? Rata-rata waktu pemesanan perangkat keras data center adalah antara 8 sampai 12 minggu semenjak purchase order (PO) diberikan.

Studi Kasus: Amazon.com

Tidak perlu dikatakan lagi, Amazon.com adalah salah satu pelanggan setia dan terbesar dari AWS. Sebelum hadirnya AWS, Amazon.com pun memiliki data center sendiri dan juga berhadapan dengan masalah yang sama. Coba kita pelajari gambar di bawah ini.

Amazon.com mengalami periode puncak musiman (seasonal peak) pada bulan November (Black Friday, yaitu hari belanja konsumen utama di Amerika Serikat). Perusahaan harus berinvestasi dalam sumber daya yang cukup untuk mendukung periode puncak yang terjadi setiap tahun. Seiring pertumbuhan bisnis, Amazon.com harus terus berinvestasi pada perangkat keras dan perangkat lunak tambahan. Pada suatu saat, mereka akan kehabisan tempat, jadi mereka harus menambahkan data center baru.

Saat menggunakan solusi on-premise, sekitar 76 persen sumber daya dibiarkan menganggur hampir sepanjang tahun, karena nyatanya, hanya 24 persen kapasitas sajalah yang terpakai, tentu ini menjadikan sumber daya tersebut sia-sia. Tetapi tanpa berinvestasi pada perangkat keras tambahan tersebut, perusahaan mungkin tidak akan memiliki kemampuan komputasi yang cukup untuk mendukung periode puncak di bulan tertentu. Jika terjadi kegagalan pada server, perusahaan mungkin akan kehilangan kepercayaan pelanggan.

Apakah Elastisitas itu?

Infrastruktur yang elastis dapat secara cerdas menambah dan menyusut kapasitasnya sesuai kebutuhan. Contoh dari hal ini antara lain:

• Meningkatkan jumlah server web saat traffic meningkat secara tiba-tiba.
• Menurunkan kapasitas write (tulis) di database Anda saat lalu lintas menurun.
• Menangani fluktuasi permintaan sehari-hari di seluruh arsitektur Anda.

Nah, begitu juga dengan arsitektur pada startup warung kopi. Seperti yang telah disebut di awal modul, startup kita sekarang telah memiliki puluhan ribu pengguna. Bayangkan betapa sulitnya jika kita harus menambah dan mengurangi server secara manual. 

Pertama, kita harus membuat analisis kapan lonjakan lalu lintas terjadi, kemudian bersiaga pada jam-jam tertentu, lalu menyesuaikan kapasitas sesuai beban traffic. Ahh! Itu aktivitas yang melelahkan.

Bayangkan, bagaimana jika lonjakan traffic terjadi di malam hari? Anda harus terbangun untuk menambah server! Atau, bagaimana jika lonjakan tersebut terjadi saat Anda sedang berlibur di akhir pekan? Hmm! Menjengkelkan, bukan?

Maka dari itu, elastisitas ini akan sangat membantu Anda dalam menyesuaikan kapasitas sesuai kebutuhan. Selanjutnya, mari kita lihat beberapa jenis elastisitas.

Tiga Jenis Elastisitas

AWS menawarkan tiga jenis elastisitas, yakni berbasis waktu, volume, dan perkiraan. Mari kita uraikan!

• Berbasis Waktu
  Mematikan resource saat sudah tidak dibutuhkan lagi. Contoh yang paling sering dilakukan adalah pada lingkungan Development/Testing.
  
  

• Berbasis Volume
  Menyesuaikan skala dengan intensitas permintaan Anda (memastikan Anda memiliki daya komputasi yang cukup).
  
  

• Berbasis Perkiraan
  Memprediksi kebutuhan masa depan berdasarkan tren harian dan mingguan (termasuk lonjakan yang terjadi secara teratur).

Pemantauan

Memantau lingkungan adalah salah satu hal terpenting untuk dipikirkan saat melakukan desain dan arsitektur di cloud. Anda akan selalu membutuhkan cara untuk melacak bagaimana sumber daya beroperasi dan berkinerja. Pemantauan memberi Anda petunjuk pertama untuk mengetahui apakah ada sesuatu yang perlu diubah. 

Berikut beberapa poin tentang pemantauan yang perlu Anda ingat:

• Monitoring atau pemantauan adalah langkah pertama untuk membangun arsitektur reaktif yang scalable (dapat diskalakan) saat permintaan naik dan turun. Jenis scaling ini akan sangat menghemat uang dan memberikan pengalaman yang lebih baik untuk Anda dan pelanggan Anda.

• Resource utilization (pemanfaatan sumber daya) dan application performance (kinerja aplikasi) akan menjadi komponen besar untuk memastikan infrastruktur Anda memenuhi permintaan. Anda dapat menarik informasi ini melalui pemantauan.

• Pemantauan juga sangat penting dari sudut pandang keamanan. Dengan parameter yang efektif, Anda dapat mengetahui saat pengguna mengakses bagian dari lingkungan AWS Anda yang seharusnya tidak boleh mereka akses.

AWS Cost Explorer

Untuk menciptakan arsitektur yang lebih fleksibel dan elastis, Anda harus tahu di bagian mana Anda mengeluarkan uang atas sumber daya AWS yang dibangun. AWS Cost Explorer adalah layanan pemantauan pengeluaran dari AWS yang akan sangat membantu dalam hal ini.

AWS Cost Explorer memiliki beberapa kemampuan yang dapat membantu Anda dalam memantau pengeluaran di AWS, di antaranya: 

• Monitor pengoptimalan biaya
  AWS Cost Explorer dapat menghasilkan laporan yang memberikan wawasan tentang penggunaan layanan dan biaya. Layanan ini akan memberikan perkiraan biaya yang dapat dikelompokkan berdasarkan periode, akun, sumber daya, atau tag.
  
  

• Melihat data hingga 13 bulan
  Layanan ini memungkinkan Anda untuk melihat pola pembelanjaan sumber daya AWS dari waktu ke waktu, dengan maksimal 13 bulan (12 bulan terakhir dan bulan ini).
  
  

• Forecasting dengan AWS Cost Explorer
  Forecast atau perkiraan adalah prediksi seberapa banyak Anda akan menggunakan layanan AWS selama periode waktu tertentu di masa mendatang, berdasarkan penggunaan sebelumnya. 

Forecasting akan memberikan estimasi tentang berapa tagihan AWS yang akan Anda dapat. Ia juga memungkinkan Anda untuk menggunakan alarm dan budget (anggaran) untuk nilai jumlah tertentu yang diprediksikan akan Anda gunakan. Karena forecast adalah prediksi, maka estimasi jumlah penagihan pun mungkin bisa berbeda dari nilai aktual biaya sebenarnya untuk setiap periode laporan.

Rentang akurasi yang berbeda memiliki interval prediksi yang berbeda pula. Semakin tinggi interval prediksinya, semakin besar kemungkinan forecast tersebut benar. AWS Cost Explorer forecast memiliki interval prediksi 80%. Jika AWS tidak memiliki cukup data untuk memperkirakan dalam interval prediksi 80%, maka AWS Cost Explorer tidak akan menampilkan forecast.

Amazon CloudWatch

Langkah pertama dalam perjalanan kita untuk membuat arsitektur elastis adalah dengan mempelajari Amazon CloudWatch. CloudWatch mampu memberikan tingkat visibilitas yang lebih tinggi ke dalam sumber daya dan aplikasi AWS Anda.

Amazon CloudWatch memiliki beberapa kemampuan, di antaranya:

• Anda dapat menggunakan CloudWatch untuk mengumpulkan dan melacak metrik, yaitu variabel yang dapat Anda ukur untuk sumber daya dan aplikasi.
• CloudWatch alarm (dibahas nanti) bisa mengirimkan notifikasi. 
• CloudWatch dapat secara otomatis membuat perubahan pada sumber daya yang sedang dipantau berdasarkan aturan yang Anda tentukan.

Misalnya, Anda dapat memantau penggunaan CPU dan read/write pada disk Amazon EC2 instance, lalu menggunakan data ini untuk menentukan apakah Anda harus meluncurkan instance tambahan guna menangani peningkatan traffic atau tidak. Anda juga dapat menggunakan data tersebut untuk menghentikan instance yang tak terpakai agar menghemat uang. 

Selain metrik bawaan (built-in), Anda juga dapat memantau metrik custom yang Anda buat sendiri. Intinya, dengan CloudWatch Anda bisa mendapatkan visibilitas ke seluruh sistem, seperti pemanfaatan sumber daya, kinerja aplikasi, dan kesehatan operasional.

Cara Amazon CloudWatch Merespons

Amazon CloudWatch dapat merespons setiap kejadian berdasarkan beberapa faktor, seperti metrics, logs, alarms, events, rules, dan target. Bahkan, kita juga bisa memvisualisasikan metrik dalam bentuk berbagai diagram. Mari kita bahas satu per satu.

Metrics

Amazon CloudWatch metrics--mari kita singkat menjadi metrik--adalah data tentang kinerja sistem Anda. Banyak layanan AWS yang menyediakan metrik untuk sumber daya secara default (seperti Amazon EC2 instance, Amazon EBS volume, dan Amazon RDS DB instance). 

Anda juga dapat mengaktifkan pemantauan mendetail (detailed monitoring) untuk beberapa sumber daya, seperti Amazon EC2 instance atau menerbitkan metrik aplikasi Anda sendiri. Amazon CloudWatch bisa memuat semua metrik di akun Anda (baik metrik sumber daya AWS dan metrik aplikasi yang di-publish oleh Anda) untuk pencarian, grafik, dan alarm.

Data-data metrics akan disimpan oleh Amazon CloudWatch selama 15 bulan, tanpa biaya. Data yang disimpan dalam jangka waktu lebih lama dari 15 bulan akan expire secara bertahap.

Logs

CloudWatch Logs memungkinkan Anda untuk memantau, menyimpan, dan mengakses file log dari sumber seperti EC2 instance, Amazon Route 53, AWS CloudTrail, dan layanan AWS lainnya. Misalnya, Anda dapat memantau log dari Amazon EC2 instance secara real time, lalu menyimpannya di Amazon S3. 

Bahkan, Anda dapat melacak jumlah kesalahan yang telah terjadi dalam log yang berasal dari aplikasi Anda dan mengirimkan pemberitahuan jika tingkat error tersebut melebihi jumlah yang sudah didefinisikan sebelumnya.

Tidak ada perubahan kode yang diperlukan pada aplikasi Anda untuk menggunakan Amazon CloudWatch. Selain itu, Anda dapat menggunakan CloudWatch Logs Insights untuk menganalisis log dalam hitungan detik guna memberi Anda kueri yang cepat dan visualisasi yang interaktif. Anda dapat memvisualisasikan hasil query menggunakan diagram dan menambahkan query tersebut ke CloudWatch dashboard.

Alarms

Anda dapat menggunakan CloudWatch alarm untuk secara otomatis memulai tindakan atas nama Anda. Alarm mengawasi satu metrik selama jangka waktu tertentu dan menjalankan satu atau beberapa tindakan tertentu berdasarkan nilai metrik yang relatif terhadap ambang batas (threshold) dari waktu ke waktu. Aksi yang dapat di-trigger contohnya adalah notifikasi yang dikirim ke Amazon SNS topic atau Auto Scaling policy. Anda juga bisa menambahkan alarm ke CloudWatch dashboard.

Pada contoh di atas, trigger akan memulai beberapa tindakan yang telah didefinisikan yaitu:

• Mengirim pemberitahuan (misalnya ke tim developer);
• Membuat instance lain untuk menangani traffic. 

Alarm meng-invoke (menjalankan) tindakan hanya untuk perubahan status yang dapat bertahan. CloudWatch alarm tidak meng-invoke tindakan hanya karena berada dalam status tertentu. Status tersebut harus telah berubah dan dapat dipertahankan selama beberapa periode tertentu.

Catatan: Tindakan/Action juga dapat dijalankan saat alarm tidak ter-trigger.

Events

Amazon CloudWatch event memberikan aliran sistem event (kejadian) hampir real time yang menggambarkan perubahan dalam sumber daya AWS.

Sumber daya di AWS dapat menghasilkan event ketika statusnya berubah. Misalnya, pada Amazon EC2 instance saat statusnya pending berubah menjadi running dan pada Amazon EC2 Auto Scaling saat meluncurkan instance baru atau mengakhiri (terminate) instance.

Dengan menggunakan rules (dibahas nanti) yang sederhana, Anda dapat mencocokkan event dan mengarahkannya ke satu atau beberapa target (Lambda function atau Kinesis stream).

CloudWatch Events akan menyadari atas terjadinya perubahan operasional. CloudWatch event akan menanggapi perubahan operasional tersebut dan mengambil tindakan perbaikan yang diperlukan dengan mengirim pesan untuk merespons lingkungan, mengaktifkan Lambda function, membuat perubahan, dan menangkap status informasi.

Anda juga dapat menggunakan CloudWatch Events untuk menjadwalkan tindakan otomatis yang self-trigger (memicu diri sendiri) pada waktu tertentu menggunakan cron atau rate expressions.

Rules

CloudWatch rules mencocokkan event yang masuk dan mengarahkannya ke target untuk diproses. Satu rules dapat diarahkan ke beberapa target yang semuanya diproses secara paralel. Rules tidak diproses dalam urutan tertentu, sehingga ini memungkinkan berbagai bagian yang berbeda dari sebuah organisasi untuk mencari dan memproses event yang menarik bagi mereka. 

Selain itu, rules dapat mengubah/menyesuaikan JSON yang dikirim ke target dengan hanya meneruskan bagian tertentu atau menimpanya dengan nilai konstan (constant values) yang kita definisikan.

Target

Target adalah komponen yang memproses event. Target ini dapat berupa Amazon EC2 instance, AWS Lambda function, Kinesis stream, Amazon ECS task, Step Functions state machine, Amazon SNS topic, Amazon SQS queue, dan built-in target (target bawaan). Target menerima event dalam format JSON.

Visualisasi CloudWatch

Diambil dari Getting started with Amazon CloudWatch

Amazon CloudWatch pada dasarnya adalah repositori metrik. Layanan AWS—seperti contoh Amazon EC2—menempatkan metrik ke dalam repositori, sehingga Anda dapat mengambil statistik berdasarkan metrik tersebut. Jika Anda memasukkan metrik custom ke dalam repositori, Anda juga dapat mengambil statistik pada metrik tersebut. 

Dengan CloudWatch dashboard, Anda dapat menggunakan visualisasi seperti diagram batang (bar chart), diagram garis (line chart), dan diagram area bertumpuk (stacked area chart) untuk mengidentifikasi pola dalam data log secara lebih efisien. CloudWatch Logs Insights menghasilkan visualisasi untuk query yang menggunakan fungsi statistik dan satu atau beberapa fungsi agregasi.

AWS CloudTrail

AWS CloudTrail adalah layanan web yang mencatat panggilan AWS API dan mengirimkan file log kepada Anda. Informasi yang terekam mencakup identitas pemanggil API, waktu panggilan API, alamat IP sumber dari pemanggil API, parameter permintaan, dan elemen respons yang di-return oleh layanan AWS.

Dengan CloudTrail, Anda bisa mendapatkan riwayat panggilan API AWS untuk akun Anda, termasuk panggilan API yang dilakukan melalui AWS Management Console, AWS SDK, command-line, dan layanan AWS lainnya (seperti AWS CloudFormation). Riwayat panggilan API yang dihasilkan oleh CloudTrail akan memberikan analisis keamanan, pelacakan perubahan sumber daya, dan audit compliance (kepatuhan).

CloudTrail berjalan pada basis Region. Jika Anda menggunakan lebih dari satu Region, Anda dapat memilih ke mana file log dikirimkan. Misalnya, Anda dapat memiliki Amazon S3 bucket terpisah untuk setiap region atau menyatukan file log dari semua region dalam satu Amazon S3 bucket.

VPC Flow Logs

VPC Flow Logs adalah fitur yang memungkinkan Anda untuk menangkap informasi tentang lalu lintas IP yang menuju dan dari network interface (antarmuka jaringan) di VPC Anda. Data Flow Logs disimpan menggunakan Amazon CloudWatch Logs. Sehingga setelah membuat Flow Logs, Anda dapat melihat dan mengambil datanya di Amazon CloudWatch Logs.

Berikut adalah beberapa fitur dari VPC Flow Logs:

• Menangkap detail data aliran jaringan di VPC.
• Bisa diaktifkan di tingkat VPC, subnet, atau ENI.
• Log bisa disimpan di CloudWatch atau Amazon S3.

Flow Logs dapat membantu Anda dengan sejumlah tugas (seperti memecahkan masalah mengapa lalu lintas tertentu tidak mencapai sebuah instance), yang pada akhirnya membantu Anda mendiagnosis rule dari security group yang terlalu membatasi. Anda juga dapat menggunakan Flow Logs sebagai alat keamanan untuk memantau lalu lintas yang mencapai instance Anda.

VPC Flow Logs dapat digunakan untuk beberapa hal, misalnya memecahkan masalah konektivitas, menguji aturan akses jaringan, memantau lalu lintas, serta mendeteksi dan menyelidiki insiden keamanan.

Auto Scaling (Penyesuaian Kapasitas secara Otomatis)

Masih ingatkah Anda dengan kebutuhan startup warung kopi kita dalam hal elastisitas? Yup, Anda tak ingin menambah dan mengurangi jumlah server secara manual. Apalagi jika itu dilakukan pada malam hari atau akhir pekan. 

Nah, AWS menawarkan Auto Scaling yang dapat membantu Anda dalam menyesuaikan kapasitas secara otomatis sesuai kebutuhan.

Dengan menentukan scaling policies, Auto Scaling dapat meluncurkan atau menghentikan instance saat permintaan pada aplikasi Anda meningkat atau menurun. 

Auto Scaling terintegrasi dengan ELB (Elastic Load Balancing) untuk memungkinkan Anda memasang satu atau beberapa load balancer ke Auto Scaling group yang ada. Setelah memasang Load Balancer, secara otomatis Amazon EC2 Auto Scaling akan mendaftarkan instance di Auto Scaling group, lalu ELB akan mendistribusikan lalu lintas masuk ke seluruh instance.

Saat satu Availability Zone menjadi unhealthy (tidak sehat) atau unavailable (tidak tersedia), Auto Scaling akan meluncurkan instance baru di Availability Zone yang tidak terpengaruh. Ketika Availability Zone yang unhealthy tersebut kembali ke keadaan healthy (sehat), Auto Scaling secara otomatis mendistribusikan ulang instance aplikasi secara merata di semua Availability Zone untuk Auto Scaling group Anda. 

Auto Scaling melakukan percobaan meluncurkan instance baru di Availability Zone dengan jumlah instance yang paling sedikit. Namun, jika upaya tersebut gagal, Auto Scaling akan mencoba untuk meluncurkan instance di Availability Zone lain hingga berhasil.

Cara Auto Scaling

Di AWS, AWS menawarkan beberapa cara untuk Anda melakukan Auto Scaling. Lihatlah gambar di bawah ini.

Mari kita kupas satu per satu:

• Scaling berdasarkan jadwal (scheduled) memungkinkan Anda untuk melakukan scale terhadap aplikasi sebelum perubahan beban traffic diketahui. Misalnya, lalu lintas ke aplikasi web Anda mulai meningkat setiap hari Rabu, tetap tinggi pada hari Kamis, dan mulai menurun pada hari Jumat.

• Scaling secara dinamis adalah solusi terbaik untuk penggunaan secara umum. Scaling akan dilakukan berdasarkan penggunaan CPU. Misalnya, saat penggunaan CPU mencapai 80%, maka Amazon EC2 Auto Scaling akan menambah instance baru.

• Predictive Scaling adalah opsi yang paling mudah digunakan. AWS akan melakukan scaling berdasarkan machine learning sehingga Anda tidak perlu menyesuaikan rule secara manual.

Opsi Pembelian Auto Scaling

Amazon EC2 Auto Scaling mendukung beberapa opsi pembelian dalam Auto Scaling group (ASG) yang sama. Anda dapat menyertakan Spot Instance, On-Demand, dan Reserved Instance dalam satu ASG, sehingga memungkinkan Anda untuk menghemat hingga 90% pada biaya komputasi.

Gunakanlah Amazon EC2 Fleet agar dapat menentukan kombinasi tipe instance untuk membuat kapasitas yang diinginkan dari ASG Anda. Kombinasi ini dapat didefinisikan sebagai persentase dari setiap jenis opsi pembelian. 

EC2 Auto Scaling akan mempertahankan pengoptimalan biaya yang diinginkan saat ASG melakukan scaling in atau scaling out. ASG yang terdiri dari EC2 Fleet campuran (kombinasi tipe instance) masih mendukung life cycle hook (dibahas nanti), instance health check, dan scheduled scaling yang sama seperti ASG dengan EC2 Fleet tunggal.

Di bawah ini adalah opsi yang dapat dikonfigurasi pada saat menentukan ASG menggunakan kombinasi model model pembelian dan tipe-tipe instance:

• Harga Spot Instance Maksimum : Menentukan harga maksimum Spot untuk instances di dalam ASG.

• Strategi Alokasi Spot Instance : Konfigurasikan keragaman per Availability Zone. Ini sangat membantu ketika tipe instance tertentu mendapatkan permintaan yang tinggi di salah satu Availability Zone.

• (Opsional) Basis On-Demand : Konfigurasikan kapasitas awal yang akan terdiri dari On-Demand Instance. Hal ini terlepas pada persentase On-Demand Instance yang membentuk total kapasitas.

• Persentase On-Demand di Atas Basis : Mengontrol persentase On-Demand Instance untuk ditambahkan ke grup awal.

Konfigurasi mixed-fleet (fleet campuran) dapat digabungkan dengan tipe instance yang berbeda dengan jumlah RAM dan kapasitas vCPU yang bervariasi. EC2 Auto Scaling akan secara otomatis menyediakan kombinasi harga terendah untuk memenuhi kapasitas yang diinginkan.

Sekarang, perhatikan poin-poin berikut yang merupakan hal-hal penting mengenai Auto Scaling:

• Anda mungkin perlu menggabungkan beberapa jenis Auto Scaling.
• Arsitektur Anda mungkin memerlukan lebih banyak bantuan scaling menggunakan: Step Scaling.
• Beberapa arsitektur perlu melakukan scaling dengan menggunakan dua atau lebih metrik (bukan hanya metric CPU saja).
• Cobalah untuk melakukan scale out lebih awal dan cepat, sedangkan scale in perlahan secara bertahap (gradually).
• Gunakan Life Cycle Hooks.

Life Cycle Hooks memungkinkan Anda untuk melakukan tindakan custom dengan menjeda (pause) instance saat Auto Scaling group meluncurkan atau menghentikannya. Saat sebuah instance dijeda, ia tetap dalam status menunggu hingga Anda menyelesaikan tindakan life cycle menggunakan perintah complete-lifecycle-action, operasi CompleteLifecycleAction, atau hingga periode waktu tunggu berakhir (satu jam secara default).

Sebagai contoh, misalnya instance yang baru Anda luncurkan menyelesaikan tahapan proses startup dan life cycle hook menjeda instans tersebut. Saat instance dalam status menunggu, Anda dapat menginstal atau mengonfigurasi perangkat lunak di dalamnya, memastikan bahwa instance Anda sepenuhnya siap sebelum mulai menerima traffic.

INGAT! EC2 instance mungkin memerlukan waktu beberapa menit sampai benar-benar beroperasi.

Scaling Database (Penyesuaian Kapasitas pada Database)

Scaling pada database tentu berbeda dengan EC2 instance. Database tidak bisa di-scaling dengan menempatkan Load Balancer di depannya. Oleh karena itu, pada pembahasan kali ini kita akan belajar bagaimana melakukan scaling pada database. Berikut adalah metode-metode yang bisa kita lakukan untuk men-scaling database di AWS:

Horizontal Scaling 

Anda bisa meningkatkan kinerja database yang besar di sisi read (baca) data dengan menggunakan read replica untuk horizontal scaling pada database Anda. Amazon RDS MySQL, PostgreSQL, dan MariaDB dapat memiliki hingga 5 read replica, sedangkan Amazon Aurora dapat memiliki hingga 15 read replica.

Read Replica memungkinkan Anda membuat salinan read-only yang disinkronkan dengan database master. Anda juga dapat menempatkan read replica di AWS Regions yang berbeda sehingga membuatnya lebih dekat dengan pengguna Anda demi kinerja yang lebih baik. 

Sebagai tambahan, Anda dapat menggunakan read replica untuk meningkatkan availability (ketersediaan) database dengan mem-promote (mempromosikan) read replica ke master guna pemulihan yang lebih cepat jika terjadi bencana (disaster recovery). Namun, read replica bukanlah solusi pengganti untuk high availability dan kemampuan automatic failover karena hal itu sudah disediakan oleh fitur Amazon RDS Multi-AZ Deployments.

Push Button Scaling

Dengan menggunakan Amazon RDS API atau beberapa klik pada console, Anda dapat melakukan scaling up atau scaling down terhadap sumber daya komputasi dan memori yang mendasari proses deployment Anda. Operasi scaling biasanya selesai dalam beberapa menit. 

Catatan: * RDS normalnya memerlukan waktu henti (downtime) singkat 1-2 menit saat di-scale, tetapi Aurora Serverless dapat melakukan scaling tanpa downtime.

Seiring bertambahnya kebutuhan, Anda dapat menyediakan penyimpanan tambahan dengan cepat tanpa downtime. Jika Anda menggunakan RDS Provisioned IOPS (dengan pengecualian Amazon RDS for SQL Server), Anda juga dapat melakukan scaling terhadap throughput DB instance dengan menentukan tarif IOPS dari 1.000 IOPS hingga 80.000 IOPS (dalam kelipatan 1.000 IOPS) dan penyimpanan dari 100 GB menjadi 64 TB.

Storage alias penyimpanan dapat ditingkatkan tanpa downtime. Namun, mengubah tipe instance akan membutuhkan downtime.

Aurora DB Cluster

Amazon Aurora DB Cluster terdiri dari satu atau lebih DB instance dan cluster volume--yang mengelola data untuk DB instance tersebut. Aurora cluster volume adalah volume penyimpanan database virtual yang mencakup beberapa Availability Zone, dengan setiap Availability Zone-nya memiliki salinan data dari DB cluster. Dua jenis DB instance yang membentuk Aurora DB cluster antara lain:

• Primary DB Instance
  Mendukung operasi read/write dan melakukan semua modifikasi data ke cluster volume. Setiap Aurora DB cluster memiliki satu DB instance utama.
  
  

• Aurora Replica
  Menghubungkan ke volume penyimpanan yang sama dengan DB instance utama dan hanya mendukung operasi read. Setiap Aurora DB cluster dapat memiliki hingga 15 Aurora Replica selain DB instance utama.
  
  Pertahankan high availability dengan menempatkan Aurora Replica di Availability Zone yang terpisah. Aurora secara otomatis akan failover (beralih) ke Aurora Replica jika terjadi kegagalan di DB instance utama.
  
  Anda dapat menentukan prioritas failover untuk Aurora Replica. Saat instance utama gagal, Amazon RDS akan mempromosikan instance replica dengan prioritas tertinggi menjadi instance utama.
  
  Jika dua atau lebih Aurora Replica berbagi prioritas yang sama, maka Amazon RDS mempromosikan replica dengan ukuran (size) terbesar. Namun jika dua atau lebih Aurora Replica berbagi prioritas dan size yang sama, maka Amazon RDS mempromosikan replica secara acak di tingkat promosi yang sama.
  
  Aurora Replica juga dapat offload (melepaskan) beban kerja read dari DB instance utama.
   

Aurora Serverless

Amazon Aurora Serverless adalah konfigurasi Auto Scaling sesuai permintaan untuk Amazon Aurora sebagai database relasional. Aurora Serverless DB cluster adalah DB cluster yang secara otomatis memulai, mematikan, dan meningkatkan atau menurunkan kapasitas berdasarkan kebutuhan aplikasi Anda tanpa perlu mengelola infrastruktur server database.

Aurora Serverless menyediakan opsi yang relatif sederhana dan hemat biaya untuk beban kerja yang jarang, terputus-putus, atau tidak dapat diprediksi. Aurora Serverless dapat membantu Anda dalam hal tersebut karena ia secara otomatis memulai instance, melakukan scaling terhadap kapasitas agar sesuai dengan penggunaan aplikasi, dan menghentikan instance saat tidak digunakan. Saat mengonfigurasi Aurora Serverless, Anda menentukan maksimum dan minimum Aurora Capacity Unit (ACU) dan membayar jumlah ACU tersebut sesuai yang Anda gunakan.

Database Sharding

Sharding adalah teknik untuk meningkatkan kinerja writing (penulisan) dengan beberapa server database. Database dengan struktur identik disiapkan dan dibagi menggunakan kolom tabel yang sesuai sebagai kunci untuk mendistribusikan proses writing. Penggunaan layanan RDBMS yang disediakan di AWS Cloud memungkinkan Anda melakukan sharding ini untuk mencapai peningkatan ketersediaan dan operasi yang lebih efektif.

Anda dapat menggunakan Amazon RDS dalam membagi database backend. Cukup instal perangkat lunak sharding seperti server MySQL yang digabungkan dengan Spider Storage Engine pada Amazon EC2 instance, siapkan beberapa RDS, dan gunakan sebagai database backend sharding. Yang lebih menariknya, Anda dapat mendistribusikan RDS ke beberapa region.

DynamoDB

Saat Anda membuat tabel baru di layanan DynamoDB dengan menggunakan console, tabel tersebut akan mengaktifkan Auto Scaling secara default. DynamoDB Auto Scaling secara otomatis menyesuaikan kapasitas throughput read (baca) dan write (tulis) sebagai respons terhadap volume permintaan yang berubah secara dinamis dengan downtime (waktu henti) nol. 

Dengan DynamoDB Auto Scaling, Anda cukup menetapkan target penggunaan throughput yang diinginkan, batas minimum dan maksimum, dan Auto Scaling akan menangani sisanya.

DynamoDB Auto Scaling bekerja dengan Amazon CloudWatch untuk terus memantau konsumsi throughput yang aktual dan melakukan scaling up dan scaling down terhadap kapasitas secara otomatis ketika penggunaan aktual menyimpang dari target Anda.

Auto Scaling dapat diaktifkan untuk tabel baru (new table), yang sudah ada (existing table), dan indeks sekunder global. Tidak ada biaya tambahan untuk menggunakan DynamoDB Auto Scaling, selain yang sudah Anda bayar untuk DynamoDB dan CloudWatch alarm. DynamoDB Auto Scaling tersedia di semua AWS Region.

Amazon DynamoDB On-Demand adalah opsi penagihan fleksibel untuk DynamoDB yang mampu melayani ribuan permintaan per detik tanpa harus melakukan perencanaan kapasitas. Ini menggunakan model harga pay-per-request (bayar per permintaan), bukan provisioned-price model (jenis pembayaran berdasarkan sumber daya yang ditetapkan sebelumnya). 

DynamoDB On-Demand dapat mengamati setiap peningkatan atau scale (skala) tingkat lalu lintas. Jika tingkat lalu lintas mencapai puncak baru, DynamoDB akan beradaptasi dengan cepat untuk mengakomodasi beban kerja. Ini berguna jika beban kerja Anda sulit diprediksi atau mengalami lonjakan besar dalam durasi yang singkat. 

Anda dapat mengubah tabel dari kapasitas yang disediakan (provisioned) menjadi sesuai permintaan (on-demand) satu kali sehari. Sementara itu, Anda dapat beralih dari kapasitas on-demand ke provisioned sesering yang Anda inginkan.

Cara Kerja DynamoDB Auto Scaling

Setelah kita mengetahui penjelasan tentang DynamoDB Auto Scaling, mari kita telaah bagaimana cara kerjanya. Simaklah gambar berikut yang menunjukkan cara kerja dari DynamoDB Auto Scaling:

Dari gambar di atas, mari kita jabarkan cara kerjanya:

1. Buat Application Auto Scaling policy untuk tabel DynamoDB Anda.
2. DynamoDB publish (menerbitkan) metrik kapasitas yang dikonsumsi ke Amazon CloudWatch.
3. Jika kapasitas tabel yang dikonsumsi melebihi penggunaan target Anda (atau berada di bawah target) untuk jangka waktu tertentu, Amazon CloudWatch akan men-trigger (memicu) alarm. Anda dapat melihat alarm di console dan menerima notifikasi menggunakan Amazon SNS.
4. CloudWatch alarm memanggil Application Auto Scaling untuk mengevaluasi scaling policy Anda.
5. Application Auto Scaling mengeluarkan permintaan UpdateTable untuk menyesuaikan throughput yang disediakan tabel Anda.
6. DynamoDB memproses permintaan UpdateTable, kemudian ia secara dinamis meningkatkan (atau menurunkan) kapasitas throughput yang disediakan tabel sehingga mendekati penggunaan target Anda.

Warning Ikuti modul latihan ini sesuai dengan langkah-langkah yang kami berikan. Jika Anda telah menyelesaikan latihan ini, harap mengikuti tahapan Clean Up yang ada di akhir latihan untuk mengetahui bagaimana cara menghapus resource yang telah dibuat.

Hands-on Lab: Membangun Arsitektur yang Highly Available (Sangat Tersedia)

Masih ingatkah Anda dengan latihan sebelumnya? Kita telah berhasil melakukan VPC Peering sehingga startup warung kopi Anda bisa membagi lingkungan antara Development dan Testing.

Sekarang, pelanggan warung kopi Anda semakin bertambah dan semakin banyak pula yang melakukan transaksi pada website penjualan kopi online Anda. Ini membuat server kewalahan. Tahukah Anda apa solusinya untuk persoalan ini? Yup! Menambah server!

Namun masalahnya, Anda tak mengetahui kapan lonjakan lalu lintas terjadi. Terkadang, itu terjadi di pagi hari saat orang-orang berangkat kerja, sesekali juga melonjak pada malam hari saat menjelang libur.

Jika kasusnya seperti itu, tentu akan sulit untuk menambahkan server secara manual. Alhasil, kita harus menebak-nebak kapan lonjakan traffic terjadi. Maka dari itu, pada latihan kali ini kita akan belajar bagaimana cara membuat lingkungan yang elastis sekaligus highly available. Sehingga jika terjadi gangguan pada salah satu server Anda, website penjualan kopi pun tetap tersedia dan berjalan normal.

Berikut adalah gambar arsitektur yang akan kita buat pada latihan ini:

Kita akan menggunakan beberapa layanan yang telah dipelajari sebelumnya, yakni Amazon EC2, VPC, ELB, dan Auto Scaling. Untuk membuat server menjadi elastis dan highly available, kita akan menggunakan Auto Scaling dan menempatkannya di 2 Availability Zone, yang mana Auto Scaling tersebut terhubung dengan ELB. Berikut adalah tahapannya:

1. Membuat Load Balancer.
2. Meluncurkan Auto Scaling.
3. Melakukan Pengujian. 

Pastikan Anda mengikuti setiap tahapan dengan saksama ya agar semakin memahami teori yang telah kita pelajari. Penasaran seperti apa? Yuk kita mulai.

Hands-on Lab: Membangun Arsitektur yang Highly Available (Sangat Tersedia) - Membuat Load Balancer

Pada bagian pertama, kita akan membuat load balancer yang berfungsi untuk mendistribusikan lalu lintas masuk ke Auto Scaling instance (akan kita buat nanti). Silakan ikuti langkah-langkah berikut:

1. Masuklah ke Amazon EC2 console dengan ketikkan ec2 di kotak pencarian, lalu klik EC2.
   
   
   

2. Scroll pada navigasi sebelah kiri, masuk ke menu Load Balancers, kemudian klik tombol Create Load Balancer.
   
   
   

3. Tentu Anda sudah belajar bahwa Elastic Load Balancing memiliki 3 tipe load balancer, yakni Application Load Balancer, Network Load Balancer, dan Classic Load Balancer. Untuk latihan kali ini, kita akan menggunakan Application Load Balancer. Silakan klik tombol Create di bagian Application Load Balancer.
   
   
   

4. Isilah nama load balancer Anda menjadi dicoding-lb. Biarkan konfigurasi yang lain sesuai default pada bagian ini.
   
   
   

5. Scroll ke bawah pada halaman tersebut hingga Anda menemukan bagian Availability Zones. Kita akan menggunakan VPC default agar mempermudah proses latihan kali ini. Pilihlah VPC default, lalu klik 2 availability zone (ap-southeast-1a dan ap-southeast-1b).
   
   
   

6. Tambahkan Tag dengan konfigurasi berikut:

   Key	Name
   Value	Dicoding Load Balancer

   Jika sudah, lanjutkan dengan klik tombol Next: Configure Security Settings.
   
   
   

7. Kita tak perlu mengubah apa pun di halaman ini. Jadi, silakan klik tombol Next: Configure Security Groups.
   
   
   

8. Pilih Create a new security group. Kemudian isikan sesuai konfigurasi berikut:

   Security group name	Load-Balancer-SG
   Description	Load Balancer Security Group

   Biarkan nilai-nilai lain sesuai default, lalu klik tombol Next: Configure Routing.
   
   
   

9. Di halaman ini kita akan membuat target group untuk load balancer. Isikan nama target group Anda dengan dicoding-target-group.
   
   
   

10. Scroll ke halaman paling bawah dan klik tombol Next: Register Targets.
    
    
    

11. Sekarang masuk ke halaman Register Targets. Di sini kita dapat mendaftarkan target (instance) untuk masuk ke dalam target group. Namun karena sampai tahap ini kita belum meluncurkan instance, jadi kita lewati saja proses ini. Kita akan melakukan registrasi target nanti dengan menggunakan Auto Scaling. Yuk lanjutkan dengan klik Next: Review.
    
    
    

12. Review-lah konfigurasi Anda, lalu klik tombol Create.
    
    
    

13. Kemudian tunggu hingga proses pembuatan load balancer selesai, lalu klik Close.
    
    
    

Congrats! Anda telah berhasil membuat load balancer. Mari kita lanjutkan ke tahap meluncurkan Auto Scaling.

Hands-on Lab: Membangun Arsitektur yang High Available (Sangat Tersedia) - Meluncurkan Auto Scaling

Pada bagian kedua ini kita akan meluncurkan Auto Scaling di 2 Availability Zone serta menghubungkannya dengan load balancer yang telah dibuat. Tapi sebelum itu, mari kita buat security group untuk server terlebih dahulu.

1. Pada halaman Amazon EC2 console, di bagian bawah Network & Security, masuklah ke halaman Security Groups, kemudian klik Create security group.
   
   
   

2. Di bagian ini, isikan sesuai konfigurasi berikut:

   Security group name	dicoding-security-group-server
   Description	Allow SSH dan HTTP
   VPC	default

   
   
   

3. Untuk Inbound rules, kita akan membuat 2 rule. Klik Add rule dan sesuaikan dengan konfigurasi berikut ini:

   HTTP
   Type	HTTP
   Source	Anywhere
   SSH
   Type	SSH
   Source	Anywhere

   Jika Anda merasa kesulitan, silakan lihat gambar di bawah ini.
   
   
   

4. Tambah tag dengan Key (Name) dan Value (Allow SSH dan HTTP). Jika sudah, lanjutkan dengan klik Create security group.
   
   
   

5. Oke, security group telah terbuat. Sekarang, yuk kita buat Auto Scaling. Dalam keadaan masih di halaman Amazon EC2 console, scroll navigasi di sisi kiri hingga ke paling bawah, masuklah ke menu Auto Scaling Groups, dan klik tombol Create Auto Scaling group.
   
   
   

6. Isi Auto Scaling group name dengan dicoding-auto-scaling-group. Saat membuat Auto Scaling, kita harus memilih launch template terlebih dahulu untuk meluncurkan instance nantinya. Nah, karena kita belum membuatnya, silakan klik Create a launch template. Ini akan membuka tab browser yang baru.
   
   Catatan: Jangan dulu tutup tab browser sebelumnya, nanti kita akan kembali ke halaman tersebut.
   
   

7. Pada bagian Launch template name and description, isilah dengan konfigurasi berikut:

   Launch template name	dicoding-launch-template
   Template version description	Launch Template untuk App Server

   
   
   

8. Lanjut, pilihlah Amazon Linux 2 AMI untuk bagian Amazon machine image (AMI) dan t2.micro pada Instance type.
   
   
   

9. Selanjutnya, buatlah key pair baru dengan klik Create new key pair.
   
   
   

10. Isikan Key pair name dengan dicoding-server, biarkan File format pada pilihan .pem, lalu klik tombol Create key pair. Kemudian simpanlah file tersebut di lokasi penyimpanan yang mudah diingat, seperti di folder Downloads.
    
    
    

11. Selanjutnya adalah konfigurasi pada bagian Network settings. Biarkan pilihan Networking platform sesuai default, yakni Virtual Private Cloud (VPC). Selepas itu, pilihlah security group yang telah Anda buat sebelumnya pada step 1, yaitu dicoding-security-group-server.
    
    
    

12. Lanjut, scroll ke halaman paling bawah dan silakan klik tanda panah pada Advanced details. Lalu, scroll lagi hingga Anda menemukan bagian User data. Pada box, isikan perintah berikut:

    #! /bin/bash
    yum install httpd -y
    systemctl start httpd
    systemctl enable httpd

13. Klik tombol Create launch template.
    
     

14. Oke, kita telah berhasil membuat launch template. Silakan kembali ke tab browser Auto Scaling Anda. Klik tombol refresh, lalu pilih dicoding-launch-template. Scroll ke paling bawah dan klik tombol Next untuk melanjutkan proses berikutnya.
    
     

15. Pada bagian Step 2 Configure settings, scroll ke bagian Network, dan untuk mempermudah latihan kali ini pilihlah VPC default. Kemudian, lanjut ke bagian Subnets. Karena kita ingin membuat instance pada Auto Scaling berada di 2 Availability Zone, maka pilihlah 2 subnet (ap-southeast-1a dan ap-southeast-1b). Usai itu, klik tombol Next.
    
     

16. Langkah selanjutnya, kita akan memasang load balancer pada Auto Scaling. Klik Attach to an existing load balancer, lalu pada bagian Application or Network Load Balancer target groups pilih target group yang telah kita buat sebelumnya, yakni dicoding-target-group. Lanjut ke tahap selanjutnya, scroll ke halaman paling bawah dan klik tombol Next.
    
    
    

17. Ubahlah nilai Desired capacity, Minimum capacity, dan Maximum capacity dengan nilai 2. Nanti, kita akan mengubah nilai tersebut saat proses pengujian. Mari kita masuk ke tahap berikutnya dengan scroll ke halaman paling bawah dan klik tombol Next.
    
     

18. Di tahap ini, kita tak akan menambahkan notifikasi apa pun. Jadi, silakan klik tombol Next.
    
     

19. Tambahkan tag dengan Key (Name) dan Value (AutoScaling EC2), kemudian klik tombol Next.
    
    
    

20. Selanjutnya, silakan review konfigurasi Anda, kemudian klik Create Auto Scaling group.
    
    
    

Hooray! Kita telah berhasil meluncurkan Auto Scaling. Langkah selanjutnya sekaligus terakhir adalah melakukan pengujian. Yuk lanjut ke bagian ketiga!

Hands-on Lab: Membangun Arsitektur yang High Available (Sangat Tersedia) - Pengujian

Di bagian ketiga ini, kita akan melakukan pengujian, baik untuk kasus Load Balancer maupun Auto Scaling. Pertama, mari kita uji Load Balancer terlebih dahulu.

1. Masih di Amazon EC2 console, masuklah ke menu Load Balancers, pilih dicoding-lb, lalu salin DNS name-nya.
   
    

2. Kemudian, paste DNS name tersebut ke browser Anda dan lihatlah apa yang terjadi. Ta-da! Muncul suatu halaman tes alias Test Page. Namun, ini tidak memperlihatkan persis bagaimana load balancer yang telah kita buat mendistribusikan lalu lintasnya. Jadi, mari lanjut ke langkah berikutnya.
   
   Catatan: Jika tidak muncul halaman Test Page, tunggulah beberapa saat, lalu lakukan refresh kembali. Ingat! Tunggu proses pembuatan EC2 instance hingga berstatus running. Jika tidak, maka alamat DNS name untuk load balancer akan menunjukkan Error 503.

3. Lakukan SSH atau EC2 Instance Connect terhadap instance pertama pada Auto Scaling Anda (lihat menu Instances di Amazon EC2 console). Jika sudah masuk ke instance tersebut, silakan pindah ke folder /var/www/html/ dengan sintaks:

   cd /var/www/html/

4. Buatlah suatu file html sederhana bernama index.html.

   sudo nano index.html

5. Di dalam file tersebut, tuliskan seperti berikut:

   <h1>Ini adalah instance 1</h1>

   Jika sudah, simpan dengan cara menekan CTRL+X -> Y -> Enter.

6. Oke, semua yang perlu dilakukan pada instance pertama ini sudah selesai. Silakan keluar dengan menuliskan perintah:

   exit

7. Selanjutnya, silakan lakukan hal yang sama (step 3-6) pada instance kedua Anda.

   1. Lakukan SSH terhadap instance kedua.

   2. Instal, nyalakan, dan aktifkan httpd.

   3. Buat file index.html di folder /var/www/html/ dengan isi Ini adalah instance 2.

   4. Keluar dari instance kedua tersebut.

8. Alright. Tugas kita sudah selesai untuk proses konfigurasi instance. Mari kita uji! Masih di halaman Amazon EC2 console, masuklah ke menu Load Balancers -> dicoding-lb. Salin DNS name dari load balancer Anda, kemudian bukalah tab browser baru, lalu paste di tab browser yang baru tersebut, dan lihatlah apa yang terjadi.
   
   
   

9. Voila! Anda akan melihat tulisan “Ini adalah instance 1”, lakukan refresh berulang kali, dan akan muncul “Ini adalah instance 2”. Bisa jadi sebaliknya, Anda akan melihat tulisan “Ini adalah instance 2”, lakukan refresh berulang kali di browser Anda, dan akan muncul “Ini adalah instance 1”.
   
   
   Catatan: Jika tulisan di atas tidak muncul dan malah timbul eror. Tunggulah beberapa menit, lalu lakukan refresh kembali. Hal itu terjadi karena load balancer akan melakukan health check terlebih dahulu.
   
   

10. Yeay! Dengan munculnya tulisan seperti di atas, itu menandakan load balancer kita bekerja dengan baik dan mendistribusikan traffic ke kedua instance yang kita miliki. Jika Anda ingin memeriksa status dari health check yang dilakukan oleh load balancer, silakan masuk ke menu Target Groups, lalu klik nama dicoding-target-group.
    
    
    

11. Bukalah tab Targets dan lihat kolom Status. Kedua instance kita berstatus healthy yang berarti load balancer dapat mengirim permintaan ke kedua instance tersebut dengan baik.
    
     

12. Langkah selanjutnya, mari lakukan pengujian terhadap kasus Auto Scaling, yakni dengan mengakhiri salah satu instance. Masuklah ke menu Instances, pilih salah satu instance Anda, klik tombol Instance state, dan klik Terminate Instance untuk mengakhiri instance tersebut.
    
    
    

13. Pastikan kolom Instance state berstatus Terminated. Tunggulah beberapa saat, lakukan refresh secara berkala, dan Anda akan melihat satu instance tambahan muncul.
    
    
    

Yuhuu! Latihan kali ini berjalan dengan sukses. Load balancer kita telah berjalan dengan baik dan Auto Scaling pun melakukan tugasnya dengan sempurna. Selamat untuk itu! Level Unlocked! 

Masih ada beberapa modul yang harus Anda selesaikan di kelas ini. Jadi, keep it up!

Clean Up Hapuslah segala sumber daya yang telah Anda buat, seperti EC2 instance, load balancer, auto scaling group, dan lain-lain guna menghindari adanya tagihan.

Ikhtisar 

Di modul ini kita telah belajar banyak hal mengenai elastisitas, ketersediaan tinggi, dan pemantauan. Mari kita jabarkan:

1. Kita belajar mengenai apakah elastisitas itu dan mengapa elastisitas penting bahkan merupakan kunci dari cara cloud bekerja. 

2. Kita juga telah memahami bahwa untuk memperoleh elastisitas, kita membutuhkan solusi pemantauan yang mumpuni.

3. Kita pun sudah membahas empat jenis solusi pemantauan di AWS yaitu, AWS Cost Explorer, Amazon CloudWatch, AWS CloudTrail, dan VPC Flow Logs.

4. Terakhir, di modul ini kita juga belajar bahwa scaling database berbeda dari scaling server lain, misalnya web server. 

Oke, itulah pembahasan kita kali ini mengenai elastisitas, ketersediaan tinggi, dan pemantauan. Selanjutnya, Anda akan belajar ke level tinggi. Maka dari itu, tetap semangat ya!

Pengantar ke Automasi

Di modul sebelumnya kita sudah mempelajari bagaimana Elastisitas, Ketersediaan Tinggi, dan Pemantauan membantu kita untuk melakukan scaling terhadap Startup Warung Kopi dalam menangani lonjakan pengguna hingga menembus angka puluhan bahkan mungkin ratusan ribu. Mantap!

Tetapi jangan lupa, sampai saat ini, proses membuat arsitektur, men-deploy aplikasi, dan pembaruan perangkat lunak masih dilakukan secara manual. Hal ini akan sangat menghambat Startup kita untuk mampu menangani lonjakan user seperti itu.

Di modul ini kita akan melengkapi arsitektur Startup Warung Kopi dengan automasi. Sehingga, saat melakukan update ataupun deploy di cloud, Anda akan terbebas dari proses manual. 

Dengan menghilangkan proses manual, arsitektur IT kita akan benar-benar mampu beradaptasi terhadap tuntutan bisnis, baik itu lonjakan user (naik maupun turun), peluncuran produk, atau mencoba fitur baru yang bisa mendukung pertumbuhan bisnis Startup kita. 

Untuk menjawab kebutuhan arsitektur di atas, kita akan mempelajari hal-hal berikut ini:

• Mengapa melakukan automasi?
• Automasi infrastruktur
• Automasi deployment

Oke, mari kita lihat penjelasan lebih detail di materi berikutnya!

Alasan Melakukan Automasi

Pada materi-materi sebelumnya, kita telah belajar untuk membangun arsitektur di AWS secara manual, seperti membuat VPC, EC2 instance, RDS instance, dll. Semua komponen tersebut harus Anda buat satu per satu di masing-masing dashboard console layanannya. Nah, tahukah Anda? Kita bisa membuat automasi proses deploy arsitektur sehingga akan menghemat waktu.

Gambar di bawah ini menunjukkan proses manual dan panjang yang harus Anda lakukan saat membangun arsitektur di cloud. 

Dapat Anda lihat pada gambar di atas bahwa dibutuhkan waktu dan proses yang besar untuk membangun lingkungan komputasi berskala besar. Berikut beberapa pertanyaan yang perlu Anda pertimbangkan:

• Mana yang ingin Anda terapkan, implementasi otomatis atau manual? 
• Apa saja risiko dari implementasi manual?
• Bagaimana Anda memperbarui server yang berjalan di lingkungan production? Bagaimana Anda akan meluncurkan deployment di beberapa region geografis? Ketika terjadi kegagalan, bagaimana Anda melakukan rollback/restore?
• Bagaimana dengan penerapan debugging? Bagaimana Anda menemukan apa yang salah dan kemudian memperbaikinya?
• Bagaimana Anda akan mengelola dependensi pada berbagai sistem dan subsistem di organisasi Anda?
• Terakhir, dapatkah Anda melakukan semua ini dengan manual?

INGAT! Jika Anda harus mengubah sesuatu di lingkungan production secara manual, itu berarti Anda menempatkan diri pada risiko. Berikut adalah beberapa risiko jika Anda melakukan perubahan secara manual.

Mari kita jabarkan poin-poinnya:

• Dengan membuat dan menambahkan fitur aplikasi secara manual ke lingkungan Anda, lingkungan cloud Anda tidak akan bisa di-scale (diskalakan). Jika Anda bertanggung jawab atas aplikasi enterprise yang besar, maka takkan ada cukup orang untuk menjalankan proses secara manual.
• Dengan melakukan proses manual, maka tidak ada version control. Sehingga, akan sulit untuk mengembalikan lingkungan production ke versi sebelumnya.
• Memiliki jejak audit tentu sangatlah penting untuk menghadapi situasi compliance dan keamanan. Sangatlah berbahaya jika Anda membiarkan orang mengontrol dan mengedit lingkungan Anda secara manual.
• Terakhir, sulit menerapkan konsistensi. Tahukah Anda? Konsistensi merupakan hal yang sangat penting untuk meminimalkan risiko. Nah, dengan automasi, Anda dapat menjaga konsistensi di lingkungan AWS.

Automasi Infrastruktur

Saat membangun arsitektur di AWS, tentu akan jauh lebih baik jika Anda melakukan automasi guna menghindari risiko human error, memudahkan Anda dalam mengimplementasikan desain arsitektur, dan menghemat waktu. Dalam hal ini termasuk juga untuk mengotomatiskan proses pembuatan infrastruktur.

Nah, untuk mengetahui bagaimana cara membuat infrastruktur secara otomatis, yuk kita lihat di pembahasan berikutnya!

AWS CloudFormation

AWS CloudFormation menyediakan resource dengan cara yang aman dan dapat diulang (repeatable). Ini memungkinkan Anda untuk build (membangun) dan rebuild (membangun kembali) infrastruktur dan aplikasi Anda tanpa harus melakukan tindakan secara manual.

AWS CloudFormation memungkinkan Anda untuk memperlakukan infrastruktur sebagai kode (infrastructure as code). Anda bisa membuatnya dengan code editor apa pun, upload ke dalam version control system seperti GitHub atau AWS CodeCommit, dan memeriksa file dengan anggota tim sebelum men-deploy-nya ke lingkungan yang sesuai.

Dengan AWS CloudFormation, Anda dapat membuat template berformat YAML untuk mendeskripsikan resource dan properti AWS di AWS CloudFormation. Tak hanya YAML, Anda juga memiliki opsi untuk menggunakan template berformat JSON untuk membuat model dan mendeskripsikan infrastruktur AWS Anda. 

Template AWS CloudFormation berformat YAML mengikuti anatomi yang sama seperti template berformat JSON yang ada dan mendukung semua fitur yang sama.

Selain penjelasan di atas, berikut adalah beberapa poin tambahan untuk template AWS CloudFormation:

• Perlakukan sebagai kode dan kelola menggunakan version control pilihan Anda (misal, Git atau SVN).
• Tentukan seluruh stack aplikasi (semua resource yang diperlukan untuk aplikasi Anda) dalam file template JSON atau YAML.
• Tentukan parameter runtime untuk template (ukuran Amazon EC2 instance, Amazon EC2 key pair, dll).

Saat menggunakan AWS CloudFormation, Anda juga dapat membuat cross stack reference (referensi lintas stack) yang memungkinkan berbagi output atau keluaran dari satu CloudFormation stack dengan stack lainnya. Cross stack reference berguna untuk pelanggan yang memisahkan infrastruktur AWS mereka menjadi komponen logis yang dikelompokkan berdasarkan stack (misal stack jaringan, stack aplikasi, dll). Selain itu, cross stack reference berguna bagi yang membutuhkan cara untuk menerapkan loosely coupled (keterkaitan yang longgar) terhadap stack secara bersamaan sebagai alternatif dari nested stack (stack bersarang) dalam satu template besar.

Infrastructure as Code (IaC)

AWS CloudFormation memungkinkan pembuatan sekumpulan resource Amazon Web Services (AWS) menjadi mudah, kita hanya perlu mengirimkan template ke layanan CloudFormation.

Jika Anda masih merasa asing dengan beberapa term atau beberapa istilah di atas, berikut adalah poin-poin pembahasannya:

• Template adalah file teks yang menjelaskan dan mendefinisikan resource yang akan di-deploy di lingkungan.
• AWS CloudFormation adalah mesin yang memproses template. Output dari AWS CloudFormation disebut stack.
• Stack adalah kumpulan resource AWS yang di-deploy bersama sebagai satu grup.

Saat menggunakan AWS CloudFormation, Anda perlu memahami apa yang dimaksud dengan drift detection. Untuk pembahasan lebih jelas, simak penjelasan di bawah ini.

Apakah Drift Detection itu?
Melakukan operasi deteksi penyimpangan (drift detection) pada stack dapat menentukan apakah terjadi perubahan yang menyimpang terhadap stack dari konfigurasi template yang ditentukan sebelumnya. Kita akan mendapatkan informasi mendetail tentang status penyimpangan dari setiap resource dalam stack yang mendukung drift detection.

Drift detection dapat diaktifkan pada stack dengan klik kotak dialog "Detect Drift for current stack". Proses ini akan melanjutkan deteksi penyimpangan meskipun Anda menutup kotak dialog dan meninjau detail penyimpangan nanti. Jika Anda ingin mempelajarinya lebih lanjut, silakan lihat referensi situs-situs berikut:

• Detect drift on an entire CloudFormation stack. 
• Detecting unmanaged configuration changes to stacks and resources.

Keuntungan menggunakan IaC

Dengan membangun infrastruktur dengan kode, Anda akan mendapatkan manfaat dari repeatability (pengulangan) dan reusability (penggunaan kembali) saat membangun lingkungan Anda. Bayangkan, dengan satu template (atau kombinasi beberapa template), Anda dapat membangun lingkungan kompleks yang sama secara akurat berulang kali. 

Saat menggunakan infrastruktur sebagai kode dengan AWS, Anda bahkan dapat membuat lingkungan yang bergantung pada kondisi. Dengan demikian, apa yang akan Anda buat akhirnya dibangun secara spesifik sesuai dengan konteks Anda membuatnya. 

Misalnya, template dapat dirancang menggunakan kondisi sehingga AMI yang berbeda digunakan berdasarkan apakah template ini akan diluncurkan ke dalam lingkungan Development atau Production.

Perhatikan gambar di bawah ini yang menerangkan penggunaan CloudFormation template yang memanfaatkan repeatability dan reusability. 

Dalam skenario yang ada di gambar, template telah diperbarui dengan menambahkan konfigurasi security group baru ke dalam stack. 

Hanya dengan satu perubahan pada template yang digunakan untuk meluncurkan lingkungan ini, kedua lingkungan dapat memiliki security group baru yang Anda tambahkan. Fitur ini memberikan manfaat kemudahan pemeliharaan resource, konsistensi yang lebih baik, dan pengurangan upaya melalui paralelisasi.

CloudFormation Conditions

Lingkungan Production dan Development Anda harus dibangun dari stack yang sama. Ini memastikan bahwa aplikasi Anda bekerja dalam produksi sesuai dengan yang dirancang dan dikembangkan pada lingkungan Development.

Selain itu, lingkungan Development dan Testing Anda juga harus menggunakan stack yang sama. Dengan demikian, semua lingkungan akan memiliki aplikasi dan konfigurasi yang identik.

Anda mungkin memerlukan beberapa lingkungan Testing berbeda untuk pengujian fungsional, pengujian User Acceptance, dan pengujian beban / Load Test. Menciptakan lingkungan-lingkungan tersebut secara manual memiliki risiko yang besar.

Maka dari itu, Anda dapat menggunakan pernyataan Kondisi/Conditions di AWS CloudFormation template untuk memastikan bahwa lingkungan Development, Testing, dan Production dikonfigurasi secara identik, meskipun berbeda dalam ukuran dan cakupan.

Pada contoh di atas, diperlihatkan bahwa dengan satu template, kita dapat mendefinisikan hal-hal berikut (kita ambil contoh Web Tier): 

1. Men-deploy Web Tier ke 2 Availability Zone di lingkungan Production.
2. Web Tier terbentuk dengan arsitektur yang mirip tetapi lebih sederhana (deployment untuk 1 Availability Zone) di lingkungan Development.

Memperbarui Stack dengan ChangeSets

Saat dirasa perlu untuk memperbarui Stack, maka Anda harus memahami bagaimana perubahan akan memengaruhi resource yang sedang berjalan sebelum Anda menerapkannya, sehingga dapat membantu Anda dalam memperbarui Stack tanpa takut terjadi masalah. 

Change Sets memungkinkan Anda untuk melihat preview bagaimana perubahan yang diusulkan pada Stack dapat memengaruhi resource Anda yang sedang berjalan. Misalnya, apakah perubahan Anda akan menghapus atau mengganti resource penting? 

AWS CloudFormation akan membuat perubahan pada Stack hanya ketika Anda memutuskan untuk menjalankan Change Sets. Ini memungkinkan Anda memutuskan apakah akan melanjutkan perubahan yang Anda usulkan atau memeriksa perubahan lain dengan membuat Change Sets lain. Anda dapat membuat dan mengelola Change Sets menggunakan AWS CloudFormation console, AWS CLI, atau AWS CloudFormation API.

Untuk menggunakan Change Sets, lakukan langkah-langkah berikut:

1. Buat Change Sets dengan mengirimkan perubahan untuk Stack yang ingin Anda perbarui. Anda dapat mengirimkan template Stack atau nilai parameter input yang telah dimodifikasi. AWS CloudFormation akan membandingkan Stack Anda dengan perubahan yang Anda kirim untuk menghasilkan Change Sets. Saat ini tidak ada perubahaan pada Stack anda.
2. Lihat Change Sets untuk melihat pengaturan Stack dan resource mana yang akan berubah. Anda dapat melihat resource mana yang akan ditambahkan, diubah, atau dihapus oleh AWS CloudFormation.
3. Opsional : Jika Anda ingin mempertimbangkan perubahan lain sebelum memutuskan perubahan mana yang akan dilakukan, maka buatlah Change Sets tambahan. Membuat beberapa Change Sets membantu Anda memahami dan mengevaluasi bagaimana perubahan yang berbeda akan memengaruhi resource. Anda dapat membuat Change Sets sebanyak yang dibutuhkan.
4. Jalankan Change Sets yang berisi perubahan yang ingin diterapkan ke Stack Anda. AWS CloudFormation akan memperbarui Stack Anda dengan perubahan tersebut.

Dengan atribut DeletionPolicy, Anda dapat mempertahankan atau (dalam beberapa kasus) membuat backup dari resources saat stacknya dihapus atau diperbarui. Misalnya, jika Anda menghapus resource dari template stack, lalu mengupdate stack dengan template tersebut. Anda menentukan atribut DeletionPolicy untuk setiap sumber daya yang ingin Anda kontrol. Jika sebuah resource tidak memiliki atribut DeletionPolicy, AWS CloudFormation akan menghapusnya secara default. 

Kemampuan ini tidak berlaku untuk resource yang instance-nya diganti/diubah propertinya selama operasi pembaruan stack. Misalnya, jika Anda mengedit properti dari resource sehingga AWS CloudFormation mengganti resource tersebut ketika proses update stack.

Layered Architecture

AWS CloudFormation templates bisa Anda gunakan untuk membangun layered architecture alias arsitektur berlapis. Perhatikan gambar di bawah ini yang merupakan diagram sederhana dari layered architecture.

Pada pendekatan ini, kita menggunakan CloudFormation templates yang berbeda untuk masing-masing layer dan cross-stack reference di mana output dari--misalnya-- Stack Identity yang mendefinisikan IAM Users, Groups, dan Roles menjadi input dari layer di atasnya, dalam hal ini template Base Network dan seterusnya.

AWS Quick Starts

AWS Quick Starts dibuat oleh AWS solutions architects dan partner untuk membantu Anda dalam men-deploy teknologi populer di AWS berdasarkan praktik terbaik AWS untuk keamanan dan high availability (ketersediaan tinggi). 

Akselerator ini mampu mengurangi ratusan prosedur manual menjadi hanya beberapa langkah saja, sehingga Anda dapat membangun lingkungan production dengan cepat dan bisa segera mulai menggunakannya. Setiap Quick Starts menyertakan AWS CloudFormation template yang mengotomatiskan proses deploy, panduan yang membahas arsitektur, dan memberikan instruksi deployment langkah demi langkah. Quick start dapat diakses secara online dari website AWS.

AWS Quick Starts dibuat dari AWS CloudFormation template dan skrip terkait untuk membangun lingkungan di akun AWS Anda. Quick Starts akan melakukan semua bootstrap dan deployment untuk Anda. 

Perlu diperhatikan bahwa Anda akan dikenai biaya untuk resource yang digunakan dalam pembuatan dan pengoperasian lingkungan yang dibuat.

Automasi Deployment

Anda dapat membuat seluruh infrastruktur secara otomatis dengan menggunakan AWS CloudFormation, tetapi masih ada beberapa pertanyaan penting untuk diajukan.

Bagaimana cara memperbarui Amazon EC2 instance Anda? Apakah Anda harus masuk ke setiap instance dan menjalankan perintah pembaruan secara manual? Bagaimana Anda mengembalikan perubahan jika terjadi kesalahan? Bagaimana jika Anda memiliki 100 server yang menjalankan tiga aplikasi berbeda?

Sebenarnya, ada beberapa tool tradisional yang dapat membantu Anda dalam skenario di atas, tetapi sebuah solusi yang out-of-the-box tentu akan lebih baik. Simaklah materi-materi berikutnya!

AWS Systems Manager

AWS Systems Manager adalah layanan manajemen yang membantu Anda mengumpulkan inventaris perangkat lunak secara otomatis, menerapkan patch OS, membuat image sistem, dan mengonfigurasi sistem operasi Windows dan Linux. 

Kemampuan ini membantu Anda untuk menentukan dan melacak konfigurasi sistem, mencegah penyimpangan, serta menjaga compliance perangkat lunak Amazon EC2 dan konfigurasi on-premise Anda. Dengan memberikan pendekatan manajemen ini, AWS Systems Manager memudahkan Anda untuk menjembatani dengan mulus infrastruktur yang Anda miliki dengan AWS.

Anda dapat membuka AWS Systems Manager dari Amazon EC2 console, pilih instance yang ingin Anda kelola, dan tentukan tugas manajemen yang ingin dilakukan. AWS Systems Manager tersedia tanpa biaya untuk mengelola Amazon EC2 dan resource di on-premise.

AWS Systems Manager mampu melakukan beberapa hal, silakan perhatikan gambar di bawah ini.

Berdasarkan gambar di atas, AWS Systems Manager memiliki kemampuan dalam hal Command, Patch Management, Session Manager, Maintenance Windows, State Manager, dan Inventory. Mari kita uraikan setiap poinnya.

• Run Command
  Gunakan Run Command untuk melakukan perubahan sesuai permintaan (on-demand changes), seperti memperbarui aplikasi atau menjalankan Linux shell scripts dan Windows PowerShell commands pada kumpulan target untuk lusinan atau ratusan instance.
  
  

• Patch Management
  Gunakan Patch Manager untuk mengotomatiskan proses patching instance terkelola Anda. Kemampuan ini memungkinkan Anda untuk memindai (scan) instance dalam menemukan patch yang hilang dan menerapkan patch tersebut secara individual atau ke sekelompok instance melalui tag pada Amazon EC2 instance.
  
  Untuk security patch, Patch Manager menggunakan patch baseline yang menyertakan aturan untuk auto-approving patches (patch yang disetujui secara otomatis) dalam beberapa hari setelah dirilis, demikian pula daftar patch yang disetujui dan ditolak.
  
  Security patch diinstal dari repositori default untuk patch yang dikonfigurasi bagi instance tersebut. Anda dapat menginstal security patch secara teratur dengan menjadwalkan proses patching untuk dijalankan sebagai Systems Manager Maintenance Window task.
  
  Pada sistem operasi Linux, Anda dapat menentukan repositori yang harus digunakan untuk operasi patching sebagai bagian dari patch baseline Anda. Dengan demikian, Anda dapat meyakinkan bahwa updates yang diinstal akan bersumber dari repositori yang dapat dipercaya terlepas dari repositori yang terkonfigurasi pada instance.
  
  

• Maintenance Windows
  Gunakan Maintenance Windows untuk menyiapkan jadwal bagi instance Anda dalam menjalankan tugas seperti menginstal patch tanpa mengganggu keberlangsungan operasi bisnis yang kritikal.
  
  

• State Manager
  Membantu mengotomatiskan proses dalam menjaga instance terkelola Anda agar tetap pada keadaan (state) yang ditentukan. Anda dapat menggunakan State Manager untuk memastikan instance Anda di-bootstrap dengan perangkat lunak tertentu saat memulai, digabungkan ke domain Windows (hanya instance Windows), atau di-patch dengan pembaruan perangkat lunak tertentu.
  
  

• Session Manager
  Gunakan Session Manager untuk mengelola Amazon EC2 instance Anda melalui shell berbasis browser atau AWS CLI. Session Manager menyediakan manajemen instance yang aman dan dapat diaudit tanpa perlu membuka inbound-port masuk, memelihara bastion host, atau mengelola SSH key.
  
  Session Manager juga memudahkan Anda untuk mematuhi kebijakan perusahaan yang memerlukan akses terkontrol ke instance, praktik keamanan yang ketat, dan log yang dapat diaudit sepenuhnya dengan detail akses instance.
  
  

• Inventory
  Gunakan Inventory untuk visibilitas ke Amazon EC2 Anda dan lingkungan komputasi di on-premise. Anda dapat menggunakan Inventory untuk mengumpulkan metadata dari instance terkelola Anda.

AWS OpsWorks

AWS OpsWorks adalah layanan manajemen konfigurasi yang membantu Anda mengonfigurasi dan mengoperasikan aplikasi di perusahaan cloud dengan menggunakan Puppet atau Chef. 

AWS OpsWorks Stacks dan AWS OpsWorks for Chef Automate memungkinkan Anda menggunakan Chef cookbooks dan solusi untuk manajemen konfigurasi.

Sementara itu, AWS OpsWorks for Puppet Enterprise memudahkan Anda dalam mengonfigurasi Puppet Enterprise master server di AWS. Puppet menawarkan serangkaian tools untuk menegakkan kondisi infrastruktur yang Anda inginkan dan mengautomasi tugas sesuai permintaan.

Mari kita bahas AWS OpsWorks for Chef Automate, AWS OpsWorks for Puppet Enterprise, dan AWS OpsWorks Stacks satu per satu pada poin-poin berikut:

• AWS OpsWorks for Chef Automate
  AWS OpsWorks for Chef Automate adalah layanan Chef Automate server terkelola sepenuhnya dan rangkaian alat automasi yang memberikan automasi alur kerja untuk deployment berkelanjutan, automasi pengujian untuk compliance dan keamanan, serta user interface yang memberikan penglihatan ke dalam nodes dan statusnya.
  
  OpsWorks menghilangkan kebutuhan untuk mengoperasikan sistem manajemen konfigurasi Anda sendiri, sehingga Anda tak perlu khawatir tentang pemeliharaan infrastruktur.
  
  OpsWorks memberi Anda akses ke semua fitur Chef Automate, seperti konfigurasi dan manajemen compliance yang dapat Anda kelola melalui Chef console atau command line tool (Knife). Layanan ini juga mampu bekerja dengan Chef cookbook yang Anda miliki. Gunakan AWS OpsWorks for Chef Automate jika anda berpengalaman menggunakan Chef.
  
  

• AWS OpsWorks for Puppet Enterprise
  AWS OpsWorks for Puppet Enterprise menyediakan Puppet Enterprise server yang terkelola dan serangkaian tool automasi yang memberikan alur automasi alur kerja untuk orkestrasi, penyediaan otomatis, dan visualisasi untuk traceability (keterlacakan).
  
  Puppet Enterprise server memberikan Anda automasi penuh dengan menangani tugas operasional, seperti konfigurasi perangkat lunak dan sistem operasi, instalasi paket, penyiapan database, dan lainnya. Puppet Master secara terpusat menyimpan tugas konfigurasi Anda dan menyajikannya ke setiap node di lingkungan komputasi pada skala apa pun, dari beberapa node hingga ribuan node.
  
  

• AWS OpsWorks Stacks
  AWS OpsWorks Stacks adalah aplikasi dan layanan manajemen server. Dengan OpsWorks Stacks, Anda dapat membuat model aplikasi sebagai stack yang berisi berbagai layer, seperti load balancing, database, dan server aplikasi.
  
  Dalam setiap layer, Anda dapat menggunakan Amazon EC2 instance, mengaktifkan Auto Scaling, dan mengonfigurasi instance dengan Chef recipes menggunakan Chef Solo. Ini memungkinkan Anda untuk mengotomatiskan tugas-tugas seperti menginstal paket, mengonfigurasi perangkat lunak, dan banyak lagi.
  
  AWS OpsWorks Stacks menyediakan cara yang fleksibel untuk membuat dan mengelola Stacks serta aplikasi, yaitu melalui trigger seperti ditunjukkan di gambar di bawah ini.
   

Menggunakan AWS Opsworks Stacks dengan AWS CloudFormation

Ketahuilah! Anda dapat membuat model komponen OpsWorks (stacks, layer, instance, dan aplikasi) di dalam CloudFormation template, lalu menyajikannya sebagai CloudFormation stacks. 

Hal tersebut memungkinkan Anda untuk mendokumentasikan, melakukan version control, dan berbagi konfigurasi OpsWorks. Anda memiliki fleksibilitas untuk menyediakan komponen OpsWorks dan resource AWS lainnya, seperti Amazon VPC dan AWS Elastic Load Balancer dengan CloudFormation template terpadu atau CloudFormation template terpisah.

Pada gambar di atas, CloudFormation template digunakan untuk membuat infrastruktur dasar seperti IAM Permissions, VPC, dsb. Selanjutnya, dalam template tersebut juga didefinisikan PHP Application Stack yang sebenarnya merupakan stacks dari OpsWorks.

Opsi Automasi yang Lebih Mudah

Opsi automasi seperti CloudFormation, System Manager, maupun OpsWorks memang sangat membantu, tetapi hal ini masih cukup kompleks dan memerlukan waktu dan tenaga yang tidak sedikit, ini disebabkan beberapa hal berikut:

• Mengelola infrastruktur untuk proses deploy aplikasi bisa jadi sulit.
• Perlu banyak waktu untuk mengelola dan mengonfigurasi server.
• Kurangnya konsistensi di beberapa proyek atau aplikasi.

Tenang, AWS sangat memahami hal ini. Maka dari itu, untuk lebih membantu Anda dan tim developer, AWS menghadirkan Elastic Beanstalk. Simak penjelasannya di materi berikutnya!

AWS Elastic Beanstalk

Tujuan dari AWS Elastic Beanstalk adalah membantu developer men-deploy dan memelihara aplikasi serta layanan web yang dapat di-scale (diskalakan) di cloud tanpa harus mengkhawatirkan infrastruktur yang mendasarinya. Perhatikan, gambar di bawah ini menunjukkan bahwa hanya Code-lah yang menjadi tanggung jawab Anda, sisanya, provision sumber daya, operasi dari infrastruktur, dan pengelolaan stack aplikasi akan ditangani oleh AWS.

AWS Elastic Beanstalk mengonfigurasi setiap EC2 instance di lingkungan Anda dengan komponen yang diperlukan untuk menjalankan aplikasi di atas platform yang dipilih. Bahkan, Anda tidak perlu mengoperasikan instance Anda untuk memasang dan mengonfigurasi stack aplikasi.

Terdapat dua jenis lingkungan yang dapat Anda pilih saat bekerja dengan AWS Elastic Beanstalk. Pertama, lingkungan instance tunggal. Jenis ini memungkinkan Anda untuk meluncurkan satu EC2 instance. Ingat bahwa di sini tidak menyertakan load balancer atau Auto Scaling. 

Ada juga lingkungan yang kedua. Jenis ini dapat meluncurkan beberapa EC2 instance, mencakup load balancer, dan konfigurasi Auto Scaling.

Dengan hadirnya AWS Elastic Beanstalk, tentu ini akan memudahkan kita dalam men-deploy aplikasi. Layanan ini akan menyediakan resource infrastruktur yang diperlukan, seperti ELB, Auto Scaling group, security group, dan database (opsional).

Warning Ikuti modul latihan ini sesuai dengan langkah-langkah yang kami berikan. Jika Anda telah menyelesaikan latihan ini, harap mengikuti tahapan Clean Up yang ada di akhir latihan untuk mengetahui bagaimana cara menghapus resource yang telah dibuat. 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: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation

Pada latihan kali ini, kita akan men-deploy infrastruktur multi-tier yang andal menggunakan automasi dengan layanan AWS CloudFormation. Kita akan membuat dua CloudFormation template, satu untuk membuat Amazon Virtual Private Cloud (VPC) dan lainnya untuk men-deploy infrastruktur yang andal ke VPC Anda, yakni Amazon EC2 yang terdistribusi ke tiga Availability Zone. 

Setelah selesai men-deploy dan mengulas template, kita juga akan meng-update CloudFormation stack, lalu terakhir kita akan melihat proses penghapusan stack. Dengan mengikuti latihan ini, Anda akan bisa membangun beban kerja yang elastis, andal, dan memiliki ketersediaan tinggi sesuai dengan praktik terbaik AWS Well-Architected Framework untuk pilar reliability menggunakan automasi. Menarik, bukan?

Arsitektur dari infrastruktur yang akan Anda deploy direpresentasikan dengan diagram berikut:

Mari kita ulas apa yang dimaksud dari gambar arsitektur di atas:

1. Terdapat satu EC2 instance di setiap Availability Zone.
2. Ketika connection terhadap website di-refresh beberapa kali, perhatikan bahwa EC2 instance dan Availability Zone yang melayani permintaan tersebut akan berubah di antara tiga yang tersedia.
3. Kita menggunakan salah satu jenis load balancer dari ELB, yakni Application Load Balancer yang akan menerima setiap permintaan dan mendistribusikannya di antara EC2 instance yang tersedia di seluruh Availability Zone.
4. EC2 instance berada dalam Amazon EC2 Auto Scaling group. Auto Scaling group ini dikonfigurasi untuk mempertahankan tiga instance. Oleh karena itu, jika satu instance terdeteksi unhealthy (tidak sehat), ia akan digantikan dengan instance yang baru guna mempertahankan tiga instance yang healthy (sehat).

Oke, sebelum kita masuk ke praktiknya, berikut adalah tahapan-tahapan yang akan kita lakukan di latihan ini:

1. Men-deploy VPC menggunakan AWS CloudFormation.
2. Men-deploy aplikasi web dan infrastructure menggunakan AWS CloudFormation.
3. Menguji aplikasi web.
4. Mengulas CloudFormation template.
5. Memperbarui CloudFormation stack untuk menambahkan S3 bucket.
6. Menghapus CloudFormation stack.

Oke, sepertinya Anda sudah siap untuk memulai latihan kali ini. Jadi, mari kita meluncur ke langkah-langkah di bawah ini.

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Deploy VPC

Pada bagian pertama, kita akan menggunakan AWS CloudFormation untuk men-deploy VPC. Untuk membuatnya, silakan unduh file berikut vpc-alb-app-db.yaml dan simpan di lokasi penyimpanan komputer/laptop Anda yang mudah dicari (misalnya di folder Downloads). Ini adalah file YAML yang akan kita gunakan nanti sebagai template saat membuat CloudFormation stack. Yuk kita mulai!

1. Masuklah ke halaman utama AWS CloudFormation dengan cara mengetik cloudformation pada kotak pencarian yang berada di bagian atas AWS Management Console.
   
   Catatan: Pastikan Anda berada di region terdekat ya (di bagian kanan atas halaman console), yakni Singapore (ap-southeast-1).
   
   

2. Buatlah CloudFormation stack dengan klik tombol Create stack.
    

3. Pada bagian Prepare template, biarkan pada pilihan Template is ready. Kemudian pada Specify template, pilihlah Upload a template file, lalu klik Choose file, dan pilihlah file vpc-alb-app-db.yaml di komputer Anda. Jika sudah, silakan klik tombol Next.
   
   
   

4. Anda akan diarahkan ke halaman Specify stack details. Masukkan nama stack dengan WebApp1-VPC (pastikan sama, termasuk huruf besar kecilnya).
   
   
   

5. Selanjutnya adalah bagian Parameters, biarkan bagian ini sesuai default (Anda tidak perlu mengubah apa pun). Silakan perhatikan setiap konfigurasi dengan saksama, lalu scroll ke paling bawah, dan klik tombol Next.
   
   
   

6. Mari kita buat tag yang dapat membantu Anda dalam mengidentifikasi stack. Masukkan Name pada kolom kiri yang mana adalah key dan WebApp1-VPC pada kolom sebelah kanan yang mana adalah value.
   
    

7. Kita tidak akan menggunakan permission atau opsi tambahan.  Jadi, klik tombol Next.
    

8. Silakan review konfigurasi stack Anda. Pada halaman paling bawah, centang I acknowledge that AWS CloudFormation might create IAM resources with custom names, kemudian klik tombol Create stack.
    

9. Tunggulah beberapa menit hingga status stack Anda berubah dari CREATE_IN_PROGRESS menjadi CREATE_COMPLETE. Anda bisa klik tombol refresh secara berkala untuk memastikan perubahan pada status stack Anda.
   
   
   

Yuhuu! Anda sudah berhasil membuat CloudFormation stack untuk VPC (sebenarnya, CloudFormation-lah yang melakukannya untuk Anda). Sebagai bukti, silakan cek ke halaman Amazon VPC (dengan cara mengetikkan vpc di kotak pencarian pada bagian atas console) dan lihatlah bahwa di sana ada VPC yang telah kita buat menggunakan AWS CloudFormation. 

Mari kita lanjutkan ke bagian berikutnya!

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Deploy Aplikasi Web dan Infrastruktur

Pada bagian kedua ini, kita akan men-deploy aplikasi web dan infrastrukturnya. Kita akan membuat Amazon EC2 instance, DynamoDB table, Application Load Balancer, dan Auto Scaling.  

Silakan unduh file YAML berikut staticwebapp.yaml yang nantinya akan kita gunakan saat membuat CloudFormation stack.

1. Silakan masuk ke halaman AWS CloudFormation (dengan cara mengetikkan cloudformation di kotak pencarian pada bagian atas console). Buka menu Stacks -> Create stack -> With new resources (standard).
    

2. Biarkan Prepare template sesuai default. Untuk Template source, pilih Upload a template file. Kemudian klik Choose file dan pilih CloudFormation template yang telah Anda unduh sebelumnya: staticwebapp.yaml. Jika sudah, klik tombol Next.
    

3. Pada Stack name, isikan CloudFormationLab.
    

4. Selanjutnya, silakan perhatikan bagian Parameters dan biarkan sesuai default. Lalu klik tombol Next.
   
   
   

5. Sekarang kita masuk ke bagian Configure stack options. Tambahkanlah tag dengan isian Name di kolom kiri yang mana adalah key dan CloudFormationLab di kolom sebelah kanan yang mana adalah value.
   
   
   

6. Kita tak akan menggunakan permission dan opsi tambahan pada latihan kali ini. Jadi, klik tombol Next.
    

7. Masuklah kita ke halaman Review. Silakan perhatikan konfigurasi yang telah Anda buat. Pada halaman paling bawah, centang I acknowledge that AWS CloudFormation might create IAM resources with custom names. Jika sudah, silakan klik tombol Create stack.
   
   
   

8. Kita akan dibawa ke halaman status dari CloudFormation stack events. Tunggulah beberapa menit dan lakukan refresh secara berkala guna melihat perubahan pada status stack Anda hingga menjadi CREATE_COMPLETE.
   
   
   

Selamat! Anda telah berhasil membuat CloudFormation stack untuk aplikasi web dan infrastrukturnya. Sebagai bukti, silakan cek ke halaman Amazon EC2 (dengan cara mengetikkan ec2 di kotak pencarian pada bagian atas console) dan lihatlah bahwa di sana ada hasil instance yang telah kita buat menggunakan AWS CloudFormation. 

Cek juga Load Balancer dan Auto Scaling (masih berada di halaman EC2), serta DynamoDB (dengan cara mengetikkan dynamodb di kotak pencarian pada bagian atas console) untuk melihat hasil dari CloudFormation stack kita. Perhatikan, gambar di bawah ini adalah tampilan DynamoDB table yang telah kita buat menggunakan AWS CloudFormation. Terdapat sebuah DynamoDB table dengan nama RecommendationService. Cobalah klik pada nama tabel tersebut.

Kemudian buka ke tab Items dan Anda akan melihat sekumpulan nilai. Fokuslah ke kolom Result dan UserName.

Penasaran seperti apa penggunaan kedua kolom tersebut? Jawabannya ada di bagian berikutnya, semangat!

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Menguji Aplikasi Web

Sekarang, kita akan menguji coba aplikasi web yang telah di-deploy menggunakan AWS CloudFormation pada bagian sebelumnya. Penasaran? Mari kita mulai!

1. Masuk ke halaman AWS CloudFormation, buka menu Stacks, lalu klik CloudFormationLab. Pastikan stack tersebut telah berstatus CREATE_COMPLETE.
   
   
   

2. Selanjutnya buka tab Outputs, lalu klik kanan -> open in new tab pada tautan yang ada di kolom Value.
   
   
   

3. Aplikasi website Anda pun akan muncul seperti gambar di bawah ini. Ingat! Data yang dimuat pertama kali mungkin akan berbeda pada layar Anda.
   
   Catatan: Jika muncul eror seperti 502 Bad Gateway, maka tunggulah beberapa saat dan coba lakukan refresh. Ini karena server membutuhkan waktu untuk memulai.
   
   

4. Cobalah lakukan refresh di web browser beberapa kali. Perhatikan! Bagian nama, judul, Availability Zone, dan instance id akan berubah setiap Anda melakukan refresh.
    

Oke, aplikasi website Anda sudah berhasil termuat. Mari kita jabarkan penjelasannya berdasarkan gambar di atas.

Aplikasi website tersebut menyimulasikan sebuah recommendation engine (mesin pemberi rekomendasi) yang membuat saran yang dipersonalisasi untuk acara TV klasik. Berikut adalah fitur-fiturnya:

• Bagian di atas garis menunjukkan rekomendasi yang dipersonalisasi.
  • Bagian ini menampilkan nama dan acara TV.
  • Cara kerjanya cukup sederhana. Setiap request yang dilakukan akan menampilkan nama pengguna secara acak dan memuat rekomendasi yang dipetakan secara statis ke pengguna tersebut. Nama pengguna, judul acara TV, dan proses pemetaan berada di sebuah DynamoDB table.
• Bagian di bawah garis menunjukkan metadata yang berguna bagi Anda pada latihan kali ini
  • Bagian instance_id dan availability_zone memudahkan Anda untuk melihat EC2 instance dan Availability Zone mana yang sedang melayani request masuk.

Menarik, bukan? Eits, belum berhenti sampai di sini. Selanjutnya, kita akan mengulas template yang kita pakai sebelumnya. Let’s Go!

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Mengulas CloudFormation Template

Di bagian keempat ini kita akan menjelajahi template dan belajar bagaimana Anda bisa men-deploy aplikasi web menggunakan template tersebut. Seperti yang sudah dijelaskan sebelumnya, template ini ditulis dengan format YAML, ia merupakan salah satu format file yang didukung oleh layanan CloudFormation selain JSON. Mari kita mulai!

1. Masuk ke halaman AWS CloudFormation, lalu buka menu Stacks, dan klik CloudFormationLab. Ini adalah hasil Stack yang dibuat oleh step sebelumnya di bagian 2.
    

2. Selanjutnya, silakan buka tab Template. Ini adalah template yang Anda gunakan untuk membuat aplikasi web. Mari kita kupas beberapa bagian.
   
   
   

3. Pertama, lihatlah pada bagian InstanceType (Anda bisa melakukan pencarian dengan tekan CTRL + F). Ini adalah bagian di mana kita bisa memilih tipe instance yang akan digunakan untuk men-deploy server untuk aplikasi web. Nah, di sini kita menentukan bahwa default-nya adalah t2.micro karena tipe ini termasuk ke dalam Free Tier.

   InstanceType:     Description: WebServer EC2 instance type     Type: String     Default: t2.micro     AllowedValues:       - t3.nano       - t3.micro       - t3.small       - t3.medium       - t3.large       - t2.nano       - t2.micro       - t2.small       - t2.medium       - t2.large       - m5.medium       - m5.large       - m5.xlarge       - m5.2xlarge       - m5.4xlarge       - m5.12xlarge       - m5.24xlarge     ConstraintDescription: must be a valid EC2 instance type.

4. Selanjutnya, temukan Web1LaunchConfig. Ini adalah launch configuration yang kita gunakan untuk Auto Scaling. Lihat pada baris InstanceType: !Ref InstanceType. Ini menandakan bahwa Auto Scaling akan menggunakan tipe instance yang kita tetapkan sebelumnya pada langkah ke-3, yang telah ditentukan default value-nya adalah t2.micro.

   Web1LaunchConfig:     Type: 'AWS::AutoScaling::LaunchConfiguration'     #https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html     Properties:       ImageId: !Ref LatestAmiId       IamInstanceProfile: !Ref Web1InstanceInstanceProfile       InstanceType: !Ref InstanceType       SecurityGroups:         - !Ref Web1InstanceSecurityGroup

5. Lanjut, carilah bagian Resources. Bagian ini merupakan “jantung” dari template. Di sinilah Anda menentukan infrastruktur yang akan di-deploy.
   
   Fokus ke bagian resource pertama, yakni DynamoDB. Ini adalah Amazon DynamoDB table yang digunakan sebagai recommendation engine pada aplikasi web kita. Berikut poin-poin pembahasannya:

   Logical ID	Logical ID pada kasus ini adalah DynamoDBServiceMockTable. Logical ID ini adalah cara kita merujuk ke sumber daya DynamoDB table dalam CloudFormation template.
   Type	Ini memberi tahu CloudFormation tipe sumber daya mana yang akan dibuat. Pada kasus ini yaitu AWS::DynamoDB::Table.
   Properties	Bagian ini mendefinisikan beberapa nilai yang digunakan untuk DynamoDB table.

   Di bawah ini adalah potongan template untuk bagian DynamoDB table.

   Resources:   DynamoDBServiceMockTable:     Type: 'AWS::DynamoDB::Table'     Properties:        TableName: 'RecommendationService'       AttributeDefinitions:          -            AttributeName: 'ServiceAPI'           AttributeType: 'S'         -            AttributeName: 'UserID'           AttributeType: 'N'       KeySchema:          -            AttributeName: 'ServiceAPI'           KeyType: 'HASH'         -            AttributeName: 'UserID'           KeyType: 'RANGE'       ProvisionedThroughput:          ReadCapacityUnits: '5'         WriteCapacityUnits: '5'       SSESpecification:          SSEEnabled: 'true'

6. Sekarang mari kita lihat bagian selanjutnya, silakan scroll dan cari bagian Outputs. Bagian ini digunakan untuk menampilkan informasi tertentu mengenai sumber daya di dalam CloudFormation stack setelah proses provisioning selesai. Pada kasus ini, kita menggunakan function bawaan !GetAtt untuk mendapatkan DNSName (nama DNS) dari Application Load Balancer.
   
   URL ini adalah yang kita gunakan untuk mengakses aplikasi web seperti pada Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Menguji Aplikasi Web.

   Outputs:   WebsiteURL:     Value: !Join       - ''       - - 'http://'         - !GetAtt            - ALB1LoadBalancer           - DNSName         - /     Description: Static Website

7. Terakhir, silakan temukan bagian Metadata. Bagian ini kita gunakan untuk mengelompokkan dan mengatur bagaimana CloudFormation template ditampilkan saat Anda men-deploy template menggunakan AWS Console.

   Metadata:    AWS::CloudFormation::Interface:      ParameterGroups:        -          Label:            default: "General Configuration"         Parameters:            - NamingPrefix       -          Label:            default: "VPC Stack Imports"         Parameters:            - VPCImportName           - VPCImportApp1Instance1Subnet1           - VPCImportApp1Instance1Subnet2           - VPCImportApp1Instance1Subnet3           - VPCImportALB1Subnet1           - VPCImportALB1Subnet2           - VPCImportALB1Subnet3       -          Label:            default: "Application Tier Configuration"         Parameters:            - InstanceType           - LatestAmiId           - ServerCodeUrl           - Web1AutoScaleDesired           - ALBSGSource

   
   

Oke, kita sudah mengulas beberapa bagian pada CloudFormation template. Selanjutnya, kita akan melakukan update untuk menambahkan S3 bucket ke dalamnya. Break a leg!

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Menambahkan S3 Bucket

Pada bagian ini, kita akan memperbarui CloudFormation stack CloudFormationLab guna menambahkan S3 bucket. Yuk langsung saja kita mulai!

1. Salin konfigurasi YAML berikut:

   MyS3Bucket:     Type: AWS::S3::Bucket

2. Buka file staticwebapp.yaml pada komputer Anda menggunakan notepad atau teks editor, lalu paste konfigurasi di atas setelah bagian RecommendationServiceEnabled sebelum baris tanda pagar. Perhatikan gambar di bawah ini.
   
   Pastikan MyS3Bucket di awali dengan 2 spasi, sementara Type: AWS::S3::Bucket di awali 4 spasi. Jika sudah, silakan simpan file tersebut dengan cara pilih Save pada text editor Anda.
   
   

3. Selanjutnya, masuk ke halaman AWS CloudFormation, lalu buka menu Stacks, dan klik CloudFormationLab.
   
   
   

4. Setelah masuk ke halaman CloudFormationLab stack, silakan klik tombol Update.
   
   
   

5. Pada bagian Prepare template, klik Replace current template. Kemudian, pilih Upload a template file untuk Template source, lalu klik Choose file, dan pilih staticwebapp.yaml di komputer Anda (file ini sudah diperbarui di langkah 2). Seusai itu, klik tombol Next.
   
   Catatan : Jika Anda mengalami eror saat mengunggah file, cek kembali indentasi pada file YAML Anda (lihat langkah 2). Jika dipastikan sudah aman, silakan unggah ulang file YAML tersebut.
   
   

6. Anda akan diarahkan ke halaman selanjutnya. Tak ada yang perlu diubah, jadi silakan klik Next.
   
   
   

7. Lanjut, scroll ke halaman paling bawah dan klik tombol Next.
   
   
   

8. Pada halaman Review CloudFormationLab, perhatikan bagian Change set preview yang menampilkan penambahan S3 bucket. Kemudian, centang I acknowledge that AWS CloudFormation might create IAM resources with custom names. Jika sudah, lanjutkan dengan klik tombol Update stack.
   
   
   

9. Tunggu beberapa menit hingga status pada CloudFormationLab berubah menjadi UPDATE_COMPLETE. Lanjut, buka tab Resources, kemudian scroll hingga Anda menemukan Logical ID dengan nama MyS3Bucket. Ini menandakan bahwa penambahan S3 bucket kita telah berhasil dengan sempurna.
   
   
   

Mantap! Kita telah berhasil melakukan update pada CloudFormation stack. 

Clean Up Silakan tuntaskan latihan ini dengan menghapus kedua stack yang telah Anda buat. Jangan khawatir, langkah-langkah penghapusannya ada di modul selanjutnya.

Hands-on Lab: Automasi Proses Deploy Infrastruktur dengan AWS CloudFormation - Menghapus Stack

Setelah selesai membuat, mengulas, dan memperbarui stack, sekarang mari kita menghapus keduanya. Ikuti langkah-langkah berikut:

1. Masuk ke halaman AWS CloudFormation, lalu buka menu Stacks, dan klik CloudFormationLab.
   
   
   

2. Selanjutnya, klik tombol Delete untuk menghapusnya.
   
   
   

3. Jika CloudFormationLab sudah terhapus, lakukanlah hal yang sama untuk WebApp1-VPC.
   
   
   

Hooray! Selamat Anda telah menyelesaikan latihan pada kali ini. Tetap semangat ya! Ke depannya kita akan belajar sesuatu yang baru. Persiapkan diri Anda dan silakan meluncur ke modul selanjutnya!

Ikhtisar

Satu pertanyaan yang sering muncul saat Anda membangun arsitektur di AWS adalah tentang berbagai layanan yang menyediakan kemampuan manajemen aplikasi dan di mana batas kontrol pengelolaannya. Tentu, hal itu sangat tergantung pada tingkat kenyamanan dan sejauh mana kontrol yang Anda butuhkan. Silakan amati gambar di bawah ini.

Mari kita ingat kembali apa saja pembahasan yang kita lalui pada modul ini, yakni:

• AWS Elastic Beanstalk
  AWS Elastic Beanstalk adalah layanan aplikasi yang mudah digunakan untuk membuat aplikasi web dengan container yang populer seperti Java, PHP, Node.js, Python, Ruby, dan Docker. Jika Anda ingin mengunggah kode dan tidak perlu membangun dan menyesuaikan lingkungan Anda secara manual, Elastic Beanstalk adalah pilihan yang tepat.
  
  

• AWS OpsWorks
  AWS OpsWorks memungkinkan Anda meluncurkan aplikasi, menentukan arsitekturnya, serta spesifikasi setiap komponen termasuk instalasi paket, konfigurasi perangkat lunak, dan resource (seperti penyimpanan). Anda dapat menggunakan template untuk teknologi umum (server aplikasi, database, dll) atau Anda dapat membuat template sendiri.
  
  

• AWS CloudFormation
  AWS CloudFormation adalah mekanisme penyediaan/pembuatan arsitektur yang baik untuk berbagai resource AWS dan dari pihak ketiga. Layanan ini mendukung kebutuhan infrastruktur untuk berbagai jenis aplikasi, seperti aplikasi perusahaan, aplikasi lawas, aplikasi yang dibangun menggunakan berbagai resource AWS, dan solusi berbasis container (termasuk yang dibuat menggunakan AWS Elastic Beanstalk).
  
  Tak hanya itu, AWS CloudFormation juga mendukung AWS OpsWorks dan AWS Elastic Beanstalk.