Una empresa implementó una landing zone con una estructura de AWS Organizations y un SCP. Los desarrolladores pueden crear recursos solo con CloudFormation y AWS CDK. Un ingeniero de DevOps descubre que las colas de SQS implementadas en diferentes stacks de CloudFormation tienen configuraciones inconsistentes y que la etiqueta de asignación de costos de la aplicación a veces falta. El ingeniero necesita aplicar el etiquetado, fomentar la reutilización de código y evitar configuraciones inconsistentes de SQS. ¿Qué debería hacer el ingeniero?

La opción correcta aborda todos los problemas. El etiquetado de AWS CDK permite aplicar etiquetas de forma programática y consistente a los recursos, incluyendo las etiquetas de asignación de costos, que luego se reflejan en CloudFormation StackSets. Requerir que los desarrolladores usen AWS CDK para definir las colas de SQS y las implementen como stacks de CDK promueve la reutilización de código a través de constructos de CDK y asegura configuraciones consistentes, ya que los desarrolladores pueden definir un constructo de SQS estandarizado. Las otras opciones son menos efectivas: Las políticas de etiquetas de Organizations pueden ayudar con el etiquetado, pero no resuelven la inconsistencia de configuración de SQS ni promueven la reutilización de código de la misma manera que CDK. CloudFormation StackSets es para implementar stacks en múltiples cuentas/regiones, no para estandarizar la definición de recursos dentro de un stack. Un SCP no puede aplicar etiquetas; solo puede denegar acciones. Los módulos de CloudFormation pueden ayudar con la reutilización, pero CDK ofrece una abstracción y programabilidad superiores para la consistencia. Las feature flags de CDK son para habilitar/deshabilitar características, no para la implementación principal de recursos o la estandarización de configuraciones.