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使得這些限制有伸縮性，並且對應用使用了更嚴格的限制，防止應用耗盡資源來保護共享資源。
一個請求處理器（request handler）最多有60秒（up to 60s）的時間將響應返回給客戶端。盡管看上去對於一個Web應用來講這是相當多的，但是App Engine還是會優化應用使其響應時間小於1秒。並且（also），如果一個應用使用了很多的CPU周期的話，App Engine 可能會使它慢下來，那么在提供多個應用的機器上這個應用不會強占處理器（processor）。對於一個CPU密集型的請求處理器，如果它需要很多的處理的話會使用比本來更多的時鍾時間（clock time）。當App Engine偵查出CPU的使用方式時時鍾時間會響應地改變，分配。（A CPU-intensive request handler may take more clock time to complete than it would if it had expensive use of the processor,and clock time may vary as App Engine detects patterns in CPU usage and allocates accordingly）
Google App Engine為應用提供了三種可用的運行時環境：Java 環境，Python環境，Go環境（Google開發的新的系統語言）。你選擇的環境取決於你開發應用使用的語言和相關的技術。
Java環境在Java 6 VM上運行應用。一個應用可以使用Java語言開發，或者大部分其他的可以在JVM上編譯或運行的語言，比如PHP（使用Quercus），Ruby（使用JRuby）,JavaScript（使用Rhino 解釋器），Scala，Groovy和Clojure。應用使用基於Web工業標准的接口訪問環境和服務，包括Java Servlets和Java Persistence API （JPA）。任何在沙箱約束中起作用的Java技術都可以在App Engine中運行，使得許多存在的框架和庫適用於它。尤其是，App Engine完全支持Google Web Tookit(GWT)，一個富Web應用程序框架，使我們可以用Java語言寫所有的應用代碼（包括在瀏覽器中運行的用戶接口），並且使富圖形應用能夠在絕大多數瀏覽器上工作而不需要插件。
Python環境運行由Python2.7編程語言編寫的應用，使用自定義的CPython版本，官方的Python解釋器。App Engine使用WSGI調用Python 應用，一個廣泛使用的應用接口標准。應用可以使用大部分Python的大型的傑出的標准庫，以及訪問服務和模型數據（modeling data）的富APIs和庫。許多開源的Python web應用框架和App Engine一起工作，比如Django，web2py，Pyramid，Flask。App Engine 甚至有一個自己的叫做webapp的輕量級的框架。
這三個運行時環境使用相同的應用服務模型：一個請求路由到app server，應用實例初期化（必要的話），應用代碼被調用來處理這個請求，生成響應，響應返回客戶端。每個環境都在沙箱約束中運行應用代碼，所以任何使用語言本身或某個庫來訪問沙箱以外的東西都會返回一個錯誤。
你可以配置實例的創建、銷毀和初期化的任何一個方面。如何配置應用取決於花費與性能之間的平衡點。如果傾向於性能，就可以多配置一些運行的實例。開啟多個實例處理需要。如果預算有限就調整限制，使用最少的實例來控制請求的排隊等候。（if you have a limited budget,you can adjust the limits that control how requests queue up to use a minimum number of instances）
現在還沒有說到任何關於App Engine使用的操作系統和硬件配置。有辦法知道一個服務器使用的操作系統和硬件，不過這是沒有必要的：運行時環境是操作系統之上的一個抽象。允許App Engine管理資源的分配、計算、請求處理、規模擴大（scaling）、負載分布而沒有應用的參與。那些需要用到操作系統的特性是由運行環境之外的服務提供，由標准庫的調用來提供或仿真，或者在沙箱的定義中以理智的方法（in sensible way）限制。
上述內容描述了App Engine會根據應用的流量動態地分配應用實例來擴展。你也可以在指定的手動分配的實例上運行代碼，這些實例就是backends(or simply,"servers")。這些指定的實例十分適合於后台作業和自定義服務，有它們自己的參數來執行代碼（have their own parameters for how they execute code）。然而它們不會自動擴展（scale）。當達到了一個服務器的容量時，它根據你的代碼來決定下面怎么做。Backends是App Engine的一個新特性，這個體系結構正在演化。在這個版本的書中不會詳細談及這個特性。