The advent of generative AI spurred an enormous and controversial datacenter building boom that has seen almost anyone who knows how to run a bit barn try to expand their business ASAP. Fujitsu, however, wants out. The Australian outpost of the Japanese giant’s business this week announced the sale of five datacenters down under. The company said selling the bit barns “enables us to further invest in the technology services where customer demand is growing fastest.” In Australia, that apparently means “helping organisations modernise critical systems, strengthen cyber resilience, adopt sovereign AI, and access the high-performance and quantum computing capabilities needed for their next phase of transformation.” Fujitsu said its datacenter business “is a strong platform, and its next phase will benefit from dedicated commercial ownership and investment.” That new owner, private equity outfit Next Capital, may have its work cut out for it because some of the bit barns it bought appeared to be rather modest. Fujitsu’s manifest of its Australian properties lists one facility capable of hosting 92MW worth of kit, another with 28MW capacity, plus bit barns that can host 10MW, 4.8MW, 3MW, or 2MW worth of kit. Keen-eyed readers will have noticed that the paragraph above mentions six datacenters and that earlier in this story we said Fujitsu is selling five. The Register understands Fujitsu has already disposed of the other one to another buyer. Whatever Next Capital bought, it will surely be aware that a modern rack filled with AI kit can require 500KW or more. Fujitsu Australia’s littlest datacenters therefore won’t help the private equity company to catch the AI wave unless it invests in upgrades – a process that might be cheaper than building new AI-ready datacenters from scratch and could also involve fewer regulatory complications than greenfield builds. Next Capital was quiet about its plans, but shared a local media report suggesting it’s spent AUD$200 million ($139.97/£104 million) to do the deal. The firm promised continuity for tenants. Fujitsu Australia’s services business won plenty of blue-chip and government clients, and The Register understands many are long-term residents of the offloaded datacenters. Next Capital can probably therefore bank on solid cashflow for months or years to come. Fujitsu sold its US datacenter business in 2023 and at the time hinted at divestments elsewhere. The company has also “absorbed” its Japanese public cloud and quit the mainframe business. The Japanese giant plans to return to the big iron business with machines built on the Monaka CPU which it hopes to deliver next year, and perhaps also get into the quantum computing biz. ®

Iran's Islamic Revolutionary Guard Corps (IRGC) claims it hit an AWS datacenter in Bahrain months after taking it offline for the first time, in a move it claimed as retaliation for a US attack on a nuclear plant that was under construction. The IRGC said in a statement on Tuesday that it had struck back at what it called the "child-killing US Army" by attacking Amazon infrastructure in Bahrain, claiming AWS's "central data infrastructure" had been "destroyed" after being hit by "several cruise missiles," according to Google Translate. The IRGC said the claimed strike was retaliation for what Iran described as a US attack on the under-construction Darkhovin nuclear facility. A look at the AWS Health Dashboard shows that there are definitely issues in Bahrain and the UAE, with issues in both regions being blamed on the US-Iranian conflict. While the status of AWS me-central-1 (UAE) is just “unable to reliably support customer applications,” me-south-1 (Bahrain) is said to be “currently unavailable.” The last update to the state of AWS services in Bahrain and the UAE in the open issues area of the Dashboard was on April 30, and the Service History tab shows that every single AWS service in Bahrain has been offline for months. Per our previous reporting, Iranian state-affiliated media claimed that strikes on AWS infrastructure in Bahrain and the UAE were deliberate, after US and Israeli attacks on Iran in late February. AWS-hosted providers including Snowflake and Red Hat subsequently urged affected customers to fail over or move workloads to other regions after the facilities were damaged. AWS waived all usage-related charges for March 2026 in its me-central-1 region in the UAE following the attacks on its infrastructure. Iran has also reportedly designated facilities associated with Google, IBM, Microsoft, Nvidia, Oracle, and Palantir as legitimate targets for retaliatory strikes, citing their alleged support for US military operations. The fact that services in Bahrain have been unavailable for months, and continue to be offline, makes it challenging for El Reg to confirm the legitimacy of Iranian claims it hit the site again. We’ve reached out to AWS to learn more, but didn’t hear back. ®

