突然ですが 『 サービスエンドポイント 』 ご存じでしょうか？

VNet 内から PaaSサービスのグローバルIPアドレスに向かって、インターネットからのアクセスではなく Azureバックボーンネットワークを経由して通信するための接続オプションです。

ちなみに、似たような接続オプションとして「プライベートエンドポイント」なるものも存在します。

後者は VNet と統合したオンプレミスネットワーク ( VPN / ER ) からでも PaaSサービスの「プライベートIPアドレス」に向かって通信できます。

ですが今回は前者についてです。
サービスエンドポイントを通り Azureバックボーンネットワークを経由する通信にて Azureファイル共有のフォルダをマウントしてみたいと思います。

環境を準備する

以前に書いたこちらの記事の環境に少し手を加えます。

作成する環境のイメージとしては以下の図になります。

サービスエンドポイント

対象となるサブネットに対して「ストレージエンドポイント」という種類のサービスエンドポイントを構成します。

Bicepファイルにおけるシンボリック名でいうと

• subnet1 ➡ パブリックサブネット

• subnet2 ➡ プライベートサブネット

• subnet3 ➡ Bastionホスト専用サブネット

という役割の違う三つのサブネットを作成するのですが、今回対象となるのは subnet2 です。

subnet2 ( プライベートサブネット ) についてはそもそもインターネットにも接続できないようにするわけですが、この状態ではストレージアカウントにもたどり着けません。
そこでサービスエンドポイントを作成することでたどり着けるようにします。

なおサービスエンドポイントは、サービスごと、サブネットごとに有効になります。

今回の場合のサービスとは ストレージアカウントなので 💡 のように記述します。

var subnet2 = { 
    name: 'privateSubnet' 
    properties: { 
      addressPrefix: '${addressPrefix}1.0/24' 
      serviceEndpoints: [ //👈
        { 
          service: 'Microsoft.Storage' //💡 
          locations: [ 
            'japaneast' 
            'japanwest' 
          ] 
        } 
      ] 
      networkSecurityGroup: { 
        id: subnet2nsg.id 
      } 
    } 
}

実際にこれを使ってデプロイしたものは以下となります。

ネットワークセキュリティグループ ( NSG )

プライベートサブネットに紐づける NSG に送信セキュリティ規則を一つ追記します。
これでサブネット（ 厳密には VNet ）からのストレージアカウントへのアクセスは許可するようにできます。

      { 
        name: 'Allow-Storage-All' 
        properties: { 
          direction: 'Outbound' 
          protocol: '*' 
          access: 'Allow' 
          priority: 1000 
          sourceAddressPrefix: 'VirtualNetwork' 
          sourcePortRange: '*' 
          destinationAddressPrefix: 'Storage' 
          destinationPortRange: '*' 
        } 
      }

実際にこれを使ってデプロイしたものは以下となります。

ストレージアカウント

新しく、独立したモジュールファイル 「 storageAccount.bicep 」 を追加しました。

デプロイするリソースは、

• ストレージアカウント ( 1️⃣ )

• ファイル共有 ( 2️⃣ )

の二つです。

💡 については、subnet2 ( プライベートサブネット ) のリソースID の出力値を入れ込みます。
そして 1️⃣ でこのサブネットからのアクセスだけは許可するとします。

param location string 
param subnetId string //💡

var storageAccountName = 'sta'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = { // 1️⃣
  name: '${storageAccountName}${uniqueString(subscription().id)}' 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    networkAcls: { 
      defaultAction: 'Deny' 
      virtualNetworkRules: [ 
        { 
          action: 'Allow' 
          id: subnetId 
        } 
      ] 
    } 
  } 
}
resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2021-09-01' = { // 2️⃣
  name: '${storageAccount.name}/default/forprivate' 
}

実際にこれを使ってデプロイしたものは以下となります。

ストレージアカウント ( 1️⃣ ) の properties ( networkAcls ) 

ファイル共有 ( 2️⃣ ) 

Azure VM ( Windows Server )

