SRX

I'm trying to get routing configured on an AWS vSRX which will be responsible for routing 4 different subnets (mgmt, untrust, trust, & dmz). Right now I'm having trouble getting the dmz (172.20.52.0/23) and trust (172.20.56.0/23) subnets to behave. Based on recommendations listed here Juniper vSRX AWS Documentation I've created 3 different routing-instances to handle the routing needs of the 3 subnets I care about (untrust, dmz, & trust). 

interfaces {
    ge-0/0/0 {
        description rtr-or-west2a-untrust-juniper;
        unit 0 {
            family inet {
                address 172.20.48.10/23;
            }
        }
    }
    ge-0/0/1 {
        description rtr-or-west2a-trust-juniper;
        unit 0 {
            family inet {
                address 172.20.56.10/23;
            }
        }
    }
    ge-0/0/2 {
        description rtr-or-west2a-dmz-juniper;
        unit 0 {
            family inet {
                address 172.20.52.10/23;
            }
        }
    }
}

routing-instances {
    aws-dmz {
        instance-type virtual-router;
        interface ge-0/0/2.0;
        routing-options {
            static {
                route 10.0.0.0/8 next-hop 172.20.52.1;
            }
        }
    }
    aws-trust {
        instance-type virtual-router;
        interface ge-0/0/1.0;
        routing-options {
            static {
                route 10.0.0.0/8 next-hop 172.20.56.1;
            }
        }
    }
    aws-untrust {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 172.20.48.1;
            }
        }
    }
}

I figured I needed to do this because I would need to point my corporate static route of 10.0.0.0/8 to the appropriate router in AWS. My host on the dmz subnet (pointing to the dmz interface as it's default gateway) isn't able to ping my corporate resources. Is this the correct setup? Should I be throwing the dmz & trust interface in the same routing-instance and setting up some sort of policy based route so if a packet is coming from my dmz network? 

Perhaps the problem is something else??? I'm able to ping the dmz interface from my corporate network. I'm at a loss, can someone assist me here?

Perhaps setup my routing-instances like this and setup some sort of policy based routing to cover the correct IP address for the dmz subnet to access my corporate resources.

aws-trust {
    instance-type virtual-router;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    routing-options {
        static {
            route 10.0.0.0/8 next-hop 172.20.56.1;
        }
    }
}
aws-untrust {
    instance-type virtual-router;
    interface ge-0/0/0.0;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 172.20.48.1;
        }
    }
}

I'm not familiar with the AWS interface but those don't look like routing instances only creating separate subnets assigned to zones.

A virtual router routing instance creates a completely separate routing table as if a separate router were in use.  You seem to only really need a singel router with three interfaces each in their own zone.

I'm pretty sure the code at the bottom the first block of code is routing-instances. The recommendations from Juniper for a vSRX in AWS is to create a second routing-instance to isolate the management traffic on fxp0.0 from the revenue interfaces ge-0/0/0,1,2. I just expanded on that to create 2 more to further isolate the route tables for 0,1 & 2. I can bunch them all into their own instance but then my route statement of 10.0.0.0/8 is pointing to an IP (172.20.56.1) that only the trust subnet can contact. The traffic from my DMZ would need to be able to route their traffic destined for 10.0.0.0/8 to 172.20.52.1 and I don't know how to do that.

Yes it is common to put the mgmt in a separate routing instance to keep mgmt traffic off the production network.

but your production subnets need to talk to each other so isolating them into separate routing domains creates communications problems for you.  We only use routing instances to isolate subnets from other subnets or interfaces on the same box.

As Steve mentioned, you probably don't need to separate your subnets into different routing-instances, as you can control traffic between interfaces with security policies. 

If you still feel the need to have them in separate routing instances (thus, different routing tables) you can use filter based forwarding, or tricks like static routes with next-table instead of next-hop, to send traffic from one routing-instance to the other, and will probably need to do some route sharing between the tables with maybe rib-groups.

It is possible to do things like that, but it can get complex. So, unless you really need that, why not just keep them in the same routing table and use security policies to control traffic between the interfaces?  

OK, I've got all 3 of my revenue interfaces located in one separate routing-instance per the recommendations from Juniper

security {
    flow {
        traceoptions {
            file joshua-stage;
            flag all;
            packet-filter packet-filter1 {
                protocol icmp;
            }
        }
    }
    nat {
        source {
            rule-set trust-to-untrust {
                from zone [ dmz trust ];
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone trust to-zone untrust {
            policy default_allow {
                match {
                    source-address any;
                    destination-address any;
                    application junos-ping;
                }
                then {
                    permit;
                }
            }
        }
        from-zone dmz to-zone untrust {
            policy default_allow {
                match {
                    source-address any;
                    destination-address any;
                    application junos-ping;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone dmz {
            policy default_allow {
                match {
                    source-address any;
                    destination-address any;
                    application junos-ping;
                }
                then {
                    permit;
                }
            }
        }
        from-zone dmz to-zone trust {
            policy default_allow {
                match {
                    source-address any;
                    destination-address any;
                    application junos-ping;
                }
                then {
                    permit;
                }
            }
        }
    }
    zones {
        security-zone untrust {
            interfaces {
                ge-0/0/0.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                    }
                }
            }
        }
        security-zone trust {
            interfaces {
                ge-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                    }
                }
            }
        }
        security-zone dmz {
            interfaces {
                ge-0/0/2.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                    }
                }
            }
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 172.20.48.10/23;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 172.20.56.10/23;
            }
        }
    }
    ge-0/0/2 {
        unit 0 {
            family inet {
                address 172.20.52.10/23;
            }
        }
    }
}
routing-instances {
    aws {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface ge-0/0/1.0;
        interface ge-0/0/2.0;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 172.20.48.1;
                route 10.0.0.0/8 next-hop 172.20.56.1;
            }
        }
    }
}

I'm still not seeing ICMP traffic sourced from my DMZ interface to my workstation on-prem. I see it when it's sourced from the trust interface but not DMZ. Not sure my next steps here.