AWS Security Best Practices Checklist for Indian Businesses

IAM: The Foundation of AWS Security

Almost every public AWS breach in 2024 and 2025 came back to IAM. Over-privileged roles, leaked access keys, shared accounts, and missing MFA are the recurring patterns. The first 30 days of an AWS security programme should focus almost entirely on IAM, because every other control is undermined if identity is loose.

Baseline IAM hygiene starts with the root account. Set a 24+ character password, enable a hardware MFA device, store the recovery contacts in a vault accessible to two named people, and never use the root account for daily operations. Programmatic root access keys should be deleted entirely; CloudTrail will tell you if the root account is ever used after lockdown.

Human Access via IAM Identity Center

Long-lived IAM users for human operators are a 2019 pattern that should not exist in 2026. AWS IAM Identity Center (the new name for AWS SSO) federates from your identity provider (Microsoft Entra ID, Okta, Google Workspace, JumpCloud, or AWS-native) and issues short-lived credentials. Permissions are assigned by permission set per account, so the same engineer can have different access in prod versus dev. Onboarding and offboarding happens in the IdP, which means a leaver loses access the moment HR completes the offboarding workflow.

Service and CI/CD Access

Workloads use IAM Roles, never IAM users with access keys. EC2 uses instance profiles (with IMDSv2 enforced, see the next section). Lambda, ECS and EKS pods inherit roles through their execution context. CI/CD systems (GitHub Actions, GitLab, Bitbucket, Buildkite) use OIDC federation rather than long-lived access keys, and target a single deploy role per environment with narrow permissions. Where access keys are unavoidable (third-party SaaS that has no other option), rotate every 60 days, store in AWS Secrets Manager, and audit usage monthly.

S3: The Most Common Data Exposure Source

Public S3 buckets remain a leading cause of cloud data exposure. AWS Block Public Access (BPA) at the account level (since 2018) and at the bucket level (since 2019) makes accidental public-read configurations harder, but they still happen when an engineer disables BPA temporarily and forgets to re-enable it. The checklist applies BPA at the account level for every account and treats public buckets as exceptions that require named approval.

Beyond public access: enforce server-side encryption (SSE-S3 minimum, SSE-KMS for regulated data) as the default bucket setting, enable S3 versioning on buckets holding data that matters, configure lifecycle rules to transition cold data to S3 Glacier and to expire incomplete multipart uploads (a real cost line item), and turn on S3 Access Logging or S3 Server Access Logs to a central log bucket. S3 Access Analyzer adds external-access detection on top.

VPC, Security Groups and Network Controls

Security Groups are stateful and apply at the instance level. They should be tight and purposeful. The recurring finding is 0.0.0.0/0 ingress on port 22, 3389, 1433, 3306, 27017 or 9200. Every one of these is an SSH, RDP, database or search engine open to the internet. The fix is invariably one of: Systems Manager Session Manager for SSH and RDP (removes the need for any inbound port), VPN or PrivateLink for database access, or a tightly scoped Bastion with MFA.

Network ACLs (NACLs) are stateless and apply at the subnet level. Use them as a coarse second layer (block ranges you never want to reach a subnet) rather than as the primary control. VPC Flow Logs to S3 or CloudWatch Logs are required for any incident response or forensics. Without them, the SOC is blind to lateral movement and exfiltration.

EC2 IMDSv2 Enforcement

The EC2 Instance Metadata Service v1 is the path SSRF attackers take to steal temporary IAM credentials. IMDSv2 (session-token based, since 2019) blocks the typical SSRF pattern. Enforce IMDSv2-only on every EC2 launch template and every existing instance. AWS Config has a managed rule (ec2-imdsv2-check) that surfaces non-compliant instances; remediate them on a schedule.

Logging: CloudTrail, VPC Flow, S3 Access, Central Account

CloudTrail logs every AWS API call. Configure organisation-wide, multi-region trails, log file validation enabled, encrypted with KMS, delivered to a dedicated central log archive account with restrictive cross-account access. Without this, post-incident forensics is impossible and SOC 2 / ISO 27001 audits cannot complete.

VPC Flow Logs capture network metadata. Enable on every VPC, route to the central account. S3 server access logs or S3 access logs go to a dedicated logging bucket. CloudWatch Logs (and the unified CloudWatch agent on EC2) collect application logs. Together, these feed AWS Security Hub or a third-party SIEM (Splunk, Sentinel, Elastic, Sumo Logic, Cribl) for detection.

Detection: GuardDuty, Security Hub, Config, Inspector

GuardDuty is AWS-native threat detection. Enable across the organisation, ingest into Security Hub for centralised findings management. Typical detections include anomalous IAM API patterns, exposed credentials used from unfamiliar geographies, EC2 instances communicating with known C2 infrastructure, and S3 object exfiltration patterns.

Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, AWS Config conformance packs and (importantly) third-party security tools that publish to ASFF (AWS Security Finding Format). Security Hub Standards include CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices; both are worth running.

AWS Config tracks configuration changes and runs Config Rules continuously against desired state. The Config Conformance Pack mechanism deploys a curated bundle of rules in one action. Inspector v2 covers EC2, ECR container images and Lambda for vulnerability findings; integrate into the patch programme. Amazon Macie classifies sensitive data in S3 (PII, financial, healthcare patterns).

Encryption: KMS Keys, Default Encryption, Customer Keys

AWS makes default encryption easy for new resources. EBS volumes: enable default encryption in every region. RDS: enable encryption at instance creation (cannot be changed in place). S3: default bucket encryption SSE-S3 minimum, SSE-KMS for regulated workloads. CloudWatch Logs and SNS topics: KMS encryption available.

For regulated data (banking, healthcare, payment card scope), use Customer Managed Keys (CMK) with automatic key rotation and explicit key policy restricting use. AWS-managed keys are simpler but offer less audit and access control. KMS key policies should follow least privilege: a key used to encrypt RDS snapshots should be usable only by the RDS service principal and the named operations role.

Compliance and Cost Considerations for Indian SMBs

Indian customers commonly need their AWS posture to support several compliance positions at once: ISO/IEC 27001:2022 Annex A, SOC 2 Trust Services Criteria, DPDP Act 2023 Section 8 reasonable security safeguards, and for regulated entities the RBI cloud computing guidance, the SEBI cyber resilience framework, IRDAI guidance for insurers, or NCIIPC requirements for critical infrastructure. Most of the checklist above doubles as evidence for these frameworks if logged and documented.

Cost is real. GuardDuty across an organisation, full multi-region CloudTrail, VPC Flow Logs at high data volume, Security Hub and Inspector all add line items. For small estates, expect roughly 1 to 2 percent of cloud spend on security tooling at this baseline. For regulated workloads (banking, healthcare) the spend reaches 3 to 5 percent and is non-negotiable. The cost of one breach exceeds five years of this overhead easily.