Planning My First AWS Security Lab: Start Small and Make It Explainable

A cloud security lab can get complicated before the first experiment even starts. There are dashboards to choose, services to compare, and diagrams that make a small project look unfinished. For my first AWS security lab, I want a simpler starting point: one system, one question, and enough evidence to explain the result.

This is my plan for the build. I have not completed or benchmarked this setup yet. The aim is to make the first version small enough to understand before adding more tools.

My first question is straightforward: can I trace a failed login attempt from the connection to the server’s authentication log?

That gives the project a clear boundary. I would use one Linux instance on Amazon EC2 and make a small number of manual login attempts against my own machine. I would record the time of each attempt, check the relevant authentication logs, and compare the entries with what I did. The log location depends on the Linux distribution, so checking that comes before writing any detection rule.

A dashboard can wait. If I cannot explain the original log entry, collecting it in another tool will only make the confusion harder to spot.

Before creating the instance, I would protect the AWS account with MFA and use a separate identity for everyday work instead of the root user. AWS recommends temporary credentials and least-privilege permissions. For this lab, that means understanding which permissions the task needs rather than leaving broad access in place because it is convenient.

If I use SSH, I would restrict the security group rule to my current public IP address. AWS recommends allowing SSH only from the specific addresses that need access. If my IP changes, I would update the rule. I would keep any monitoring interface private as the lab grows.

The first access test would be simple: confirm that the intended connection works, then review the rule and explain why it permits that connection.

I would choose one Region, check the current prices for the resources I intend to create, and decide how long the experiment should run. I would also configure a small AWS budget with email alerts.

A budget alert is not a guaranteed spending cap. AWS documents that billing data and notifications can be delayed, so charges can pass the alert threshold before an email arrives. I would use alerts as a warning alongside regular cost checks and a short resource list.

That list would include the instance and anything else created for the experiment. At the end of the session, I would check each item, remove what I no longer need, and review billing again after usage data catches up. I would not assume that ending the SSH session ends the cost.

For each test, I would save four things: what I changed, what I expected, what I observed, and what I would check next. A timestamped log excerpt and a short explanation would be more useful than a screenshot with no context.

For example, if a login fails but I cannot find a matching entry, I would check the username, authentication method, log source, and timestamps before assuming the logging is broken. That investigation is part of the project.

Any notes I share publicly would leave out credentials and unnecessary account or network details.

Once I can repeat and explain the login test, I would consider forwarding the logs to a monitoring tool such as Wazuh. The next goal would be to follow one event from the Linux host into the monitoring interface and explain any alert it produces.

I want the first version to end with something concrete: a small diagram, a repeatable test, a few useful log entries, and a cleanup record. If another student can follow those notes and understand the same result, the lab has done its job.