跟讀練習: Azure App Service and Virtual Network Integration Options - 通過影片學習英語口語

選擇練習模式

每種模式都會開啟全屏練習室。

315 句

如果句子過短或過長，請點選 Edit 進行調整。

Hey everyone.

In this video, I want to talk about the relationship and the interaction between app services and virtual networks.

Because there seems to be a lot of questions coming in about,

well, do I use a private endpoint?

Do I use VNet integration?

Do I use a gateway?

So let's kind of look at this.

So app services were actually one of the original Azure services way back

when it first started and gone through a lot of innovation around now.

So I can think about,

well, I have my app service plan.

Now, normally this is a multi-tenant model.

There's a certain stamp of infrastructure that has front ends.

There's data roles.

There's file services.

So that is shared by the customers on that particular staff.

There's a single inbound IP address.

You can get a unique IP address if you really want it through the kind of SSL option.

Then there's multiple outbound IP addresses.

We have this shared set of front ends,

the data roles, the file servers.

And then unique per customer,

you have a number of workers.

These are the things where you say,

hey, this is the type of worker on the SKU.

These can auto scale.

And this is where when you create your particular kind of web app,

etc., it's running on your workers.

So the workers, they're unique to you.

Then there's that other shared set of infrastructure.

And then you have kind of your virtual network.

So over here I'm creating my VNet,

which again is kind of a set of IP addresses.

And the challenge we have is really two.

The first one is the apps running in my app service plan

want to be able to reach resources running in my VNet.

And or, well maybe there's other VNets that I have tiered them.

And or there's on-premises resources that I happen to have connected via site-to-site VPN or ExpressRoute.

So from the app, maybe there's a database,

there's some other tier of service.

I want to be able to get to things here.

And then I've got resources running here that want to be able to privately get to the app.

Remember, the multi-tenant model, there's an inbound IP address that's public facing.

And maybe I want to lock that down.

So what can I do with that?

So we have these two different requirements.

Now, when we think about that,

let's start off thinking about going to our application.

And the first solution is kind of a very familiar one.

It's service endpoints.

So if we think about,

well, hey, look, we've got our virtual network here.

And we think about, well,

we divide this into subnets.

So I can think about,

well, I have a particular subnet here.

And what I can do is I can turn on the service endpoint.

So the service endpoint is going to be that Microsoft.web.

Now, this particular subnet can be known to app services.

So now on this app service,

it has kind of its set of inbound controls.

I can actually specify, hey,

well, on those inbound controls,

you can imagine it's kind of like a firewall into the app service.

I'm only going to allow in,

and we'll call this subnet one,

well I'm going to say subnet one, yes, you're allowed.

So it's still technically going through the public IP address,

but when I do the service endpoint,

remember it creates the optimized route,

so it's not just bouncing around the regular edge routers,

etc. It's doing a very direct route,

really as optimized as it can get.

And I'm now restricting it through its rules to say,

hey, only coming from this particular subnet.

Now the challenge with this is service endpoints,

it's just for things in the subnet.

What about if I want to get to it from other networks or on-premises?

So one of the things I can kind of add to this is,

well, I can actually do something like AppGateway.

If I deployed AppGateway into that subnet with the service endpoint of Microsoft.web,

other things would come into the AppGateway and essentially proxy through and then go via that path.

So this gives me that ability.

So it's still going to the public endpoint,

but it's completely locked down.

I can't get to it from anywhere other than the subnet to the service endpoint that I have enabled.

So it's all about, hey,

from our vNet, wanting to go to that particular app.

The other option, well, there is one other,

but the other main option for controlling giving access that way is private endpoints.

So that's obviously very, very common today.

More and more services are kind of adopting this.

So the private endpoint, there's an IP address is consumed from a particular subnet in our virtual network that essentially

is natting the traffic to that.

I could now completely again lock down the app to not allow anything other than this particular private endpoint.

And that's going to work for kind of Windows apps,

Linux apps, even Windows containers today.

So at this precise moment,

as I'm recording, it's previewed,

100

but I think it's going to come out of that any day.

101

So again, that's the other option,

102

private endpoint, I would then access that IP address.

103

And the great thing about private endpoint is it is just an IP in this VNet.

104

So any network that is connected to this VNet can see the IP and use it.

105

I just have to make sure I have the consistent DNS in place so it works and resolves to the private endpoint.

106

I mentioned there was another.

107

There is, of course, IP address restrictions that I can use on this thing.

108

So if I know the IP address the request is coming from,

