WEBVTT

00:00:00.000 --> 00:00:02.320
Anda menghost-nya di satu tempat, katakanlah pusat data di Virginia.

00:00:02.960 --> 00:00:05.120
Itu berjalan lancar bagi pelanggan di New York atau Chicago.

00:00:05.560 --> 00:00:07.900
Namun bagaimana dengan seseorang di Tokyo, London, atau Sydney?

00:00:08.540 --> 00:00:10.220
Tiap kali orang tersebut menunjungi situs Anda,

00:00:10.480 --> 00:00:13.800
permintaan mereka harus melintasi samudera dan benua hanya untuk mencapai server Anda.

00:00:14.580 --> 00:00:18.320
Setiap gambar, setiap pemuatan halaman, setiap panggilan api menempuh perjalanan panjang yang sama

00:00:18.320 --> 00:00:19.580
dan penundaan itu bertambah dengan cepat.

00:00:19.900 --> 00:00:23.600
Faktanya, penelitian menunjukkan bahwa penundaan pemuatan halaman selama satu detik saja

00:00:23.600 --> 00:00:26.120
dapat mengurangi konversi dan membuat pengunjung yang frustrasi pergi.

00:00:26.120 --> 00:00:30.800
Namun begini, apa yang terjadi saat situs Anda menjadi viral atau botnet memutuskan untuk menyerang?

00:00:31.180 --> 00:00:32.660
Satu-satunya server Anda di Virginia akan kewala.

00:00:33.100 --> 00:00:34.880
Server tersebut melambat dan bahkan bisa mati total.

00:00:35.100 --> 00:00:36.100
Anda terjebak tanpa rencana cara.

00:00:36.420 --> 00:00:40.240
Anda dapat mengatasi masalah ketersediaan dengan membangun salinan situs Anda di berbagai wilayah,

00:00:40.320 --> 00:00:41.300
Tokyo, London, São Paulo.

00:00:41.640 --> 00:00:41.840
Bantu.

00:00:42.660 --> 00:00:43.780
Namun sekarang Anda punya masalah baru.

00:00:44.180 --> 00:00:46.100
Bagaimana cara Anda mengirim setiap pengunjung ke lokasi yang tepat?

00:00:46.500 --> 00:00:49.120
Anda tentu tidak ingin seseorang di Jepang tidak sengaja mengakses server asana.

00:00:49.120 --> 00:00:53.120
Anda memerlukan cara cerdas untuk mengarahkan lalu lintas dan disitulah peran Azure Front Dog.

00:00:53.120 --> 00:00:56.260
Temui polisi lalu lintas global, itulah Azure Front Door.

00:00:57.280 --> 00:00:59.440
Bayangkan Azure Front Door sebagai polisi lalu lintas global.

00:00:59.580 --> 00:01:00.700
Bukan hanya satu di persimpangan,

00:01:00.840 --> 00:01:03.340
melainkan dibuat yang ditempatkan di persimpangan utama di seluruh dunia.

00:01:04.040 --> 00:01:05.660
Setiap kali seseorang mengunjungi situs web Anda,

00:01:05.780 --> 00:01:07.720
polisi terdekat akan turun tangan dan berkata-kata,

00:01:08.200 --> 00:01:09.560
Tokoh tercepat untuk Anda di Singapura.

00:01:10.180 --> 00:01:10.940
Izinkan saya mengantar Anda.

00:01:11.220 --> 00:01:13.120
Jadi apa bedanya ini dengan load balancer biasa?

00:01:13.840 --> 00:01:15.540
Kebanyakan load balancer bekerja di layar 4,

00:01:15.540 --> 00:01:17.920
melihat alamat IP dan port untuk mengarahkan lalu lintas.

00:01:18.460 --> 00:01:19.760
Itu cukup untuk kebutuhan dasar.

00:01:19.760 --> 00:01:21.800
Namun Azure Front Door bekerja di layar 7,

00:01:21.980 --> 00:01:24.480
artinya ia memahami lalu lintas HTTP dan HTTPS.

00:01:25.440 --> 00:01:27.300
Ia dapat melihat URL yang diketik seseorang,

00:01:27.460 --> 00:01:28.520
memeriksa header browser mereka,

00:01:28.620 --> 00:01:29.900
melihat jenis konten yang diminta,

00:01:30.220 --> 00:01:32.800
dan membuat keputusan perutian cerdas berdasarkan semua itu.

00:01:33.560 --> 00:01:35.900
Alih-alih hanya mengatakan IP ini menuju ke server itu.

00:01:36.300 --> 00:01:38.760
Front Door dapat mengatakan permintaan untuk pengguna IP ini

00:01:38.760 --> 00:01:40.420
menuju ke backend AS Anda.

00:01:40.420 --> 00:01:44.160
Tapi permintaan untuk gambar ini menuju ke salinan Cech di Tokyo.

00:01:44.880 --> 00:01:47.020
Inilah yang memungkinkan hal tersebut terjadi di balik layar.

00:01:47.020 --> 00:01:50.260
Azure Front Door berjalan di jaringan global Microsoft

00:01:50.260 --> 00:01:55.520
dengan lebih dari 210 titik kehadiran di lebih dari 130 lokasi metropolitan di seluruh dunia.

00:01:56.320 --> 00:01:58.700
Anggap setiap titik kehadiran sebagai pause lalu lintas kecil,

00:01:59.040 --> 00:02:02.080
kantor lokal di setiap kota besar yang dapat menangani permintaan awal dengan cepat.

00:02:02.840 --> 00:02:04.140
Saat pengguna mengunjungi situs Anda,

00:02:04.400 --> 00:02:07.940
mereka terhubung ke gerai terdekat alih-alih harus menjangkau server asal Anda di Virginia.

00:02:08.080 --> 00:02:10.320
Gerai tersebut kemudian mengarahkan permintaan mereka

00:02:10.320 --> 00:02:12.420
melalui jaringan tuang punggung privat Microsoft ke backend Anda.

00:02:12.820 --> 00:02:14.700
Ini penting karena internet publik tidak dapat diprediksi.

00:02:14.700 --> 00:02:18.540
Lalu lintas Anda mungkin melewati belasan lompatan melalui jaringan berbeda

00:02:18.540 --> 00:02:20.940
yang masing-masing menambah latensi dan potensi kehilangan paket.

00:02:21.500 --> 00:02:22.080
Di sisi lain,

00:02:22.380 --> 00:02:24.840
tuang punggung Microsoft adalah jaringan berkecepatan tinggi privat

00:02:24.840 --> 00:02:26.640
yang menghubungkan pusat data mereka secara langsung.

00:02:27.020 --> 00:02:29.780
Jadi, begitu permintaan Anda mencapai titik keberadaan terdekat,

00:02:29.900 --> 00:02:32.200
sisa perjalanannya terjadi di jalan tol yang cepat dan Anda.

00:02:32.900 --> 00:02:35.340
Anda mendapatkan waktu muat lebih cepat, latensi lebih rendah,

