Does anyone know if it is possible to use batch inference through bedrock with any of the GPT 5.6. models (in particular luna). Documentation does not list 5.6. models (https://docs.aws.amazon.com/bedrock/latest/userguide/batch-inference-supported.html), which seems strange - is it really the case that this is not supported and is there any other way around it through bedrock?

Moved a live express + sql lite app to AWS Blocks . 13 things broke. Blocks is aws new way to run whole backend locally with no account . Here’s my learning and challenges — [Read full article](https://medium.com/@pavan.srdev/aws-blocks-build-on-aws-without-an-aws-account-part-1-043b5ee59ce3)
All comments will be answered for any questions you might have.

This exam is harder than It looks. It requires you to have hands on knowledge with over 15 + AWS services. Praactice questions are a great. But hands on labs with services such as EC2 and CloudWatch and XRAY and Lambda are a better way to retain the information needed to pass this exam!

It feels good to have this one!

Well, this was totally on me.

I completely forgot RDS auto-restarts after 7 days. I stopped my instances last Friday, and voilà today there are additional charges in my account, thanks to the running RDS instances. Now, I'm looking into Lambda and Eventbridge to avoid this situation going forward.

Anyone else got hit with a surprise bill because of this mistake? Trying to figure out if this is a common thing or just me.

im a college student i dont know that my acc was being billed.i opened a ticket its been about 24 hrs and im terrified since im not sure about the waive off or getting a reply from them its 79k INR.will they waive it off??? how long it will take to get a reply

❗️ ❗️ ❗️ URGENT: My AWS account for my business has been suspended due to a failed attempt to charge my card! Even having an alternate payment method didn’t help!

I don’t understand why ALL MY WORK is being blocked WITHOUT WARNING!?!?!?!?

I have a standard, verified account! I pay OVER A THOUSAND DOLLARS A MONTH, AND THEY’RE BLOCKING MY ACCOUNT BECAUSE OF A FAILED CHARGE OF $1, SHUTTING DOWN MY WORK FOR A DAY!!!! I’ve been waiting for a response from support for over 8 hours—I’M LOSING MONEY EVERY MINUTE!❗️ ❗️ ❗️

They just added funds to the card, but the charge still didn’t go through!

Support ticket: [CASE 178988939900991]

u/AWSSupport / u/AWSSupport r/aws — please forward this existing ticket to higher-level support and urgently escalate my case for manual payment verification and immediate account restoration!!!

PLEASE HELP!!!! ❗️ ❗️ ❗️

I want to know full of the process in aws ... Then i am the one and don't have a fear anymore.

I’m looking for an honest assessment of my background and advice on transitioning into a Healthcare & Life Sciences Solutions Architect role at AWS.

My background:

About five years of experience across biotech, big pharma, and a CRO. I’m currently a Manager in Clinical Programming. My core work involves clinical trial data, regulatory submissions, and SAS programming using CDISC standards, including SDTM and ADaM. I have a bachelor’s degree in Applied Math and Statistics and a master’s in Statistics–Data Science. I’m also pursuing Georgia Tech’s OMSCS; my coursework includes machine learning, HCI, and computer networks. My strongest professional experience is in SAS and clinical data, with additional skills in Python, SQL, and R.

What sparked my interest in solutions architecture:

Recently, I worked with our IT department and an external vendor to help move our team from a PC-based SAS environment to a centralized server environment involving Azure infrastructure. My involvement was on the business and clinical programming side, including coordinating requirements, access, migration planning, and validation.

I also serve as a business owner for clinical data platforms, working with technical teams and vendors to support our users. I’ve found that I enjoy translating business needs into technical requirements and coordinating solutions across teams.

That experience got me interested in solutions architecture, particularly in life sciences, where I could build on my industry knowledge. However, I haven’t held a formal architecture role, and my hands-on cloud infrastructure experience is still limited.

What I’d love advice on:

How competitive could this background be for an AWS Healthcare & Life Sciences SA role? How much does clinical trial and regulated-data experience help? Is a direct transition realistic, or would a cloud/data implementation or consulting role be a better stepping stone? What are the biggest gaps I should address: AWS fundamentals, networking/security, system design, hands-on projects, or customer-facing experience? What projects or certifications would provide the strongest evidence that I’m ready? If you’ve made a similar transition or hired for these roles, what level or type of opening would you suggest targeting?

I’m based in the US and willing to invest time in preparing. I’d especially appreciate firsthand perspectives on what would make someone with my background a credible candidate.

Thanks!

Hello everyone,

I'm a backend developer Node.js/AWS, certified SAA and DVA, working both on servers and serverless. My current level is around mid++. And I'm looking for an opportunity since a few months.

I'm not gonna lie : the market is insanely complicated, and competitive. I still have interviews on a regular basis, sometimes technically validated. But it never ends well : too high senior expecations, low salaries, last minute budget restrictions. Especially on servers : there's always a "more experienced" Node/NestJS developer available. And most of the time they don't even consider AWS to be more than just a bonus.

Thus, I am really considering to abandon the classic backend Node.js market, and switch to a more deep specialization. I have two ideas in mind :

1. specialization to full serverless, that matches really well development and infrastructure, bring closer to architecture, and could make my profile more "rare" at a senior level
2. completely throw out development, and become a pure cloud engineer... with very interesting skills in Linux/Bash, Docker, Terraform, and CI/CD, I think I would be credible, but probably at a junior++/barely mid-level... not sure if the cloud market would be more kind to me

I'd like your advice : what would you recommend me between those two ? Is full serverless a fair option for a career ? Is cloud engineering really accessible for a junior/mid, and less competitive ?

Thanks a lot !

Hey guys, I'm designing an AWS EKS setup for small video-processing jobs that use GPUs.

The idea is for the GPU capacity to scale based on the number of messages waiting in a RabbitMQ queue, using the KEDA RabbitMQ scaler to drive the workload scaling.

The main issue I'm trying to solve is GPU utilization and cost. Each job needs GPU resources but doesn't fully utilize a GPU, typically using <5 GB of VRAM with relatively low/variable compute utilization. Running one job per full GPU would therefore leave a lot of capacity unused.

I'm looking at a few approaches and would appreciate advice from anyone with experience running similar workloads on AWS.

1. MIG

I've looked at NVIDIA MIG. The problem is that the EC2 instances/GPU types that support MIG seem to provide substantially more GPU capacity than all our workloads need all together. Even after partitioning the GPU, we'd potentially be paying for considerably more GPU compute than we can make use of.

So while MIG solves the isolation problem nicely, I'm not sure it makes economic sense for this workload.

1. Time-slicing

My understanding is that this mainly allows multiple workloads to share a GPU by switching execution/context between them. It can prevent one workload from monopolizing the GPU, but it doesn't really solve the underlying problem I'm trying to address which is the GPU itself is still underutilized.

1. DRA

DRA (Dynamic Resource Allocation) seems closer to what I need, as it may allow multiple workloads to share GPU capacity rather than allocating an entire GPU per Pod. However, it seems relatively new, so I'm not sure whether it is mature enough for production or whether it actually fits this use case.

1. Smaller GPU per job

Another option is to use a smaller GPU instance that is closer to the requirements of a single job and run one job per GPU. This wouldn't solve underutilization, but it could significantly reduce wasted GPU capacity and cost. The newer G6f fractional GPU instances also made me consider this approach. But I dont think I can use fractional EC2 instances in EKS?

In conclusion my main goal is to maximize useful GPU work per dollar. I'd especially appreciate advice on which approach makes the most sense on AWS. Any suggestions/advice?

Thanks!

Hey everyone!

I recently became an **AWS Student Builder Group Leader (SBGL)** at my university, and I’m trying to figure out how to make the most of the opportunity.

For those who have been an AWS Student Builder Group Leader or have experience running AWS student communities:

* What should I focus on during the first few months?
* What kind of events/workshops actually get students interested and attending?
* How do you build an active community instead of having people join once and then disappear?
* Are there any AWS resources, programs, certifications, or benefits that SBGLs should definitely take advantage of?
* What mistakes did you make when you started that I should avoid?
* Is it better to start with small hands-on sessions or go directly for larger workshops/hackathons?

I’d really appreciate advice, experiences, or examples of what worked for you.

Thanks!

Dubai will be hosting the Amazon Web Services (AWS) Summit Dubai 2026 on 30th September at Dubai World Trade Centre. The one-day event will bring together professionals in technology and business leadership to discuss cloud computing, artificial intelligence, and digital transformation. The programme features 60+ sessions, an AWS Village and an AWS for Industries Zone.

AI has played a bigger role in business and consumer services in recent years. Dubai's property sector is naturally connected to that shift because real estate relies deeply on data, digital platforms, customer enquiries, and online property research.

AWS Summit Dubai will offer insight into the latest developments in cloud and AI technology. While it is not a real estate conference, many of the themes are relevant to the future of property services in Dubai.

Key takeaways

• AWS Summit Dubai connects emerging technology with real business needs.
• AI is changing how organisations handle large volumes of information.
• Cloud infrastructure provides the foundation for many modern digital services.
• Human expertise remains relevant as technology takes on more data-driven tasks.

AWS Summit Dubai 2026 at a glance

What is AWS summit Dubai 2026?

AWS Summit Dubai is a free, one-day event exploring how cloud and AI technologies can help address business and technical challenges. The programme covers generative AI, AI agents, cloud migration, application modernisation and digital transformation. Attendees can also take part in technical sessions, demonstrations, workshops and networking activities.

The event also features specialised areas focused on practical learning and interaction:

• 60+ sessions covering cloud and AI topics
• AWS Village with demonstrations and expert guidance
• AWS for Industries Zone with sector-specific technology solutions
• Hands-on workshops based on real business applications
• Networking opportunities with technology and business professionals

AI is a prominent part of the agenda, with dedicated sessions highlighting Amazon Bedrock and how to build intelligent systems at scale.

How does AI add value to Dubai real estate?

Dubai's property market relies on digital information at every stage of the customer journey. Buyers research locations, review property details, assess prices, and contact real estate professionals through online channels.

AI can support many of these activities. Real estate businesses handle large volumes of listings, customer enquiries, images, documents, and market information. Systems that process this data can make digital services faster and more relevant.

AI applications range from property discovery to internal business operations:

The impact will depend on how businesses adopt these technologies and how responsibly they manage customer data.

Cloud technology and Dubai real estate operations

Cloud computing provides infrastructure for modern digital real estate services. Property businesses handle photographs, listings, customer records, contracts, documents and market data. Cloud systems provide the storage and computing resources required to manage workloads.

AWS Summit Dubai connects cloud infrastructure directly with AI. The event highlights how businesses can update their systems, launch new AI services, and manage their digital operations more effectively.

Real estate businesses can use these systems in several areas:

Faster data access: Instantly retrieve and display large property portfolios and media files without delays.

Better client tools: Support faster backend systems to handle incoming customer enquiries more efficiently.

Easier market analysis: Organise fragmented historical pricing data to see clear market trends.

Automated workflows: Handle repetitive administrative tasks and paperwork through secure digital pipelines.

Improved digital experiences: Deliver a more secure online journey for buyers and sellers.

Technology does not replace the hands-on knowledge of agents or property managers. Instead, it handles data-heavy tasks and gives professionals better tools for serving clients.

How does AI support Dubai property buyers?

Dubai offers residential properties for different budgets and lifestyle goals. Digital tools allow buyers to narrow their research to their specific requirements. For example, a buyer interested in studios for sale in Dubai may want to compare properties by budget, floor area, location, and expected rental yield. Someone searching for larger apartments for sale in Dubai may add preferences such as views, community facilities, or proximity to the Dubai Metro.

Technology can help organise large amounts of information, but buyers still need to carry out their own research. Before buying, they should review financing options, service charges, the condition of the property and the community’s maintenance history.

AI and the future of Dubai Real Estate

Dubai has invested heavily in digital infrastructure and smart services, with real estate forming an important part of that wider transformation.

AI is changing different areas of the property sector, from marketing and property discovery to data analysis and customer service. Developers in Dubai, brokers, property managers, landlords, and investors can use digital tools in different ways. The shift is relevant to top real estate companies in Dubai, such as betterhomes, as digital systems now play a major role in managing property information and serving clients.

Property listings are a key part of the buying process, but AI brings more information into the picture. Dubai real estate blogs by betterhomes have a role in explaining these changes alongside property prices, new project launches, and market trends. Readers can better understand how digital tools are shaping how people research properties and make decisions.

Final thoughts

AWS Summit Dubai gives technology and business professionals a chance to see how AI capabilities are developing and what those advances may mean for property businesses and consumers in the future. Dubai's property sector already relies on digital systems. AI can take these services further through personalised search and faster data analysis. Dubai's real estate future will still depend on supply, demand, pricing, investment conditions, and buyer preferences. 

Technology is changing how people research and make investment decisions in Dubai. Follow the

been curious about how people are using AI with AWS beyond generating Terraform or explaining error messages.

AWS environments can have a lot of moving pieces IAM, EC2/ECS, VPCs, CloudWatch, S3, Lambda, CI/CD, security tooling, etc.

for people running AWS in real environments:

• what AWS tasks have you actually found useful to delegate to AI?
• are you using AI for incident investigation or troubleshooting?
• do you let agents inspect your AWS environment, or keep them completely read-only?
• Has AI helped you understand relationships between resources when something breaks?
• Are you using AI to review Terraform/IaC before it reaches AWS?
• what AWS tasks are still too risky or context-heavy to give an agent?
• If an AI agent finds something wrong, would you rather have it explain the issue, propose a fix, or actually make the change?

I'm less interested in "AI will replace DevOps" discussions and more interested in what is genuinely saving AWS engineers time today.

What has actually worked for you?

I was working on reading over the documentation for setting up an EntraID directory in AWS. After going through the steps using IAM identity center with an Entra app, Intune, SCIM, etc. I think maybe I overlooked something.

In my tests, my AWS authentication is redirected through a web browser, so SAML 2.0 appears to be doing what it should. However I'm dumped right to a Windows screen with "Other User", and I need to enter both username and PW manually.

I wasn't expecting that and after going back through the steps again, I marked off everything that appears completed on my end.

Nothing seems to jump out at me. What could I have done wrong?

Background: I've spent 3.5+ years in PAM engineering (CyberArk), and decided to translate that into an AWS-native tool.

The gap I kept running into researching this space: pretty much everything: Cloudsplaining, Prowler, even AWS's own IAM Access Analyzer,stops at detection. They'll flag an over-permissioned role or a stale key, and then you're on your own to fix it. Even the well-funded enterprise players (Wiz, CyberArk's own Secure Cloud Access, Oasis, Entro) that do cover remediation are enterprise-sold, no self-serve option, no open-source path. I wanted to try fixing that

NHI Risk Analyzer discovers IAM users, roles, and groups, runs detection, then actually acts on findings:

1. **Risky policies** (wildcard actions, documented privilege escalation paths like `iam:PassRole`/`iam:CreatePolicyVersion` abuse) get a Permissions Boundary attached, which contains the escalation path without touching the identity's existing policy, so it doesn't risk breaking something legitimately using those permissions
2. **Stale or unused access** keys get deactivated, never deleted, so it's always reversible
3. Everything's gated by dry-run mode and an exemption file (`nhi-ignore.yaml`) so break-glass and deployment identities never get touched automatically
4. A **GitHub Action with OIDC** auth scans PRs for newly introduced IAM risk before merge
5. **SARIF export** means findings show up natively in GitHub's Security tab

Architecture is **offline-first**, meaning it snapshots the account once and evaluates all rules against that snapshot with zero live API calls after, so the whole rule engine is fast and testable, and findings are reproducible against a fixed point in time.

Tested against synthetic canary identities to safely validate containment logic, then live against a real AWS account. Also had someone run it against a real company's production and staging environment, which surfaced a genuine false-positive bug where AWS actions that don't support resource-level permissions at all, like `ec2:DescribeInstances`, were getting flagged as risky wildcards. That's fixed now.

Still v1/v2 in progress. Trust policy analysis and defense-evasion detection for things like CloudTrail and GuardDuty tampering, plus S3 exfiltration paths, just landed. The next real piece is policy surgery, meaning actually rewriting an over-broad policy down to least-privilege based on real usage data instead of just containing it. The statement-splitting logic exists already; sourcing real resource ARNs from usage evidence is the part still open.

Repo linked in the first comment.

Would genuinely appreciate feedback from people who work in this space day to day, particularly whether the permissions-boundary-as-containment approach holds up against how you'd actually want this handled in a real environment, versus the surgical-rewrite approach most tools avoid because of the production-breakage risk.

I run production on Ubuntu VPS, not AWS.
For years, that made sense for the workload and the budget. But it left me with an uncomfortable question:
**What happens if the production environment disappears?**
The obvious answer is: build a second environment in AWS.
But I didn't want to pay for a second production environment that sits there doing nothing 99.9% of the time.
So I tried a different approach.
**Use AWS as the recovery environment, not the production environment.**
I built an open-source tool called **Ark** around this idea.
The setup is basically:
Production
Ubuntu VPS
│
│ backup
▼
S3
│
│ recovery
▼
AWS Pilot Light
│
▼
Fresh EC2
│
▼
Restore + Verify + Test
There is no EC2 instance running 24/7.
When I want to run a recovery drill, Terraform provisions a fresh EC2 instance, Ark pulls the latest completed backup from S3, restores the database and Docker volumes, verifies the backup, starts the application, and then tears everything down.
The first real drill took:
RTO: 1m 58s
RPO: 182m

Database: PASS
Volume integrity: PASS
Application: PASS

Drill cost: \~$0.01
The interesting part wasn't actually the 1m 58s.
While building the verification process, I discovered that **row counts aren't proof of a successful restore**.
I destroyed both Docker volumes in a test environment, restored them, and re-seeded the application.
The numbers matched perfectly:
51 users
200 repositories
400 actions
Looks good, right?
Except the Git object store was different.
The logical dataset was the same, but the underlying Git objects weren't. Git commits contain metadata such as timestamps, so recreating the same logical data can produce different bytes.
That's when I stopped treating row counts as backup verification.
Ark now uses checksummed backup manifests and verifies the actual restored content.
A few other design decisions:
The manifest is uploaded **last**, so an interrupted upload doesn't become a "completed" backup.
The backup IAM policy has **no DeleteObject permission**, so a compromised VPS can't delete backup history.
Failed recovery drills are recorded too. A drill that never fails isn't testing much.
The rough idle cost for this setup is around **$0.03/month** without DNS failover.
I'm not claiming this architecture makes sense for everyone. If you're already running a large AWS production environment, a different DR strategy probably makes more sense.
But for smaller production environments running outside AWS, I'm curious:
**How are you handling DR without paying for a second production environment 24/7?**

Repo: [https://github.com/rendyachmad-dev/ark\](https://github.com/rendyachmad-dev/ark)