What does securing your AWS Environment look like in 2025?

When you look across todays digital landscape it is more critical than ever to ensure that our Cloud environments are secured against bad actors both externally and internally

Wait you say... Internal bad actors, surely this is not a thing?

Well most companies in the present day spend time and money vetting their staff (especially in the UK, I’m not sure on the rest of the world), via supplied references, BPSS checks, potentially even as far as UK Government Security vetting if the systems they are working on require it. This is about as much due diligence you can do, however we have all made questionable decisions in our lives and unfortunately, when a person is under duress, disgruntled etc there is no telling what they may do, so we need to ensure that we protect internally as much as we can.

The Basics

1 - Develop a comprehensive security plan

Before diving into specific practices it is essential to have a well-defined security plan. Your plan should outline things like your security goals, identified potential risks and establish protocols for incident response. Once you have this in place you can dive into specific security policies and configurations standards for AWS Infrastructure, AWS Services and your applications.

2 - Identity & Access Management

Identity & Access Management (IAM) is the backbone of AWS Security so implementing strong IAM policies and configurations will mean you are 90% there.

So when we talk about IAM what areas do we want to look at?

• Secure your Root accounts - Enable MFA, remove programmatic access, use strong passwords and be ultra strict with who has access and what access they have.

• Principle of least privilege - This should be front and center of every permissions policy, that we only grant users or apps/services the permissions they need to perform their tasks.

• MFA..MFA...MFA - Ensure through policies that all users need to have MFA enabled to be able to do anything in the account.

• IAM Roles and Policies - IAM Roles should be used for applications and services so no hard coded credentials are used, combined with this, IAM policies with permissions defined using the principle of least privilege. We can also use permissions boundary policies to set the limits of what levels of privilege cane be added to IAM roles (especially useful for developer accounts). Reviewing Roles and Policies regularly is recommended to ensure Roles are still needed and policies are still protecting as needed.

• Regular Audits - This is often over looked, I know I have mentioned it previously but it is hugely important that you regularly review configured users and IAM roles and assigned IAM policies to ensure that they are still in use and that policies grant the needed permissions only. IAM policies need to be regularly reviewed to ensure that they are assigned to users or roles and if they aren’t carry out some housekeeping and remove them. Maybe this is something you can automate using the AWS CLI and Python or maybe Lambda, maybe someone has already done this... if you have comment a link to help others out.

3 - Data Encryption at Rest and In Transit

• Data at Rest - There are very few AWS Storage services that are not encrypted by default these days, up until very recently... I think (my memory is not as good as it used to be) S3 and EBS were the only services that weren't encrypted by default, however AWS updated S3 in 2023 to ensure all newly created buckets were encrypted by default, which leaves EBS as the only service that is not encrypted by default and requires the user to enable it. So AWS have got you covered there, for all your Data at Rest, you just need to remember to turn it on... and you can always use AWS Systems Manager and AWS Config to check services they need manual enablement of encryption and alert you and take action if needed.

• Encryption in Transit - Making sure all your communications between Applications and AWS Services seems like common sense, however it can be tempting especially when your AWS elements are all in the same VPC and subnets to neglect encryption in transit, however within AWS although things may appear they are all together it is very unlikely and your traffic will be using an internal network to talk, so making sure traffic is encrypted is essentially.

• AWS Key Management Service - Utilising AWS Key Management Service (KMS) can be key to a successful implementation of encrypting data at rest, it allows for you to create and manage keys via AWS, you can bring your own cryptographic material, or if you need something really special you can even setup a Cloud HSM if you have specific requirements.

4 - Monitoring and responding to threats

• Visibility is key - If you are blind to events that are going on in your environment then you cannot act. At the very least you need to have AWS Cloud Trail enabled and CloudWatch setup, CloudTrail ensures you have visibility of actions going on within your AWS Accounts when AWS API's are being called. CloudWatch gives the ability to see what is going on with your workloads and can ingest application logs if the CloudWatch Logs Agent is deployed.

• Detection of Threats - So we have observability but there is a huge amount of information go through, in fact I would wage that it is more information than a human could process effectively. So what do you do, well this is where we would use Guard Duty and AWS Security Hub. With Guard Duty we can utilise powerful machine learning for intelligent threat detection for your AWS environment. Guard Duty can be combined with AWS Security Hub to provide a centralised portal for security alerts and automated compliance checks.

5 - Let's Automate

• Configuration Tracking - so once you have got you environment configured as it should be to best practices etc, how do you know if something changes? Well we have CloudTrail but this only tells you what commands have been executed.. This is where AWS Config comes in, AWS Config tracks your configurations and has several functions that you can utilise, the first is configuration tracking and alerting, so if a configuration changes you can get alerted to the changes so you can act, however the second function you can pair it with is AWS Systems Manager (SSM) Automation, so that when a particular configuration is modified SSM can be triggered and take action to correct configurations.

• Lambda is not just for serverless apps - Lambda is very versatile and can be used in an event driven way to automate responses to security threats. A great use case for Lambda is isolating compromised instances or revoking access keys.

• SSM can do the hard work - keeping workloads up to date with the latest security patches can be tiresome however SSM Patch manager can lighten the load and ensure that your workloads are protected from the latest vulnerabilities, and with automation these can be scheduled at a time that is best for your business.

By implementing the above you can significantly enhance the security of your AWS environment. Remember security is an ongoing process the requires continuous monitoring and improvement.

If you have any other gems you think others would benefit from drop them in the comments.

In my next blog we'll have a look at some environment enhancements that go beyond the basics to provide further security enhancements.