00:02:35.420 --> 00:02:37.320
dan pengalaman lebih baik bagi pengguna di mana saja,

00:02:37.460 --> 00:02:38.860
baik di Tokyo, London, atau Sampaulo.

00:02:38.860 --> 00:02:43.160
Dan semua ini terjadi secara otomatis tanpa pengunjung Anda menyadarinya.

00:02:44.160 --> 00:02:46.860
Tiga lapisan ketahanan, bagaimana FD tetap aktif?

00:02:47.440 --> 00:02:48.680
Sekarang, Anda mungkin berpikir,

00:02:49.020 --> 00:02:50.800
ide polisi lalu lintas global ini terdengar hebat,

00:02:50.940 --> 00:02:52.760
tapi apa yang terjadi jika polisinya sendiri mogok?

00:02:53.520 --> 00:02:56.320
Jika Azure Front Door adalah titik masuk tunggal untuk seluruh aplikasi Anda,

00:02:56.480 --> 00:02:58.120
itu menjadi titik kegagalan tunggu besar, bukan?

00:02:58.580 --> 00:02:59.480
Microsoft memikirkan hal ini.

00:02:59.860 --> 00:03:02.060
Mereka membangun tiga lapisan ketahanan ke dalam Front Door,

00:03:02.260 --> 00:03:03.340
sehingga hampir tidak pernah mati.

00:03:03.640 --> 00:03:04.440
Ini dengan saya menjelaskannya.

00:03:04.920 --> 00:03:05.960
Lapisan pertama, Front End.

00:03:05.960 --> 00:03:09.260
Ingat 210 titik keberadaan lebih yang saya sebutkan tadi.

00:03:10.380 --> 00:03:12.240
Masing-masing adalah gerai lintas yang sebenarnya independen.

00:03:12.720 --> 00:03:16.500
POP ini berada di lebih dari 130 lokasi metropolitan di seluruh dunia,

00:03:16.680 --> 00:03:19.300
berjalan di dalam pusat data Microsoft dan fasilitas kolokasi mitra.

00:03:20.140 --> 00:03:22.520
Setiap POP menampung beberapa rak server dengan pengontrol Edge

00:03:22.520 --> 00:03:24.900
di atasnya yang berfungsi sebagai penyeimbang beban bawaan.

00:03:25.680 --> 00:03:27.060
Jika satu server di dalam POP gagal,

00:03:27.140 --> 00:03:31.040
pengontrol Edge mengalihkan lalu lintas ke server yang sehat di dalam POP yang sama.

00:03:31.140 --> 00:03:32.840
Dan jika satu POP mati total,

00:03:33.040 --> 00:03:34.820
disitulah pengalamatan IPI NKS berperan.

00:03:34.820 --> 00:03:38.540
Permintaan pengunjung Anda secara otomatis diarahkan ke POP terdekat berikutnya.

00:03:39.080 --> 00:03:40.640
Tanpa gangguan dan termaintervensi manual,

00:03:40.780 --> 00:03:41.620
semuanya terjadi begitu saja.

00:03:41.960 --> 00:03:42.720
Lapisan kedua cadangan.

00:03:43.260 --> 00:03:44.540
Tapi bagaimana jika sebuah pekwalahan?

00:03:45.000 --> 00:03:46.840
Katakanlah ada lonjakan, lalu lintas masif,

00:03:46.920 --> 00:03:48.720
atau beberapa POP di suatu wilayah yang mati sekaligus.

00:03:49.000 --> 00:03:51.040
POP yang tersisa mungkin tidak mampu menangani beban tersebut.

00:03:51.300 --> 00:03:52.720
Saat itulah lapisan cadangan turun tangan.

00:03:52.720 --> 00:03:54.700
Ini adalah kumpulan POP terpisah.

00:03:54.820 --> 00:03:57.600
Jumlahnya puluhan, bukan ratusan yang menjalankan perangkat lunak dan setektur yang sama.

00:03:58.040 --> 00:04:00.680
Semuanya hanya berada di pusat data Microsoft, bukan fasilitas mitra.

00:04:01.480 --> 00:04:03.320
Ketika POP RONN perlu mengurangi beban lalu lintas,

00:04:03.700 --> 00:04:05.320
ia mengalihkan permintaan ke lapisan cadangan ini.

00:04:05.640 --> 00:04:07.500
Cacing yang sama, perutahan yang sama, keamanan yang sama.

00:04:07.920 --> 00:04:09.320
Pengunjung Anda tidak akan pernah menyadari perbedaan.

00:04:09.660 --> 00:04:11.480
Mereka mungkin mendapatkan konten sedikit lebih lambat,

00:04:11.480 --> 00:04:14.300
tetapi mereka tetap mendapatkan lapisan ketiga perisai lalu lintas.

00:04:14.340 --> 00:04:15.260
Ini adalah pengawasnya.

00:04:15.660 --> 00:04:19.100
Anggaplah ini sebagai pusat komando global yang mengawasi seluruh jaringan front door.

00:04:19.680 --> 00:04:22.540
Ia memantau pola lalu lintas, tingkat beban, dan kesehatan di semua POP.

00:04:23.180 --> 00:04:25.200
Saat mendeteksi POP tertentu mulai kewalahan,

00:04:25.280 --> 00:04:27.420
ia tidak hanya menunggu lapisan cadangan bekerja.

00:04:27.660 --> 00:04:32.040
Ia secara proaktif mengalihkan lalu lintas dengan memperbarui resolusi DNS titik akhir front door Anda.

00:04:32.840 --> 00:04:35.180
Ia dapat beralih dari IP Any Case Global ke regional

00:04:35.180 --> 00:04:37.840
memindahkan klien ke set POP yang benar-benar berbeda.

00:04:38.300 --> 00:04:39.720
Bahkan bisa melintasi benua jika diperlukan.

00:04:39.720 --> 00:04:42.740
Perisai lalu lintas inilah yang membuat front door terasa hampir seperti sihir.

00:04:43.160 --> 00:04:45.140
Ia terus melakukan optimalisasi di balik layar,

00:04:45.280 --> 00:04:46.960
menyesuaikan router sebelum masalah terjadi.

00:04:47.560 --> 00:04:48.840
Sekarang saya perlu menyebutkan suatu risiko.

00:04:49.200 --> 00:04:52.120
Pada Oktober 2025, Azure front door mengalami gangguan yang signifikan.

00:04:52.460 --> 00:04:54.700
Perubahan konfigurasi melewati validasi keselamatan

00:04:54.700 --> 00:04:57.700
dan menyebabkan masalah luas di Microsoft 365, Xbox Live,

00:04:58.020 --> 00:04:59.360
dan ribuan situs web pelanggan.

00:04:59.880 --> 00:05:00.860
Microsoft belajar dari Hot Reset.

00:05:01.360 --> 00:05:04.160
Mereka menghapus semua pemprosesan asinkron dari alur konfigurasi.

00:05:04.720 --> 00:05:06.880
Sekarang setiap jalur kode diuji selama peluncuran.

