HasnainWaris

I’ve recently been studying for the AWS SAA and coming from a mostly on Prem or virtual environment I noticed how many of the services I’m reviewing have such great use cases, or the function of the services and how they correlate to previous existing functions. Don’t get me wrong, I don’t see everything about the cloud as a plus, or life changing as an admin, but going over this prep material and coming from an architect POV, I can appreciate the designing of an infrastructure much more.

AWS EC2: Autoscaling

A useful feature with EC2 (AWS’ VM) that I find is the idea of Autoscaling (vertical/horizontal). With on-prem environments you’re often left manually provisioning a new server when an increase in demand comes, or planning ahead of time to build out a cluster build with a load balancer to manage system load.

The convenience of an Auto Scaling Group solves this headache. The purpose is to scale out/in to match the load your application is receiving. And with the various scaling options we can configure based on which scaling option is most applicable to our need. Dynamic (setting a target based off a metric), Scheduling (scaling based off known usage patterns), Predictive (continuously forecasts load and schedules based off it)

From previous experience of handling a similar scenario with on-prem servers, this would save plenty of headache and ease. From reactive to proactive.

AWS: S3 vs Traditional File Storage

Dealing with Files and storage there are plenty of useful tools and functions we are able to use on Linux, nothing is really lacking in terms of usefulness. But there are a few useful features that make S3 a great choice.

With on-prem servers, you’re dealing with setting up file servers, managing disk space, dealing with RAID configurations, worrying about backups, setting up NFS shares for application access etc. These are multiple different applications or services we have to deal with.

S3 gives us various Storage Class options, built-in redundancy, versioning, and lifecycle policies. No managing underlying storage hardware.

Storage classes: With S3 we have various storage options based off need, based off how we want our storage to operate. Do we need instant retrieval of our storage? Frequent or Infrequent access ? Or archive it in Glacier for backups?

Versioning: A very useful feature to help protect against unintended deletes and easy rollbacks to previous versions

Lifecycle Policies: another useful feature to help us move our S3 objects between storage classes. Use case example, if we want to convert an object after X amount of time from frequent access to eventually archiving it as Glacier storage class.

The features are plentiful that I haven’t discussed like encryption, Access Points, performance etc. All useful features available with S3 buckets.

I’ve kept it to just 2 services, but those architecting environments can see different problem solving solutions that Cloud Services can provide. But I wouldn’t say I’m all-in on the cloud, I still very much enjoy the hands on experience with building with On-Prem or virtual environments. Planning and building out clusters and applications with different services and tools, intertwining them into a functioning, highly available end product. And coming from that background I can understand the issues that cloud services try and tackle and the solutions it can offer. Giving me a background to base it off of and relate to.