How to Design Azure Infrastructure with GitHub Copilot

Even when you know what you want to build on Azure, deciding on services, SKUs, instance counts, networking, and monitoring from the outset can be difficult. You may want a cost estimate but get stuck because you do not know what to enter in the Azure Pricing Calculator.

You do not need to think like an Azure expert from the start. Instead, tell GitHub Copilot what you want to build, have it ask about missing details, and ask it to propose a concrete starting point.

This site was built that way. This article uses it as a real-world example to show how I went from an initial conversation to organized requirements, an architecture diagram, Bicep, and an actual Azure deployment, then refined the result based on behavior and cost.

Table of Contents

• Conclusion First
• Start by Describing What You Want to Build
• How a Vague Idea Becomes a Concrete Proposal
• Validate It by Deploying Bicep
• This Site Also Grew Through Repeated Consultation and Validation
• Start with This Prompt
• What to Delegate to Copilot and What People Must Decide
• Summary

Conclusion First

One advantage of GitHub Copilot is that you do not need to learn Azure terminology before asking for help.

For example, in Plan mode, you could say, “I want to publish a small web service on Azure. It does not have many users yet, and I want to minimize operational overhead.” Copilot can then ask about missing requirements and use your answers to develop specific recommendations for services, initial sizing, an architecture diagram, and cost-estimation assumptions.

Once you are satisfied with the plan, switch to Agent mode. In the same conversation, you can turn the plan into Bicep and application code, then build and test it instead of stopping at a design document.

The goal is not to have Copilot make the final decision in place of an expert. It is to quickly organize the proposal so that an expert can review it, then run a small deployment to gather evidence for the decision.

This makes it easier to take the first step from a blank slate, even with limited Azure experience.

Start by Describing What You Want to Build

When I started building this site, I had not finalized the specification. I planned to refine it as I built.

• Revive my personal blog
• Separate technical, community, photography, and daily-life posts
• Manage content on GitHub
• Run the site on Azure
• Add demos and useful features later

That was the level of detail I had when I started talking with GitHub Copilot. At the time, I asked Agent mode to “start by making a plan.” Today, Plan mode is a better place to start because it lets you refine the direction without changing files, making it easier to separate design from implementation.

Copilot then asks questions such as: Who will update the articles? How should drafts and published articles be separated? Where should images be stored? Is authentication required? How much recovery capability is needed after an outage?

If you are new to Azure, you may not even know what decisions you have overlooked. Copilot’s questions separate the requirements already in your head from the unresolved details. It is fine to answer “undecided.” Once an item is explicitly undecided, you can make a temporary assumption and test it.

How a Vague Idea Becomes a Concrete Proposal

Once the requirements are reasonably complete, you can ask Copilot how to get an initial version running. The key is not to ask for a single correct answer, but to request an initial proposal together with the assumptions behind it.

For a small content site, for example, the discussion can lead to concrete proposals like these:

This is not an attempt to reproduce a person’s intuition about what will “probably be enough.” It uses assumptions such as user count, peak requests, data volume, and acceptable response time to establish numbers from which validation can begin.

GitHub Copilot can also use tools during this process.

• Use the Microsoft Learn MCP Server to check current official specifications, constraints, and recommendations
• Use the Azure MCP Server to inspect resources, configuration, logs, pricing information, and other details in the subscription
• Read the repository to verify that the proposal does not conflict with existing code or Bicep

In other words, the conversation can continue using official information, the actual Azure environment, and the current code, rather than relying only on generic answers.

Validate It by Deploying Bicep

An architecture proposal and initial sizing are not the finish line. Ask Copilot to create Bicep, deploy it to a small environment, and validate it.

The process is straightforward:

1. Describe what you want to build and the usage conditions you know
2. Have Plan mode ask about missing requirements
3. Ask for a minimum configuration, initial sizing, and the reasoning behind them
4. Verify the specifications with the Microsoft Learn MCP Server
5. Review the plan and switch to Agent mode
6. Ask for an architecture diagram, cost-estimation assumptions, and Bicep
7. Review the changes with what-if, then deploy to Azure
8. Check response time, errors, logs, and actual cost
9. Give the results back to Copilot and revise the architecture or sizing

In this process, the initial sizing is a hypothesis, not a finished answer. Increase it if capacity is insufficient, and decrease it if resources are underused. After deployment, update the Azure Pricing Calculator estimate by comparing it with actual spending in Microsoft Cost Management.

Copilot’s value is in shortening the distance from hypothesis to Bicep, deployment, measurement, and revision.

This Site Also Grew Through Repeated Consultation and Validation

During the site’s initial development on July 13, 2026, I told Copilot that I wanted to proceed in this order:

1. Record the design in docs
2. Design the site
3. Create the Phase 1 Bicep
4. Scaffold the application