00:05:06.880 --> 00:05:09.960
Mereka mengurangi waktu pemulihan rollback dari 4 jam menjadi 1 jam

00:05:09.960 --> 00:05:12.020
dan nargetkan 10 menit pada Maret 2026.

00:05:12.760 --> 00:05:14.620
Mereka juga memperkenalkan segmentasi mikrosel

00:05:14.620 --> 00:05:17.740
untuk membatasi dampak di masa depan hingga kurang dari 1% penyewa.

00:05:18.100 --> 00:05:19.800
Intinya, tidak ada sistem yang sempurna.

00:05:19.980 --> 00:05:21.520
Tetapi arsitektur tiga lapis front door

00:05:21.520 --> 00:05:23.320
dilancang untuk bertahan dari gangguan regional,

00:05:23.560 --> 00:05:25.760
lonjakan lalu lintas, dan bahkan beberapa kesalahan konfigurasi.

00:05:26.160 --> 00:05:28.200
Untuk sebagian besar aplikasi itu sudah lebih dari cukup.

00:05:28.200 --> 00:05:29.680
Untuk sistem yang benar-benar sangat penting,

00:05:29.940 --> 00:05:32.260
Anda dapat melapisi Azure Traffic Manager di depan front door

00:05:32.260 --> 00:05:33.200
sebagai jalur darurat.

00:05:33.200 --> 00:05:35.080
Tetapi itu adalah topik lanjutan untuk lain waktu.

00:05:35.800 --> 00:05:38.120
Cara mengarahkan lalu lintas perutean dan grup asal origin group.

00:05:38.440 --> 00:05:40.080
Jadi, kita punya polisi lalu lintas global

00:05:40.080 --> 00:05:42.180
dengan lebih dari 210 post dan tiga lapisan cadangan

00:05:42.180 --> 00:05:43.740
tetapi bagaimana ia benar-benar memutuskan

00:05:43.740 --> 00:05:45.040
kemana harus mengirim setiap pengunjung.

00:05:45.780 --> 00:05:46.900
Disitulah grup asal berperang.

00:05:47.360 --> 00:05:49.860
Grup asal pada dasarnya adalah kumpulan server back-end Anda.

00:05:50.580 --> 00:05:52.100
Anggaplah ini sebagai daftar toko Anda,

00:05:52.340 --> 00:05:54.700
tempat sebenarnya di mana situs web atau aplikasi Anda berjalan.

00:05:55.200 --> 00:05:57.240
Anda mungkin memiliki satu server di Amerika Utara,

00:05:57.320 --> 00:05:58.300
satu di Eropa, dan satu di Asia.

00:05:58.680 --> 00:05:59.940
Semuanya masuk ke dalam grup asal yang sama.

00:05:59.940 --> 00:06:02.700
Sekarang front door tidak begitu saja mengirim lalu lintas ke semuanya.

00:06:03.060 --> 00:06:04.440
Ia terus menulis memeliksa apakah mereka akut.

00:06:04.900 --> 00:06:06.000
Itu disebut keperiksaan kesehatan Anda.

00:06:06.440 --> 00:06:08.440
Setiap beberapa detik, setiap POP front door

00:06:08.440 --> 00:06:11.020
melakukan ping ke server Anda dengan mengakses jalur tertentu,

00:06:11.300 --> 00:06:12.380
biasanya akar situs Anda,

00:06:12.620 --> 00:06:14.780
atau titik akhir kesehatan khusus seperti player health.

00:06:15.460 --> 00:06:17.700
Jika server tidak merespons atau memberikan kode kesalahan,

00:06:17.960 --> 00:06:19.280
front door menandainya sebagai tidak sehat

00:06:19.280 --> 00:06:20.760
dan berhenti mengirim lalu lintas ke sana.

00:06:21.380 --> 00:06:23.060
Ini seperti polisi lalu lintas yang meriksa

00:06:23.060 --> 00:06:25.040
apakah toko benar-benar buka sebelum membiarkan pelanggan masuk.

00:06:25.040 --> 00:06:28.000
Namun setelah Anda memiliki beberapa server yang sehat,

00:06:28.100 --> 00:06:30.020
pertanyaannya adalah mana yang harus menerima pengunjung.

00:06:31.220 --> 00:06:32.720
Front door menggunakan tiga faktor

00:06:32.720 --> 00:06:34.920
untuk memutuskan prioritas, latensi, dan bobot.

00:06:35.420 --> 00:06:37.220
Dan ketiganya bekerja bersama dalam urutan itu.

00:06:37.480 --> 00:06:38.420
Pertama adalah prioritas.

00:06:38.840 --> 00:06:40.600
Anda dapat menetapkan satu server sebagai utama

00:06:40.600 --> 00:06:41.520
dan lainnya sebagai cadangan.

00:06:41.980 --> 00:06:43.360
Atur yang utama ke prioritas satu

00:06:43.360 --> 00:06:44.700
dan cadangan ke prioritas dua.

00:06:45.200 --> 00:06:45.960
Dalam kondisi normal,

00:06:46.160 --> 00:06:47.520
semua lalu lintas diarahkan ke server utama.

00:06:47.880 --> 00:06:48.860
Jika server utama mati,

00:06:48.860 --> 00:06:49.980
lalu lintas beralih ke cadangan.

00:06:50.400 --> 00:06:50.860
Sederhana bukan?

00:06:51.240 --> 00:06:53.020
Ini sangat cocok untuk pengaturan aktif pasif

00:06:53.020 --> 00:06:54.540
di mana Anda ingin satu wilayah menangani semuanya

00:06:54.540 --> 00:06:55.700
kecuali jika terjadi kegagalan.

00:06:56.080 --> 00:06:57.300
Tapi bagaimana jika Anda ingin kedua server?

00:06:57.780 --> 00:06:58.840
Disitulah latensi berperang.

00:06:59.180 --> 00:07:01.240
Jika beberapa server memiliki prioritas yang sama,

00:07:01.360 --> 00:07:02.680
front door mengirim lalu lintas ke server

00:07:02.680 --> 00:07:03.560
dengan latensi terendah,

00:07:03.680 --> 00:07:05.740
yakni waktu respons tercepat dari lokasi pengunjung.

00:07:06.720 --> 00:07:08.660
Jadi pengguna di London diarahkan ke server Eropa Anda,

00:07:08.780 --> 00:07:10.880
sementara pengguna di Tokyo diarahkan ke server Asia.

00:07:11.840 --> 00:07:13.180
Ada juga pengaturan sensitivitas.

00:07:13.400 --> 00:07:14.720
Secara default, 50 milidetik.

00:07:15.400 --> 00:07:18.160
Jika dua server memiliki selisih waktu 50 milidetik satu sama lain,

00:07:18.160 --> 00:07:19.600
front door menganggap keduanya sama cepat.

00:07:20.140 --> 00:07:21.580
Itu mencegah perpindahan terus-menerus

00:07:21.580 --> 00:07:23.640
antar server yang kecepatannya pada dasarnya sama.

00:07:24.080 --> 00:07:25.020
Dan saat latensi setara,