Google Cloud last week experienced an outage that analysts say demonstrates that not all promises of cloudy resilience are created equal. Google’s incident report explained that three services – the VMware Engine (GCVE), NetApp Volumes, and Bare Metal Solutions (BMS) – experienced a 15-hour outage due to a cooling failure in its europe-west4-a zone. The report includes the following detail: “The datacenter serving europe-west4-a for GCVE, BMS, and NetApp has experienced a power failure, which subsequently caused a cooling failure.” The important detail there is that Google uses a discrete datacenter for those three services. Another notable element of the incident report is the admission that “An electrical fault occurred on the utility grid upstream of the datacenter, disrupting the electrical distribution gear and cooling equipment.” Google hasn’t explained how an upstream failure caused that disruption but did say it “proactively turned down workloads in order to protect customer data from any risks posed by running infrastructure in a high temperature environment.” Whenever your correspondent talks to hyperscalers or datacenter operators about how they ensure resilience, they tell me about their use of multiple redundant pieces of energy infrastructure, plus on-site generation capabilities that can keep a datacenter powered for days if necessary. We’ve asked Google if it had generators or other energy sources at this site, and if so, why it nonetheless had to turn down workloads. We’ve not received a response at the time of writing. Google told us its incident analysis “is currently ongoing” and promised to follow up once it is available. Hidden dependencies We also asked Google if it advertises the fact that some of its services are tied to a single datacenter, a matter of interest because like other hyperscalers it divides its cloud into “regions” that typically comprise multiple “zones” spread across a city or other locale. Like its hyperscale peers, Google recommends placing workloads across different zones and regions to ensure resilience. Yet this incident shows some services can be tied to a single datacenter in a zone – and that those single datacenters can experience problems while the rest of the zone keeps working. Analysts told The Register the outage shows organizations need to dig into clouds’ promises of resilience. “The real issue is transparency: customers are generally told to use multiple zones and regions for resilience but are rarely given visibility into whether a particular managed service has a single-datacenter dependency within a zone,” said Biswajeet Mahapatra, principal analyst at Forrester. “As a result, many organizations assume the cloud abstraction provides more facility-level redundancy than may actually exist for specialized services." “The underlying architecture is not necessarily unusual,” he added. “AWS, Azure, and Google all operate services that rely on dedicated hardware, storage platforms, or tightly coupled infrastructure that may not be distributed across multiple facilities in the same way as core compute and storage services.” Gartner Director Analyst Adrian Wong reminded The Register of the 2023 outage at Google Cloud’s europe-west9-a region, the cause of which was a water leak that Google said “originated in a non-Google portion of the facility.” Google uses a tool called “Spanner” to replicate data across zones, but in the flooded zone Google’s Spanner configuration didn’t work once one building became unavailable. “It is very hard to figure out how an individual region is architected,” Wong said. “Our customers are often surprised by that,” he added. The incident report for last week’s outage includes an apology. “We know how much you rely on Google Cloud, and we regret the impact on your productivity,” the document states, before promising a final incident report will detail “preventative actions.” But as this incident shows, knowing how Google plans to avoid future incidents of this sort won’t arm customers with the knowledge to understand if those mitigations will address hidden design issues that can reduce resilience. ®

