Identity
Begin with who or what needs access, to which resource, under what conditions, and for how long.
Archive 04 · Programmable infrastructure
Cloud
Systems
Cloud engineering does not replace infrastructure fundamentals. It exposes them through APIs, policies, templates, events, and services that must still be designed, secured, observed, and recovered.
01EDGEDNS · TLS · CDN
02 · VPC BOUNDARY
PUBLICIngress · load balance
PRIVATECompute · services
DATAState · backup
03OPERATIONSLogs · metrics · events
Engineering perspectiveFrom systems to services
Infrastructure through an API
The cloud changes the controls.
Not the responsibility.
Christian brings physical infrastructure, networking, Linux, Windows, virtualization, and production troubleshooting into cloud design. That background keeps architecture grounded in real dependencies: addresses, routes, identity, certificates, capacity, failure domains, monitoring, and recovery.
His AWS learning path includes Cloud Practitioner, Developer Associate, and Solutions Architect Associate material, supported by hands-on labs in serverless processing, CI/CD, deployment automation, and command-line workflows.
Architecture domains
Design the whole workload
A reliable cloud system is the interaction of identity, network, compute, data, delivery, and operations. Optimizing only one layer creates hidden failure elsewhere.
Network
Design address space, public and private boundaries, routing, endpoints, name resolution, and controlled ingress and egress.
Compute
Select the operating model that fits the workload, then define health, capacity, patching, and failure behavior.
Data
Classify data, encrypt it, control access, choose durability and recovery behavior, and manage retention intentionally.
Delivery
Make content reachable through resilient naming, edge delivery, certificates, caching, and observable request paths.
Operations
Collect the signals needed to detect failure, explain change, respond safely, and improve the next deployment.
Design doctrine
Decisions before services
Service names are implementation choices. Start with the workload’s access, availability, security, data, operational, and cost requirements.
- 01
Identity first
Prefer short-lived credentials, roles, least privilege, separation of duties, and auditable access.
- 02
Failure is a design input
Define what can fail, what must survive, what can be rebuilt, and how recovery will be proven.
- 03
Networks are explicit
Treat routes, security groups, network ACLs, DNS, endpoints, and return paths as part of the application.
- 04
Changes are repeatable
Use versioned templates, pipelines, peer review, approvals, and automated validation to reduce configuration drift.
- 05
Observability is built in
Logs, metrics, traces, events, alarms, dashboards, and runbooks are workload requirements—not post-launch decoration.
- 06
Cost is architecture
Match resources to demand, remove waste, use lifecycle policies, and understand how data transfer changes the bill.
Hands-on record
Learning by building
and breaking the path.
The lab record connects architecture concepts to actual behavior: events entering queues, functions consuming messages, pipelines waiting for approval, and deployments moving code into controlled environments.
AWS certification pathCloud Practitioner→Developer Associate→Solutions Architect Associate
Event-driven processing
Built Lambda processing from an SQS queue and examined how asynchronous work decouples producers from consumers.
Controlled delivery
Built CI/CD pipeline exercises with a manual approval stage so promotion required an explicit decision point.
Application deployment
Worked through CodeDeploy automation and the sequence required to release, validate, and recover application changes.
Source control from the CLI
Used CodeCommit command-line workflows as part of the completed 2023 AWS lab track.
Reference architecture
A portfolio built as a cloud project
This is a reference design for a future AWS-hosted portfolio—not a claim about the Holocron’s current hosting platform.
01Route 53Authoritative DNS
→02CloudFrontGlobal delivery
→03S3 originPrivate static content
Security: keep the origin private and allow access through the delivery layer.
Delivery: version content, invalidate deliberately, and verify the public certificate and response.
Operations: treat DNS, TLS, cache behavior, and origin policy as one end-to-end path.
Diagnostic patterns
Translate symptoms into cloud evidence
Cloud consoles can make a system look like a collection of services. Troubleshooting reconnects those services into the request path the application actually follows.
A workload is reachable from the internet but not from a private subnet
Trace the effective route, security-group state, network ACLs, DNS response, endpoint or NAT dependency, and the return path before changing rules.
An application works with broad permissions but fails under its role
Capture the denied action and resource, inspect the complete policy evaluation path, and grant only the specific permission the workload requires.
A deployment succeeded but the service is unhealthy
Separate pipeline success from workload health. Validate target registration, application logs, dependencies, listener behavior, alarms, and an external transaction.
Cloud doctrine
Automate what should repeat
Use infrastructure as code to make intent reviewable, pipelines to make change repeatable, observability to make behavior explainable, and tested recovery to make resilience real.
Return to all archives →