AWS re:Invent 2021 - Securing your data perimeter with VPC endpoints

[@briankepha]

This was sooooo good.Thank you, getting history of why a service exists in the first place gives so much perspective

[@amazonwebservices]

We're so glad you enjoyed it! 😁

[@srirajan1933]

Absolutely loved your enthusiasm and clarity on VPC endpoints, Becky -- stellar delivery and and content! Thank you!

[@benjaminsh8576]

one of the best explanation of VPC endpoint concept by far!

[@shaunwang2160]

So good!

[@ambc38vsxn]

Such a brilliant session! Thanks a lot!

[@awssupport]

Thanks for watching! Glad you enjoyed it. ^RS

[@alexeyalexandrov7583]

Amazing talk! Really great content and awesome speaker!

[@charlesuneze4920]

A lovely session with great storytelling.

[@vishalgupta8986]

Superb!!! specifically last 30 minutes.

[@abduljabbarazam943]

That was useful and very interesting. Thanks

[@kapilch]

awesome session

[@samjackgreen]

Great talk. some personal notes... 29:20 problem with using Gateway VPC endpoint "The problem here is this is done with routes. And if you've ever set up connectivity to an on-premises network... those are done with routes too. And so you can't really do that. You can route _VPC-bound_ traffic from the on-premises network. No problem. But how do you route traffic into the VPC endpoint _that doesn't seem to be bound for the VPC_? On Interface Endpoints: 35:26 "What you got was not a prefix list and some routes and a gateway." 35:35 "Rather you got Kinesis planted at *an IP address in your VPC*" 35:54 "each of these VPC endpoints to Kinesis is actually now at an IP address IN your VPC. It's something we call an 36:10 refering back to the above problem at 29:20 (the 'core problem) 36:20 [Now, with Interface endpoints, traffic which is not bound for the VPC can come from on-premises. Remember, we could always deal with traffic that was VPC-bound. Now we can deal with traffic that comes into our VPC (aiming to get so, say, Kinesis) which is not VPC-bound.