The Hybrid Illusion: Why AWS is Losing the Enterprise Control Plane

1
00:00:00,000 --> 00:00:03,600
Most organizations believe AWS is winning the cloud war,

2
00:00:03,600 --> 00:00:06,000
but they are looking at the wrong battlefield.

3
00:00:06,000 --> 00:00:08,400
While AWS still runs more global workloads

4
00:00:08,400 --> 00:00:10,400
than any other competitor enterprise control

5
00:00:10,400 --> 00:00:12,680
has shifted to a different arena entirely.

6
00:00:12,680 --> 00:00:15,000
The original cloud war focused on infrastructure,

7
00:00:15,000 --> 00:00:17,160
specifically who could provision compute fastest,

8
00:00:17,160 --> 00:00:19,880
scale storage cheapest and offer the broader service catalog.

9
00:00:19,880 --> 00:00:21,760
AWS won that war decisively,

10
00:00:21,760 --> 00:00:24,440
yet the new conflict centers on something else,

11
00:00:24,440 --> 00:00:28,520
identity, policy, and governance across the entire organization.

12
00:00:28,520 --> 00:00:30,800
In this environment, Microsoft has positioned itself

13
00:00:30,800 --> 00:00:33,280
as the control plane, while AWS continues

14
00:00:33,280 --> 00:00:34,840
to build the infrastructure underneath.

15
00:00:34,840 --> 00:00:37,480
Over 80% of enterprises are currently hybrid

16
00:00:37,480 --> 00:00:39,520
and will remain so through 2027,

17
00:00:39,520 --> 00:00:41,480
which is not a failure of cloud migration

18
00:00:41,480 --> 00:00:42,480
or a lack of commitment.

19
00:00:42,480 --> 00:00:44,400
Hybrid is the architectural end state.

20
00:00:44,400 --> 00:00:46,680
In these environments, the winner is not the provider

21
00:00:46,680 --> 00:00:47,720
with the most compute,

22
00:00:47,720 --> 00:00:50,240
but the one controlling identity, policy,

23
00:00:50,240 --> 00:00:53,280
and workflow across the entire organization.

24
00:00:53,280 --> 00:00:54,440
That is Microsoft.

25
00:00:54,440 --> 00:00:56,160
The infrastructure war is over.

26
00:00:56,160 --> 00:00:57,560
AWS won.

27
00:00:57,560 --> 00:01:00,160
We should be clear about what AWS actually accomplished.

28
00:01:00,160 --> 00:01:01,840
AWS dominates raw market share

29
00:01:01,840 --> 00:01:04,480
with 32% of global cloud infrastructure spending

30
00:01:04,480 --> 00:01:08,200
and offers 230 services across compute, storage, networking,

31
00:01:08,200 --> 00:01:09,200
and AI.

32
00:01:09,200 --> 00:01:12,760
With 33 regions and 105 availability zones,

33
00:01:12,760 --> 00:01:16,360
they built a mature ecosystem with deep DevOps automation

34
00:01:16,360 --> 00:01:20,840
and cost optimization tools that competitors still cannot match.

35
00:01:20,840 --> 00:01:24,240
The victory AWS achieved in infrastructure is not in question

36
00:01:24,240 --> 00:01:25,920
as it is a historical fact.

37
00:01:25,920 --> 00:01:27,560
However, here is the uncomfortable part

38
00:01:27,560 --> 00:01:30,080
that dominance does not translate to dominance in governance

39
00:01:30,080 --> 00:01:31,920
because the battleground has simply moved.

40
00:01:31,920 --> 00:01:34,760
Enterprises have stopped asking which cloud they should build on.

41
00:01:34,760 --> 00:01:37,520
As that question was settled years ago for most organizations,

42
00:01:37,520 --> 00:01:39,160
they asked it, received an answer,

43
00:01:39,160 --> 00:01:41,200
and moved on to a completely different problem.

44
00:01:41,200 --> 00:01:44,320
How to govern identity and policy across multiple clouds?

45
00:01:44,320 --> 00:01:45,680
That question has a different answer.

46
00:01:45,680 --> 00:01:48,280
This shift happened gradually, but around 2020,

47
00:01:48,280 --> 00:01:50,600
enterprises started noticing a significant problem

48
00:01:50,600 --> 00:01:51,880
with their architectural sprawl.

49
00:01:51,880 --> 00:01:55,560
They had workloads on AWS, Azure, and Google Cloud.

50
00:01:55,560 --> 00:01:58,720
Along with on-premises infrastructure, they could not decommission.

51
00:01:58,720 --> 00:02:01,640
Managing five different identity systems became untenable

52
00:02:01,640 --> 00:02:04,480
because it meant maintaining five different audit trails,

53
00:02:04,480 --> 00:02:06,080
five compliance frameworks,

54
00:02:06,080 --> 00:02:08,400
and five different places to revoke access

55
00:02:08,400 --> 00:02:10,640
when an employee left the company.

56
00:02:10,640 --> 00:02:14,000
The result was a new demand, unified identity.

57
00:02:14,000 --> 00:02:17,480
AWS responded to this need with IAM Identity Center,

58
00:02:17,480 --> 00:02:20,680
which is a solid product for providing SSO and MFA

59
00:02:20,680 --> 00:02:21,920
across AWS accounts.

60
00:02:21,920 --> 00:02:24,520
But the architectural truth is that IAM Identity Center

61
00:02:24,520 --> 00:02:27,640
originates in AWS and is built specifically for AWS.

62
00:02:27,640 --> 00:02:29,600
When you federated to other platforms,

63
00:02:29,600 --> 00:02:32,600
you are extending AWS Identity outward

64
00:02:32,600 --> 00:02:35,120
and claiming that AWS is the source of truth.

65
00:02:35,120 --> 00:02:37,960
Microsoft EntraID approaches the problem from a different angle.

66
00:02:37,960 --> 00:02:39,880
EntraID originates in the workforce

67
00:02:39,880 --> 00:02:42,160
and is built for humans and their applications,

68
00:02:42,160 --> 00:02:43,360
rather than just servers.

69
00:02:43,360 --> 00:02:45,600
When EntraID federates with AWS,

70
00:02:45,600 --> 00:02:47,880
the Microsoft Identity Engine issues the tokens

71
00:02:47,880 --> 00:02:51,240
that grant AWS access, which is not a state of coexistence.

72
00:02:51,240 --> 00:02:53,120
It is subordination, the enterprise no longer

73
00:02:53,120 --> 00:02:54,880
sees two identity systems,

74
00:02:54,880 --> 00:02:57,200
but rather one Microsoft system managing access

75
00:02:57,200 --> 00:03:00,520
to multiple platforms that difference in origin matters at scale.

76
00:03:00,520 --> 00:03:03,240
When identity originates in one place and governs everywhere,

77
00:03:03,240 --> 00:03:06,160
you create control plane gravity that compounds over time.

78
00:03:06,160 --> 00:03:09,000
AWS built a cloud for developers and infrastructure teams

79
00:03:09,000 --> 00:03:11,560
by optimizing for rapid provisioning, cost flexibility

80
00:03:11,560 --> 00:03:13,000
and regional distribution.

81
00:03:13,000 --> 00:03:14,960
All of those features are valuable,

82
00:03:14,960 --> 00:03:17,800
but enterprises do not actually run on infrastructure.

83
00:03:17,800 --> 00:03:19,920
They run on identity policy and workflow.

84
00:03:19,920 --> 00:03:23,480
AWS either did not anticipate that shift or decided

85
00:03:23,480 --> 00:03:25,720
it was not a battle they wanted to fight.

86
00:03:25,720 --> 00:03:28,720
By 2023, the pattern was clear as enterprises standardized

87
00:03:28,720 --> 00:03:31,280
on Microsoft 365 for workforce collaboration

88
00:03:31,280 --> 00:03:33,160
through teams, SharePoint and Outlook.

89
00:03:33,160 --> 00:03:37,080
Over 95% of Fortune 500 companies use Microsoft 365,

90
00:03:37,080 --> 00:03:39,560
which is not a cloud choice so much as an identity choice

91
00:03:39,560 --> 00:03:41,880
because governance sits where the work happens.

92
00:03:41,880 --> 00:03:45,080
Microsoft owns the enterprise by owning the employee surface area.

93
00:03:45,080 --> 00:03:48,400
AWS owns the compute, but Microsoft owns the people.

94
00:03:48,400 --> 00:03:50,440
This is the inversion that nobody talks about.

95
00:03:50,440 --> 00:03:52,840
The infrastructure war is over and AWS won,

96
00:03:52,840 --> 00:03:55,040
but the enterprise war that determines how organizations

97
00:03:55,040 --> 00:03:58,040
actually operate is being decided on different terms.

98
00:03:58,040 --> 00:04:00,680
Those terms favor the company that controls identity,

99
00:04:00,680 --> 00:04:03,240
not the company that controls instances.

100
00:04:03,240 --> 00:04:05,080
What a control plane actually is,

101
00:04:05,080 --> 00:04:06,720
we need to define this term precisely

102
00:04:06,720 --> 00:04:09,480
because it gets thrown around until it loses all meaning.

103
00:04:09,480 --> 00:04:11,560
A control plane is not infrastructure

104
00:04:11,560 --> 00:04:13,840
and it is certainly not a collection of servers.

105
00:04:13,840 --> 00:04:15,880
It is the underlying system that governs

106
00:04:15,880 --> 00:04:17,800
who accesses what when they do it.

107
00:04:17,800 --> 00:04:20,160
And the specific conditions required for that access

108
00:04:20,160 --> 00:04:21,320
to be granted.

109
00:04:21,320 --> 00:04:23,400
In the era of traditional enterprise IT,

110
00:04:23,400 --> 00:04:26,520
Active Directory functioned as the primary control plane.

111
00:04:26,520 --> 00:04:28,480
It sat physically in the data center

112
00:04:28,480 --> 00:04:31,200
and controlled which users could log into which machines

113
00:04:31,200 --> 00:04:32,880
while managing group memberships

114
00:04:32,880 --> 00:04:34,560
and enforcing password policies.

115
00:04:34,560 --> 00:04:36,280
Everything in the environment flowed through it

116
00:04:36,280 --> 00:04:38,560
because it represented the single authoritative source

117
00:04:38,560 --> 00:04:39,880
of truth for identity.

118
00:04:39,880 --> 00:04:41,760
In the cloud, the control plane has shifted

119
00:04:41,760 --> 00:04:43,400
into something more complex.

120
00:04:43,400 --> 00:04:45,320
It is no longer just about managing machines

121
00:04:45,320 --> 00:04:48,000
but rather about identity, policy enforcement

122
00:04:48,000 --> 00:04:50,880
and compliance across every fragmented environment you own.

123
00:04:50,880 --> 00:04:52,280
This includes your cloud footprint,

124
00:04:52,280 --> 00:04:53,840
your remaining on-premises hardware,

125
00:04:53,840 --> 00:04:57,000
the edge and every SAS application your employees touch.

126
00:04:57,000 --> 00:04:58,600
A modern control plane is defined

127
00:04:58,600 --> 00:05:01,200
by three specific architectural components.

128
00:05:01,200 --> 00:05:03,160
First identity must be the origin point.

129
00:05:03,160 --> 00:05:05,520
I'm not talking about federation or synchronization

130
00:05:05,520 --> 00:05:07,400
but the actual origin where user accounts

131
00:05:07,400 --> 00:05:09,720
are created, managed and eventually revoked.

132
00:05:09,720 --> 00:05:12,320
This is the authoritative source where a person exists first

133
00:05:12,320 --> 00:05:13,400
when they join the company

134
00:05:13,400 --> 00:05:15,680
and where they are deleted first when they leave.

135
00:05:15,680 --> 00:05:16,920
In a functional architecture,

136
00:05:16,920 --> 00:05:19,760
every other system is merely downstream from this point.

137
00:05:19,760 --> 00:05:22,280
Second, policy must travel with the identity

138
00:05:22,280 --> 00:05:24,760
rather than sitting as a static rule in a database.

139
00:05:24,760 --> 00:05:27,440
These are dynamic policies that evaluate context

140
00:05:27,440 --> 00:05:30,880
in real time to determine if a login should be allowed.

141
00:05:30,880 --> 00:05:33,400
The system asks where the user is signing in from,

142
00:05:33,400 --> 00:05:34,880
whether their device is compliant

143
00:05:34,880 --> 00:05:36,920
and if their risk profile has suddenly spiked.

144
00:05:36,920 --> 00:05:38,360
Based on those shifting signals,

145
00:05:38,360 --> 00:05:41,560
the engine can enforce MFA, block access entirely

146
00:05:41,560 --> 00:05:43,360
or demand full device management.

147
00:05:43,360 --> 00:05:45,280
This is the reality of conditional access

148
00:05:45,280 --> 00:05:46,800
and continuous verification,

149
00:05:46,800 --> 00:05:48,560
which stands as the direct opposite

150
00:05:48,560 --> 00:05:50,280
of the old model where authentication

151
00:05:50,280 --> 00:05:52,040
equaled permanent trust.

152
00:05:52,040 --> 00:05:54,520
Third, governance must span every environment

153
00:05:54,520 --> 00:05:56,960
instead of being isolated to a single platform.

154
00:05:56,960 --> 00:05:59,880
You need one audit trail, one compliance dashboard

155
00:05:59,880 --> 00:06:01,800
and one centralized place to review

156
00:06:01,800 --> 00:06:04,600
who has access to what across the entire enterprise.

157
00:06:04,600 --> 00:06:07,960
This provides a single location to enforce data residency rules

158
00:06:07,960 --> 00:06:10,160
and prove to regulators that you are managing access

159
00:06:10,160 --> 00:06:13,360
correctly without jumping between a dozen different consoles.

160
00:06:13,360 --> 00:06:16,680
Now let's look at how AWS IAM compares to this model.

161
00:06:16,680 --> 00:06:20,520
AWS IAM is a resource-centric system designed specifically

162
00:06:20,520 --> 00:06:23,320
to control access to AWS resources.

163
00:06:23,320 --> 00:06:25,920
You define roles and attach policies to those roles

164
00:06:25,920 --> 00:06:28,360
to specify exactly which actions can be performed

165
00:06:28,360 --> 00:06:29,880
on which buckets or instances.

166
00:06:29,880 --> 00:06:33,240
An IAM user might assume a role to read from an S3 bucket

167
00:06:33,240 --> 00:06:36,280
while another role allows them to launch EC2 instances.

168
00:06:36,280 --> 00:06:39,000
While this is granular and undeniably powerful,

169
00:06:39,000 --> 00:06:42,280
the system is fundamentally built around resources, not people.

170
00:06:42,280 --> 00:06:45,280
The critical distinction is that AWS IAM does not

171
00:06:45,280 --> 00:06:47,320
originate identity for the enterprise.

172
00:06:47,320 --> 00:06:50,080
It originates identity specifically for AWS.

173
00:06:50,080 --> 00:06:54,440
When you create an IAM user, that user exists within an AWS account

174
00:06:54,440 --> 00:06:56,560
rather than within your actual organization.

175
00:06:56,560 --> 00:06:59,200
If your company operates multiple AWS accounts,

176
00:06:59,200 --> 00:07:01,280
you end up with multiple identity silos

177
00:07:01,280 --> 00:07:04,680
that require federation or AWS organizations to manage.

178
00:07:04,680 --> 00:07:08,680
Even then, the origin of that identity remains tethered to AWS.

179
00:07:08,680 --> 00:07:11,000
Microsoft Enter ID is an identity-centric system

180
00:07:11,000 --> 00:07:13,080
that attempts to control access to everything.

181
00:07:13,080 --> 00:07:14,960
It starts by asking who the person is,

182
00:07:14,960 --> 00:07:16,520
which applications they should access,

183
00:07:16,520 --> 00:07:18,080
what data they are allowed to see,

184
00:07:18,080 --> 00:07:19,560
and which devices they are using.

185
00:07:19,560 --> 00:07:20,880
It originates in the workforce.

186
00:07:20,880 --> 00:07:22,920
When you create a user in Enter ID,

187
00:07:22,920 --> 00:07:25,120
they are a person in your organizational directory

188
00:07:25,120 --> 00:07:29,560
who can access Azure, Microsoft 365, and thousands of SAS apps.

189
00:07:29,560 --> 00:07:33,000
They can even access AWS via SAML or OIDC trust.

190
00:07:33,000 --> 00:07:35,120
When Enter ID federates AWS,

191
00:07:35,120 --> 00:07:37,440
the Microsoft Identity Engine is the one issuing

192
00:07:37,440 --> 00:07:39,920
the tokens that grant access to the Amazon Cloud.

193
00:07:39,920 --> 00:07:43,600
The enterprise sees one identity system managing multiple platforms,

194
00:07:43,600 --> 00:07:47,080
which effectively turns AWS into just another resource

195
00:07:47,080 --> 00:07:49,320
that enter authenticated users can access.

196
00:07:49,320 --> 00:07:50,920
This is not a state of coexistence,

197
00:07:50,920 --> 00:07:53,800
but rather a form of architectural subordination.

198
00:07:53,800 --> 00:07:55,720
This distinction matters because of scale

199
00:07:55,720 --> 00:07:57,880
and what I call control plane gravity.

200
00:07:57,880 --> 00:08:01,000
When identity originates in one place and governs everywhere,

201
00:08:01,000 --> 00:08:03,400
that gravity begins to compound over time.

202
00:08:03,400 --> 00:08:05,920
Every new application that needs to authenticate users

203
00:08:05,920 --> 00:08:08,160
naturally gravitates toward that origin point,

204
00:08:08,160 --> 00:08:10,120
and every new policy requiring enforcement

205
00:08:10,120 --> 00:08:11,640
moves toward the governance layer.

206
00:08:11,640 --> 00:08:14,640
Eventually, that gravity becomes inescapable for the organization.

207
00:08:14,640 --> 00:08:18,040
AWS IAM provides roles and policies that are largely static,

208
00:08:18,040 --> 00:08:20,360
meaning a user either has permission to access a resource

209
00:08:20,360 --> 00:08:21,400
or they do not.

210
00:08:21,400 --> 00:08:23,120
Conditional access changes that equation

211
00:08:23,120 --> 00:08:25,640
by ensuring permission is evaluated continuously based

212
00:08:25,640 --> 00:08:27,280
on context, risk, and location.

213
00:08:27,280 --> 00:08:30,080
The same user might have access to sensitive data

214
00:08:30,080 --> 00:08:31,520
while sitting in the corporate office,

215
00:08:31,520 --> 00:08:33,520
but find themselves blocked from that same data

216
00:08:33,520 --> 00:08:36,160
while working from a coffee shop in a high-risk country.

217
00:08:36,160 --> 00:08:37,920
This is not a simple feature comparison,

218
00:08:37,920 --> 00:08:39,760
but a fundamental architectural difference.

219
00:08:39,760 --> 00:08:42,440
One system is built around the resources being accessed

220
00:08:42,440 --> 00:08:45,240
while the other is built around the people doing the accessing.

221
00:08:45,240 --> 00:08:47,720
In the modern enterprise, people are the control plane

222
00:08:47,720 --> 00:08:49,880
and the resources are always downstream.

223
00:08:49,880 --> 00:08:54,160
Entra ID is gravitational pull, one billion active users.

224
00:08:54,160 --> 00:08:55,880
To understand the weight of this system,

225
00:08:55,880 --> 00:08:58,760
you have to look at the sheer scale of the numbers involved.

226
00:08:58,760 --> 00:09:03,480
Microsoft Entra ID currently has one billion monthly active users

227
00:09:03,480 --> 00:09:05,800
which is not a traditional achievement for Microsoft

228
00:09:05,800 --> 00:09:08,560
as much as it is an unavoidable enterprise reality.