Nothing can ruin the end of a week like finding out that all of the websites and hosted email you’re responsible for are offline, which is exactly what happened to Christopher Bradbury and his web design and development firm, Digital Takumi last week. AWS has since resolved the situation, but Bradbury's mistakes can serve as a useful lesson to others of what not to do. As Bradbury explained to The Register in an email, he noticed last Thursday, July 16, that all the websites and Google Workspace email accounts connected to domains he manages were offline. All of those sites are hosted through Route 53, AWS’ combined DNS/hosting service, and none of them were resolving. Bradbury went digging through his emails to figure out if there was anything to point to the failures, and sure enough: In his spam folder were numerous messages from AWS telling him a payment card on file had expired, and warning him that the account used to host all those customer websites through Route 53 was going to be suspended unless he took action. He didn’t obviously, because he didn’t realize there was an issue. “AWS had been sending billing notifications, but unfortunately they had been filtered into a spam folder and, in some cases, were being delivered to an employee who had since left the business,” Bradbury told us. “I accept responsibility for missing those notifications,” he added, but that didn't help his customers' websites get back online. The situation could have been resolved sooner, but Bradbury had made some other mistakes as well: “The root account had MFA enabled using a software authenticator that had been stored on an older laptop which has since suffered a motherboard failure,” Bradbury explained. Without access to that authentication code generator, he was unable to get into the account. Rather than getting the dead-laptop-with-a-critical-authenticator-on-it problem resolved, he was just relying on MFA emails instead – not the best idea. "I've been bypassing the device key for quite a while by just using the recovery MFA via my email," Bradbury told us. "It works, I get access. However if I just had my Passkey up to date it would have let me right in and I could have solved this." And then there was the email address where those MFA codes were going: “The AWS recovery process required email verification using the registered root email address,” Bradbury told us. “That email address belonged to one of the domains whose DNS was hosted in the suspended AWS account, meaning I couldn't receive the verification email.” The account recovery tango Bradbury’s next option was contacting AWS from a different email address, which didn’t go anywhere. He created another AWS account and purchased business support access on someone’s recommendation, but the support engineers he spoke to using that method wouldn’t discuss the other account until he verified he owned the one in question. “Over the following days I spoke with several AWS teams, including Billing and Account Recovery. I was transferred between teams multiple times, but nobody was able to complete the ownership verification or restore access to the account,” Bradbury told us. He wanted to pay AWS, Bradbury told us, but it took a while for them to be able to take his money. “The practical consequence is that I cannot log into the AWS account, cannot receive email at the registered root address, cannot access the MFA device, cannot update the expired payment method, and therefore cannot pay the outstanding invoices from inside the account.” While we were working on this story, after speaking to both Amazon and Bradbury, he contacted us to say that access to the sites had been restored, and that he had logged in, paid the back invoices, updated his payment method, reset his MFA keys, and generally taken care of all the stuff he had been putting off until all this happened. It's unfortunate that someone has to go through AWS billing hell to serve as an example to others, so let this be a warning to anyone else managing client websites through AWS. "Firstly pay your AWS bills," Bradbury said in an email, adding that anyone running an AWS hosting account also makes sure their emergency recovery email isn't on the same domain as one of the sites they manage through that profile. That, and "stop using shortcuts" when it comes to MFA. "This isn't a big infrastructure account, we run a single company marketing website and some domains through Route 53," Bradbury explained. "It just shows that even the most modest instances of AWS can be absolutely business critical and you need to use proper practices and processes." ®

Your AWS billing estimate might look just a little inflated right now. If you woke up to find an email from Amazon Web Services this morning telling you that you’d gone over your billing threshold by a few hundred million dollars, don’t panic: Something’s gone wrong in the AWS Billing Console, the company admitted. An open issue on the AWS Health Dashboard (archived copy at the time of writing) popped up at 1:33 am Pacific time on Friday informing users that Cost Explorer was “reflecting inaccurate estimated billing data.” As of writing, the issue is still unresolved despite AWS trying several different things to get it fixed. The company apparently identified the root cause within an hour and a half of beginning its investigation, only describing it as “an issue with unit pricing within the estimated billing computation subsystem.” AWS followed up by pausing estimated bill updates, saying customers would continue to see the inflated figures already displayed, but that those estimates would not increase further. “The displayed billing estimates do not reflect actual usage and charges,” AWS explained, noting that customers don’t need to take any action, like, we imagine, flooding the help portal with tickets telling them what they already know, for instance. “Once the issue has been mitigated, we expect full resolution to take multiple hours as we work through recomputing the estimated billing data,” AWS added. After we first published this article, Amazon updated the issue page to indicate that it had identified the root cause and mitigated the underlying issue. The company says that it's begun backfilling data in the Cost Management Console to correct billing numbers, and that all customers should see corrected amounts by Saturday, July 18 at noon pacific time. We owe HOW much? Users took to Reddit and Hacker News this morning to report they’d received overage emails for massive amounts - we weren’t exaggerating with that hundreds of millions opening line. If anything, it was an understatement. Screenshots posted in the Reddit thread showed one user whose AWS charges totaled just $0.19 last month receiving an estimated bill of nearly $2.5 billion. Others in the thread claimed to have received estimated monthly charges ranging from $126,000 to as much as $2.5 trillion. Hacker News users similarly reported estimates in the billions. Amazon said the figures shown in customers' accounts were inaccurate estimates rather than actual charges. As for when users might see their billing portal reflect an accurate number, that could take a while. AWS declined to explain the issue aside from pointing us to the dashboard page linked above. We'll be keeping an eye on this developing story and update it as we learn more. ® Updated at 1903 to show that Amazon has updated its issue page with a resolution.

