The AWS Spend of Our SaaS Side-Business

Yes. Although Administration / UI is slightly more confusing. We had unique performance issues with the ELB offering that couldn't be fixed because it was the way it was designed. With ALB, that performance issue no longer existed.

You should talk to a gcp sales rep. They can help you move to a multi Cloud deployment. As well as describe some migration options.

Some of it is just documentation and marketing. If you go to the AWS api gateway main page, it talks about serverless/lambda integration right there. They also have specific pages that show how to use them together. Including using them as the endpoint, or using them at a higher level to influence routing to a different endpoint, or modify requests, etc.

Contrast with Google, you start with the confusion that there are two products (cloud endpoints, apigee), and neither really talks about integration with Cloud functions.

In my case the first obstacle (and I haven't looked into it too much) is we have a lot of Lambda functions written in Python and Scala.

If it's internal, you probably shouldn't be using the API Gateway. You can just call the underlying lambda directly through the SDK with invoke and save yourself the cost of the API Gateway, as well as be able to invoke it asynchronously should that be a better fit.

That said, it depends on your design/architecture as to whether that is appropriate or not. Sometimes you want that distinct separation. But if that's the case, you should also probably not even be thinking about that low latency case, because you should treat it as a service outside of your control, that may be (and probably should be) cross regionally available (so you might even be crossing the country, for all you know. This presumes the inclusion of latency based routing with a custom DNS, of course, but for a standalone, client facing service, that's what you should be doing anyway).

Obviously there may be a middle ground you want, but I'd say you probably either want to treat it as "your" API, and thus, you can be as pragmatic as you want when accessing it, or you want to treat it as a reusable, completely separate service, that you are a client of, in which case things like location can not be guaranteed, and thus latency is a reality.

We recently used API gateway to publish our first "public" facing API for some of our partners to integrate with. We we're using swagger to describe our internal APIs. A subset of those APIs needed to be exposed to partners. We also wanted to enforce a different security model and leverage rate limiting for these requests to protect us from unexpected growth.

Integrating API gateway into our deployment took a little bit of work, but we're happy to have it part of our automated deployment process. We push updates of our swagger spec with AWS CLI to a separate API per environment (dev, staging, and prod-west, prod-east). Each of environment has one API gateways with several stages that we use for green/blue deployments. The stages are green, blue, and public. We deploy to the inactive color (green or blue) smoke test and promote that stage to public. This simulates the same process we do in production and the swap to public is akin to our DNS swap from one side to the other. We were very happy that it wasn't a huge time investment to fit this workflow into our deployment process.

Somehow we missed the fact that because API gateway was tied to CloudFront that it did not support multi regional failover. If we have a service outage in our primary region we swap all of our traffic with DNS to our secondary region (from us-west-2 to us-east-1). In order for us to do a regional failover with API gateway we would need to deprovision the endpoint api.domain.com in the failing region and provision api.domain.com in our failover region. I'm expecting if we have to do a regional failover there is a very good chance that the request to deprovision the endpoint will likely fail. See my AWS forum reply and other's asking for the same feature: https://forums.aws.amazon.com/message.jspa?messageID=761925#...

    My team is very much looking forward to this functionality. We have duplicated our infrastructure across multiple regions to mitigate a region outage. We were planning on relying on a dns change to route traffic to a new region.
    
    With the limitations that you have described, our failover process is much more complicated and uncertain. 
    
    Given the two regions primary (us-west-2) and secondary (us-east-1). We will need to attempt to disassociate our api.domain.com from primary API Gateway and wait for that operation to complete. After that we must associate our secondary API Gateway with api.domain.com. Its very possible and likely issues on primary that caused us to fail over to secondary may prevent the disassociating from the primary. This is an extremely undesirable side effect as it could leave us with unhandled requests or error responses to api.domain.com.
    
    I wanted to post this here for others suggest alternative workarounds or ideas. We will also follow up with a support ticket.

They are aware of the issue and it seems like something on their roadmap, but that could mean 1-2 years out. Thankfully this partner API doesn't have near the same SLA and HA requirements we have for other features of our SaaS product. If our SLA requirements were higher we would need to consider a different solution. We have handwaved some ideas that we could use if there was an extensive outage which likely equates to standing up a reverse proxy that listens on api.domain.com and proxies traffic to the API gateway url for our secondary region. That certainly isn't ideal and doubles the latency that we have with API Gateway already proxying requests to our internal API.

-If you benefit from it-. Utility only matters if you're using it; otherwise, why pay for it?

I also saw they were using S3; I thought that was what the OP question was in relation to.

Use Virtual IP rather than DNS for failover.

Minutes is a really long time to go down.

If you use MariaDB drivers.

can't you just create new accounts ad infintum?

cloudability starts at $499 minimum per month. Not sure how this seems to be a feasible option for side projects.

Yeah, I think even from my experience with their other services, that graph can be a bit misleading - even though it shows the timeline in 5 min increments, I think the actual refresh in the back end is a lot longer than that. No idea with their Billing system, but I think even Lambda doesn't get updated more than once every 15 minutes or so.