229
00:09:08,560 --> 00:09:12,400
Entra ID serves as the identity backbone for Microsoft 365,

230
00:09:12,400 --> 00:09:16,000
Azure Cloud Services, and thousands of federated SaaS applications.

231
00:09:16,000 --> 00:09:17,400
Increasingly, it is also becoming

232
00:09:17,400 --> 00:09:20,920
the primary identity backbone for accessing AWS.

233
00:09:20,920 --> 00:09:23,400
Reaching one billion active users means Entra ID

234
00:09:23,400 --> 00:09:25,640
is now the largest identity platform on the planet.

235
00:09:25,640 --> 00:09:26,800
This did not happen by design,

236
00:09:26,800 --> 00:09:29,560
but through the sheer force of architectural gravity.

237
00:09:29,560 --> 00:09:32,520
When Entra ID federates AWS, the workflow reveals

238
00:09:32,520 --> 00:09:34,280
who is actually in charge of the gate.

239
00:09:34,280 --> 00:09:36,880
An employee signs into Microsoft Teams using their

240
00:09:36,880 --> 00:09:39,680
enter credentials and then decides they need to access

241
00:09:39,680 --> 00:09:41,280
an AWS resource.

242
00:09:41,280 --> 00:09:44,520
When they click that link, Entra ID evaluates their identity,

243
00:09:44,520 --> 00:09:46,840
their device health, and their current risk profile

244
00:09:46,840 --> 00:09:48,400
before issuing a SAML assertion.

245
00:09:48,400 --> 00:09:50,720
That assertion is what grants them temporary credentials

246
00:09:50,720 --> 00:09:52,080
to enter AWS.

247
00:09:52,080 --> 00:09:55,240
Even though AWS logs the access and manages the resource,

248
00:09:55,240 --> 00:09:57,200
Microsoft is the one controlling the gate.

249
00:09:57,200 --> 00:09:58,960
That is not a partnership between equals

250
00:09:58,960 --> 00:10:01,040
but a clear architectural hierarchy.

251
00:10:01,040 --> 00:10:04,440
This gravitational pull extends far beyond simple identity

252
00:10:04,440 --> 00:10:07,400
and into the realm of policy and conditional access.

253
00:10:07,400 --> 00:10:09,200
When Entra ID federates AWS,

254
00:10:09,200 --> 00:10:11,000
it does not just handle the login,

255
00:10:11,000 --> 00:10:13,680
it enforces the organization's rules across the board.

256
00:10:13,680 --> 00:10:16,920
A company can set a single rule to block all AWS access

257
00:10:16,920 --> 00:10:19,440
from unapproved countries, and that rule applies

258
00:10:19,440 --> 00:10:23,560
to every federated user regardless of which AWS account

259
00:10:23,560 --> 00:10:24,720
they are trying to reach.

260
00:10:24,720 --> 00:10:27,280
You end up with one policy and one control plane

261
00:10:27,280 --> 00:10:29,080
governing multiple platforms.

262
00:10:29,080 --> 00:10:32,000
AWS IAM Identity Center is simply not built to do this

263
00:10:32,000 --> 00:10:34,040
because it was designed for AWS accounts.

264
00:10:34,040 --> 00:10:36,040
It can provide SSO across those accounts

265
00:10:36,040 --> 00:10:37,760
and federate external providers,

266
00:10:37,760 --> 00:10:40,200
but it does not originate identity for the enterprise.

267
00:10:40,200 --> 00:10:41,960
It originates in AWS.

268
00:10:41,960 --> 00:10:45,080
When you connect an external provider to IAM Identity Center,

269
00:10:45,080 --> 00:10:47,760
you are just extending the AWS framework outward

270
00:10:47,760 --> 00:10:49,800
rather than establishing an external system

271
00:10:49,800 --> 00:10:51,480
as the true source of truth.

272
00:10:51,480 --> 00:10:54,240
The distinction is subtle, but the architectural consequences

273
00:10:54,240 --> 00:10:55,160
are massive.

274
00:10:55,160 --> 00:10:57,080
Entra ID's pull is amplified by the fact

275
00:10:57,080 --> 00:11:00,480
that Microsoft 365 is ubiquitous with over 95%

276
00:11:00,480 --> 00:11:02,520
of Fortune 500 companies relying on it.

277
00:11:02,520 --> 00:11:04,480
This means the identity, the workflow,

278
00:11:04,480 --> 00:11:06,520
and the data for the world's largest companies

279
00:11:06,520 --> 00:11:08,000
all flow through Microsoft.

280
00:11:08,000 --> 00:11:09,400
Teams is where the decisions happen,

281
00:11:09,400 --> 00:11:11,360
SharePoint is where the documents live,

282
00:11:11,360 --> 00:11:13,320
and Outlook is where the priorities are set.

283
00:11:13,320 --> 00:11:15,600
This isn't a commentary on the quality of the software,

284
00:11:15,600 --> 00:11:18,160
but a recognition that the actual work of the enterprise

285
00:11:18,160 --> 00:11:19,960
happens inside the Microsoft ecosystem.

286
00:11:19,960 --> 00:11:21,560
When the work happens in Microsoft,

287
00:11:21,560 --> 00:11:24,000
the governance inevitably happens there as well.

288
00:11:24,000 --> 00:11:26,080
Approvals move through Power Automate workflows

289
00:11:26,080 --> 00:11:28,040
built in Power Apps and compliance boundaries

290
00:11:28,040 --> 00:11:29,240
are defined in PerView.

291
00:11:29,240 --> 00:11:31,200
An enterprise could choose to run every single bit

292
00:11:31,200 --> 00:11:33,440
of its compute on AWS, but the control plane

293
00:11:33,440 --> 00:11:34,800
would still belong to Microsoft.

294
00:11:34,800 --> 00:11:36,720
AWS owns the infrastructure underneath,

295
00:11:36,720 --> 00:11:39,480
but Microsoft owns the employee surface area

296
00:11:39,480 --> 00:11:41,160
where the business actually functions.

297
00:11:41,160 --> 00:11:43,720
The gravity compounds because it integrates identity

298
00:11:43,720 --> 00:11:47,120
with workflow, data, and compliance into a single engine.

299
00:11:47,120 --> 00:11:48,760
When Entra ID authenticates a user,

300
00:11:48,760 --> 00:11:50,800
it knows exactly who they are while teams

301
00:11:50,800 --> 00:11:53,160
sees what they are communicating and SharePoint sees

302
00:11:53,160 --> 00:11:54,280
what they are creating.

303
00:11:54,280 --> 00:11:56,880
PerView then classifies that data for protection

304
00:11:56,880 --> 00:11:59,680
while defender monitors the device risk profile.

305
00:11:59,680 --> 00:12:02,200
All of these signals flow into a single governance engine

306
00:12:02,200 --> 00:12:04,680
that AWS has no way to replicate.

307
00:12:04,680 --> 00:12:08,280
AWS has identity management and infrastructure security tools,

308
00:12:08,280 --> 00:12:10,680
but it does not own the space where the work is performed

309
00:12:10,680 --> 00:12:13,320
because it doesn't own the employee surface area.

310
00:12:13,320 --> 00:12:15,520
It cannot build this kind of unified governance

311
00:12:15,520 --> 00:12:17,880
or create this level of control plane gravity.

312
00:12:17,880 --> 00:12:20,480
This is why that 1 billion user figure actually matters.

313
00:12:20,480 --> 00:12:23,400
It is a statement about where the enterprise control plane lives

314
00:12:23,400 --> 00:12:25,360
and which identity engine is responsible

315
00:12:25,360 --> 00:12:28,040
for issuing the tokens that grant access to everything else.

316
00:12:28,040 --> 00:12:30,800
It tells you exactly who is defining the governance layer

317
00:12:30,800 --> 00:12:32,960
that sits on top of all your infrastructure.

318
00:12:32,960 --> 00:12:35,720
And that is Microsoft conditional access

319
00:12:35,720 --> 00:12:37,520
where policy follows identity.

320
00:12:37,520 --> 00:12:39,880
Conditional access is a Microsoft Entra ID feature

321
00:12:39,880 --> 00:12:41,840
that evaluates context in real time

322
00:12:41,840 --> 00:12:43,120
and understanding how this works

323
00:12:43,120 --> 00:12:45,040
is where the architectural difference between Azure

324
00:12:45,040 --> 00:12:47,080
and AWS becomes visceral.

325
00:12:47,080 --> 00:12:49,760
Imagine an employee signs in from the corporate office.

326
00:12:49,760 --> 00:12:52,680
Conditional access asks if the user is in a trusted location

327
00:12:52,680 --> 00:12:56,160
if their device is compliant and if their risk profile is elevated.

328
00:12:56,160 --> 00:12:57,760
When all signals are green,

329
00:12:57,760 --> 00:13:00,240
the system grants access without any friction.

330
00:13:00,240 --> 00:13:03,520
Everything changes when that same employee travels to a conference

331
00:13:03,520 --> 00:13:06,040
in another country and tries to access the same resource

332
00:13:06,040 --> 00:13:07,400
from a hotel.

333
00:13:07,400 --> 00:13:09,480
Conditional access asks the same questions,

334
00:13:09,480 --> 00:13:11,160
but now the location is untrusted

335
00:13:11,160 --> 00:13:14,120
and the risk profile is elevated due to impossible travel.

336
00:13:14,120 --> 00:13:15,880
The system does not just grant access,

337
00:13:15,880 --> 00:13:20,280
but instead enforces MFA or requires device management verification

338
00:13:20,280 --> 00:13:22,640
and it might even block access entirely depending

339
00:13:22,640 --> 00:13:24,560
on the sensitivity of the resource.

340
00:13:24,560 --> 00:13:26,720
This is not static role-based access control.

341
00:13:26,720 --> 00:13:29,440
In reality, it is dynamic, context-aware governance

342
00:13:29,440 --> 00:13:32,040
where the same user might have access to sensitive data

343
00:13:32,040 --> 00:13:34,000
from one location but find themselves blocked

344
00:13:34,000 --> 00:13:35,720
from that same data in another.

345
00:13:35,720 --> 00:13:38,000
The same device might be trusted in one scenario

346
00:13:38,000 --> 00:13:40,280
but flagged in another based on the risk profile

347
00:13:40,280 --> 00:13:42,560
and the same application might require MFA

348
00:13:42,560 --> 00:13:45,080
for one user while letting another pass through.

349
00:13:45,080 --> 00:13:47,240
AWS IAM provides roles and policies

350
00:13:47,240 --> 00:13:48,880
that are fundamentally static,

351
00:13:48,880 --> 00:13:52,120
meaning a user either has permission to access an S3 bucket

352
00:13:52,120 --> 00:13:53,240
or they do not.

353
00:13:53,240 --> 00:13:56,040
You can attach a policy that says a user can read objects

354
00:13:56,040 --> 00:13:57,880
but that policy applies everywhere

355
00:13:57,880 --> 00:14:00,080
and always without any context evaluation

356
00:14:00,080 --> 00:14:01,480
or continuous verification.

357
00:14:01,480 --> 00:14:04,240
There is no mechanism to say that access is allowed from here

358
00:14:04,240 --> 00:14:05,120
but not from there.

359
00:14:05,120 --> 00:14:07,320
AWS uses guard duty for threat detection

360
00:14:07,320 --> 00:14:09,160
and security hub for aggregation

361
00:14:09,160 --> 00:14:10,520
but these are detective controls

362
00:14:10,520 --> 00:14:12,360
that tell you what went wrong after the fact.

363
00:14:12,360 --> 00:14:14,840
They do not prevent access before a breach occurs

364
00:14:14,840 --> 00:14:17,280
whereas conditional access is a preventive mechanism

365
00:14:17,280 --> 00:14:20,280
that stops unauthorized access from happening in the first place.

366
00:14:20,280 --> 00:14:23,000
This distinction matters enormously in hybrid environments

367
00:14:23,000 --> 00:14:25,400
where an employee at a coffee shop gets different treatment

368
00:14:25,400 --> 00:14:27,280
than they would at the corporate office.

369
00:14:27,280 --> 00:14:29,720
Accessing a cloud application from a compliant device

370
00:14:29,720 --> 00:14:32,360
results in a different outcome than using a personal device

371
00:14:32,360 --> 00:14:35,320
and signing in from an approved country is treated differently

372
00:14:35,320 --> 00:14:37,720
than signing in from a high-risk region.

373
00:14:37,720 --> 00:14:41,080
AWS has no native equivalent to this architectural pattern

374
00:14:41,080 --> 00:14:43,920
while AWS can log the access alert on anomalies

375
00:14:43,920 --> 00:14:45,800
or revoke credentials after the fact

376
00:14:45,800 --> 00:14:48,320
it cannot prevent the access before it happens

377
00:14:48,320 --> 00:14:49,840
based on real-time context.

378
00:14:49,840 --> 00:14:51,480
This becomes critical for the control plane

379
00:14:51,480 --> 00:14:54,520
because when enter ID federates AWS conditional access

380
00:14:54,520 --> 00:14:55,800
travels with the identity

381
00:14:55,800 --> 00:14:58,480
an organization can set a rule requiring MFA

382
00:14:58,480 --> 00:15:01,400
for all AWS access from outside the network

383
00:15:01,400 --> 00:15:03,480
and that rule applies to every federated user

384
00:15:03,480 --> 00:15:06,960
regardless of which AWS account or service they are using.

385
00:15:06,960 --> 00:15:09,320
This creates one policy for multiple platforms

386
00:15:09,320 --> 00:15:10,640
under one control plane.

387
00:15:10,640 --> 00:15:12,840
Microsoft Defender for Cloud amplifies this

388
00:15:12,840 --> 00:15:16,680
by monitoring as your resources and connecting to AWS workloads

389
00:15:16,680 --> 00:15:17,520
at the same time.

390
00:15:17,520 --> 00:15:19,640
When a security incident occurs in AWS

391
00:15:19,640 --> 00:15:22,640
the response flows through Microsoft's compliance engine

392
00:15:22,640 --> 00:15:25,920
which evaluates the incident against organizational policies

393
00:15:25,920 --> 00:15:27,520
and enforces remediation.

394
00:15:27,520 --> 00:15:29,760
AWS remains the infrastructure provider

395
00:15:29,760 --> 00:15:31,520
but Microsoft controls the response.

396
00:15:31,520 --> 00:15:33,800
The control plane finally becomes visible here.

397
00:15:33,800 --> 00:15:35,400
It is not just about authentication

398
00:15:35,400 --> 00:15:37,800
but about authorization that adapts to context

399
00:15:37,800 --> 00:15:40,480
and policy that travels with identity across environments.

400
00:15:40,480 --> 00:15:41,920
This is continuous verification

401
00:15:41,920 --> 00:15:43,600
instead of one time authentication.

402
00:15:43,600 --> 00:15:46,720
AWS Security Hub attempts to aggregate security signals

403
00:15:46,720 --> 00:15:48,880
into a dashboard to show you what is happening

404
00:15:48,880 --> 00:15:51,000
but it does not govern identity across platforms

405
00:15:51,000 --> 00:15:53,640
or enforce policy or non-AWS infrastructure.

406
00:15:53,640 --> 00:15:55,200
Security Hub is a security tool

407
00:15:55,200 --> 00:15:57,800
while the combination of conditional access and defender

408
00:15:57,800 --> 00:15:58,880
is a governance layer.

409
00:15:58,880 --> 00:16:01,240
One is a service, one is a control mechanism.

410
00:16:01,240 --> 00:16:03,000
In the enterprise the control mechanism

411
00:16:03,000 --> 00:16:06,600
is what determines who actually has access to what.

412
00:16:06,600 --> 00:16:09,400
Defender for Cloud, the multi-cloud control plane.

413
00:16:09,400 --> 00:16:12,640
Microsoft Defender for Cloud acts as a single pane of glass

414
00:16:12,640 --> 00:16:15,360
for security across multiple environments

415
00:16:15,360 --> 00:16:18,800
covering Azure infrastructure, AWS workloads,

416
00:16:18,800 --> 00:16:23,280
Google Cloud resources and on-premises servers via Azure Arc.

417
00:16:23,280 --> 00:16:26,360
It also integrates endpoints through Defender for Endpoint,

418
00:16:26,360 --> 00:16:31,040
identity through Entra ID and Data through Microsoft purview.

419
00:16:31,040 --> 00:16:32,680
This is not just a feature list

420
00:16:32,680 --> 00:16:34,320
but an architectural inversion.

421
00:16:34,320 --> 00:16:37,040
AWS Security Hub attempts something similar

422
00:16:37,040 --> 00:16:39,680
by aggregating AWS Security signals

423
00:16:39,680 --> 00:16:41,760
to show you what is happening in your environment

424
00:16:41,760 --> 00:16:43,040
which is certainly useful.

425
00:16:43,040 --> 00:16:45,120
However, Security Hub does not govern identity

426
00:16:45,120 --> 00:16:48,400
across platforms or enforce policy on non-AWS infrastructure

427
00:16:48,400 --> 00:16:50,040
making it a dashboard that tells you

428
00:16:50,040 --> 00:16:53,000
what went wrong rather than a system that prevents it.

429
00:16:53,000 --> 00:16:55,600
The foundational mistake is thinking these are equivalent.

430
00:16:55,600 --> 00:16:57,800
When a security incident occurs in AWS,

431
00:16:57,800 --> 00:17:00,240
the response flows through Microsoft's compliance engine

432
00:17:00,240 --> 00:17:02,360
instead of the AWS engine allowing Defender

433
00:17:02,360 --> 00:17:05,120
to evaluate the incident against organizational policies

434
00:17:05,120 --> 00:17:06,760
and enforce remediation.

435
00:17:06,760 --> 00:17:10,000
AWS provides the platform but Microsoft provides the governance

436
00:17:10,000 --> 00:17:11,920
and that is control plane dominance.

437
00:17:11,920 --> 00:17:14,240
Consider what this means for daily operations.

438
00:17:14,240 --> 00:17:17,400
An organization with workloads on AWS, Azure,

439
00:17:17,400 --> 00:17:20,040
on-premises servers and edge devices

440
00:17:20,040 --> 00:17:22,600
would traditionally need five different security tools

441
00:17:22,600 --> 00:17:24,120
and five different alert systems.

442
00:17:24,120 --> 00:17:26,160
That creates chaos and security debt

443
00:17:26,160 --> 00:17:28,600
and it is the primary reason most organizations fail

444
00:17:28,600 --> 00:17:30,240
to respond to incidents quickly.

445
00:17:30,240 --> 00:17:33,200
Defender for Cloud centralizes the signal into one dashboard

446
00:17:33,200 --> 00:17:34,840
with one remediation workflow.

447
00:17:34,840 --> 00:17:37,280
So an unauthorized access attempt in AWS triggers

448
00:17:37,280 --> 00:17:39,400
the same response as one in Azure.

449
00:17:39,400 --> 00:17:42,800
The same policy applies and the same escalation process activates,

450
00:17:42,800 --> 00:17:44,760
creating one control plane that governs

451
00:17:44,760 --> 00:17:46,840
multiple platforms simultaneously.

452
00:17:46,840 --> 00:17:49,960
AWS lacks an equivalent because it does not own the identity

453
00:17:49,960 --> 00:17:52,040
layer whereas Defender for Cloud works

454
00:17:52,040 --> 00:17:54,720
because it sits directly on top of identity.

455
00:17:54,720 --> 00:17:57,120
When Enter ID authenticates a user, Defender

456
00:17:57,120 --> 00:17:59,720
knows exactly who they are and monitors their access

457
00:17:59,720 --> 00:18:01,880
to AWS resources in real time.

458
00:18:01,880 --> 00:18:04,520
When anomalies occur, Defender evaluates them

459
00:18:04,520 --> 00:18:07,720
against organizational policy and enforces remediation

