100 Days of DevOps and Cloud (AWS), Day 16: A Load Balancer in Ten Lines of Nginx, and Least-Privilege IAM

You do not need a cloud load balancer to load balance. Ten lines of Nginx will spread traffic across a pool of servers, and understanding those ten lines teaches you what the managed services are quietly doing for you. Day 16 was that, plus setting up IAM the way it is meant to be done, with least privilege instead of a blank check. One Linux task, one AWS task. Turn Nginx into a load balancer in front of three app servers, then create an IAM user, group, and read-only policy. The tasks come from the KodeKloud Engineer platform. Nginx load balancer: an upstream block and a proxy_pass On the load balancer host, install Nginx and get it running: yum install -y nginx systemctl enable nginx systemctl start nginx Enter fullscreen mode Exit fullscreen mode On each app server: confirm the port Apache is running on sudo ss -tulp | grep httpd Alternative: systemctl status httpd Then the config that turns it into a load balancer: Enter fullscreen mode Exit fullscreen mode bash On the load balancer: edit the Nginx config to set up upstream load balancing vi /etc/nginx/nginx.conf Enter fullscreen mode Exit fullscreen mode nginx Define the pool of backend servers upstream app_servers { server stapp01:5000; server stapp02:5000; server stapp03:5000; } server { listen 80; location / { proxy_pass http://app_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } The `upstream` block names a group of backend servers. The `proxy_pass` points incoming requests at that group. That is the load balancer. By default Nginx spreads requests across the pool in round-robin order, one server after another in turn, and if you want a different strategy like least-connections or IP hash, it is a single extra directive. The `proxy_set_header` lines matter more than they look. Without them, every backend sees the request as coming from the load balancer itself, so these pass along the client's real IP and protocol, which is what keeps your backend logs and any IP-based logic honest. Enter fullscreen mode Exit fullscreen mode bash nginx -t # test the config systemctl reload nginx # apply it without dropping connections curl http://stlb01:80 Same discipline as Day 15, test, then reload. Reload rather than restart here, so the new config applies without cutting live connections. ## IAM: grant exactly what is needed, nothing more The AWS task was IAM done the right way, a user, a group, and a policy that grants only what is needed: Enter fullscreen mode Exit fullscreen mode bash aws iam create-user --user-name Bob aws iam create-group --group-name Admins Then the policy document: Enter fullscreen mode Exit fullscreen mode json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeTags", "ec2:DescribeSnapshots" ], "Resource": "*" }] } Enter fullscreen mode Exit fullscreen mode bash aws iam create-policy \ --policy-name ec2-readonly-policy \ --policy-document file://policy.json aws iam list-policies --scope Local This is least privilege in practice. The policy allows four specific read-only actions, the `Describe` calls, and nothing else. The lazy version would be `"Action": "ec2:*"`, which hands over full control of EC2 for what is supposed to be read-only access. Do not do that. Grant the exact actions the role needs and widen only when a real need shows up. The `"Resource": "*"` looks broad, but most EC2 Describe actions do not support resource-level restrictions, so it is expected here, the actions are already the tight part. One small syntax trap. The `--policy-document` value is `file://policy.json`, with the double slash. Miss it, and the CLI treats your filename as a literal policy string and fails. The task stopped at creating these pieces. To actually put them to work, you take two more steps, attach the policy to the group with `attach-group-policy`, and add the user to the group with `add-user-to-group`, so Bob inherits the read-only access through the group. Managing permissions at the group level instead of per user is the habit that keeps IAM sane as a team grows. ## Where this leaves us Both tasks were about doing the fundamental version properly. A load balancer you build yourself teaches you what the managed one abstracts away. An IAM policy scoped to four actions teaches you the security posture that `ec2:*` quietly throws away. This whole first stretch of the challenge has been exactly that, the boring, correct version of each skill, because that is the version that holds up when it counts. So here is the Day 16 question. Would you rather reach for the broad, convenient option and hope it never bites you, or build the tight version now while the stakes are still just a lab? Day 16 down. Eighty-four to go. Enter fullscreen mode Exit fullscreen mode