CLOUD & INFRASTRUCTURE

AWS Cloud Security

Comprehensive AWS cloud infrastructure security - from IAM and access management through network security to audit and compliance.

What is AWS Cloud Security?

AWS Cloud Security encompasses all practices, tools, and processes for securing your cloud infrastructure on Amazon Web Services. Key areas include access management (IAM), network security (VPC, security groups), data protection, and monitoring. A properly configured AWS infrastructure is the foundation for secure operation of your applications in the cloud.

Why is AWS Security Critical?

When we create servers for application deployment, we introduce a whole range of security layers that must be protected. Just as we secure application code, third-party code, and container images, we must also secure the environment beneath the container - the server and the entire infrastructure network.

  • Access Management: Who has access to which services, which users and what permissions on AWS
  • Network Security: VPC configuration, security groups, NACLs, and firewall rules
  • Data Protection: Encryption of data at rest and in transit, key management
  • Audit & Compliance: Activity tracking, logging, and regulatory compliance
  • Credential Management: Managing access keys, rotation, and secure storage

Security Risks from Misconfiguration

  • Stolen credentials: Hardcoded access keys in pipelines or application code
  • Excessive permissions: Users with admin access they do not need
  • Unrevoked permissions: Former employees with active accounts
  • Open ports: Publicly accessible SSH or database ports
  • Missing MFA: Accounts without multi-factor authentication

AWS IAM - Identity and Access Management

AWS IAM is the service for managing access to your AWS account. It allows you to create users, groups, and roles with precise permissions.

Root User vs Admin User

The root user is created automatically when an AWS account is set up and has permissions to do absolutely anything. It should not be used for day-to-day operations - only for special administrative tasks such as changing billing information or closing the account.

Best Practice: Creating an Admin User

Immediately after creating an AWS account, create an admin user and stop using the root user. The admin user will manage the rest of the account and create additional users.

Users, Groups & Policies

# Example IAM Policy - allow start/stop of EC2 instances { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:Owner": "specific-user" } } }, { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" } ] }

Policies are highly granular - you can decide on read-only, write, or delete access to each specific resource. You can also restrict access with additional conditions, for example limiting access to a specific region only.

IAM Roles for CI/CD Pipelines

For automated processes like CI/CD pipelines, do not use static access keys. Instead, use IAM Roles with short-lived tokens.

# GitLab CI/CD - using OIDC instead of static keys variables: AWS_REGION: eu-central-1 assume_role: id_tokens: GITLAB_OIDC_TOKEN: aud: https://gitlab.com script: - > export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $(aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789:role/GitLabCIRole --role-session-name "GitLabRunner-${CI_JOB_ID}" --web-identity-token "${GITLAB_OIDC_TOKEN}" --duration-seconds 3600 --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' --output text))

AWS Security Layers

Defense in Depth Approach

1. Account Security

Securing the AWS account

  • MFA for all users (mandatory for root and admin)
  • Strong password policy
  • Credential reports for auditing
  • AWS Organizations for multi-account setup

2. Identity & Access Management

Managing identities and access

  • Least privilege access - only the permissions needed
  • IAM Roles instead of long-lived credentials
  • Service-linked roles for AWS services
  • Resource-based policies

3. Network Security

Securing the network

  • VPC isolation - private and public subnets
  • Security Groups (stateful firewall)
  • Network ACLs (stateless firewall)
  • VPC Flow Logs for monitoring

4. Data Protection

Protecting data

  • Encryption at rest (KMS, S3 encryption)
  • Encryption in transit (TLS/SSL)
  • AWS Secrets Manager for credentials
  • S3 bucket policies

5. Monitoring & Audit

Activity tracking and auditing

  • CloudTrail for API logging
  • CloudWatch for metrics and alarms
  • AWS Config for compliance
  • GuardDuty for threat detection

AWS Security Services

Identity

AWS IAM

Central service for managing users, groups, roles, and policies.

  • Users, Groups, Roles
  • Policies and Permissions
  • Identity Federation
  • Service Control Policies
Secrets

AWS Secrets Manager

Secure storage and rotation of credentials and API keys.

  • Automatic secrets rotation
  • RDS integration
  • Access auditing
  • Cross-account sharing
Monitoring

AWS CloudTrail

Logging of all API calls within an AWS account.

  • Management events
  • Data events
  • Multi-region trails
  • Log file integrity
Threat Detection

AWS GuardDuty

Intelligent threat detection using ML.

  • Anomaly detection
  • Threat intelligence
  • Automatic findings
  • Integration with Security Hub

Practical Example: Secure EC2 Deployment

# Terraform - Secure EC2 Instance with IAM Role # IAM Role for EC2 instance resource "aws_iam_role" "ec2_role" { name = "ec2-app-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "ec2.amazonaws.com" } } ] }) } # Policy - only necessary permissions resource "aws_iam_role_policy" "ecr_policy" { name = "ecr-pull-policy" role = aws_iam_role.ec2_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = [ "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:BatchCheckLayerAvailability" ] Resource = "arn:aws:ecr:*:*:repository/myapp" }, { Effect = "Allow" Action = "ecr:GetAuthorizationToken" Resource = "*" } ] }) } # Instance Profile resource "aws_iam_instance_profile" "ec2_profile" { name = "ec2-app-profile" role = aws_iam_role.ec2_role.name } # Security Group - minimal open ports resource "aws_security_group" "app_sg" { name = "app-security-group" description = "Security group for application" vpc_id = aws_vpc.main.id # HTTPS only ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } # Outbound - only what is needed egress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } # NO SSH from internet! # Use AWS Systems Manager Session Manager } # EC2 Instance resource "aws_instance" "app_server" { ami = data.aws_ami.amazon_linux.id instance_type = "t3.micro" iam_instance_profile = aws_iam_instance_profile.ec2_profile.name vpc_security_group_ids = [aws_security_group.app_sg.id] subnet_id = aws_subnet.private.id metadata_options { http_endpoint = "enabled" http_tokens = "required" # IMDSv2 required } root_block_device { encrypted = true } tags = { Name = "app-server" } }

AWS Security Best Practices - Summary

Account & Identity

  • Never use the root user for routine operations
  • MFA for all users
  • Strong password policy
  • Regular permission reviews
  • Remove unused accounts

Access Management

  • Least privilege - only the permissions needed
  • Use Roles instead of long-lived credentials
  • OIDC/Federation for CI/CD pipelines
  • Resource-based policies where possible
  • Regular access key rotation

Network & Data

  • Private subnets for application servers
  • Security Groups with minimal rules
  • No SSH from the internet - use Session Manager
  • Encryption at rest and in transit
  • VPC Flow Logs for auditing

What NOT to Do

  • Hardcoded credentials in code or pipelines
  • Sharing access keys between users
  • Open port 22 (SSH) from the internet
  • Wildcard (*) permissions in production
  • Disabling CloudTrail logging
  • Public S3 buckets without good reason