increaseing the log size duing the opeartion like REBUILD /REORGANIZE / Update-STATS is normal depending on how much actual data size and how much it grows. What we can reduce is unnecessary disk uasage due to the incorrect implemnation of maintanance plan.
Firts Read the folowing MSDN BOL information sincerely.
Choosing a Recovery Model for Index Operations
From the table you will notice that even if you have database in SIMPLE recovery model, REORGANIZE operation is Fully Logged. but Rebuild is Minimally logged.
Reorganizing and Rebuilding Indexes
From above link you will find that Rebuild Clustered Index without disableing NONCLUSTERED index can have huge impact on DISK USAGE. Also the order of REBUIDL/REORGANIZE operation for CLUSTERED and NONCLUSTERED index is important. All NONCLUSTERED OPERATION should be followed by CLUSTERED INDEX operations.
Also notice the infomation Where it explanins the REBULD of large index in two phases. second phase of that opeartion runs in background and does not afect db performance but the down side is disk space will be remain used untill that phase is finished.
Now what are the logical steps you can take?
0) Make sure the Database is in right Recovery Model. if db has "FULL RECOVERY" mode, then you must have proper transectional log back up process as well. if not then either "FULL Recovery" is not really needed or you should revisite the LOG Backup process currently implemented.
1) check the maintanance plan and make sure you are doing REBUILD OR REORGANIZE as based on the right conditions. (for example fragmatation percentage.) in some cases you are sure that you want to rebuild index for specific table thats fine.
2) check if opertaion on NONCLUSTERED indexes are followed by OPERATION on CLUSTERED INDEX.
if not update the plan accordingly.
3) you are using STANDERED EDITION so all operation are happening OFFLINE.
but also check if SORT_IN_TEMPDB option is being used in REBUILD/REORGANIZE.
4) if answer of (3) is NO: "Whihc is most likely because you actual DB log size is increases and you haven't mentioned anything about tempdb" then consider using that option after looking at checks I mentioned in point (5).
5) if answer of (3) is YES: "which is unlikely" yet if thats the case, that means you also need to check Tempdb Configuration is doen proerly or not. like,
Does it have more than one LDF and MDF file? if no have atlease 2 for each.
Are those files are set to increase at right amount instead of default 10mb?
if default then start with the 1024MB increament. gradually you should find the
sweet spot.
Are those Files are ristricted to some size? if so check the disk size where the
files are and set accordingly.
Even If your Tempdb is not located on Seperate Disk, from the disk Actual DB is
on, making sure above checks is good practice amd sure help you.
6) As Shrink log operation is not devil if done moderatly same way REBUILD/REORGANIZE is not angel when you overdo it. you shold check if REBUILD/REORGANIZE on whole DB is really neccessary? may be weekly or every 3 day works better.
I am happy to go over next steps/suggestions about Statistics once you try out above and get some results. I will not expect that above steps megically solves your concern compeletly but yes, those will definetly improve the situation.