00:07:25.180 --> 00:07:26.020
disitulah bobot berperang.

00:07:26.460 --> 00:07:27.480
Anda dapat menetapkan bobot

00:07:27.480 --> 00:07:28.980
untuk membagi lalu lintas antar server.

00:07:29.560 --> 00:07:31.280
Katakanlah Anda ingin menguji versi baru aplikasinya.

00:07:31.780 --> 00:07:33.140
Anda bisa memberi server saat ini

00:07:33.140 --> 00:07:34.700
bobot 90 dan yang baru bobot 10.

00:07:35.180 --> 00:07:36.840
Itu berarti kira-kira 9 dari 10 pengunjung

00:07:36.840 --> 00:07:37.720
akan menuju versi lama

00:07:37.720 --> 00:07:39.320
dan 1 dari 10 akan menuju versi baru.

00:07:39.680 --> 00:07:41.120
Ini sempurna untuk peluncuran bertahap,

00:07:41.360 --> 00:07:41.960
pengujian AB,

00:07:42.200 --> 00:07:43.240
atau sekadar menyeimbangkan beban

00:07:43.240 --> 00:07:44.780
di seluruh server dengan kapasitas berbeda.

00:07:45.580 --> 00:07:46.180
Inilah hal yang penting.

00:07:46.580 --> 00:07:48.160
Semua ini terjadi secara otomatis.

00:07:48.160 --> 00:07:50.140
Anda mengonfigurasi grup origin sekali

00:07:50.140 --> 00:07:51.520
dan front door menangani sisanya.

00:07:51.960 --> 00:07:53.320
Layanan ini memeriksa server Anda

00:07:53.320 --> 00:07:54.040
mengkur latensi,

00:07:54.160 --> 00:07:55.000
menghormati prioritas,

00:07:55.300 --> 00:07:56.860
dan mendistribusikan lalu lintas berdasarkan bobot.

00:07:57.340 --> 00:07:58.600
Dan itu semua dilakukan di Edge

00:07:58.600 --> 00:08:00.320
sebelum permintaan mencapai backend Anda.

00:08:00.960 --> 00:08:02.580
Artinya server Anda tidak perlu mencari tahu

00:08:02.580 --> 00:08:03.800
dari mana lalu lintas berasal

00:08:03.800 --> 00:08:04.860
atau bagaimana cara merotakan.

00:08:05.240 --> 00:08:06.160
Mereka hanya melayani konten.

00:08:07.040 --> 00:08:08.340
Kalianan di Edge, WF, dan seterusnya.

00:08:08.820 --> 00:08:10.000
Jadi sekarang mari kita bicara tentang kan.

00:08:10.360 --> 00:08:12.140
Karena front door berada di ujung jaringan Microsoft,

00:08:12.320 --> 00:08:13.260
ini adalah tempat sempurna

00:08:13.260 --> 00:08:14.280
untuk menghentikan serangan

00:08:14.280 --> 00:08:16.020
sebelum mencapai server Anda.

00:08:16.020 --> 00:08:18.640
Anggaplah ini sebagai pos pemeriksaan keamanan

00:08:18.640 --> 00:08:19.380
di pintu masuk gedung.

00:08:20.000 --> 00:08:20.680
Siapapun yang ingin masuk

00:08:20.680 --> 00:08:22.040
harus melalui tempat itu terlebih dahulu.

00:08:22.340 --> 00:08:23.380
Pemeriksaan tersebut disebut

00:08:23.380 --> 00:08:25.440
Web Application Firewall atau WAF

00:08:25.440 --> 00:08:27.320
yang terintegrasi di front door standar

00:08:27.320 --> 00:08:27.960
maupun premium.

00:08:28.560 --> 00:08:30.440
WAF secara otomatis memblokir serangan web yang ujung.

00:08:31.200 --> 00:08:32.280
Seperti injeksi SQL,

00:08:32.640 --> 00:08:33.880
saat penyerang menyisipkan perintah

00:08:33.880 --> 00:08:35.660
basis data berbahaya ke kolom formulir

00:08:35.660 --> 00:08:36.820
atau cross-head scripting

00:08:36.820 --> 00:08:38.700
saat mereka menyuntikkan skrip ke halaman Anda

00:08:38.700 --> 00:08:39.820
atau serangan DDoS

00:08:39.820 --> 00:08:41.700
saat mereka mencoba membanjiri server Anda

00:08:41.700 --> 00:08:42.440
dengan trafik.

00:08:43.280 --> 00:08:44.660
WAF menangkap semua ini di Edge

00:08:44.660 --> 00:08:46.880
dan menolaknya sebelum origin Anda melihat apapun.

00:08:47.660 --> 00:08:48.640
Selain perlindungan otomatis,

00:08:48.760 --> 00:08:50.100
Anda juga dapat membuat aturan khusus.

00:08:50.440 --> 00:08:50.760
Misalnya,

00:08:51.120 --> 00:08:52.260
jika situs Anda hanya ditujukan

00:08:52.260 --> 00:08:53.100
untuk pelanggan di Eropa,

00:08:53.320 --> 00:08:54.360
Anda dapat memblokir trafik

00:08:54.360 --> 00:08:55.420
dari wilayah lain sepenuhnya.

00:08:55.940 --> 00:08:57.660
Atau mungkin Anda melihat rentang IP tertentu

00:08:57.660 --> 00:08:59.040
yang terus mencoba masuk ke situs Anda,

00:08:59.260 --> 00:09:00.180
Anda pun dapat memblokirnya.

00:09:00.640 --> 00:09:01.640
Anda juga dapat memfilter

00:09:01.640 --> 00:09:02.800
berdasarkan header permintaan,

00:09:02.860 --> 00:09:03.300
pola URL,

00:09:03.440 --> 00:09:04.680
atau bahkan browser yang digunakan seseorang.

00:09:05.080 --> 00:09:06.500
Memberikan kontrol yang sangat spesifik

00:09:06.500 --> 00:09:07.460
mengenai siapa yang dapat masuk

00:09:07.460 --> 00:09:08.040
dan siapa yang tidak.

00:09:08.460 --> 00:09:09.680
Di sini ada tingkat harga berperan penting.

00:09:09.680 --> 00:09:11.920
Standar memberi Anda aturan WAF khusus

00:09:11.920 --> 00:09:13.280
untuk menentukan apa yang akan diblokir

00:09:13.280 --> 00:09:13.860
dan diizinkan.

00:09:14.640 --> 00:09:15.860
Premium melangkah lebih jauh

00:09:15.860 --> 00:09:17.640
dengan menambahkan kumpulan aturan terkelola

00:09:17.640 --> 00:09:19.620
yang didukung oleh intelijen ancaman Microsoft

00:09:19.620 --> 00:09:22.080
yang terus diperbarui berdasarkan pola serangan nyatai

00:09:22.080 --> 00:09:23.740
yang dilihat Microsoft di seluruh jaringannya.

00:09:24.660 --> 00:09:26.120
Premium juga mencakup perlindungan bot