The first commit included docs/architecture.md, docs/design.md, Bicep, Astro, Azure Functions, and GitHub Actions. What we organized in conversation flowed directly into design documents and working code.

The site began as a small setup that served an Astro-generated blog through Azure Static Web Apps. From there, I continued asking for changes: “I want to create English articles,” “I want to collect Microsoft-related information automatically,” “I want to use a custom domain and WAF,” “I want to keep Storage private,” and “I want to detect outages and attacks.”

Each time, I worked with Copilot to organize the requirements, checked the specifications on Microsoft Learn, updated the Bicep and application, and tested the changes on Azure. The current architecture is shown below.

Articles, images, Astro and Functions code, and Bicep are managed on GitHub. When changes reach main, GitHub Actions builds the static site and deploys it to Azure Static Web Apps, while deploying the API to Azure Functions. Bicep does not run automatically on every push. It is deployed explicitly only when infrastructure changes, after reviewing the what-if output.

This was not all built at once.

For example, I initially reduced the Function memory for the Hot Topics API to control cost, but the response time did not meet expectations, so I reviewed the configuration based on measurements. I also discovered that the initial Storage implementation did not comply with tenant policies and changed the architecture to use Managed Identity, Private Endpoint, and Private DNS.

Copilot’s first proposal was not always correct. Even so, when I brought errors, logs, policies, and response-time measurements back into the conversation, it could investigate possible causes and update both the Bicep and the design documents.

Through these iterations, the site grew from a static blog into its current architecture. If I had waited until I had learned every Azure service before starting, it would have taken much longer to experiment this far.

Start with This Prompt

You do not need to ask for Azure service names or Bicep from the outset. Start in Plan mode by sharing only what you want to build and what you already know, then organize the requirements needed for the design.

I want to build a small web service on Azure.
I am not familiar with Azure architecture or sizing.

First, ask me one question at a time about the requirements that are missing from the design.
If I do not know an answer, mark it as "undecided" and explain the available options and their differences.

After you finish asking questions, organize the following:

1. What I want to achieve
2. Confirmed requirements and constraints
3. Assumptions
4. Undecided items
5. Decisions that need to be made next

At this stage, do not create or modify files or deploy Azure resources.

Review the organized information yourself and answer the unresolved items. Once you are satisfied with the requirements and assumptions, use the next prompt to move on to architecture proposals.

Based on the organized requirements and assumptions, propose the following:

1. A minimum configuration and a configuration with some additional capacity
2. The Azure services to use and the reasons for selecting them
3. Initial sizing and the assumptions behind it
4. An architecture diagram
5. Items to enter in the Azure Pricing Calculator
6. Performance, availability, security, and cost metrics to check after deployment

Use the Microsoft Learn MCP Server to verify the latest official information.
If the Azure MCP Server is available, also inspect the actual state of the target subscription.
Clearly separate confirmed facts, assumptions, and undecided items.

After reviewing the architecture proposal, switch to Agent mode and continue with requests such as, “Turn the approved architecture into Bicep,” “Run what-if before deployment,” and “Check response time and logs after deployment.” Separating requirements discovery, architecture selection, and implementation helps prevent Azure resources from being created based on unintended assumptions.

As an additional resource, GitHub’s Awesome Copilot repository provides examples of prompts, custom agents, Instructions, and Skills. The azure-architecture-autopilot Skill, which closely resembles the process in this article, guides users step by step from conversational Azure architecture design through an architecture diagram, Bicep, what-if, and deployment.

The repository also includes azure-principal-architect for requirements and Azure design, bicep-plan for creating Bicep implementation plans, and bicep-implement for implementing Bicep. The prompts in this article are enough to get started, but these are useful references when formalizing your own process as a Skill or custom agent.

What to Delegate to Copilot and What People Must Decide

Copilot can be a thought partner, identify overlooked questions, develop concrete proposals, and help with implementation and validation. People must still take responsibility for deciding whether to accept its proposals.

For critical systems, also ask specialists such as security, legal, and operations staff or a Cloud Solution Architect to review the proposal. If Copilot has already helped prepare the requirements, architecture diagram, Bicep, cost-estimation assumptions, and unresolved items, the time with specialists can focus on the decisions that matter most.

Summary

You do not need deep Azure expertise, but that does not mean your goal can remain entirely vague. At the same time, you do not need to choose Azure service names and sizes before asking for help.

Tell GitHub Copilot what you want to achieve. It can ask about missing requirements, verify information with the Microsoft Learn MCP Server and Azure MCP Server, and organize a concrete proposal that includes initial sizing. From there, the same process can produce an architecture diagram and Bicep, then deploy the result to Azure for validation.

This site did not begin with a finished design. It grew through this iterative process.

Start by telling GitHub Copilot, “I want to build this on Azure. Ask me what is missing from the design, then propose a concrete first version to try.”