Webinar: Best Practices Learned from 2,000 AWS VPC Configurations
Buurst Staff
June 03, 2019

The following is a recording and full transcript from the webinar, “Best Practices Learned from 2,000 AWS VPC Configurations”. You can download the full slide deck on Slideshare


Full Transcript: Consolidate Your Files in the Cloud

John Bedrick: Good afternoon everyone. Welcome to the SoftNAS webinar, today, on Lessons Learned from 2,000 Amazon VPC Configurations. As the title say, during today’s webinar, we’ll be talking about some of the lessons that we’ve learned from configuring over 2,000 VPCs for our customers on AWS.

Our presenter today will be Eric Olson the VP of engineering here at SoftNAS. Erick has personally configured most of these VPCs for our customers. Eric, I’ll go ahead and give you a second to say hi.

Eric Olson: Good morning and good afternoon for everyone. Thanks for taking the time out to join our webinar today.

Taran: Fantastic. Thank you, Eric

Eric:  You are welcome.

Taran:   Before we begin today’s webinar, we just want to cover a couple of housekeeping items with everyone. Just so everyone’s aware, you can listen to this webinar through your phone or through your computers audio. You can select the telephone option if you want to dial in through your phone or the mic and speakers option if you want to listen in through your computer.

We are also going to be taking questions during this webinar. On the GoTo webinar control panel, you’ll see a questions pane. Please feel free to ask any questions that you might have during this webinar.

We know that with Amazon VPCs there tend to be a lot of questions and we’re here to answer any questions that you may have. Eric is personally looking forward to answering all your questions.

Finally, this session is being recorded. After today’s webinar, we are going to send out a link that has both the webinar video and the slide deck readily available.

For those of you who are interested in using SoftNAS, you’ll have that information on-hand. For our partners, you’ll be able to share this webinar in the slide deck with your customers.

As a bonus for joining today’s webinar, we are offering $100 AWS credits. The first 100 attendees to register during this webinar will receive a $100 AWS credit, and the link for that credit will be announced at the end of the webinar.

For our agenda today, we’re going to be talking about what is a Virtual Private Cloud or VPC. We’re going to talk about the 10 lessons that we’ve learned from configuring all these VPCs. We’ll also tell you a bit about how SoftNAS uses VPCs, and we’ll give you a bit of an overview about SoftNAS as well.

Finally at the end of the webinar, we are going to be answering ant questions that may pop up during the webinar.

Just a little bit of background here. We’ve configured over 2,000 Amazon VPCs for our customers and some of the customers that we’ve configured the VPCs for are listed out here.

We’ve got a wide-range of experience in both the SMB and the Fortune500 market. Companies like Nike, Boeing, Autodesk, ProQuest, Raytheon, have all had their VPCs configured by SoftNAS.

Just to give you a brief overview of what we mean by SoftNAS. SoftNAS is our product that we use for helping manage storage on AWS. You can think of it as a software-defined NAS.

Instead of having a physical NAS as you do on traditional data center, our NAS is software-defined and it’s based-fully in the cloud with no hardware required. It’s easy to use.

You can get up and running in under 30 minutes and it works with some of the most popular cloud computing platforms so Amazon, VMware, Azure, and CenturyLink Cloud.

With that, I’ll go ahead and hand it over to Eric to talk about lessons learned from our VPCs. Eric, I’m going to go ahead and make you the presenter.

Eric: Thank you very much, Taran. Hopefully, everybody can hear me well as well as see my screen. Thanks again for taking the time out to join this morning or this afternoon, depending upon your time zone.

Let’s go ahead and dive into it. Just one other reminder; if you have any questions, go ahead and stick them into the chat, and at the end, we will get to them and I will hopefully answer as many of them as I can.

Let’s get started with some terminology and some overview before we dive in. what is a VPC or a Virtual Private Cloud? It can be broken down in a couple of different ways, and we’re going to break this down from how Amazon Web Service looks at this.

