Manual Minecraft Server on EC2

The CEO of Obsidian Dynamics read an article about “employee engagement” on a cross-country flight and landed with a vision: a company Minecraft server, live by Friday. The IT budget for this initiative is zero dollars. The headcount assigned to it is you. There was no discussion.

Your stakeholders do not care how it runs; they care that it is reachable, stable, and well-operated. You have one EC2 instance, an SSH key, and whatever dignity you brought to work this morning. Build the server completely manually on AWS Academy.

Learning Objectives

• Configure a Linux server to run a persistent network service.
• Apply baseline security controls (least privilege, SSH hygiene, network exposure).
• Demonstrate operational competence: start/stop, validate, and troubleshoot service behavior.
• Produce documentation that another operator could follow.

Constraints (AWS Academy)

• You must use AWS Academy resources only.
• Use EC2 for compute.
• Public exposure must be minimized:
  • SSH should be restricted to known IPs
  • The Minecraft port must be exposed only as required by the assignment.
• You must document cost controls (instance size choice + how/when you stop resources).
• If you use EC2 user-data for bootstrapping, it must be idempotent and defensible (e.g., for installing updates or a runtime). You may not use it to “bake in” configuration that you would otherwise do manually.

Requirements

Infrastructure and Access

• One Linux EC2 instance in a public subnet.
• A Security Group that:
  • Allows Minecraft traffic on 25565/tcp.
  • Allows administrative access with a clear restriction strategy.
• A dedicated minecraft operating system user.

Service Operation

• A Minecraft Java Edition server (Paper recommended) runs as a managed service.
• You may use any defensible process manager/init approach (e.g., systemd, pm2, or equivalent).
• The server starts automatically on reboot and restarts on failure.
• The world state persists across service restarts.

Documentation

Create an operator-facing, step-by-step tutorial runbook that includes:

• Exact setup steps from a fresh EC2 instance to a working Minecraft service.
• A dedicated section: How to Connect (admin SSH + player connection flow).
• A connection verification step using:

  nmap -sV -Pn -p T:25565 <instance_public_ip>

• How to start/stop/restart and confirm service health.
• Where logs are, and what “healthy startup” looks like.
• How to apply updates safely.
• A dedicated section: Cost-Control Strategy (instance sizing choice, stop schedule, and guardrails).

Question 1

What would break if you had to rebuild this server from scratch tomorrow? What information would you need that isn’t in your runbook?

Question 2

If two operators needed to manage this server simultaneously, what conflicts or risks would arise with your current setup?

What You’ll Submit

1. Tutorial Runbook (PDF) that is written as a reproducible step-by-step setup guide and includes:
   • setup from fresh EC2 to working service,
   • a How to Connect section,
   • the nmap connection test command and expected result,
   • a Cost-Control Strategy section,
   • operations content required above,
   • answers to the reflection questions above.
2. Narrated screen recording (max 3 minutes) with a timestamp list for each checkpoint:
   1. Show AWS console with account ID, SSH in, show dedicated minecraft user exists.
   2. Reboot the instance, then run nmap -sV -Pn -p T:25565 <public-ip> showing the service is reachable.
   3. Show systemd status (or equivalent) confirming auto-start after reboot.
   4. Demonstrate one stop/start cycle with health confirmation.

Your server MOTD must include your name or student ID. Submit timestamps (e.g., “Checkpoint 1: 0:00, Checkpoint 2: 0:38, …”) alongside the video.

Rubric

Always refer to Canvas for the most up-to-date rubric information. Canvas's rubric will be used for grading.

Manual Minecraft Server on EC2 (Total: 100 pts)

Criteria	Ratings
Tutorial setup completeness (25) Runbook is a reproducible build tutorial from fresh EC2 to running Minecraft service (instance creation, OS user, Java/runtime, server files, process manager configuration, and first start).	25 pts Exemplary All required build steps are present, correctly ordered, and executable by a new operator without guesswork. 20 pts Proficient Most build steps are correct and usable; minor gaps do not prevent successful setup. 12 pts Developing Several setup steps are missing/unclear; substantial inference is required to complete setup. 0 pts Insufficient Build instructions are incomplete, incorrect, or not reproducible.
Post-reboot connectivity verification (20) Evidence that the service is reachable after reboot using `nmap -sV -Pn -p T:25565 <instance_public_ip>`; this command/result is sufficient for this criterion.	20 pts Exemplary After reboot, evidence shows `nmap` run against the instance public IP with port `25565/tcp` reachable/open and service responding as expected. 16 pts Proficient Reboot and `nmap` evidence are present but one detail is weak (e.g., incomplete output, missing timing/context). 10 pts Developing Partial proof only (reboot or connectivity shown, not both clearly connected). 0 pts Insufficient No credible post-reboot reachability proof with `nmap`.
Secure access posture (20) Security controls are specific and least-privilege: dedicated `minecraft` user, SSH source restriction, and only required inbound ports exposed.	20 pts Exemplary Controls are correctly configured and justified; admin access is narrowly scoped and exposed surface is minimal. 16 pts Proficient Core controls are present with minor misconfigurations or incomplete justification. 10 pts Developing Some controls exist, but major least-privilege or network-restriction gaps remain. 0 pts Insufficient Security configuration is missing, unsafe, or not evidenced.
Service operations runbook quality (20) Operational procedures are explicit and usable: start/stop/restart commands, health checks, log locations/interpretation, and safe update steps.	20 pts Exemplary All operation procedures are clear, accurate, and actionable with expected outputs/signs of healthy state. 16 pts Proficient Most procedures are usable; minor omissions or ambiguity in one area. 10 pts Developing Operations guidance is partial or vague across multiple required procedures. 0 pts Insufficient Operations procedures are largely missing or unusable.
Cost-control strategy quality (15) Cost controls are concrete and defensible: instance sizing rationale, shutdown schedule, and practical guardrails for AWS Academy usage.	15 pts Exemplary Strategy is specific, realistic, and clearly linked to expected usage and constraints. 12 pts Proficient Strategy covers required elements but lacks depth in rationale or guardrails. 8 pts Developing Cost guidance is generic, incomplete, or weakly justified. 0 pts Insufficient Cost-control strategy is missing or not actionable.

Extra Credit (up to +10)

• Service/process hardening (+3): apply at least 3 meaningful hardening controls for your chosen service manager/process approach and justify each in the runbook.
• Operational diagnostics (+4): add a short diagnostics section to the runbook with command-driven checks (e.g., ss, manager logs/status tools) and expected outputs for a healthy service.
• In-service administration (+3): show how to administer the Minecraft server while it runs under your chosen manager (e.g., secure RCON setup), including at least 3 successful admin commands and safety notes.

Extra credit must stay within this assignment’s manual-operations scope (no Docker/Kubernetes, IaC, configuration-management frameworks, or backup/restore workflows).