I'm in the process of designing our Azure infrastructure using Bicep, and I'm facing some challenges in creating a scalable and well-structured architecture. We manage about 40 resource groups, each linked to different applications across both production and development environments. New resource groups are rarely created or edited, and each is expected to include key components like Virtual Networks (VNet), Network Security Groups (NSG), Log Analytics Workspaces, Application Insights, Databases, and VMs. I'm looking for advice or best practices to set this up in a maintainable and modular way since the infrastructure's complexity is low, and most applications don't interact with each other. Everything is hosted in the same tenant with different subscriptions, so I'm aiming for a structure that is easy to maintain and update. Any insights would be greatly appreciated!
3 Answers
To start, consider reevaluating how you're structuring your resource groups. Mixing development and production resources within the same group can lead to security issues. It's generally better to separate them into different subscriptions for each environment. Think about structuring your resource groups based on their functions—having distinct groups for networking, applications, and data could enhance security and management. This approach aligns more with proper practices and would set a solid foundation for your Bicep strategy.
It's crucial to separate environments effectively. Use different subscriptions for production and development for better cost optimization and security. Establish resource groups based on purpose—for instance, have dedicated groups for applications, monitoring, and networking. Depending on your organization, sharing environments like AKS in a non-prod and prod subscription could help organize resources while keeping things manageable.
I recently set up a similar structure and found it useful to divide my templates into three key folders:
1. **Core** - Contains basic templates like databases and app services, ensuring compliance with organizational policies. Each core template should ideally deploy just one resource.
2. **Templates** - This folder has common compositions, e.g., a database integrated with a VNet. Make these templates reusable and utilize core templates to build them. In some cases, like key vault secrets, you might create resources directly.
3. **Application** - Specific to each application, with each having a main.bicep file and parameters. Try to maximize the use of templates here. Avoid direct resource creation unless necessary.
Also, leverage Bicep's typing and lambda systems to streamline your configurations. Define types to simplify outputs and tagging among shared resources—this practice will pay off down the line!
Great tips! Also, just a heads-up, you can now mark outputs as secure so that sensitive information remains protected.
Don't forget to check out the Azure Developer CLI for a great Bicep starter. It helped me set up my initial structure!