It’s a virtual network that’s dedicated to you. It’s essentially isolated from other environments in the AWS Cloud. Think of it as your own little mini data center inside of the AWS data center.

It’s actually a location where you launch resources into and allow you to virtually logically group them together for control. It gives you configuration flexibility to use your own private IP addresses, create different subnets, routing, whether you want to allow VPN access in, how you want to do internet access out, and configure different security settings from a security group. I’m on access control list point of view.

The main things to look at that I see are around control. What is your IP address range? How is the routing going to work? Are you going to allow VPN access? Is it going to be a hardware device at the other end? Are you going to use Direct Connect? How are you going to architect your subnets?

These are all questions. I’m going to cover some of the tips and tricks that I have learned throughout the years. Hopefully, these will things that will help everyone because there is not really a great VPC book out there or dot guidance. It’s just a smattering of different titbits and tricks from different people.

Security groups and ACL’s as well as some specific routing rules. There are some specific features that are available only in VPCs. You can configure multiple NIC interfaces.

You can set static private IPs so that you don’t ever lose that private IP when the machine is stopped and started, and certain instances such as the T2s and the M4s, their primary purpose is to be lost within a VPC.

This is the way that you could perform your hybrid cloud setup or configuration. You could use Direct Connect, for example, to securely extend your premise location into the AWS Cloud, or you could use your VPN connection in the internet to also extend your premise location into the cloud.

You can peer the different VPCs together. You can actually use multiple different VPCs and peer them together for different organizational needs. You can also peer them together with other organizations for access to certain things — think of a backend supplier potentially for inventory control data.

Then there is a bunch of endpoint flow logs that help you with troubleshooting. Think of this, for those of you that have a Linux background or any type of networking background, like a tcpdump or a Wireshark ability to look at the packets and how they flow and that can be very useful when you’re trying to do some troubleshooting.

Just some topology guidance so hopefully you’ll come away will something useful here. Our VPC is used in a single region but will be a multiple availability zone.

It will extend across at least two zones because you’re going to have multiple subnets. Each subnet lives in a single availability zone. If you configure multiple subnets, you can configure this across multiple zones. You can take the default or you can dedicate a specific subnet to a specific zone.

All the local subnets have the ability to reach each other and route to each other by default. The subnet sizes can be from a /16 to a /28 and you can choose whatever your IP prefix is.

How can access traffic within the virtual private cloud environment? There’s multiple difference of these gateways. What do these gateways mean and what do they do? You hear these acronyms IGW, VPG, and VGW? What does all this stuff do?

These gateways generally are provisioned at the time of VPC creation, so keep that also in mind. The internet gateway is an ingress and egress for internet access.

You can essentially in your VPC point specific machines or different routes to actually go out over the internet gateway to actually access resources outside of the VPC or you can restrict that and not allow that to happen. That’s all based upon your organizational policy.

A virtual private gateway, which is basically the AWS side of a VPN connection, if you’re going to have VPN access into your VPC, this is the VPC on the AWS side of that connection and the CG is the customer side of the VPN connection within a specific VPC.

From a VPN option, you have multiple subsets. I mentioned the Direct Connect which would essentially give you dedicated bandwidth to your VPC. If you wanted to extend your premise location up into the cloud, you could leverage Direct Connect for your high-bandwidth lower latency type of connections.

Or if you wanted to just be able to make a connection faster and you didn’t necessarily need that level of your throughput or performance, you can just tap up a VPN channel.

Most VPN vendors like Cisco and others are supported and you can easily download a template configuration file for those major vendors directly [pause 10:50].

Let’s talk a little bit about how the packets flow within a VPC. This is one of the things that I really wish I had known earlier on when I was first delving into configuring SoftNAS instances inside of VPCs and setting up VPCs for customers in their environments.

Its, there is not really a great documentation out there on how does packets get from point A to point B under specific circumstances. We’re going to back to this a couple of different times, but you’ve got to keep this in mind that we’ve got three instances here — instance A, B, and C — installed on three different subnets as you can see across the board.

