Cloud Ingress Egress

Overview

Ingress and Egress refer to inflows and outflows (respectively). They can be used in any context where a flow of traffic exists. Without additional context, the point of reference is typically the core of a system (such as a primary database responsible for satisfying the request or message). With additional context (such as a teammate who works on the same service), Ingress and Egress can refer to traffic flows in and out of any service or service's data store.

Request / Response

In Request / Response, requests have a final destination, regardless of the number of hops to that destination. All hops to the destination are Ingress while the response is Egress. The final destination is the point of reference. Additional requests could be made by these intermediary services in order to properly handle and hydrate the request or response. The terms Ingress and Egress could be used from the point of reference of these individual intermediary services, and they could also be used in the context of the main request's journey. Was the intermediary request made before handling the inbound request's response? Then it's an intermediary request on Ingress on handling of the inbound request. Otherwise, it's an intermediary request on Egress.

Ambiguity in Messaging Patterns

There exist contexts where traffic can be considered either Ingress, Egress, or neither. This isn't the case with Request / Response architecture, but it can be with Messaging Patterns. For example, if the messages are fetched from an Ingress distributed data store, and they require processing at two internal services before being stored in another distributed data store to be fetched by some other external system, then the path between the two internal services can be regarded as either Ingress, Egress, or neither. Then again, if one of those two services do more work, then that service can be regarded as the point of reference of that message's journey.

In the Cloud

In the context of the Cloud, the point of reference is your Cloud network (your Cloud accounts). In this context, Ingress and Egress refer to traffic flowing into and out of your Cloud accounts. An important implication is billing.

Billing

Cloud providers typically do not charge for most types of Ingress traffic (traffic into a Cloud network), but they do charge for Egress traffic (traffic moving out of a Cloud network). Reasons for this include:

• Encouraging data ingestion, given that data stored in the Cloud already incurs costs.
• Recover data center and global networking infrastructure costs (they do build transcontinental undersea cables).

Monitoring

Cloud providers typically offer some built-in metrics and tools to help monitor Ingress vs Egress Cloud traffic. Examples of this include the following offered by AWS CloudWatch for EC2 Instances:

• NetworkIn: The number of bytes received by the instance on all network interfaces.
• NetworkOut: The number of bytes sent out from the instance on all network interfaces.
• NetworkPacketsIn: The number of packets received by the instance on all network interfaces.
• NetworkPacketsOut: The number of packets sent out from the instance on all network interfaces.

Monitoring Ingress and Egress traffic across all products may require building Lambdas that consume access and flow logs, and emit metrics to CloudWatch. If a ~24-hour worst-case delay in these metrics is acceptable, they will appear on your billing console.

Conclusion

On the surface, Ingress and Egress are very simple concepts. However, given specific contexts and points of reference, it can be ambiguous.

To be updated with examples for monitoring access and flow logs.

To be updated with diagrams.