Post

What is Azure Container Apps LZA and how it can help me

Posted Updated
By Thodoris Theodorou 6 min read

Landing Zone Accelerators (LZA)

Enterprises embarking on their Cloud Adoption journey need solid technical guidance to plan ahead and design architectures that align with their business requirements and technical goals. Microsoft offers a wealth of proven guidance and best practices to assist organizations in confidently embracing the cloud and achieving their business objectives.

An Azure landing zone is an environment that follows key design principles across critical design areas. These design principles accommodate all application portfolios and enable application migration, modernization, and innovation at scale.

Azure landing zone accelerators provide architectural guidance, reference architectures, reference implementations, and automation to deploy workload platforms on Azure at scale. They are aligned with industry proven practices, such as those presented in Azure landing zones guidance in the Cloud Adoption Framework.

Landing zone accelerators are open source projects, continuously maintained by Microsoft Program Managers and Azure technical specialists, hosted under the Azure GitHub Organization. For a comprehensive list of available LZAs and regular updates, visit aka.ms/lza.

Azure Container Apps Landing Zone Accelerator

The Azure Container Apps landing zone accelerator is an open-source collection of architectural guidance and reference implementation to accelerate deployment of Azure Container Apps at scale.

The repository evolves by continually adding new features as they are made available for Azure Container Apps. The most recent (at the time of writing) release V2.0.0 incorporates the latest features from GA availability announcement

You can find the GitHub Repo for the Azure Container Apps Landing Zone Accelerator here: aka.ms/aca-lza

Secure Baseline Architecture

The repository presents a scenario called “Secure Baseline”. In this scenario, the fundamental decisions taken for what we call the secure baseline are: Use Azure Container Apps deployed on a custom Virtual Network

  • Internal Accessibility level. Internal environments have no public endpoints and are deployed with a virtual IP (VIP) mapped to an internal IP address.
  • Secure all subnets with Network Security Groups(NSG)
  • Control egress traffic with Azure Firewall. The benefits of such a setup are numerous; to name some:
    • Data protection / data exfiltration prevention: You can prevent malware or malicious software within your environment from communicating with external command and control servers. This can help in identifying and stopping cyber threats before they cause significant damage)
    • Compliance: regulatory frameworks, such as GDPR, HIPAA, and PCI DSS, require organizations to have controls in place to monitor and restrict outbound traffic
    • Access Control: Egress control allows you to specify which applications and services can access external resources, reducing the attack surface and limiting the potential for exposure to vulnerabilities in those applications)
    • Visibility and Monitoring: Azure Firewall provides the ability to log and analyze outbound traffic. This visibility is essential for detecting suspicious activities, security incidents, and compliance auditing.
    • Centralized Management: Azure Firewall allows for centralized management of egress traffic policies, making it easier to maintain and enforce consistent security controls across the entire environment.
  • Expose web applications / APIs through an Application Reverse Proxy with WAF (Layer 7) capabilities, such as Azure Application Gateway (or Azure Front Door Premium for supporting multi-regional deployments)
  • Use Azure native PaaS services for supporting resources required by your application (i.e. Databases) which are exposed only through Private Endpoints
  • Use Azure DDoS IP protection for the public IP of the Application Gateway.
  • Use Azure Policies for securing the deployment of apps on the Azure Container Apps environment, for enforcing organizational standards and to assess compliance at-scale.
  • Use Azure Container Registry Premium to store and manage your container images and related artifacts, with Zone redundancy enabled, for enhanced High Availability.
  • Use Azure Key Vault to securely store and access secrets, such as API keys, passwords, certificates, connection strings and other.
  • Use User Assigned Managed Identities for securing with fine grain access of the container apps to other resources (i.e. Azure Key Vault, databases etc)
  • Use Azure Bastion Services to securely connect to private Jump-boxes or self-hosted devops agents, to deploy your applications.

The diagram below illustrates the architecture. The reference implementation will create all the resources as shown in the diagram, except for the ones behind the gray background, i.e., GatewaySubnet. In reality, most organizations should already have a Hub network in place, but for the sake of completeness, we provide an implementation for that as well. If the hub is not required in your deployment, it can be safely removed from the deployment artifacts with little customization.

Azure Container Apps - Secure Baseline LZA Azure Container Apps - Secure Baseline LZA

Design areas

The architecture is considered across four key design areas. Please review them as part of your overall understanding of this landing zone accelerator.

Infrastructure as Code (IaC) options

The Reference Implementation is supporting two options

Both implementations follow best practices, as described in the contributing document. Special care has been given to:

Automation and deployment options

A complete deployment of the ACA LZA (both Hub and Spoke network and Azure resources) can be accomplished through various methods.

Deployment Automation

  • Azure devops pipeline
  • [Github Actions](https://github.com/Azure/aca-landing-zone-accelerator/blob/main/.github/

Both deployment automation methods are comprised of the following steps:

  • lint: Executes az bicep build on the main.bicep file
  • validate: Runs preflight validation
  • preview: Runs a [what-if operation] (https://learn.microsoft.com/azure/azure-resource-manager/templates/deploy-what-if?tabs=azure-powershell) to let you see how resources will change if you deploy the template
  • deploy: Runs the actual deployment
  • teardown: This step is optional (executed only if the user selects so by answering ‘yes’ to an issue opened by the deploy step) and is used to clean-up all deployed resources.

GitHub Action steps GitHub Action steps

Other Deployment Options

Manual Deployment

You can manually deploy the LZA by either using the BICEP or the Terraform IaC artifacts. You need the latest Az CLI (must be at least 2.40), or you can perform this from Azure Cloud Shell.

AZD and GitHub Codespaces

You can deploy everything with Azure Developer (AZD) CLI and [GitHub Codespaces](https://docs.github.com/codespaces, as described here: AZD & Codespaces

‘Deploy To Azure’ Button

The quickest method to deploy the LZA is to click on the “Deploy To Azure” button.

This will redirect you to the Azure Portal, where a series of steps will guide you through the customization of the deployment based on your needs. These steps include:

  • Basics: In this deployment step, fill in basic parameters such as Deployment Region and Workload Name
  • Network Settings: Adjust the default IPv4 address spaces for all required subnets if necessary.
  • Jump-Box Settings: Provide details if you need a Jumpbox VM, including VM SKU, username, and password.
  • Deployment feature flag: the final deployment by adding extra resources like Redis Cache, Bastion Service, etc., using simple true/false parameters.

ACA LZA Azure portal deployment ACA LZA Azure portal deployment

Azure, IaC
azure iac bicep container-apps containers architecture
This post is licensed under CC BY 4.0 by the author.