How do these instances communicate to each other? Let’s look at how instance A communicates to instance B. The packets hit the routing table. They hit the node table. They go outbound to the outbound firewall.
They hit the source and destination check that occurs and then the outbound security group is checked. Then the inbound security group source and destination check in firewall.

This gives you an idea if you make different configuration changes in different areas, where they actually impact and where they actually come into play. Let’s just talk about how instances would talk B to C.

Let’s go back to this diagram. We’ve already shown how A would communicate with B. How do we get over here to this other network? What does that actually look like from a packet flow perspective?

This is how it looks from an instance B perspective to try to talk to instance C, where it’s actually sitting on two subnets and the third instance (instance C) is on a completely different subnet.

It actually shows how these instances and how the packets would flow out to a completely different network and this would depend with in which subnet each instance was configured in.

Some of the lessons that we’ve learned over time. These are personal lessons that I have learned and things that I wish that if, on day one, somebody handed me a piece of paper. What would I want to have known going into setting up different VPCs and some of the mistakes that I’ve made throughout my time.

Number one is tag all of your resources within AWS. If you’re not doing it today, go do it. It may seem trivial, but when you start to get into multiple machines, multiple subnets, and multiple VPCs, having everything tagged so that you can see it all in one shot really helps not make big mistakes even bigger.

Plan your CIDR block very carefully. Once you set this VPC up, you can’t make it any bigger or smaller. That’s it, you’re stuck with it. Go a little bit bigger than you think you may need because everybody seems to really wish they hadn’t undersized the VPC, overall.

Remember that AWS takes five IPs per subnet. They just take them away for their use. You don’t get them. Avoid overlapping CIDR blocks. It makes things difficult.

Save some room for future expansion, and remember, you can’t ever add any more. There is no more IPs once you set up the overall CIDR.

Control the network properly. What I mean by that is use your ACLs, use the things in the security groups. Don’t be lazy with them. Control all those resources properly. We have a lot of resources and flexibility right there within the ACLs and the security groups to really lock down your environment.

Understand what your subnet strategy is. Is it going to be smaller networks, or you’re just going to handout class Cs to everyone? How is that going to work? If your subnets aren’t associated to a very specific routing table, know that they are associated to the main routing table by default and only one routing table is the main.

I can’t tell you how many times I thought I had configured a route properly but hadn’t actually assigned the subnet to the routing table and put the entry into the wrong routing table. Just something to keep in mind — some of these are little things that they don’t tell you.

I’ve seen a lot of people configure things and aligning their subnets to different tiers. They have the DMZ tier, sloe the proxy tier, and subnet. They are subnets for load balancing, subnet for application, and subnet for databases. If you’re going to use RDS instances, you’re going to have to have at least three subnets, so keep that in mind.

Set your subnet permissions to “private by default” for everything. Use Elastic Load Balancers for filtering and monitoring frontend traffic. Use NAT to gain access to public networks. If you decide that you need to expand, remember the ability to peer your VPCs together.

Also, Amazon has endpoints available for services that exist within AWS such as S3. I highly recommend that you leverage the endpoints capability within these VPCs, not only from a security perspective but from a performance perspective.

Understand that if you try to access S3 from inside of the VPC without an endpoint configured, it actually goes out to the internet before it comes back in so the traffic actually leaves the VPC. These endpoints allow you to actually go through the backend and not have to go back out to the internet to leverage the services that Amazon is actually offering.

Do not set your default route to the internet gateway. This means that everybody is going to be able to get out. And in some of the defaulted wizard settings that Amazon offers, this is the configuration so keep it in mind. Everyone would have access to the internet.

You do use redundant NAT instances if you’re going to go with the instance mode, and there are some cloud formation templates that exist to make this really easy to deploy.

