Skip to main content
Welcome back. This lesson provides a concise, high-level guide to securing AI/ML systems on AWS. It reinforces core security concepts from the AWS Cloud Practitioner (CLF-C02) and highlights responsibilities, identity and access, encryption, network isolation, and SageMaker-specific controls. First, understand the AWS Shared Responsibility Model: AWS secures the underlying cloud infrastructure, while you (the customer) secure anything you configure, run, or upload.
A slide titled "AWS Shared Responsibility Model – Introduction" showing two cloud icons: the left cloud has the AWS logo and is labeled "AWS: Security of the cloud," while the right cloud shows a user icon labeled "Customer: Security in the cloud."
AWS is responsible for physical infrastructure, data centers, the hypervisor/virtualization layer, and core networking. Anything you can access, log into, configure, or upload—such as EC2 instances, application code, or datasets—is your responsibility to secure.
A slide titled "Shared Responsibility Model – AWS’s Role" showing a cloud diagram with servers, a security shield, a laptop and a gear. Two callouts state that AWS protects infrastructure, data centers and hardware, and manages hardware, virtualization and networking.
On the customer side, secure configurations, access control, patching (when applicable), and data protection. For managed services (for example, Lambda or managed SageMaker components), you are not responsible for patching the underlying host OS, but you remain responsible for the code, configuration, and data you provide.
Slide titled "Shared Responsibility Model — Customer's Role" showing two dark panels: 01 with a hand-and-gear icon saying "Configure AWS services securely" and 02 with a user-and-key icon saying "Limit access, use encryption, follow best practices."

Identity and Access Management (IAM)

IAM is the foundation for controlling access to AWS resources. Use these best practices to reduce risk:
  • Manage users, groups, roles, policies, and federation with IAM.
  • Enforce Multi-Factor Authentication (MFA) for privileged and console users.
  • Apply the principle of least privilege: grant the minimum permissions required.
  • Use IAM roles and temporary credentials for applications, services, and cross-account access.
A slide titled "Multi-Factor Authentication (MFA) With IAM" showing an icon of a laptop and mobile device with a lock and password and the caption "MFA adds extra security for accounts." To the right are two checked items: "Supports physical MFA devices" and "Supports virtual MFA devices."
Apply the principle of least privilege: grant only the minimum permissions required for a user or role to perform their tasks.
IAM policies are JSON documents that define permissions (Version, Statement, Effect, Action, Resource). You don’t need to memorize every field for certification, but you should recognize common patterns.
A presentation slide titled "IAM Policies and Permissions" showing two points: "Policies define permissions for resources" and "JSON-based, enabling least privilege access."
Example IAM policy granting s3:ListBucket on the bucket and s3:GetObject/s3:PutObject on objects within the bucket:

Root account and user management

  • Avoid using the root AWS account for routine tasks—use it only for rare account-level changes (billing, root-level contact info, or closing the account).
  • Create IAM users and place them into groups with role-appropriate permissions.
  • Prefer group-based permission assignment for easier auditing and maintenance.
A slide titled "AWS Root User Security — Best Practices" showing icons of a user at a workstation, a padlock, and a laptop/phone representing access and authentication. The caption warns that the root user has unrestricted AWS account access and should only be used for essential administrative functions.
Do not use the root user for everyday tasks. Enable MFA on the root account, minimize root access, and store root credentials securely.

Roles and temporary credentials

  • IAM roles bundle permissions with a trust policy; when assumed, they provide temporary credentials that expire.
  • Use roles for EC2 instance profiles, Lambda execution roles, cross-account access, and federation with identity providers.
A diagram titled "IAM Roles and Temporary Access" with an AWS Identity and Access Management icon in the center linked to three roles labeled Dev, QA, and Admin. Each role is shown as a user-group icon with small policy and clock symbols to indicate temporary or time-limited access.

Logging and auditing

  • Enable AWS CloudTrail to record API activity across your account for auditing and incident investigation.
  • Store CloudTrail logs in a dedicated, secured S3 bucket in a separate logging or security account to prevent tampering.
  • Apply S3 public access blocking and strict bucket policies for log storage and retention.

SageMaker role separation

In ML environments, separate permissions to avoid privilege creep:
  • Create distinct roles for data scientists, MLOps engineers, and compute/service accounts.
  • Limit dataset access and model artifact permissions according to job needs.
