Anything that doesn't have a real life time requirement should be moved to update the simulation on demand before passing back the results.
For example, a real life time requirement might be that you have matches at Sunday afternoon and email out results to team owners. You would run that process once a week, there's no need to keep it running all the time.
Without needing the real life requirement to email out results weekly you could just wait until someone logs in before updating the entire simulation.
You will have to build the team data model to have a history of events over time alongside current state of the team.
Side effects of designing that way is that multiple simulation results will need to be queued up and added to the team history. The example being that if someone was away for three weeks they will log in and when they ask for their team state the simulation has to run three weeks of updates and play three matches, each of which will require its own result to be added.
Note that since the team simulation is updated on demand, when a match is called for in the simulation the other team will then be updated recursively to be ready for the match, and so on. The effect will be that one person logging in will spawn a flurry of simulation updates but only as many as are touched by events like simulated matches that need other teams.
Gameplay in this setup comes from logging in daily (or often enough) to make player decisions on training, morale, etc... Where someone who logs in a lot can tune up their team to be effective while someone who only comes on every week or two will have an unspecialized team with lower morale.
PS: don't forget to add social functions for team owners to get together and talk, a forum or something simple, this will help players feel more invested in the game.