Upstood

Multi-AZ is disaster recovery. For fires and floods. The big cloud outages are not floods. When us-east-1 went down for roughly 14 hours in October 2025, the root cause was a race condition in DNS automation. A software bug in a regional control plane. Every availability zone in the region was affected equally. Against that failure mode, multi-AZ provided zero isolation. A second region did not automatically save you either. Sign-in and parts of IAM are homed in us-east-1, so customers in other regions could not log in with federated identities. AWS's own Support Center failed over as designed, then broke anyway on a hidden dependency. And DORA, the regulation both camps cite, never mentions availability zones or regions at all. Zero occurrences in the full text. It asks something else. Per application: how long can you afford to be down, how much data can you afford to lose, and can you prove it with test evidence? Most applications tolerate hours: multi-AZ plus cross-region backups is a defensible, cheaper answer. The few that cannot need a second region with the hidden dependencies engineered out. The full breakdown, with the regulation text and AWS's own numbers, is in the first comment.

Every person who enters your VMs through Session Manager is the same person: ssm-user. Session Manager is the right way to kill public IPs on EC2. The biggest advantage: port 22 is not restricted, it is closed. Access happens over the web, a shell in a browser tab from the AWS console, with the IAM login every engineer already has. No key pairs, no bastion. An instance profile, three VPC endpoints, done. At startups we see this rolled out in an afternoon. At enterprises the same rollout stalls on one question: who did what inside the VM? Because by default, the OS-level answer is nobody. CloudTrail knows which IAM principal started the session. But auditd, file ownership, /var/log/secure: they all say ssm-user, a shared account with sudo rights. If your regulator expects OS actions attributable to a named individual, the default setup fails, quietly. It is fixable: 1. Session activity logging ties the full terminal transcript to the IAM identity (the log stream is named after the user). 2. Run As replaces ssm-user with a personal OS account, per person, even behind Entra ID SSO (session tags carry each user's own mapping through the shared role). 3. The OS account must exist first. Provision it, or domain-join. Session Manager never creates users. We wrote up the full pattern: minimum IAM policies, the three VPC endpoints, and when OS logs belong in your SIEM. Link in the first comment.

"Can you send us an IAM user and password for the audit?" If your auditor asks for that, that should be the first finding!!!. An external auditor needs access to your AWS accounts — and the first instinct in most companies is the same: create an IAM user and share the access keys, or provision a user in your identity provider to give them console access. Neither is necessary. An auditor doesn't need a login in your organization at all — API access is enough, and there's a better way to grant it. It's the same mechanism AWS partners and third-party tools have used for years: A cross-account IAM role with a trust relationship. No credentials ever change hands. We use two CloudFormation templates for this pattern — one for a single account, one for an entire AWS Organization — and we send them to clients at the start of every audit engagement. Here's how it works: 1. You deploy the template in your account — one click in the CloudFormation console. It creates a read-only role (ReadOnlyAccess + SecurityAudit, optionally billing). And because it's plain YAML, you can read every line of what you're granting before you deploy. 2. The trust policy allows exactly one AWS account to assume the role: the auditor's. Not a user, not a password — an account-to-account trust. 3. An External ID (a shared secret set as a condition on the trust policy) protects against the confused-deputy problem. Without it, the role can't be assumed. 4. Every action is temporary (STS sessions, 1-hour default) and fully logged in CloudTrail. You see exactly what the auditor looked at, and when. 5. When the audit is done? Delete the stack. Access is gone. Nothing to rotate, nothing to clean up, no forgotten IAM user with active keys waiting for the next auditor to find. For AWS Organizations, the second template scales the same pattern: deployed once in the management account, it creates the role in every member account via a service-managed StackSet — targeted at OUs, auto-deployed to new accounts, removed centrally when the audit ends. The whole setup takes about 5 minutes. The auditor gets exactly the access they need — scoped read-only, time-boxed, auditable. No credentials shared. No users created. No leftovers. Want the templates for your own environment? Comment "templates" below or send us a message — we'll get them to you. #AWS #CloudSecurity #IAM #CloudFormation #Audit

"Can you send us an IAM user and password for the audit?" If your auditor asks for that, that should be the first finding!!!. An external auditor needs access to your AWS accounts — and the first instinct in most companies is the same: create an IAM user and share the access keys, or provision a user in your identity provider to give them console access. Neither is necessary. An auditor doesn't need a login in your organization at all — API access is enough, and there's a better way to grant it. It's the same mechanism AWS partners and third-party tools have used for years: A cross-account IAM role with a trust relationship. No credentials ever change hands. We use two CloudFormation templates for this pattern — one for a single account, one for an entire AWS Organization — and we send them to clients at the start of every audit engagement. Here's how it works: 1. You deploy the template in your account — one click in the CloudFormation console. It creates a read-only role (ReadOnlyAccess + SecurityAudit, optionally billing). And because it's plain YAML, you can read every line of what you're granting before you deploy. 2. The trust policy allows exactly one AWS account to assume the role: the auditor's. Not a user, not a password — an account-to-account trust. 3. An External ID (a shared secret set as a condition on the trust policy) protects against the confused-deputy problem. Without it, the role can't be assumed. 4. Every action is temporary (STS sessions, 1-hour default) and fully logged in CloudTrail. You see exactly what the auditor looked at, and when. 5. When the audit is done? Delete the stack. Access is gone. Nothing to rotate, nothing to clean up, no forgotten IAM user with active keys waiting for the next auditor to find. For AWS Organizations, the second template scales the same pattern: deployed once in the management account, it creates the role in every member account via a service-managed StackSet — targeted at OUs, auto-deployed to new accounts, removed centrally when the audit ends. The whole setup takes about 5 minutes. The auditor gets exactly the access they need — scoped read-only, time-boxed, auditable. No credentials shared. No users created. No leftovers. Want the templates for your own environment? Comment "templates" below or send us a message — we'll get them to you. #AWS #CloudSecurity #IAM #CloudFormation #Audit

Many AWS audits stop at a list of findings.                                    We wanted to show what comes next: what an audit report looks like when each finding is connected to risk, priority, remediation, ownership, and the operational procedures needed after the audit. We published a few anonymized AWS audit report examples covering startup, enterprise, and finance environments. They include security, reliability, cost optimization, compliance evidence, backup/restore readiness, and Amazon Bedrock governance. The goal is simple: Make AWS audits more useful for the people who actually need to fix and operate the environment. https://lnkd.in/d2Hd2Nvs                                                                                                  #AWS #CloudSecurity #DevOps #WellArchitected #FinOps #Compliance #GenerativeAI  

We started using Andrej Karpathy's LLM Wiki pattern for our AWS architectures and standards, and the results have been great. Karpathy's thesis: instead of RAG re-deriving answers from raw sources every query, let the LLM maintain a persistent, compounding wiki. Humans curate sources and ask questions. The model handles the bookkeeping. We applied that pattern to AWS consulting. Every client gets their own folder inside one structured Obsidian vault. Before we write a line of CDK, the agent has already loaded: the client's architecture notes, kickoff constraints, gotchas from similar projects, and the AWS patterns we trust. The wiki is the context window. The shape of it: - Per-client folder in Obsidian — architecture decisions, account layout, compliance constraints, meeting notes, open questions. Frontmatter on every page so skills query it like a database. - Claude Code skills — small, focused workflows that read the folder and produce outputs: an architecture diagram, a decision doc, a CDK stack, an audit report. - up-cdk — our CDK construct library. Compliance-aligned building blocks, so the agent never ships bespoke infra. Karpathy's three-layer architecture maps 1:1 onto our setup: raw sources (client docs, AWS bills, meeting transcripts) → wiki (LLM-maintained markdown) → schema (CLAUDE.md that tells the agent how to operate on it). What changes for the client: 1. Architecture designs aren't a one-off PDF. They're a living page in a vault the client owns, regenerated when constraints change. 2. Per-client docs stay current. New decision → updated _status.md → the next agent run already knows. 3. Delivery speed — a full AWS audit in hours instead of days, and the output is CDK the client owns. Full writeup on dev.to — link in the first comment. No need to comment or to connect with us to get it. #AWS #ClaudeCode #Obsidian

🚀 We’ve rebranded our website — Welcome to the New Upstood We’re excited to share the launch of the new Upstood website. This rebrand marks the next step in our journey, and we’re just getting started. Take a look at the new website and let us know what you think. http://www.upstood.com #AI #Automation #Cloud #AWS #DigitalTransformation

We are pleased to announce that Upstood has released its first blockchain-registered AWS CDK templates: two CDK Atoms and our first CDK Molecule. The Atoms serve as reusable building blocks for AWS infrastructure and include templates for Lambda and API Gateway. Our first Molecule is a custom OAuth2 template, designed with modular features and flexibility in mind. As part of this launch initiative: •⁠ ⁠The first 10 clients to contact us at info@upstood.com will receive free access to the source code •⁠ ⁠Those who wish to build their own Infrastructure-as-Code platform on AWS will receive a 50% discount on the setup Special thanks to Kiril Antevski for the outstanding support and expertise in implementing our blockchain integration. Stay tuned — more building blocks are on the way, along with complex architectural components (Organisms) that will follow soon. #AWS #CDK #InfrastructureAsCode #Blockchain #DevOps #Upstood #IAC

We’re pleased to celebrate a customer success with CODE10. They’ve just shared their AWS infrastructure overhaul—delivered in close collaboration with Upstood. For more details, see their post below. From discovery to rollout, we worked as one team—aligning architecture with business goals and keeping the product at the center. The result: cleaner delivery workflows, fewer distractions from infrastructure, and a platform ready for growth. A sincere thank-you to the CODE10 team for the trust and partnership. We’re proud of what we built together and excited to see what they launch next. If your team is navigating similar AWS challenges, we’d be glad to help. 🔗 CODE10’s post: https://lnkd.in/dyiUD8cV 👉 upstood.com #CustomerSuccess #AWS #DevOps #InfrastructureAsCode #Cloud #Security #SRE #Milano

We’re pleased to celebrate a customer success with CODE10. They’ve just shared their AWS infrastructure overhaul—delivered in close collaboration with Upstood. For more details, see their post below. From discovery to rollout, we worked as one team—aligning architecture with business goals and keeping the product at the center. The result: cleaner delivery workflows, fewer distractions from infrastructure, and a platform ready for growth. A sincere thank-you to the CODE10 team for the trust and partnership. We’re proud of what we built together and excited to see what they launch next. If your team is navigating similar AWS challenges, we’d be glad to help. 🔗 CODE10’s post: https://lnkd.in/dyiUD8cV 👉 upstood.com #CustomerSuccess #AWS #DevOps #InfrastructureAsCode #Cloud #Security #SRE #Milano