A diagram titled "SageMaker Role Manager for ML Permissions" showing a central SageMaker Role Manager icon connected by dotted lines to three groups labeled Data Scientist, MLOps, and Compute. Each group is represented by a people icon and a small checklist/permissions icon.

Encryption

Protect data at rest and in transit using AWS encryption services:
  • AWS Key Management Service (KMS) manages cryptographic keys for server-side encryption.
  • S3 supports server-side encryption options: SSE-S3, SSE-KMS, and customer-provided keys (SSE-C).
  • For highly sensitive data, use client-side encryption so data is encrypted before upload.
  • Use TLS/SSL for data in transit and store certificates in AWS Certificate Manager (ACM) for integration with load balancers, API Gateway, and CloudFront.
A slide titled "AWS Key Management Service (KMS) for Data Encryption" showing a red AWS KMS icon connected by an arrow to a green S3 bucket icon, illustrating KMS managing encryption keys for S3.
An infographic titled "Server-Side and Client-Side Encryption" showing two panels: the server-side panel says "AWS handles encryption" with a server/lock icon, and the client-side panel says "Customers encrypt data before sending to AWS" with a user/lock icon. The slide is credited to KodeKloud.
ACM (AWS Certificate Manager)
  • Use ACM to provision and manage TLS certificates for AWS-integrated services.
  • AWS SDKs and the CLI default to HTTPS; ensure certificates are valid and renew before expiry.

Network isolation and private connectivity

Design networks to reduce exposure and keep service traffic on AWS private networks:
  • A VPC provides an isolated virtual network spanning Availability Zones (AZs). Use public subnets for internet-facing resources and private subnets for internal components.
  • Private subnets that need outbound internet access should use a NAT gateway or NAT instance. To avoid routing traffic over the internet to reach AWS public services, use VPC endpoints.
  • Gateway endpoints are available for S3 and DynamoDB; interface endpoints (AWS PrivateLink) provide private connectivity to many other AWS services.
  • Apply security groups (stateful) and network ACLs (stateless) for layer-4 access control. Consider AWS Network Firewall or third-party appliances for additional inspection.
A diagram titled "SageMaker Distributed Training – Inter-Node Encryption" showing a master node and three interconnected worker nodes (with encrypted links) performing distributed training. It also shows a data source feeding the master node and an output storage (S3 bucket) receiving results.

Inter-node encryption for distributed training

  • Enable SageMaker inter-node encryption for distributed training jobs to encrypt network traffic between training instances. This is particularly important when workers exchange sensitive features or PII.

VPCs, subnets, and internet access

  • Multi-AZ VPC designs typically include public and private subnets for high availability and separation of concerns.
  • Public subnets route through an Internet Gateway; private subnets use a NAT gateway for outbound internet access while remaining unreachable from the internet.
  • Combine security groups, NACLs, and endpoint policies to minimize exposure.
A diagram titled "Virtual Private Cloud (VPC) in AWS" showing a region containing a default VPC split into four availability zones, each with a green (private) and red (public) subnet. The public subnets show routes for 0.0.0.0/0 to an internet gateway/load-balancer icon, illustrating network isolation and internet access.

VPC endpoints

  • Use gateway endpoints for S3 and DynamoDB.
  • Use interface endpoints (PrivateLink) for other supported services to keep traffic on the AWS network and reduce exposure to the public internet.

Quick reference: Common AWS security services and use cases

Summary

This article covered essential security controls for AI systems on AWS:
  • Shared Responsibility Model — what AWS manages vs. what you must manage.
  • IAM best practices — policies, roles, MFA, and least privilege.
  • Logging and auditing — CloudTrail and secure log storage.
  • Encryption — KMS for keys, server-side vs. client-side encryption, and ACM for TLS.
  • Network isolation — VPC design, subnets, NAT, VPC endpoints, and PrivateLink.
  • SageMaker-specific considerations — role separation and inter-node encryption for distributed training.
For deeper, service-specific guidance, consult the AWS documentation and community resources: This coverage is intentionally high-level and tailored for the AWS Certified AI Practitioner context. If you want a deeper dive into any area (IAM policy examples, VPC endpoint patterns, SageMaker secure training patterns), ask for a focused follow-up.

Watch Video