Getting started with AWS (Amazon Web Services) can feel overwhelming. With so many services and concepts, it’s easy to get lost. However, you don’t need to learn everything at once. By understanding the fundamentals, you’ll build a solid foundation that makes the rest of AWS much easier to navigate.
I know this firsthand. My background is in JavaScript and React development, but recently I started transitioning into cloud development. The shift began when my current role gave me the opportunity to set up a CI/CD pipeline using Docker and AWS EKS (Elastic Kubernetes Service). Although the full pipeline was put on hold, it sparked a fire that I continue to flame.
The tips I’m sharing below come from research and some from experience. My goal is to save you time, help you avoid common pitfalls, and give you practical steps you can use to start building confidently in AWS.
Think of Your AWS Account as a “Container”
I learned this tip from an Adrian Cantrill course. You can think of an AWS account like a container for everything you do in AWS. And two main components of this container are identities and resources. Identities represent users (i.e. developers, admin personnel, hr,…) who have access to your AWS account with certain permissions. Resources in AWS are things like EC2 instances, S3 buckets, or CloudFormation stacks which provide business value to a company. I appreciate this tip because it affords you the ability to think of AWS from a high level. This high level thinking is necessary when conceptualizing how things work or solving system level problems.
Don’t assume because you’re not using an service, you wont be charged
I was under the impression that as long as I turned a service off (i.e. EC2 server) I wouldn’t be charged because AWS is pay as you go. Unfortunately, this isn’t the case. Yes, AWS is pay as you go. But what does “go” mean in AWS? In AWS if a service like EC2 still has “Resources” available like Elastic IP addresses and Amazon Elastic Block Store (Amazon EBS) volumes, then you are still “going” and will continue to rack up charges. Here’s what amazon’s knowledge center says:
”Stopped instances don't incur charges, but Elastic IP addresses or EBS volumes attached to those instances do”
Use plus addressing for multiple accounts
Its important to understand that emails are what make AWS accounts unique. While multiple accounts can share the same credit card info, emails must be different. To overcame this hurdle, you use an email technique known as plus addressing or sub addressing were you add a plus after your email. Heres an example from a google blog:
If your name was hikingfan@gmail.com, you could send mail to hikingfan+friends@gmail.com or hikingfan+mailinglists@gmail.com.
Keep in mind the second account will be bumped up to the paid plan which means you will need to add billing alerts and be cautious about your usage.
Protect your accounts with MFA
When you first start building with AWS, you may be tempted to whip up VPC’s with EC2’s and add S3 buckets to deploy the next billion dollar SAAS product. But what good is your product if someone can easily hack into your account and shut down your whole business. There’s a proverb that goes, “…and he who hurries his footsteps misses the mark. When you rush the process and ignore best practices like setting up an MFA for your IAM users, you miss the mark of securing your app from fraud and nefarious individuals.
Use Multiple Accounts for Safety and Organization
AWS accounts are decoupled. In other words, a mistake in one account shouldn’t affect others. That’s why its a good idea to use multiple accounts for dev, staging, and production. If a hacker gets access to one, you can utilize the others and possible keep your app running in the mean time. This principle avoids having a single point of failure which is a common systems technique.
Embrace IAM (Identity and Access Management) Early
IAM is AWS’s way of controlling who can do what in your AWS accountant. It helps you avoid accidents by limiting permissions. For example, if a team member only needs access to the billing info of your account, no need to give them access to an EC2 instance. This is known as giving a user least privileges to avoid “accidents” or fraud. Its also best practice to avoid using the root user which has unrestricted access to your account. Instead, use the root user to create an IAM user with admin privileges (less permissions than root) and give this access to trusted senior AWS cloud engineers.
Understand IAM Identities: Users, Groups, and Roles
Users: Individual people or applications (e.g., a developer or a backup app).
Groups: Collections of users who share the same policies (e.g., all developers).
Roles: Temporary access for AWS services or external entities (e.g., EC2 accessing S3).
Take Advantage of the Free Tier but understand the details
AWS offers a free tier with limited monthly usage of services like EC2, S3, and Lambda. This is a great way to experiment without worrying about costs. But its also important to understand the details around the free tier. For instance, your free tier will end after 6 months or if you’ve depleted your $100 credits. So if you’re using AWS with a course like I’m currently doing, make you are diligently studying your course before your credits or 6 months runs out.
Take your time when learning
I have to remind myself of this because I’m ready to build apps that can scale millions of users. At the same time, I know that I want to be a highly skilled engineer in the cloud and not an hobbyist. And this means a mastery of the fundamentals.
Use multiple sources if you’re trying to obtain an certificate
I did a bit of research and a common theme I found from this reddit thread is you shouldn’t rely on a single resource to pass an exam. Most of the strategies included taking an online course and taking a practice exam at tutorial dojo also knowns as TD.
Hope you enjoyed these tips. If you found value in this content I encourage you do the one or more of the following:
Share with your community
Leave a comment
Subscribe for more