Always use IAM roles. It’s so much better than access keys. It’s so much better for access control. It’s very flexible. Here in the last 10 days, now you can actually attach an IAM role to a running instance, which is fantastic, even easier to leverage now that you don’t have to deploy the new compute instances to attach and set IAM roles.

After we’ve been through that, how does SoftNAS actually fit into using VPC and why is this important? SoftNAS, we have a high-availability architecture leveraging our SNAP HA feature which provides high availability for failover cross zones, so multiple AZ high-availability. We leverage our own secure block replication using SnapReplicate to keep the nodes in sync, and we can provide a no downtime guarantee within Amazon if you deploy SoftNAS with the multiple AZ configuration in accordance with our best practices.

This is how this looks and we actually offer two modes of high availability within AWS. The first is the Elastic IP based mode where essentially two SoftNAS controllers can be deployed in a single region each of them into a separate zone.

They would be deployed in the public subnet of your VPC and they would be given elastic IP addresses and one of this elastic IPs would act as the VIP or the virtual IP to access both controllers. This would be particularly useful if you have on-premises resources, for example, or resources outside of the VPC that need to access this storage, but this is not the most commonly deployed use-case.

Our private virtual IP address configuration is really the most common way that customers deploy the product today, and this is probably at this point about 85 to 90-plus percent of our deployments is in this cross-zone private approach, where you deploy the SoftNAS instance in the private subnet of your VPC.

It’s not sitting in the public subnet, and you pick any IP address that exists outside of the CIDR block of the VPC in order to be able to have high availability, and then you just mount your NFS clients or map your CIFS shares to that private virtual IP that exists outside of the subnet of the CIDR block for the overall VPC.

Some common mistakes that we see when people have attempted to deploy SoftNAS in a high availability architecture in VPC mode. You need to deploy two ENIs or Elastic Network Interfaces on each of the SoftNAS instances.

If you don’t catch this right away when you deploy it…Of course, these ENIs can be added to the instance after it’s already deployed, but it’s much easier just to go ahead and deploy the instances with the network interface attached.

Both of these NICs need to be in the same subnet. If you deploy an ENI, you need to make sure that both of them are in the same subnet. We do require ICMP to be open between the two zones as part of our health check.

We also see that the other problem is that people are providing access to S3. We actually as part of our HA provide a third-party witness and that third-party witness is an S3 bucket.

So, therefore, we require access to S3, so that would require an endpoint or access out of your data infrastructure.

For Private HA mode, the VIP IP must not be within the CIDR of the VPC in order to overcome some of the networking limitations that exist within Amazon. Taran, I’m going to turn it back over to you. That concludes my portion of the presentation.

Taran: Thanks, Eric. I just want to confirm that, yeah, my screen is showing. Just to give everyone a brief overview of SoftNAS cloud. Basically, what we are is a Linux virtual appliance that’s available on the AWS marketplace. You are able to go to SoftNAS on AWS and spin up an instance and get up and running in about 30 minutes.
As you can see on the slide here, our architecture is based on ZFS on Linux. We have an HTML5 GUI that’s very accessible and easy to use. We do work on a number of cloud platforms including AWS, as well as Amazon S3 and Amazon EBS.

To give you a brief overview of our partners here, we do partner heavily with Amazon Web Services and that’s why we’re doing this webinar. We also do partner with a couple of other technology providers as well – NetApp, SanDisk, VMware; and some other cloud partners as well including 2ndWatch, CloudHesive, and RELIS.

As we said earlier on in the webinar, in order to reward everyone for joining today’s webinar, if you go ahead and click on the link here, we’re offering $100 AWS credits to everyone who joined in.

The first 100 people to register by clicking on this link right down here on the bottom will be able to go in and register for a free $100 AWS credit. Then someone from our team will be in touch with you and will send you a code for that credit.

Before we begin the Q&A session, I’d just like to remind everyone, if you do have any questions that you wanted to ask us, please feel free to put those questions in the questions pane. I can see we’ve gotten a number of questions already. We’ll go ahead and answer them in just a few moments.

