Moving to AWS (?) – Part 3

Previous parts: 1 and 2.

Today we will look at the new network design as we move resources to AWS. Mainly we want to focus on the security camera system as it is the most complex. Any web hosting, for example this blog, will just move from a server onsite to a server in AWS, keeping complexity low.

Looking at the existing design for our security server we see three main traffic flows that needs to move. End users viewing video feeds internally and externally, as well as the security server connecting to cameras. Let’s start with a diagram of the existing setup:

Here is how the flows will change if we migrate the security server to AWS:
The main challenge will be the video feeds, which will have to traverse the public Internet, versus local LAN as is the case today. We want to make sure the traffic is encrypted, possibly through a VPN tunnel. We also need to take into account bandwidth, as today the video streams are 1080p 30fps, which consumes a significant amount of bandwidth. We want to make sure to tweak this to not consume all available upload bandwidth (10 Mbps). Perhaps we will configure QoS here as well, and give the video feeds a lower priority.

In the previous part we were planning to use two servers; one for the security system which has to run on Windows and one for various smaller functions such as a couple of web servers, running on Linux. For the Linux server it makes sense to use containers through Docker and Amazon ECS. Using containers gives us easier administration, and using Amazon ECS gives us a great opportunity to become more familiar with this platform.

The design options looks like this:

As the last step of our planning we need to put together some lists of tasks to be completed in order for our migration to AWS to be successful. These tasks will be listed in part 4.