UrlFetchApp.fetch on Google Spreadsheets cannot connect AWS backend webservice

Question

We have an EC2 instance on AWS which we deployed our backend services to. We started by using Google Spreadsheets (scripted with Google Apps Script) to present our backend, through a webservice deployed on our server. We have a specific port from which https (uses a self-signed certifiate) protocol is used to serve the webservice encrypted while on flight. We had set up Security Groups (basically a firewall entry group) which include following CIDR ranges for that specific ingress port of our webservice:

64.18.0.0/20 
64.233.160.0/19 
66.102.0.0/20 
66.249.80.0/20 
72.14.192.0/18 
74.125.0.0/16 
173.194.0.0/16 
207.126.144.0/20 
209.85.128.0/17 
216.58.192.0/19 
216.239.32.0/19 

as described in https://developers.google.com/apps-script/guides/jdbc#setup_for_google_cloud_sql

This setup was working fine until 5 days ago. Then something weird happened. When we run the script behind the spreadsheet from 'Script Editor' code works fine and requests to our webservice return successfully. But when the exact same code was invoked through a menu item, it was not doing anything. After long frustrating investigation we found out that request was not even reaching our server (there were numerous other quirky symptoms like only last log command was visible on 'Execution Transcript' even though there should have been many others). Then we tried replacing the security group with a rule that accepts from any ip but to specific port everything was working fine again.

Here is a link to seemingly relevant issue in google-apps-script-issues page: https://code.google.com/p/google-apps-script-issues/issues/detail?id=4679#c8

We ran tcpdump tcp port <port> -i eth0 -vv and observed that when we run the code from 'Script Editor' request was made from 66.102.7.156 (and from similar ips, which are in 66.102.0.0/20), when code is invoked from menu item in spreadsheet the request was made from 72.14.199.55 (and from similar ips, which are in 72.14.192.0/18). This one seems to be the problematic ip range.

My question is, why is it the case that when request sources are correctly included in firewall rules one block of ips don't work and starts to work when ip restriction on the port is lifted (source ip 0.0.0.0/0)? Is it a bug of Security Groups in AWS? Or are we doing something wrong? Also if our approach is not adequate in any way, alternative solutions or suggestions would be much appreciated.

Answer 1

As per the issues you linked to, there was a bug in Apps Script that lead to this behavior. That bug has now been fixed.