← Return to Guides

AWS Security Guide

Protecting Your Side of the Shared Responsibility Model

AWS gives you strong foundations: hardened data centres, resilient hardware, managed services, and a deep catalogue of security tooling. That’s their side of the shared responsibility model. The cloud is secure by design.

What AWS cannot own – and what lands squarely on your desk – is what sits in that cloud: Identities and roles. S3 buckets and data lakes. Databases integrated with SaaS apps and legacy systems are still necessary for daily functionalities. Above all, the sensitive data that powers billing, care, and customer trust.

This is where AWS Security Best Practices shift from a checklist to your judgment. You know where standard IAM, KMS, and GuardDuty coverage ends. You also know you’ll be the one answering when an overexposed bucket, a mis-scoped role, or a “temporary” export turns into real impact.

DataStealth is built for that gap. It does not replace AWS controls; instead, it helps you secure your side of the model by discovering, classifying, and protecting data across AWS, SaaS, and on-premises environments  – hence, even if someone breaches your perimeter, what they find is tokenized and rendered useless.

AWS Security Best Practices Checklist

1. Discover and Classify Data

Every AWS Security Best Practices checklist from cybersecurity vendors or AWS itself lands on the same point: you cannot protect what you cannot see.

AWS offers tools such as Amazon Macie to discover and classify sensitive data in S3, but real estates are broader than a single service. Data flows through:

  • S3, RDS, DynamoDB, Redshift, and logs in CloudWatch
  • SaaS tools connected via APIs
  • On-prem databases and file stores still in daily use

DataStealth’s Data Discovery fills this gap by scanning across your entire environment – on-premise, AWS, and third-party SaaS – to build a living inventory of sensitive data across known and  unknown sources, including shadow IT and unsanctioned repositories.

Deployment is pragmatic. You can begin with a simple DNS change, then run discovery via repeated scans, or scheduled jobs during off-hours.

For AWS security, this turns a vague mandate (“classify your data”) into concrete tasks:

  • Map which S3 buckets, RDS instances, and Redshift tables actually store regulated data
  • Identify dark data that never shows up in spreadsheets
  • Align AWS security best practices with dark data and shadow data analysis, not just asset lists

This is the first step in hardening your security posture: grounding cloud security in a complete picture of where sensitive information really lives.

2. Protect Data, Not Just Perimeters

Most AWS security documents emphasize encrypting data at rest and in transit using TLS and AWS Key Management Service KMS.

That is the right baseline. However, encrypting a disk or bucket is still container-level protection. If an attacker or over-privileged user reaches an application or query layer, they often see real data.

DataStealth shifts AWS Security Best Practices toward field-level protection:

  • Tokenization – Replace sensitive values with non-sensitive stand-ins that preserve format, so applications continue to work.

  • Encryption and format-preserving encryption (FPE) – Apply strong cryptography down to the field, without forcing schema changes.

  • Masking – Dynamically hide or partially reveal values based on role and purpose.

These controls are part of DataStealth’s core security architecture, which combines encryption, tokenization, and masking so that no system holds readily usable data.

DataStealth operates at the network layer.

  • Inline gateways or reverse proxies sit in front of HTTP, REST, gRPC, and GraphQL APIs. They protect web applications and microservices before requests hit your code.

  • Database and data-store proxies apply field-level policies for SQL and JSON traffic to RDS, Aurora, DynamoDB, Redshift, and other managed services.

  • Batch and streaming workers protect data in lakes and file storage (e.g., S3) and secure messaging platforms like Kafka and Kinesis, keeping fields safe in transit and at rest.

In AWS terms, you still follow AWS guidance around securing VPCs, IAM, and GuardDuty. But DataStealth adds a data security layer that ensures even successful attacks cannot easily convert access into readable records.

3. Strong KMS and Key Control

AWS is very clear on keys: use AWS Key Management Service (KMS), avoid hard-coded secrets, and implement regular reviews and rotation policies.

DataStealth is built to align with this pattern, not compete with it. Its key management layer integrates directly with AWS KMS, Azure Key Vault, GCP KMS, and on-prem HSMs.

