CA-09 Internal System Connectionsca-9

CA-09 has four elements and this output serves parts of two of them. The part it holds: which internal connections exist. Every plane on which one component of the system reaches another leaves a resource behind — a peering connection, a Transit Gateway attachment, an endpoint, an endpoint connection, or a security-group rule that names another group instead of a CIDR — and five calls enumerate them completely for a Region. That enumeration is worth having on its own: it is the list the control's documentation requirement is written against, and most providers do not have it. What it does not hold is everything CA-09 asks you to record about each connection. The interface characteristics, the security AND PRIVACY requirements agreed for the connection, the nature of the information communicated, and the authorization to connect at all — none of them is a field. Two further elements of the control are not addressed here at all and should not be read as covered: terminating internal connections when the stated conditions are met, and reviewing the continued need for each connection on a stated frequency. The second of those is the one this inventory most nearly serves — a continuously collected enumeration is the substrate a periodic review runs on — but the review itself is a decision with a date and a reviewer, and none of that is in the response. They live in an interconnection agreement or an internal approval record, and the reconciliation of that record against this inventory is the CA-09 artifact. This recipe produces the column you reconcile against, which is why it is partial and why no assertion below claims more than attachment and state. Read every one of these lists as a history rather than an inventory. Peering connections persist in the response with Status.Code deleted, rejected, expired or failed; Transit Gateway attachments persist as deleted, failed or rejected; endpoints persist as Deleted or Rejected. A count taken over the raw response counts connections that do not exist, and — the direction that actually matters — a clause of the form 'every connection carries an authorization tag' evaluated over the raw response is answering about the dead ones too. Every assertion here is therefore narrowed by state, and the narrowing is the assertion. The completeness clauses are written as OFFENDER LISTS — a filter that selects the rows which fail, asserted to be empty — and not as 'every connection carries a tag'. This is not a style preference. A field projection over a list drops the rows where the field is absent instead of reporting them as false, so an every-row clause of the obvious form evaluates only the rows that already comply and is green on an estate where half the connections are untagged. The offender form was verified against synthetic responses before it was written down. The vacuity to state plainly: all five lists are empty on an account that has none of these, and an every-entry clause over an empty list is true. This evidence cannot distinguish 'no internal connections' from 'no connections in THIS Region' from 'the collection ran with a role that cannot see them'. Record the Region set the collection covered beside the output, because every one of these calls is Regional and nothing in the response says which Region produced it. Two directions, and only one of them is intuitive. Four of the five calls show what this account reaches OUT to. describe-vpc-endpoint-connections is the other direction — it is the provider-side view of who has connected IN to an endpoint service you publish — and a pendingAcceptance entry there is a connection request nobody has adjudicated. The same is true of a peering connection in pending-acceptance: an unaccepted request is not yet a connection, but it is a decision someone owes, and it belongs in the review the KSIs describe as persistent rather than in a quarterly surprise. OwnerId and ResourceOwnerId are what make 'internal' checkable at all, and they are also the join this grammar cannot do: deciding whether a peer account is inside the authorization boundary means comparing OwnerId against your own account list, and an assertion compares a field to a constant. Write the boundary's account set into the assessment and reconcile by hand; a tag naming the authorization record is the closest a field gets, which is what the assertions ask for. Security-group rules are included for a reason worth stating: they are the only one of the five that shows a connection with no resource of its own. A rule whose ReferencedGroupInfo names another security group is one component permitted to reach another by identity, and it is invisible to any inventory that looks only for peering connections and attachments. Description is free text and no AWS call validates it, so treat the description assertion as a documentation-completeness check rather than as evidence about the connection itself.