App Engine应用响应网络请求。当一个客户端（典型的是用户的Web浏览器）使用HTTP请求（比如获取在URL上的网页）连接上应用的时候，网络请求就开始了。当App Engine接收到请求时，它会从地址的域名中识别应用，.appspot.com子域名（为每个应用免费提供的）或你在Google Apps中已经注册创建了的自定义的子域名。App Engine从众多可能的服务中选择一个服务来处理这个请求。选择的依据是哪个服务最可能提供一个快速的响应。然后它使用Http请求的内容调用应用，从应用中获取响应的数据，并且将响应返回给客户端。
从应用的角度看（perspective），这个运行时环境在请求处理开始的时候存在（spring into existence），在请求处理结束时消失。App Engine提供了几种在请求之间保存数据的方法，但是这些机制在运行时环境之外存在（live outside of the runtime environment）。在运行时环境中请求之间的状态不保留，或者至少不希望在请求之间保留状态，App Engine可以在众多的需要用的服务间分发流量来给予每个请求相同的对待，而不管它一次处理的流量是多少。
从全局来看（in the complete picture），App Engine 允许运行时环境在请求处理之后还存在，并且尽可能地重用环境来避免不必要的初期化。你的应用的每个实例都拥有本地内存来缓存导入的代码和初期化的数据结构。App Engine会按需创建或销毁实例来适应你的应用的流量（traffic）。如果你允许多线程的特性，那么一个实例可以充分利用它的资源并发地处理多个请求。
传统意义上，应用代码不能访问运行它的服务器。一个应用可以从文件系统中读取它自己的文件。但是不能向文件中写，也不能读取属于其他应用的文件。应用可以看到App Engine设置的环境变量，这些变量的操纵在请求之间没有必要继续存在。尽管应用可以使用服务来执行网络操作，但是应用不能访问服务器硬件的网络设备。
总之，每个请求存在于它自己的沙箱中。这允许App Engine使用最快的响应服务器来处理这个请求（估算的）。对于我们的向这个应用发出的请求，无法保证同一个应用实例来处理两个请求，尽管这些请求来自于同一个客户端并且都相对很快地到达了。
沙箱也允许App Engine在同一个服务器上运行多个应用而不会出现一个应用影响另一个应用。除了限制对操作系统的访问，运行时环境也限制了时钟的数量以及一个请求可以得到的内存。App Engine使得这些限制有伸缩性，并且对应用使用了更严格的限制，防止应用耗尽资源来保护共享资源。