Low-cost best practices in AWS

Low-cost best practices in AWS

Have you ever felt that doing things right is way too expensive? Well, you're not entirely wrong. The absolute best, bleeding-edge technology can significantly impact your wallet, and to be honest, it's often not worth it except for very few use cases.

But that's no excuse for doing things entirely wrong either! There is an acceptable middle ground where you can invest a little to get a lot. In this article, I'll show you a few things you can do in your AWS solution to improve your Reliability, Performance Efficiency, Security, Operational Excellence, or Cost Optimization, or perhaps more than one of those. They're not difficult, and they're not expensive. You'll spend very little time and money, and get a big impact out of this. They're low-cost!

Implementing MFA in AWS

AWS services involved: IAM or IAM Identity Center

Well-Architected pillars: Security

Description: It's pretty simple, always use MFA. MFA stands for Multi-Factor Authentication. Possible authentication factors are: Something that you possess (e.g. your phone), something that you know (e.g. your password), something that is inherent to you (e.g. your fingerprints), your location. A simple way to implement this is to require an MFA device such as Google Authenticator (an app for Android and iPhone) for logins. That way, if someone knows your password, they won't be able to log in without having access to your phone as well.




  • If someone knows your password, they won't be able to log in with just that; they'd need another factor.

  • It can be a bit annoying to pull your phone out of your pocket every time you want to log in, but it's a lot less annoying than dealing with a hijacked account.

How to implement: Go to IAM or IAM Identity Center and set up your MFA device for your user.

A few tips:

  • In IAM Identity Center, you can require that users have an MFA device set up.

  • In IAM Policies, you can require MFA for some actions, such as deleting resources.

Common mistakes to avoid:

  • Not using MFA.

Master AWS with Real Solutions and Best Practices. Subscribe to the free newsletter Simple AWS. 3000 engineers and tech experts already have.

AWS Multi-account setup with single sign-on

AWS services involved: AWS Organizations, AWS IAM Identity Center

Well-Architected pillars: Operational Excellence, Security

Description: Don't throw every AWS resource (EC2 instances for dev and prod, S3 for backups, etc.) into the same AWS account. Instead, create multiple accounts (as many as you need), each with a clearly defined purpose (e.g., dev environment for app 1), all grouped under the same Organization. Use consolidated billing so you only need to introduce your payment details once. Use AWS IAM Identity Center (formerly Single Sign-On) so you have just one username and password for all accounts. Limit who can access which accounts.




  • Workload separation and much easier work isolation

  • Ability to introduce Service Control Policies (SCPs) to enforce specific limitations across your entire organization

  • Better security and access control between accounts and environments

  • No long-lived access keys

How to implement: Create a new AWS account and use it to create an AWS Organization, enabling all features. Do this even if you already have an AWS account, and invite your existing AWS account into the Organization. Create all accounts that you need (you can create more later). Go to the IAM Identity Center service and set it up in your preferred region. If you want to use an existing identity provider such as Microsoft AD or Google Workspaces, connect it. Otherwise, create your SSO users directly in IAM Identity Center. Group users in groups, assign permissions to each group.

A few tips:

  • Organize your accounts in a hierarchy and apply policies at the root level or Organizational Units (OUs) to enforce specific limitations across your organization.

  • Use AWS IAM Identity Center to enable single sign-on across your AWS accounts, which simplifies managing access to multiple accounts.

  • You can use AWS CLI with IAM Identity Center, see here how to configure it.

  • You can create your own users in IAM Identity Center or you can connect your existing identity provider such as Okta, Microsoft AD or Google Workspaces (formerly GSuite).

  • Always use MFA.

  • There are a few accounts that are common in multi-account setups: Security (for security stuff such as access logs and related tools, appliances, etc), Shared Services (anything that's for multiple accounts, environments or apps, such as CI/CD), Log Archive (archiving logs), Backups (it's easier to isolate them and ensure nobody has write or delete access if they're in a separate account), Networking (shared network services, for example NAT Gateways shared with all accounts).

  • There's no cost for cross-account traffic, and resources can be shared with Resource Access Manager to, for example, deploy an EC2 instance in a subnet that belongs to another account. For other stuff you'll need IAM roles to be assumed by your services in another account and trust policies that permit that.

Common mistakes to avoid:

  • Overcomplicating the account structure - keep it simple and clear.

  • Not having a proper naming convention for your accounts.

  • When migrating from a single account to a multi-account setup, don't use your existing account as the Organization root. It's not a good practice to deploy resources on the root account, because it can't be limited by Service Control Policies. Instead, create a new account (you'll need to add payment details just this once), use it to create an AWS Organization and then invite your existing account

  • Don't grant everyone access to everything. Do your developers really need write access to the production account? Grant only what's necessary, and review the permissions and the necessities periodically.