00:09:26.120 --> 00:09:27.020
yang secara otomatis

00:09:27.020 --> 00:09:28.120
memblokir scriper otomatis,

00:09:28.200 --> 00:09:29.940
credential, staffer, dan bot lainnya.

00:09:30.520 --> 00:09:32.100
Dan fitur ini menambahkan dukungan private link

00:09:32.100 --> 00:09:33.500
yang mungkinkan Anda terhubung ke origin

00:09:33.500 --> 00:09:34.640
melalui koneksi jaringan privak,

00:09:34.740 --> 00:09:35.440
bukan internet publik.

00:09:35.900 --> 00:09:37.420
Itu berarti server backend Anda dapat

00:09:37.420 --> 00:09:39.360
disembunyikan sepenuhnya dari dunia luar.

00:09:40.000 --> 00:09:41.140
Hanya front door yang dapat menjangkau-nya.

00:09:41.580 --> 00:09:42.900
Ini merupakan hal penting untuk keamanan.

00:09:43.300 --> 00:09:44.780
Banyak serangan tidak menarketkan front door.

00:09:45.680 --> 00:09:46.640
Mereka mencoba mencari pintu belah.

00:09:47.660 --> 00:09:48.880
Jika server origin Anda

00:09:48.880 --> 00:09:49.860
memiliki alamat IP publik,

00:09:50.000 --> 00:09:51.480
penyerang dapat membeksanya secara langsung

00:09:51.480 --> 00:09:53.300
dan melewati semua perlindungan front door Anda.

00:09:54.080 --> 00:09:54.820
Dengan private link,

00:09:54.980 --> 00:09:56.020
hal itu tidak mungkin dilakukan

00:09:56.020 --> 00:09:57.720
karena origin tidak memiliki titik akhir publik

00:09:57.720 --> 00:09:59.120
dan hanya dapat diakses melalui front door.

00:09:59.520 --> 00:10:01.280
Jadi meskipun seorang menemukan IP server Anda,

00:10:01.400 --> 00:10:02.280
mereka tidak akan bisa menjangkau.

00:10:02.600 --> 00:10:03.920
Hasilnya adalah pertanda mendalam.

00:10:04.520 --> 00:10:06.140
WAF memblokir serangan di lapisan aplikasi.

00:10:06.140 --> 00:10:08.200
Aturan khusus menangani kebutuhan spesifik Anda.

00:10:08.700 --> 00:10:10.200
Perlindungan buat menghentikan ancaman otomatis.

00:10:10.600 --> 00:10:12.440
Dan private link menjaga origin Anda tetap di data link.

00:10:13.160 --> 00:10:14.280
Semua ini terjadi di ads

00:10:14.280 --> 00:10:16.240
sebelum trafik mencapai infrastruktur Anda

00:10:16.240 --> 00:10:18.160
sehingga server Anda tetap fokus melayani konten

00:10:18.160 --> 00:10:19.120
bukan menangkis serangan.

00:10:20.140 --> 00:10:21.720
Cacing membuat segala yang menjadi lebih cepat.

00:10:22.400 --> 00:10:24.220
Jadi kita telah membahas perlutaan dan keamanan

00:10:24.220 --> 00:10:26.500
tetapi ada fitur lain yang membuat front door sangat berguna

00:10:26.500 --> 00:10:27.080
yaitu cacing.

00:10:27.880 --> 00:10:28.340
Begini denya.

00:10:28.720 --> 00:10:30.680
Banyak konten situs web Anda tidak sering berubah.

00:10:31.280 --> 00:10:33.800
Gambar, file CSS, pustaka JavaScript, foto produk,

00:10:33.800 --> 00:10:35.800
bahkan mungkin beberapa halaman HTML.

00:10:36.140 --> 00:10:39.600
Jika setiap pengunjung harus mengambil data dari server origin Anda.

00:10:39.760 --> 00:10:41.080
Anda membuang waktu dan bandwidth

00:10:41.080 --> 00:10:43.820
karena server harus memproses permintaan yang sama berulang kali.

00:10:44.260 --> 00:10:46.280
Mengirimkan byte yang sama melalui internet setiap saat.

00:10:47.080 --> 00:10:48.220
Cacing mengatasi hal tersebut

00:10:48.220 --> 00:10:50.040
dengan menyimpan salinan konten statis di PP8.

00:10:50.500 --> 00:10:52.080
Lain kali seseorang meminta file yang sama,

00:10:52.200 --> 00:10:53.700
POP akan menyajikannya secara instan

00:10:53.700 --> 00:10:54.880
tanpa perlu menghubungi originan.

00:10:55.320 --> 00:10:57.740
Ini seperti memiliki gudang kecil di samping setiap gerbang toh.

00:10:58.480 --> 00:11:00.460
Alih-alih menyuruh setiap pelanggan kembali ke pabrik utama,

00:11:00.640 --> 00:11:02.120
Anda cukup memberikan apa yang sudah ada di rang.

00:11:02.520 --> 00:11:03.920
Perbedaan performanya sangat dramatis.

00:11:03.920 --> 00:11:06.040
Bukan perjalanan pelang pergi melintasi samudera.

00:11:06.240 --> 00:11:07.880
Respons datang dari server di kota yang sama.

00:11:08.640 --> 00:11:09.780
Dalam mili detik bukan detik.

00:11:10.340 --> 00:11:11.980
Dan server origin Anda menjadi lebih ringan

00:11:11.980 --> 00:11:13.540
karena menangani lebih sedikit permintaan

00:11:13.540 --> 00:11:15.640
dan bisa fokus pada hal dinamis yang memang perlu diproses.

00:11:16.100 --> 00:11:17.760
Namun cacing tidak otomatis berlaku untuk semua.

00:11:18.320 --> 00:11:20.240
Anda mengontrol apa yang dicecen berapa lama durasinya.

00:11:20.240 --> 00:11:24.180
Front Door menghargai header catch control standar dari origin Anda

00:11:24.180 --> 00:11:25.800
seperti Max H atau S-Max H

00:11:25.800 --> 00:11:28.560
dan Anda juga dapat mengonfigurasi aturan catching secara langsung

00:11:28.560 --> 00:11:30.460
menimpa header origin jika diperlukan.

00:11:31.020 --> 00:11:32.100
Saat Anda memperbarui konten,

00:11:32.260 --> 00:11:34.040
Anda dapat menghapus chassis dan meminta Front Door

00:11:34.040 --> 00:11:35.720
untuk membuang salinan lama serta mengambil angbak.

00:11:36.140 --> 00:11:38.420
Hal ini penting untuk peluncuran produk atau perubahan harga

00:11:38.420 --> 00:11:40.460
di mana versi baru harus segera terlihat.

00:11:40.900 --> 00:11:41.320
Begini tinggal.

00:11:41.840 --> 00:11:43.540
Front Door bukan hanya untuk konten statis.

00:11:43.920 --> 00:11:45.480
Bahkan untuk konten dinamis seperti API,

