I recently quoted out a estimated AWS environment using t2 instances. I recommended for development t2.nano servers due to the single developer only working eight hours a day. I then recommended t2.medium instances for a soft production launch. Total user base will be around 30 users, so we were after redundancy at a low cost. I was asked “Why not use t2.small or t2.nano for production?”. I knew it was against best practices but I did not have any data to show why until I installed TeamCity on a t2.small sever for internal use.
Above is the CPU graph for the t2.small instance that runs the head node for TeamCity. By default, AWS servers start in UTC time, also a good best practice if your applications support it.
By default, Windows, and Windows Server 2016 sets the active hours from 8AM to 5PM local time to the server.
5PM UTC time is 12 PM EST, which will kick off Windows Update during your lunch hour. In our case, it dropped all of our CPU credits before I could shut off windows updates.
Each t2 instance has a baseline of vCPU, t2.Small is 20%, but the vCPU is not the best with intensive applications. Thankfully now we have Windows Update set correctly for business hours in the East Coast and our TeamCity server is now running fine. Lesson learned with t2 instance, be careful with any automatic process.