- Saya membuat mind map yang memperlihatkan hubungan antar resource jaringan AWS secara sekilas untuk memahami item-item kompleks di dasbor AWS VPC
- Menggunakan AWS Networking Fundamentals karya Toni Pasanen sebagai referensi utama, resource terkait jaringan disusun dengan fokus pada struktur koneksinya
- Alasan jaringan AWS menjadi kompleks adalah beragamnya jenis koneksi, termasuk koneksi akun–on-premises, akun–akun, VPC–VPC, subnet–subnet, VPC–internet, dan VPC–layanan AWS
- Hasilnya adalah mind map yang menghubungkan komponen-komponen jaringan AWS satu sama lain, dan versi asli Lucidchart juga dapat dilihat
- Pengembang yang baru mulai merapikan pemahaman tentang jaringan AWS dapat memanfaatkannya untuk memahami secara visual bagaimana berbagai resource saling terkait
Kebingungan yang bermula dari dasbor VPC
- Sebelum Maret 2023, sulit memahami apa yang terjadi di dasbor VPC AWS
- Karena ada begitu banyak item hingga scrollbar di panel kiri menjadi panjang, sulit memahami bagaimana setiap resource terhubung
Referensi yang digunakan dan arah penyusunan
- Untuk memahami berbagai resource yang terlibat dalam jaringan AWS, sebagian besar AWS Networking Fundamentals karya Toni Pasanen telah dibaca
- Setelah membaca buku tersebut, banyaknya resource jaringan AWS disimpulkan terjadi karena banyaknya cara koneksi yang memungkinkan
Jenis koneksi yang dibahas dalam jaringan AWS
- Jaringan AWS mencakup berbagai jenis koneksi
- Koneksi antara akun AWS dan on-premises
- Koneksi antar akun
- Koneksi antara VPC dan VPC
- Koneksi antar subnet
- Koneksi antara VPC dan internet
- Koneksi antara VPC dan layanan AWS tertentu
Hasil mind map
- Untuk menghubungkan berbagai bagian tersebut, konsep jaringan AWS dibuat dalam bentuk mind map
- Versi edit asli dapat dilihat di tautan Lucidchart
- Meminta umpan balik tentang apakah ini bermanfaat atau apakah ada kesalahan
1 komentar
Komentar Hacker News
Tidak paham kenapa debugging kebijakan IAM dan masalah autentikasi di AWS bisa seberantakan ini
Kalau ingin jadi pesaing, fokus saja ke sini. Saya buang berjam-jam untuk mencari penyebab error izin ditolak, dan dokumentasi resminya menyuruh saya menelusuri secara manual sekitar 8 jenis kebijakan yang mungkin berlaku seperti SCP, IAM, resource policy, dan lain-lain
Pada akhirnya, bahkan setelah menemukan dokumentasi untuk memakai Athena dan CloudTrail, separuh request tetap hilang tanpa alasan, dan meski ada request ID di pesan error, itu pun tidak bisa dipakai untuk mencarinya dengan mudah. Seharusnya bisa langsung mencari berdasarkan request ID dan menampilkan dengan jelas kebijakan mana yang menolak
Dari awal sampai akhir benar-benar kacau, dan kadang terasa seperti kondisi ini dipertahankan agar bisa menjual lebih banyak kontrak dukungan
Untuk proyek pribadi, kecuali dalam kasus yang sangat jarang, saya hampir selalu memilih opsi lain yang memberi nilai lebih baik. Sekitar 10 tahun lalu AWS dijual dengan narasi seperti “biar kami yang mengelola sistemnya, pecat saja semua sysadmin”, tapi sekarang engineer AWS DevOps yang bagus mahal, sulit dicari, dan terutama pada konfigurasi besar, kalau benar-benar mengikuti rekomendasi AWS, biayanya juga luar biasa besar
Saat memberi function app akses ke database SQL, saya cukup memakai nama asli function app itu, dan kalau ada alias, cukup dibatasi dengan object identifier. Tidak perlu lagi password atau sertifikat, dan semuanya langsung jalan
Kalau dipakai bersama paket autentikasi dan hal-hal seperti Application Insights, dengan asumsi kita tahu cara membaca log, kita hampir tidak pernah lama terjebak pada pertanyaan “sebenarnya apa yang terjadi”
Tapi Azure juga tetap mengharuskan kita tahu dulu di mana ranjau-ranjaunya; kalau tidak, frustrasinya bisa mirip. Microsoft memang meninggalkan petunjuk lokasi ranjau jauh lebih baik daripada AWS, tetapi beberapa petunjuk penting tetap conveniently hilang, sampai-sampai Anda butuh orang seperti penyihir berpengalaman 20 tahun agar bisa menembus lapisan terakhir dan menghindari biaya serta kompleksitas yang membengkak 5~10 kali lipat
Debugging service account kadang bahkan perlu reboot mesin atau klaster, jadi makin berat. Akan luar biasa kalau ada alat semacam “cloud traceroute” yang bisa menunjukkan persis di mana masalahnya terjadi
Agar adil, ada beberapa tool least privilege yang belum saya coba: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
Benar-benar menjengkelkan, dan mereka seharusnya melibatkan desainer UX dan engineer dalam perancangannya, tetapi tidak melakukannya
Jika layanan seperti itu disediakan ke pelanggan, secara potensial itu juga bisa tersedia bagi penyerang, dan pada kenyataannya bahkan bisa melanggar kebijakan keamanan dan kepatuhan di beberapa perusahaan
Meski begitu, saya tetap berpikir setidaknya itu harus bisa dipilih oleh pelanggan jika mereka menandatangani dokumen yang mengakui risiko besar, seperti “melakukan hal berbahaya dengan pengguna root AWS”
Karena request AWS sangat terdistribusi, secara konsep arsitektur mirip GraphQL tampaknya cocok dengan sistem seperti ini. Ini juga tidak terlalu jauh dari sistem pelacakan seperti OTEL.
Itulah sebabnya saya tidak suka harus berurusan dengan AWS. Mempelajari ini bukan pengetahuan teknis, melainkan pengetahuan produk
Saya sudah membaca seri TCP/IP Illustrated dari awal sampai akhir dan benar-benar menguasainya, dan pengetahuan itu berguna selama puluhan tahun
Sebaliknya, pengetahuan AWS memang kompleks dengan caranya sendiri, tetapi setiap kali tetap membuat saya enggan mempelajarinya. Melihat diagram ini, saya tidak yakin seberapa berhasil tujuannya jika memang yang dikejar adalah penyederhanaan
Misalnya, jika tujuannya adalah memungkinkan pelanggan enterprise mereplikasi jaringan enterprise virtual atau jaringan pusat data virtual, hal-hal itu memang jauh lebih kompleks daripada stack TCP klien
Untuk penggunaan sederhana, default-nya juga sederhana. Untuk kasus yang kompleks memang dibutuhkan pengetahuan produk khusus AWS, tetapi sebagian besar konsep dasarnya juga dipakai di cloud lain maupun jaringan on-premise. Mirip seperti mempelajari bahasa pemrograman ke-N
TCP/IP adalah pengetahuan yang berguna bagi network programmer. Di kelas networking kampus, kami menangani network, subnet, routing table, protokol routing seperti RIP·OSPF·BGP, NAT, dan sebagainya dengan perangkat nyata, dan karena banyak disponsori Cisco, pada akhir semester levelnya sudah setara sertifikasi CCNA
Kami juga belajar banyak “pengetahuan produk” seperti cara kerja produk Cisco, tetapi sebagian besar sudah saya lupakan, dan konsep intinya berpindah dengan baik ke Azure, AWS, dan GCP. VPC cloud adalah padanan virtual dari jaringan nyata, sama seperti virtual machine adalah padanan dari mesin nyata
Secara khusus, NAT benar-benar membingungkan banyak orang. Lebih mendasar lagi, banyak engineer juga kesulitan dengan notasi CIDR atau bahkan TCP itu sendiri. Misalnya, mereka mengira buffer yang diberikan ke
send()dikirim sebagai satu unit, atau mengirarecv()selalu menerima sebuah “pesan” yang utuh. Perbedaan antara connection timeout dan peer reset juga sering membuat bingungMeski begitu, saya berharap pengetahuan semacam ini tidak perlu lagi dibutuhkan. IPv6 membuat jaringan begitu besar sehingga banyak kebutuhan seperti perencanaan ukuran subnet menjadi hilang. NAT boleh lenyap ke neraka beku. VPN pun kalau bisa tidak usah saya lihat lagi, cukup pakai TLS saja. Saya juga ingin menghapus firewall cloud yang memperlakukan alamat IP seperti bentuk autentikasi, beserta error menyesatkan yang ditimbulkannya. Azure sangat buruk dalam hal ini
Seperti banyak software profesional, awalnya sederhana karena kebutuhan, tetapi lama-kelamaan menjadi kompleks, dan AWS membesar dengan cepat karena daya tarik layanan infrastruktur fully managed on-demand serta sumber daya besar yang dikucurkan Amazon
Nilai dari tidak perlu menangani hardware secara langsung tetap besar, tetapi selain harga yang tercantum, jelas ada biaya berupa pengetahuan vendor-spesifik yang sulit ditinggalkan
Sebaliknya, yang ada justru segudang konsep sekali-pakai seperti “internet gateway”, “NAT gateway”, “egress only internet gateway”, dan “transit gateway”. Pada akhirnya, rasanya akan muncul satu generasi engineer yang hanya paham “cloud” tetapi tidak tahu bagaimana sebenarnya semuanya bekerja
Semua komponen yang “tidak membedakan” itu cukup diserahkan ke AWS, lalu mereka bisa fokus pada bisnis yang memang mereka kuasai
Jika mereka hanya menyediakan pengalamatan global umum dan firewall, sebagian besar kompleksitas ini akan hilang
Kita mudah lupa untuk apa internet level IP itu ada, dan masalah apa yang diselesaikan oleh arsitektur end-to-end
Apa yang diajarkan AWS sebagai networking “Well-Architected™” sebenarnya lebih mirip pemujaan kargo yang menguntungkan, dan itu berujung pada kompleksitas, labirin jaringan 10.x yang saling mirip, konflik alamat, proxy tambal sulam saat mencoba membuatnya saling berkomunikasi, penurunan keamanan nyata, dan vendor lock-in. Kompleksitas adalah musuh keamanan
Dulu pun sysadmin tidak dibayar setengah atau seperempat dari kompensasi saya, dan biasanya satu orang mengelola hardware yang cukup untuk melayani 100 developer. Artinya, overhead yang dibutuhkan agar orang lain tidak perlu mengalami perluasan cakupan kerja dan kerusakan otak seperti ini hanya sekitar 0,5%
Di AWS, secara harfiah sedang terjadi lagi kematian spesialisasi
Dan pengalamatan global serta firewall pada dasarnya juga bisa dilakukan dengan membuat VPC yang hanya punya subnet publik lalu memakai security group seperti firewall. Praktik terbaik memang subnet publik/pribadi dan NAT gateway, tetapi rasanya tidak mustahil hanya bergantung pada security group
Itu juga berada di belakang IP anycast global
Karena itu, banyak kompleksitas yang tidak perlu dalam cloud networking yang kita lihat sekarang muncul
Mind map ini tampaknya bisa disederhanakan lagi menjadi beberapa konsep jaringan saja
Dengan begitu, sebagian besar relasi dan panah akan hilang, dan konsep AWS bisa dipetakan juga ke cloud lain atau jaringan rumah.
https://news.ycombinator.com/item?id=18925350 adalah materi yang sangat bagus untuk memvisualisasikan dasar-dasarnya. Jika mulai dari apa itu jaringan, apa itu bagian dalam dan luar, model mentalnya jadi jauh lebih mudah, dan fitur AWS cukup masuk akal bahkan tanpa mengetahui semua detailnya
Pada akhirnya, ini merangkum sistem yang rumit dengan jelas dan ringkas. Ini akan jadi referensi yang saya lihat lagi saat lain kali menelusuri rimba AWS
Misalnya ada subnet di dalam persegi panjang availability zone, di luarnya ada VPC, lalu persegi panjang itu berada di dalam region. Bentuknya kurang lebih seperti ini, hanya saja digambar lebih rapi: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
Saya ingat masa-masa bersemangat di awal cloud saat networking AWS masih sederhana
Meski begitu, saya sudah tahu ini akan terjadi. Jika ingin menjadi segalanya untuk semua orang, pada akhirnya tak terhindarkan harus meniru kegilaan networking data center IPv4 legacy
Belakangan ini saya mencoba melakukan sesuatu yang secara konsep sederhana di Azure. Yaitu memastikan akun storage yang berisi backup database tidak terekspos ke internet sehingga bisa dicoba-coba sembarang orang
Saya kira cukup mengaktifkan firewall, tetapi daftar izinnya hanya bisa menerima subnet, dan itu pun harus memasukkan tiap subnet satu per satu. Tidak bisa virtual network, dan juga tidak bisa opsi “semua virtual network saya” yang di tempat lain justru tersedia
Ada juga fitur Private Endpoint, tetapi menurunkan performa dan menambah biaya. Mungkin mengubah alamat dari “public” ke “private” di pengaturan software-defined network memang sulit, jadi para peri cloud harus diberi imbalan
Tapi pada praktiknya itu pun tidak berjalan. Karena DNS harus dioverride agar klien bisa menemukannya, saya hubungkan ke domain AD, lalu layanan PaaS malah tidak bisa mengaksesnya
Akhirnya seminggu habis untuk membuat private DNS zone yang juga menambah biaya, menghubungkannya ke jaringan hub, menambahkan layanan DNS Resolver yang lagi-lagi berbiaya, lalu menyiapkan segunung aturan agar domain AD tetap berfungsi
Padahal tujuan awalnya cuma agar kalau storage key bocor, peretas Rusia tidak bisa mengakses backup. Mungkin minggu depan saya bisa memperbarui template subscription agar virtual network dengan konfigurasi DNS yang sudah diperbarui bisa dideploy ulang. Tidak idempoten? Mungkin tahun depan akan muncul sebagai pratinjau
Lalu untuk yang perlu dipublikasikan, bisa pakai public gateway atau Front Door. Saya juga tidak suka, tetapi ini memang bukan sesuatu yang sejak dulu sangat sederhana. Hanya saja sekarang developer jadi lebih banyak terekspos pada kekacauan gila networking enterprise yang dulu benar-benar wilayah tim operasi
Saya menyebut konfigurasi DNS itu sihir karena itu bagian yang tidak saya sentuh langsung. Terutama kalau memakai App Service dan beberapa subscription, Anda tidak bisa berbagi subnet, dan harus merencanakan sebelumnya agar tidak kehabisan ruang alamat IP saat memakai app slot
Yang tidak saya pahami dari Azure adalah kenapa default enterprise-nya bukan “semuanya tidak ada di internet”. Seharusnya dibuka hanya jika memang perlu diekspos ke internet. Toh untuk memublikasikannya ke internet memang dari awal perlu banyak konfigurasi seperti load balancer dan lainnya, jadi proses itu memang sudah rumit. Minimal untuk pengaturan enterprise, default-nya seharusnya berada di luar internet
Mungkin Microsoft menjual sertifikasi Azure jadi semuanya harus dibuat sulit, tetapi saya tidak mengerti kenapa pada 2023 kompleksitas ini harus dikhawatirkan bahkan dari default-nya. Sangat bisa dikustomisasi itu tidak masalah
Materi ini sangat keren. Menurut saya dokumentasi Google Cloud cukup baik dalam memperkenalkan kompleksitas seperti ini saat memang dibutuhkan, tetapi saya belum pernah melihat ikhtisar selengkap ini
Hanya saja saya harus cukup bersusah payah untuk melihat gambarnya. Di halaman itu terlalu kecil dan tidak bisa diklik, dan kalau dibuka di tab baru malah masuk ke halaman tidak berguna seperti imgur dan tetap terlihat kecil. Akhirnya saya harus mengunduh gambarnya agar bisa melihatnya dengan benar
Materi ini luar biasa. Ini menunjukkan dengan baik betapa kuatnya mind map dan diagram saat mempelajari produk cloud atau konsep lain
Saya sering memakainya saat belajar untuk sertifikasi AWS, dan meskipun saya menulis catatan panjang, saya jauh lebih mudah memahami ketika melihat layanan-layanan yang terhubung sebagai peta dibanding melihatnya sebagai rangkaian halaman. Tentu saja tiap orang punya cara belajar yang berbeda
Saya tidak begitu paham semua kritik di thread ini. Sebagian besar sistem networking yang disediakan AWS adalah hal-hal yang dipakai saat memang diperlukan
Mungkin tidak elegan, tetapi tetap menyelesaikan pekerjaan. Lagi pula, cukup banyak komponen khusus AWS yang langsung berpadanan dengan konsep networking nyata. AZ adalah cage, VPC adalah VLAN, PL kurang lebih setara dengan VPN P2P antar-akun
Sebagian besar sisanya juga hanyalah komponen networking biasa yang lazim ditemukan di lingkungan skala besar
Perusahaan tempat saya bekerja mengoperasikan jaringan global yang cukup kompleks dan terhubung ke AWS melalui DX dari berbagai PoP. Kami menggunakan semua yang ada di diagram ini dan tiap komponennya punya tujuan yang terdefinisi dengan baik
Jika diagram ini terlihat terlalu rumit, kemungkinan besar karena Anda tidak memakai semuanya, tidak memakainya sesuai tujuan yang dimaksud, atau memang bukan network engineer
Apakah ada orang yang benar-benar bisa membaca gambar ini? Bahkan di desktop saya tidak bisa melihatnya pada resolusi yang cukup terbaca
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... juga tetap berupa halaman web, dan walaupun gambarnya lebih besar, itu tidak membuatnya lebih mudah dibaca
Meski begitu, kalau disimpan setidaknya bisa berfungsi. Setelah itu, Anda butuh layar besar. Ukurannya 7,763 × 4,684 piksel
Terlihat sangat rumit. Dari tiga penyedia cloud besar, saya hanya mengenal GCP, dan di sana pun networking tidak bisa dibilang sederhana, tetapi tetap cukup intuitif dan konsisten
Akan bagus jika ada orang dengan pengalaman multi-cloud yang bisa membandingkan, berdasarkan tiga besar, seberapa mudah atau sulit pengaturan komunikasi internal dan eksternal
Ini tidak terlalu mengejutkan, karena sebagian besar juga punya padanan langsung dalam standar networking itu sendiri. Keduanya pada dasarnya hanyalah cara pandang terhadap dunia software-defined networking