Cloud Security Essentials for Engineers

Cloud security is more about managing distributed trust than securing a perimeter.

Let’s imagine we’re setting up a new application on AWS, and we want to make sure it’s secure from the get-go. We’ll use a small, but illustrative, setup: an EC2 instance (our "server") running a web application, and an S3 bucket (our "data store") for user uploads.

First, let’s get our EC2 instance up and running.

aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type t3.micro \
    --subnet-id subnet-0123456789abcdef0 \
    --security-group-ids sg-0123456789abcdef0 \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=SecureWebAppServer}]'

This command launches a basic EC2 instance. The critical security pieces here are --security-group-ids. This security group (sg-0123456789abcdef0) acts as a virtual firewall. We’ll define rules within it. For our web app, we’ll allow inbound HTTP traffic (port 80) and HTTPS traffic (port 443) from anywhere, but only for the web server itself:

{
    "SecurityGroups": [
        {
            "Description": "Allow HTTP and HTTPS traffic",
            "GroupName": "SecureWebAppServerSG",
            "IpPermissions": [
                {
                    "IpProtocol": "tcp",
                    "FromPort": 80,
                    "ToPort": 80,
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0",
                            "Description": "Allow inbound HTTP"
                        }
                    ]
                },
                {
                    "IpProtocol": "tcp",
                    "FromPort": 443,
                    "ToPort": 443,
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0",
                            "Description": "Allow inbound HTTPS"
                        }
                    ]
                }
            ],
            "OwnerId": "123456789012",
            "GroupId": "sg-0123456789abcdef0"
        }
    ]
}

Crucially, we won’t open SSH (port 22) to the world. Instead, we’ll use a bastion host or AWS Systems Manager Session Manager. For this example, let’s assume Session Manager, which means we don’t need any inbound SSH rules at all.

Now, our S3 bucket for user uploads.

aws s3api create-bucket \
    --bucket secure-user-uploads-app-12345 \
    --region us-east-1 \
    --create-bucket-configuration LocationConstraint=us-east-1

By default, S3 buckets are private. We need to grant our EC2 instance permission to write to it. This is where IAM roles come in. We create an IAM role that our EC2 instance can assume.

{
    "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": "ec2.amazonaws.com"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    },
    "RoleName": "WebAppEC2S3AccessRole"
}

Then, we attach a policy to this role that grants specific S3 write permissions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::secure-user-uploads-app-12345",
                "arn:aws:s3:::secure-user-uploads-app-12345/*"
            ]
        }
    ]
}

Finally, we associate this IAM role with our EC2 instance when we launch it (or by modifying it later):

aws ec2 associate-iam-instance-profile \
    --instance-id i-0123456789abcdef0 \
    --iam-instance-profile Name=WebAppEC2S3AccessRole

The application on the EC2 instance, using the AWS SDK, will automatically pick up these credentials and be able to interact with the S3 bucket without needing hardcoded keys.

The fundamental problem cloud security solves is the shift from a physical, well-defined boundary to a logical, fluid one. Instead of locking a server room, you’re managing access policies, identity, and data encryption across a network of distributed services. Every service, every API call, every data object is a potential point of interaction that needs explicit authorization.

Encryption is another cornerstone. For our S3 bucket, we’ll enforce server-side encryption.

{
    "Rules": [
        {
            "ApplyServerSideEncryptionByDefault": {
                "SSEAlgorithm": "AES256"
            }
        }
    ]
}

This policy, applied to the bucket, ensures all objects uploaded are encrypted at rest using AES-256.

The most surprising thing about cloud security is how much of it relies on denial rather than allowance. Most misconfigurations stem from overly permissive IAM policies or security group rules, where the default is to allow "everything" and the administrator forgets to restrict it. Instead, the secure approach is to default to denying all access and only explicitly grant the minimal permissions required for a given task.

The next concept you’ll grapple with is how to manage secrets like API keys or database credentials securely, which leads into services like AWS Secrets Manager or HashiCorp Vault.