Un'azienda utilizza AWS Directory Service for Microsoft Active Directory come provider di identità e richiede che tutta l'infrastruttura sia fornita con AWS CloudFormation. Un ingegnere DevOps ha creato un template CloudFormation che definisce un launch template EC2, un ruolo IAM, un gruppo di sicurezza EC2 e un gruppo Auto Scaling per istanze EC2 Windows. Tutte le istanze EC2 devono essere automaticamente unite al dominio AWS Managed Microsoft AD. Quale approccio fornisce l'unione al dominio richiesta con la massima efficienza operativa?

L'opzione corretta sfrutta AWS Systems Manager (SSM) Association e il runbook AWS-JoinDirectoryServiceDomain. Questo è il metodo più efficiente operativamente perché automatizza l'unione al dominio senza richiedere script complessi nell'user data o la gestione manuale delle credenziali. L'associazione SSM può essere applicata a istanze basate su tag, garantendo che tutte le nuove istanze avviate dal gruppo Auto Scaling si uniscano automaticamente al dominio. Le policy IAM AmazonSSMManagedInstanceCore e AmazonSSMDirectoryServiceAccess sono necessarie per consentire a SSM di gestire le istanze ed eseguire l'unione al dominio. Le opzioni errate presentano svantaggi: La prima opzione, che utilizza AWS::SSM::Document e SSMAssociation nel launch template, è meno flessibile e più complessa da gestire rispetto a un'associazione SSM basata su tag. La terza opzione, che usa AWS-CreateManagedWindowsInstanceWithApproval, è progettata per la creazione di istanze con un processo di approvazione, non per l'unione automatica al dominio di istanze esistenti o appena avviate da un gruppo Auto Scaling. La quarta opzione, che usa user data per recuperare credenziali da Secrets Manager ed eseguire l'unione al dominio, è meno sicura e più complessa da mantenere. L'inserimento di credenziali o logica complessa nell'user data è generalmente sconsigliato a favore di SSM.