109

I can restrict it to just that IP address.

110

So if, for example, I could have a NAT gateway,

111

I could have a standard load balancer with outbound rules,

112

I know the outbound IP,

113

I could use that as well.

114

But honestly, if I'm talking about something in the VNet talking to it,

115

that service endpoint is a better option.

116

It's really locking it down to that particular subnet. So great.

117

that addressed things going from the VNet talking to the app.

118

What about the other direction?

119

Now, my application wants to be able to talk to things actually within the virtual network.

120

Now, option one is not really well suited to this.

121

Option one is suited to the idea that,

122

hey, there's some resource on-premises,

123

could be a database, some other component,

124

that I want the app to talk to.

125

And this is where we actually go and use hybrid connections.

126

So with hybrid connections, we have this hybrid connection manager that we deploy.

127

It establishes an outbound connection over 443 to Azure Relay,

128

which then lets the app talk to the service.

129

Now, this is only TCP.

130

It's a particular TCP port and endpoint.

131

So I'd have to have one of these for each different sort of sets of things I want to talk to.

132

It's TCP only.

133

I can't do UDP over this thing.

134

But now it's established the outbound connection which now enables the app to go

135

and talk to whatever source this is kind of offering.

136

It could be a database, for example.

137

So technically, I could deploy a hybrid connection manager in my VNet.

138

It would establish that outbound 443 to the Azure Relay,

139

which would now enable that direction of connectivity.

140

So absolutely, I can do that.

141

It doesn't make the most sense in the world, though.

142

There's better solutions for that. And we have two.

143

So the first is a gateway required VNet integration.

144

So as the name kind of suggests,

145

I have to have a gateway.

146

So I can think about it,

147

we use a different color.

148

So here I'm gonna have a gateway.

149

And it has to support point to site VPN.

150

So we're gonna do the route based dynamic.

151

And what's gonna happen here is my app is essentially gonna establish a point to site VPN connection.

152

So it is gonna go and connect to the gateway,

153

so I have to have the gateway.

154

Remember the gateway lives in its own kind of dedicated subnet.

155

And then from there, well,

156

it would be able to talk to those things.

157

Now, this does not allow me to go and traverse the things like ExpressRoute.

158

What is nice about this gateway option is,

159

well, actually that gateway where you could live in any Azure region.

160

So maybe the app service plan is South Central.

161

I wanna go and talk to a VNet that's in East or West or Europe.

162

This will work.

163

I can have a gateway in other regions and it will be able to go and talk to it.

164

Also, this will work with classic virtual networks.

165

So the old style before ARM,

166

I could have the gateway there and I could do a point to site VPN connection to it.

167

So that's one option.

168

The preferred option is regional vNet integration.

169

So we're going to kind of draw this in yet another color.

170

We'll do this in gold.

171

So with regional vNet integration,

172

as the name kind of suggests,

173

we have a particular subnet.

174

Now this is going to be delegated for this app to integrate in.

175

So now what we're going to do is this app is essentially going to take over this subnet,

176

and it's going to consume IP addresses within that subnet.

177

This has to be in the same region as the app.

178

That's why it's regional VNet integration.

179

I cannot use this if I want to talk to a VNet that's in a different region.

180

I cannot use this to talk to a classic virtual network.

181

So this is the best solution if the VNet is in the same region as the app.

182

But if it's a different region,

183

it's classic, I'll have to go for the gateway approach.

184

Now, what's going to happen here,

185

remember these workers, each worker is going to consume an IP address in this kind of delegated subnet.

186

And I can't use this subnet for anything else.

187

it's locked down only the app service plan.

188

So if I had three workers,

189

I'd be consuming three IP addresses.

190

So when I'm sizing this subnet,

191

I have to think about what's the maximum scale I'm ever gonna do,

192

and then double it.

193

Because let's say I was gonna have eight workers at max.

194

Remember, if I resize my workers,

195

the way Azure works is it spins up eight new ones of the new size,

196

make sure they're working, and then deletes the old one.

197

So it'd have the eight existing,

198

the eight new ones, and then it would delete the old.

199

So I'd have double that number.

200

So when I think about sizing,

201

make sure it's double the maximum number of workers you're ever gonna have.

202

Remember, you lose five IP addresses.

203

So the host, the broadcast,

204

the three Azure ones that it steals.

205

So make sure you size this subnet.

206

So you're gonna size this subnet.

207

So if I thought I was gonna have eight workers,

208

I think, well, I need 16 usable IP addresses,

