1
00:00:06,488 --> 00:00:10,733
- Now let's take a look at
a few VPC peering scenarios.

2
00:00:10,733 --> 00:00:14,127
There are many, many ways that you could

3
00:00:14,127 --> 00:00:15,869
segregate your networks,

4
00:00:15,869 --> 00:00:18,870
separate applications and departments,

5
00:00:18,870 --> 00:00:22,992
and peer VPCs using different strategies.

6
00:00:22,992 --> 00:00:24,896
One strategy might be

7
00:00:24,896 --> 00:00:27,816
that you want to isolate
different services.

8
00:00:27,816 --> 00:00:30,320
In this example, we might want

9
00:00:30,320 --> 00:00:33,848
our web application in one network,

10
00:00:33,848 --> 00:00:37,889
all of our back end servers
in yet another network,

11
00:00:37,889 --> 00:00:40,757
and then our databases
in their own network.

12
00:00:40,757 --> 00:00:42,214
This is totally up to you.

13
00:00:42,214 --> 00:00:44,872
It's fairly arbitrary;
there's nothing within

14
00:00:44,872 --> 00:00:48,587
Amazon Web Services that
says you have to segregate

15
00:00:48,587 --> 00:00:51,414
and separate your networks
in any particular way.

16
00:00:51,414 --> 00:00:54,097
It's all up to you; whatever
makes the most sense

17
00:00:54,097 --> 00:00:57,473
for your application
and for your business.

18
00:00:57,473 --> 00:00:59,978
Some business choose to segregate

19
00:00:59,978 --> 00:01:03,568
their networks by department:
whereas finance department

20
00:01:03,568 --> 00:01:06,304
has their resources and their VPC,

21
00:01:06,304 --> 00:01:09,286
and accounting has their
resources in their own VPC.

22
00:01:09,286 --> 00:01:12,009
But they're connected and
they can talk to each other.

23
00:01:12,009 --> 00:01:14,801
Accounting needs access to resources

24
00:01:14,801 --> 00:01:16,458
that are in the finance department,

25
00:01:16,458 --> 00:01:18,830
so they would peer those two VPCs.

26
00:01:18,830 --> 00:01:22,597
In another situation, maybe
you need centralized resources

27
00:01:22,597 --> 00:01:24,406
where you have various departments.

28
00:01:24,406 --> 00:01:26,907
They are all essentially
isolated from each other.

29
00:01:26,907 --> 00:01:29,116
We don't want these departments, really,

30
00:01:29,116 --> 00:01:32,060
gaining access to each other's resources,

31
00:01:32,060 --> 00:01:35,532
but they all need access
to the corporate internet,

32
00:01:35,532 --> 00:01:37,709
or the corporate file sharing server.

33
00:01:37,709 --> 00:01:39,830
Here's that example of you have

34
00:01:39,830 --> 00:01:44,076
those kinds of shared
resources in one VPC,

35
00:01:44,076 --> 00:01:46,721
and you keep your departmental,

36
00:01:46,721 --> 00:01:50,466
specific departmental
resources in their own VPCs.

37
00:01:50,466 --> 00:01:54,455
Another approach to VPC peering might be

38
00:01:54,455 --> 00:01:57,456
that you put shared resources in a VPC,

39
00:01:57,456 --> 00:02:01,162
and you have different customers
that have access to that.

40
00:02:01,162 --> 00:02:04,912
Each customer, or each
vendor having their own VPC

41
00:02:04,912 --> 00:02:08,902
and their own account, and then
you're granting them access

42
00:02:08,902 --> 00:02:12,335
to your pool of shared resources.

43
00:02:12,335 --> 00:02:14,492
So again, it's all arbitrary.

44
00:02:14,492 --> 00:02:16,484
Amazon does not dictate

45
00:02:16,484 --> 00:02:18,979
how we do this,

46
00:02:18,979 --> 00:02:22,484
other than that, as we've talked about,

47
00:02:22,484 --> 00:02:26,260
VPCs, VPC peering is a
one-to-one relationship

48
00:02:26,260 --> 00:02:28,671
with no overlapping IP ranges.

49
00:02:28,671 --> 00:02:31,341
Other than that, you can
pretty much do what you want.

50
00:02:31,341 --> 00:02:35,291
Whatever makes sense for your
application and your business.