00:11:45.980 --> 00:11:47.180
halaman yang dipersonalisasi,

00:11:47.180 --> 00:11:48.220
atau keranjang belanja,

00:11:48.440 --> 00:11:49.520
pengiriman tetap dipercepat

00:11:49.520 --> 00:11:51.660
karena setelah permintaan mencapai POP terdekat,

00:11:51.800 --> 00:11:53.640
ia akan melintasi backbone pribadi Microsoft,

00:11:53.860 --> 00:11:54.680
bukan internet publik.

00:11:55.680 --> 00:11:57.100
Backbone pribadi tersebut lebih cepat

00:11:57.100 --> 00:11:58.560
dan lebih andal daripada web terbuka.

00:11:59.140 --> 00:12:00.320
Jadi permintaan yang tidak dicecep pun

00:12:00.320 --> 00:12:01.500
mendapatkan peringkatan bercepatan.

00:12:01.820 --> 00:12:03.100
Ini adalah salah satu perbedaan utama

00:12:03.100 --> 00:12:04.920
antara Front Door dan CDN tradisional.

00:12:05.480 --> 00:12:07.620
CDN hanya melakukan cacing pada konten statis, itu saja.

00:12:08.080 --> 00:12:09.760
Front Door melakukan cacing pada konten statis

00:12:09.760 --> 00:12:10.800
dan mempercepat semua konten lainnya.

00:12:11.360 --> 00:12:12.340
Ini adalah penawaran lu dalam sana.

00:12:12.980 --> 00:12:14.840
Tingkat harga, mana yang harus dipilih?

00:12:15.440 --> 00:12:16.460
Baiklah, mari bicara soal uang

00:12:16.460 --> 00:12:17.560
karena itu adalah pertanyaan besar.

00:12:18.040 --> 00:12:19.600
Berapa biayanya dan tingkat malah

00:12:19.600 --> 00:12:20.600
yang sebenarnya harus Anda pilih?

00:12:20.960 --> 00:12:22.000
Sebelum kita masukkan ke angkanya,

00:12:22.100 --> 00:12:22.820
inilah mengapa hal yang penting.

00:12:23.360 --> 00:12:25.400
Tingkat yang Anda pilih tidak hanya mengaruhi harga,

00:12:25.580 --> 00:12:26.820
tetapi juga menentukan keamanan

00:12:26.820 --> 00:12:27.680
dan fitur yang tersedia

00:12:27.680 --> 00:12:28.940
untuk melindungi aplikasi Anda.

00:12:29.620 --> 00:12:31.180
Azure Front Door hadir dalam tiga versi.

00:12:31.580 --> 00:12:32.400
Klasik adalah versi lama.

00:12:32.660 --> 00:12:33.580
Versi ini masih berfungsi,

00:12:33.720 --> 00:12:34.720
tetapi Microsoft menyarankan

00:12:34.720 --> 00:12:36.080
untuk tidak menggunakannya untuk proyekan.

00:12:36.580 --> 00:12:37.560
Klasik akan segera dihentikan.

00:12:38.160 --> 00:12:39.880
Tidak ada sumber daya baru setelah 2025

00:12:39.880 --> 00:12:42.200
dan akan dipensiunkan sepenuhnya pada 2027.

00:12:43.000 --> 00:12:44.360
Jadi jika Anda mulai dari awal,

00:12:44.360 --> 00:12:46.020
pilihan Anda adalah standar atau premium.

00:12:46.460 --> 00:12:47.320
Berikut ada sumber daya sederhana.

00:12:47.820 --> 00:12:50.340
Standar mengenakan biaya dasar 35 per bulan.

00:12:51.120 --> 00:12:53.180
Premium mengenakan biaya 330 harga per bulan.

00:12:53.520 --> 00:12:54.280
Itu lompatan yang besar,

00:12:54.380 --> 00:12:55.060
tapi inilah yang menarik.

00:12:55.760 --> 00:12:57.940
Tarif transfer data per gigabyte identik

00:12:57.940 --> 00:12:59.120
untuk kedua tingkat.

00:12:59.820 --> 00:13:01.040
Di Amerika Utara dan Eropa,

00:13:01.180 --> 00:13:02.120
lalu lintas keluar mencapai

00:13:02.120 --> 00:13:03.740
sekitar 8,25 sen per gigabyte

00:13:03.740 --> 00:13:04.780
untuk 10 terabyte pertama.

00:13:05.240 --> 00:13:06.320
Transfer dari edge ke orijin

00:13:06.320 --> 00:13:07.560
adalah sekitar 2 sen per gigabyte.

00:13:07.880 --> 00:13:08.660
Harganya sama untuk kedua.

00:13:08.860 --> 00:13:10.100
Jadi apa yang Anda dapatkan

00:13:10.100 --> 00:13:11.140
dengan tambahan 300 hal itu?

00:13:11.880 --> 00:13:12.080
Itu.

00:13:12.080 --> 00:13:14.660
Premium menambahkan aturan WF terkelola

00:13:14.660 --> 00:13:16.580
yang didukung oleh intelijen ancaman Microsoft,

00:13:16.820 --> 00:13:18.220
aturan yang diperbarui secara otomatis

00:13:18.220 --> 00:13:19.440
berdasarkan pola serangan nyata.

00:13:20.400 --> 00:13:21.820
Anda juga mendapatkan perlindungan bot,

00:13:21.980 --> 00:13:22.640
dukungan private link

00:13:22.640 --> 00:13:23.940
agar orijin Anda tetap tersembunyi

00:13:23.940 --> 00:13:24.760
dari internet publik

00:13:24.760 --> 00:13:26.220
dan analisis keamanan yang lebih dalam.

00:13:26.880 --> 00:13:28.040
Standar memberi Anda penyembang

00:13:28.040 --> 00:13:28.700
beban global,

00:13:28.880 --> 00:13:29.220
caching,

00:13:29.400 --> 00:13:30.260
akselerasi dinamis,

00:13:30.420 --> 00:13:31.380
dan aturan WF custom.

00:13:32.140 --> 00:13:33.780
Anda dapat memblokir rentang IP negara

00:13:33.780 --> 00:13:34.620
atau pola permintaan.

00:13:34.620 --> 00:13:35.980
Anda hanya tidak mendapatkan

00:13:35.980 --> 00:13:37.240
rangkaian aturan terkelola atau private.

00:13:37.640 --> 00:13:38.820
Biaya permintanya pun berbeda.

00:13:39.300 --> 00:13:40.340
Standar mengenakan biaya

00:13:40.340 --> 00:13:42.140
sekitar 9 cent per 10 ribu permintaan

00:13:42.140 --> 00:13:43.420
untuk 290 juta bertang.

00:13:43.540 --> 00:13:44.420
Premium mengenakan biaya

00:13:44.420 --> 00:13:45.760
sekitar 15 cent per 10 ribu.

00:13:45.840 --> 00:13:46.360
Dalam skala besar,

00:13:46.440 --> 00:13:47.180
perbedaan itu akan terhasil.

