mac1.metal

I should have written this post before "Terraforming mac1.metal at AWS", but I did not think about the series of posts back then. Now I do.

iOS applications are fully dependent on XCode that only supports macOS platforms, also using containers or virtual machines is nearly impossible because of XCode installation size (~32GB).

macstadium has been doing this for a while, but it can be unstable and annoying at times. If they can be better than macstadium then it is compelling for iOS dev shops who don't want to maintain a fleet of mac mini build servers. Also amazon can use it themselves for their own CI services

Build servers for iOS apps, it can also be part of a CI/CD flow for mobile or cross-platform apps because you need to be running MacOS to upload apps to App Store Central

Fuzzing binaries comes to mind as well.

I have the same question. Why would I want this over a Linux instance (assuming the latter is cheaper)?

You can't build for macOS, iOS, iPadOS, watchOS, tvOS on a Linux machine. Well, not legally / non-hackily anyway.

We have an internal application that would benefit from having local access to our network infrastructure (VPC) without needing a VPN.

Build/CI systems for Mac and iOS apps, I would guess. Definitely not for running generic web apps.

Custom CI agents perhaps. Or maybe on-demand / shared build / debugging machines for a development shop that does mostly cross-platform mobile development and (very) occasionally encounters ios-specific bugs.

Builds without having to maintain your own macs.

Automated testing using browsers on target operating systems as well as other testing that requires the target operating system. CI/CD pipelines using Mac build tools is another.

As with everyone else, the answer is CI/CD. Having run a team that built out its own Mac build farm... it's a pain.

Wanted to try one. Then I saw the price...

$26 per day according to TC, for a full Mini (6 core i7/32 GB RAM). If you do enough that you can get high utilization that is cheaper than the CI services. (e.g. travis wants close to double for 2 vCore/8GB VMs) EDIT: On the other hand, renting a physical machine at Macstadium is a lot cheaper, so you'll want to have the AWS integration or some flexibility...

BSDP + IPKVM?

Sorry, but dedicated hosts are expensive AF, it is not a virtual machine, you pay for the hardware.

CI/CD for iOS, MacOS, and React Native builds. Right now the pricing for Mac instances for builds via Github, Gitlab, Circle, etc are ludicrous. For a certain developer velocity, these instances will probably be much, much cheaper than running builds through the CI/CD SaaS providers.

Yup! There are additional nitpicks that haven't yet been discovered, I'm cheering you on from the sidelines.

More days or less customers is also ok.

Apple’s licensing terms for macOS permit _only_ the licensing of one unit of Apple macOS running on one unit of Apple hardware to one customer for a minimum term of one day. There is no option to purchase a virtual-machine or other shared-instance license when macOS is involved.(Nitpicky points: I believe the customer can do whatever they want with their licensed cloud Mac hardware, such as dual-boot different releases of macOS or virtualize to their heart’s content, as long as they are the exclusive user of the Apple hardware underlying any instances of macOS. “One customer per Mac per day, no more and no less” is probably a better summary in hindsight.)

That sounds elegant for IO, but I wonder how device level security is handled, out of band management, and firmware updates.

> As always, I asked the EC2 team for access to an instance in order to put it through its paces. The instances are available in Dedicated Host form, so I started by allocating a host.Dedicated Hosts () are more pricey than virtual instances (most EC2) and Dedicated Instances. Not sure if it's possible to containerize/sell as many virtual instances off a dedicated server without paying a separate high license fee to Apple.

I can't see a way to frame it otherwise - it's certainly functionally identical in terms of effect, both on the end user's need and on Apple's interests to sell hardware.

Right. The Nitro cards speak PCIe, and Thunderbolt is “just” PCIe plus DP in one:> Thunderbolt combines PCI Express (PCIe) and DisplayPort (DP) into two serial signals,[7][8] and additionally provides DC power, all in one cable.From the Wikipedia entry at

Yes, AIUI AWS Nitro is a PCI (in this case thunderbolt?) disk abstraction system that fronts EBS for the host.

Over Thunderbolt:

MacOS AMI images, EBS disks, VPC networking, 10gbps ENA. Bare metal only, Intel available now, M1 coming soon. This is another game changer.The post says they’re based on Mac Minis, but also use AWS Nitro. Is this custom AWS specific hardware?

They would have been VMing on top of the machine provided by MacStadium.

The limitation is only from Big Sur. AWS chose to do it on Catalina so that customers may not experience a big change later on. This means any provider who uses < Big Sur is in compliance.

It seems we are making the assumption that GitHub/MacStadium are bound by the same terms as everyone else. There is nothing that says they can't get special treatment for some arbitrary reason.

Yeah I think the issue here is more likely GitHub not following the EULA

