After moving the eth0 interface from the trusted to the internet zone, after a few minutes I cannot connect to the GUI. My ssh connection disconnects as well.
The AWS console shows the instance is still running but I have to reboot to get things working again.
If possible, use AWS security groups to handle your firewall needs.
I found that the FreePBX Distro firewall blocks DHCP and this causes the instance to drop its IP address after some time. So if you are using the distro firewall, try adding a custom rule to allow DHCP.
I have an elastic IP address assigned so no need for DHCP
Unfortunately, that’s not how it works. Your EC2 instance will receive a private IP address from AWS DHCP server. Your elastic IP is mapped to that private IP. You must use DHCP and you cannot assign the public IP directly to the interface.
Thanks for clearing that up. I’ll give this a try.
No joy. I created the custom service as you specified and put the eth0 interface into the internet zone. I can connect to the GUI until the firewall kicks in then it is blocked
I also put my client network into the trusted zone.
I’ll try to ssh tomorrow. It’s 0130 ICT
Your issue may be different than the one I mentioned. With the DHCP packets being blocked, it usually would fail after several hours because the DHCP lease expires and the server can’t renew. In your case it is blocking you right away so you probably have something different going on. If you can operate with only AWS Security Groups as your firewall and disable the Distro firewall you will have a simpler configuration.
Do you have a working example security group for AWS with inbound rules
I’ve worked on dozens of systems on Vultr and they never have a problem getting their DHCP assigned address. I’ve also dealt with dozens of local VM installs with DHCP assigned IP addresses without ever seeing this. I have never used AWS though.
I don’t have the log information at hand and the incident I worked on was a year or so ago (which is why the screenshot image I shared has the old styling). I know this firewall rule solved the problem we had. If I remember it right, the initial DHCP acquisition by way of broadcast worked fine. Later, the renewal which happens by unicast was blocked, so at the end of the lease time the IP was released. When the IP was released, this caused several services on the server to go berserk (technically speaking!) and it never recovered. What I would expect to happen is for the DHCP client to start over with a broadcast to get a new lease, but that didn’t happen.
Please see my last comment. Can you help
I’m happy with AWS
How so, we all read that you can’t make it work 
Maybe they can help you traverse their firewall, you will need both your SIP signalling and your SDP traffic seamlessly forwarded both ways, along with any http/https services on whatever port you want to provide.
If I don’t put eth0 in the internet zone, it works. The private IP address is in the internet zone.
This is on a free tier so the price is right
Nothing is free. Time, yours or someone elses costs you or someone else
So don’t do that
https://aws.amazon.com/marketplace/pp/prodview-fzocchp6qcacs
Free tiers are free.
I’m using a community marketplace AMI that has no subscription fees
I found this. Is it complete? Would you make any changes?
Nobody has answered the question
It has been nighttime.
Yes, that guide is fine. Only allow traffic for what you are using. If you are only using SIP from your business then only allow your business IP to access SIP ports.
Thanks for all your help. I never did figure out exactly why putting the eth0 interface in the internet zone causes the failure that I described.