00:13:47.400 --> 00:13:48.420
Jadi bagaimana cara memilih?

00:13:48.480 --> 00:13:49.260
Aturan praktis dari saya.

00:13:49.660 --> 00:13:50.880
Jika Anda menjalankan situs web

00:13:50.880 --> 00:13:51.740
atau API standar

00:13:51.740 --> 00:13:53.000
yang membutuhkan kinerja global

00:13:53.000 --> 00:13:53.840
dan keamanan dasar,

00:13:54.000 --> 00:13:54.860
mulailah dengan standar.

00:13:55.320 --> 00:13:56.780
Biaya dasar 35 terjangkau

00:13:56.780 --> 00:13:57.760
dan aturan WF custom

00:13:57.760 --> 00:13:58.660
menangani sebagian besar

00:13:58.660 --> 00:13:59.340
ancaman umum.

00:14:00.060 --> 00:14:01.740
Anda selalu bisa meningkatkan versi nanti

00:14:01.740 --> 00:14:02.880
jika kebutuhan keamanan Anda bertang.

00:14:02.880 --> 00:14:04.520
Jika Anda berada di industri

00:14:04.520 --> 00:14:05.800
teregulasi kesehatan,

00:14:05.900 --> 00:14:06.760
keuangan pemerintah

00:14:06.760 --> 00:14:08.540
atau menangani data pelanggan yang sensitif,

00:14:08.900 --> 00:14:10.340
premium sepadan dengan biaya tambahannya.

00:14:11.040 --> 00:14:11.820
Aturan WF terkelola

00:14:11.820 --> 00:14:12.760
mendeteksi ancaman yang mungkin

00:14:12.760 --> 00:14:13.980
tidak terpikirkan oleh Anda untuk di-block.

00:14:14.300 --> 00:14:15.020
Private link menjaga

00:14:15.020 --> 00:14:16.180
orijin Anda tetap tak terlihat

00:14:16.180 --> 00:14:16.980
dan perlindungan bot

00:14:16.980 --> 00:14:18.080
menghentikan serangan otomatis

00:14:18.080 --> 00:14:19.080
yang tidak terdeteksi oleh Anda.

00:14:19.480 --> 00:14:20.300
Satu hal terakhir,

00:14:20.680 --> 00:14:22.100
jika Anda hanya menyajikan konten statis

00:14:22.100 --> 00:14:23.120
dan tidak memerlukan fitur

00:14:23.120 --> 00:14:24.020
perutean atau keamanan,

00:14:24.140 --> 00:14:25.360
CDN tradisional mungkin lebih murah.

00:14:25.860 --> 00:14:26.960
Azure CDN dari Microsoft

00:14:26.960 --> 00:14:27.500
masih ada

00:14:27.500 --> 00:14:29.180
dan untuk pengiriman statis murni

00:14:29.180 --> 00:14:30.340
seringkali lebih hemat biaya.

00:14:31.020 --> 00:14:32.040
Namun, untuk sebagian besar

00:14:32.040 --> 00:14:33.000
aplikasi dunia nyata

00:14:33.000 --> 00:14:33.980
di mana Anda memerlukan

00:14:33.980 --> 00:14:34.820
perutean, keamanan,

00:14:34.900 --> 00:14:35.880
cacing, dan akselerasi,

00:14:36.160 --> 00:14:36.880
Front Door Standard adalah

00:14:36.880 --> 00:14:37.540
pilihan yang tepat.

00:14:38.640 --> 00:14:39.700
Singkatnya, mari kita lihat

00:14:39.700 --> 00:14:40.600
contoh dunia nyata.

00:14:41.220 --> 00:14:42.120
Izinkan saya memandu Anda

00:14:42.120 --> 00:14:43.160
melalui skenario dunia nyata

00:14:43.160 --> 00:14:43.920
agar Anda bisa melihat

00:14:43.920 --> 00:14:44.720
bagaimana semua bagian ini

00:14:44.720 --> 00:14:45.260
bekerja bersama.

00:14:45.880 --> 00:14:46.680
Bayangkan Anda menjalankan

00:14:46.680 --> 00:14:47.180
situs e-commerce.

00:14:47.580 --> 00:14:48.860
Anda memiliki server di tiga wilayah,

00:14:48.960 --> 00:14:50.140
Amerika Utara, Eropa, dan Asia.

00:14:50.480 --> 00:14:51.560
Pelanggan Anda ada di mana-mana,

00:14:51.840 --> 00:14:52.640
dari Jepang hingga Brazil

00:14:52.640 --> 00:14:53.400
sampai Afrika Selatan.

00:14:53.940 --> 00:14:54.700
Tanpa Front Door,

00:14:54.700 --> 00:14:55.560
pelanggan di Tokyo

00:14:55.560 --> 00:14:56.280
terhubung langsung

00:14:56.280 --> 00:14:57.860
ke server Anda di AS.

00:14:58.580 --> 00:14:59.180
Setiap gambar,

00:14:59.240 --> 00:15:00.400
halaman produk dan permintaan

00:15:00.400 --> 00:15:01.280
check-out harus melintasi

00:15:01.280 --> 00:15:01.940
samudera Pasifik.

00:15:02.320 --> 00:15:02.720
Itu lambat.

00:15:03.120 --> 00:15:04.260
Dan jika server AS Anda mati,

00:15:04.340 --> 00:15:04.960
pelanggan itu hanya akan

00:15:04.960 --> 00:15:05.760
melihat pesan kesalahan.

00:15:06.020 --> 00:15:06.820
Sekarang tambahkan Front Door.

00:15:07.300 --> 00:15:07.960
Pelanggan di Tokyo

00:15:07.960 --> 00:15:08.720
membuka situs Anda.

00:15:09.480 --> 00:15:10.360
Browser mereka mengakses

00:15:10.360 --> 00:15:11.360
lokasi Azure terdekat

00:15:11.360 --> 00:15:12.020
sebuah saja Tokyo.

00:15:12.640 --> 00:15:13.400
Lokasi itu memeriksa

00:15:13.400 --> 00:15:14.580
kesehatan ketiga server Anda.

00:15:14.740 --> 00:15:15.180
Semuanya sehat.

00:15:15.580 --> 00:15:16.360
Lokasi itu mengukur retention.

00:15:16.840 --> 00:15:17.660
Server Asia merespons

00:15:17.660 --> 00:15:18.180
paling cepat,

00:15:18.600 --> 00:15:19.760
jadi permintaan diarahkan ke sana

00:15:19.760 --> 00:15:20.340
melalui background

00:15:20.340 --> 00:15:21.240
pribadi Microsoft.

00:15:21.240 --> 00:15:22.440
Halaman dimuat dalam waktu

00:15:22.440 --> 00:15:23.700
kurang dari 1.5-3 detik.

00:15:24.060 --> 00:15:25.380
Sekarang bayangkan server Asia

00:15:25.380 --> 00:15:26.580
kewalahan saat flash sale.

00:15:27.120 --> 00:15:28.080
Probe kesehatan Front Door