As weird as it is, I think as long as they provide an entire physical Mac you’re free to run as many macOS virtual hosts on it yourself as you want to. At least that’s my understanding of the EULA explained in the MacStadium blog post.

But "they provide the outputs" _is_ the gray area – does providing the outputs count as renting out the software itself?

the user doesnt have these rights in their eula.

Good point!

But they will have to update to Big Sur in the feature. So if they don‘t set the limitation now they will have to „worsen“ the service later, it‘s best to the set the limitation now even if not required.

Luckily there are still cloud services that you can use for iOS CI like Bitrise.

But the original post says they're not using Big Sur. The available OSes are Mojave and Catalina. Unless that term exists in those licenses too?

"The instances are launched as EC2 Dedicated Hosts with a minimum tenancy of 24 hours"These are just rentable Mac Minis, not VMs. This will have only one use case and that's for build servers. Unless anyone has scalable AppleScript jobs to run?

The 24 hours is dictated by new Big Sur EULA.[https://9to5mac.com/2020/11/11/macos-big-sur-adds-leasing-te...](https://9to5mac.com/2020/11/11/macos-big-sur-adds-leasing-terms-that-pull-hosting-services-like-macstadium-out-of-a-legal-gray-area/)From the new EULA (not just for Amazon, paraphrased by 9to5mac):* Apple software and hardware must be leased “in its entirety to and individual or organization”* A lease period must be “for a minimum period of twenty-four (24) consecutive hours”* Customers must now accept software agreements for all installed software of leased hardware* All of these changes are only offered for “Permitted Developer services,” which are now spelled out for users* Developers may now “install, use, and run additional copies or instances of the Apple Software within virtual operating system environments”* The “lessor” such as Macstadium is fully responsible for making sure that all of these new requirements are upheld

Why do they restrict the use to development work?

...or Codemagic.io

if I've mac with accepted EULAs and share it via network to wife, kids or neighbor (might be even wife/neighbor used it to do some business activities) - how it does works from legal perspective? is it will viewed as EULA violation?

There are some fairly broad usage restrictions in section 1.J.[1]._Except as otherwise permitted by the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at a time, and (ii) you may not make the Apple Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Apple Software._ Make of it what you will.

Link to Apple's EULA:Under: "Leasing for Permitted Developer Services"

The EULA applies to leasing the whole OS. I don't need a whole virtual Mac to run CI jobs. It doesn't sound like there's anything stopping anyone from offering a Mac CI job runner that gets shared with multiple organizations at the same time.

If you're ok with saying "shame on you Apple" every time they pull a trick like this, then I don't know how to convince you.I'm just saying that as Apple gets more power this may get worse, hence the shortsightedness remark.

> Because there's money to be made by not "ditching the entire Apple ecosystem."That's very shortsighted. You can make money without Apple. And by doing so, you show that you value open, generic compute systems. Also, the prosperity of your business won't be at the whim of Apple.

Because there's money to be made by not "ditching the entire Apple ecosystem."If you were able to run a business that was fun, that made you money, and that enabled you to help other people have fun and make money (i.e., your employees), would you not do that out of principle? I'm genuinely asking.

You could also make money by selling paperclips or by creating satellite constellations. Which path you choose comes down to interest, expertise, and luck/chance.All businesses have constraints. In this business, you're subject to the Apple EULA. In others, you're subject to government regulation or pricing pressure due to commoditization. That's not short-sighted — no industry is forever, and there's money to be made now. Why not deploy their expertise toward financial success (and, presumably, fun)? There's demand for these services — someone's going to fill it.For folks who don't value 'open, generic compute systems' over 'putting food on the table', the closed nature of Apple's ecosystem is just the reality they need to deal with. They're not making a moral tradeoff, just a practical one.Are you suggesting MacStadium and co should shut down their businesses out of principle? Will you employ them once they do? Where will their customers go?

It would be cheaper if you had your own data center already or an office space sufficiently large to store these Mac Mini's.

I will spend more time trying (with no great chance of succcess) to obtain authorisation to establish an additional commercial relationship, and corporate billing/card approval, and the time burned on this instantly exceeds any amount of money they could possibly save me.

MacsWhy not ditch the entire Apple ecosystem while you still can? Show them that we, developers, don't like feudal lords that like to tell us what we can and cannot do with our systems. So others won't dare to copy them.

You can check in one day, one shot, if your app "works" on an M1 and that's that? Yikes.

If you're already in AWS, your deployment infrastructure and tooling is already configured and tuned for AWS. Deploying a Mac EC2 instance is just adding another target.

It's a lot easier to click a button on the AWS console then to get approval to buy new capital equipment, or to get approval to use a new vendor (for which we'd likely need legal review, security audits, etc.).

