Cloud adoption in Kenya has accelerated dramatically over the past three years. AWS remains the dominant platform, and we now assess dozens of AWS environments annually across industries including fintech, e-commerce, healthcare, and logistics. What we find, consistently, are the same misconfigurations recurring across organisations of all sizes.
These aren't obscure edge cases — they're common, fixable, and in many cases being actively exploited in the wild. Here are the top 10 we encounter, and what to do about each one.
1. Publicly Accessible S3 Buckets
Despite years of high-profile breaches, we still find publicly accessible S3 buckets in nearly 40% of assessments. Often, a developer enabled public access for testing and never reverted it. The fix: enable "Block Public Access" at the account level and audit bucket policies and ACLs regularly using AWS Config rules.
2. Overly Permissive IAM Policies
The "AdministratorAccess" policy is attached to far more entities than it should be. We frequently find Lambda functions, EC2 instances, and even application service accounts with full admin rights "because it was easier." Every IAM entity should follow least-privilege; grant only the specific permissions needed, nothing more. Use IAM Access Analyzer and policy simulation tools to identify excessive permissions.
3. No MFA on Root Account
The AWS root account is the most powerful account in your AWS environment. It should have MFA enabled, should never be used for day-to-day operations, and its access keys should not exist. Yet we regularly find root accounts with no MFA and active access keys. Fix this immediately.
4. Security Groups with 0.0.0.0/0 Ingress
Opening all inbound traffic to a resource (0.0.0.0/0) on sensitive ports like SSH (22), RDP (3389), or database ports (3306, 5432) is an open invitation to attackers. Every security group rule should specify the minimum necessary source IP ranges, and management ports should only be accessible via a VPN or bastion host.
5. Unencrypted RDS Databases
RDS encryption at rest is a checkbox during setup, but we frequently find production databases without it enabled. This is particularly concerning in regulated industries. Note that you cannot enable encryption on an existing unencrypted RDS instance — you need to create a snapshot, copy it with encryption enabled, and restore from the encrypted snapshot.
aws rds describe-db-instances --query 'DBInstances[?StorageEncrypted==\`false\`].[DBInstanceIdentifier,DBInstanceClass]'6. CloudTrail Disabled or Incomplete
CloudTrail is AWS's audit log service. Without it, you have no visibility into who did what in your AWS environment. We find it disabled or only partially configured in roughly 25% of assessments. Enable CloudTrail in all regions, enable log file validation, and ship logs to a separate security account or protected S3 bucket that cannot be deleted by the same account that's being audited.
7. No Resource Tagging Strategy
This isn't a direct security vulnerability, but it creates significant security debt. Without consistent tagging, organisations lose track of what resources exist, who owns them, and whether they're still needed. Orphaned resources — forgotten EC2 instances, old load balancers — are common attack surfaces.
8. Lambda Functions with Excessive Permissions
Serverless functions are among the most over-permissioned resources we assess. Each Lambda function should have its own IAM role with the minimum permissions needed. A function that reads from DynamoDB should not also have access to S3, RDS, and EC2.
9. No VPC Flow Logs
VPC Flow Logs give you visibility into network traffic within your AWS environment. Without them, you cannot detect lateral movement, data exfiltration, or unexpected network connections. Enable Flow Logs for all VPCs and ship them to CloudWatch Logs or S3.
10. Hardcoded Credentials in Code
We find AWS access keys, database passwords, and API secrets hardcoded in application code — sometimes committed to public GitHub repositories. The fix is to use AWS Secrets Manager or Parameter Store for all secrets, and to implement pre-commit hooks that scan for credential patterns before code is committed.