00:15:28.080 --> 00:15:29.580
mendeteksi peningkatan latensi.

00:15:30.300 --> 00:15:31.160
Sistem mulai mengalihkan

00:15:31.160 --> 00:15:32.400
lalu lintas ke server Eropa

00:15:32.400 --> 00:15:33.420
opsi terbaik berikutnya.

00:15:34.300 --> 00:15:35.200
Pelanggan tetap mendapatkan

00:15:35.200 --> 00:15:35.880
pengalaman cepat.

00:15:36.020 --> 00:15:37.160
Mungkin tidak secepat server Asia

00:15:37.160 --> 00:15:38.120
tapi tetap lebih baik

00:15:38.120 --> 00:15:39.520
daripada akses ke AS.

00:15:40.440 --> 00:15:41.440
Seluruh failover terjadi

00:15:41.440 --> 00:15:42.060
secara otomatis

00:15:42.060 --> 00:15:42.860
tanpa perlu mengubah

00:15:42.860 --> 00:15:43.700
konfigurasi apapun.

00:15:44.120 --> 00:15:44.560
Sementara itu

00:15:44.560 --> 00:15:45.400
WAF berjalan di AID.

00:15:45.620 --> 00:15:46.580
WAF memblokir upaya

00:15:46.580 --> 00:15:47.640
injeksi SQL dari botnet

00:15:47.640 --> 00:15:48.740
yang memiksa formula pembayaran.

00:15:49.160 --> 00:15:50.280
WAF memblokir lalu lintas

00:15:50.280 --> 00:15:51.240
dari rentang IP berbayang

00:15:51.240 --> 00:15:51.740
yang sudah diketal.

00:15:52.080 --> 00:15:53.100
Dan WAF membatasi laju

00:15:53.100 --> 00:15:53.900
permintaan dari IP

00:15:53.900 --> 00:15:54.480
yang sedang melakukan

00:15:54.480 --> 00:15:55.260
scrapping ke toko produk.

00:15:55.500 --> 00:15:56.800
Tak satu pun dari serangan ini

00:15:56.800 --> 00:15:57.580
mencapai server asalan.

00:15:57.940 --> 00:15:58.400
Tim backend Anda

00:15:58.400 --> 00:15:59.220
bahkan tidak tahu itu terjadi.

00:16:00.140 --> 00:16:00.980
Dan konten statis?

00:16:01.500 --> 00:16:02.700
Gambar produk, file CSS,

00:16:02.960 --> 00:16:03.560
pustaka JavaScript

00:16:03.560 --> 00:16:04.520
semuanya disimpan

00:16:04.520 --> 00:16:05.460
di lokasi Tokyo.

00:16:06.380 --> 00:16:06.940
Pengunjung pertama

00:16:06.940 --> 00:16:07.860
membuatnya dari asal Asia.

00:16:08.740 --> 00:16:09.260
Pengunjung kedua

00:16:09.260 --> 00:16:10.200
mendapatkan konten tersebut

00:16:10.200 --> 00:16:11.000
dari Kitch Edge Charged.

00:16:11.700 --> 00:16:12.560
Pengunjung berulang

00:16:12.560 --> 00:16:13.480
merasakan waktu muat

00:16:13.480 --> 00:16:14.140
yang sangat cepat

00:16:14.140 --> 00:16:15.360
karena semua yang mereka butuhkan

00:16:15.360 --> 00:16:16.380
sudah ada di lokasi Edge

00:16:16.380 --> 00:16:16.920
dekat mereka.

00:16:17.820 --> 00:16:18.280
Semua ini,

00:16:18.620 --> 00:16:19.500
perutian yang lebih cepat,

00:16:19.640 --> 00:16:20.500
file offer otomatis,

00:16:20.600 --> 00:16:21.220
keamalan Edge,

00:16:21.380 --> 00:16:22.020
dan konten CC

00:16:22.020 --> 00:16:23.460
bekerja sama dengan mulus.

00:16:23.840 --> 00:16:24.560
Pelanggan Anda tidak pernah tahu

00:16:24.560 --> 00:16:24.980
itu ada di sana.

00:16:25.340 --> 00:16:26.160
Mereka hanya melihat situs

00:16:26.160 --> 00:16:26.760
yang cepat dan ada.

00:16:27.340 --> 00:16:28.140
Inilah yang perlu diingat.

00:16:28.540 --> 00:16:29.120
Azure Front Door

00:16:29.120 --> 00:16:30.280
bertindak sebagai polisi lalu

00:16:30.280 --> 00:16:31.300
lintas global yang mengerahkan

00:16:31.300 --> 00:16:32.320
pengguna ke server tercepat

00:16:32.320 --> 00:16:33.180
menyimpan konten di Edge

00:16:33.180 --> 00:16:33.940
dan memblokir serangan

00:16:33.940 --> 00:16:34.700
sebelum mencapai Anda.

00:16:35.320 --> 00:16:36.160
Layanan ini dibangun

00:16:36.160 --> 00:16:37.420
di atas tiga lapisan ketahanan

00:16:37.420 --> 00:16:38.620
jadi meskipun suatu wilayah mati

00:16:38.620 --> 00:16:39.660
situs Anda tetap aktif.

00:16:39.660 --> 00:16:41.660
Untuk sebagian besar proyek,

00:16:41.760 --> 00:16:42.700
tingkat standar dengan harga

00:16:42.700 --> 00:16:43.840
hanya 35 per bulan

00:16:43.840 --> 00:16:44.980
antara kinerja dan biaya.

00:16:46.120 --> 00:16:46.860
Ingatkan ke premium

00:16:46.860 --> 00:16:47.700
saat Anda memerlukan

00:16:47.700 --> 00:16:48.500
keamanan tingkat lanjut

00:16:48.500 --> 00:16:49.040
atau private link.

00:16:49.440 --> 00:16:50.280
Mulailah dari yang kecil

00:16:50.280 --> 00:16:50.940
dengan satu orijin

00:16:50.940 --> 00:16:51.820
dan kembangkan dari sana.

00:16:52.320 --> 00:16:53.220
Front Door berskala bersama Anda.

00:16:54.100 --> 00:16:55.060
Jika aplikasi web Anda

00:16:55.060 --> 00:16:56.020
memiliki pengguna yang tersebar

00:16:56.020 --> 00:16:56.620
di berbagai wilayah,

00:16:56.700 --> 00:16:57.560
siapkan profil Front Door hari.

00:16:57.980 --> 00:16:58.960
Bahkan server tunggal pun

00:16:58.960 --> 00:16:59.660
mendapatkan manfaat

00:16:59.660 --> 00:17:00.960
akselerasi dan keamanan global.

00:17:01.440 --> 00:17:02.240
Berlangganan di platform

00:17:02.240 --> 00:17:03.200
podcast favorit Anda

00:17:03.200 --> 00:17:04.160
dan bagikan ini kepada

00:17:04.160 --> 00:17:05.120
seseorang yang bermulai

00:17:05.120 --> 00:17:05.960
perjalanan cloud mereka.