460
00:18:07,720 --> 00:18:09,200
through a single governance engine.

461
00:18:09,200 --> 00:18:12,640
You can integrate AWS security hub with third party tools

462
00:18:12,640 --> 00:18:14,880
or automate responses via Lambda,

463
00:18:14,880 --> 00:18:17,400
but you are essentially building a governance layer

464
00:18:17,400 --> 00:18:19,480
on top of infrastructure from scratch.

465
00:18:19,480 --> 00:18:21,120
You are not inheriting a governance layer

466
00:18:21,120 --> 00:18:22,760
from a unified identity platform

467
00:18:22,760 --> 00:18:25,680
but rather constructing one from individual components.

468
00:18:25,680 --> 00:18:28,520
This matters at scale when you have hundreds of AWS accounts

469
00:18:28,520 --> 00:18:30,480
and millions of access events per day

470
00:18:30,480 --> 00:18:33,440
making a unified governance layer an operational necessity.

471
00:18:33,440 --> 00:18:37,440
You cannot manually review every alert or enforce every policy

472
00:18:37,440 --> 00:18:39,960
so you need a system that understands context

473
00:18:39,960 --> 00:18:42,240
and uses intelligence to manage the load.

474
00:18:42,240 --> 00:18:44,040
Defender for Cloud understands context

475
00:18:44,040 --> 00:18:45,800
because it is built on identity

476
00:18:45,800 --> 00:18:48,000
meaning it knows the user, their device,

477
00:18:48,000 --> 00:18:50,320
their location and their historical behavior.

478
00:18:50,320 --> 00:18:52,920
When anomalies occur, Defender does not just flag them

479
00:18:52,920 --> 00:18:54,600
but instead contextualizes them

480
00:18:54,600 --> 00:18:57,360
and enforces policy based on that specific context.

481
00:18:57,360 --> 00:18:59,760
AWS security hub does not have this context

482
00:18:59,760 --> 00:19:01,880
because it sees infrastructure events

483
00:19:01,880 --> 00:19:03,200
rather than identity events.

484
00:19:03,200 --> 00:19:05,120
It sees that an access event happened

485
00:19:05,120 --> 00:19:07,200
but it does not see the identity context,

486
00:19:07,200 --> 00:19:10,520
the device compliance or the risk profile of the user involved.

487
00:19:10,520 --> 00:19:12,240
This is why the control plane matters.

488
00:19:12,240 --> 00:19:13,440
Infrastructure is visible

489
00:19:13,440 --> 00:19:16,000
but identity remains invisible until something goes wrong

490
00:19:16,000 --> 00:19:18,920
and Defender for Cloud is what finally makes identity

491
00:19:18,920 --> 00:19:21,840
and policy enforcement visible across every platform.

492
00:19:21,840 --> 00:19:23,760
AWS will likely continue to dominate

493
00:19:23,760 --> 00:19:26,160
in raw infrastructure scale and offer more services

494
00:19:26,160 --> 00:19:27,560
than any other competitor.

495
00:19:27,560 --> 00:19:30,200
However, AWS will not control the governance layer

496
00:19:30,200 --> 00:19:31,880
that sits on top of that infrastructure

497
00:19:31,880 --> 00:19:33,560
as that layer belongs to Microsoft.

498
00:19:33,560 --> 00:19:36,400
That layer is where enterprise security actually lives

499
00:19:36,400 --> 00:19:38,920
where policy is enforced and where compliance is proven.

500
00:19:38,920 --> 00:19:40,200
That is the control plane

501
00:19:40,200 --> 00:19:42,920
and that is where the enterprise battle is being decided.

502
00:19:42,920 --> 00:19:45,520
Sentinel and PerView compliance as control.

503
00:19:45,520 --> 00:19:48,400
Microsoft Sentinel is often described as a SIEM,

504
00:19:48,400 --> 00:19:51,800
a tool that simply ingests logs from AWS, Azure

505
00:19:51,800 --> 00:19:53,640
and your on-premises SAS applications

506
00:19:53,640 --> 00:19:54,800
to centralize the signal.

507
00:19:54,800 --> 00:19:57,840
Most organizations believe it is just a high-end log aggregator

508
00:19:57,840 --> 00:20:00,600
where you can see everything happening across your infrastructure.

509
00:20:00,600 --> 00:20:01,480
They are wrong.

510
00:20:01,480 --> 00:20:03,880
Architecturally, Sentinel is the compliance backbone

511
00:20:03,880 --> 00:20:05,760
where policy enforcement becomes visible

512
00:20:05,760 --> 00:20:08,080
and governance finally becomes auditable.

513
00:20:08,080 --> 00:20:10,600
Microsoft PerView sits directly on top of that signal

514
00:20:10,600 --> 00:20:12,720
to add a layer of compliance governance

515
00:20:12,720 --> 00:20:15,000
that the underlying infrastructure cannot provide.

516
00:20:15,000 --> 00:20:18,040
PerView is the engine that enforces data classification,

517
00:20:18,040 --> 00:20:19,720
manages retention policies

518
00:20:19,720 --> 00:20:23,080
and handles the complexities of e-discovery and insider risk.

519
00:20:23,080 --> 00:20:26,040
Because it enforces data loss prevention across teams,

520
00:20:26,040 --> 00:20:27,720
sharepoint and exchange,

521
00:20:27,720 --> 00:20:29,680
you are looking at a single governance engine

522
00:20:29,680 --> 00:20:32,760
that dictates behavior across multiple platforms.

523
00:20:32,760 --> 00:20:35,800
Consider the operational reality of proving GDPR compliance

524
00:20:35,800 --> 00:20:39,080
to a regulator who demands to see how you manage sensitive data.

525
00:20:39,080 --> 00:20:41,640
You need to demonstrate exactly where that data lives,

526
00:20:41,640 --> 00:20:44,160
who touched it and what happened to that information

527
00:20:44,160 --> 00:20:46,280
the moment an employee left the company.

528
00:20:46,280 --> 00:20:48,160
The traditional approach involves auditing

529
00:20:48,160 --> 00:20:50,480
five different systems with five different frameworks

530
00:20:50,480 --> 00:20:52,760
resulting in months of work and thousands of dollars

531
00:20:52,760 --> 00:20:55,040
spent on a fragmented audit trail.

532
00:20:55,040 --> 00:20:57,920
The Sentinel and PerView approach replaces that chaos

533
00:20:57,920 --> 00:21:00,520
with a unified audit trail and a single dashboard

534
00:21:00,520 --> 00:21:02,880
to prove consistent policy enforcement.

535
00:21:02,880 --> 00:21:04,680
When a document is classified as sensitive,

536
00:21:04,680 --> 00:21:07,440
PerView recognizes the state, Sentinel logs the access

537
00:21:07,440 --> 00:21:10,120
and DLP blocks any attempt to share it externally.

538
00:21:10,120 --> 00:21:12,920
This is a deterministic model where the document owner's departure

539
00:21:12,920 --> 00:21:14,760
triggers an automatic retention policy,

540
00:21:14,760 --> 00:21:17,600
providing one version of the truth for your compliance proof.

541
00:21:17,600 --> 00:21:19,600
AWS has no functionally equivalent to this

542
00:21:19,600 --> 00:21:23,040
because AWS config is limited to infrastructure compliance

543
00:21:23,040 --> 00:21:24,400
rather than data governance.

544
00:21:24,400 --> 00:21:27,680
While AWS config can tell you if an estri bucket is encrypted

545
00:21:27,680 --> 00:21:30,040
or if an EC2 instance is configured correctly,

546
00:21:30,040 --> 00:21:32,880
it cannot manage a retention policy or enforce DLP.

547
00:21:32,880 --> 00:21:34,720
AWS provides the virtual hardware

548
00:21:34,720 --> 00:21:36,960
but Microsoft provides the compliance layer

549
00:21:36,960 --> 00:21:39,880
and in regulated industries like finance or healthcare,

550
00:21:39,880 --> 00:21:42,240
that layer is the only thing that matters.

551
00:21:42,240 --> 00:21:44,400
When an enterprise needs to prove hyper compliance,

552
00:21:44,400 --> 00:21:45,960
they don't look to their cloud provider,

553
00:21:45,960 --> 00:21:47,480
they look to their compliance officer.

554
00:21:47,480 --> 00:21:50,960
That officer uses PerView to classify data and enter ID

555
00:21:50,960 --> 00:21:53,920
to manage identity because that is where the control plane

556
00:21:53,920 --> 00:21:54,960
actually lives.

557
00:21:54,960 --> 00:21:57,120
The infrastructure has become a commodity

558
00:21:57,120 --> 00:21:59,720
but the ability to prove that a policy was enforced

559
00:21:59,720 --> 00:22:01,360
is the ultimate differentiator.

560
00:22:01,360 --> 00:22:04,160
This is why enterprises standardize on Microsoft

561
00:22:04,160 --> 00:22:06,800
for their most sensitive regulated workloads.

562
00:22:06,800 --> 00:22:09,680
It is not because Azure Infrastructure is inherently superior

563
00:22:09,680 --> 00:22:12,520
to AWS or because the services have more features,

564
00:22:12,520 --> 00:22:15,080
it is because Microsoft owns the audit trail

565
00:22:15,080 --> 00:22:16,360
and the proof of enforcement.

566
00:22:16,360 --> 00:22:18,880
Even when an organization runs a workload on AWS,

567
00:22:18,880 --> 00:22:20,880
they still extend PerView and Sentinel

568
00:22:20,880 --> 00:22:22,880
across that environment to maintain control.

569
00:22:22,880 --> 00:22:24,360
That is the control plane at work.

570
00:22:24,360 --> 00:22:27,400
AWS provides the workload but Microsoft provides the governance

571
00:22:27,400 --> 00:22:29,400
that makes that workload legal to operate.

572
00:22:29,400 --> 00:22:31,240
In the world of enterprise IT,

573
00:22:31,240 --> 00:22:33,080
control is what the regulators demand

574
00:22:33,080 --> 00:22:34,640
and what the organization pays for.

575
00:22:34,640 --> 00:22:36,680
The battle for the enterprise is not being decided

576
00:22:36,680 --> 00:22:38,200
by cost per compute hour

577
00:22:38,200 --> 00:22:39,880
but by the ability to enforce policy

578
00:22:39,880 --> 00:22:41,960
consistently across every platform.

579
00:22:41,960 --> 00:22:44,080
AWS will never win this specific battle

580
00:22:44,080 --> 00:22:46,880
because they do not own the identity foundation.

581
00:22:46,880 --> 00:22:49,000
Without identity you can build security tools

582
00:22:49,000 --> 00:22:50,360
and monitoring systems

583
00:22:50,360 --> 00:22:52,320
but you cannot build a true governance layer.

584
00:22:52,320 --> 00:22:54,880
Governance requires a deterministic identity model

585
00:22:54,880 --> 00:22:55,920
as its starting point

586
00:22:55,920 --> 00:22:58,240
and that identity belongs to Microsoft.

587
00:22:58,240 --> 00:23:02,120
The M365 Gravity Well, where enterprise work happens.

588
00:23:02,120 --> 00:23:05,760
Over 95% of Fortune 500 companies use Microsoft 365

589
00:23:05,760 --> 00:23:08,240
a number that represents where the actual work

590
00:23:08,240 --> 00:23:09,920
of the enterprise occurs.

591
00:23:09,920 --> 00:23:12,640
This isn't just about IT mandates or licensing bundles,

592
00:23:12,640 --> 00:23:15,240
it's about where the organizational memory is stored

593
00:23:15,240 --> 00:23:17,080
and where decisions are documented.

594
00:23:17,080 --> 00:23:18,960
Teams is no longer just a chat app.

595
00:23:18,960 --> 00:23:20,480
It is the virtual conference room

596
00:23:20,480 --> 00:23:22,000
where executives make the choices

597
00:23:22,000 --> 00:23:23,760
that shape the company's future.

598
00:23:23,760 --> 00:23:25,680
SharePoint has replaced the file server

599
00:23:25,680 --> 00:23:27,600
as the place where every governed document

600
00:23:27,600 --> 00:23:29,320
lives stays or eventually dies.

601
00:23:29,320 --> 00:23:30,480
When a file needs to be discovered

602
00:23:30,480 --> 00:23:33,120
during litigation or deleted according to a legal hold

603
00:23:33,120 --> 00:23:35,120
it happens within the SharePoint architecture.

604
00:23:35,120 --> 00:23:37,840
Exchange serves a similar role for communication,

605
00:23:37,840 --> 00:23:40,640
acting as the permanent archive that regulators check

606
00:23:40,640 --> 00:23:43,400
when they need to see who knew what and when they knew it.

607
00:23:43,400 --> 00:23:45,400
We are not discussing the subjective quality

608
00:23:45,400 --> 00:23:47,640
of these products or whether teams is better

609
00:23:47,640 --> 00:23:48,880
than slack in a vacuum.

610
00:23:48,880 --> 00:23:50,640
The reality is one of ubiquity

611
00:23:50,640 --> 00:23:52,400
where the actual work of the enterprise happens

612
00:23:52,400 --> 00:23:54,480
inside the Microsoft 365 ecosystem.

613
00:23:54,480 --> 00:23:55,800
Because the work happens there,

614
00:23:55,800 --> 00:23:57,440
the governance must happen there as well

615
00:23:57,440 --> 00:24:00,040
making the two concepts architecturally inseparable.

616
00:24:00,040 --> 00:24:01,400
Every approval that flows through power

617
00:24:01,400 --> 00:24:04,040
automate relies on EntraID to know who the approver is

618
00:24:04,040 --> 00:24:06,200
and conditional access to check their context.

619
00:24:06,200 --> 00:24:08,040
Sentinel watches the entire process,

620
00:24:08,040 --> 00:24:10,440
logging the approval to ensure the workflow remains

621
00:24:10,440 --> 00:24:12,920
compliant with the organization's stated intent.

622
00:24:12,920 --> 00:24:14,280
You are not just using a tool,

623
00:24:14,280 --> 00:24:16,120
you are operating within a policy layer

624
00:24:16,120 --> 00:24:19,040
that governs the entire lifecycle of an action.

625
00:24:19,040 --> 00:24:21,080
Custom applications built in PowerApps

626
00:24:21,080 --> 00:24:23,280
follow the same logic by authenticating users

627
00:24:23,280 --> 00:24:26,040
through EntraID and enforcing roles defined

628
00:24:26,040 --> 00:24:27,600
in the identity platform.

629
00:24:27,600 --> 00:24:28,760
When a document is created,

630
00:24:28,760 --> 00:24:30,280
Perview classifies it immediately

631
00:24:30,280 --> 00:24:32,320
and DLP prevents it from leaving the boundaries

632
00:24:32,320 --> 00:24:33,440
of the organization.

633
00:24:33,440 --> 00:24:36,440
This integrated governance means that even if your compute

634
00:24:36,440 --> 00:24:39,800
lives on AWS, your control plane is still firmly rooted

635
00:24:39,800 --> 00:24:40,920
in Microsoft.

636
00:24:40,920 --> 00:24:43,720
AWS does not own the employee surface area

637
00:24:43,720 --> 00:24:46,760
which means they cannot build this type of integrated governance.

638
00:24:46,760 --> 00:24:48,080
This is the gravity well.

639
00:24:48,080 --> 00:24:51,120
Work happens in M365 identity flows through Entra

640
00:24:51,120 --> 00:24:53,520
and policies enforced by conditional access.

641
00:24:53,520 --> 00:24:55,360
All of these signals flow into Sentinel

642
00:24:55,360 --> 00:24:56,880
creating a unified control plane

643
00:24:56,880 --> 00:25:00,240
that AWS simply cannot replicate from the infrastructure layer.

644
00:25:00,240 --> 00:25:04,600
An enterprise might choose AWS for 80% of its raw compute power

645
00:25:04,600 --> 00:25:07,760
but they remain 100% Microsoft by governance and control.

646
00:25:07,760 --> 00:25:09,600
They rely on Microsoft for the place

647
00:25:09,600 --> 00:25:12,720
where decisions are made, archived and eventually audited.

648
00:25:12,720 --> 00:25:15,560
AWS can provide the storage and the AI infrastructure

649
00:25:15,560 --> 00:25:18,560
but they cannot provide the layer that makes that work auditable.

650
00:25:18,560 --> 00:25:20,400
That distinction matters because it defines

651
00:25:20,400 --> 00:25:22,680
who actually owns the enterprise relationship.

652
00:25:22,680 --> 00:25:25,280
The gravity well ensures that as long as work happens

653
00:25:25,280 --> 00:25:27,960
in the Microsoft suite, the governance will follow.

654
00:25:27,960 --> 00:25:30,480
Microsoft owns the place where work happens

655
00:25:30,480 --> 00:25:32,280
and that is why the control plane belongs to them

656
00:25:32,280 --> 00:25:34,840
regardless of where the servers are located.

657
00:25:34,840 --> 00:25:36,960
Co-pilot is control plane acceleration.

658
00:25:36,960 --> 00:25:40,760
Microsoft co-pilot for Microsoft 365 is not merely an AI feature

659
00:25:40,760 --> 00:25:42,520
but rather a governance accelerator

660
00:25:42,520 --> 00:25:45,480
that makes the control plane narrative impossible to ignore.

661
00:25:45,480 --> 00:25:47,600
To function safely within an enterprise environment,

662
00:25:47,600 --> 00:25:50,280
co-pilot requires specific architectural foundations

663
00:25:50,280 --> 00:25:53,160
like data classification, identity scoping

664
00:25:53,160 --> 00:25:55,200
and rigid compliance boundaries.

665
00:25:55,200 --> 00:25:58,320
Without these guardrails, the system cannot operate reliably

666
00:25:58,320 --> 00:26:01,160
and the tool quickly transforms from a productivity asset

667
00:26:01,160 --> 00:26:02,800
into a massive liability.

668
00:26:02,800 --> 00:26:04,800
Consider the actual behavior of the system

669
00:26:04,800 --> 00:26:07,120
as it reads your emails, scans your documents

670
00:26:07,120 --> 00:26:09,080
and synthesizes your entire chat history

671
00:26:09,080 --> 00:26:10,800
into automated insights.

672
00:26:10,800 --> 00:26:12,960
This process becomes a data breach

673
00:26:12,960 --> 00:26:15,360
waiting to happen if the engine lacks the context

674
00:26:15,360 --> 00:26:17,400
to know which documents are sensitive

675
00:26:17,400 --> 00:26:20,280
or which regulated data must remain siloed.

676
00:26:20,280 --> 00:26:22,600
Because the system lacks inherent intent,

677
00:26:22,600 --> 00:26:24,680
it will process whatever it can reach,

678
00:26:24,680 --> 00:26:26,760
making the underlying authorization graph

679
00:26:26,760 --> 00:26:29,360
the only thing standing between utility and catastrophe.

680
00:26:29,360 --> 00:26:31,760
This reality forces organizations to strengthen

681
00:26:31,760 --> 00:26:34,400
their control plane before they can even begin a deployment.

682
00:26:34,400 --> 00:26:35,720
You find yourself needing purview

683
00:26:35,720 --> 00:26:38,640
to classify the data and DLP to enforce boundaries

684
00:26:38,640 --> 00:26:40,320
while enter ID scopes access,

685
00:26:40,320 --> 00:26:43,200
based on the specific role and context of the user.

686
00:26:43,200 --> 00:26:46,040
To maintain oversight, you then need Sentinel to audit

687
00:26:46,040 --> 00:26:48,560
what the engine is reading alongside conditional access

688
00:26:48,560 --> 00:26:51,080
to ensure that only authorized actors can trigger

689
00:26:51,080 --> 00:26:52,040
these features.

690
00:26:52,040 --> 00:26:53,560
Enterprises are moving toward co-pilot