209

then I'd probably make that kind of a slash 27.

210

If you're not short on IP addresses,

211

maybe just give it a slash 24.

212

But make sure you size it correctly.

213

So from here, it can now go and talk to things in that virtual network.

214

It can talk to things over the express route.

215

So I can go and talk to that as well.

216

It cannot talk to peer networks.

217

So if I had another network that's peered, it's not gonna work.

218

If it was a regional peer, it's not gonna work.

219

That's what's called regional Vignette Peering.

220

It doesn't support peering itself today.

221

It's just a regional integration.

222

Now, if I had private endpoints within this virtual network talking to other services,

223

maybe I've got a particular storage account or something.

224

Well now, this app through the Vignette integration can go and talk via the private endpoint to that storage.

225

So I can start to lock those things that way,

226

it can work together like that.

227

So what do we kind of have to the app?

228

I can do IP access restrictions,

229

but generally we're gonna do a service endpoint for the Microsoft.web.

230

If I need beyond the subnet,

231

I can always proxy via App Gateway,

232

or I can use private endpoints.

233

from the app to my resources,

234

well, yeah, I can use the hybrid connections.

235

Doesn't make the most sense.

236

I can use the gateway,

237

point to site, works across different regions.

238

Best option is the VNet integration.

239

Today, VNet has to be the same region,

240

actually has the app itself.

241

One caveat to all of these things,

242

and there's different types of kind of app,

243

like running an app service plan,

244

web apps, mobile apps, API apps, and functions.

245

Now remember, functions can be serverless.

246

If I wanna use functions,

247

and I wanna use these kind of capabilities,

248

with the exception of the service endpoints and the IP restrictions,

249

if I wanna do functions,

250

I have to run it in kind of a dedicated,

251

I am running it in a regular app service plan of workers,

252

or I think it's kind of the elastic premium,

253

which is fairly close to a kind of dedicated.

254

I cannot do the pure consumption,

255

the regular consumption, can't spell,

256

functions will not work for most of these things,

257

because it can't, there's no dedicated set of resources establish this.

258

So if you want to use Azure Functions,

259

I want to use private endpoints,

260

I want to use the VNet integration,

261

I need to run it on a dedicated App Service Plan or Elastic Premium,

262

then I can get that.

263

Now there is of course one other option and this is the ACE.

264

So if I just draw a brand new picture for this one super quick,

265

I can think about once again,

266

I have my virtual network,

267

so I have my VNet.

268

And remember before we talked about there's all those shared components like the data stores,

269

the file servers, the front ends,

270

and then there was the workers.

271

With an ACE, what actually happens is I have a particular subnet,

272

and then I deploy my app service environment into that directly.

273

So I can think about within here,

274

I have kind of the front ends,

275

I have kind of the file servers,

276

and I have my workers.

277

So these are now actually running in the subnet in my virtual network.

278

It's dedicated, it's all dedicated to me.

279

So now if there are other resources in the vnet

280

or cover connected well there's no other integration required this stuff's

281

sitting in the subnet there's different types of ace there's internal

282

external in terms of what it's facing you would do internal

283

if you wanted that direction but now it's on the subnet

284

inside that ace i would create one or more app service plans where i'd run my apps

285

and they'll now have that full kind of connectivity to it.

286

So that's the other option.

287

The downside is the ACE is more expensive because I'm not getting the benefit of those shared components anymore.

288

I kind of split the cost with other tenants and they're all running inside my subnet.

289

But this was kind of the traditional way we had to have kind of that private connectivity in the past.

290

But now we have all those other great private endpoints,

291

service endpoints, Bnet integration, etc. One note,

292

if you do this, remember there is still kind of the Azure Resource Manager management plane and lots of other things.

293

This still has to be able to talk to that.

294

If you do a bunch of controls and locks and things on this and lock it down so much,

295

you can break it.

296

There's actually a lot of different communications required.

297

They're all documented, but don't think I can just deploy an ACE and then turn everything off,

298

it's gonna break.

299

So there's still communications required with the kind of arm management,

300

but this is another option.

301

It's just they are in your vNet.

302

That wouldn't be my first choice because of the cost.

303

There's more things involved.

304

Ideally, you'll kind of look at these And in the ideal world,

305

it's the same region.

306

I'm probably going to use the regional network integration option and private endpoints or those kind of service endpoints.

307

We'll hopefully do what you need.

308

So, again, I hope this was useful.

309

I was trying to clear up the distinction.

310

I'm going to need one of each.

