Updates to AppSheet IP addresses supported for access control

[lizlynch]

In a previous announcement, we provided a list of IP addresses that we had reserved, but were not yet serving traffic.Within the next few days, we will place these IP addresses in service (excluding the Asia-Southeast1 and Australia-Southeast1 addresses, as AppSheet does not currently serve traffic from those regions). If you are expecting AppSheet traffic to use a particular IP address, and have not already updated your firewall or network security group rules with these addresses, we recommend doing so soon. For quick reference, these addresses are as follows:

US-West1

34.82.138.241
35.230.32.44
35.233.206.57
104.199.122.182

US-East4

34.145.159.146
35.245.45.144

Us-Central1

34.123.81.112
35.232.30.149

Europe-West4

34.91.142.99
34.141.206.242

Additionally, we have placed a new list of IP addresses in reserve. These IP addresses are not yet serving traffic, and we will make a new announcement before we place them into service, but again we recommend updating your firewall or network security group rules with these addresses. The new addresses are as follows:

US-West1

35.203.182.241
35.247.115.29

US-East4

35.245.185.255
35.245.210.44

Us-Central1

34.30.208.22
34.135.161.164

Europe-West4

34.90.174.231
34.91.186.92

For the complete list of AppSheet IP addresses and other details, see Managing IP addresses and firewall information.

[takuya_miyai]

@lizlynch 
@isdal 
@zito 
@devingu 

As I pointed out before, the addition of the server IP should be announced more delicately.

When in the world will you start operating with this IP?
Tomorrow or a week from now?

We are running an app in japan that uses US-West Cloud SQL.
If we use the app from Japan and the APAC servers are activated, we will incur intercontinental communication costs.
Is my understanding correct?

[zito]

Hey Takuya,

This topic has come up before, you can see my post on the subject here:

https://www.googlecloudcommunity.com/gc/Announcements/Updates-to-AppSheet-IP-addresses-supported-for...

In short, though, database connections are made from the region where app *users* are connecting from.  An app user in california, for example, will likely connect to our app servers in us-west, and then those app servers will connect from us-west to the cloud SQL instance in US-west.  

If an app user launches the app in, say, France, they will likely connect to our app servers in europe-west, and then those app servers in europe-west will connect to your cloud SQL database in us-west1 and will incur traffic costs.

In general, we do not make any predictions or commitments that traffic from a particular region can be localized to a particular datacenter, so we can't commit that traffic won't generate network costs under any situations.  In addition, the nature of internet routing is such that its possible that a user in one physical region might connect to a different GCP region due to factors outside of our control. 

There's no way we can guarantee how any of this traffic flows, and so the purpose of notifying users of these ip address changes are so they can update their firewalls to ensure continued application operation, not to make people aware of possible changes in network patterns.  In this case, these IPs were announced back in august, so there's been a long notification period.  

EDIT: Also, to be clear, we're not adding new regions to operate out of at this time.  This is simply changing the set of IP addresses that existing regions utilize

[takuya_miyai]

Thanks @zito 

Yes, first of all, you clarified, and I apologize for the way I wrote about the traffic costs, which you seem to have forgotten about.

And with your and @Trevor_Ryland  help, I have known that the AppSheet server is not going to work in the new region. It looks like we can avoid the problem for now.

But again I would like to point out that I feel that Google is downplaying this issue, despite the following reasons.

* AppSheet and Cloud SQL connection is a basic solution.
* However, since it is not possible to specify the AppSheet server, traffic costs should be considered when selecting that solution.
* Also, due to AppSheet's architecture, a certain number of records are downloaded to the client each time a Sync is performed, which tends to increase the amount of traffic, even though it is text-based.
* However, this fact is not generally known and even local Google account sales are not aware of it.
* As a result, one day the customer will receive a bill for unintended traffic costs

This is a problem that has already actually occurred at our key customer sites and is still a challenge. (our, by which I include Google).

Finally, my request, as previously stated, is that connections from the AppSheet server be excluded from the traffic costs.
If we pay for an AppSheet license and employ Google's DB solution, we would normally think to be able to control costs.
However, there are cases where the current AppSheet and Cloud SQL solutions are very difficult to use for worldwide apps.