691
00:26:53,560 --> 00:26:55,120
because the productivity gains are real,

692
00:26:55,120 --> 00:26:57,840
but they are finding that adoption is not governance optional.

693
00:26:57,840 --> 00:26:59,240
You cannot deploy this technology

694
00:26:59,240 --> 00:27:01,040
without first hardening your governance layer

695
00:27:01,040 --> 00:27:02,360
which creates a functional lock-in

696
00:27:02,360 --> 00:27:04,920
that is rarely discussed in marketing materials.

697
00:27:04,920 --> 00:27:07,560
While AWS offers bedrock as a service for hosting

698
00:27:07,560 --> 00:27:09,000
and fine-tuning models,

699
00:27:09,000 --> 00:27:10,840
it remains a piece of infrastructure

700
00:27:10,840 --> 00:27:12,320
rather than a control mechanism.

701
00:27:12,320 --> 00:27:14,640
Bedrock is a substrate that allows you to run models

702
00:27:14,640 --> 00:27:15,480
however you like,

703
00:27:15,480 --> 00:27:18,280
but it does not mandate that you classify your data

704
00:27:18,280 --> 00:27:20,480
or implement identity governance to function.

705
00:27:20,480 --> 00:27:22,760
Co-pilot is different because it is architecturally

706
00:27:22,760 --> 00:27:24,400
inseparable from governance.

707
00:27:24,400 --> 00:27:26,720
It forces you to confront your access management

708
00:27:26,720 --> 00:27:30,120
and audit trails because the alternative is conditional chaos

709
00:27:30,120 --> 00:27:32,600
within your most sensitive data sets.

710
00:27:32,600 --> 00:27:34,520
As organizations adopt these tools,

711
00:27:34,520 --> 00:27:36,160
they aren't just buying AI.

712
00:27:36,160 --> 00:27:38,120
They are deepening their structural dependence

713
00:27:38,120 --> 00:27:39,640
on Microsoft's governance stack.

714
00:27:39,640 --> 00:27:41,800
Every query and every recommendation makes

715
00:27:41,800 --> 00:27:45,320
Entra ID and purview more essential to daily operations,

716
00:27:45,320 --> 00:27:48,000
turning these security tools into the literal heartbeat

717
00:27:48,000 --> 00:27:49,040
of the business.

718
00:27:49,040 --> 00:27:50,960
AWS cannot replicate this dynamic

719
00:27:50,960 --> 00:27:53,400
because they do not own the employee surface area

720
00:27:53,400 --> 00:27:54,760
where work actually happens.

721
00:27:54,760 --> 00:27:57,200
Co-pilot succeeds because it lives inside teams outlook

722
00:27:57,200 --> 00:27:58,160
and SharePoint,

723
00:27:58,160 --> 00:28:00,720
whereas AWS lacks the hooks into the daily workflow

724
00:28:00,720 --> 00:28:02,800
to force this kind of governance hardening.

725
00:28:02,800 --> 00:28:05,920
They can host the models and provide the raw inference power,

726
00:28:05,920 --> 00:28:08,640
but they cannot create a feature that accelerates the control

727
00:28:08,640 --> 00:28:10,520
plane because they do not own the interface.

728
00:28:10,520 --> 00:28:13,680
This isn't a coercive tactic, but a functional reality

729
00:28:13,680 --> 00:28:16,440
where the Microsoft control plane becomes more valuable

730
00:28:16,440 --> 00:28:17,480
the more you use it.

731
00:28:17,480 --> 00:28:20,560
Once this layer becomes critical to your operations,

732
00:28:20,560 --> 00:28:23,800
the cost of switching to another provider becomes astronomical.

733
00:28:23,800 --> 00:28:26,800
Removing Entra ID or purview would mean dismantling

734
00:28:26,800 --> 00:28:29,320
your entire identity and data governance framework,

735
00:28:29,320 --> 00:28:30,840
leaving you with a security vacuum

736
00:28:30,840 --> 00:28:32,600
that is nearly impossible to fill.

737
00:28:32,600 --> 00:28:34,640
Choosing Co-pilot is a strategic decision

738
00:28:34,640 --> 00:28:37,560
to prioritize the governance layer over the infrastructure layer

739
00:28:37,560 --> 00:28:40,960
eventually making the underlying hardware irrelevant.

740
00:28:40,960 --> 00:28:43,840
Azure Arc, managing everything everywhere.

741
00:28:43,840 --> 00:28:46,800
Azure Arc represents the software-defined control plane

742
00:28:46,800 --> 00:28:48,080
for hybrid infrastructure,

743
00:28:48,080 --> 00:28:50,040
serving as the most tangible example

744
00:28:50,040 --> 00:28:52,960
of the architectural inversion I've been describing.

745
00:28:52,960 --> 00:28:55,920
It allows you to project a Azure policy and defender

746
00:28:55,920 --> 00:28:58,320
onto infrastructure you don't even own,

747
00:28:58,320 --> 00:29:01,880
including on-premises servers and AWS EC2 instances.

748
00:29:01,880 --> 00:29:03,360
By installing a lightweight agent,

749
00:29:03,360 --> 00:29:06,240
these external resources appear in your Azure portal

750
00:29:06,240 --> 00:29:09,400
as managed objects, effectively pulling your competitors hardware

751
00:29:09,400 --> 00:29:10,800
into your own governance model.

752
00:29:10,800 --> 00:29:12,360
This is not an extension of infrastructure,

753
00:29:12,360 --> 00:29:14,000
but a projection of policy.

754
00:29:14,000 --> 00:29:16,680
While AWS Outpost tries to solve the hybrid problem

755
00:29:16,680 --> 00:29:19,600
by putting AWS Managed Hardware in your data center,

756
00:29:19,600 --> 00:29:22,400
it keeps you trapped inside their specific APIs

757
00:29:22,400 --> 00:29:23,680
and hardware lifecycle.

758
00:29:23,680 --> 00:29:25,960
Outposts is a hardware play that locks you

759
00:29:25,960 --> 00:29:27,680
into a specific vendor's metal,

760
00:29:27,680 --> 00:29:31,960
whereas Arc is a software play that abstracts the hardware entirely.

761
00:29:31,960 --> 00:29:33,640
In the enterprise software, always wins

762
00:29:33,640 --> 00:29:36,360
because that is where the actual control of the system lives.

763
00:29:36,360 --> 00:29:39,840
When you install the Arc agent on a legacy on-premises server,

764
00:29:39,840 --> 00:29:42,720
that machine suddenly behaves like a native Azure resource.

765
00:29:42,720 --> 00:29:44,320
You can enforce security baselines,

766
00:29:44,320 --> 00:29:46,080
require specific encryption standards

767
00:29:46,080 --> 00:29:48,800
and manage firewall rules through the same policy engine

768
00:29:48,800 --> 00:29:50,560
that governs your cloud footprint.

769
00:29:50,560 --> 00:29:53,320
The same logic applies to your AWS instances,

770
00:29:53,320 --> 00:29:55,480
allowing you to monitor them with Azure Monitor

771
00:29:55,480 --> 00:29:58,760
and protect them with Defender under a single unified framework.

772
00:29:58,760 --> 00:30:01,080
This is the definition of control plane abstraction.

773
00:30:01,080 --> 00:30:04,040
You are essentially stating that the location of the infrastructure

774
00:30:04,040 --> 00:30:06,400
is irrelevant as long as the policy is enforced

775
00:30:06,400 --> 00:30:08,760
consistently across the entire environment.

776
00:30:08,760 --> 00:30:10,720
AWS cannot offer a true equivalent

777
00:30:10,720 --> 00:30:13,840
because their DNA is fundamentally infrastructure focused,

778
00:30:13,840 --> 00:30:16,160
meaning they excel at managing their own hardware,

779
00:30:16,160 --> 00:30:18,320
but struggle to provide a unified governance layer

780
00:30:18,320 --> 00:30:20,320
for their competitors platforms.

781
00:30:20,320 --> 00:30:22,640
Arc treats infrastructure as a mere substrate,

782
00:30:22,640 --> 00:30:24,720
allowing the governance layer to remain constant

783
00:30:24,720 --> 00:30:26,760
while the hardware becomes interchangeable.

784
00:30:26,760 --> 00:30:29,440
For an enterprise with a messy mix of on-premises workloads

785
00:30:29,440 --> 00:30:31,680
and multi-cloud deployments, this solves the problem

786
00:30:31,680 --> 00:30:32,800
of operational chaos.

787
00:30:32,800 --> 00:30:35,360
Instead of juggling three different management frameworks

788
00:30:35,360 --> 00:30:36,840
and three different sets of dashboards,

789
00:30:36,840 --> 00:30:38,600
you move toward a single compliance engine

790
00:30:38,600 --> 00:30:41,240
where Azure Policy applies everywhere.

791
00:30:41,240 --> 00:30:43,120
This shift represents a fundamental change

792
00:30:43,120 --> 00:30:44,800
in how we design systems.

793
00:30:44,800 --> 00:30:46,640
You no longer choose a hardware provider

794
00:30:46,640 --> 00:30:48,640
and then try to figure out how to secure it.

795
00:30:48,640 --> 00:30:50,440
Instead, you choose a governance framework

796
00:30:50,440 --> 00:30:52,080
and then decide which infrastructure

797
00:30:52,080 --> 00:30:53,520
fits within those rules.

798
00:30:53,520 --> 00:30:55,400
Microsoft built this abstraction layer

799
00:30:55,400 --> 00:30:57,120
while AWS was still focused

800
00:30:57,120 --> 00:30:58,960
on building better virtual machines.

801
00:30:58,960 --> 00:31:01,400
And that distinction in architectural philosophy

802
00:31:01,400 --> 00:31:04,200
is now becoming a major competitive advantage.

803
00:31:04,200 --> 00:31:06,200
Arc also enables a policy as code model

804
00:31:06,200 --> 00:31:08,120
that is truly platform agnostic.

805
00:31:08,120 --> 00:31:10,760
While tools like cloud formation are powerful,

806
00:31:10,760 --> 00:31:13,440
they are generally confined to the AWS ecosystem

807
00:31:13,440 --> 00:31:16,600
and do not help you manage your data center or other clouds.

808
00:31:16,600 --> 00:31:18,120
Arc policy applies everywhere

809
00:31:18,120 --> 00:31:20,880
because it is focused on the intent of the configuration

810
00:31:20,880 --> 00:31:23,600
rather than the specifics of the underlying provider.

811
00:31:23,600 --> 00:31:25,040
Enterprises aren't adopting Arc

812
00:31:25,040 --> 00:31:26,680
because Azure's compute is better

813
00:31:26,680 --> 00:31:28,280
but because Microsoft's governance model

814
00:31:28,280 --> 00:31:31,480
is more comprehensive and easier to enforce at scale.

815
00:31:31,480 --> 00:31:33,960
Entra-Curbos and Cloud-only identities.

816
00:31:33,960 --> 00:31:36,480
Entra-Curbos is a cloud-native authentication protocol

817
00:31:36,480 --> 00:31:39,600
that finally kills off a fundamental architectural requirement

818
00:31:39,600 --> 00:31:42,760
that has haunted enterprise environments for decades.

819
00:31:42,760 --> 00:31:45,280
Historically, if you wanted Kerberos authentication,

820
00:31:45,280 --> 00:31:47,360
you needed active directory domain controllers

821
00:31:47,360 --> 00:31:48,360
living on premises.

822
00:31:48,360 --> 00:31:51,160
That was a non-negotiable law of the data center.

823
00:31:51,160 --> 00:31:53,840
Accessing file shares or using Kerberos-based security

824
00:31:53,840 --> 00:31:55,880
meant you had to maintain a domain controller

825
00:31:55,880 --> 00:31:57,800
and show a constant line of side connectivity

826
00:31:57,800 --> 00:31:59,800
and swallow the massive infrastructure overhead

827
00:31:59,800 --> 00:32:00,920
that came with it.

828
00:32:00,920 --> 00:32:03,680
Entra-Curbos changes that equation completely.

829
00:32:03,680 --> 00:32:07,360
This shift makes Entra-ID the KDC, the key distribution center.

830
00:32:07,360 --> 00:32:09,800
Instead of relying on a physical box in a server room

831
00:32:09,800 --> 00:32:13,600
to issue Kerberos tickets, Entra-ID handles the heavy lifting

832
00:32:13,600 --> 00:32:14,440
from the cloud.

833
00:32:14,440 --> 00:32:17,920
An employee using an Entra-joint laptop can now authenticate

834
00:32:17,920 --> 00:32:19,760
to Azure files without ever talking

835
00:32:19,760 --> 00:32:21,840
to an on-premises domain controller.

836
00:32:21,840 --> 00:32:23,920
They can jump into an Azure virtual desktop session

837
00:32:23,920 --> 00:32:25,920
without a VPN tunnel back to the home office

838
00:32:25,920 --> 00:32:27,520
allowing them to work from anywhere

839
00:32:27,520 --> 00:32:29,720
while maintaining full Kerberos security.

840
00:32:29,720 --> 00:32:33,000
This is not just a new feature, it is a massive architectural shift.

841
00:32:33,000 --> 00:32:34,560
To understand the operational impact,

842
00:32:34,560 --> 00:32:36,800
you have to look at the old way of doing things.

843
00:32:36,800 --> 00:32:39,120
Traditionally, migrating file service to Azure

844
00:32:39,120 --> 00:32:41,560
created a specific kind of architectural friction

845
00:32:41,560 --> 00:32:43,920
because while Azure file supports SMB,

846
00:32:43,920 --> 00:32:47,680
and SMB supports Kerberos, Kerberos always required a KDC.

847
00:32:47,680 --> 00:32:50,080
You were trapped in a cycle where you either kept your aging

848
00:32:50,080 --> 00:32:51,800
on premises domain controllers running

849
00:32:51,800 --> 00:32:55,120
or you settled for weaker, less secure authentication methods.

850
00:32:55,120 --> 00:32:57,400
Entra Kerberos removes that trap by turning Entra-ID

851
00:32:57,400 --> 00:32:58,840
into the KDC itself.

852
00:32:58,840 --> 00:33:01,840
Cloud-only identities, users who exist solely in Entra-ID

853
00:33:01,840 --> 00:33:03,720
with no footprint in a local AD,

854
00:33:03,720 --> 00:33:06,920
can now authenticate to Azure files using pure Kerberos.

855
00:33:06,920 --> 00:33:08,560
The entire flow is cloud-native,

856
00:33:08,560 --> 00:33:11,160
which means you no longer need on-premises infrastructure,

857
00:33:11,160 --> 00:33:14,080
VPN tunnels, or fragile line-of-side dependencies

858
00:33:14,080 --> 00:33:15,160
to keep things running.

859
00:33:15,160 --> 00:33:17,680
The implications here are significant for any organization

860
00:33:17,680 --> 00:33:19,320
looking to decouple from Legacy Hardware.

861
00:33:19,320 --> 00:33:21,760
You can now decommission your domain controllers,

862
00:33:21,760 --> 00:33:23,800
shut down your local identity systems

863
00:33:23,800 --> 00:33:27,120
and operate entirely in the cloud with enterprise-grade encryption.

864
00:33:27,120 --> 00:33:30,600
Kerberos is no longer a legacy protocol tied to a server rack.

865
00:33:30,600 --> 00:33:33,040
It has been redefined as a cloud-native tool.

866
00:33:33,040 --> 00:33:34,680
AWS has no real answer to this

867
00:33:34,680 --> 00:33:36,760
because they don't own the enterprise identity layer

868
00:33:36,760 --> 00:33:37,760
in the first place.

869
00:33:37,760 --> 00:33:40,760
Since AWS IM is built to manage resources,

870
00:33:40,760 --> 00:33:42,960
rather than identities, they cannot offer

871
00:33:42,960 --> 00:33:45,080
a cloud-only identity infrastructure

872
00:33:45,080 --> 00:33:47,000
or turn their platform into a KDC.

873
00:33:47,000 --> 00:33:49,960
They simply don't own the foundational layer required

874
00:33:49,960 --> 00:33:52,480
to build this kind of authentication architecture.

875
00:33:52,480 --> 00:33:54,680
Enter Kerberos is the technical manifestation

876
00:33:54,680 --> 00:33:56,000
of control play and gravity.

877
00:33:56,000 --> 00:33:58,760
It strips away the last valid architectural reason

878
00:33:58,760 --> 00:34:01,200
to keep identity infrastructure on-premises

879
00:34:01,200 --> 00:34:03,800
as organizations no longer need local domain controllers

880
00:34:03,800 --> 00:34:05,200
for basic authentication.

881
00:34:05,200 --> 00:34:07,240
Enter ID handles the entire stack

882
00:34:07,240 --> 00:34:10,160
in a way that is scalable, governed, and entirely cloud-native.

883
00:34:10,160 --> 00:34:11,760
This matters because it accelerates

884
00:34:11,760 --> 00:34:14,440
the inevitable move toward cloud-only architectures.

885
00:34:14,440 --> 00:34:15,880
Organizations that used to struggle

886
00:34:15,880 --> 00:34:18,960
with hybrid identity setups and complex synchronization

887
00:34:18,960 --> 00:34:21,440
can now cut the cord and move everything to the cloud.

888
00:34:21,440 --> 00:34:24,480
They eliminate the mess of managing two separate identity systems

889
00:34:24,480 --> 00:34:27,680
and the administrative debt that comes with synchronization errors.

890
00:34:27,680 --> 00:34:30,440
When an organization moves to a cloud-only identity model,

891
00:34:30,440 --> 00:34:32,400
they aren't just using a Microsoft service,

892
00:34:32,400 --> 00:34:35,520
they are embedding themselves deeper into the ecosystem.

893
00:34:35,520 --> 00:34:37,800
Enter ID becomes the sole source of truth

894
00:34:37,800 --> 00:34:40,480
and a non-negotiable part of daily operations.

895
00:34:40,480 --> 00:34:42,240
The control plane becomes more visible

896
00:34:42,240 --> 00:34:44,560
and more essential to the business than ever before.

897
00:34:44,560 --> 00:34:46,320
This is how gravity works in practice.

898
00:34:46,320 --> 00:34:49,000
Enter Kerberos doesn't force you to use Azure through a contract,

899
00:34:49,000 --> 00:34:51,440
but you adopt it because it solves the very real problem

900
00:34:51,440 --> 00:34:53,600
of legacy infrastructure dependencies.

901
00:34:53,600 --> 00:34:56,600
However, that choice makes Enter ID strategically dominant,

902
00:34:56,600 --> 00:34:58,440
increasing the importance of the control plane

903
00:34:58,440 --> 00:35:01,960
and making the cost of switching nearly impossible to justify.

904
00:35:01,960 --> 00:35:03,880
Once your identity stack lives in Enter ID

905
00:35:03,880 --> 00:35:06,280
and your file servers rely on Enter Kerberos,

906
00:35:06,280 --> 00:35:08,720
you cannot easily migrate to a different provider.

907
00:35:08,720 --> 00:35:10,760
Moving to AWS identity infrastructure

908
00:35:10,760 --> 00:35:12,200
becomes a functional nightmare

909
00:35:12,200 --> 00:35:13,960
rather than a simple business decision.

910
00:35:13,960 --> 00:35:15,840
You are locked in, not by a salesperson,

911
00:35:15,840 --> 00:35:18,760
but by the functional necessity of your own architecture.

912
00:35:18,760 --> 00:35:20,720
That is the kind of architectural lock-in

913
00:35:20,720 --> 00:35:22,520
that actually matters in the enterprise.

914
00:35:22,520 --> 00:35:25,440
It isn't about your licensing agreement or assigned commitment.

915
00:35:25,440 --> 00:35:28,440
It's about the fact that Enter ID is now the foundation

916
00:35:28,440 --> 00:35:29,960
of your entire environment.

