29 ‐ Azure Scenario – Single VNet with No Internet (Blob Storage) - SanjeevOCI/Study GitHub Wiki

Scenario: Single Private VNet with No Internet, Having All Other Services Connected (Blob Storage)

Key Points

  • No Internet access for workloads.
  • Private Endpoint for secure Blob Storage access.
  • NAT Gateway (optional) for outbound updates.
  • 5 reserved IPs per subnet in Azure.
  • NSGs enforce least privilege.

Architecture (Mermaid)

    A[VNet 10.0.0.0/16] --> B[Subnet 10.0.0.0/24]
    B --> C[VM (Private IP only)]
    B --> D[NSG (Restrict inbound/outbound)]
    A --> E[Private Endpoint (Blob Storage)]
    A --> F[NAT Gateway (optional)]

  1. First, I will confirm the subscription and region, as these are mandatory before designing a network. Next, I will plan the VNet and subnets based on resource requirements. As an architect, I should always ask how many services we need to create inside the VNet, and based on that design the IP address range accordingly.

  2. For simplicity, I will consider 10.0.0.0/16 as the VNet IP Address Range. In real-world scenarios, I would calculate the number of resources, and based on that, I would plan the subnets. I will also consider 40–50% additional IPs to accommodate future growth. Generally, I design with a 3-tier architecture, so I ask how many load balancers, application services, and databases will be created. Then, I map my subnets accordingly.

    • Sometimes, even if we need only 32 IPs, we must plan a higher IP Address Range because these IPs will be distributed among multiple subnets.
    • In Azure, there are 5 reserved IPs per subnet, so this must be factored into subnet planning.

    For this scenario, I will create one subnet, say 10.0.0.0/24, since you asked for one resource. If more resources are needed, I will allocate new IP Address Ranges for additional subnets.

  3. Once the VNet and subnet are ready, I will move ahead with services. After defining the network, the next step is to plan gateways and routes. Since the VM needs to connect to services like Blob Storage, I will use a Private Endpoint. I will also provision a NAT Gateway but keep it unused initially, following the least-access principle, in case future outbound connectivity is required.

  4. Next, I will configure the route table. Default system routes are available, but I may need to add custom routes. I will create a route pointing to the Private Endpoint for Blob Storage. Another route will be reserved for the NAT Gateway if needed later.

  5. After this, I will move to security. Before creating an NSG, I must first provision a VM.

    • Required: Subscription, Resource Group, Availability Zone/Set, VM Size (vCPUs/RAM), Image, Subnet (NIC), SSH public key.
  6. Once the VM is created, I will attach a custom NSG instead of the default one. Initially, it will have no allow rules, just the default deny rules. Later, I will add rules as per requirements.

    • For ingress, I will allow port 22 (SSH) because administrators will need access to the VM.
    • The source CIDR will be restricted to the corporate private network range for secure access.
    • If private connectivity to on-premises is needed in the future, ExpressRoute or VPN would be required, along with additional route table and NSG configurations. For now, that is out of scope.
  7. With this setup, we have a private VNet with no internet connectivity, VM resources, NSGs, route tables, and gateways properly planned. This ensures Blob Storage and other Azure services can be securely accessed within the VNet, without exposure to the public internet.