this is a broad “culling” question applicable to many environments, a quick internet search ought to turn up lots of “strategies”. your choice of strategy might depend on how big your map really is, as Corona already internally handles “visual culling” so even if you have a lot of tiles offscreen, most won’t be rendered anyway (they’d still be consuming memory however).
if your map is truly large enough to have memory issues (not graphics issues) then you’ll need your own memory-culling system on top of Corona’s graphics-culling. for a zelda-style map, one strategy is to think in terms of the “sub-screens” (say 16x14 tiles, for instance), then cull based on a 3x3 area of sub-screens centered around player. it’s “cheaper” than per-tile culling if you can spare at least that much memory, though does require that you can “quickly” create/destroy a 1x3 (or 3x1) set of sub-screens on-demand at runtime rates.
for extreme memory-saving, consider that for per-tile culling you really only need (R+1)*(C+1) sprites ever (where C,R are the number of tile columns/rows in your viewport) - you can just move them around and “repurpose” them (ie, change their sprite frame) without ever destroying/recreating them. this is essentially the opposite of the sub-screen strategy above - more work to maintain, but very memory-efficient.
keep in mind that by “memory-saving” we’re not talking about texture memory - that’s going to remain a fixed cost assuming that you have the whole tilesheet always loaded (which is probably recommended, for performance reasons - you wouldn’t want to be loading/unloading textures while scrolling).
