AWS Cloud Security

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. Do not use it for day-to-day operations, only for tasks that require root user credentials: for example changing the root user email or password of a standalone account, closing the account, or restoring permissions when the only IAM administrator accidentally revokes their own access. Since June 2025, AWS requires MFA for root users across all account types, including member accounts in AWS Organizations. In Organizations you can centrally remove root credentials from member accounts.

Best Practice: An Administrator in IAM Identity Center

Immediately after creating an AWS account, set up an administrative user in AWS IAM Identity Center and stop using the root user. AWS recommends that people access AWS through federation with temporary credentials, not through IAM users with long-term keys.

Users, Groups & Policies

# Example IAM Policy - start/stop EC2 instances tagged Owner = user name
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Owner": "${aws:username}"
                }
            }
        },
        {
            "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. The example above follows the official AWS sample and uses the aws:ResourceTag/Owner condition.

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, for example through OIDC and AssumeRoleWithWebIdentity in GitLab CI/CD.

# 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:
    - >
      aws_sts_output=$(aws sts assume-role-with-web-identity
      --role-arn arn:aws:iam::123456789012:role/GitLabCIRole
      --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
      --web-identity-token "${GITLAB_OIDC_TOKEN}"
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text)
    - export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s" $aws_sts_output)
    - aws sts get-caller-identity

AWS Security Layers

Defense in Depth Approach

1. Account Security

Securing the AWS account

MFA for all users (AWS requires it for the root user)
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 (AWS Organizations)

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

Amazon GuardDuty

Threat detection from CloudTrail, VPC Flow Logs and DNS logs using threat intelligence and ML models.

Anomaly detection
Threat intelligence
Automatic findings
Integration with AWS Security Hub and Security Hub CSPM

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 = "*"
      }
    ]
  })
}

# Session Manager instead of SSH - the instance needs SSM permissions
resource "aws_iam_role_policy_attachment" "ssm_core" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# 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
Long-term access keys only where a role cannot be used; update them when needed based on last used information

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 (new buckets do not allow public access by default; keep Block Public Access on)

Sources

AWS IAM User Guide: Security best practices in IAM (October 2026)
AWS IAM User Guide: AWS account root user (October 2026)
AWS What's New: AWS IAM now enforces MFA for root users across all account types (June 2025)
AWS IAM User Guide: Amazon EC2: Allows starting or stopping EC2 instances a user has tagged (October 2026)
GitLab Docs: Configure OpenID Connect in AWS to retrieve temporary credentials (October 2026)
AWS Systems Manager User Guide: Configure instance permissions required for Systems Manager (October 2026)
Amazon GuardDuty User Guide: What is Amazon GuardDuty? (October 2026)
AWS What's New: AWS Security Hub is now generally available with near real-time risk analytics (December 2025)
Amazon S3 User Guide: Blocking public access to your Amazon S3 storage (October 2026)

What is AWS Cloud Security?

Why is AWS Security Critical?

Security Risks from Misconfiguration

AWS IAM - Identity and Access Management

Root User vs Admin User

Best Practice: An Administrator in IAM Identity Center

Users, Groups & Policies

IAM Roles for CI/CD Pipelines

AWS Security Layers

Defense in Depth Approach

1. Account Security

2. Identity & Access Management

3. Network Security

4. Data Protection

5. Monitoring & Audit

AWS Security Services

AWS IAM

AWS Secrets Manager

AWS CloudTrail

Amazon GuardDuty

Practical Example: Secure EC2 Deployment

AWS Security Best Practices - Summary

Account & Identity

Access Management

Network & Data

What NOT to Do

Sources

Want this handled without building your own DevOps team?

What is AWS Cloud Security?

Why is AWS Security Critical?

Security Risks from Misconfiguration

AWS IAM - Identity and Access Management

Root User vs Admin User

Best Practice: An Administrator in IAM Identity Center

Users, Groups & Policies

IAM Roles for CI/CD Pipelines

AWS Security Layers

Defense in Depth Approach

1. Account Security

2. Identity & Access Management

3. Network Security

4. Data Protection

5. Monitoring & Audit

AWS Security Services

AWS IAM

AWS Secrets Manager

AWS CloudTrail

Amazon GuardDuty

Practical Example: Secure EC2 Deployment

AWS Security Best Practices - Summary

Account & Identity

Access Management

Network & Data

What NOT to Do

Sources

More on this topic

Cloud Outages 2025–2026: What the Post-Mortems Mean for Your Architecture

FinOps in 2026: Where Companies Overpay in the Cloud and How to Measure It in One Week

Digital sovereignty: what the “sovereign” clouds of AWS, Microsoft and Google actually offer

Want this handled without building your own DevOps team?

We use cookies