The Court of Justice of the European Union (CJEU) has ruled that Google may not be able to claim intermediary liability protection for YouTube content it reviews as part of a commercial partnership with a creator. The case stems from a €750,000 fine imposed on Google Ireland by Italy's communications regulator in 2022 over YouTube videos promoting online gambling. Before entering the revenue-sharing agreement, under which Google placed pre-roll ads on the creator's videos, the company reviewed the channel's content. The regulator argued that this examination undermined Google's claim that it acted as a neutral intermediary exempt from liability. Google appealed against the fine, and the case was referred to the CJEU. The court rejected Mountain View's reading of the liability exemption, leaving Italy's Council of State to decide the dispute. The exemption still applies where "the service provider has neither knowledge of nor control over the information which is transmitted or stored." However, in this instance, Google was aware of the content. The court held that the exemption "does not apply" to a platform operator that agreed commercial terms with a channel where the operator "carried out an examination of the content of that channel," including its main theme, its most-viewed or newest videos, or the associated metadata. In effect, the ruling limits Google's ability to rely on its "intermediary service provider" defense when it has reviewed a channel as part of a commercial partnership. In those circumstances, the platform may be unable to claim the liability exemption for the content at issue. This doesn't mean Google is liable for everything on YouTube, but the megacorp needs to be more careful with channels where it has commercial deals that come with a level of content review and specific knowledge that can forfeit intermediary status. A Google spokesperson said: "We are disappointed by the CJEU's decision, which we will need further clarity on. We ⁠will raise our arguments before the Council of State." ®

UPDATED Amazon Web Services (AWS) is experiencing another outage after a CloudFront issue began throwing 5xx errors, knocking a string of websites and online services offline across multiple regions. According to AWS, the issue began at 0145 PDT (0945 UTC) this morning and affects CloudFront customers using VPC Origins. This is a relatively new CloudFront feature that lets customers serve applications running behind private load balancers through CloudFront without exposing their back-end infrastructure to the public internet. The cloud giant said customers using other origin types are not impacted, and suggested that anyone who doesn't strictly need VPC Origins could switch origin types as a temporary workaround while engineers work on a fix. “We are experiencing increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity,” the cloud giant said on its service status page. “Our engineers are engaged and are actively working to mitigate impact." At 03:18 PDT (118BST, 1018 UTC), it added: "We continue working to resolve the increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity. Customers utilizing other origin types remain unaffected by this issue. "Based on our investigation, we believe the root cause is related to a packet processing subsystem responsible for routing requests from CloudFront's edge locations to resources within customer VPCs. We continue to recommend that customers who are able to do so temporarily change their origin type to resolve the errors." It promised another update in the next hour. Users trying to reach sites affected by the CloudFront issues are being met with an error page that reads: “We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website” Among the early casualties was the AI developer platform Hugging Face, which acknowledged that its service was unavailable "from most regions in the world" due to the AWS outage while it worked on mitigation. Meanwhile, the UK's National Lottery admitted in a post on X that players were unable to access its website and mobile app due to what it described as a wider AWS outage, advising hopeful millionaires to try refreshing later. Gamers weren't spared either. Reports quickly piled up on Reddit from Fallout 76 players wondering why Bethesda's post-apocalyptic wasteland had become more inaccessible than usual, while various other threads rapidly filled with reports from disgruntled AWS customers, all describing the same symptom: CloudFront distributions returning 5xx errors while other AWS services carried on as normal. AWS had not disclosed the cause of the borkage and didn’t immediately respond to The Register’s questions. While it said the outage was limited to one CloudFront configuration, the list of broken services made it look considerably less limited. ® Updated at 17.39 UTC on July 16 2026 to add: AWS says it "identified the root cause of the issue as an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly, affecting routing of VPC Origin connections." It took mitigation actions and this led to a "full recovery." "Now that the issue has been mitigated, customers who temporarily changed their origin type can safely revert these changes. Customers utilizing other origin types were not affected by this issue. The issue has been resolved and the service is operating normally."

