Low-cost best practices in AWS
Tags: aws, architecture, security
Published: 2022-08-12 17:25:41

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.

**Picture:**

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1660152852417/I-FfM1rL5.png align="left")

**Impact:**

* 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**](https://www.simpleaws.dev?utm_source=blog&utm_medium=dev.to). 3000 engineers and tech experts already have.

<iframe src="https://embeds.beehiiv.com/1c90a8a9-57b7-4a3f-ac56-5f05d0121f72?slim=true" style="margin:0;border-radius:0px;background-color:transparent;display:block;margin-left:auto;margin-right:auto" height="55px"></iframe>

---


## 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.

**Picture:**

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1660152364543/1mNio2Ibd.png align="left")

**Impact:**

* 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html). 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.

**Picture:**

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1660161498467/Jp3OrcfTm.png align="left")

**Impact:**

* 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](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) or [other good sources](https://asecure.cloud/l/scp/). 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:**

* Adding an explicit allow in an SCP doesn't automatically grant permissions to users, it just means the account can do those actions. An explicit deny will deny actions to the root user, every IAM user and every IAM role. That means an SCP that allows everything is the equivalent of not having SCPs (and when you enable all features in the organization that SCP is automatically created and attached)
    
* SCPs are the only way to limit the root user. It's a good practice to [deny all actions by the root user](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-root-user).
    
* Another standard guardrail is to [prevent the account from leaving the organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-leave-org).
    
* SCPs attached to an organizational unit are inherited by child organizational units and child accounts.
    
* SCPs have a limit of 5120 bytes, and only 5 SCPs can be directly attached to an account or organizational unit. Inherited SCPs don't count towards this limit. To circumvent it, [combine multiple effects into a single SCP, delete unnecessary characters such as spaces, and create organizational units to benefit from SCP inheritance](https://aws.amazon.com/premiumsupport/knowledge-center/organization-scp-size/).
    

**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](https://aws.amazon.com/premiumsupport/knowledge-center/ebs-automatic-encryption/), but keep in mind that it's enabled on a per-region basis and that the KMS keys used for encryption are regional.

**Picture:**

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1660239092846/mA-y-sY9U.png align="left")

**Impact:**

* 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](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html).
    

**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:**

* You can use different KMS keys for different volumes or workloads, and you can use policies on those KMS keys to control who can access the volumes and their snapshots
    
* When you [copy a snapshot](https://aws.amazon.com/blogs/aws/ebs-snapshot-copy/) (in the same region or across regions) you can specify a new KMS key to encrypt it. You can do this manually, with an automated EBS snapshot script, or [create automated EBS snapshots with Data Lifecycle Manager](https://blog.guilleojeda.com/how-to-automate-aws-ebs-snapshots).
    
* [You can use multi-region KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
    

**Common mistakes to avoid:**

* EBS encryption by default might not play nice with AWS Server Migration Service. If your migration jobs are failing, try turning off EBS encryption by default. Instead, you can [enable AMI encryption when you create the replication job](https://docs.aws.amazon.com/server-migration-service/latest/userguide/server-migration.html).
    

## 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](https://www.simpleaws.dev?utm_source=blog&utm_medium=dev.to).

* 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!](https://www.simpleaws.dev?utm_source=blog&utm_medium=dev.to)

<iframe src="https://embeds.beehiiv.com/1c90a8a9-57b7-4a3f-ac56-5f05d0121f72?slim=true" style="margin:0;border-radius:0px;background-color:transparent;display:block;margin-left:auto;margin-right:auto" height="55px"></iframe>

If you'd like to know more about me, you can find me [on LinkedIn](https://www.linkedin.com/in/guilleojeda/) or at [www.guilleojeda.com](https://www.guilleojeda.com?utm_source=blog&utm_medium=dev.to)

<script type="text/javascript" async src="https://embeds.beehiiv.com/attribution.js"></script>