A surprising number of security incidents happen not to production business infrastructure, but to personal side projects and free-tier AWS accounts set up quickly to test an idea, then left running with minimal security attention. This guide covers the specific, low-effort steps worth taking even for a small personal or side project account, building on our broader cloud security basics guide.
Why free-tier accounts are still worth securing properly
It is tempting to treat a free-tier or side-project account as low stakes, reasoning that there is little to lose. In practice, a compromised AWS account is frequently used by attackers to run cryptocurrency mining workloads at your expense, racking up significant unexpected charges well beyond the free tier limits, or as a launching point for further attacks using your account’s reputation. The financial and cleanup cost of a compromised “unimportant” account is often disproportionate to how little attention it originally seemed to warrant.
Enable multi-factor authentication immediately
This is the single most important step and takes only a few minutes. Enable multi-factor authentication on the root account the moment you create it, before deploying any actual project resources. A root account without multi-factor authentication is the most common single point of failure behind personal AWS account compromises, and it costs nothing and adds minimal friction to your own legitimate access.
Set up billing alerts before you need them
Configure a billing alert at a low threshold — even just a few dollars above your expected free-tier usage — so you are notified quickly if something unexpected starts accumulating charges, whether from a genuine mistake in your own configuration or from unauthorized access. This is a five-minute setup step that gives you an early warning system rather than discovering a large unexpected bill only when the monthly statement arrives.
Do not use the root account for daily work
Create a separate IAM user with appropriately scoped permissions for your actual day-to-day project work, reserving the root account purely for the rare account-level tasks that specifically require it. This limits the damage if your daily-use credentials are ever compromised, since they would not carry the unrestricted access the root account has. Our IAM best practices guide covers this in more depth, and the same principles apply at this smaller scale.
Avoid hardcoding credentials, even in a personal project
It is common in a quick side project to hardcode an access key directly into a script for convenience, intending to clean it up later. If that project’s code ever ends up in a public repository — even accidentally, through a misconfigured repository visibility setting — automated bots scanning public code for exposed credentials can find and exploit it within a short window. Use environment variables even for a personal project, and specifically double-check the visibility settings of any repository before pushing project code.
Clean up resources you are not actively using
Side projects frequently get set aside for weeks or months without being fully shut down, leaving running resources that are neither actively developed nor actively monitored — an ideal target profile, since nobody is paying close attention. When you pause work on a project, either fully shut down the associated resources or specifically schedule time to review its security configuration periodically, rather than letting it run unattended and unreviewed indefinitely.
Understanding what “free tier” actually protects you from
It is worth being clear about a common misconception: the free tier limits how much AWS charges you for your own legitimate usage within defined limits, but it does not prevent an attacker who gains access to your account from launching resources that exceed those limits and generate real charges. The free tier is a billing structure, not a security boundary, and treating it as though it inherently limits your financial exposure in a compromise scenario is a mistake worth correcting early.
This is precisely why the billing alert step matters as much as it does for even the smallest personal project — it is your primary defense against discovering a compromise only through an unexpectedly large bill weeks after the fact.
When a side project becomes something more serious
If a side project starts handling real user data, processing payments, or otherwise moving beyond a purely personal experiment, revisit its security posture with the same rigor you would apply to a genuine business system — the practices in our full cloud security basics guide become directly relevant rather than optional at that point. Many successful small products started as unguarded side projects, and the transition point where security attention needs to increase is easy to miss if nobody consciously decides to make that shift.
Practical starting checklist
1. Enable multi-factor authentication on the root account immediately upon creation.
2. Set a low-threshold billing alert before deploying any resources.
3. Create a separate IAM user for daily work instead of using root.
4. Use environment variables for any credentials, never hardcoded in project code.
5. Periodically review or shut down side projects you have paused, rather than leaving them running unattended.
Frequently asked questions
Is a free-tier account actually a realistic target for attackers?
Yes — automated scanning tools do not distinguish between a personal side project and a production business account, and specifically target exposed credentials and misconfigurations regardless of the account’s apparent importance to its owner.
What should I do if I suspect my free-tier account has already been compromised?
Change your root account password and rotate any IAM credentials immediately, review your billing dashboard and running resources for anything you did not create yourself, and contact AWS support, who have specific processes for handling suspected account compromise and unexpected charges resulting from it.
Do these steps apply equally to GCP’s free tier?
The same underlying principles apply, with GCP’s equivalent tools (organization owner account protection, budget alerts, IAM roles) serving the same purpose as their AWS counterparts described here.
For more on securing your cloud projects as they grow, see our cloud security basics guide and IAM best practices guide.