Top 10 things IT departments miss when setting up AWS

Getting started in AWS is easy. Anyone can do it!  That said, when IT departments set up their own AWS cloud environments, they almost always miss something. Some of the things mean they have to spend more time maintaining things, while others can cause significant security or financial risks.

As an AWS consultancy with years of experience under our belts, we’ve seen it all. Here are the top 10 things that IT departments miss when setting up their cloud environments - and the steps to take in mitigating them:

1. Improper Security Group & IAM setup.
2. Improper VPN design and exposed databases.
3. No billing alerts.
4. Poor cost optimization.
5. Using the wrong AWS services.
6. Building it by hand in the console instead of using Infrastructure as Code (IaC).
7. Backups non-existent or not tested
8. Not understanding how to do logging/auditing
9. Using a 3rd party CDN and CloudFront in line with one another
10. Not using some sort of CICD pipeline

1. Improper Security Group & IAM setup.

The number one biggest mistake that IT departments make when setting up AWS environments is missing key security requirements. Chief among these is improper Security Group setup and leaving and IAM roles open. This is a big deal because it leaves your AWS environment vulnerable, and if you have sensitive information (PII, passwords, etc.) all of those things can be compromised. Paying too much is one thing, getting hacked is a whole other realm of pain.  

If you are concerned you may have missed things here are a few recommendations:

1. Get professional help! No joke. Metal Toad has a low cost to free 6-point AWS inspection, which includes a security review. How can it be free? AWS will fund Proof of Concepts, and our inspection often qualifies.
2. Use the principle of least privilege - only grant the minimum level of permissions required for a user or resource to perform its task. Avoid giving blanket permissions to users or resources.
3. Enable multi-factor authentication (MFA)  - enable MFA for all users who have access to your AWS account. This adds an extra layer of security to your account, making it more difficult for unauthorized users to access your resources.
4. Use automated tools - there are several automated tools available that can help you identify and fix security issues in your AWS environment. Some examples include AWS Config, AWS Security Hub, AWS Trusted Advisor, and AWS GuardDuty.
5. Don’t use the root user - the root user is the one user on your AWS account with unfettered access to everything. The root user can never have their permissions changed or revoked, so it’s a very good policy to never use it AND to set it up using MFA.

2. Improper VPN design and exposed databases.

Improper VPN design may sound like a minor issue, but the real danger here is putting databases or other ‘sensitive’ resources on public IP addresses. When first starting with AWS just getting resources talking to one another can be a real challenge and in the process of trial and error is very common for a Virtual Private Network (VPN) to end up configured without any sort of security, in the worst cases, sensitive databases can be on publicly available IP addresses.

If you are concerned that you might have made your database publicly available on AWS by mistake, here are some steps you can take to check:

1. Check the database's security group settings. Go to the Amazon RDS console and check the security group settings for your database instance. Ensure that the security group allows only authorized traffic and does not allow traffic from any public IP address.
2. Check the database's network ACL settings. If your database is in a VPC, check the network ACL settings to ensure that traffic is not allowed from any public IP address.
3. Check the database's IAM policies. Check the IAM policies associated with your database to ensure that they are correctly configured and do not allow any unauthorized access.
4. Use a port scanner. You can use a port scanner to scan your database's IP address and check which ports are open. If any unnecessary ports are open, you should close them immediately.
5. Get professional help. An exposed database is a real risk and well worth paying someone to help make sure it’s configured correctly. Have we mentioned that Metal Toad has a low cost to free 6-point AWS inspection, which includes a security review?

By taking these steps, you can identify if your database is publicly available and take appropriate actions to secure it. If you find that your database is publicly accessible, you should immediately take steps to restrict access and secure it from unauthorized access. If you have to do this in your production environment, get help right away as that can help mitigate unplanned downtime.

3. No billing alerts.

Now that we’ve addressed the most important security concerns, let’s talk about financial risk. AWS likes to talk about practically limitless scalability, and that is very true. But remember this: with great scaling comes great responsibility paying the bill. If you are new to AWS and haven’t accidentally spent a thousand dollars you didn’t mean to, it’s likely only a matter of time.

Thankfully, AWS does have billing alerts built into their platform, you just need to know how to set them up. You can set up billing alerts on AWS by following these steps:

1. Log in to the AWS Management Console and navigate to the Billing and Cost Management dashboard.
2. Click on the "Preferences" link in the navigation menu on the left-hand side of the screen.
3. Under "Billing preferences", click on the "Receive Billing Alerts" button.
4. Click on the "Create a billing alarm" button.
5. Enter a name for your billing alarm and choose the appropriate threshold for the alarm. You can choose to be notified when your charges exceed a certain amount or when your usage exceeds a certain level.
6. Choose the notification method for your billing alert. You can choose to receive notifications by email, SMS, or SNS (Simple Notification Service).
7. Click on the "Create Alarm" button to save your billing alarm settings.

Once your billing alarm is set up, you will receive notifications when your AWS charges exceed the threshold you have set. You can also view your current billing status and history from the Billing and Cost Management dashboard.  If you need help setting up your billing alerts, this is part of the Metal Toad 6-point AWS inspection.

4. Poor cost optimization.

Poor cost optimization is by far the most common issue with self-set up in AWS environments. If you are new to AWS, I can guarantee you are overpaying. If you are an AWS expert, I can guarantee you are still overpaying. Paying for a cost audit (part of the Metal Toad 6-point AWS inspection) almost all the time has a 100% or more return on investment.  

If you’d like to troubleshoot costs yourself there are several indicators that can help you determine if your AWS environment is poorly optimized from a cost standpoint. Here are some common signs to look out for:

1. Unutilized or underutilized resources. If you have resources such as EC2 instances, RDS databases, or S3 buckets that are not being used or are being used at a fraction of their capacity, it can be a sign of poor optimization.
2. Poorly provisioned resources. If you have resources that are overprovisioned or underprovisioned, it can lead to wastage of resources and higher costs. For example, running a large EC2 instance for a workload that can be run on a smaller instance type.
3. Lack of automation. Manual processes for resource management and deployment can be time-consuming and error-prone, leading to inefficiencies and higher costs (we will come back to this one later).
4. Inefficient architecture. If your architecture is inefficient, it can lead to unnecessary resource usage and higher costs. For example, if you have a poorly designed network architecture that results in high data transfer costs.
5. Lack of monitoring and analysis. If you are not monitoring your usage and costs on AWS, you may miss opportunities to optimize your environment and reduce costs.

To optimize your AWS environment from a cost standpoint, you can perform a cost optimization analysis, implement cost management best practices, and use AWS cost management tools such as AWS Cost Explorer, AWS Trusted Advisor - or get professional help. By regularly monitoring your usage and costs and implementing best practices for cost management, you can ensure that your AWS environment is optimized for cost efficiency.

5. Using the wrong AWS services.

One of the drivers of overpaying is inefficient architecture, which can sometimes come from using the wrong AWS for the job you need done. An example of this is putting everything on EC2 (Compute) instead of using specific services like RDS (database).  This will work, but you are going to pay a lot more AND you are going to miss really great functionality. In the case of using RDS for databases, with a few extra clicks not only can you see improved performance but you can also easily distribute your database across multiple geographies using RDS Multi AZ Deployments.

Choosing the right AWS services for your workloads is crucial for achieving optimal performance and cost-efficiency. Here are some indicators that can help you determine if you are using the right AWS services for your workloads:

1. Performance. If your workloads are experiencing performance issues or are not meeting your performance requirements, it could be a sign that you are not using the right AWS services. For example, if your application is running slow or experiencing high latency, it could be an indication that you need to optimize your database or use a different database service altogether.
2. Cost. If you are experiencing high costs that are not justified by your workload requirements, it could be an indication that you are using the wrong AWS services. For example, if you are using a high-cost service for a workload that can be run on a cheaper alternative, it could be an indication that you need to switch to a more cost-effective service.
3. Scalability. If your workload requires scalability, but your current AWS services are not able to scale effectively, it could be an indication that you are using the wrong services. For example, if your workload requires automatic scaling but your current service does not support it, it could be an indication that you need to use a different service that supports automatic scaling.
4. Features. If your workload requires specific features or functionality that are not supported by your current AWS services, it could be an indication that you are using the wrong services. For example, if your application requires real-time data processing but your current database service does not support it, it could be an indication that you need to switch to a service that supports real-time data processing.
5. Maintenance. If you are spending a lot of time and effort maintaining your current AWS services, it could be an indication that you are using the wrong services. For example, if your workload requires a lot of maintenance to keep your services running, it could be an indication that you need to switch to a more reliable and easier-to-manage service.

By speaking with a professional and evaluating your AWS services based on the indicators above, you can ensure that you are using the right AWS services for your workloads.

That’s it for the top 5 things IT departments miss when setting up AWS themselves! I’ll be filling in the rest of the top 10 in a future blog post. Remember: you can always get help, and it may cost a lot less than you think.