Using AWS Service Control Policies

AWS services involved: AWS Organizations

Well-Architected pillars: Security

Description: Service Control Policies (SCPs) are like IAM Policies, but they apply to the whole account (or all accounts in the Organizational Unit), and instead of actually granting permissions, they specify the maximum permissions an account can have. SCPs require the account to be in an Organization (see above). They affect the root user and every IAM user or role, so they can be used to prevent any action in an account. Typically used as safeguards, e.g. deny all actions in a region you don't use, or only allow creating resources if they have a certain tag.




  • Guardrails around what people can do in an account

  • Ability to deny actions to every user, including the root user

How to implement: On the root account of your organization go to the Organizations service and make sure that all features are enabled for your organization. Go to Policies and Service Control Policies. Write a policy or copy one from the official example policies or other good sources. Then go to Accounts, choose an account or organizational unit, click on the Policies tab and attach your new policy to the account/OU.

A few tips:

Common mistakes to avoid:

  • If an action is not explicitly allowed by an SCP (for example you deleted the default SCP that allows all actions), then it's denied.

  • SCPs do not apply at all to the root account of the organization. For that reason, that account is more vulnerable than the other ones. The best practice is to use the root account as little as possible, and never deploy workloads there.

  • Allowing everyone access to the root account of the organization, so that they can modify SCPs, can help prevent mistakes and accidents, but won't protect you from an attacker.

Encrypting AWS EBS volumes

AWS services involved: AWS Key Management System, AWS Elastic Block Storage

Well-Architected pillars: Security

Description: Data at rest should be encrypted. When you create an EBS volume you have the option to encrypt it just by changing a dropdown from No to Yes. Simple enough, right? Well, you might forget. Let's be honest, you will forget, at some point. Luckily, you have the option to enable encryption by default, which means that all EBS volumes will always be encrypted. It's pretty simple to enable, but keep in mind that it's enabled on a per-region basis and that the KMS keys used for encryption are regional.




  • All your EBS volumes will be encrypted

  • All your EBS snapshots will also be encrypted, with the same KMS key used for the volume. This means that to share a snapshot with another account you will need to grant that account permissions to use the KMS key.

  • You won’t be able to share encrypted AMIs publicly, and any AMIs you share across accounts need access to your chosen KMS key.

  • You won’t be able to share snapshots / AMI if you encrypt with AWS managed CMK

  • The default encryption settings are per-region. As are the KMS keys.

  • Amazon EBS does not support asymmetric CMKs.

How to implement: Open the EC2 console. On the EC2 Dashboard scroll down to Account attributes and click EBS encryption. Click Manage, tick the box below Always encrypt new EBS volumes and click Update EBS Encryption. That's it.

A few tips:

Common mistakes to avoid:

Wrapping up

This was just a list of good practices that you can implement for a really small time and money investment, and get a big impact. Low cost, and best value for money/time.

It's by no means an exhaustive list. It could be a good starting point, but don't stop here. Keep finding the low hanging fruit, the simple things you can improve, and keep improving your cloud solution.

You probably don't need big and super expensive solutions. Don't overpay, don't overengineer. But don't settle.

Master AWS with Real Solutions and Best Practices.
Join over 3000 devs, tech leads, and experts learning real AWS solutions with the Simple AWS newsletter.

  • Analyze real-world scenarios

  • Learn the why behind every solution

  • Get best practices to scale and secure them

Simple AWS is free. Start mastering AWS!

If you'd like to know more about me, you can find me on LinkedIn or at www.guilleojeda.com

Did you find this article valuable?

Support Guillermo Ojeda by becoming a sponsor. Any amount is appreciated!