WordPress’s behavior in this scenario is related to how it handles URL resolution and DNS lookup. WordPress relies on the site URL specified in its configuration to construct internal links and route requests. When you access your WordPress site at https://mysite.example.com, WordPress will generate links based on this URL.
In your case, you have configured your WordPress site URL as https://mysite.example.com in wp-config.php. When WordPress generates internal links, it will use this URL as the base.
The issue arises when you try to access other pages or subdomains within your WordPress multisite installation. WordPress will use the site URL https://mysite.example.com as the base, and when it constructs links to other pages or subdomains, it will use this URL. This means that when a user tries to access a subdomain or a different page, WordPress will construct URLs like https://mysite.example.com/other-page or https://subsite1.mysite.example.com, which are external to your EC2 instance.
Because your EC2 instance does not have internet access, it cannot resolve these external URLs, resulting in a timeout error.
To resolve this issue without giving your EC2 instance direct internet access, you can use the /etc/hosts file to override DNS resolution for these domains, just as you’ve already done:
127.0.0.1 mysite.example.com
127.0.0.1 subsite1.mysite.example.com
By adding these entries to /etc/hosts, you are telling the server to resolve these domain names locally, pointing them to the loopback address (127.0.0.1). This allows WordPress to route requests internally without trying to reach external DNS servers.