How to Right-Size Your First AWS Portfolio Project (When You Come from Networking and Helpdesk)

How to Right-Size Your First AWS Portfolio Project (When You Come from Networking and Helpdesk)

A year of firewall rules and a new helpdesk role is not a weak starting point. It is the exact set of instincts that makes a cloud project real: you already think about access, change control, and what breaks at 4 a.m.

The mistake most people make before building an AWS portfolio is starting with a title instead of a scope. They try to build a full-stack app, a CI/CD platform, a data lake, and a security dashboard at once. Then they ship a half-working demo they cannot defend.

The fix is a project small enough to finish and deep enough to explain.

The scope rule: one problem, one perimeter, one signal

A portfolio project should prove two things:

1. You can use AWS to change a real infrastructure state.

2. You can explain why that change reduces risk.

You do not need a complex product. You need one visible failure mode, one automated response, and one written runbook.

For your background, the strongest theme is **cloud security operations**—not app development.

Recommended build: Open security group detector and auto-remediation

Build a tiny, simulated corporate VPC that catches a firewall mistake and fixes it like a support escalation. This maps to the AWS Well-Architected Security Pillar and the CIS AWS Foundations Benchmark controls that flag overly permissive ingress.

What to include

**A VPC with one public subnet and one private subnet.** Keep it deliberately small.

**A security group that allows SSH or RDP from `0.0.0.0/0`.** This is your failure scenario.

**AWS Config** with the `restricted-ssh` managed rule or an equivalent RDP rule to detect the opening.

**EventBridge** to react to the compliance change.

**AWS Lambda** to replace the bad rule with your office IP or a safer address, and send a ticket notification.

**Amazon SNS** to deliver an email or Slack message with the finding, action taken, and timestamp.

**AWS CloudTrail** to keep API history.

**Amazon GuardDuty** for threat findings around the same resource.

**IAM roles** with least privilege for the Lambda, Config, and EventBridge.

**A README and runbook** with architecture diagram, cost estimate, failure test, and cleanup steps.

What to skip

ECS, EKS, and serverless microservices.

A user-facing frontend.

Multi-region redundancy.

Terraform or CDK in the first pass.

Those tools are valuable, but they will expand the scope until you cannot finish. If you already know Terraform, add it only after the console version works. If you do not, leave it for the next iteration.

Four-week execution plan

| Week | Focus | Finish line |

| --- | --- | --- |

| 1 | VPC, subnets, route tables, IAM | You can SSH or RDP to a test instance through a locked-down bastion |

| 2 | AWS Config, GuardDuty, CloudTrail | The console flags the open security group rule |

| 3 | EventBridge, Lambda, SNS | The Lambda removes or updates the bad rule and sends a ticket |

| 4 | Docs and demo | You have a two-minute walkthrough and a runbook in the README |

The week-four deliverable is not more features. It is a clean demo where you open a security group, trigger the detector, and show the remediation and notification.

How to write it like an operator, not a student

Your README should answer:

What is the business risk? Open management ports to the internet.

What is the alert path? Config → EventBridge → Lambda → SNS.

What is the containment action? Restrict the source to a known IP, not just close the port.

What is the recovery? Re-run the test, verify with Config, confirm the SNS notification.

What does it cost? Include a monthly estimate and a teardown command or console cleanup.

That framing is closer to a real change ticket than a school project. It also gives you natural talking points for helpdesk-to-cloud interviews: access controls, escalation, audit logs, and risk.

Non-CS means you explain less code and more causality

You do not need to compensate for a non-CS degree by building something bigger. You compensate by being able to explain the system clearly.

If you can say:

> Config detects a security group violation. EventBridge routes that event. Lambda revokes or tightens the offending ingress rule. SNS notifies the team. CloudTrail records who changed what.

...then hiring managers for cloud support, cloud operations, and junior security roles will listen. That is the actual outcome of the project.

Build the proof, not the ambition

Your networking and helpdesk background already gives you a better mental model than many new builders: every cloud resource is just another endpoint, permission, and ticket waiting to happen.

So keep the AWS project narrow. Make it detect one bad security group, remediate one risk, notify one queue, and document one runbook.

Finish that. Then expand.