I could see it being reasonable if a medium to large companies entire infrastructure was cloud based, and they only needed a handful of mac minis.

If I need to check if my app works on m1, I can now spend $24 to do that instead of $650 or whatever it retails for.

From my experience, saying "we're just going to increase our EC2 spend" is a no-brainer

In a very substantial number of enterprises; the cost of procuring, validating, installing, powering, cooling, fire-rating, commissioning, maintaining, writing up, handing over, revising, reporting, auditing, approving, and very occasionally actually executing those hot<>cold standby procedures, _exceeds the entire purchase cost of the cold standby unit_.

Hell, the company will spend more money on agonizing over the question of whether we should buy a $1500 Mac in the first place.

For what Amazon is asking, one could have both an extra hot _and_ an extra cold standby locally, so it still doesn't make economic sense for a large company.

The problem is not the first time setup. The problem is essentially what “uptime” you can provide.

MacStadium's prices are "rather less than 20%" of AWS's prices. To make sense, AWS would have to be comparable to MacStadium's pricing.

I'm no expert, but I'm stunned that it costs more than $10,000 a year to connect a single computer to a corporate network such that AWS Macs become cost competitive.

This is what I mean by "hobbyist mindset": driving straight past the huge neon sign flashing _TCO_ , assuming that some idiot (that's me) has failed arithmetic 101

MacStadium is not inside the AWS network, so there’s nothing comparable about it.

Sure, but then I'd have to use an iPhone. The machine is the main thing to my customers, the app is just a tool for monitoring its status and the Android app and webserver shows the same information.

I have an app I need to compile on a Mac that I only make changes to maybe once a quarter, or four days a year. That's an ideal use case for on-demand AWS Macs, and I'll probably transition to that if the Mac Mini in the corner ever decides not to boot or not to accept a mandatory OS update when I have to use it someday.

Those numbers actually make the AWS instances a shoo-in for my current development purposes.

It does not recognize the live resize of EBS either — you must reboot the instance so resize change can take effect.

AWS wants to ensure that anyone who uses the Host (Mac mini) after you will get your data stored neither on disks (including the physical SSD mentioned earlier) nor inside memory or NVRAM, nor anywhere else.

you are allowed to use the Instances solely for developer purposes

Therefore, you can launch the next Instance on the same Host no earlier than ~1,5 hours after you terminated the previous one.

And the same relates to the Elastic Network Interfaces — attach and reboot the instance to apply it.

It can’t recognize the attached EBS if you connected it while the instance was running — you must reboot the instance to make it visible.

It lives in your VPC because it is an EC2 Instance, so you can access many other services.

It supports AutoScaling

And you can share the instances using AWS Resource Access Manager.

It can report CPU metrics to CloudWatch.

The mac2.metal costs 40% less compared to the mac1.metal

AWS announced EC2 macOS instances based on the Intel CPU on 30 November 2020. After a year and a half, the M1 Mac Instances arrived (7 July 2022).

you are allowed to use the Instances solely for developer purposes

AWS wants to ensure that anyone who uses the Host (Mac mini) after you will get your data stored neither on disks (including the physical SSD mentioned earlier) nor inside memory or NVRAM, nor anywhere else.

Therefore, you can launch the next Instance on the same Host no earlier than ~1,5 hours after you terminated the previous one.

And again: you can release the “mac1.metal” Dedicated Host no earlier than 24 hours after it was allocated.

It is possible to set a custom screen resolution when connected to the instance using native ScreenSharing or any other VNC-compatible software.

System updates are disabled by default in the macOS AMIs provided by AWS. But you can use them with no issues.

The time from the Instance launch until you can SSH into it varies between 5 and 20 minutes.

The Mac metal Instances can boot from the EBS-backed macOS AMIs only.

If you specified the EBS size to be more than AMI’s default, you need to resize the disk inside the system manually after the boot

And you can share the instances using AWS Resource Access Manager.

It supports AutoScaling

It can report CPU metrics to CloudWatch.

For EBS, it supports the attachment of up to 16 volumes for mac1

My test upload/download to S3 was about 300GB/s.

The mac1.metal instances are Intel-based 12 vCPU, 32 GiB RAM | 10 Gbps Network and 8 Gbps EBS bandwidth

AWS announced EC2 macOS instances based on the Intel CPU on 30 November 2020.

My Amazon Elastic Compute Cloud (Amazon EC2) macOS instance has slow processing speeds when it invokes, updates, or renders data, or when it runs applications. Or, the macOS instance that I launched with an Amazon Elastic Block Store (Amazon EBS) snapshot has slow performance.