- [Alex] Welcome to the second part of Translating AWS Services. In the first section, we covered services that might be easier to translate from the on-prem world to the cloud. Now, when I say easy, I don't mean that there isn't any work involved, just that there's a direct one-to-one path. Compute? Probably EC2. Relational databases? Let's use RDS. In this lesson, we're going to cover some services that aren't as simple to move to the cloud. Namely, your networking architecture. Are you the networking person? If you are, you're amazing. I say that because I've seen you fine folks crawling under desks, through ceilings, and wrapped with so many cables that you look like a mummy. Now, whether you work directly in networking, or simply lend a hand once in a while, I've got some good news for you. Now, that you're moving to the cloud, everything is virtual. No more cable runs, CAT6, 7, or 8 through 14, just simple AWS API calls. Now, the very first step is to create a map of your existing networking infrastructure. There's no magic button to press to take that network and make it appear in the cloud. However, I promise it probably, definitely, maybe, won't be as hard to build in AWS as it is to build on-prem. So, let's hop over to the whiteboard now, to walk through some of the terminology that you'll need to be familiar with when building your networking foundation. Now in front of us here, we've got a pretty basic AWS infrastructure. For this exercise, we're going to be using the us-west-2, also known as that Oregon Region. For simplicity's sake, we've got our two Availability Zones, here. I'll let you mentally fill in the rest, as you don't only have to use two. We're going to want to make sure that we select an IP range that doesn't conflict with our on-prem networking space. Let's say that this one is going to be 10.0.0.0/16. Perfect. Once we've built our VPC, it's time to carve it up into those subnets. For this application, we're going to want to make sure that we're using both public and private subnets. Now, those public subnets simply mean that those resources are created in an environment that has potential direct internet access. Private subnets, on the other hand, don't have that direct access. So, let's start off by putting the majority of our architecture in those private subnets. So, we've got some frontend resources, here. Let's throw in a backend resource, and a database for good measure. Now that we've got those up, we want to make sure that they can communicate externally to our customers through a secure and structured method. Let's throw in some NAT Gateways. We'll put them right here in those public subnets. These act as a go-between our instances and the public internet for outbound connectivity. If you need to deploy some code from github.com or grab some package updates from a remote repo, the NAT Gateway will let that happen. Now, what about our customers trying to reach our network? That's what our elastic load balancer is going to handle for us. It's going to live here, in front of our frontend resources, and handle that incoming traffic. Let's also put one between our frontend and our backend architecture, as well. Perfect, we've got a three-tiered application that follows AWS best practices. Now, we've got another topic we need to cover. What about our data center that's sitting over here? If we're making a clean break from our on-prem architecture, we can use a virtual private network, also known as a VPN, to create a needed private connection between the cloud and our resources. This is great for that happy little user. We'll put them here, at our data center. And they want to be able to talk to the cloud. They need to be able to send data over the wire in a safe, secure, and encrypted manner. Now, are they using SSH or RDP every day? Got a couple of GBs of files that have to be sent? The VPN is going to be the best bet here. What happens, though, if you need to create that hybrid environment? What happens if your backend servers, or even database, haven't been migrated yet? Most likely, that VPN isn't going to be able to handle all of that traffic. That's where the Direct Connect service comes into play. Essentially, it's a much bigger pipeline that connects your data center and the AWS Cloud together. So let's expand that pipe right now, taking it from a VPN connection all the way up to that Direct Connect service. Direct Connect is run through our partners, and it gives you a private fiber run directly into the AWS backbone. Speeds start at 50 megabits per second, and work their way up to a whopping 10 gigabits. You've got a lot of flexibility in what you're building here. Direct Connect is going to be useful for long-term migrations or hybrid setups. If you're looking to quickly transmit data in a one-time fashion from your data center to the cloud, you'll probably want to avoid using Direct Connect. And we'll cover a solution that'll solve that for us a little bit later, when we talk about Data Sync and the Snow Family. We're giving you the networking building blocks to build whatever you need during this migration process. I'd strongly recommend that you loop in your networking team when you start designing your first VPC, as they're going to have valuable insight into what you need to do. All right, well, that was a lot of networking talk here. I think this is a great stopping point. If you'd like to do some more reading on Direct Connect or VPN options, I've included some links in the readings for this lesson. That's all for me right now. We'll see you soon.