311

VNet integration doesn't provide me with the ability to talk to the service.

312

VNet integration is app talking stuff here and then private endpoints or service endpoints go in the other way.

313

So, it's different technologies.

314

they're all unidirectional they do one of the requirements we have hope this was useful again please like comment subscribe

315

and share if it was until next time take care

下載應用

流利口語所需的一切

AI 發音評分逐句打分

音標練習掌握每個音

詞彙學習建立你的詞庫

詞彙遊戲邊玩邊學

掃碼

Download on theApp Store Get it onGoogle Play

FOR YOU

本節課簡介

在這節課中，您將學習如何描述 Azure 應用服務和虛擬網路之間的關係和互動。通過分析影片中講述的內容，您將掌握與應用程式服務相關的核心概念，並瞭解如何通過虛擬網路整合它們的基礎設施。我們將介紹一些重要的術語和短語，幫助您在與他人討論時更加自信。

關鍵詞彙與短語

應用服務 (App Service): Azure 提供的一種服務，允許開發者構建和託管 web 應用。
虛擬網路 (Virtual Network, VNet): 一種網路服務，用於連線和隔離 Azure 中的資源。
服務終結點 (Service Endpoints): 用於允許應用訪問其他 Azure 服務的功能。
多租戶模型 (Multi-tenant Model): 多個客戶共享相同基礎設施的模式。
私有終結點 (Private Endpoint): 允許在私有網路中安全訪問 Azure 服務的方式。
IP 地址 (IP Address): 用於識別計算機或網路裝置的地址。
自動擴充套件 (Auto Scale): 根據流量自動調整資源的能力。

練習技巧

為幫助您提高英語發音和口語能力，建議您使用影子練習（shadowing）的方法。影子練習是一種通過模仿原音軌道的發音和語調來提升語言能力的技巧。在觀看本影片時，可以根據以下幾點進行練習：

隨著影片的播放，緩慢模仿演講者的發音和語調，幫助您更好地理解聲音的韻律和強調。
嘗試重複演講者的語言片段，專注於發音，以提高您的英語口語練習效果。
調整播放速度，在較慢的速度下練習，然後逐漸提高至正常速度，幫助您適應不同的說話速度。
在重要短語上停頓，例如“私有終結點”和“自動擴充套件”，確保您掌握這些關鍵概念。
使用不同場景進行雅思口語練習，嘗試將影片中學到的知識應用於真實對話中。

通過這些實踐，您將逐漸提高英語發音和口語交流能力，為未來的學習打下堅實的基礎。

影片中的語法

說話人最常用的結構，並附上影片中的原話：

結構	影片中的用法
被動語態 be + 過去分詞 — 強調發生了什麼，而不是誰做的	is shared · can be known · is consumed
現在完成時 have/has + 過去分詞 — 過去發生但與現在仍有關聯的事	have tiered · have enabled

什麼是跟讀法？

跟讀法 (Shadowing) 是一種有科學依據的語言學習技巧，最初開發用於專業口譯員的培訓，並由多語言者Alexander Arguelles博士普及。這個方法簡單而強大：您在聽英語母語原聲的同時立即大聲重複——就像是一個延遲1-2秒緊跟說話者的影子。與被動聽力或語法練習不同，跟讀法強迫您的大腦和口腔肌肉同時處理並模模擬實的講話模式。研究表明它能顯著提高發音準確性，語調，節奏，連讀，聽力理解和口語流利度——使其成為雅思口語備考和真實英語交流最有效的方法之一。

影子跟讀法: 閱讀完整分步指南 →

跟讀練習: Azure App Service and Virtual Network Integration Options - 通過影片學習英語口語

選擇練習模式

下載應用

推薦影片

Technical deep dive on Managed Instance for App Service | BRK102

Every Networking Concept Explained | Networking 101 (2026)

Top 5 AI Gateway Use Cases | Solo.io

BAS Bootcamp: Day 6 Setting up IO Internally

Understand Microsoft Entra ID | AZ-104 | Episode 2

Design a File Upload Service Like a Senior Engineer

OWASP Top 10 Explained

BGP Overview

Armchair Architects: Resiliency in the Cloud – Core Patterns

LangChain in 5 Minutes (Explained Clearly)

Mini Project - Implementing a Simple Web Identity Federation Application

What is a server? Types of Servers? Virtual server vs Physical server 🖥️🌐

本節課簡介

關鍵詞彙與短語

練習技巧

影片中的語法

什麼是跟讀法？