Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Batas akun AMS

Ada tiga jenis batasan berbeda yang perlu dipertimbangkan dalam landing zone multi-akun AMS: batas AMS API, batas sumber daya AMS, dan batas AWS.

Ada dua jenis batasan berbeda yang perlu dipertimbangkan dalam landing zone akun tunggal AMS: batas AMS API, dan batas AWS.

Batas API akun AMS

Bagian ini menjelaskan batas level akun setelah AWS Managed Services (AMS) membatasi layanan AMS SKMS API. Ini berarti, jika Anda memanggil salah satu yang terdaftar APIs lebih dari 10 kali dalam satu detik, salah satu panggilan “dibatasi” (Anda menerima aThrottleException). Dalam situasi yang jarang terjadi, dependensi eksternal atau hilir mungkin menghambat API AMS dan kemudian AMS dapat membatasi panggilan API Anda pada tingkat yang mungkin lebih rendah.

Untuk setiap API AMS SKMS yang terdaftar, operasi dibatasi setelah 10 TPS (transaksi per detik):

Batas sumber daya akun landing zone multi-akun AMS

Batas sumber daya akun terkait dengan akun dan subnet aplikasi landing zone multi-akun VPCs AMS.

Batas sumber daya akun aplikasi

Ada batas lunak 50 akun aplikasi per organisasi. Jika Anda memiliki kasus penggunaan untuk lebih dari 50 akun aplikasi, hubungi manajer pengiriman layanan cloud (CSDM) Anda untuk menyampaikan persyaratan Anda.

VPCs dan batas sumber daya subnet

Ada batas lunak 10 VPCs per akun aplikasi dalam Wilayah AWS yang telah ditentukan sebelumnya untuk organisasi.

Setiap VPC mungkin memiliki 1 hingga 10 tingkatan subnet pribadi yang membentang di 2 hingga 3 zona ketersediaan. Selain itu, setiap VPC mungkin memiliki 0 hingga 5 tingkatan subnet publik yang membentang di 2 hingga 3 zona ketersediaan. Jika Anda memiliki persyaratan di luar batas ini, beri tahu CSDM atau Cloud Architect Anda untuk meninjau kasus penggunaan Anda.

Aplikasi multi-akun landing zone AMS terhadap rasio akun

Satu akun per aplikasi didukung di landing zone multi-akun AMS; namun, setiap akun Aplikasi memiliki biaya yang kecil, dan Anda dikenakan biaya untuk jumlah koneksi ke Transit Gateway per jam, dan jumlah lalu lintas yang mengalir melalui AWS Transit Gateway. Jadi, semakin banyak aplikasi terpisah ke dalam akun atau VPCs, semakin tinggi biayanya.

Untuk mengurangi biaya dan tetap memastikan pemisahan tugas yang tepat, AMS merekomendasikan agar Anda 1) mengelompokkan aplikasi berdasarkan tim dengan proses bisnis yang digabungkan secara erat, dan 2) tidak mencampur aplikasi yang berada dalam tahap yang berbeda (prod vs non-prod) atau dikelola oleh tim yang berbeda. Dengan cara ini, Anda akan memiliki lebih sedikit akun, manajemen akses dan pemisahan tugas akan lebih mudah, dan biaya lalu lintas dapat dikurangi.

Misalnya: Perusahaan telah memproduksi aplikasi Perdagangan dan aplikasi Manajemen Portofolio, kedua aplikasi dikelola oleh tim TI Investasi dan bertukar banyak lalu lintas satu sama lain. Dalam skenario ini perusahaan dapat memperoleh manfaat dari pengelompokan kedua aplikasi dalam akun yang sama dan sama dengan VPC, karena tim TI Investasi tidak perlu meminta akses ke beberapa akun Aplikasi dan perusahaan akan menghemat biaya lalu lintas. Dalam hal ini, perusahaan harus membuat akun lain untuk aplikasi yang sama dalam tahap pengembangan dan menyediakan akses ke tim pengembangan.

Dalam skenario lain, perusahaan telah memproduksi aplikasi Penggajian dan aplikasi Akuntansi, yang dikelola oleh tim TI Sumber Daya Manusia dan Akuntansi TI masing-masing. Meskipun aplikasi Payroll harus bertukar informasi dengan aplikasi Akuntansi, kami sarankan memisahkan kedua aplikasi dalam akun yang berbeda, satu per tim, dan membuat koneksi antara kedua aplikasi VPCs menggunakan akun Jaringan. Dengan cara ini, perusahaan akan mencegah perubahan permintaan tim TI SDM yang memengaruhi infrastruktur aplikasi akuntansi, yang tidak akan mereka ketahui.

Kiat tentang cara mengelompokkan akun ke dalam unit organisasi (OUs). OU adalah mekanisme pengelompokan logis yang memungkinkan Anda untuk mengkategorikan akun (grup) dan menerapkan kebijakan dan konfigurasi berdasarkan grup tersebut. Pendekatan yang disarankan untuk membuat OUs adalah mendasarkan mereka pada kebijakan yang perlu diterapkan pada grup akun tertentu, bukan pada hierarki internal tim dalam struktur pelaporan Anda. OU tidak setara dengan OU Direktori Aktif, dan mencoba mereplikasi struktur AD OU tidak AWS Organizations disarankan dan menghasilkan struktur operasi yang sulit dipertahankan. and/or

AWS batas akun

AWS batas akun berlaku untuk akun AWS Managed Services (AMS) Anda. Metode termudah untuk menentukan batas default dan saat ini untuk AWS layanan adalah dengan memanfaatkan AWS Service Quotas. AMS merekomendasikan batas layanan individual dengan ukuran yang tepat ke ukuran yang sesuai untuk menjalankan layanan di akun. Batas bertindak seperti pagar pelindung untuk melindungi akun Anda demi keamanan dan pelarian biaya. Jika Anda ingin menaikkan batas tertentu, kirimkan permintaan layanan dengan AMS, dan Operasi AMS akan menaikkan batas atas nama Anda. Misalnya, batas default (atau kuota) untuk instans RDS adalah 40; jika beban kerja Anda memerlukan 50 instans RDS, tingkatkan permintaan layanan untuk Operasi AMS untuk menaikkan batas ke nilai yang Anda butuhkan.