917
00:35:29,960 --> 00:35:32,840
If you remove that layer, everything else stops working immediately.

918
00:35:32,840 --> 00:35:34,560
AWS will likely never compete here

919
00:35:34,560 --> 00:35:37,720
because they focus on compute, storage, and databases

920
00:35:37,720 --> 00:35:39,080
rather than the identity layer.

921
00:35:39,080 --> 00:35:40,840
Microsoft owns the foundational piece

922
00:35:40,840 --> 00:35:43,360
that makes all those other services function.

923
00:35:43,360 --> 00:35:45,920
Enter Kerberos is just one more mechanism designed

924
00:35:45,920 --> 00:35:50,400
to deepen that control and ensure the center of gravity stays exactly where it is.

925
00:35:50,400 --> 00:35:54,200
The hybrid inevitability, 90% by 2027,

926
00:35:54,200 --> 00:35:56,480
Gardner predicts that 90% of organizations

927
00:35:56,480 --> 00:35:59,080
will adopt a hybrid cloud model by 2027.

928
00:35:59,080 --> 00:36:02,160
We should be very clear about what that number represents.

929
00:36:02,160 --> 00:36:04,880
This isn't a guess that most companies will try hybrid

930
00:36:04,880 --> 00:36:06,560
and fail to reach the real cloud,

931
00:36:06,560 --> 00:36:09,360
nor is it a forecast of a temporary transition phase.

932
00:36:09,360 --> 00:36:11,120
This is a statement that hybrid cloud

933
00:36:11,120 --> 00:36:14,120
is the final architectural end state for the enterprise.

934
00:36:14,120 --> 00:36:16,480
This shift isn't happening because organizations

935
00:36:16,480 --> 00:36:18,960
failed their cloud migrations or couldn't afford the bill.

936
00:36:18,960 --> 00:36:22,160
It is happening because hybrid is the optimal way to run a business.

937
00:36:22,160 --> 00:36:24,360
It is the only architecture that actually aligns

938
00:36:24,360 --> 00:36:27,560
with how large-scale enterprises operate in the real world.

939
00:36:27,560 --> 00:36:30,760
Hybrid setups allow organizations to solve for data residency

940
00:36:30,760 --> 00:36:32,840
in a way that pure cloud cannot match.

941
00:36:32,840 --> 00:36:35,320
Sensitivity or regulated data stays on premises

942
00:36:35,320 --> 00:36:36,920
to satisfy legal requirements,

943
00:36:36,920 --> 00:36:39,000
while elastic workloads and AI training

944
00:36:39,000 --> 00:36:40,520
scale out to cloud GPUs.

945
00:36:40,520 --> 00:36:42,720
This isn't a compromise made out of weakness.

946
00:36:42,720 --> 00:36:45,840
It is a deliberate optimization of resources and compliance.

947
00:36:45,840 --> 00:36:48,280
You also get cost benefits that a pure cloud model

948
00:36:48,280 --> 00:36:49,600
struggles to provide.

949
00:36:49,600 --> 00:36:52,400
Predictible steady state workloads run on premises

950
00:36:52,400 --> 00:36:54,920
where you can own the hardware and amortize the cost

951
00:36:54,920 --> 00:36:55,880
over several years.

952
00:36:55,880 --> 00:36:58,280
Meanwhile, your bursty or experimental workloads

953
00:36:58,280 --> 00:37:00,840
run in the cloud where you only pay for what you use.

954
00:37:00,840 --> 00:37:02,440
This isn't a failure to migrate.

955
00:37:02,440 --> 00:37:04,680
It is a mature strategy that matches infrastructure

956
00:37:04,680 --> 00:37:06,600
to the specific needs of the workload.

957
00:37:06,600 --> 00:37:09,320
Latency is another area where hybrid wins.

958
00:37:09,320 --> 00:37:11,080
Real-time processing and edge inference

959
00:37:11,080 --> 00:37:13,640
happen on-site where every millisecond counts,

960
00:37:13,640 --> 00:37:15,360
while the heavy lifting of model training

961
00:37:15,360 --> 00:37:17,920
happens in the cloud where resources are plentiful.

962
00:37:17,920 --> 00:37:20,520
Keeping data close to the point of use means network latency

963
00:37:20,520 --> 00:37:23,440
stops being a bottleneck for your most critical applications.

964
00:37:23,440 --> 00:37:26,200
Finally, hybrid provides a level of security isolation

965
00:37:26,200 --> 00:37:28,560
that the pure cloud model lacks.

966
00:37:28,560 --> 00:37:31,160
Legacy systems that are too risky to modernize

967
00:37:31,160 --> 00:37:34,520
can stay on premises, completely air-gapped from the cloud,

968
00:37:34,520 --> 00:37:37,440
while your modern apps run with cloud-native security.

969
00:37:37,440 --> 00:37:40,720
You aren't trying to force every single app into one rigid model,

970
00:37:40,720 --> 00:37:43,800
which shows architectural maturity rather than a lack of progress.

971
00:37:43,800 --> 00:37:46,640
The 90% forecast isn't an aspirational goal.

972
00:37:46,640 --> 00:37:49,320
It is a description of where the market is already going.

973
00:37:49,320 --> 00:37:51,360
Hybrid is the most efficient architecture

974
00:37:51,360 --> 00:37:52,800
for practical operations.

975
00:37:52,800 --> 00:37:55,760
And that reality changes the entire competitive landscape.

976
00:37:55,760 --> 00:37:58,040
In a hybrid world, the most important question

977
00:37:58,040 --> 00:38:00,400
is no longer which cloud are we using.

978
00:38:00,400 --> 00:38:02,400
But who is governing the whole thing?

979
00:38:02,400 --> 00:38:05,360
The first era of the cloud wars was about where to build

980
00:38:05,360 --> 00:38:07,040
and that favored AWS.

981
00:38:07,040 --> 00:38:09,600
They had the most services, the most regions,

982
00:38:09,600 --> 00:38:11,960
and the most mature tools for developers.

983
00:38:11,960 --> 00:38:15,120
When organizations asked where they should put their new workloads,

984
00:38:15,120 --> 00:38:17,200
the answer was almost always AWS,

985
00:38:17,200 --> 00:38:20,560
and as a result, AWS won that initial round of the fight.

986
00:38:20,560 --> 00:38:22,960
But the new question is about who governs identity

987
00:38:22,960 --> 00:38:25,080
and policy across multiple environments,

988
00:38:25,080 --> 00:38:26,560
and that favors Microsoft.

989
00:38:26,560 --> 00:38:28,800
Because Microsoft owns the enterprise identity

990
00:38:28,800 --> 00:38:29,880
and the governance layer,

991
00:38:29,880 --> 00:38:32,280
they are the natural answer for any organization

992
00:38:32,280 --> 00:38:34,240
trying to manage a split environment.

993
00:38:34,240 --> 00:38:37,000
They extend their control plane across AWS workloads

994
00:38:37,000 --> 00:38:38,320
and on premises servers alike.

995
00:38:38,320 --> 00:38:40,320
And in that arena, Microsoft wins.

996
00:38:40,320 --> 00:38:42,120
This is a total architectural inversion.

997
00:38:42,120 --> 00:38:43,960
In a pure cloud world, the provider

998
00:38:43,960 --> 00:38:46,600
with the best infrastructure wins, but in a hybrid world,

999
00:38:46,600 --> 00:38:49,080
the provider with the best control plane takes the lead.

1000
00:38:49,080 --> 00:38:50,720
AWS was built for the first world

1001
00:38:50,720 --> 00:38:53,280
while Microsoft has spent decades preparing for the second.

1002
00:38:53,280 --> 00:38:56,000
By 2027, when nearly everyone is hybrid,

1003
00:38:56,000 --> 00:38:59,240
the original debate over which cloud is better will become irrelevant.

1004
00:38:59,240 --> 00:39:02,440
Most companies will already be using AWS as your

1005
00:39:02,440 --> 00:39:04,840
and Google cloud simultaneously.

1006
00:39:04,840 --> 00:39:07,520
The real battle will be over how to govern that complexity

1007
00:39:07,520 --> 00:39:10,360
and that is a conversation that Microsoft completely dominates.

1008
00:39:10,360 --> 00:39:12,640
This is why the hybrid forecast is so important.

1009
00:39:12,640 --> 00:39:14,640
It isn't just a market stat, it's a signal

1010
00:39:14,640 --> 00:39:17,280
of which architectural concerns are going to matter most

1011
00:39:17,280 --> 00:39:18,040
in the coming years.

1012
00:39:18,040 --> 00:39:19,560
It tells us that the control plane,

1013
00:39:19,560 --> 00:39:21,800
the identity, the policy and the governance

1014
00:39:21,800 --> 00:39:23,320
is the only thing that determines

1015
00:39:23,320 --> 00:39:26,400
a competitive advantage in a fragmented environment.

1016
00:39:26,400 --> 00:39:29,520
AWS will likely continue to lead in raw infrastructure

1017
00:39:29,520 --> 00:39:32,480
and run more total workloads than anyone else.

1018
00:39:32,480 --> 00:39:34,560
But Microsoft will be the one defining

1019
00:39:34,560 --> 00:39:36,040
how those workloads are governed

1020
00:39:36,040 --> 00:39:37,640
and who has access to them.

1021
00:39:37,640 --> 00:39:39,880
They will set the rules for policy and compliance

1022
00:39:39,880 --> 00:39:41,480
across the entire industry.

1023
00:39:41,480 --> 00:39:43,480
That is the inevitability of the hybrid model.

1024
00:39:43,480 --> 00:39:45,440
It is the reason why the control plane belongs

1025
00:39:45,440 --> 00:39:48,680
to Microsoft regardless of where the actual servers are located.

1026
00:39:48,680 --> 00:39:51,680
The licensing lock-in, enterprise agreements and bundling.

1027
00:39:51,680 --> 00:39:54,520
Microsoft enterprise agreements bundle services together

1028
00:39:54,520 --> 00:39:56,960
in a way that AWS fundamentally cannot replicate.

1029
00:39:56,960 --> 00:39:59,720
To understand why the control plane story is actually

1030
00:39:59,720 --> 00:40:03,400
a financial one, we have to look at what an EA actually contains.

1031
00:40:03,400 --> 00:40:07,680
An enterprise agreement typically bundles Microsoft 365 e5,

1032
00:40:07,680 --> 00:40:09,680
which covers the core of daily work

1033
00:40:09,680 --> 00:40:12,280
through Teams, Exchange, SharePoint and OneDrive.

1034
00:40:12,280 --> 00:40:15,560
It includes Microsoft Entry DP2 for identity governance

1035
00:40:15,560 --> 00:40:18,640
and privilege identity management alongside Microsoft Defender

1036
00:40:18,640 --> 00:40:22,080
for Cloud to monitor security across Azure, AWS

1037
00:40:22,080 --> 00:40:23,840
and on-premises environments.

1038
00:40:23,840 --> 00:40:25,760
The bundle also provides Microsoft Sentinel

1039
00:40:25,760 --> 00:40:27,200
for centralized security management,

1040
00:40:27,200 --> 00:40:30,120
Microsoft Perview for data classification and risk detection

1041
00:40:30,120 --> 00:40:33,200
and Microsoft co-pilot to integrate AI into every workflow.

1042
00:40:33,200 --> 00:40:34,960
This is not a simple feature list.

1043
00:40:34,960 --> 00:40:36,400
It is an architectural lock-in.

1044
00:40:36,400 --> 00:40:38,040
When an enterprise signs an EA,

1045
00:40:38,040 --> 00:40:40,640
they are doing more than just purchasing software licenses.

1046
00:40:40,640 --> 00:40:43,520
They are committing to Microsoft as their primary control plane.

1047
00:40:43,520 --> 00:40:45,920
By signing that contract, the organization is stating

1048
00:40:45,920 --> 00:40:48,280
that Microsoft will serve as the foundation

1049
00:40:48,280 --> 00:40:52,240
for how they govern identity, enforce policy and operate securely.

1050
00:40:52,240 --> 00:40:54,120
AWS cannot offer an equivalent bundle

1051
00:40:54,120 --> 00:40:56,680
because they do not own the workforce software layer.

1052
00:40:56,680 --> 00:41:01,560
While AWS can provide compute, storage, databases and AI infrastructure,

1053
00:41:01,560 --> 00:41:03,480
they cannot offer identity governance

1054
00:41:03,480 --> 00:41:06,000
that is natively integrated with your daily workflow.

1055
00:41:06,000 --> 00:41:07,720
They cannot provide compliance tools

1056
00:41:07,720 --> 00:41:09,840
that live inside your productivity applications

1057
00:41:09,840 --> 00:41:11,880
and they certainly cannot offer an AI assistant

1058
00:41:11,880 --> 00:41:13,080
that is baked into Teams.

1059
00:41:13,080 --> 00:41:15,640
Because of this, enterprises seeking unified governance

1060
00:41:15,640 --> 00:41:16,640
choose Microsoft.

1061
00:41:16,640 --> 00:41:17,720
Once that choice is made,

1062
00:41:17,720 --> 00:41:19,480
they naturally extend Microsoft's reach

1063
00:41:19,480 --> 00:41:21,760
across their existing AWS workloads.

1064
00:41:21,760 --> 00:41:24,880
They use EntraID to authenticate their AWS users

1065
00:41:24,880 --> 00:41:28,000
and Defender for Cloud to monitor their AWS infrastructure.

1066
00:41:28,000 --> 00:41:30,520
They rely on Sentinel to log access and Perview

1067
00:41:30,520 --> 00:41:33,440
to classify data living in AWS buckets.

1068
00:41:33,440 --> 00:41:36,440
The result is that Microsoft's governance is layer directly

1069
00:41:36,440 --> 00:41:38,400
on top of AWS infrastructure.

1070
00:41:38,400 --> 00:41:40,480
This is the inherent advantage of bundling.

1071
00:41:40,480 --> 00:41:43,240
It is not necessarily that Microsoft's individual products

1072
00:41:43,240 --> 00:41:46,640
outperform AWS alternatives on a feature-by-feature basis.

1073
00:41:46,640 --> 00:41:48,920
The reality is that Microsoft's products are integrated,

1074
00:41:48,920 --> 00:41:51,320
meaning they share data and enforce consistent policy

1075
00:41:51,320 --> 00:41:54,720
without requiring you to glue five different third-party tools together.

1076
00:41:54,720 --> 00:41:56,120
The glue is built into the license.

1077
00:41:56,120 --> 00:41:59,040
An organization signs an EA and receives Microsoft 365,

1078
00:41:59,040 --> 00:42:00,720
which ensures that work happens in Teams

1079
00:42:00,720 --> 00:42:02,520
and identity originates in EntraID.

1080
00:42:02,520 --> 00:42:04,680
Security monitoring flows through Defender,

1081
00:42:04,680 --> 00:42:06,200
audit trails live in Sentinel,

1082
00:42:06,200 --> 00:42:08,360
and compliance is enforced through Perview.

1083
00:42:08,360 --> 00:42:11,240
When those same organizations run AWS workloads,

1084
00:42:11,240 --> 00:42:12,560
they need a way to govern them.

1085
00:42:12,560 --> 00:42:14,040
Microsoft owns the control plane,

1086
00:42:14,040 --> 00:42:16,600
so Microsoft governs the AWS workloads.

1087
00:42:16,600 --> 00:42:18,160
The licensing advantage is profound

1088
00:42:18,160 --> 00:42:19,840
because it scales with the organization.

1089
00:42:19,840 --> 00:42:22,760
An enterprise with 5,000 employees needs M365

1090
00:42:22,760 --> 00:42:24,440
and EntraID for every single person

1091
00:42:24,440 --> 00:42:25,760
and they need Defender and Perview

1092
00:42:25,760 --> 00:42:27,720
to maintain their operational foundation.

1093
00:42:27,720 --> 00:42:29,760
These licenses become non-negotiable

1094
00:42:29,760 --> 00:42:32,720
because they are the bedrock of how the company functions.

1095
00:42:32,720 --> 00:42:35,400
AWS cannot compete here because they do not own

1096
00:42:35,400 --> 00:42:37,000
the foundational layer of the business.

1097
00:42:37,000 --> 00:42:40,120
They might offer better compute or more performant databases,

1098
00:42:40,120 --> 00:42:42,280
but they cannot offer better identity governance

1099
00:42:42,280 --> 00:42:44,160
when they don't own the identity itself.

1100
00:42:44,160 --> 00:42:46,280
They cannot bundle governance with productivity

1101
00:42:46,280 --> 00:42:48,680
because they do not own the productivity suite.

1102
00:42:48,680 --> 00:42:51,440
This is why enterprises extend Microsoft across AWS.

1103
00:42:51,440 --> 00:42:53,840
It isn't because Azure services are more feature-rich,

1104
00:42:53,840 --> 00:42:55,560
but because Microsoft owns the bundle

1105
00:42:55,560 --> 00:42:57,200
and the integration that comes with it.

1106
00:42:57,200 --> 00:42:59,240
Once an organization commits to this bundle,

1107
00:42:59,240 --> 00:43:01,240
the cost of switching becomes astronomical.

1108
00:43:01,240 --> 00:43:03,000
You cannot easily remove EntraID

1109
00:43:03,000 --> 00:43:06,000
without dismantling your entire identity management strategy.

1110
00:43:06,000 --> 00:43:08,280
You cannot pull out Defender or Sentinel

1111
00:43:08,280 --> 00:43:11,720
without losing your security monitoring and audit trails.

1112
00:43:11,720 --> 00:43:13,400
The EA is an architectural commitment

1113
00:43:13,400 --> 00:43:15,360
rather than a simple licensing deal.

1114
00:43:15,360 --> 00:43:18,640
It is a declaration that Microsoft's control plane

1115
00:43:18,640 --> 00:43:20,320
is the foundation of the organization.

1116
00:43:20,320 --> 00:43:21,840
Once that foundation is set,

1117
00:43:21,840 --> 00:43:23,840
the underlying AWS infrastructure

1118
00:43:23,840 --> 00:43:26,320
becomes less strategically important.

1119
00:43:26,320 --> 00:43:28,960
AWS becomes the place where workloads run,

1120
00:43:28,960 --> 00:43:31,760
but Microsoft remains the place where governance happens.

1121
00:43:31,760 --> 00:43:33,920
That is the reality of the licensing lock-in.

1122
00:43:33,920 --> 00:43:35,760
Enterprises standardize on Microsoft

1123
00:43:35,760 --> 00:43:38,720
because the control plane makes everything else work.

1124
00:43:38,720 --> 00:43:42,200
Regulated industries where control plane dominance is absolute

1125
00:43:42,200 --> 00:43:44,200
in healthcare, finance and government

1126
00:43:44,200 --> 00:43:46,160
compliance is an existential requirement

1127
00:43:46,160 --> 00:43:48,680
rather than an optional configuration.

1128
00:43:48,680 --> 00:43:51,160
Regulators are not interested in your infrastructure.

1129
00:43:51,160 --> 00:43:53,400
They care if you can prove that data is protected

1130
00:43:53,400 --> 00:43:55,080
and access is strictly controlled.

1131
00:43:55,080 --> 00:43:56,680
This is where the control plane shifts

1132
00:43:56,680 --> 00:43:59,480
from being a benefit to being a mandatory requirement.

1133
00:43:59,480 --> 00:44:02,760
These industries require specific hard guarantees.

1134
00:44:02,760 --> 00:44:04,040
They need residency protections,

1135
00:44:04,040 --> 00:44:06,600
tamper-proof audit trails and insider risk detection

1136
00:44:06,600 --> 00:44:08,560
that catches threats before a breach occurs.

1137
00:44:08,560 --> 00:44:11,080
They need DLP enforcement to stop sensitive data

