OSIRIS JSON for Amazon AWS #6
skhell
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The OSIRIS JSON producer for Amazon AWS is now available as v0.1.0. It collects over 60 resource types across all major AWS service categories like networking, compute, data services, storage, security, and identity, emitting a single portable topology document per region.
The challenge has never been a lack of AWS data, the modern challenge is that the architectural truth of an AWS environment is spread across accounts, regions, VPCs, subnets, security boundaries, managed services and service-specific APIs that are difficult to retrieve and translate in an end-to-end document report and topology view at a single point in time. The OSIRIS JSON producer for AWS turns that fragmented view into one portable topology document that can be validated, reviewed, diffed, and reused outside your AWS infrastructure.
What OSIRIS JSON producer for AWS v0.1.0 collects
The producer is organized around several collection phases that run per region. Global resources (Route53, CloudFront, Global Accelerator, IAM, OIDC, and SAML providers) are automatically merged into the
us-east-1document.Your AWS infrastructure report and topology needs structure not just inventory
The OSIRIS JSON producer maps AWS resources directly to the OSIRIS JSON specification type taxonomy.
For example:
compute.vmcompute.function.serverlessapplication.databaseapplication.cacheapplication.queueapplication.eventstreamnetwork.vpc,network.subnet,network.security.groupand so on.Resources that have no direct OSIRIS JSON specification equivalent live in a dedicated AWS
osiris.aws.*namespace following the OSIRIS JSON specification guidelines. This includes route tables, NAT gateways, Transit Gateway hierarchies, and service-specific constructs that are meaningful inside AWS but do not have a direct portable equivalent in the core spec.Boundaries like VPCs, subnets, availability zones, and accounts are not secondary metadata—they are fundamental pillars of the AWS architecture itself. The OSIRIS JSON producer represents these boundaries through native groups, provider metadata, and explicit relationships without locking the document into AWS-only semantics.
Deep visibility without losing AWS-native meaning
The OSIRIS JSON producer preserves AWS-native details alongside the portable OSIRIS JSON model. Each resource carries provider metadata using CloudFormation type names (such as
AWS::EC2::VPCorAWS::Lambda::Function) and the underlyingaws-sdk-go-v2source identifier.When run with the
--purpose auditflag, the producer emits full resource properties: instance types, private and public IPs, engine versions, storage sizes, backup retention settings, VPC configurations for Lambda, memory/timeout settings for functions, DynamoDB key schemas, and similar fields. In contrast, the default documentation mode strips these deep configuration properties before emission, preserving only the clean topology structure.The special
--include-raw-bodyflag (available in audit mode) attaches the full, raw AWS SDK response JSON for key resource types underextensions["osiris.aws.sdk"].body. This gives consumers the complete source record without losing the benefits of OSIRIS JSON normalization.Topology became more than just a flat resource list
The OSIRIS JSON producer for AWS captures over 40 explicit connection types. The relationships between these components are what separate a true topology snapshot ready for draw.io or mermaidJS from a simple flat service inventory:
These connections represent the actual, living AWS architecture topology.
High quality documentation and topology matters even more in hybrid and multi-cloud designs
The AWS story becomes even more vital when your architecture does not stop at the cloud boundary.
The OSIRIS JSON examples already show AWS participating in both multi-hyperscaler and hybrid scenarios, demonstrating AWS resources tied logically to Microsoft Azure services. For Solution Architects this is a core use case that will become fully achievable with the OSIRIS JSON consumers (currently under development). You do not just want to know what exists inside AWS; you need to understand how AWS fits into your entire ecosystem for true end-to-end visibility.
An application tier in AWS, a database in Azure, or an on-premises dependency in a private data center connected via VPN should still be documented and viewed as a single, cohesive distributed architecture, not as disconnected list of service inventories.
The OSIRIS JSON producer contract
The AWS producer strictly follows the foundational OSIRIS JSON producer contract:
Permission-denied errors from restricted IAM roles are handled gracefully—they are logged at the debug level and will not abort the collection run. Cross-account resources that are reachable by reference but outside the scope of the current profile are cleanly emitted as stubs with a
cross-accountstate.Operating modes
The OSIRIS JSON producer for AWS supports four execution modes: single-region, multi-region (covering 17 default AWS regions), CSV batch mode for multi-account pipelines and an interactive CLI picker when no flags are passed. AWS IAM Identity Center (SSO) authentication is handled smoothly through an OIDC device flow subcommand.
Read the related docs
Beta Was this translation helpful? Give feedback.
All reactions