App Engine is a Platform-as-a-Service. It means that you simply deploy your code, and the platform does everything else for you. For example, if your app becomes very successful, App Engine will automatically create more instances to handle the increased volume.

Read more about App Engine

Compute Engine is an Infrastructure-as-a-Service. You have to create and configure your own virtual machine instances. It gives you more flexibility and generally costs much less than App Engine. The drawback is that you have to manage your app and virtual machines yourself.

Read more about Compute Engine

You can mix both App Engine and Compute Engine, if necessary. They both work well with the other parts of the Google Cloud Platform.

EDIT (May 2016):

One more important distinction: projects running on App Engine can scale down to zero instances if no requests are coming in. This is extremely useful at the development stage as you can go for weeks without going over the generous free quota of instance-hours. Flexible runtime (i.e. "managed VMs") require at least one instance to run constantly.

EDIT (April 2017):

Cloud Functions (currently in beta) is the next level up from App Engine in terms of abstraction - no instances! It allows developers to deploy bite-size pieces of code that execute in response to different events, which may include HTTP requests, changes in Cloud Storage, etc.

The biggest difference with App Engine is that functions are priced per 100 milliseconds, while App Engine's instances shut down only after 15 minutes of inactivity. Another advantage is that Cloud Functions execute immediately, while a call to App Engine may require a new instance - and cold-starting a new instance may take a few seconds or longer (depending on runtime and your code).

This makes Cloud Functions ideal for (a) rare calls - no need to keep an instance live just in case something happens, (b) rapidly changing loads where instances are often spinning and shutting down, and possibly more use cases.

Read more about Cloud Functions

The Cloud Run documentation is not yet very informative but the new video Where Should I Run My Code? Choosing From 5+ Compute Options (Cloud Next '19) compares Cloud Run with App Engine and also Cloud Functions, Google Kubernetes Engine, and Google Compute Engine.

• You can choose to deploy your Cloud Run app on fully managed infrastructure ("serverless", pay per use, auto-scaling up rapidly and down to 0 depending on traffic) or on a Google Kubernetes Engine cluster. App Engine is always fully managed, with auto-scaling. App Engine Flex auto-scales gradually and down to 1. App Engine Second Generation auto-scales up rapidly and down to 0.
• Cloud Run requires your app to run in a container. App Engine Flex runs your container for any language runtime. App Engine Second Generation provides a few language runtimes.
• Cloud Run services can now respond to HTTPS requests (which don't have to be from web browsers), gRPC requests, Pub/Sub triggers, or scheduled triggers. It can be configured to allow up to 15 minutes to process a request. App Engine runs HTTP web apps. It has different request timeouts for App Engine Classic, Standard, and Flex, and it varies for Automatic scaling, Basic scaling, and Manual scaling.
• Cloud Run is designed for teams that include both software developers and ops experts. App Engine is designed for developers.
• Cloud Run is generally available (as of Nov. 14, 2019). App Engine has been battle tested for years and is serving many billions of requests per day.

Investigate Cloud Run's limitations before getting started. E.g. the payload container can be configured with up to 2GB RAM (more with a GKE cluster) with no disk space (only RAM disk). See the Cloud Run How-To Guides and the rest of the Cloud Run Documentation.

Also see the App Engine Documentation.

App Engine is a Platform-as-a-Service. It means that you simply deploy your code, and the platform does everything else for you. For example, if your app becomes very successful, App Engine will automatically create more instances to handle the increased volume.

It auto scales from 0 to unlimited instances (It uses GCE underneath). It comes with 2 flavors Standard Environment and Flexible Environment. Standard Environment is really fast, scales down to 0 instances when no-one is using your app, scales up and down in seconds and has dedicated Google services and libraries for caching, authentication etc. The caveat with Standard environment is that it is very restrictive since it runs in a sandbox. The recent additions are Node.js (8.x) and Python 3.x. Flexible Environment is more open as it allows you to use custom runtimes as it uses docker containers. Thus if your runtime is not available in the provided runtimes, you can always create your own dockerfile for the execution environment. The caveat with it is, it requires having at least 1 instance running, even if no-one is using your app, plus the scaling up and down requires a few minutes.

Read more about App Engine

App Engine is for deploying code, Cloud Run for deploying containers, and containers are today’s requirements.Cloud Run runs containers, so for each release you have to build a container and push it to GCP.

Cloud Run, App Engine Flexible and Newer runtimes of App Engine Standard are designed for portability (you can use open-source libraries or standard libraries and not just Google Libraries). Cloud Run and App Engine Flexible allow for custom runtimes.

Cloud Run gives you the freedom to expand your infrastructure into hybrid and multi-cloud environments.

Read more about Cloud Run

Differences you should consider:

• For a low-traffic application, Cloud Run or App Engine Standard which is set to automatic scaling are both cheaper than App Engine Standard which is set to manual/basic scaling or App Engine Flexible. Cloud Run only runs when it is serving requests. App Engine which is set to automatic scaling shuts down when it is not serving requests. This means for both types, you're not using resources when your application is not running and Google only bills you for resources that you consume. In addition, App Engine Standard provides a free daily quota of resources so you're only billed for consuming resources above the free quota. App Engine Flexible or App Engine Standard set to manual/basic scaling must have at least 1 instance running continuously, which means they run for a full month which in turn means you're going to pay more.

• App Engine responds on average 56 ms faster than Cloud Run. The huge caveat here is that these times vary widely between runs, sometimes tripling or quadrupling The total request size from Cloud Run was larger because it doesn’t gzip files by default. The big difference between the two services is that Cloud Run doesn’t run your container unless it’s getting requests. When a request comes in, it does things: [i] boots up the container [ii] serves the request [iii] shuts down the container Of course, you also save a lot of money doing it this way, so the tradeoff here is whether you care more about optimizing your speed or your cost.

• AppEngine can only be deployed to a single region. If you want an AppEngine app to be multi-regional then you need one project per region. Cloud run allows you to deploy a service to every region within a single project making your API truly global, all within a single project

• Cloud Run also allows you to set up a static IP address, something you cannot get with AppEngine. This is helpful for situations where you need to relay mail or connect to some other service that restricts access by IP address. Also AppEngine still has some things Cloud Run doesn't (like Identity Aware Proxy) have.

• The docker image support in Cloud Run is also more versatile than what you get from AppEngine Standard, and Cloud Run has more robust options to choose from (more ram, cpu, etc).

1https://cloud.google.com/appengine/docs/standard/nodejs/quickstart 2https://cloud.google.com/run/docs/quickstarts/build-and-deploy/deploy-nodejs-service