1138
00:44:11,080 --> 00:44:14,040
from leaving the perimeter and role-based access control

1139
00:44:14,040 --> 00:44:16,480
that is enforced at every single layer.

1140
00:44:16,480 --> 00:44:18,800
Microsoft PerView provides this entire framework

1141
00:44:18,800 --> 00:44:23,120
across M365, Azure and even federated AWS environments.

1142
00:44:23,120 --> 00:44:25,120
When a healthcare provider needs to prove

1143
00:44:25,120 --> 00:44:26,880
hyper compliance, they do not start

1144
00:44:26,880 --> 00:44:28,840
by auditing their EC2 instances.

1145
00:44:28,840 --> 00:44:30,360
They audit their data flows and check

1146
00:44:30,360 --> 00:44:31,920
who accessed patient records.

1147
00:44:31,920 --> 00:44:33,680
They look at whether DLP policies stopped

1148
00:44:33,680 --> 00:44:34,960
unauthorized sharing.

1149
00:44:34,960 --> 00:44:37,880
PerView answers those questions and provides the audit trail

1150
00:44:37,880 --> 00:44:39,960
that proves compliance to the regulator.

1151
00:44:39,960 --> 00:44:43,160
AWS offers AWS config for infrastructure compliance,

1152
00:44:43,160 --> 00:44:45,760
which is useful for verifying that EC2 instances

1153
00:44:45,760 --> 00:44:49,120
are configured correctly or that S3 buckets are encrypted.

1154
00:44:49,120 --> 00:44:51,320
However, AWS config does not govern data

1155
00:44:51,320 --> 00:44:52,960
or manage retention policies.

1156
00:44:52,960 --> 00:44:54,840
It is a tool for hardening the compute layer,

1157
00:44:54,840 --> 00:44:57,360
but it is not a complete compliance solution.

1158
00:44:57,360 --> 00:44:58,800
There is a critical distinction here

1159
00:44:58,800 --> 00:45:01,360
that regulated industries understand perfectly.

1160
00:45:01,360 --> 00:45:04,200
AWS is compliant with HIPAA, meaning their data centers

1161
00:45:04,200 --> 00:45:06,280
are secure and their encryption is strong,

1162
00:45:06,280 --> 00:45:08,560
but Microsoft's governance layer is what actually

1163
00:45:08,560 --> 00:45:10,560
enforces HIPAA for the organization.

1164
00:45:10,560 --> 00:45:12,760
When a healthcare company runs a regulated workload

1165
00:45:12,760 --> 00:45:15,760
on AWS, they still rely on PerView for data governance.

1166
00:45:15,760 --> 00:45:18,280
They still need Sentinel to audit record access

1167
00:45:18,280 --> 00:45:21,600
and enter ID to manage identity through context-aware policies.

1168
00:45:21,600 --> 00:45:24,120
They require the entire Microsoft governance stack

1169
00:45:24,120 --> 00:45:26,840
even when the infrastructure belongs to AWS.

1170
00:45:26,840 --> 00:45:28,360
This creates a strange inversion.

1171
00:45:28,360 --> 00:45:30,800
AWS provides the compliant infrastructure,

1172
00:45:30,800 --> 00:45:33,360
but Microsoft provides the compliant governance.

1173
00:45:33,360 --> 00:45:35,440
In these industries, the governance is what matters

1174
00:45:35,440 --> 00:45:38,240
because the infrastructure has become a commodity.

1175
00:45:38,240 --> 00:45:41,240
Every major cloud provider meets the basic regulatory requirements

1176
00:45:41,240 --> 00:45:42,920
for storage and compute.

1177
00:45:42,920 --> 00:45:45,240
The real differentiator is the governance layer

1178
00:45:45,240 --> 00:45:48,120
that makes those requirements provable to an auditor.

1179
00:45:48,120 --> 00:45:49,600
When the regulator arrives,

1180
00:45:49,600 --> 00:45:52,360
the organization doesn't show them a list of AWS servers.

1181
00:45:52,360 --> 00:45:54,360
They show them the PerView compliance dashboard

1182
00:45:54,360 --> 00:45:56,080
and the Sentinel audit logs.

1183
00:45:56,080 --> 00:45:58,760
Financial services experience these same pressures.

1184
00:45:58,760 --> 00:46:01,440
To prove ASOX compliance, a bank must demonstrate

1185
00:46:01,440 --> 00:46:03,920
that access to critical systems is controlled

1186
00:46:03,920 --> 00:46:06,600
and that insider threats are being monitored.

1187
00:46:06,600 --> 00:46:08,320
PerView handles this natively,

1188
00:46:08,320 --> 00:46:11,120
while AWS config simply cannot reach that level

1189
00:46:11,120 --> 00:46:12,680
of data-centric oversight.

1190
00:46:12,680 --> 00:46:15,600
Government agencies face the most intense requirements of all,

1191
00:46:15,600 --> 00:46:18,880
including FedRAMP, NIST and CMMC frameworks.

1192
00:46:18,880 --> 00:46:21,360
These standards demand centralized identity management

1193
00:46:21,360 --> 00:46:23,400
and comprehensive continuous monitoring.

1194
00:46:23,400 --> 00:46:25,680
Microsoft's governance layer was built to address

1195
00:46:25,680 --> 00:46:27,040
these specific needs.

1196
00:46:27,040 --> 00:46:30,360
While AWS infrastructure can be FedRAMP compliant,

1197
00:46:30,360 --> 00:46:33,320
AWS does not own the governance layer that actually proves it.

1198
00:46:33,320 --> 00:46:35,920
This is where control plane dominance becomes absolute.

1199
00:46:35,920 --> 00:46:39,000
In these sectors, the control plane is the entire business.

1200
00:46:39,000 --> 00:46:41,760
Organizations do not choose between AWS and Azure

1201
00:46:41,760 --> 00:46:44,240
based on how fast a virtual machine boots up.

1202
00:46:44,240 --> 00:46:46,680
They choose based on which platform allows them to survive

1203
00:46:46,680 --> 00:46:47,240
and audit.

1204
00:46:47,240 --> 00:46:49,240
Microsoft owns this space entirely.

1205
00:46:49,240 --> 00:46:51,560
AWS will continue to provide the hardware

1206
00:46:51,560 --> 00:46:53,280
and the compliant data centers,

1207
00:46:53,280 --> 00:46:55,880
but Microsoft will continue to own the governance layer

1208
00:46:55,880 --> 00:46:57,440
in the world of regulated industries.

1209
00:46:57,440 --> 00:46:59,680
That is the only thing that determines the winner.

1210
00:46:59,680 --> 00:47:02,680
That is where the battle for the enterprise is being won.

1211
00:47:02,680 --> 00:47:04,120
Government and sovereign cloud

1212
00:47:04,120 --> 00:47:06,120
where Microsoft's advantage is structural.

1213
00:47:06,120 --> 00:47:08,240
Most organizations view sovereign clouds

1214
00:47:08,240 --> 00:47:11,520
as a simple matter of data residency, but they are wrong.

1215
00:47:11,520 --> 00:47:14,040
Microsoft operates specialized regions in territories

1216
00:47:14,040 --> 00:47:16,680
where data sovereignty is a non-negotiable requirement

1217
00:47:16,680 --> 00:47:17,520
of doing business.

1218
00:47:17,520 --> 00:47:19,560
You see this in Germany through Deutsche Telekom

1219
00:47:19,560 --> 00:47:22,680
in China via 21 VNET and across the US government

1220
00:47:22,680 --> 00:47:25,720
with GCC, GCC high and DOD variants.

1221
00:47:25,720 --> 00:47:27,520
These are not merely infrastructure regions

1222
00:47:27,520 --> 00:47:29,080
designed to host virtual machines.

1223
00:47:29,080 --> 00:47:30,240
They are governance containers

1224
00:47:30,240 --> 00:47:33,240
where the system enforces boundaries by design.

1225
00:47:33,240 --> 00:47:36,880
Within these walls, identity remains local, data stays put,

1226
00:47:36,880 --> 00:47:38,800
and regulators can perform audits

1227
00:47:38,800 --> 00:47:42,400
because nothing leaves the perimeter without explicit authorization.

1228
00:47:42,400 --> 00:47:44,180
AWS maintains similar footprints with

1229
00:47:44,180 --> 00:47:46,420
Gough Cloud and various international regions

1230
00:47:46,420 --> 00:47:48,860
yet a fundamental architectural gap remains.

1231
00:47:48,860 --> 00:47:51,620
While AWS can host the underlying infrastructure

1232
00:47:51,620 --> 00:47:53,180
in these sensitive locations,

1233
00:47:53,180 --> 00:47:54,900
they do not own the governance layer

1234
00:47:54,900 --> 00:47:56,740
that sits on top of that hardware.

1235
00:47:56,740 --> 00:47:59,580
The US government still runs its workforce collaboration

1236
00:47:59,580 --> 00:48:02,700
on Microsoft 365, meaning that even in the most restricted

1237
00:48:02,700 --> 00:48:06,300
GCC high environments, the control plane belongs to Microsoft.

1238
00:48:06,300 --> 00:48:08,820
Decisions are made in teams, documents live in SharePoint

1239
00:48:08,820 --> 00:48:10,940
and communications are archived in exchange

1240
00:48:10,940 --> 00:48:13,820
while EntraID serves as the origin for every identity.

1241
00:48:13,820 --> 00:48:15,620
Security is monitored through defender

1242
00:48:15,620 --> 00:48:18,340
and audit trails are consolidated in Sentinel,

1243
00:48:18,340 --> 00:48:20,420
creating a reality where Microsoft manages

1244
00:48:20,420 --> 00:48:22,260
the entire operational context.

1245
00:48:22,260 --> 00:48:26,060
This distinction matters because it is a structural reality

1246
00:48:26,060 --> 00:48:29,780
rather than a simple feature comparison or product evaluation.

1247
00:48:29,780 --> 00:48:32,180
We are looking at a scenario where Microsoft owns

1248
00:48:32,180 --> 00:48:34,100
the entire stack in sovereign environments

1249
00:48:34,100 --> 00:48:37,020
while AWS is relegated to providing the substrate.

1250
00:48:37,020 --> 00:48:39,460
AWS provides the raw infrastructure

1251
00:48:39,460 --> 00:48:41,100
but Microsoft provides the governance

1252
00:48:41,100 --> 00:48:43,860
that makes that infrastructure usable for regulated agency.

1253
00:48:43,860 --> 00:48:45,420
Consider the operational consequences

1254
00:48:45,420 --> 00:48:47,740
for a government agency running a multi-cloud strategy

1255
00:48:47,740 --> 00:48:48,700
within GCC high.

1256
00:48:48,700 --> 00:48:50,700
They might have workload sitting in AWS

1257
00:48:50,700 --> 00:48:54,060
and Azure simultaneously alongside legacy on premises systems

1258
00:48:54,060 --> 00:48:56,700
yet they still require a unified way to manage them all.

1259
00:48:56,700 --> 00:48:58,100
Microsoft provides that bridge

1260
00:48:58,100 --> 00:49:00,660
because EntraID authenticates the users

1261
00:49:00,660 --> 00:49:03,220
and conditional access enforces the policies

1262
00:49:03,220 --> 00:49:04,860
across the entire environment.

1263
00:49:04,860 --> 00:49:06,820
Defender monitors the AWS instances

1264
00:49:06,820 --> 00:49:09,820
while Sentinel logs the access and purview ensures compliance

1265
00:49:09,820 --> 00:49:13,020
meaning the entire governance layer is a Microsoft engine

1266
00:49:13,020 --> 00:49:15,100
operating within the sovereign boundary.

1267
00:49:15,100 --> 00:49:16,980
AWS cannot replicate this model

1268
00:49:16,980 --> 00:49:19,420
because they do not own the identity system

1269
00:49:19,420 --> 00:49:22,140
or the policy engine required to authenticate users

1270
00:49:22,140 --> 00:49:24,460
and enforce context-aware access.

1271
00:49:24,460 --> 00:49:26,820
They can provide compliant racks and power

1272
00:49:26,820 --> 00:49:29,140
but they cannot provide the overarching framework

1273
00:49:29,140 --> 00:49:31,100
that proves to a regulator that every policy

1274
00:49:31,100 --> 00:49:32,500
is being strictly enforced.

1275
00:49:32,500 --> 00:49:34,340
This structural advantage repeats itself

1276
00:49:34,340 --> 00:49:36,340
in every sovereign region across the globe.

1277
00:49:36,340 --> 00:49:38,540
In Germany the data and identity stay local

1278
00:49:38,540 --> 00:49:40,580
but the system that determines who has access

1279
00:49:40,580 --> 00:49:42,820
and what they can do still belongs to Microsoft.

1280
00:49:42,820 --> 00:49:45,300
For government agencies this is the decisive factor

1281
00:49:45,300 --> 00:49:48,180
that outweighs compute performance or storage capacity

1282
00:49:48,180 --> 00:49:50,100
every single time they aren't buying features

1283
00:49:50,100 --> 00:49:51,780
they are buying the ability to operate

1284
00:49:51,780 --> 00:49:55,100
within a sovereign boundary using a single unified governance model.

1285
00:49:55,100 --> 00:49:57,420
This is why government adoption consistently favors

1286
00:49:57,420 --> 00:49:59,860
Microsoft regardless of whether Azure infrastructure

1287
00:49:59,860 --> 00:50:01,220
is better in a vacuum.

1288
00:50:01,220 --> 00:50:04,020
Microsoft owns the identity, the policy, the compliance

1289
00:50:04,020 --> 00:50:05,780
and the audit trail all contained

1290
00:50:05,780 --> 00:50:07,900
within the required sovereignty boundary.

1291
00:50:07,900 --> 00:50:10,740
AWS will continue to provide the underlying infrastructure

1292
00:50:10,740 --> 00:50:12,220
but they will never control the layer

1293
00:50:12,220 --> 00:50:13,780
where the government actually operates

1294
00:50:13,780 --> 00:50:16,020
and where compliance is ultimately proven.

1295
00:50:16,020 --> 00:50:18,980
As agencies adopt teams, sharepoint and outlook

1296
00:50:18,980 --> 00:50:20,580
this structural advantage compounds

1297
00:50:20,580 --> 00:50:22,780
and the control plane becomes even more critical

1298
00:50:22,780 --> 00:50:24,100
to daily operations.

1299
00:50:24,100 --> 00:50:27,340
The implementation of co-pilot only deepens this dependence

1300
00:50:27,340 --> 00:50:30,180
and as agencies move toward cloud only identities

1301
00:50:30,180 --> 00:50:33,180
via intra-carberos they eliminate their old on premises

1302
00:50:33,180 --> 00:50:34,420
footprint entirely.

1303
00:50:34,420 --> 00:50:36,420
The real advantage isn't found in current products

1304
00:50:36,420 --> 00:50:39,020
but in the architectural foundation of the companies themselves.

1305
00:50:39,020 --> 00:50:41,300
Microsoft built the control plane first

1306
00:50:41,300 --> 00:50:42,900
and attached infrastructure to it

1307
00:50:42,900 --> 00:50:44,620
whereas AWS built infrastructure

1308
00:50:44,620 --> 00:50:47,820
and tried to bolt on governance as an afterthought.

1309
00:50:47,820 --> 00:50:50,740
In sovereign environments where governance is the entire business

1310
00:50:50,740 --> 00:50:53,740
that original architectural intent determines the winner.

1311
00:50:53,740 --> 00:50:56,540
By 2027 the shift to cloud only identities

1312
00:50:56,540 --> 00:50:58,820
and the rollout of AI across the workforce

1313
00:50:58,820 --> 00:51:00,980
will make this advantage feel insurmountable.

1314
00:51:00,980 --> 00:51:03,580
AWS will still be a viable compliant platform

1315
00:51:03,580 --> 00:51:04,940
for hosting workloads

1316
00:51:04,940 --> 00:51:07,060
but Microsoft will control the decision engine

1317
00:51:07,060 --> 00:51:09,380
that dictates every action within the environment.

1318
00:51:09,380 --> 00:51:12,220
In the world of regulated industries and government contracts

1319
00:51:12,220 --> 00:51:14,420
that structural ownership of the control plane

1320
00:51:14,420 --> 00:51:16,540
is the only thing that actually matters.

1321
00:51:16,540 --> 00:51:20,580
The CIO's dilemma, unified control versus best of breed services.

1322
00:51:20,580 --> 00:51:22,460
CIOs are currently facing a choice

1323
00:51:22,460 --> 00:51:24,300
that sounds perfectly rational in a boardroom

1324
00:51:24,300 --> 00:51:27,460
but reveals a massive hidden cost once it hits production.

1325
00:51:27,460 --> 00:51:30,060
They have to choose between a unified control plane

1326
00:51:30,060 --> 00:51:32,060
and the best of breed service model

1327
00:51:32,060 --> 00:51:34,740
and this is where architectural theory turns into

1328
00:51:34,740 --> 00:51:36,260
a painful budget decision.

1329
00:51:36,260 --> 00:51:39,020
A unified control plane means committing to a single vendor

1330
00:51:39,020 --> 00:51:42,140
like Microsoft to handle identity policy compliance

1331
00:51:42,140 --> 00:51:45,100
and security monitoring through a single integrated stack.

1332
00:51:45,100 --> 00:51:48,180
You use EntraID for identity, conditional access

1333
00:51:48,180 --> 00:51:50,620
for your policy engine, purview for compliance

1334
00:51:50,620 --> 00:51:52,100
and Sentinel as your CM.

1335
00:51:52,100 --> 00:51:53,980
While the cost per service might be higher

1336
00:51:53,980 --> 00:51:55,700
because you are paying for deep integration

1337
00:51:55,700 --> 00:51:57,540
the trade-off is a simplified operation

1338
00:51:57,540 --> 00:52:00,340
with one dashboard and one consistent governance model.

1339
00:52:00,340 --> 00:52:02,460
The alternative is the best of breed approach

1340
00:52:02,460 --> 00:52:05,420
where you pick the absolute best tool for every specific job

1341
00:52:05,420 --> 00:52:06,260
in the enterprise.

1342
00:52:06,260 --> 00:52:08,940
You might choose Octa for identity, Splunk for your CM

1343
00:52:08,940 --> 00:52:10,540
and a specialized vendor for DLP

1344
00:52:10,540 --> 00:52:12,420
because you want the most advanced solution

1345
00:52:12,420 --> 00:52:13,980
for every individual function.

1346
00:52:13,980 --> 00:52:16,300
On paper this looks cheaper because you only buy exactly

1347
00:52:16,300 --> 00:52:18,540
what you need but the operational complexity

1348
00:52:18,540 --> 00:52:21,460
begins to multiply the moment the contracts are signed.

1349
00:52:21,460 --> 00:52:23,500
Best of breed sounds superior in theory

1350
00:52:23,500 --> 00:52:25,580
because nobody wants to accept an inferior tool

1351
00:52:25,580 --> 00:52:27,260
just for the sake of integration.

1352
00:52:27,260 --> 00:52:30,580
However, this model almost always fails at enterprise scale

1353
00:52:30,580 --> 00:52:32,980
because it ignores the reality of system entropy.

1354
00:52:32,980 --> 00:52:34,580
When you manage 10 different vendors

1355
00:52:34,580 --> 00:52:37,540
you are actually managing 10 different identity systems

1356
00:52:37,540 --> 00:52:39,180
with 10 different credential stores

1357
00:52:39,180 --> 00:52:40,660
and 10 different password policies.

1358
00:52:40,660 --> 00:52:42,820
If an employee changes their password in one system

1359
00:52:42,820 --> 00:52:44,500
and it fails to propagate to the others

1360
00:52:44,500 --> 00:52:46,660
they are immediately locked out of half their tools.

1361
00:52:46,660 --> 00:52:49,620
Support tickets start to pile up and productivity drops

