Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Manajemen identitas dan kontrol akses untuk transisi ke arsitektur multi-akun
Langkah pertama saat beralih ke arsitektur multi-akun ini adalah menyiapkan struktur akun baru Anda dalam suatu organisasi. Kemudian Anda dapat menambahkan pengguna dan mengonfigurasi akses mereka ke akun. Bagian ini menjelaskan pendekatan untuk mengelola akses manusia ke beberapa Akun AWS.
**Topics**
+ [Menyiapkan organisasi](set-up-organization.md)
+ [Buat landing zone](create-landing-zone.md)
+ [Tambahkan unit organisasi](add-organizational-units.md)
+ [Tambahkan pengguna awal](add-initial-users.md)
+ [Kelola akun anggota](manage-member-accounts.md)
# Menyiapkan organisasi
Ketika Anda memiliki beberapa Akun AWS, Anda dapat secara logis mengelola akun tersebut melalui organisasi di [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). *Akun* di AWS Organizations adalah standar Akun AWS yang berisi AWS sumber daya Anda dan identitas yang dapat mengakses sumber daya tersebut. *Organisasi* adalah entitas yang mengkonsolidasikan Anda Akun AWS sehingga Anda dapat mengelolanya sebagai satu unit.
Ketika Anda menggunakan akun untuk membuat organisasi, akun itu menjadi *akun manajemen* (juga dikenal sebagai akun *pembayar atau akun* *root*) untuk organisasi. Sebuah organisasi hanya dapat memiliki satu akun manajemen. Ketika Anda menambahkan tambahan Akun AWS ke organisasi, mereka menjadi *akun anggota*.
**catatan**
Masing-masing Akun AWS juga memiliki identitas tunggal yang disebut *pengguna root*. Anda dapat masuk sebagai pengguna root dengan menggunakan alamat email dan kata sandi yang Anda gunakan untuk membuat akun. Namun, kami sangat menyarankan agar Anda tidak menggunakan pengguna root untuk tugas sehari-hari, bahkan yang administratif. Untuk informasi selengkapnya, lihat [pengguna Akun AWS root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html).
Kami juga menyarankan untuk [memusatkan akses root untuk akun anggota](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) dan menghapus kredensi pengguna root dari akun anggota di organisasi Anda.
Anda mengatur akun dalam struktur hierarkis seperti pohon yang terdiri dari akar organisasi, unit organisasi (OUs), dan akun anggota. *Root* adalah wadah induk untuk semua akun di organisasi Anda. *Unit organisasi* (OU) adalah wadah untuk [akun](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) di dalam [root](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root). OU dapat berisi akun lain OUs atau anggota. OU hanya dapat memiliki satu orang tua, dan setiap akun dapat menjadi anggota hanya satu OU. Untuk informasi lebih lanjut, lihat [Terminologi dan konsep](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations dokumentasi).
[Kebijakan kontrol layanan (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) menentukan layanan dan tindakan yang dapat digunakan pengguna dan peran. SCPs mirip dengan kebijakan izin AWS Identity and Access Management (IAM) kecuali bahwa mereka tidak memberikan izin. Sebagai gantinya, SCPs tentukan izin maksimum. Ketika Anda melampirkan kebijakan ke salah satu node dalam hierarki, itu berlaku untuk semua OUs dan akun dalam node tersebut. Misalnya, jika Anda menerapkan kebijakan ke root, itu berlaku untuk semua [OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)dan [akun](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account) di organisasi, dan jika Anda menerapkan kebijakan ke OU, itu hanya berlaku untuk akun OUs dan di OU target.
[Kebijakan kontrol sumber daya (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) menawarkan kontrol pusat atas izin maksimum yang tersedia untuk sumber daya di organisasi Anda. RCPs membantu Anda memastikan bahwa sumber daya di akun Anda tetap berada dalam pedoman kontrol akses organisasi Anda.
Anda dapat menggunakan AWS Organizations konsol untuk melihat dan mengelola semua akun Anda secara terpusat dalam suatu organisasi. Salah satu manfaat menggunakan organisasi adalah Anda dapat menerima tagihan konsolidasi yang menunjukkan semua biaya yang terkait dengan akun manajemen dan anggota. Untuk informasi selengkapnya, lihat [Penagihan konsolidasi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) (AWS Organizations dokumentasi).
## Praktik terbaik
+ Jangan gunakan yang sudah ada Akun AWS untuk membuat organisasi. Mulailah dengan akun baru, yang menjadi akun manajemen Anda untuk organisasi. Operasi istimewa dapat dilakukan dalam akun manajemen organisasi, SCPs dan RCPs tidak berlaku untuk akun manajemen. Itu sebabnya Anda harus membatasi sumber daya cloud dan data yang terkandung dalam akun manajemen hanya untuk yang harus dikelola di akun manajemen.
+ Batasi akses ke akun manajemen hanya untuk individu-individu yang perlu menyediakan baru Akun AWS dan mengelola organisasi.
+ Gunakan SCPs untuk menentukan izin maksimum untuk root, unit organisasi, dan akun anggota. SCPs tidak dapat langsung diterapkan ke akun manajemen.
+ Gunakan RCPs untuk menentukan izin maksimum untuk sumber daya di akun anggota. RCPstidak dapat langsung diterapkan ke akun manajemen.
+ Patuhi [Praktik terbaik untuk AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html) (AWS Organizations dokumentasi).
# Buat landing zone
*Landing zone* adalah AWS lingkungan multi-akun yang dirancang dengan baik yang merupakan titik awal dari mana Anda dapat menyebarkan beban kerja dan aplikasi. Ini memberikan dasar untuk memulai dengan arsitektur multi-akun, identitas dan manajemen akses, tata kelola, keamanan data, desain jaringan, dan logging. [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)adalah layanan yang menyederhanakan pemeliharaan dan tata kelola lingkungan multi-akun dengan menyediakan pagar pembatas otomatis. Biasanya, Anda menyediakan satu AWS Control Tower landing zone yang mengelola lingkungan Anda di semua Wilayah AWS. AWS Control Tower bekerja dengan mengatur orang lain Layanan AWS dalam akun Anda. Untuk informasi selengkapnya, lihat [Apa yang terjadi saat Anda menyiapkan landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup) (AWS Control Tower dokumentasi).
Saat menyiapkan landing zone AWS Control Tower, Anda mengidentifikasi tiga akun bersama: akun manajemen, akun arsip log, dan akun audit. Untuk informasi selengkapnya, lihat [Apa itu akun bersama](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared) (AWS Control Tower dokumentasi). Untuk akun manajemen, Anda harus menggunakan akun yang sudah ada yang tidak menghosting beban kerja apa pun untuk mengatur landing zone. Untuk arsip log dan akun audit, Anda dapat memilih untuk menggunakan kembali yang sudah ada Akun AWS, atau AWS Control Tower dapat membuatnya untuk Anda.
Untuk petunjuk tentang cara mengatur AWS Control Tower landing zone, lihat [Memulai](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) (AWS Control Tower dokumentasi).
## Praktik terbaik
+ Patuhi praktik terbaik dalam [prinsip-prinsip Desain untuk strategi multi-akun Anda](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html) (AWS Whitepaper).
+ Patuhi [Praktik terbaik untuk AWS Control Tower administrator](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html) (AWS Control Tower dokumentasi).
+ Buat landing zone Anda di tempat Wilayah AWS yang menampung sebagian besar beban kerja Anda.
**penting**
Jika Anda memutuskan untuk mengubah Wilayah ini setelah menerapkan landing zone Anda, Anda memerlukan bantuan AWS Dukungan, dan Anda harus menonaktifkan landing zone. Praktek ini tidak dianjurkan.
+ Saat menentukan Wilayah mana yang AWS Control Tower akan diatur, pilih hanya Wilayah yang Anda harapkan untuk segera menerapkan beban kerja. Anda dapat mengubah Wilayah ini atau menambahkan lebih banyak lagi nanti. Jika AWS Control Tower memerintah suatu Wilayah, ia akan mengerahkan pagar pembatas detektifnya ke Wilayah itu sebagai. [Aturan AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ Setelah menentukan Wilayah mana yang AWS Control Tower akan memerintah, tolak akses ke semua Wilayah yang tidak diatur. Ini membantu memastikan bahwa beban kerja dan pengembang Anda hanya dapat menggunakan disetujui Wilayah AWS. Ini diimplementasikan sebagai kebijakan kontrol layanan (SCP) dalam organisasi. Untuk informasi selengkapnya, lihat [Wilayah AWS Mengonfigurasi kontrol](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html) penolakan (AWS Control Tower dokumentasi).
+ Saat menyiapkan landing zone Anda di AWS Control Tower, kami sarankan Anda mengganti nama berikut OUs dan akun:
+ Kami menyarankan Anda mengganti nama **Security OU menjadi **Security\$1Prod**** untuk menandakan bahwa OU ini akan digunakan untuk keamanan produksi terkait. Akun AWS
+ **Kami menyarankan Anda mengizinkan AWS Control Tower untuk membuat OU tambahan dan kemudian mengganti namanya dari **Sandbox** ke Workloads.** Di bagian berikutnya, Anda membuat tambahan OUs dalam **Workloads** OU, yang Anda gunakan untuk mengatur Anda Akun AWS.
+ Kami menyarankan Anda mengganti nama logging terpusat Akun AWS dari **Log Archive** menjadi. **log-archive-prod**
+ Kami menyarankan Anda mengganti nama akun audit dari **Audit** menjadi **security-tooling-prod**.
+ Untuk membantu mencegah penipuan, AWS diperlukan yang Akun AWS memiliki riwayat penggunaan sebelum dapat ditambahkan ke AWS Control Tower landing zone. Jika Anda menggunakan yang baru Akun AWS tanpa riwayat penggunaan apa pun, di akun baru, Anda dapat meluncurkan instans Amazon Elastic Compute Cloud (Amazon EC2) yang tidak ada di Tingkat Gratis. AWS Biarkan instance berjalan selama beberapa menit dan kemudian hentikan.
# Tambahkan unit organisasi
Menetapkan struktur organisasi yang tepat sangat penting untuk menyiapkan lingkungan multi-akun. Karena Anda menggunakan kebijakan kontrol layanan (SCPs) untuk menentukan izin maksimum untuk OU dan akun di dalamnya, struktur organisasi Anda harus logis dari perspektif manajemen, izin, dan pelaporan keuangan. Untuk informasi lebih lanjut tentang struktur organisasi, termasuk unit organisasi (OUs), lihat [Terminologi dan konsep](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations dokumentasi).
Di bagian ini, Anda menyesuaikan landing zone dengan membuat nested OUs yang membantu Anda mengelompokkan dan menyusun lingkungan Anda, seperti produksi dan non-produksi. Praktik terbaik yang direkomendasikan ini dirancang untuk mengelompokkan landing zone Anda untuk memisahkan sumber daya produksi dan non-produksi serta memisahkan infrastruktur dari beban kerja.
Untuk informasi selengkapnya tentang cara membuat OUs, lihat [Mengelola unit organisasi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations dokumentasi).
## Praktik terbaik
+ Dalam **Workloads** OU yang Anda buat[Buat landing zone](create-landing-zone.md), buat yang berikut ini bersarang OUs:
+ **Prod** - Gunakan OU ini untuk Akun AWS menyimpan dan mengakses data produksi, termasuk data pelanggan.
+ **NonProd**— Gunakan OU ini untuk Akun AWS menyimpan data non-produksi, seperti lingkungan pengembangan, pementasan, atau pengujian
Di bawah root organisasi, buat **Infrastructure\$1Prod** OU. Gunakan OU ini untuk meng-host akun jaringan terpusat.
# Tambahkan pengguna awal
Ada dua cara untuk memberi orang akses ke Akun AWS:
+ Identitas IAM, seperti pengguna, grup, dan peran
+ Federasi identitas, seperti dengan menggunakan AWS IAM Identity Center
Di perusahaan yang lebih kecil dan lingkungan akun tunggal, adalah umum bagi administrator untuk membuat pengguna IAM ketika orang baru bergabung dengan perusahaan. Kunci akses dan kredenal kunci rahasia yang terkait dengan pengguna IAM dikenal sebagai *kredensi jangka panjang* karena tidak kedaluwarsa. Namun, ini bukan praktik terbaik keamanan yang direkomendasikan karena jika penyerang mengkompromikan kredensil tersebut, Anda harus menghasilkan satu set kredensil baru untuk pengguna. Pendekatan lain untuk mengakses Akun AWS adalah melalui peran [IAM](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/). Anda juga dapat menggunakan [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)(AWS STS) untuk sementara meminta *kredensil jangka pendek*, yang kedaluwarsa setelah jangka waktu yang dapat dikonfigurasi.
Anda dapat mengelola akses orang ke Anda Akun AWS melalui [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). Anda dapat membuat akun pengguna individual untuk setiap karyawan atau kontraktor Anda, mereka dapat mengelola kata sandi dan solusi otentikasi multi-faktor (MFA) mereka sendiri, dan Anda dapat mengelompokkannya untuk mengelola akses. Saat mengonfigurasi MFA, Anda dapat menggunakan token perangkat lunak, seperti aplikasi autentikator, atau Anda dapat menggunakan token perangkat keras, seperti perangkat. YubiKey
IAM Identity Center juga mendukung federasi dari penyedia identitas eksternal (IdPs) seperti Okta, JumpCloud, dan Ping Identity. Untuk informasi selengkapnya, lihat [Penyedia identitas yang didukung](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (dokumentasi Pusat Identitas IAM). Dengan berfederasi dengan iDP eksternal, Anda dapat mengelola otentikasi pengguna di seluruh aplikasi dan kemudian menggunakan IAM Identity Center untuk mengotorisasi akses ke spesifik. Akun AWS
## Praktik terbaik
+ Patuhi [praktik terbaik Keamanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) (dokumentasi IAM) untuk mengonfigurasi akses pengguna.
+ Kelola akses akun berdasarkan grup, bukan oleh pengguna individu. Di IAM Identity Center, buat grup baru yang mewakili setiap fungsi bisnis Anda. Misalnya, Anda dapat membuat grup untuk teknik, keuangan, penjualan, dan manajemen produk.
+ Seringkali, grup didefinisikan dengan memisahkan mereka yang membutuhkan akses ke semua Akun AWS (seringkali akses hanya-baca) dan mereka yang membutuhkan akses ke satu. Akun AWS Kami menyarankan Anda menggunakan konvensi penamaan berikut untuk grup sehingga mudah untuk mengidentifikasi Akun AWS dan izin yang terkait dengan grup.
`--`
+ Misalnya, untuk grup`AWS-A-dev-nonprod-DeveloperAccess`, `AWS-A` adalah awalan yang menunjukkan akses ke satu akun, `dev-nonprod` adalah nama akun, dan `DeveloperAccess` merupakan set izin yang ditetapkan ke grup. Untuk grup`AWS-O-BillingAccess`, `AWS-O` awalan menunjukkan akses ke seluruh organisasi, dan `BillingAccess` menunjukkan izin yang ditetapkan untuk grup. Dalam contoh ini, karena grup memiliki akses ke seluruh organisasi, nama akun tidak direpresentasikan dalam nama grup.
+ Jika Anda menggunakan IAM Identity Center dengan IDP berbasis SAML eksternal dan ingin meminta MFA, Anda dapat menggunakan kontrol akses berbasis atribut (ABAC) untuk meneruskan metode otentikasi dari IDP ke IAM Identity Center. Atribut dikirim melalui pernyataan SAMP. Untuk informasi selengkapnya, lihat [Mengaktifkan dan mengonfigurasi atribut untuk kontrol akses](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html) (dokumentasi Pusat Identitas IAM).
Banyak IdPs, seperti Microsoft Azure Active Directory dan Okta, dapat menggunakan klaim Authentication Method Reference (`amr`) di dalam pernyataan SAMP untuk meneruskan status MFA pengguna ke IAM Identity Center. Klaim yang digunakan untuk menegaskan status MFA dan formatnya bervariasi menurut IDP. Untuk informasi selengkapnya, lihat dokumentasi untuk IDP Anda.
Di Pusat Identitas IAM, Anda kemudian dapat membuat kebijakan set izin yang menentukan siapa yang dapat mengakses AWS sumber daya Anda. Saat Anda mengaktifkan ABAC dan menentukan atribut, Pusat Identitas IAM meneruskan nilai atribut pengguna yang diautentikasi ke IAM untuk digunakan dalam evaluasi kebijakan. Untuk informasi selengkapnya, lihat [Membuat kebijakan izin untuk ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html) (dokumentasi Pusat Identitas IAM). Seperti yang ditunjukkan pada contoh berikut, Anda menggunakan tombol `aws:PrincipalTag` kondisi untuk membuat aturan kontrol akses untuk MFA.
```
"Condition": {
"StringLike": { "aws:PrincipalTag/amr": "mfa" }
}
```
# Kelola akun anggota
Di bagian ini, Anda mengundang akun yang sudah ada sebelumnya ke organisasi dan Anda mulai membuat akun baru dalam organisasi Anda. Bagian penting dari proses ini adalah mendefinisikan kriteria yang Anda gunakan untuk menentukan apakah Anda perlu menyediakan akun baru.
**Topics**
+ [Undang akun Anda yang sudah ada sebelumnya](#invite-account)
+ [Sesuaikan pengaturan VPC di AWS Control Tower](#customize-vpc-settings)
+ [Tentukan kriteria pelingkupan](#define-scoping-criteria)
## Undang akun Anda yang sudah ada sebelumnya
Di dalamnya AWS Organizations, Anda dapat mengundang akun perusahaan Anda yang sudah ada sebelumnya ke organisasi baru Anda. Hanya akun manajemen di organisasi yang dapat mengundang akun lain untuk bergabung. Ketika administrator akun yang diundang menerima, akun segera bergabung dengan organisasi, dan akun manajemen organisasi menjadi bertanggung jawab atas semua biaya yang timbul oleh akun anggota baru. Untuk informasi selengkapnya, lihat [Mengundang Akun AWS untuk bergabung dengan organisasi Anda](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) dan [Menerima atau menolak undangan dari organisasi](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite) (AWS Organizations dokumentasi).
**catatan**
Anda dapat mengundang akun untuk bergabung dengan organisasi hanya jika akun tersebut saat ini tidak berada di organisasi lain. Jika akun tersebut adalah anggota organisasi yang ada, Anda harus menghapusnya dari organisasi. Jika akun tersebut adalah akun manajemen untuk organisasi lain yang dibuat karena kesalahan, Anda harus menghapus organisasi.
**penting**
Jika Anda memerlukan akses ke informasi biaya atau penggunaan historis dari akun yang sudah ada sebelumnya, Anda dapat menggunakannya AWS Cost and Usage Report untuk mengekspor informasi tersebut ke bucket Amazon Simple Storage Service (Amazon S3). Lakukan ini sebelum menerima undangan untuk bergabung dengan organisasi. Saat akun bergabung dengan organisasi, Anda kehilangan akses ke data historis ini untuk akun tersebut. Untuk informasi selengkapnya, lihat [Menyiapkan bucket Amazon S3 untuk Laporan Biaya dan Penggunaan](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (AWS Cost and Usage Report dokumentasi).
*Praktik terbaik*
+ Kami menyarankan Anda menambahkan akun yang sudah ada sebelumnya, yang kemungkinan berisi beban kerja produksi, ke unit organisasi **Beban Kerja** > **Prod** yang Anda buat. [Tambahkan unit organisasi](add-organizational-units.md)
+ Secara default, akun manajemen organisasi tidak memiliki akses administratif atas akun anggota yang diundang ke organisasi. Jika Anda ingin akun manajemen memiliki kontrol administratif, Anda harus membuat peran **OrganizationAccountAccessRole**IAM di akun anggota dan memberikan izin ke akun manajemen untuk mengambil peran tersebut. Untuk informasi selengkapnya, lihat [Membuat akun anggota yang diundang](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role) (AWS Organizations dokumentasi). OrganizationAccountAccessRole
+ Untuk akun yang sudah ada sebelumnya yang Anda undang ke organisasi, tinjau [Praktik terbaik untuk akun anggota](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html) (AWS Organizations dokumentasi) dan konfirmasikan bahwa akun tersebut mematuhi rekomendasi ini.
## Sesuaikan pengaturan VPC di AWS Control Tower
Kami menyarankan Anda untuk menyediakan yang baru Akun AWS melalui [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) di AWS Control Tower. Dengan menggunakan Account Factory, Anda dapat menggunakan AWS Control Tower integrasi dengan Amazon EventBridge untuk menyediakan sumber daya baru Akun AWS segera setelah akun dibuat.
Saat Anda menyiapkan yang baru Akun AWS, [virtual private cloud (VPC) default](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) secara otomatis disediakan. Namun, ketika Anda menyiapkan akun baru melalui Account Factory, AWS Control Tower secara otomatis memberikan VPC tambahan. Untuk informasi selengkapnya, lihat [Ikhtisar AWS Control Tower dan VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html) (AWS Control Tower dokumentasi). Ini berarti bahwa, secara default, AWS Control Tower ketentuan dua default VPCs di setiap akun baru.
Adalah umum bagi perusahaan untuk menginginkan kontrol lebih besar atas VPCs dalam akun mereka. Banyak yang lebih suka menggunakan layanan lain, seperti AWS CloudFormation, Hashicorp Terraform, atau Pulumi, untuk mengatur dan mengelola mereka. VPCs Anda harus menyesuaikan pengaturan Account Factory untuk mencegah pembuatan VPC tambahan yang disediakan oleh. AWS Control Tower Untuk petunjuknya, lihat [Mengonfigurasi setelan Amazon VPC](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html) (AWS Control Tower dokumentasi), dan menerapkan setelan berikut:
1. Nonaktifkan opsi **subnet yang dapat diakses Internet**.
1. Dalam **jumlah maksimum subnet pribadi**, pilih **0**.
1. Di **Wilayah untuk pembuatan VPC**, hapus semua Wilayah.
1. Di **Availability Zones**, pilih **3**.
*Praktik terbaik*
+ Hapus VPC default yang secara otomatis disediakan di setiap akun baru. Ini mencegah pengguna meluncurkan instans EC2 publik di akun tanpa secara eksplisit membuat VPC khusus. Untuk informasi selengkapnya, lihat [Menghapus subnet default dan VPC default](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc) (dokumentasi Amazon Virtual Private Cloud). Anda juga dapat mengonfigurasi [AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) untuk secara otomatis menghapus VPC default di akun yang baru dibuat.
+ Menyediakan yang baru Akun AWS disebut **dev-nonprod** ke dalam **Workloads** > unit organisasi. **NonProd** Gunakan akun ini untuk lingkungan pengembangan Anda. Untuk petunjuk, lihat [Menyediakan akun Account Factory dengan AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower dokumentasi).
## Tentukan kriteria pelingkupan
Anda perlu memilih kriteria yang akan digunakan perusahaan Anda ketika memutuskan apakah akan menyediakan yang baru Akun AWS. Anda mungkin memutuskan untuk menyediakan akun untuk setiap unit bisnis, atau Anda mungkin memutuskan untuk menyediakan akun berdasarkan lingkungan, seperti produksi, pengujian, atau QA. Setiap perusahaan memiliki persyaratan sendiri untuk seberapa besar atau kecil mereka Akun AWS seharusnya. Umumnya, Anda mengevaluasi tiga faktor berikut saat memutuskan cara mengukur akun Anda:
+ **Kuota layanan penyeimbangan** — *Kuota layanan* adalah nilai maksimum untuk jumlah sumber daya, tindakan, dan item untuk masing-masing Layanan AWS dalam file. Akun AWS Jika banyak beban kerja berbagi akun yang sama dan satu beban kerja menghabiskan sebagian besar atau seluruh kuota layanan, itu mungkin berdampak negatif pada beban kerja lain di akun yang sama. Jika demikian, Anda mungkin perlu memisahkan beban kerja tersebut ke dalam akun yang berbeda. Untuk informasi selengkapnya, lihat [Layanan AWS kuota](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) (Referensi Umum AWS).
+ **Pelaporan biaya** - Mengisolasi beban kerja ke dalam akun terpisah memungkinkan Anda melihat biaya pada tingkat akun dalam laporan biaya dan penggunaan. Saat menggunakan akun yang sama untuk beberapa beban kerja, Anda dapat menggunakan tag untuk membantu mengelola dan mengidentifikasi sumber daya. Untuk informasi selengkapnya tentang penandaan, lihat [Menandai AWS resource](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) ()Referensi Umum AWS.
+ **Mengontrol akses** - Saat beban kerja berbagi akun, Anda perlu mempertimbangkan cara mengonfigurasi kebijakan IAM untuk membatasi akses ke sumber daya akun sehingga pengguna tidak memiliki akses ke beban kerja yang tidak mereka butuhkan. Sebagai alternatif, Anda dapat menggunakan beberapa akun dan [set izin](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) di Pusat Identitas IAM untuk mengelola akses ke akun individual.
*Praktik terbaik*
+ Patuhi praktik terbaik dalam [strategi AWS multi-akun untuk AWS Control Tower landing zone Anda](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html) (AWS Control Tower dokumentasi).
+ Tetapkan strategi penandaan yang efektif yang membantu Anda mengidentifikasi dan mengelola AWS sumber daya. Anda dapat menggunakan tag untuk mengkategorikan sumber daya berdasarkan tujuan, unit bisnis, lingkungan, atau kriteria lainnya. Untuk informasi selengkapnya, lihat [Praktik terbaik untuk penandaan](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices) (Referensi Umum AWS dokumentasi).
+ Jangan membebani akun dengan terlalu banyak beban kerja. Jika permintaan beban kerja melebihi kuota layanan, ini dapat menyebabkan masalah kinerja. Anda dapat memisahkan beban kerja yang bersaing menjadi berbeda Akun AWS atau Anda dapat meminta peningkatan kuota layanan. Untuk informasi selengkapnya, lihat [Meminta peningkatan kuota (Dokumentasi Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)).