I'm asked frequently about
the costs and process of moving a small office file and application
server to the cloud. At Akzium we have moved entire datacenters with
hundreds of servers to a cloud-hosted environment and we've helped small
businesses avoid the upfront investment costs of a physical server by
leveraging low cost cloud computing options.
In this post I'll outline a very simple way that a small office can
"go cloud" with their file and application server. This is just one way
to accomplish the task but it serves as a nice blueprint for all of the
other variations. Also, while there are many options out there for cloud
hosting, I'm going to use Amazon Web Services (AWS) here as the example
since their pricing is easily accessible.
Here is a brief outline of the steps involved in this process:
- Sign up for AWS and create an EC2 instance with EBS storage (~$65.00/mo)
- Configure the AWS EC2 Windows Server (updates, installed antivirus,
opened ports 80/443/3389 on the EC2 instance firewall and VPC
- Create folder(s) on the AWS EC2 Windows file server and assign share permissions.
- Sign up for LogMeIn Hamachi account ($29.00/yr)
- Install Hamachi on the AWS EC2 Server and designated it a HUB
- Install Hamachi on each PC/Mac needing access to the server and designated each of them as a SPOKE
- Used the "browse" option in the Hamachi client on the PC/Mac to
connect to the HUB and login using Windows server username/password to
gain access to the permissions.
With those steps we've created a cloud-hosted Windows file server
with VPN access from remote PC/Mac clients for file shares. I would also
suggest installing something like CloudBerryLab's cloud backup for
servers ($79.99 one-time-cost) and doing backups of all shared folders
into Amazon S3, Azure or any of the many supported cloud object storage
providers supported by CloudberryLab. Costs vary by provider but AWS S3
is roughly three cents ($.03) per GB per month, so for our 120GB example
that would be $3.60/month in backup costs if the entire 120GB was used.
For those who want a more detailed description, I'll expand upon the
steps listed above. First, we need to set up a cloud server. In this
case I'm going to use a server with Microsoft's Windows Server 2012r2
since most businesses use Windows servers, but for the tech savvy user
AWS also offers Linux which can lower one's monthly hosting costs. To
get an estimate of costs for this post I'm using Amazon's AWS Simple
Monthly Calculator for each of the AWS items we'll be discussing here.
Also, I'm not intending for this to be a step-by-step whitepaper on the
process but rather to outline the general procedures for a cloud hosted
file server. An AWS EC2 instance labeled "t2.medium" provides 2 cpus of
compute power and 4GB of memory for $52.71/month including the Windows
Server 2012r2 operating system, plenty of juice for a small office file
server. EBS storage for the file server is roughly five cents ($.05) per
GB per month. For this example let's assume a need for an 80GB "C:"
drive and a 120GB "E:" drive for a total of 200GB of EBS storage which
will cost and additional $10.00/month. Make sure to assign an AWS
Elastic IP to the EC2 instance so that you have a static public IP
address. There are additional bandwidth charges so I've estimated
200GB/mo. of total data transfer which costs and additional $2.00/month
for a grand total of $64.71/month. In the interest of keeping this
example very simple I'm not going to use Amazon's VPC firewall to set up
a site-to-site IPSEC VPN tunnel but rather am going to opt for
LogMeIn's Hamachi VPN solution. Only very limited technical knowledge is
needed for this type of VPN whereas more technical networking skill is
required to set up the IPSEC VPN. The t2.medium instance type does
require that you configure the AWS VPC and assign the instance; you'll
also need to open ports 80, 443 and 3389 on the VPC security rules.
Again, I'll not go into a deep dive tutorial here on AWS EC2 instance
creation and VPC setup here as there are plenty of resources to assist
with that elsewhere.
LogMeIn's Hamachi is a simple solution for creating a
virtual network. You'll need to create a LogMeIn account and log into
the control panel. For $29.00 per year you can set up a single site VPN
with up to 32 remote users. The LogMeIn Hamachi client is installed on
each PC or Mac and from the LogMeIn control panel you designate network
type, members and settings. There are some step by step guides out there
and this post is not intended to guide you through the setup but rather
as an introduction to a reference architecture. Setup of the Hamachi
network is rather simple, once you login to your LogMeIn account, click
on the left hand option for "My Networks", select "Add Network", give
your new network a name such as "XYZ Co Network" and a description and
in this example I elect to use the hub-and-spoke option where the
cloud-hosted server is the "hub" and all other devices are "spokes."
Now, go login to the AWS-hosted server (RDP), open the browser, go to
LogMeIn, login to your account, choose "My Networks" on the left and
install the Hamachi client via "Add Client." The "trick" to connecting
to your recently created network is to know the network ID number which
you can get by clicking on the Edit button next to your recently created
network. The ID will be a 9-digit number (eg 123-456-789). I elected in
my Network Settings to require a password and approval before a member
can be added to the network so if you elect that security option you'll
have to go to the LogMeIn control panel and approve the member. Now, the
one rather non-transparent operation in the Hamachi setup is the
process for designating a "hub" in their hub-and-spoke network
configuration. To do this you go to Add/Remove members and the Hub and
Spoke radio buttons appear on this screen allowing you to designate your
recently approved network member as the Hub server. Not at all
intuitive but once you understand where it is it's not an issue. Next
you should go install the Hamachi client on each Windows PC or Mac that
you want to make a member of the network, again approving the addition
of each member via your control panel.
Once you've set up Hamachi on the AWS server and designated it a Hub,
you'll need to create folders and share them just as you would on a
locally created network server. If you elect not to install the Domain
Controller role on the AWS server you can simply create a "workgroup"
type network. If you go the workgroup route, to make things easier you
might want to change the workgroup name on all of the PCs to match your
designated workgroup name on your AWS server as well as changing the AWS
server instance name to something besides the default cryptic
WIN-xxxxxxxxxx naming convention. If you are restricting shares by user
permissions you can go to the control panel, add users to the local
machine (in this case our AWS server) and designate folder permissions
based on user. I won't delve into a Windows user permissions tutorial
here but suffice it to say that you should do everything just as if you
were on a local server. Next, go to one of the local PCs that you've
installed the Hamachi client on (a "spoke" in Hamachi-speak) and right
click on the Hamachi icon in the Notifications area, open the Hamachi
client and you'll see your Hamachi Network, you should now be able to
click on the network and "see" the AWS server listed. Occasionally, I've
had to reboot the client before it recognized the network. If you click
on the "browse" option, a local Windows File Manager will open and you
should be prompted to login to the server, just remember to use the
XYZSERVERNAME\username convention in the UserID portion of the login
screen if you're not on a domain. Once you've authenticated to the
server you should see your shared folder(s) listed. You can then map a
drive letter to the folder(s). If you make the AWS server a Domain
Controller things get a little easier but that can also bring up other
issues we won't make a part of this post.
A twist on this solution would be to keep a local file server and use
the EC2 instance as a cloud hosted replica using Microsoft's DFS
replication solution or a third-party option such as Vision's DoubleTake
or even the CDP option in CloudberryLab's backup software. In the event
of a local disaster you could then instantly launch the Hamachi client
and connect to the replicated EC2 file server and continue on with
business as usual until the local server was repaired or replaced.