1362
00:52:49,620 --> 00:52:51,660
because the systems aren't talking to each other

1363
00:52:51,660 --> 00:52:52,620
in a meaningful way.

1364
00:52:52,620 --> 00:52:54,420
Compliance becomes a theater performance

1365
00:52:54,420 --> 00:52:56,980
when you have to pull logs from 10 different vendors

1366
00:52:56,980 --> 00:52:58,580
who all use different data formats.

1367
00:52:58,580 --> 00:53:01,220
One might use Jason while another uses CISLOG

1368
00:53:01,220 --> 00:53:03,340
forcing your team to spend weeks normalizing

1369
00:53:03,340 --> 00:53:06,180
and correlating data just to prove a single access event

1370
00:53:06,180 --> 00:53:07,140
to a regulator.

1371
00:53:07,140 --> 00:53:08,860
This isn't true compliance.

1372
00:53:08,860 --> 00:53:11,260
It's a desperate attempt to reconstruct a narrative

1373
00:53:11,260 --> 00:53:13,260
from fragmented pieces of evidence.

1374
00:53:13,260 --> 00:53:15,100
Security posture also suffers

1375
00:53:15,100 --> 00:53:17,420
because you end up with 10 different policy frameworks

1376
00:53:17,420 --> 00:53:19,140
that don't share the same standards.

1377
00:53:19,140 --> 00:53:21,660
One vendor might enforce MFA while another allows

1378
00:53:21,660 --> 00:53:24,140
weak passwords creating a fragmented environment

1379
00:53:24,140 --> 00:53:25,900
where an attacker only needs to find

1380
00:53:25,900 --> 00:53:27,540
the single weakest link to succeed.

1381
00:53:27,540 --> 00:53:30,180
Your security is no longer a cohesive shield.

1382
00:53:30,180 --> 00:53:31,940
It is a collection of mismatched plates

1383
00:53:31,940 --> 00:53:33,220
with gaps in between them.

1384
00:53:33,220 --> 00:53:35,700
The maintenance burden is the final nail in the coffin

1385
00:53:35,700 --> 00:53:38,220
as every integration between these disparate tools

1386
00:53:38,220 --> 00:53:39,940
becomes a potential failure point.

1387
00:53:39,940 --> 00:53:42,940
You have to write custom code to make the identity system

1388
00:53:42,940 --> 00:53:45,660
talk to the seam and the seam talk to the ticketing system

1389
00:53:45,660 --> 00:53:46,980
and all of it breaks the moment

1390
00:53:46,980 --> 00:53:48,460
a vendor updates an API.

1391
00:53:48,460 --> 00:53:50,300
You also stop hiring cloud architects

1392
00:53:50,300 --> 00:53:51,540
and start hiring specialists

1393
00:53:51,540 --> 00:53:54,420
who only know how to run specific point solutions.

1394
00:53:54,420 --> 00:53:56,500
Training and hiring costs skyrocket

1395
00:53:56,500 --> 00:53:58,940
because your team is focused on mastering tools

1396
00:53:58,940 --> 00:54:01,380
that might be obsolete or acquired within a few years.

1397
00:54:01,380 --> 00:54:04,460
This is the true hidden cost of the best of breed strategy.

1398
00:54:04,460 --> 00:54:06,180
It isn't the price of the software

1399
00:54:06,180 --> 00:54:09,140
but the massive overhead of managing the fragmentation.

1400
00:54:09,140 --> 00:54:11,860
A unified control plane eliminates these friction points

1401
00:54:11,860 --> 00:54:14,060
by providing one authentication mechanism,

1402
00:54:14,060 --> 00:54:16,700
one policy engine and one provable audit trail.

1403
00:54:16,700 --> 00:54:18,340
You pay more for the individual services

1404
00:54:18,340 --> 00:54:20,260
but you pay significantly less overall

1405
00:54:20,260 --> 00:54:23,180
because you aren't funding 10 different integration projects

1406
00:54:23,180 --> 00:54:25,220
or 10 different specialist teams.

1407
00:54:25,220 --> 00:54:27,260
This is the core of the CIO's dilemma

1408
00:54:27,260 --> 00:54:30,060
where the best of breed approach wins the technical debate

1409
00:54:30,060 --> 00:54:32,900
but the unified control plane wins the business reality.

1410
00:54:32,900 --> 00:54:34,500
Enterprises choose Microsoft

1411
00:54:34,500 --> 00:54:37,340
not because every individual tool is the market leader

1412
00:54:37,340 --> 00:54:39,700
but because the platform offers a single place

1413
00:54:39,700 --> 00:54:41,900
where policy is actually enforced.

1414
00:54:41,900 --> 00:54:44,140
AWS cannot offer this level of cohesion

1415
00:54:44,140 --> 00:54:45,940
because they do not own the identity

1416
00:54:45,940 --> 00:54:48,300
or the workflow layers of the stack.

1417
00:54:48,300 --> 00:54:51,580
Once an enterprise chooses Microsoft for that unified control

1418
00:54:51,580 --> 00:54:53,380
they inevitably extend that governance

1419
00:54:53,380 --> 00:54:55,460
across their AWS workloads

1420
00:54:55,460 --> 00:54:57,780
and the battle for the control plane is over.

1421
00:54:57,780 --> 00:55:01,460
The architectural inversion, infrastructure,

1422
00:55:01,460 --> 00:55:03,140
subordinate to governance.

1423
00:55:03,140 --> 00:55:05,100
For decades the hierarchy of enterprise IT

1424
00:55:05,100 --> 00:55:07,140
was built entirely around infrastructure.

1425
00:55:07,140 --> 00:55:10,060
You had a data center team to manage physical servers,

1426
00:55:10,060 --> 00:55:12,380
a network team to handle connectivity

1427
00:55:12,380 --> 00:55:14,620
and a storage team to oversee capacity.

1428
00:55:14,620 --> 00:55:16,980
These groups operated in rigid silos

1429
00:55:16,980 --> 00:55:18,260
reporting up different chains

1430
00:55:18,260 --> 00:55:20,740
and optimizing for completely different metrics.

1431
00:55:20,740 --> 00:55:24,180
In that world, infrastructure was the primary organizing principle

1432
00:55:24,180 --> 00:55:26,580
and every other concern was secondary.

1433
00:55:26,580 --> 00:55:29,660
Cloud computing flattened that hierarchy almost overnight.

1434
00:55:29,660 --> 00:55:31,820
Suddenly infrastructure became a commodity

1435
00:55:31,820 --> 00:55:33,020
you could buy off a shelf.

1436
00:55:33,020 --> 00:55:35,300
You no longer needed a dedicated data center team

1437
00:55:35,300 --> 00:55:36,620
because someone else owned the building

1438
00:55:36,620 --> 00:55:38,580
and you didn't need to manage physical hardware

1439
00:55:38,580 --> 00:55:41,780
because providers handled the maintenance for you.

1440
00:55:41,780 --> 00:55:44,940
Compute, storage and networking all transformed into services

1441
00:55:44,940 --> 00:55:47,620
which meant infrastructure was no longer a scarce resource

1442
00:55:47,620 --> 00:55:49,220
or a meaningful constraint.

1443
00:55:49,220 --> 00:55:50,980
When infrastructure stops being scarce,

1444
00:55:50,980 --> 00:55:52,620
the bottleneck shifts elsewhere.

1445
00:55:52,620 --> 00:55:54,180
The new scarcity is governance.

1446
00:55:54,180 --> 00:55:55,460
The new constraint is policy.

1447
00:55:55,460 --> 00:55:57,140
The real struggle now is the ability

1448
00:55:57,140 --> 00:55:59,420
to enforce consistent rules across a messy

1449
00:55:59,420 --> 00:56:01,100
fragmented collection of platforms

1450
00:56:01,100 --> 00:56:02,900
and this is the architectural inversion.

1451
00:56:02,900 --> 00:56:06,300
While organizations used to be built around their hardware,

1452
00:56:06,300 --> 00:56:08,980
they are now being rebuilt around their governance models.

1453
00:56:08,980 --> 00:56:10,660
Infrastructure has become subordinate

1454
00:56:10,660 --> 00:56:13,140
while governance has become the primary driver of design.

1455
00:56:13,140 --> 00:56:15,540
Think about how this changes your day-to-day operations.

1456
00:56:15,540 --> 00:56:16,700
In the old model you picked

1457
00:56:16,700 --> 00:56:18,580
an infrastructure provider first

1458
00:56:18,580 --> 00:56:20,780
deciding to build on AWS or Azure

1459
00:56:20,780 --> 00:56:22,900
before you ever worried about oversight.

1460
00:56:22,900 --> 00:56:24,340
Governance was an afterthought.

1461
00:56:24,340 --> 00:56:27,220
Something you figured out only after the servers were ready running.

1462
00:56:27,220 --> 00:56:28,620
Infrastructure was the big decision

1463
00:56:28,620 --> 00:56:30,540
and governance just followed along behind it.

1464
00:56:30,540 --> 00:56:32,980
In this new model, you choose your governance framework

1465
00:56:32,980 --> 00:56:34,580
before you do anything else.

1466
00:56:34,580 --> 00:56:37,140
You decide that identity will originate in EntraID

1467
00:56:37,140 --> 00:56:39,660
that policy will be enforced through conditional access

1468
00:56:39,660 --> 00:56:41,860
and that compliance will live in purview.

1469
00:56:41,860 --> 00:56:43,620
Only after those rules are set,

1470
00:56:43,620 --> 00:56:45,980
do you figure out where the actual workloads should live.

1471
00:56:45,980 --> 00:56:48,100
Governance is now the foundational decision

1472
00:56:48,100 --> 00:56:50,220
and the infrastructure simply follows.

1473
00:56:50,220 --> 00:56:52,660
This inversion gives Microsoft a massive home field advantage

1474
00:56:52,660 --> 00:56:55,660
because they built their ecosystem around governance from day one.

1475
00:56:55,660 --> 00:56:58,460
They prioritized identity, policy enforcement,

1476
00:56:58,460 --> 00:57:00,980
and compliance frameworks long before they ever worried

1477
00:57:00,980 --> 00:57:02,620
about the underlying hardware.

1478
00:57:02,620 --> 00:57:04,180
AWS took the opposite path

1479
00:57:04,180 --> 00:57:06,180
by building world-class infrastructure first

1480
00:57:06,180 --> 00:57:07,900
and trying to bolt on governance later.

1481
00:57:07,900 --> 00:57:11,140
As a result, AWS governance still feels like a tool

1482
00:57:11,140 --> 00:57:13,340
for managing servers rather than a system

1483
00:57:13,340 --> 00:57:15,220
for managing an entire enterprise.

1484
00:57:15,220 --> 00:57:17,220
When infrastructure is subordinate to governance,

1485
00:57:17,220 --> 00:57:19,740
the provider who owns the rules wins the contract.

1486
00:57:19,740 --> 00:57:23,180
AWS might still be the best infrastructure provider on the planet,

1487
00:57:23,180 --> 00:57:25,220
offering more services, more regions

1488
00:57:25,220 --> 00:57:28,380
and more mature optimization tools than anyone else.

1489
00:57:28,380 --> 00:57:29,700
But here is the uncomfortable truth.

1490
00:57:29,700 --> 00:57:32,260
Enterprises aren't optimizing for infrastructure anymore.

1491
00:57:32,260 --> 00:57:33,740
They are optimizing for control.

1492
00:57:33,740 --> 00:57:35,100
This isn't a temporary trend

1493
00:57:35,100 --> 00:57:36,900
or a passing phase in the industry.

1494
00:57:36,900 --> 00:57:38,780
It is an architectural shift that reflects

1495
00:57:38,780 --> 00:57:40,980
what modern businesses actually need to survive.

1496
00:57:40,980 --> 00:57:43,340
They need to enforce policy consistently

1497
00:57:43,340 --> 00:57:45,020
across every single platform they use

1498
00:57:45,020 --> 00:57:47,540
and they need to prove that compliance to regulators

1499
00:57:47,540 --> 00:57:49,420
with audit trails that cannot be faked.

1500
00:57:49,420 --> 00:57:51,500
These are governance problems, not hardware problems.

1501
00:57:51,500 --> 00:57:54,940
AWS can solve infrastructure problems with brilliant efficiency,

1502
00:57:54,940 --> 00:57:56,260
but they struggle with governance

1503
00:57:56,260 --> 00:57:59,060
because that layer requires owning the identity of the user.

1504
00:57:59,060 --> 00:58:01,260
AWS does not own the identity layer.

1505
00:58:01,260 --> 00:58:02,260
Microsoft does.

1506
00:58:02,260 --> 00:58:04,540
This architectural inversion will only accelerate

1507
00:58:04,540 --> 00:58:06,500
as we move toward 2027.

1508
00:58:06,500 --> 00:58:09,140
As nearly every enterprise adopts a multi-cloud strategy

1509
00:58:09,140 --> 00:58:11,500
and identity replaces the network as the new perimeter,

1510
00:58:11,500 --> 00:58:14,860
governance becomes the only thing that stays constant.

1511
00:58:14,860 --> 00:58:17,020
Infrastructure is becoming interchangeable

1512
00:58:17,020 --> 00:58:19,820
while the control plane is becoming the only strategic asset

1513
00:58:19,820 --> 00:58:20,700
that matters.

1514
00:58:20,700 --> 00:58:23,020
The organization of the future will be built entirely

1515
00:58:23,020 --> 00:58:24,340
around this governance layer.

1516
00:58:24,340 --> 00:58:27,100
You will choose your framework, likely Microsoft,

1517
00:58:27,100 --> 00:58:29,100
and then treat infrastructure providers

1518
00:58:29,100 --> 00:58:30,620
like plug and play components.

1519
00:58:30,620 --> 00:58:33,700
You might run some workloads on AWS, someone Azure

1520
00:58:33,700 --> 00:58:36,620
and keep others on premises, but your policy will be unified.

1521
00:58:36,620 --> 00:58:38,140
Your identity will be centralized

1522
00:58:38,140 --> 00:58:40,060
and your audit trails will be complete.

1523
00:58:40,060 --> 00:58:42,620
That is the reality of the architectural inversion.

1524
00:58:42,620 --> 00:58:44,340
The control plane belongs to Microsoft,

1525
00:58:44,340 --> 00:58:45,780
not because their servers are better,

1526
00:58:45,780 --> 00:58:48,060
but because the servers themselves aren't the point anymore.

1527
00:58:48,060 --> 00:58:49,140
Governance is what matters,

1528
00:58:49,140 --> 00:58:51,220
and Microsoft owns the engine that runs it.

1529
00:58:51,220 --> 00:58:53,860
Still manning AWS, why they still matter.

1530
00:58:53,860 --> 00:58:57,140
AWS is not losing this fight, and I want to be very clear about that.

1531
00:58:57,140 --> 00:58:58,740
What we are seeing is not a defeat,

1532
00:58:58,740 --> 00:59:02,340
but a repositioning of where AWS fits into the stack.

1533
00:59:02,340 --> 00:59:03,980
That distinction matters.

1534
00:59:03,980 --> 00:59:07,580
AWS remains the undisputed heavyweight champion of infrastructure.

1535
00:59:07,580 --> 00:59:09,340
That isn't a controversial opinion.

1536
00:59:09,340 --> 00:59:12,980
It is a measurable fact backed by 15 years of relentless expansion.

1537
00:59:12,980 --> 00:59:16,020
Their advantages aren't just theoretical ideas on a slide deck.

1538
00:59:16,020 --> 00:59:19,220
They are operational realities that companies rely on every single day.

1539
00:59:19,220 --> 00:59:21,180
And if you look at raw service breadth,

1540
00:59:21,180 --> 00:59:24,740
AWS is still in a league of its own with over 230 services.

1541
00:59:24,740 --> 00:59:27,140
They offer everything from basic compute and storage

1542
00:59:27,140 --> 00:59:30,340
to quantum computing and specialized machine learning tools.

1543
00:59:30,340 --> 00:59:31,300
This wasn't an accident,

1544
00:59:31,300 --> 00:59:34,820
but the result of a decade and a half of building an ecosystem so deep

1545
00:59:34,820 --> 00:59:36,580
that if you can imagine a cloud service,

1546
00:59:36,580 --> 00:59:40,180
AWS probably already has a mature version of it.

1547
00:59:40,180 --> 00:59:43,380
Their global footprint is equally dominant spanning 33 regions

1548
00:59:43,380 --> 00:59:45,140
and over 100 availability zones.

1549
00:59:45,140 --> 00:59:47,300
If your application is sensitive to latency

1550
00:59:47,300 --> 00:59:50,900
or you have to meet strict data residency laws in obscure locations,

1551
00:59:50,900 --> 00:59:54,020
AWS is usually the only provider that can actually deliver.

1552
00:59:54,020 --> 00:59:57,140
That kind of reach is incredibly valuable for global enterprises.

1553
00:59:57,140 --> 01:00:00,900
Beyond the hardware, AWS dominates in the maturity of its DevOps tooling.

1554
01:00:00,900 --> 01:00:03,780
Organizations have spent years and millions of dollars

1555
01:00:03,780 --> 01:00:05,940
building automation on top of cloud formation,

1556
01:00:05,940 --> 01:00:08,020
systems manager and code to deploy.

1557
01:00:08,020 --> 01:00:12,020
They have teams of experts who understand the AWS way of doing things down to the bone.

1558
01:00:12,020 --> 01:00:14,660
You don't just throw away that level of institutional knowledge

1559
01:00:14,660 --> 01:00:18,260
and technical investment because a competitor has a better identity plate.

1560
01:00:18,260 --> 01:00:20,420
They also lead the way in cost optimization.

1561
01:00:20,420 --> 01:00:23,860
Between savings plans, spot instances and the compute optimizer,

1562
01:00:23,860 --> 01:00:26,020
AWS gives you the most granular tools

1563
01:00:26,020 --> 01:00:28,420
to squeeze every bit of value out of your spend.

1564
01:00:28,420 --> 01:00:30,260
For a company running at massive scale,

1565
01:00:30,260 --> 01:00:32,820
the visibility and efficiency AWS provides

1566
01:00:32,820 --> 01:00:34,980
can save them tens of millions of dollars a year.

1567
01:00:34,980 --> 01:00:39,700
Even in the AI race, AWS is holding its ground by focusing on the heavy lifting.

1568
01:00:39,700 --> 01:00:43,620
With bedrock, sage maker and their own custom training and inferential chips,

1569
01:00:43,620 --> 01:00:46,580
they provide the raw power for companies that want to build

1570
01:00:46,580 --> 01:00:48,980
and fine tune their own proprietary models.

1571
01:00:48,980 --> 01:00:52,020
They are providing the flexibility that developers crave.

1572
01:00:52,020 --> 01:00:56,180
AWS will continue to dominate these specific areas for the foreseeable future.

1573
01:00:56,180 --> 01:00:58,980
They will likely continue to run more workloads than anyone else

1574
01:00:58,980 --> 01:01:01,540
and maintain the most sophisticated catalog of tools.

1575
01:01:01,540 --> 01:01:03,220
These strengths aren't going anywhere,

1576
01:01:03,220 --> 01:01:05,220
but the repositioning is happening nonetheless.

1577
01:01:05,220 --> 01:01:10,420
AWS is moving from being the cloud to being the infrastructure layer that Microsoft governs.

1578
01:01:10,420 --> 01:01:14,180
This isn't a failure, it's just a different way of being dominant.

1579
01:01:14,180 --> 01:01:15,620
Look at how this works in practice.

1580
01:01:15,620 --> 01:01:19,380
A company might run 80% of its actual compute power on AWS,

1581
01:01:19,380 --> 01:01:21,380
which is a massive win for Amazon's bottom line.

1582
01:01:21,380 --> 01:01:23,940
But that same company uses EntraID for identity,