Thanks.

[Markus_Malessa]

I am wondering if this is something that can be solved via a Google service account. When we used Google App Maker that is how all traffic with Google Cloud SQL was handled. When I first switched to Appsheet and found out about having to maintain an IP whitelist I was somewhat shocked. Of course this was over 2 years ago now and at that time I had suggested allowing a google service account to connect with Appsheet, but obviously this appears to be not very high on the priority list. Between this announcement and me noticing that my apps started having troubles with Cloud SQL connections, I had to make updates to my list, resulting in about 12 deletions and probably 24 additions. Somewhat ridiculous. I agree with the sentiment that Cloud SQL and Appsheet being Google services, they should make a much better attempt at integrating them with each other. Although unrelated, I am still also lamenting that they have not switched Google Maps to the mobile version to integrate with Appsheet so that maps would be available completely offline.

[zito]

---

@Markus_Malessa wrote:

I am wondering if this is something that can be solved via a Google service account. When we used Google App Maker that is how all traffic with Google Cloud SQL was handled. When I first switched to Appsheet and found out about having to maintain an IP whitelist I was somewhat shocked.

---

We're exploring this currently - there were some limitations on the CloudSQL side that made this difficult for us, but they've made some changes.  We are looking at doing some pilot implementations - the goal is more to avoid opening up firewall holes rather than avoiding transit network costs, but I should find out whether it would also solve that issue.  

[Trevor_Ryland]

Hello @takuya_miyai,

I'm the engineer who drafted the announcement, and I want to apologize for and clarify a miscommunication I made. I mistakenly included the Asia and Australia addresses in the announcement, but AppSheet does not serve traffic from APAC regions (or have plans to do so, to my knowledge). We still have those addresses reserved and recommend customers keep them in their allowlist, but they will not be enabled at this time and you will not see a shift in traffic to/from APAC as a result of this update. I have asked Liz to remove those addresses from this announcement and indicate the regions of the addresses that are actually being placed into service.

We currently expect the new addresses to begin serving traffic on Monday, but the timing is inexact and may be delayed by a day or two. If there is a more significant delay, we will update the announcement accordingly.

[takuya_miyai]

Thanks @Trevor_Ryland 

Yes, I have confirmed that the APAC IP has been removed from the list of scheduled activations.
As noted in my comment to @zito , there are still some fundamental issues, but for now it looks like the problem can be avoided.

By issues, I mean that one day traffic costs will suddenly be notified to our customers and they will distrust AppSheet.
This problem has already occurred once.
I hope you can help us continue to use AppSheet with confidence.

[takuya_miyai]

@Roderick @Michelle @Lauren_vdv 

Please support this case as a community moderator.
Although this is an announcement that affects many production apps, many members of the AppSheet team do not understand the nature of the problem.

@Koichi_Tsuji 
@Aleksi 
@Steve 

[Jimbo]

Y cuáles son las IP que dejaron de usar?

[w_inoue_yata]

@Trevor_Ryland 
Since I'm using Cloud SQL, I need to add any changes to the AppSheet source IP address to the Cloud SQL allowed IPs, but I don't want to do this manually. To automate this with Cloud Functions, etc., is there any plan to implement an API to get the latest IP address list or update information in plain text format such as json?

[Jamie]

Hi @lizlynch  - recently we have started seeing some very limited traffic (~30 connections in 30 days) connecting from the IP 34.91.125.96 to the Microsoft 365 (OneDrive) share which hosts all our Appsheet content. This source IP is registered to Google Cloud, but it is not present on the list above, nor on the other list of documented AppSheet IPs (Manage IP addresses and firewall information - AppSheet Help (google.com)

Is it possible that some traffic is leaking out an undocumented IP? I am going to block the traffic, but I would like to understand what it is, and since the physical location (Groningen, Netherlands) is identical to the 4 new Europe West IPs above, it seems likely that this is coming from AppSheet servers. As I said, it is a tiny amount of traffic, so I don't believe it could be an actual user connecting from this address. It is just enough to set off our alerting rules.

Thanks for any info you can provide