My background: I spent most of my career (starting in 2008) working at a few different startups, but have spent the past 4 years working for one of the big tech companies.
There's actually a lot that's the same. If you were hired by a large tech company, they think you can do your main thing (write code, think through product strategy, whatever) well. Most of how you do that thing doesn't change.
You're still working with people. People everywhere are more-or-less the same. Some bosses do a good job encouraging debate/disagreement, some less so, but that's true both at large companies and start-ups.
There's a lot of pressure that comes with working at a startup where a release determines whether the company will continue to have money, something you don't have to worry about as much in a large company. But life in a large company is often capital constrained in a similar way. In a large company, the set of pressures is different (keeping costs down in order to be more profitable, as opposed to being limited by what check VCs wrote), but you still have some budget you're working against, timelines, and the possibility of your team being defunded.
At a big company, you have to distinguish between where your team is in the product lifecycle. Some teams are developing new products. Working for these teams feels a lot like working at a start-up, and comes with many similar challenges. It does have some other challenges - you have pre-defined standards for what it means for something to be ready for launch, but you also have a larger network to draw from in order to get you there.
For established products at a large company, the tolerance for risk is much lower. Other commenters have said "well, you're just a cog in the machine now," but this risk tolerance indicates the opposite: your one-line code change or that feature you designed can make life better for thousands of people, or it can make life a nightmare. There's a lot of individual responsibility that comes with that.
At a large company, be prepared to spend longer thinking through your ideas and defending them to others. This comes with trade-offs: you are forced to think through your ideas, making them clearer and better along the way (good), but also may spend less time on that then writing code (bad).
At least at the large company I work for, I've found the standards are much more consistent. I spent the first 8.5 years of my career defending/recommending/arguing for the use of unit tests (of course, being pragmatic with it, when it's helpful, and all the other caveats that ought to come with that). I have not had that debate in 4 years - engineers here understand why we need unit tests (and code reviews, design reviews, coding standards, linters, automated builds...). I think this has a lot to do with the culture and one group of employees learning the lessons from a previous group, but for whatever reason it might be it does make life easier to take certain standards for granted.
At a large company, the access to experts is pretty amazing. If you don't know how to do something - how to fix an issue with your service, how to get started in new technology, conduct a particular kind of user study, etc. - there's very likely someone who does know that is an email send away. At a start-up, even a larger O(100's) people start-up, your network is more limited.
At least at the large tech company I work for, when people are ready for something new, that usually means moving within the company. This isn't usually an option at a start-up. This means that all that stuff you learned about the company's special ways of doing things maintain transferrable for longer.
I've found an entrepreneurial approach can be valuable at a larger company. At the company I work for, it's not unheard of for new ideas to go to market in the matter of months, but very often management looks for successful milestones at a rate not that different from what startup management or VCs look for: some kind of 2-3 year plan of where you want to end up, and with a milestone release within the next 6-12 months, closed betas before that, etc. All the same things apply about knowing your customer (who, in this case, might be someone else inside the company), understand the customers' needs, start with a problem and not a solution, and all that.
One of the biggest differences has been navigating the corporate structure. At a 300 person company, you probably know who to go to for any possible problem you can imagine. At a large tech company, you probably don't know who to talk to, and you might not even know who to talk to in order to find out who to talk to. Finding the right person to talk to is more of a skill in these larger settings, and it helps to understand the corporate structure, what are the different teams working on similar kinds of things as your team, and all that sort of thing.
So, that's a bunch of things, let me know if there's some other aspect of the switch you're curious about.