This allows you to apply AWS Security Best Practices while gaining:

  • BYOK and HYOK – Bring or hold your own keys, with rotation and revocation controlled by your team.

  • Per-tenant and per-dataset keys – Limit blast radius and meet data residency requirements by isolating keys for specific regions or business units.

  • Dual control and audit – Separate duties for key management and operations, with full logs of key usage.

In practice, it looks like this:

  1. Manage master keys in AWS KMS.
  2. Use DataStealth to perform field-level tokenization and encryption using those keys.
  3. Keep key material under your control while DataStealth protects data across all your cloud environments.

The result is coherent cloud security: AWS provides hardened key infrastructure; DataStealth orchestrates how those keys are applied to real data.

4. Least Privilege and Access Control

In terms of identity and access management (IAM), AWS documentation stresses least privilege, avoiding the root account, and enforcing multi-factor authentication (MFA) for high-value roles.

That covers who can reach a resource. It does not fully answer what they should see once they are inside.

DataStealth extends IAM from infrastructure to the data layer:

  • Fine-grained, role- and attribute-based policies govern who can view cleartext or perform detokenization.

  • Dynamic masking ensures that dashboards, web applications, and internal tools only reveal what each user needs to perform their job effectively.

The pattern looks like this:

  • IAM and SSO decide which engineer can access an S3 bucket or RDS instance.

  • DataStealth policies decide whether that engineer sees a full card number, a partially masked email, or just a token.

You grant users only the permissions they need at the resource level, then apply DataStealth’s data-level access control to narrow what sensitive fields can be reconstructed. 

That combination sharply reduces security risks from insider abuse, compromised credentials, or misconfigured IAM policies.

5. Reducing Compliance Scope, Not Just Passing Audits

Many approaches connect AWS security to frameworks like CIS Benchmarks, the AWS Foundational Security Best Practices standard, and the CSA Cloud Controls Matrix. 

But compliance isn’t just about passing a configuration scan; it’s about shrinking the amount of data that actually sits in scope.

DataStealth’s platform is designed for regulated environments. It emphasizes:

  • Meeting data residency, sovereignty, and retention requirements. 
  • End-to-end auditing of access, policy changes, and data recomposition events. 
  • Policy-as-code for consistent enforcement across accounts and environments. 

For PCI, tokenizing cardholder data before it touches AWS workloads can substantially reduce the audit scope of your AWS accounts, because systems work with tokens instead of PANs. 

For privacy laws such as HIPAA and GDPR, controlling detokenization and masking at the data layer allows auditors to see exactly how sensitive data is handled, not just where it resides. 

This allows for a powerful combination:

  • AWS: hardened infrastructure, logging, and managed services with strong certifications.

  • DataStealth: evidence that data security controls operate consistently across AWS, other clouds, and on-prem systems.

This combination makes AWS security easier to sustain, not just achieve once. 

6. Hybrid and Multi-Cloud Environments

Most enterprise AWS accounts live in hybrid and multi-cloud environments with estates that span AWS, Azure, GCP, and on-prem.

AWS provides the plumbing – Transit Gateway, Direct Connect, Outposts – but security cannot end at the account boundary. Cloud-native applications share data with systems that will never move off-premises.

​​DataStealth was built for this reality as it:

  • Works across hybrid and multi-cloud environments, preserving data formats to ensure existing applications and validations continue to function.
     
  • Deploys in your own AWS accounts using VMs, containers, or Kubernetes, with components placed in the same VPC and region as your workloads for low-latency protection.

  • Supports hybrid models where on-prem clusters and cloud clusters enforce consistent policies but maintain local processing for performance and residency.

Messaging platforms, data lakes, and logs are treated as first-class citizens: Kafka, Kinesis, S3, and file shares are all protected in-line or via workers, so sensitive fields remain safe as they move between cloud environments.

Cloud security measures for hybrid estates are no longer a patchwork of point tools. Rather, AWS handles the infrastructure, and DataStealth can provide consistent security on-prem and in the cloud,  data security controls wherever the data actually resides.

Download the Full Guide

Submit the form to access the the full article.