Beginner start with AWS – Migrate to AWS Serverless services on-premises trivial resources


AWS migration, starting small and slowly moving your production services into AWS Cloud Services. I may be late to the game, but better late than never. AWS serverless services can be used to augment, improve and optimize the availability of your onpremises production services.

If you do decide to start with AWS open 3 AWS Linked Accounts, first AWS account should be only the AWS billing account, open a second and third account. The second AWS account should be the account onto which you start deploying some production payload and the third account can be the account from which you and other admins login and assume the roles into account 1 and 2. In addition using AWS linked accounts or AWS Organizations enables to have one consolidated bill. This piece of information did not become available to me in the first trainings I subscribed to. It is mentioned in the more advanced courses. If you are a Linux Sys Admin then your burden to the cloud is lessened further because all public clouds with one exception run on Linux. So more power to you.

I have obtained two AWS certifications and there still things that are not apparent, only when starting with production into AWS one can truly understand to a better depth the finer nuances in the AWS cloud. So far the monthly bill is under fifty dollars but the returns are a few fold more valuable. For starters, most everyone in systems admin roles may find some small production feature to migrate to AWS, even if they are just beginning with AWS.

If you have some static website that just needs to be highly available you can move it to the AWS cloud CloudFront or S3, or a logo for an email signature. Extremely useful to use are Route 53 health-checks monitoring on-premises  public facing services. If you have a public website hosted on premises then throw a few healthchecks into AWS cloud, to monitor your website’s availability. You can setup route 53 healthchecks with CloudWatch Alerts, that subscribe to an SNS topic and email when you have on outage to the website. Even if your website is at home you can put an AWS healthcheck on it. FYI AWS healthchecks to non AWS resources are pricier.

It is not apparent that even if the healthchecks in Route 53 are global, the CloudWatch Alarms are hosted only in the North Virginia Region (US-EAST-1). Moreover you can host a static website in CloudFront with an origin in S3 to minimize the exposure of your perimeter network. AWS services are changing and improving at rapid pace and many features of your on-premises production services can be moved to AWS microservices at a fraction of the cost. I can understand that the principle of “Why not host it on premises if the infrastructure exists”, is still strong, but some of the services offered by AWS are making your Sys admin life much easier than hosting complicated solutions for trivial payloads. In this manner there are less things for you to worry about.

As a sysadmin beginner in a small environment Studying the AWS cloud or any other major cloud, and how infrastructure is provisioned and architected in the cloud can open your eyes on how large organisations handle tens of thousands of servers or instances. It may not be apparent once you are starting with AWS but new avenues will open before you as you start to migrate to AWS cloud services some of your smaller resources. And I say AWS services because it is a great excuse to migrate some small production resource to AWS Serverless architecture. Once you go serverless there is no additional overhead like patching, restarts scheduling maintenance and the like. Just like in a book if you capture a wagon of supplies from the enemy is worth 20 of yours, or something like that. In a similar instance if you manage to outsource to AWS one payload and decommission a VM instance then is like you don’t have to take care of 20 VM.

I feel that if you can decommission a few virtual machines and migrate to AWS serverless service, there’s none more to gain. In this manner you can reduce the onpremises exposure to the outside, and also you can restructure to a smaller and less complicated infrastructure as time goes on. Or in the least you don’t need to manage those decommissioned instances.

I began this AWS journey to challenge myself, but many questions have been answered by studying the cloud about how things are done in other organisations or how should I do things better. Now I feel that the AWS migration can be done as the AWS services grow, add and improve their features.If there is a lot of resistance in your organization for going to the cloud then try migrating relatively simple resources to AWS services. There is an added benefit for the Sys Admins having a less to worry.