Indian tech services giant and retro software house HCL has decided to get into the AI datacenter business. The company yesterday revealed its plan in an announcement [PDF] released alongside its Q1 results, which included news of three-percent year-over-year revenue growth to $3.65 billion and 20 percent growth in net income which reached $488 million. CEO C. Vijayakumar also pointed to 62 percent year-over-year revenue growth for a segment HCL calls “Advanced AI” that encompasses building its own AI platforms. The CEO said HCL’s strategy is to “Benefit disproportionately from the AI-native and AI-amplified opportunities” because they “together represent the fastest growing pool of enterprise spend.” The company has therefore decided to get into the datacenter business and has found ₹3,500 crore ($36.5 million) to put toward facilities it says have “potential to scale to 50MW of capacity.” That’s not a vast facility – just one of Meta’s datacenters will host 50GW of kit – but Vijayakumar said HCL can make it relevant by using its existing software to offer “full-stack” infrastructure. “The biggest opportunity is not to rent AI, but to own the full stack,” the CEO said. “The datacenters that compute the models built to address client-specific needs.” “This is a business which is shifting from physical infrastructure to higher value AI-ready solutions,” he added. “We will create full-stack offerings by combining our capabilities across AI datacenter design, DevOps, and cloud operations, as well as a software portfolio with our new datacenter business.” HCL’s focus appears to be on Indian customers, as Vijayakumar said the datacenter investment will “position us as a key enabler of India’s sovereign AI ecosystem, expanding our presence in the fastest-growing market among largest economies with differentiated offerings around sovereign cloud, secure AI, and managed AI infrastructure.” The CEO said HCL is already “in advanced discussions with clients to ensure we start with certain level of committed consumption from day one.” The company didn’t say where it will build its bit barns, when they might come online, or how it will secure energy supply – an important consideration given we yesterday reported on an effort to locate a datacenter in renewable-energy-rich Bhutan to serve Indian customers. Vijayakumar also revealed that HCL booked $2.4 billion of new business in the quarter, a record. The CEO pointed to one of those deals as an exemplar of HCL’s AI smarts, as it will see the services company work with an unnamed Fortune 250 semiconductor equipment OEM “to accelerate AI-driven transformation across its semiconductor engineering and manufacturing value stream.” To make that happen, HCL will deploy SAP, integrate it with existing systems, and establish “an enterprise backbone for a future-ready, scalable, AI-led digital supply chain.” Another new deal, struck earlier this month and therefore not included in the $2.4 billion of new deals won in the quarter ended June 30, will see HCL work with an unidentified “Europe-headquartered Fortune Global 50 firm as a technology partner to accelerate AI-led transformation and management of their digital workplace and enterprise networks.” Numerous reports in Indian media identified the new client as Mercedes Benz, and suggest the automotive giant has moved its business to HCL from Infosys, which announces its quarterly results next week. ®