1583
01:01:23,940 --> 01:01:26,740
conditional access for security and purview for compliance.

1584
01:01:26,740 --> 01:01:28,580
Their audit logs sit in Sentinel

1585
01:01:28,580 --> 01:01:31,060
and their employees use co-pilot for daily tasks.

1586
01:01:31,060 --> 01:01:34,980
In this scenario, the control plane is Microsoft, but the engine room is AWS.

1587
01:01:34,980 --> 01:01:36,420
AWS isn't losing that deal.

1588
01:01:36,420 --> 01:01:40,420
They are winning the workload, providing the storage and running the databases.

1589
01:01:40,420 --> 01:01:43,700
They are the muscle of the operation, even if they aren't the brain.

1590
01:01:43,700 --> 01:01:47,060
They are providing the power while Microsoft provides the permission.

1591
01:01:47,060 --> 01:01:50,660
This is a perfectly sustainable position for AWS to hold for decades.

1592
01:01:50,660 --> 01:01:53,860
They can continue to innovate in silicon, optimize for performance

1593
01:01:53,860 --> 01:01:57,700
and dominate in raw volume without ever needing to own the identity layer.

1594
01:01:57,700 --> 01:02:02,260
They don't have to compete in every single category to be a vital part of the enterprise stack.

1595
01:02:02,260 --> 01:02:05,540
The real question is whether AWS is actually comfortable with this arrangement.

1596
01:02:05,540 --> 01:02:09,060
We have to wonder if they are okay being the utility layer

1597
01:02:09,060 --> 01:02:11,540
that sits underneath another vendor's control plane.

1598
01:02:11,540 --> 01:02:14,180
So far, their response has been to build their own governance tools

1599
01:02:14,180 --> 01:02:17,780
like control tower and guard duty, which are excellent products in their own right.

1600
01:02:17,780 --> 01:02:20,660
The problem is that those tools are AWS-specific.

1601
01:02:20,660 --> 01:02:24,180
They don't reach out and manage your Azure or on-premises environments,

1602
01:02:24,180 --> 01:02:27,140
which means they don't actually abstract the infrastructure layer.

1603
01:02:27,140 --> 01:02:30,820
They aren't designed to compete with Microsoft's cross-platform governance model

1604
01:02:30,820 --> 01:02:33,940
because they are still fundamentally built to sell more AWS.

1605
01:02:33,940 --> 01:02:36,900
For AWS to truly challenge Microsoft's control,

1606
01:02:36,900 --> 01:02:40,420
they would have to fundamentally rethink their entire business model.

1607
01:02:40,420 --> 01:02:43,060
They would have to stop being an infrastructure first company

1608
01:02:43,060 --> 01:02:44,660
and become a governance first company.

1609
01:02:44,660 --> 01:02:49,060
They would need a policy engine that treats AWS, Azure, and Google Cloud as equals.

1610
01:02:49,060 --> 01:02:52,500
Nothing they've done so far suggests they have any interest in doing that.

1611
01:02:52,500 --> 01:02:54,820
So the future looks like a division of labor.

1612
01:02:54,820 --> 01:02:58,020
AWS will remain the best place to run a workload,

1613
01:02:58,020 --> 01:03:00,900
dominating in compute, storage, and database maturity.

1614
01:03:00,900 --> 01:03:04,340
But they will do so while operating underneath Microsoft's control plane.

1615
01:03:04,340 --> 01:03:07,140
It's a world where AWS wins at the hardware level

1616
01:03:07,140 --> 01:03:09,460
and Microsoft wins at the governance level

1617
01:03:09,460 --> 01:03:10,980
that isn't a loss for either side.

1618
01:03:10,980 --> 01:03:12,820
It's just the new architectural reality.

1619
01:03:12,820 --> 01:03:16,340
The hybrid operating model, the enterprise default.

1620
01:03:16,340 --> 01:03:20,260
By 2027, the hybrid operating model will no longer be an aspirational goal

1621
01:03:20,260 --> 01:03:23,700
or a messy exception because it is becoming the enterprise default.

1622
01:03:23,700 --> 01:03:26,900
This is not a speculative prediction about what organizations should do,

1623
01:03:26,900 --> 01:03:29,860
but a statement about what they will actually be doing to survive.

1624
01:03:29,860 --> 01:03:33,460
To understand this shift, we have to look at how the model functions operationally,

1625
01:03:33,460 --> 01:03:37,380
which is quite different from the traditional marketing definition of hybrid cloud.

1626
01:03:37,380 --> 01:03:39,940
Identity now originates directly in Microsoft,

1627
01:03:39,940 --> 01:03:45,540
and rather than being synchronized from on-premises or federated from some aging legacy system,

1628
01:03:45,540 --> 01:03:48,020
Entra ID acts as the absolute source of truth

1629
01:03:48,020 --> 01:03:52,340
where users, groups, and roles exist natively in the cloud from the moment they are created.

1630
01:03:52,340 --> 01:03:56,340
This makes identity the centralized foundation of the entire architecture.

1631
01:03:56,340 --> 01:03:58,340
Policy enforcement follows a similar pattern

1632
01:03:58,340 --> 01:04:00,180
by moving through Azure Arc and Defender

1633
01:04:00,180 --> 01:04:02,020
to reach every corner of the environment.

1634
01:04:02,020 --> 01:04:04,980
On-premises servers, AWS, EC2 instances,

1635
01:04:04,980 --> 01:04:07,860
and Google Cloud VMs all run the Arc agent,

1636
01:04:07,860 --> 01:04:12,100
which allows them to appear in the Azure portal as standard managed resources.

1637
01:04:12,100 --> 01:04:13,860
This creates a single policy framework

1638
01:04:13,860 --> 01:04:16,820
where Azure Policy and Conditional Access apply to every asset,

1639
01:04:16,820 --> 01:04:20,100
regardless of which infrastructure provider is actually hosting the hardware.

1640
01:04:20,740 --> 01:04:22,900
Infrastructure has become interchangeable,

1641
01:04:22,900 --> 01:04:26,340
allowing you to run workloads on AWS for compute pricing,

1642
01:04:26,340 --> 01:04:28,900
or Azure for M365 integration,

1643
01:04:28,900 --> 01:04:32,260
while keeping latency sensitive tasks on-premises.

1644
01:04:32,260 --> 01:04:35,140
While the underlying infrastructure remains heterogeneous,

1645
01:04:35,140 --> 01:04:37,300
the governance layer is entirely unified.

1646
01:04:37,300 --> 01:04:40,500
Unified governance means you operate with one identity system,

1647
01:04:40,500 --> 01:04:44,740
one policy engine, and one-ordered trail across every cloud provider you use.

1648
01:04:44,740 --> 01:04:46,340
Pervue classifies data everywhere,

1649
01:04:46,340 --> 01:04:50,340
while DLP and Sentinel monitor access and prevent leaks without ever caring

1650
01:04:50,340 --> 01:04:52,340
about traditional infrastructure boundaries.

1651
01:04:52,340 --> 01:04:54,820
Governance is no longer about where the data lives,

1652
01:04:54,820 --> 01:04:56,820
but about how the policy is enforced.

1653
01:04:56,820 --> 01:05:00,660
This model addresses the most painful problems facing the modern enterprise

1654
01:05:00,660 --> 01:05:02,900
by ensuring compliance is never fragmented.

1655
01:05:02,900 --> 01:05:07,220
Instead of managing separate audit trails for Azure, AWS, and local data centers,

1656
01:05:07,220 --> 01:05:10,740
you maintain a single source of truth that makes compliance provable to regulators.

1657
01:05:10,740 --> 01:05:15,140
Costs are optimized because you are no longer locked into a single provider,

1658
01:05:15,140 --> 01:05:19,620
giving you the freedom to shift workloads based on current pricing or performance needs.

1659
01:05:19,620 --> 01:05:22,260
You can keep predictable workloads on hardware you own

1660
01:05:22,260 --> 01:05:26,900
while bursting elastic tasks to whichever cloud offers the best rate at that specific moment.

1661
01:05:26,900 --> 01:05:29,140
Security shifts to an identity first model,

1662
01:05:29,140 --> 01:05:32,740
where the network perimeter is replaced by EntraID and conditional access.

1663
01:05:32,740 --> 01:05:35,940
Every access decision is evaluated based on context,

1664
01:05:35,940 --> 01:05:37,940
device compliance, and risk signals,

1665
01:05:37,940 --> 01:05:39,940
which effectively prevents lateral movement

1666
01:05:39,940 --> 01:05:43,140
by ensuring every single action is logged and auditable.

1667
01:05:43,140 --> 01:05:46,180
Agility is preserved because you can swap infrastructure providers

1668
01:05:46,180 --> 01:05:50,740
or migrate workloads between clouds without ever re-architecting your identity system

1669
01:05:50,740 --> 01:05:52,580
or changing your policy framework.

1670
01:05:52,580 --> 01:05:55,300
Infrastructure becomes a variable that you can change at will

1671
01:05:55,300 --> 01:05:57,140
while governance remains the only constant.

1672
01:05:57,140 --> 01:05:59,380
AWS cannot provide this level of abstraction

1673
01:05:59,380 --> 01:06:01,220
because they do not own the governance layer,

1674
01:06:01,220 --> 01:06:06,020
whereas Microsoft owns the identity, policy, and compliance tools required to unify the stack.

1675
01:06:06,020 --> 01:06:08,100
By abstracting the infrastructure layer,

1676
01:06:08,100 --> 01:06:10,260
Microsoft has replaced it with a control plane

1677
01:06:10,260 --> 01:06:12,500
that enterprises find functionally necessary.

1678
01:06:12,500 --> 01:06:14,500
This is the default reality for 2027,

1679
01:06:14,500 --> 01:06:17,300
not because Microsoft is forcing the hand of the enterprise

1680
01:06:17,300 --> 01:06:21,460
but because the model solves the fundamental problems of cost, security, and compliance.

1681
01:06:21,460 --> 01:06:25,940
Once an organization unifies its governance across a hybrid footprint,

1682
01:06:25,940 --> 01:06:28,340
the cost of switching away becomes astronomical.

1683
01:06:28,340 --> 01:06:32,020
Removing EntraID or Azure Arc would mean dismantling the entire security

1684
01:06:32,020 --> 01:06:33,460
and compliance engine of the company.

1685
01:06:33,460 --> 01:06:37,380
The hybrid operating model locks enterprises into Microsoft's control plane

1686
01:06:37,380 --> 01:06:38,660
through functional necessity,

1687
01:06:38,660 --> 01:06:41,780
effectively making it the operating system for the modern business.

1688
01:06:42,420 --> 01:06:43,620
The prediction.

1689
01:06:43,620 --> 01:06:46,660
Enterprise operating reality by 2028.

1690
01:06:46,660 --> 01:06:50,580
By 2028, the cloud market will be completely reorganized

1691
01:06:50,580 --> 01:06:53,060
around control planes rather than infrastructure providers.

1692
01:06:53,060 --> 01:06:55,780
This shift is inevitable because of the architectural forces

1693
01:06:55,780 --> 01:06:57,860
currently in motion across the industry.

1694
01:06:57,860 --> 01:07:00,980
AWS will likely still dominate the world of cloud compute

1695
01:07:00,980 --> 01:07:04,340
by running more global workloads and offering a broader service catalog

1696
01:07:04,340 --> 01:07:05,940
than any of its competitors.

1697
01:07:05,940 --> 01:07:09,540
For organizations building cloud native applications from the ground up,

1698
01:07:09,540 --> 01:07:12,980
AWS will remain the primary choice due to a structural dominance

1699
01:07:12,980 --> 01:07:14,660
that is incredibly durable.

1700
01:07:14,660 --> 01:07:18,660
Microsoft, however, will define the actual operating reality for the enterprise

1701
01:07:18,660 --> 01:07:21,540
which represents a much more fundamental type of dominance.

1702
01:07:21,540 --> 01:07:25,060
By 2028, CIOs will measure their success through governance metrics

1703
01:07:25,060 --> 01:07:27,060
instead of focusing on infrastructure statistics.

1704
01:07:27,060 --> 01:07:29,780
They will stop asking how many workloads are running on AWS

1705
01:07:29,780 --> 01:07:32,100
and start asking what percentage of access decisions

1706
01:07:32,100 --> 01:07:34,340
are being evaluated by conditional access.

1707
01:07:34,340 --> 01:07:36,820
The primary concern will shift from Azure compute spend

1708
01:07:36,820 --> 01:07:40,100
to the number of data classification policies being enforced through PerView.

1709
01:07:40,100 --> 01:07:42,100
Governance becomes the true measure of success

1710
01:07:42,100 --> 01:07:44,500
while infrastructure is relegated to the substrate.

1711
01:07:44,500 --> 01:07:47,780
Compliance will move from a manual process to an automated one

1712
01:07:47,780 --> 01:07:51,380
where organizations no longer spend months preparing for a single audit.

1713
01:07:51,380 --> 01:07:53,620
Continuous compliance reports will be the norm

1714
01:07:53,620 --> 01:07:55,860
with PerView classifying data in real time

1715
01:07:55,860 --> 01:07:58,740
and DLP preventing violations before they can even happen.

1716
01:07:58,740 --> 01:08:01,060
Regulators will simply audit a live dashboard

1717
01:08:01,060 --> 01:08:02,900
to see policy enforcement in action,

1718
01:08:02,900 --> 01:08:06,260
making compliance a provable fact rather than a theoretical goal.

1719
01:08:06,260 --> 01:08:10,180
Identity will fully replace the network as the primary security perimeter.

1720
01:08:10,180 --> 01:08:12,980
Organizations will stop trying to defend network boundaries

1721
01:08:12,980 --> 01:08:14,980
and focus entirely on the identity boundary

1722
01:08:14,980 --> 01:08:18,180
where every user and device is evaluated by conditional access.

1723
01:08:18,180 --> 01:08:20,820
When every access request is authenticated through EntraID

1724
01:08:20,820 --> 01:08:22,820
and checked for compliance, the underlying network

1725
01:08:22,820 --> 01:08:24,740
becomes architecturally irrelevant.

1726
01:08:24,740 --> 01:08:28,260
Policy will be treated as code rather than a collection of word documents

1727
01:08:28,260 --> 01:08:29,460
or manual processes.

1728
01:08:29,460 --> 01:08:31,700
Azure policy will enforce rules that propagate

1729
01:08:31,700 --> 01:08:33,780
and remediate violations automatically,

1730
01:08:33,780 --> 01:08:36,100
allowing policy to become version controlled,

1731
01:08:36,100 --> 01:08:39,940
auditable and part of the standard infrastructure as code workflow.

1732
01:08:39,940 --> 01:08:43,700
Hybrid setups will be the default for 90% of organizations,

1733
01:08:43,700 --> 01:08:46,260
making single cloud environments a rare exception.

1734
01:08:46,260 --> 01:08:49,140
The question will no longer be whether an organization should be hybrid

1735
01:08:49,140 --> 01:08:52,180
but rather which infrastructure providers can best fit

1736
01:08:52,180 --> 01:08:54,660
within their existing hybrid governance model.

1737
01:08:54,660 --> 01:08:56,660
AWS will adapt to this new reality

1738
01:08:56,660 --> 01:08:58,580
by deepening its integration with Microsoft

1739
01:08:58,580 --> 01:09:00,660
to offer better federation with EntraID

1740
01:09:00,660 --> 01:09:02,820
and stronger support for defender for cloud.

1741
01:09:02,820 --> 01:09:04,820
It will become easier to project Azure governance

1742
01:09:04,820 --> 01:09:08,420
onto AWS infrastructure as the two companies become more complementary.

1743
01:09:08,420 --> 01:09:10,980
AWS will remain the preferred infrastructure layer

1744
01:09:10,980 --> 01:09:13,940
while Microsoft solidifies its position as the governance layer.

1745
01:09:13,940 --> 01:09:16,580
The control plane will remain firmly in Microsoft's hands

1746
01:09:16,580 --> 01:09:19,220
because AWS is not building a competing framework

1747
01:09:19,220 --> 01:09:21,300
that can span across multiple clouds

1748
01:09:21,300 --> 01:09:23,220
and on-premises environments.

1749
01:09:23,220 --> 01:09:25,300
AWS remains an infrastructure first company

1750
01:09:25,300 --> 01:09:28,100
while Microsoft has pivoted to a governance first strategy

1751
01:09:28,100 --> 01:09:30,420
and that architectural gap is not going to close.

1752
01:09:30,420 --> 01:09:34,580
By 2028 enterprises will see this arrangement as the optimal way to run a business.

1753
01:09:34,580 --> 01:09:37,380
They might run 70% of their compute on AWS

1754
01:09:37,380 --> 01:09:40,820
while managing every bit of it through the Microsoft control plane.

1755
01:09:40,820 --> 01:09:42,500
There is no contradiction in this setup

1756
01:09:42,500 --> 01:09:45,060
because it allows a company to use the best infrastructure

1757
01:09:45,060 --> 01:09:46,900
alongside the best governance tools.

1758
01:09:46,900 --> 01:09:49,300
This is the enterprise reality of 2028

1759
01:09:49,300 --> 01:09:51,620
where the conversation shifts from which cloud

1760
01:09:51,620 --> 01:09:53,860
to how do we govern across all clouds.

1761
01:09:53,860 --> 01:09:56,260
AWS will still be winning the infrastructure race

1762
01:09:56,260 --> 01:09:58,260
but Microsoft will be the one defining

1763
01:09:58,260 --> 01:09:59,860
what winning actually looks like.

1764
01:09:59,860 --> 01:10:01,620
Conclusion.

1765
01:10:01,620 --> 01:10:03,620
The control plane is the battleground.

1766
01:10:03,620 --> 01:10:05,780
AWS won the infrastructure war

1767
01:10:05,780 --> 01:10:07,940
and that is now a matter of historical record.

1768
01:10:07,940 --> 01:10:11,220
They dominate cloud compute by running more global workloads

1769
01:10:11,220 --> 01:10:12,660
than any competitor

1770
01:10:12,660 --> 01:10:16,660
and their lead in services and regions remains undisputed.

1771
01:10:16,660 --> 01:10:17,860
AWS won.

1772
01:10:17,860 --> 01:10:21,060
Microsoft is winning the control plane war

1773
01:10:21,060 --> 01:10:23,860
which is the battle currently deciding the fate of the enterprise.

1774
01:10:23,860 --> 01:10:26,260
This is where identity, policy and governance live

1775
01:10:26,260 --> 01:10:28,500
and it is exactly where Microsoft's gravity

1776
01:10:28,500 --> 01:10:30,100
pulls the largest organizations.

1777
01:10:30,100 --> 01:10:32,900
In the enterprise the control plane is the only thing that matters

1778
01:10:32,900 --> 01:10:34,980
because infrastructure has become a commodity

1779
01:10:34,980 --> 01:10:36,660
while governance remains scarce.

1780
01:10:36,660 --> 01:10:39,540
By 2027, nine out of ten organizations

1781
01:10:39,540 --> 01:10:41,140
will operate in hybrid environments

1782
01:10:41,140 --> 01:10:44,100
where unified governance always beats distributed services.

1783
01:10:44,100 --> 01:10:45,700
Microsoft owns governance

1784
01:10:45,700 --> 01:10:47,620
and while AWS owns infrastructure,

1785
01:10:47,620 --> 01:10:50,740
the enterprise will always choose the path of unified control.

1786
01:10:50,740 --> 01:10:53,220
Drop a comment if you think AWS can actually mount

1787
01:10:53,220 --> 01:10:54,740
a control plane comeback.

1788
01:10:54,740 --> 01:10:56,340
Subscribe for the architectural takes

1789
01:10:56,340 --> 01:10:58,100
that nobody else is willing to give you.