Save Costs with Basic SKU Application Gateway for more features and less fixed costs
Hi All! If you are one of the customers looking to save Costs with Application Gateway for better features than v1 SKU with limited applications as backend pools, here is a post for you! The Azure Application Gateway Basic SKU is an excellent choice for customers who have applications with lower traffic and do not necessitate high Service Level Agreements (SLAs). This feature is currently in public preview. It's a cost-effective solution that still provides core application-level load balancing features, such as URL-based, host-based, and multi-site routing, as well as cookie-based affinity. This SKU supports a variety of flexible backends, including Azure Kubernetes Service (AKS), Virtual Machine Scale Sets (VMSS), App Services, and on-premises deployments. With built-in high availability and support for HTTP2/HTTPS and WebSocket protocols, the Basic SKU ensures reliable application delivery without the need for advanced traffic management features. For small to medium-sized enterprises or developers seeking a balance between functionality and cost, the Azure Application Gateway Basic SKU presents a compelling option. Let’s delve into the details of the Azure Application Gateway Basic SKU. This SKU is designed for applications with lower traffic and SLA requirements, and it doesn’t require advanced traffic management features. Here are the key points: Advantages of Basic SKU: Basic SKU Features: High Availability: The Basic SKU includes built-in high availability. Protocol Support: It supports HTTP2/HTTPS and WebSocket protocols. Load Balancing: Core application-level load balancing features include URL-based, host-based, and multi-site routing, along with cookie-based affinity. Key Vault integration capabilities Header Rewrite Comparison with Standard V2 SKU: Performance: The Basic SKU is suitable for smaller workloads with a restriction on the number of backend pools supported upto 5 and also supports zone redundancy, while the Standard V2 SKU offers higher performance, autoscaling, zone redundancy, private application gateway, private link, mTLS and static VIPs. Autoscaling: The Standard V2 SKU allows autoscaling based on changing traffic patterns, whereas the Basic SKU doesn’t offer autoscaling. Static VIP: Basic SKU exclusively supports static VIPs, ensuring the VIP associated with the application gateway remains unchanged throughout its lifecycle. URL Rewrite: Only Standard V2 SKU allows you to add, remove, or update an URL. Security: When there is a need to use Web Application Firewall, it is better to choose WAF V2 SKU over Basic SKU as Basic SKU Application Gateway doesn't support Web Application Firewall yet. When to Use Basic SKU: Lower Traffic Workloads: Choose the Basic SKU for applications with lower traffic. Cost Savings: If advanced features aren’t necessary, Basic SKU provides cost savings. Zone Redundancy: If you need zone redundancy only for limited number of applications served as backends, choose the Basic SKU but if you need zone redundancy along with autoscaling, consider Standard V2 SKU. Limitations of Basic SKU: Now let’s explore the limitations of the Azure Application Gateway Basic SKU: Limited Performance: The Basic SKU is designed for smaller workloads and has lower performance compared to the Standard V2 SKU. If your application requires high throughput or autoscaling, consider the Standard V2 SKU instead. No Autoscaling: Unlike the Standard V2 SKU, the Basic SKU does not support autoscaling based on changing traffic patterns. You’ll need to manually adjust capacity if traffic increases. Fewer Advanced Features: The Basic SKU lacks some advanced features available in Standard V2, such as URL rewrite capabilities, private application gateway, private link, Web Application Firewall and mTLS (Mutual TLS Authentication). Remember to choose the SKU that aligns with your application’s requirements and budget. Differences between feature support with Basic SKU and Standard V2 SKU Application Gateway The following table displays a comparison between Basic and Standard_v2. Feature Capabilities Basic SKU (preview) Standard v2 SKU Reliability SLA 99.9 99.95 Functionality - basic HTTP/HTTP2/HTTPS Websocket Public/Private IP Cookie Affinity Path-based affinity Wildcard Multisite KeyVault AKS (via AGIC) Zone Header rewrite ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Functionality - advanced URL rewrite mTLS Private Link Private-only 1 TCP/TLS Proxy ✓ ✓ ✓ ✓ ✓ Scale Max. connections per second Number of listeners Number of backend pools Number of backend servers per pool Number of rules 200 1 5 5 5 5 62500 1 100 100 1200 400 Capacity Unit Connections per second per compute unit Throughput Persistent new connections 10 2.22 Mbps 2500 50 2.22 Mbps 2500 1 Estimated based on using an RSA 2048-bit key TLS certificate. Here is the source from where I got the differences between Basic SKU and Standard V2 SKU Application Gateway Capabilities. Additional information/resources: If you want to try Basic SKU in your lower environments for testing while it is in public preview, please use this article to proceed with the steps to register for the Basic SKU feature in public preview. While preview features are not something we recommend customers to use in production environment, consider production-ready Standard V2 SKU Application Gateway for production workloads. For more information on when the Basic SKU Application Gateway feature will be generally available (GA), stay tuned to Azure Updates. Savings with fixed costs on Application Gateway Basic SKU: [I have a Basic SKU Application Gateway with a single backend which is an app service in the East US region with zone redundancy enabled.] Standard SKU Application Gateway Fixed Cost: [ I have a Standard SKU Application Gateway with a single backend which is an app service in the East US region with zone redundancy enabled.] For more information on Pricing details and calculations, please check Application Gateway Pricing | Microsoft Azure. If you want to understand the way pricing is done based on the metrics on an Application Gateway, please check this article. How to register for preview feature Basic SKU Application Gateway using Azure CLI: https://learn.microsoft.com/en-us/azure/application-gateway/overview-v2#register-for-the-preview I hope you found this information useful. Happy reading! FastTrack for Azure: Move to Azure efficiently with customized guidance from Azure engineering. FastTrack for Azure – Benefits, and FAQ | Microsoft AzureChat with your Azure DevOps data
In the world of software development, the ability to quickly access and interpret Azure DevOps (ADO) Work Items is crucial. This is where our innovative solution comes into play, offering a ChatGPT-like experience directly with your ADO. Utilizing the Retrieval Augmented Generation (RAG) pattern, Azure AI Search & Azure Open AI's cutting-edge capabilities, we've created a seamless integration that elevates the efficiency of querying ADO work items.Building Intelligent Apps with Microsoft Azure: Ask the Experts 11th April 2024
Unleash the power of AI with Microsoft Azure! Join us as we build Contoso Chat, an AI-based support agent, streamline workflows with PromptFlow, and manage Azure AI platform interactions effectively. Learn about Responsible AI practices and start building your intelligent apps today. Whether you’re an educator or a student, Microsoft Azure has the tools and resources you need. Don’t wait, start your learning journey now!The Intrinsic Value of DevOps for the US Department of Defense
DevOps is not just a buzzword or a trend. It is a vital practice that can enhance the efficiency, security and agility of the US Department of Defense. DevOps can help the US Department of Defense to respond to emerging threats, innovate new solutions and optimize existing systems. DevOps is not an option, but a necessity for the US Department of Defense to fulfill its mission of protecting the nation and supporting advanced weaponry.Authentication and Authorization in Generative AI applications with Entra ID and Azure AI Search
In this blog, I will address a scenario where a customer wishes to implement authentication and authorization for their generative AI applications. Recently, customers have been implementing RAG patterns to construct the generative AI application. I will provide a detailed guide on how to enable authentication for a Gen AI web app, which signs in users using Entra ID, and how to restrict access to web pages based on Entra ID security groups. Furthermore, I will discuss how to implement access control when searching documents on Azure AI Search, using the security group as a filter. This pattern can similarly be applied to other metadata elements, like user ID, for enhanced security and personalized information retrieval. The following diagram demonstrates the architecture of a web app with identity and access management - Customer primarily using the demo repository or deploying the web app from Azure OpenAI studio. Enabling authentication After deploying your application, you must add an identity provider to facilitate authentication support. See this tutorial for more information. On your app's left menu, select Authentication, and then click Add identity provider. In the Add an identity provider page, for example select Microsoft as the Identity provider to sign in Microsoft and Microsoft Entra identities. Select a Tenant type, for example Workforce for work and school accounts or Microsoft accounts. For App registration > App registration type, select Create new app registration to create a new app registration in Microsoft Entra ID. Add a Name for the app registration, a public facing display name. For App registration > Supported account types, select Current tenant-single tenant so only users in your organization can sign in to the web app. In the App Service authentication settings section, leave Authentication set to Require authentication and Unauthenticated requests set to HTTP 302 Found redirect: recommended for websites. At the bottom of the Add an identity provider page, click Add to enable authentication for your web application. In the app's registration screen, select the API permissions blade in the left to open the page where we add access to the APIs that your application needs. Select the Add a permission button and then: Ensure that the Microsoft APIs tab is selected. In the Commonly used Microsoft APIs section, select Microsoft Graph In the Delegated permissions section, select User.Read and GroupMember.Read.All in the list. Use the search box if necessary. Select the Add permissions button at the bottom. GroupMember.Read.All requires admin consent. Select the Grant/revoke admin consent for {tenant} button, and then select Yes when you are asked if you want to grant consent for the requested permissions for all accounts in the tenant. You need to be an Azure AD tenant admin to do this. Configure Security Groups You have two different options available to you on how you can further configure your application(s) to receive the groups claim. Receive all the groups that the signed-in user is assigned to in an Azure AD tenant, including nested groups. Receive the groups claim values from a filtered set of groups that your application is programmed to work with (Not available in the Azure AD Free edition) Configure your application to receive all the groups the signed-in user is assigned to, including nested groups In the app's registration screen, select the Token Configuration blade in the left to open the page where you can configure the claims provided tokens issued to your application. Select the Add groups claim button on top to open the Edit Groups Claim screen. Select Security groups or the All groups (includes distribution lists but not groups assigned to the application) option. Choosing both negates the effect of Security Groups option. Under the ID section, select Group ID . This will result in Azure AD sending the Object ID of the groups the user is assigned to in the groups claim of the ID Token that your app receives after signing-in a user. Configure your application to receive the groups claim values from a filtered set of groups a user may be assigned to In the app's registration screen, select the Token Configuration blade in the left to open the page where you can configure the claims provided tokens issued to your application. Select the Add groups claim button on top to open the Edit Groups Claim screen. Select Groups assigned to the application . Choosing additional options like Security Groups or All groups (includes distribution lists but not groups assigned to the application) will negate the benefits your app derives from choosing to use this option. Under the ID section, select Group ID . This will result in Azure AD sending the Object ID of the groups the user is assigned to in the groups claim of the ID Token. In the app's registration screen, select on the Overview blade in the left to open the Application overview screen. Select the hyperlink with the name of your application in Managed application in local directory (note this field title can be truncated for instance Managed application in ... ). When you select this link you will navigate to the Enterprise Application Overview page associated with the service principal for your application in the tenant where you created it. You can navigate back to the app registration page by using the back button of your browser. Select the Users and groups blade in the left to open the page where you can assign users and groups to your application. Select the Add user button on the top row. Select User and Groups from the resultant screen. Choose the groups that you want to assign to this application. Click Select in the bottom to finish selecting the groups. Select Assign to finish the group assignment process. Your application will now receive these selected groups in the groups claim when a user signing into your app is a member of one or more these assigned groups. Select the Properties blade in the left to open the page that lists the basic properties of your application. Set the User assignment required? flag to Yes. Enabling document level access control Add blob metadata You can follow the instructions to add the group_id metadata in your blobs. Index file content and metadata by using Azure AI Search User-specified metadata properties are extracted verbatim. To receive the values, you must define field in the search index of type Edm.String , with same name as the metadata key of the blob. Follow the instructions to create group_id field in AI Search index. Apply the group_id filter in the query The user’s identifier is extracted from the token claims and combined with the user’s group memberships. AI Search filter uses a specific search.in syntax that can support hundreds or even thousands of group or user identifiers in a single query. For example, to filter over the groups field using a single group identifier, the filter would be groups/any(g: search.in(g, 'x')) Filters can be combined using either an and or an or operator. For example, to match documents where either the user id or the group id is present in the access control fields, the filter would be groups/any(g: search.in(g, 'x')) or users/any(g: search.in(g, 'y')) Here is a sample python code where user claims are extracted and used as a filter for searching - def build_security_filters(self, overrides: dict[str, Any], auth_claims: dict[str, Any]): # Build different permutations of the oid or groups security filter using OData filters # https://learn.microsoft.com/azure/search/search-security-trimming-for-azure-search # https://learn.microsoft.com/azure/search/search-query-odata-filter use_oid_security_filter = self.require_access_control or overrides.get("use_oid_security_filter") use_groups_security_filter = self.require_access_control or overrides.get("use_groups_security_filter") if (use_oid_security_filter or use_groups_security_filter) and not self.has_auth_fields: raise AuthError( error="oids and groups must be defined in the search index to use authentication", status_code=400 ) oid_security_filter = ( "oids/any(g:search.in(g, '{}'))".format(auth_claims.get("oid") or "") if use_oid_security_filter else None ) groups_security_filter = ( "groups/any(g:search.in(g, '{}'))".format(", ".join(auth_claims.get("groups") or [])) if use_groups_security_filter else None ) # If only one security filter is specified, return that filter # If both security filters are specified, combine them with "or" so only 1 security filter needs to pass # If no security filters are specified, don't return any filter if oid_security_filter and not groups_security_filter: return oid_security_filter elif groups_security_filter and not oid_security_filter: return groups_security_filter elif oid_security_filter and groups_security_filter: return f"({oid_security_filter} or {groups_security_filter})" else: return None Now, users can only search the documents associated with their respective Entra ID security groups. As a result, the Large Language Model (LLM) can provide answers based on the search results that users are already authorized to access. Happy learning!
