Five Tips to Get You Started in AWS

Unless you’ve been living under a rock, you’ve most likely heard of the recent craze to move everything into the cloud. It’s true, there are many great solutions that a cloud provider can offer over traditional on-premise solutions. From start-ups to large corporations, setting up and maintaining an on-premise environment has always been a headache and has often required hiring full time teams of people to maintain these solutions. Not only do cloud solutions do away with the infrastructure costs, but they also offer a lot that an on-premise solutions could never promise themselves, like elastic compute power.

So yeah, the hype is definitely validated. I might argue that a start-up skip on-premise solutions and jump immediately to the cloud. Yes, I know some people have a data security concern, but here’s my basic take… you’re betting your hardware infrastructure’s security is better than a cloud provider’s security, which is employed by the top security specialists in the world? I could write a full post just on that, but the hubris of some people who think they can do better than the best in the world makes me roll my eyes. (We will address security again down below, since AWS isn’t 100% responsible for all things security.)

Okay, I’m getting off topic! Anyway, if you know anything about cloud, then you know that Amazon Web Services (AWS) currently wears the crown in this space. There’s nothing bad about Microsoft Azure or Google Cloud Platform, but AWS got to the space first and therefore have established a sizable lead for themselves early on. I imagine the other guys will continue to catch up, but I don’t blame you if you want to jump into the cloud space with AWS. They offer a lot of great stuff!

This post is going to run you through a couple quick tips as you get started in AWS specifically. Getting these things right early on will set you up for success in the long run, especially as you scale your operations in the cloud. Without further ado, let’s get into it!

1. Before you do anything, get your IAM house in order.

Of all the tips on this list, this is the one I easily recommend you do before anything. I mentioned in the intro to this post that AWS isn’t 100% responsible for all things security. They operate on a Shared Responsibility Model, and in a nutshell, it means that AWS is responsible for security of the cloud whereas YOU are responsible for your stuff in the cloud. (Check out that link above for more details on that.)

The main service you’ll want to familiarize yourself with here is Identity & Access Management, more commonly known as IAM. IAM enables you to set up a ton of security related stuff that I won’t delve into here for brevity’s sake. Naturally, I recommend you do this first since you should want your stuff secured before you create it! Doing this in post is very risky, especially if you start accumulating a lot of resources in the crowd. If you don’t do anything else in this post, at least make this a priority. You’ll thank yourself later!

2. Make managing your resources a lot easier using tags.

One optional thing offered in AWS is the ability to tag your resources with your user-defined tags. Because it’s optional, it’s so easy to breeze right by this tagging step and not apply tagging! Not only does tagging help you to organize your resources better, but they can also be leveraged within other AWS services for specific purposes. For example, if you tag a set of S3 buckets to be accessed by a “Department” (key) with the name “Marketing” (value), then you can easily set up an IAM group policy that enables only marketing analysts to access those marketing buckets. Easy peasy! But if you DON’T set up these tags right away, then you have to manually configure IAM access to every individual S3 bucket. That can be a nightmare if you have 20+ marketing S3 buckets!

In our example above, we set the key as the “Department” name and the value as “Marketing,” but remember, these key-value pairs are defined by YOU. Don’t want to organize by department? No worries! Just define the key-value tags that make most sense to you. And you’re also not limited to a single key-value tag for each resource. AWS allows up to 50 key-value tags, and I imagine that’ll probably be more than enough for you. So go wild! Just like with IAM, getting this right early on makes things much easier to manage as your cloud ops scale up.

3. Do a little homework on your cost expectations.

One thing that can be a little challenging for companies that have a significant on-premise footprint is knowing how to manage your costs. Whereas costs for on-premise solutions largely revolve around capital expenditures (like buying physical servers), AWS revolves around a mostly pay-as-you-go model. It’s not like there’s a fixed monthly subscription cost to using AWS resources. Think of it like your electric bill. My electric bill is higher in the summer since the AC runs more when it’s hot out, and it’s lower in cooler months.

This can sort of freak people out because AWS can be a little finicky about runaway charges. Generally speaking, I think AWS is pretty cheap. In my personal AWS account, I don’t think I’ve ever spent more than $10 on my personal projects, and I’ve done a fair amount of stuff I thought would be pretty costly. (Like using SageMaker to train and deploy machine learning models.) Granted, my use cases have been pretty small. I have heard of a few instances where larger corporations left something big running over a weekend and literally racked up a $10,000 bill. That’s insane!

I’d say that latter instance is more of an edge case, and it could have been averted with a little homework. In most cases, you’ll find AWS to be cheaper than you expect, but it’s still worth doing that homework so you can avoid those $10,000 runaway bills. AWS offers several tools to help with this, including this AWS Pricing Calculator and the AWS Total Cost of Ownership (TCO) Calculator. 

(Side note: If you want to create your own personal AWS account just for learning purposes, AWS does offer a “free tier” trial period that does a great job at putting a ton of walls that will keep costs very low, if not entirely free. Take advantage of that!)

4. Don’t make the mistake of equating on-premise constrictions to also be problems in the cloud.

Having consulted with people migrating to on-premise to cloud, one thing I see most often amongst people unfamiliar with cloud computing is designing solutions as if cloud computing is constrained in the same way that on-premise solutions can be. For example, it’s very common for people to have to “take turns” using a server because the company has only a single server provisioned for a given task. That’s only a limitation on-premise because the company has only provisioned that one server, so I’ve encountered situations where people want to ensure that that “taking turns” model is optimized in the cloud. Well, that’s not really problem in the cloud where you can easily scale out servers, right?

(This is my favorite problem because I love seeing these people’s eyes light up when they see the opportunity in being able to simultaneously run tasks without having to wait for their buddy’s job to finish up!)

Again, cloud providers and AWS in particular offer a lot of cool things that a on-premise solution could never offer, so don’t think you have to design your specific solution the same way in the cloud. By taking advantage of cloud solutions like elastic scalability, you avoid constrictions imposed by on-premise hardware AND add new capabilities you never dreamed were possible before. Neat!

5. Don’t jump to EC2 as your first option for building your solution.

So if you’ve ever studied for the Cloud Practitioner or Solutions Architect - Associate certifications, you’ll know that these designations emphasize knowing Elastic Compute Cloud (EC2) quite a bit. They also emphasize S3 in the same manner, but in my experience… you don’t typically use “vanilla” EC2 nearly as much as you will almost certainly use S3. There’s nothing at all wrong with EC2, but remember, AWS has abstracted a lot of core functions and solutions in fully-managed services like DynamoDB, Lambda, and more. AWS even advertises some of those services as “serverless,” and the truth is that from your perspective, they might as well be serverless since AWS is managing all that enabling stuff — including the servers — behind the scenes.

This isn’t to say you’ll never use EC2 as there are many specific instances in which you will definitely need to use EC2 to enable a solution. But if you don’t want the headache of having to maintain an EC2 virtual machine, you might want to look to see if AWS has a managed service that you can leverage instead. (And chances are, if you need something, AWS probably has an alternative, fully managed offering for you.)

Alrighty, that wraps up this post! Hope you all learned something here that you can apply to your AWS journey. If you’re already leveraging AWS today, what might you add to this list? Sound off down in the comments! Catch you all in the next post.

Hey there, folks! If you enjoyed this post, please check out my other work at my Medium channel, @dkhundley. I write other posts over there just like this one, including a special line of posts around philosophy and spirituality that I don't typically share here on LinkedIn. I'm really proud of that work, so go and check it out!