Infoblox DDI Deployment in the Cloud for Remote Branches without Docker or ESXi Servers

[#1]

Hey everyone! New to Infoblox, and I have a question about deploying Infoblox in a cloud environment for remote branches where it's not possible to install Docker or ESXi servers. Specifically, I'd like to use Infoblox for DNS, DHCP, and IPAM services. Here are my concerns:

1. Can I deploy an Infoblox appliance in AWS for remote branches, and how can I ensure DHCP Discoveries are forwarded securely to the cloud-based Infoblox appliance? I'm new to Infoblox, so any step-by-step guidance would be greatly appreciated.

2. Have any of you, especially those with experience in Infoblox, implemented a similar setup without the ability to install Docker or ESXi servers in remote offices? Can you share your experiences or best practices for doing this?

3. Do I always need on-premises Infoblox units, or is a cloud-based approach feasible for a network with around 300 remote offices that have dynamic public IP addresses, especially considering the inability to install Docker or ESXi servers on this remote branches.

4. Considering the security aspect, what are the recommended methods to secure traffic when using public IP addresses in the cloud in a scenario where Docker or ESXi servers can't be installed in remote offices? Any beginner-friendly explanations would be great.

I appreciate any insights or advice you can provide.

Thanks!

[#2]

A few questions here, let's take it step by step. 

1. Use DHCP relay agents or helper IP addresses to get this data to the right place. For example, you have a public elastic IP on your AWS instance, which NATs to an infoblox cloud appliance, make sure that private IP is routable from the remote sites and set your relay/helpers accordingly. 
2. Do you have a full mesh type SDWAN/VPN tunnel to a few DCs / cloud DCs? In Infoblox we use a feature called DHCP failover, which allows members to split the DHCP scopes in the event of a failure (link is up but box is down) which allows for the flexibility you'd require.
3. This question is better answered with a question, "at these remote sites, if the internet goes down, will work still need to be done?" If the answer is "no, if the internet is out my workers can't do anything without it" or "yes, there are local resources there for my users to work without outbound connectivity" will guide you to what is needed for onsite. If there aren't local resources, why require local authoritative DNS and DHCP? If most work is done in the cloud, and connectivity is down, so be it. Many customers use BloxOne DDI for this, as NIOS charges per VM to horizontally scale, B1DDI doesn't. So you could deploy a ton of NUCs or RasPis or whatever to get local DNS/DHCP there at (fractional) cost. 
4. Recommended you don't use an elastic public IP as the Infoblox interface IP. That would allow for UDP53 traffic to leak from your network outbound. Keep that in IPSec, you'll be fine. If you have Meraki or the like you can make IPSec tunnels between all your branches and AWS easily.