今回は 2台の VM を使用します。
subnet1 ( パブリックサブネット ) と subnet2 ( プライベートサブネット ) に 1台ずつ Windows Server をデプロイします。

試してみる

ファイル共有への Z ドライブのマッピングを作成してみる

ありがたいことに、Azure portal で案内してくれる PowerShell スクリプトを Azure VM ( Windows Server ) から実行すると作成できます。

⇩

⇩ 下にスクロール

何やらコマンドが表示されていますのでコピーします。

Azureファイル共有をマウント

それぞれの Windows Server に作成した管理者ユーザーでサインインして PowerShell を起動して先ほどコピーしたコマンドを実行してみます。

詳細が気になる方は以下の公式ドキュメントもご参考ください。

🟡パブリックサブネットの Windows Server の場合

何やら赤字でイヤな感じの応答が返ってきていますね。

New-PSDrive : Access is denied

はい、狙い通りアクセスが拒否されています。

当然ですがエクスプローラーを見ても Zドライブはありませんね。

🟢プライベートサブネットの Windows Server の場合

CMDKEY: Credential added successfully. 
Name           Used (GB)     Free (GB) Provider      Root                                 CurrentLocation 
----           ---------     --------- --------      ----                                 --------------- 
Z                   0.00       5120.00 FileSystem    \\staavsgjemr76bak.file.core.win...

こちらはマウントがうまくいったようです。

エクスプローラーを見ると Zドライブが現れました。
狙い通りですね。

インターネットへのアクセス

PowerShell ( Test-NetConnection コマンドレット ) と Webブラウザで note.com にアクセスしてどのような応答が返ってきたか確認します。

🟡パブリックサブネットの Windows Server の場合

PS C:\Users\azureuser> Test-NetConnection -ComputerName note.com -Port 80 
ComputerName     : note.com 
RemoteAddress    : 13.32.50.5 
RemotePort       : 80 
InterfaceAlias   : Ethernet 
SourceAddress    : 10.10.0.4 
TcpTestSucceeded : True

はい、特に問題なくネットワークの疎通が確認できました。

ブラウザの場合はどうかというと

こちらも特に問題ありません。

🟢プライベートサブネットの Windows Server の場合

PS C:\Users\azureuser> Test-NetConnection -ComputerName note.com -Port 80 
WARNING: TCP connect to (18.65.202.117 : 80) failed 
WARNING: TCP connect to (18.65.202.37 : 80) failed 
WARNING: TCP connect to (18.65.202.34 : 80) failed 
WARNING: TCP connect to (18.65.202.111 : 80) failed 
WARNING: Ping to 18.65.202.117 failed with status: TimedOut 
WARNING: Ping to 18.65.202.37 failed with status: TimedOut 
WARNING: Ping to 18.65.202.34 failed with status: TimedOut 
WARNING: Ping to 18.65.202.111 failed with status: TimedOut 
ComputerName           : note.com 
RemoteAddress          : 18.65.202.117 
RemotePort             : 80 
InterfaceAlias         : Ethernet 
SourceAddress          : 10.10.1.4 
PingSucceeded          : False 
PingReplyDetails (RTT) : 0 ms 
TcpTestSucceeded       : False

はい、先ほどとは異なり疎通に問題ありです。

ブラウザの場合はどうかというと

はい、こちらも当然ながら表示できません。

🟠 さいごに 🔚

ということで、狙い通りの環境がデプロイできました。

ざっくり言えばプライベートエンドポイントの方が優秀といった感じですが、万能ではありませんし要件によってはこのようなサービスエンドポイントが必要になるかもしれません。
そんな時にはぜひ使ってみてください。

今後も Azure に関する技術情報やその他の資格試験に関する記事を書いていこうと思いますので、よろしければフォローをお願いします🔆

また、この記事が少しでもタメになった、面白かったという方がいらっしゃいましたら、ぜひ 「 スキ 」 ボタンのクリックをお願いします😋

最後までお読みいただきありがとうございました 😊

▶ おススメ Azure 学習書籍