What we would like to invite everyone to do is to try SoftNAS free for 30 days on AWS. You’ll see here, we have some links on the right that will go ahead and give you some more information about SoftNAS.

This first link, “Learn More,” takes you to our page and lets you learn more about how SoftNAS works on AWS and answers any questions you might have about some of the features and the tech specs required in order to use SoftNAS.

Also, we do offer a 30-day free trial as well. For those of you who are interested in trying out SoftNAS, just go ahead and click on the “Free Trial” link and we will go ahead and allow you to do a free 30-day trial of SoftNAS.

During the free 30-day trial, our support team is available to answer any questions that you may have, and we are happy to work with you and help you with your specific use-case.

We also do invite you to contact us as well. If you have any questions about your specific use-case or how SoftNAS can help you with cloud migrations, setting up your VPCs, just go ahead and contact us and someone from our team will be in touch with you shortly.

If you also want to see a one-on-one demo of SoftNAS, that’s how you can get the demo as well. Finally, our support team is also available to answer any questions you may have. For those of you who are currently using SoftNAS or are thinking about using SoftNAS, go ahead and reach out to our support team.

That covers this slide. Now we’ll go ahead and answer some of the questions that all of you have been asking during today’s webinar.

The first question that we have is, “How do you assign an IP that’s not in any of the subnets of the VPC?” Eric?

Eric: Actually, that’s pretty simple. I know this sounds crazy. You just make it up. It just needs to be any IP address that’s not within the CIDR block of the VPC. When you go and set up, SoftNAS high availability will ask you for what that’s going to be.

Once that’s done, we’ll go ahead and take care of everything from there by adding the static routes into the routing table automatically. It’s just any IP that’s not within the CIDR block of the VPC.

Taran: The next question that we have here is probably more common. Regarding redundant NAT instances, it would be good to stress that NAT gateways are now available which makes NAT use very easy. Any comments on that, Eric?

Eric: Yeah, they are great. Some people can use them if your organization permits. They are fantastic. NAT gateways are great and it’s basically like a service. Instead of having to deploy physical compute, you can leverage the services for it.

Taran: The next question we have here is, “SoftNAS basically works like a NAS but in the cloud, is that correct?”

Eric: That’s correct, yes.

Taran: The next question that we have here is, “When I move storage to the cloud, do I also have to move my SQL server as well or can that stay on-prem?”

Eric: It can stay on-prem. However, you would be much better served by keeping all of your applications that use the storage as close together as possible. Putting a WLAN between the storage of the database is leveraging and itself. The physical database could lead to some performance challenges. But take that up for consideration before going and adding into production.

Taran: The next question that we have here is, “What’s the storage limit for SoftNAS on AWS?”

Eric: The storage limit for SoftNAS is 16 petabytes on AWS and that can be achieved via the use of both EBS and a combination of EBS and S3.

Taran: The next question that we have here is, “I saw on one of the slides that SoftNAS supports NFS, CIFS, and iSCSI. Is it true that SoftNAS also supports AFP for my Mac clients?”

Eric: That is true.

Taran: That looks like that’s all the questions that we have today. We want to thank everyone for joining today’s webinar. If you have any questions for SoftNAS, please feel free to reach out and we’ll be happy to answer any questions that you may have.

Again, we invite everyone to try out SoftNAS for 30 days, on AWS, and we’ll be happy to go ahead and set you up. We would go ahead and happy to help you out.

As a reminder, this webinar recording is being sent out as a link shortly after today’s webinar is over. So if you want to pass that email or that link around to your colleagues, you’ll be able to do that through the email that we send. The video will also be on YouTube and the slides will be on SlideShare.

Once again, we want to thank everyone for joining today’s webinar. All of you have a fantastic day.

Subscribe to Buurst Monthly Newsletter 

More from Buurst

Try SoftNAS at No Cost